Internet Engineering Task Force Authors: INTERNET DRAFT R. Rajan/S. Kamat AT&T/IBM P. Bhattacharya/D. Biswas Cisco/FORE Systems 5/April/1999 Networking Policy Condition Information Model draft-rajan-policy-conditions-00.txt Status of Memo This document is an Internet-Draft and is in full conformance with all the provisions of Section 10 of RFC2026 except for the right to produce derivative works. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This draft is in accordance with the policy information model presented in draft-ietf-policy-core-schema-02.txt and elaborates on the information model presented for policy rule conditions for networking policy. This draft replaces draft-ietf-policy-conditions-00.txt. Discussion of this draft will be carried on the policy mailing list (policy@raleigh.ibm.com). Suggestions for improvement may also be sent to rajan@research.att.com. Distribution of this memo is unlimited. Copyright Notice rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page i] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines an information model for networking policy conditions as part of the general information model for representing networking policy defined in draft-ietf-policy-core-schema-02.txt. The information model described in this document is focussed on the structural class networkingPolicyCondition that extends the class policyCondition described draft-ietf-policy-core-schema-02.txt. Five auxiliary classes are defined to describe conditions that refer to (1) the communicating hosts, (2) the communicating users (3) application data (4) routing information at the device enforcing the policy and (5) layer 2 or data link layer information of the device. 1. Introduction The Policy Framework Core Information Model Class Hierarchy (PFCIM) [1] presents a schema for representing policy rules through five general core classes: policyGroup, policyRule, policyCondition, policyAction, and policyTimePeriodCondition. The classes comprising the PFCIM are intended to serve as an extensible class hierarchy (through specialization) for defining policy objects that enable application developers, network administrators, and policy administrators to represent policies of different types. (Please refer to [1] for details on the classes and their relationships to one another.) The draft [1] anticipates that "policy solutions for specific areas, such as QoS and security are expected to use some of these classes directly while creating their own subclasses derived from policyCondition and policyAction." This draft elaborates on the policyCondition class by providing a flexible and extensible set of classes and attributes to represent commonly used criteria relavant to the administration of networking protocols. This draft is conformant with the IPSec and QoS policy definitions in the drafts [4] and [3]. Policy conditions are meant to represent criteria that administrators use in enforcing control over behavior of devices or users in a network. This document is NOT concerned with all possible conditions that may arise with respect to computing and communication devices. It is particularly targeted at the needs of controlling resource usage and securing communication between users in an IP network. As mandated by the policy working group, the ability to represent rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page ii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 policy requirements of integrated services with RSVP, differentiated services and IPSec are the first targets of this effort. In keeping with the focus of this effort, we identify 5 condition categories that are commonly used by administrators in controlling access to network resources and services. These are host, user, application and routing and layer 2 or data link layer information. We extend the class policyCondition to the subclass networkingPolicyCondition, and define 5 auxiliary classes: hostConditionAuxClass, userConditionAuxClass, applicationConditionAuxClass, routeConditionAuxClass and layer2ConditionAuxclass. The auxiliary classes may be attached to networkingPolicyCondition in order to create fully formed conditional statements that are appropriately structured for the purpose at hand. The rationale for this class structure is discussed in Section 3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference . 2. Design Goals The following design objectives motivate the choice of class hierarchy and choice of attributes in this document: 1. Purpose -- The condition portion of a policy rule must be usable by the decision point to identify a substream of packets to which associated actions then apply. 2. Expressive Power -- Conditions must be capable of expressing commonly used administrative criterea for distinguishing amongst packet streams. Such criterea include, but are not restricted to, the communicating users and hosts, the applications generating the packet stream, the routing of packets in the stream, information regarding the data link and MAC layer protocols, interface information on the policy enforcement point, and the time of day that the communication occurs. 3. Manageability -- Policy condition objects, such as information regarding users and applications need to be created, modified and deleted. Common administrative changes should not involve excessive processing. 4. Extensibility -- Classes should be defined so as to be easily extensible. rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page iii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 5. Reusability -- Class definitions should be reusable across multiple requirements. 3. Extending policyCondition 3.1. The Class Hierarchy As defined in [1] the class policyCondition inherits from the class top. We extend the class policyCondition to the subclass netwokingPolicyCondition. The class netwokingPolicyCondition has 5 auxiliary classes: hostConditionAuxClass, userConditionAuxClass, applicationConditionAuxClass, routeConditionAuxClass and layer2ConditionAuxclass. top | | |----policyCondition | | | networkingPolicyCondition ~~~~~ | |(auxiliary classes) |-----------------hostConditionAuxClass |---------------- userConditionAuxClass |-----------------applicationConditionAuxClass |-----------------routeConditionAuxClass |-----------------layer2ConditionAuxClass 3.2. Class Definitions The class definition of policyCondition, repeated from [1] is as follows: NAME policyCondition DESCRIPTION A class representing a condition to be evaluated in conjunction with a policy rule. DERIVED FROM top TYPE structural AUXILIARY CLASSES NONE POSSIBLE SUPERIORS policyRule OID MUST cn PolicyConditionName MAY rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page iv] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 The class policyCondition is specialized to networkingPolicyCondition for extensibility. The class definition is as follows: NAME networkingPolicyCondition DESCRIPTION A class representing a networking condition to be evaluated in conjunction with a policy rule. DERIVED FROM policyCondition TYPE structural AUXILIARY CLASSES hostConditionAuxClass userConditionAuxClass applicationConditionAuxClass routeConditionAuxClass layer2ConditionAuxClass POSSIBLE SUPERIORS policyRule OID MUST MAY The following auxiliary classes are used to append attributes to the class networkingPolicyCondition. NAME hostConditionAuxClass DESCRIPTION An auxiliary class representing a condition to be evaluated in conjunction with a policy rule. The condition is based on the communicating end hosts. DERIVED FROM top TYPE auxiliary AUXILIARY CLASSES none POSSIBLE SUPERIORS networkingPolicyCondition OID MUST MAY sourceIPAddressRange destinationIPAddressRange sourceHostID destinationHostID NAME userConditionAuxClass DESCRIPTION An auxiliary class representing a condition to be evaluated in conjunction with a policy rule. The condition is based on the communicating users. DERIVED FROM top TYPE auxiliary AUXILIARY CLASSES none POSSIBLE SUPERIORS networkingPolicyCondition OID MUST MAY senderID receiverID rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page v] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 NAME applicationConditionAuxClass DESCRIPTION An auxiliary class representing a condition to be evaluated in conjunction with a policy rule. The condition is based on the nature of traffic, the transport layer in use and the application. DERIVED FROM top TYPE auxiliary AUXILIARY CLASSES none POSSIBLE SUPERIORS networkingPolicyCondition OID MUST MAY applicationName, sourcePortRange, destinationPortRange, protocolNumberRange, receivedTOSByteCheck NAME routeConditionAuxClass DESCRIPTION An auxiliary class representing a condition to be evaluated in conjunction with a policy rule. The condition is based on the routing of the packet through a device e.g. incoming and outgoing interfaces. DERIVED FROM top TYPE auxiliary AUXILIARY CLASSES none POSSIBLE SUPERIORS networkingPolicyCondition OID MUST MAY interface NAME layer2ConditionAuxClass DESCRIPTION An auxiliary class representing a condition to be evaluated in conjunction with a policy rule. The condition is based on the nature of traffic, the transport layer in use and the application generating data. DERIVED FROM top TYPE auxiliary AUXILIARY CLASSES none POSSIBLE SUPERIORS networkingPolicyCondition OID MUST MAY sourceMACAddress rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page vi] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 destinationMACAddress 802.1QVLANId SNAPHeaderValue etherTypeValue DSAP SSAP encapsulationType encapsualtionValue 3.3. Rationale behind the class structure There are two design choices that we need to justify in the manner of extending policyCondition. First, the decision to choose particular condition categories and the second the choice of class structures, especially the use of auxiliary classes. The three categories - users, hosts and applications - are very natural to administrative decision making. However, the need to define policies in terms of a dynamic category such as routing requires some explanation. Consider, for instance, a corporation that has its campuses connected by a leased line infrastructure with a backup connection over the internet. When the primary network is down, it is prudent policy to require that inter-campus traffic be encrypted. There are many ways to enforce this, for instance instruct access routers to encrypt traffic based on the destination as well as the outgoing interface. Similar examples may be considered for QoS as well, where a high grade reservation is made over a primary ISP backbone, with a lower grade backup reservation triggered by routing changes. A number of different class hierarchies are feasible even when we have determined the categories we wish to represent and their attributes. For instance, one choice would have been to associate all the attributes of users, applications, hosts, etc, to the class policyCondition. Why create the subclass networkingPolicyCondition at all? The answer is extensibility. To take a concrete example, suppose that we would like to use a similar information model as presented in this document to trepresent policy conditions for DHCP. While the attributes presented here as host attributes would continue to be relevant to DHCP, those presented as part of layer 2 attributes may be totally irrelevant. The subclass networkingPolicyCondition allows us to group all the conditions required for the purpose of expressing networking policy without requiring that all extensions have the same condition attributes. The next obvious design is to associate all attributes we want - those of users, hosts, applications, etc - to the class networkingPolicyCondition (as optional attributes, say). Will this rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page vii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 not have the same result as the elaborately subclassed structure presented in this document? The issue again is extensibility as illustrated below. policyCondition (user, application) | | _____________________ | | policyCondition-A policyCondition-B (user-A, application) (user, application-B) | | | | policyCondition-C policyCondition-D (user-A, application-A) (user-A, application-B) Suppose a certain definition of the policyCondition class were to contain the characteristics of users and applications as intrinsic attributes of the class itself. It is quite conceivable that one vendor would like to extend the base class to accomodate an expanded definition of user (say user-A), and another would prefer to expand the definition of application (to say application-B). They would have no choice but to expand from the base class policyCondition. As LDAP does not permit multiple inheritance, the sub-classes would begin to diverge unnecessarily. With the design presented in this document, if one vendor desires to extend the category application, a second only wants to represent users in greater detail, and a third wants to do both, then they don't have to extend networkingPolicyCondition in slightly different ways. Further, the auxiliary classes hostPolicyAuxClass, etc, may be associated with other subclasses of policyCondition, DHCPpolicyCondition for instance, in a selective manner. The advantage of auxiliary classes is that they allow us to mix and match attributes creating fewer objects, when compared to subclasses. One potential disadvantage of auxiliary classes is that they cannot be instantiated, i.e., objects of such classes are used by inclusion rather than by reference. While inclusion reduces directory accesses, it could hamper reuse of common instances. Note, however, that the proposed class structure does not suffer from this problem, because administrators can instantiate common reusable conditions as part of the networkingPolicyCondition class which is a structural class. rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page viii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 4. Attributes of HostConditionAuxClass NAME sourceIPAddressRange DESC Source IP addresses to which the policy applies SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT sourceIPAddressRange may be described in any of the following formats: 1 Indicates policy applies to locally generated packets. 2-- Three dash (-) seperated strings. The IP-v4 address is in dotted decimal format. The CIDRPrefixLength is the number of unmasked leading bits. A packet matches the condition if the unmasked bits on the packet are identical to the unmasked bits on the condition. 3-- IP-v4 addresses in dotted decimal format. The second address must be no smaller than the first. The first denotes the start of the range, and the second denotes the end of the range. A packet matches the condition if its source address is no smaller than the first IP address in the condition, and no larger than the second. 4-- IP-v6 addresses in any of the formats supported in RFC 2373. The second address must be no smaller than the first. The first denotes the start of the range, and the second denotes the end of the range. A packet matches the condition if its source address is no smaller than the first address in the condition, and no larger than the second. DEFAULT Defaults to the entire address range, i.e., every packet matches the source address range condition. EXAMPLES 2-83.23.23.1-24 A packet with source address 83.23.23.5 matches. A packet with source address 83.23.24.1 does not. 3-83.23.23.0-83.28.28.0 A packet with source address 83.23.23.5 matches. A packet with source address 83.29.24.1 does not. rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page ix] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 NAME destinationIPAddressRange DESC destination IP addresses to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT Identical to that of sourceIPAddressRange above. The value of ``1''indicates a locally destined packet. DEFAULT Defaults to the entire address range, i.e., every packet matches the destination address range condition. NAME sourceHostID DESC Source Host Identifier SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT Two strings, colon (`:') seperated, the first describing the ID type and the second the ID value. The following IdTypes and their corresponding values are as defined in RFC 2407. Host-FQDN: X500-DN: X500-GN: Key-Id: DEFAULT Any ID is considered valid. NAME destinationHostID DESC Destination Host Identifier SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED DEFAULT Any ID is considered valid. FORMAT Same as SourceHostID. 5. Attributes of UserConditionAuxClass NAME senderID DESC Source User Identifier SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT Two strings colon (:) seperated, the first describing the ID type and the second the ID value. The following ID Types and their rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page x] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 corresponding values are as defined in RFC 2407. User-FQDN: X500-DN: X500-GN: Key-Id: DEFAULT Any ID is considered valid. NAME receiverID DESC Destination User Identifier SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED DEFAULT Any ID is considered valid. FORMAT Same as SourceHostID. 6. Attributes of ApplicationConditionAuxClass NAME sourcePortRange DESC Source Ports to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire port range 0 to 65535, i.e. every packet matches the destination address range condition. EXAMPLE 8000:8080 (ports 8000 to 8080), 8000 (only port 8000) NAME destinationPortRange DESC Destination Ports to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire port range 0 to 65535, i.e., every packet matches the source address range condition. NAME protocolNumberRange DESC Protocol numbers to which policy applies SYNTAX INTEGER EQUALITY integerMatch MULTI-VALUED rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xi] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire protocol range 0 to 255, i.e., every packet matches the ip protocol range condition. EXAMPLE 50:51 (protocol 50 to 51), 50 (only protocol 50) NAME receivedTOSByteCheck DESC A condition attribute used to select traffic based on the contents of the TOS byte of the received packet's IP header SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT String of the form xxxxxxxx:xxxxxxxx, where each of the x's is either 0 or 1. SEMANTICS Each of the substrings is treated as specifying an 8-bit field. The left substring is termed Mask and the right substring Match. The TOS byte of the received packet's IP header is ANDed with Mask and the result is compared against Match. The combination of Mask and Match allows definition of TOS byte based conditions where certain bits in the TOS byte may be ignored for the purpose of comparison. Note that is superior to in that TOS bit positions corresponding to a Mask bit of 0 are ignored irrespective of the corresponding bit. EXAMPLE An incoming packet with TOS byte 11001010 matches the condition specified by a value of 00111100:00001000 for receivedTOSByte. 7. Attributes of RouteConditionAuxClass NAME interface DESC An attribute that limits the scope of the policy to packets on specified interface(s) and the direction(s) of traffic on these. SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT Three colon separated strings. The left-most string is a numeral denoting the type of the specification, followed by the incoming and outgoing interface identifiers. Currently defined rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 type/value formats are 1-- 2-- 3-- The IP addresses are in dotted decimal notation. The interface IDs are integers unique to the host device. The first address string specifies a restriction of the rule to traffic inbound on the interface, and the rightmost string specifies a corresponding restriction of the rule to traffic outbound from that interface. An unspecified interface(s) defaults to all interfaces on the device that this rule applies to. DEFAULTS Defaults to traffic inbound on all interfaces, outbound on all interfaces. EXAMPLE 1-9.3.1.52-9.2.1.54 (Applies to traffic inbound on 9.3.1.52 and outbound on 9.3.1.54) 1-9.3.1.32- (Applies to traffic inbound on 9.3.1.52 outbound on any interface) 3- -3 (Applies to traffic outbound on interface 3 and inbound on any interface) 8. Attributes of Layer2ConditionAuxClass NAME sourceMACAddress DESC The sourceMACAddress(es) to which the policy applies. EQUALITY CaseIgnoreIA5String SYNTAX IA5String MULTI-VALUED FORMAT The IEEE Canonical representation of the MAC address. Default Entire range of values NAME destinationMACAddress DESC The destination MAC Address(es) to which the policy applies. EQUALITY CaseIgnoreIA5String SYNTAX IA5String rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xiii] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 MULTI-VALUED FORMAT Same as sourceMACAddress Default Entire range of values NAME 802.1QVLANID DESC The VLAN identified by the value in the 802.1Q VLAN tag. EQUALITY IntegerMAtch SYNTAX Integer MULTI-VALUED FORMAT The VLAN id in the 802.1Q defined header. Default Entire range of values NAME SNAPHeaderValue DESC The value contained in the SNAP header that identifies the protocol contained in the frame. EQUALITY caseIgnoreIA5Match SYNTAX IA5String MULTI-VALUED FORMAT A string representing the hexadecimal value that would appear in the SNAP header to identify the protocol. Default Entire range of values NAME ethertypeValue DESC The value contained in the ethertype portion of the frame header identifying the protocol contained in the frame. EQUALITY caseIgnoreIA5Match SYNTAX IA5String MULTI-VALUED FORMAT A string representing the hexadecimal value that would appear in the ethertype header to identify the protocol. NAME DSAP DESC The value contained in the destination SAP of the frame that can be used to identify the frame e.g. a DSAP value of 0x04 identifies SNA frames. EQUALITY caseIgnoreIA5Match SYNTAX IA5String MULTI-VALUED FORMAT A string representing the hexadecimal value that would appear in the DSAP header to identify the protocol. NAME SSAP rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xiv] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 DESC The value contained in the source SAP of the frame that can be used to identify the frame e.g a SSAP value of 0x04 identifies SNA frames. EQUALITY caseIgnoreIA5Match SYNTAX IA5String MULTI-VALUED FORMAT A string representing the hexadecimal value that would appear in the SSAP header to identify the protocol. 9. Security Considerations There are two potential security considerations, both of which may be addressed through standards compliant mechanisms. The first is the unauthorized access to read or change policy rules and related objects in the directory repository. The schema in this document SHOULD be used in conjunction with an LDAP access control mechanisms. The second exposure for violation of security lies in the communication between policy decision point and the directory repository. Such communication SHOULD be secured, with both ends mutually authenticated using SSL/TLS or IPSec. Acknowledgments We would like to thank Jean Christophe Martin, Michael See and Skip Booth for many useful suggestions. References [1] J. Strassner, E. Ellesson, and B. Moore (editor), Policy Framework Core Information Model, Internet Draft, draft-ietf-policy-core-schema-02.txt, Feb. 1999. [2] D. Piper, The Internet IP Security Domain of Interpretation for ISAKMP, RFC2407, Nov. 1998. [3] P. Bhattacharya, et. al., An An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs), draft-ipsec-vpn-policy-model-00.txt, Oct. 1998. [4] Rajan, R., Kamat, S., et. al., Policy Action Classes for Differentiated Services and Integrated Services, draft-rajan-policy-qosschema-01.txt, Apr. 1999. rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xv] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 [5] K. Nichols, S. Blake, F. Baker and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC2474, Dec. 1998. [6] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access Protocol, RFC1777, Mar. 1995. [7] M. Wahl, A. Coulbeck, T. Howes and S. Kille, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions Internet Draft draft-ietf-asid-ldapv3-attributes-07.txt, August 1997. [8] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. AUTHORS' ADDRESS Raju Rajan AT&T Labs - Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 email: rajan@research.att.com Sanjay Kamat IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 email: sanjay@watson.ibm.com P. Bhattacharya Internet Services Management Group Cisco Systems 255 Tasman Drive San Jose CA 95134 email: pbhattac@cisco.com Debasish Biswas FORE Systems 1805 McCandles Drive Milpitas, CA 95035 debasish@fore.com rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xvi] Internet Draft draft-rajan-policy-conditions-00.txt 5/April/1999 Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. rajan,kamat,bhattacharya,biswas Expires 5/October/1999 [Page xvii]