Sharon Chisholm Internet Draft Nortel Networks Sandeep Adwankar Motorola Document: draft-chisholm-netconf-model-01.txt Expires: April 2005 October 2004 Framework for Netconf Data Models Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo defines a framework for defining content for Netconf. Conventions used in this document 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 [ii]. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 1] Framework for Netconf Data Models October 2004 Table of Contents 1. Introduction...................................................3 1.1 Definition of Terms........................................3 2. Considerations for Interoperability............................4 2.1 Data Modeling Language.....................................4 2.2 Conformance................................................4 2.2.1 Requirements4 2.2.2 Fine Grain Conformance 4 2.2.3 Operations on Data5 2.2.4 Element Status 5 2.2.5 Schema Level Conformance6 2.3 Access Control.............................................6 2.4 Versioning.................................................7 2.5 Backwards Compatibility....................................8 2.5.1 Enumerations8 2.5.2 Simple and Complex Types8 2.5.3 Lengths 9 3. Considerations for Extensibility...............................9 3.1 Data Types.................................................9 3.2 Elements and Attributes....................................9 3.2.1 Consider Attributes as Metadata 9 3.2.2 Consider the Lack of Extensibility of Attributes9 3.3 Other Extensibility Considerations........................10 4. Considerations for Parse-ability..............................10 4.1 Well-formed XML...........................................10 4.2 No DTDs...................................................10 4.3 Avoid Mixed Content.......................................10 4.4 Use an Explicit Namespace on Attributes...................11 4.5 Use Container Elements for Lists..........................11 5. Considerations for Usability..................................12 5.1 Naming....................................................12 5.1.1 Proper Tag Names 13 5.2 Considerations for Usability..............................14 5.3 Error Handling............................................14 5.3.1 Design Considerations14 5.4 Schema Documentation......................................14 6. Considerations for Predictable Modeling.......................15 6.1 Managed Object Representation.............................15 6.2 Containers versus the Data................................16 6.3 Defining Relationships....................................16 6.3.1 Element Relationships17 6.3.2 Instance Relationships 17 6.4 Specifying Statistics, Status and Configuration Information17 7. Other Topics..................................................18 7.1 Schema Identity Information...............................18 8. Relationship to Netconf Protocol..............................20 9. Security Considerations.......................................23 10. Acknowledgements.............................................23 Chisholm & Adwankar (Editor)Expires - March 2005 [Page 2] Framework for Netconf Data Models October 2004 11. Authors' Address.............................................23 12. References...................................................23 12.1 Normative................................................23 12.2 Informative References...................................24 13. Full Copyright Statement.....................................24 1. Introduction NETCONF [NETCONF-PROTO] can be conceptually partitioned into four layers: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ This document provides an introduction to the Netconf Data Model. This work provides a framework for Netconf content. This framework is intended to provide guidance for the creation of Netconf content for the purposes of enabling interoperability, extensibility, parse- ability and usability. 1.1 Definition of Terms Element An XML Element[XML]. Managed Entity A node, which supports netconf[NETCONF] and has access to management instrumentation. Managed Object Chisholm & Adwankar (Editor)Expires - March 2005 [Page 3] Framework for Netconf Data Models October 2004 A collection of one of more Elements that define an abstract object of interest. ACL Access Control List. Used to associate permissions to perform operations by a particular user to a particular Element. 2. Considerations for Interoperability This section describes some restrictions on Netconf content that will increase interoperability between implementations and between different versions of a given implementation. 2.1 Data Modeling Language XML Schema should be used to define the XML-formatted data that will be transported via Netconf. 2.2 Conformance 2.2.1 Requirements The following are the requirements that have been identified for the conformance and compliance aspects of Netconf data models. 1. Conformance Needs to be machine-readable 2. Both a high level of abstraction and lower one - specific groups of objects as well as individuals. 3. It would also be good to be able to note specific exceptions to conformance. 4. Dependencies between conformance should also be discoverable - in order to do A, you need to first do B, for example. It was noted that currently adding values to enumerations has an impact on conformance. 5. It will be necessary to be able to specify the minimum and maximum access to objects, compared to whether it can be read, written or created. 2.2.2 Fine Grain Conformance When defining elements, the 'minOccurs' and 'maxOccurs' tags must be used to specify whether that object is required to have a compliant schema. When defining an attribute, the 'use' tag must be used to define whether the attribute is required. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 4] Framework for Netconf Data Models October 2004 2.2.3 Operations on Data Operations fall into one of the following equivalence classes: "Create", "Delete", "Detect", "Read", "Write", and "Execute". A value of 'create' means it is possible to create new instances of this element using the netconf or commands. A value of 'delete' means it is possible to destroy instances of this element using the netconf , or operations. A value of 'read' means that it is possible to view values of this element using either the or operations. A value of 'write' means it is possible to modify an instance of this element using the netconf or commands. A value of 'execute' means that there is a side effect execution such as rebooting that is permissible as a result of a netconf or a command. [Editor's Note: A definition of 'Detect' is required] Netmod introduces the appInfo elements of 'minAccess' and 'maxAccess' which can contains a non-empty space separated list of values. The 'minAccess' element defines the set of operations that must be supported in order to claim compliance to this schema. The 'maxAccess' element contains the full set of operations that make operational sense for this object. For example, a status object might have a 'minAccess' of 'read' but a 'maxAccess' of 'read write' to indicate that it must be possible to perform a get operation the status, but implementations could also allow set operations on it as well. In the case of a statistic, both the 'minAccess' and 'maxAccess' might have values of 'read'. 2.2.4 Element Status As a schema evolves, certain elements may become obsolete. Simply deleting these from the Schema may be acceptable for elements that did not see implementation, but others will require a strategy to allow implementers to migrate away from the old object. An optional appInfo element called 'status'SHOULD be used to provide the status of the element. When not present, it will assume a value of 'current'. The other value of this object is 'obsolete' which indicates that implementations should consider migrating away from Chisholm & Adwankar (Editor)Expires - March 2005 [Page 5] Framework for Netconf Data Models October 2004 this object and that its implementation is not longer required to be considered conformant. For example 2.2.5 Schema Level Conformance In order to claim compliance to a netmod schema, all elements MUST conform to their given minOCcurs and maxOccurs definitions and all elements with a status of 'current and with a minOccurs greater than or equal to one MUST be supported. In addition, all of the operations listed by the minAccess attribute MUST be supported. 2.3 Access Control For discussing access control, we shall use the same equivalence classes for operations on data: "Create", "Delete", "Detect", "Read", "Write", and "Execute". Each instance of an element should be associated with access control constructs that describe the access privileges. The access control List (ACL) associated with a node should be within bounds described by maxAccess. The ACL is defined as an unbounded list of ACL entries and a boolean flag that describes ACL inheritance. Each ACL entry contains -- access list which is a list of NetConf protocol operations that can be performed on the managed object. -- identifier list which groups accessors together. An accessor is an identifying entity to which access privileges have been granted. -- accessDuration is an optional element that provides a time interval over which an ACL entry is valid. The ACL inheritance flag describes ACL inheritance mechanism. If this flag is true then ACL entries of parent node are inherited and are combined with ACL entries defined for this node. The XML Schema representation of Access control is provided below. An example of ACL with read and write access to a AverageReview node which is part of a book node is as below. www.libraryManager.com P20Y2M3D In this example, the www.libraryManager.com has write access to this node. If AverageReview node definition is such that it inherits ACLs, then the complete ACL of this node will be aggregation of ACLS of parent node Book and its parent node Catalog. 2.4 Versioning The current version of a schema needs to be complete, not a delta from the previous version. The XML Schema version attribute will be used to signify version Chisholm & Adwankar (Editor)Expires - March 2005 [Page 7] Framework for Netconf Data Models October 2004 For example: The XML Schema version attribute will be used to signify version. This allows applications to be aware of XML Schema versions, and changes to XML Schema version, without forcing instance documents to change to a new schema if the new schema is backwards compatible. Instance documents should indicate their compatible version range with an attribute on the root element which contains a list of compatible versions. This implies that applications which consume instance documents must perform processing to confirm XML Schema compliance When the context or behavior of an element is modified between versions a new schema should be created rather than updating the version of an existing XML Schema. Alternatively, a new element could be created in the existing schema, but using a different name. 2.5 Backwards Compatibility Backwards compatibility requirements come in two forms. The first is bits on the wire compatibility of managed entities and manager implementations that are based on different revisions of an XML Schema. The other is compilation compatibility with XML Schema modules that import definitions from the revised XML Schema module. [Editor's Note: the following questions need to be answered: What sorts of changes in type are permissible? What sorts of changes to the minOccurs, maxOccurs are acceptable? What about minLength maxLength?] 2.5.1 Enumerations The semantics and mappings of an enumeration cannot change, but values can be added in unused ranges during an update. Recommend to list all unused values as "Reserved" to avoid breakage. 2.5.2 Simple and Complex Types The removal of features from a simple or complex type would result in the deletion of properties or methods in those elements that use them Chisholm & Adwankar (Editor)Expires - March 2005 [Page 8] Framework for Netconf Data Models October 2004 so should be done with restraint. Inserted elements MUST NOT change keys or add required properties. 2.5.3 Lengths It is not permitted to decrease MaxLen, MaxValue or to increase MinLen or MinValue 3. Considerations for Extensibility 3.1 Data Types XML Schema has 44 built in data types [XML-SCHEMA-2]. Potentially reusable data types should be declared as complex type, rather than element. It has been suggested that SMIv2 really had too many derived data types. People couldn't really tell them apart and getting the most correct data type was occasionally a non-value add portion of the MIB review process. Care should be taken not to define too many data types. [Editor's note: how can this be turned into a guideline?] 3.2 Elements and Attributes The choice of elements and attributes has been widely discussed, but no absolute guidelines exist. When designing encoding rules for NETCONF content, the following guidelines should be used: 3.2.1 Consider Attributes as Metadata Attributes should contain metadata about the element, not true data. By extension, vital information should not be encoded in attributes. [Editor's Note: which bits of meta data are we actually interested in?] 3.2.2 Consider the Lack of Extensibility of Attributes Attributes are unordered, can appear only once, and can have no children. Data scenarios which must leave room for future expansion Chisholm & Adwankar (Editor)Expires - March 2005 [Page 9] Framework for Netconf Data Models October 2004 (in future specifications or future software releases) should avoid attributes. [Editor's note: this may need to be explained a bit better.] 3.3 Other Extensibility Considerations All data which is intended to allow extension in derived schemas should be defined as (simple or complex) types, not elements. Any data required in an element form should be a reference to a simpleType or complexType declaration. 4. Considerations for Parse-ability Netconf content can affect the efficiency and robustness of parsing routines in two ways. The first has to whether any content within the Netconf content could be confused with any aspect of the operations, RPC or application protocol layer. If this is possible, then more careful routines need to be written. In particular, it might be difficult to separate out an implementation into separate methods to parse these different layers if it is necessary to parse the Netconf content and match open and close brackets rather than just looking for an appropriate close tag. Another aspect where the Content will affect performance of the parsing routines is on the assumptions that the parsing routine can make. The following section outlines some restrictions on the Netconf content that will positively impact the performance of parsing routines with minimum impact on the usability of the solution. 4.1 Well-formed XML All XML used within a Netconf solution needs to be well formed [XML] and conform to an XML Schema specification that conforms to the guidelines in this document. 4.2 No DTDs Document type declarations (DTDs) are not permitted to appear in NETCONF content 4.3 Avoid Mixed Content Mixed content is defined as elements that can contain both data and other elements. Elements in NETCONF can contain either data or additional elements only. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 10] Framework for Netconf Data Models October 2004 This greatly simplifies the complexity of parsing XML, especially in the area of significant whitespace. Whitespace inside data elements is significant. Whitespace outside data elements is not. data data datadatamaybe some 4.4 Use an Explicit Namespace on Attributes All attributes should be prefixed so that they belong to a specific namespace. This encourages meaningful definitions that are free of collisions. 4.5 Use Container Elements for Lists A distinct container should be used when encoding lists with multiple instances, use a distinct container element, preferably the plural form of the instance element. In this example, the element 'grommet' is contained within the 'grommets' element. .... .... .... Use of container elements allows simpler manipulation of lists and list members. [Editor's Note: Would we want this one to be normative or informative? Are there benefits to never allowing this to be done another way? Would we ever want to?] Chisholm & Adwankar (Editor)Expires - March 2005 [Page 11] Framework for Netconf Data Models October 2004 5. Considerations for Usability 5.1 Naming All NetMod base elements SHOULD be defined in the namespace urn:ietf:params:xml:ns:netmod:base:1.0 All NetMod defined datatypes SHOULD be defined in the namespace urn:ietf:params:xml:ns:netmod:datatypes:1.0 The name of an elment SHOULD be unique in a given namespace and should be addressed in a reference to a given namespace. The network model SHOULD have separate namespaces for protocol states, management information, enterprises and experimental managed objects as shown below. Netmod(urn:ietf:params:xml:ns:netmod:base:1.0) | | |----Management(urn:ietf:params:xml:ns:netmod:Management:1.0) | | | | ------ system | | (urn:ietf:params:xml:ns:netmod:Management:system:1.0) | | | | | | ------ interfaces | | (urn:ietf:params:xml:ns:netmod:Management:interfaces:1.0) | | | | | | ------ security | | (urn:ietf:params:xml:ns:netmod:Management:security:1.0) | | | | | | ------ performance | (urn:ietf:params:xml:ns:netmod:Management:performance:1.0) | | | |---- experimental(urn:ietf:params:xml:ns:netmod:experimental:1.0) | XPath [XPATH] can be used to locate managed objects in a given namespace. XPATH based addressing can also be used to select a set of managed objects based on a set of criteria's, select content that is Chisholm & Adwankar (Editor)Expires - March 2005 [Page 12] Framework for Netconf Data Models October 2004 combination of different managed object values and to create simple expressions of managed objects. Examples of XPATH based addressing are shown below: 1. Provide all book titles in a catalogue. //bk:book/bk:bookTitle/@bk:value 2. Provide ACL information of the catalogue. /bk:Cataloge/ACL 3. Determine book title for a book whose ISBN number is 0596002923 //bk:book[bk:ISBN/@bk:value="0596002923"]/bk:bookTitle/@bk:value 4. List all book names where the average review rating is greater than 4. //bk:book[bk:AverageReview/@bk:value>4]/bk:bookTitle/@bk:value //if:ifEntry[if:ifMtu/@if:value>'500'] 5. Select all books that have "NetMod" in their description and average review rating is greater than 4. //bk:book[(contains(bk:bookTitle/@bk:value,'NetMod')) and (bk:AverageReview/@bk:value>'4')] 6. Find number of books whose publication year is greater than 2003. count(//bk:book[bk:PublicationYear/@bk:value>'2003']) [Editor's Note: The implications of putting the rules for constructing the object identifiers within both the protocol and the data model have been discussed. It will be important to look ahead when designing the schema. We need to ensure we don't put any dependencies on data types within the naming hierarchy, for example.] 5.1.1 Proper Tag Names When choosing element names, consider the following guidelines: o Prefer ASCII (7-bit). o Prefer lowercase. o Prefer dashes to underscores. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 13] Framework for Netconf Data Models October 2004 o Prefer full words. Note that "config" is considered a full word. o Should be consistent with existing vocabularies [Editor's Note: Does the above need to be more strongly worded?] These are guidelines only and should be considered secondary to the need for consistency with existing vocabularies. For example, when encoding MIB variables names in NETCONF, use the existing names (ifAddr) instead of shifting to these guidelines (if-address). These guidelines are valuable when no common vocabulary exists, because they help to avoid the scenario in which a dozen developers choose a dozen names that differ in ways that lead to frustrating inconsistencies, such as ifaddr, if-addr, if-address, interface- address, intf-addr, iaddr, and iface-addr. 5.2 Considerations for Usability 5.3 Error Handling It was agreed that error codes should be structured to consist of both a generic protocol level error code and data model specific error codes. If implementations don't understand the data model specific error codes, they still have the generic one to go by, but the data model specific error codes can provide information about the specific problem that has happened. 5.3.1 Design Considerations 1. Granularity of specifying error messages - is it on a per schema, per element, multiple per element basis? 2. What mechanism should be used? Annotation, reserved named element tags, attributes? 3. How closely tied are these to the known set of operations that can be performed on the data? How is this determined? 5.4 Schema Documentation. The 'documentation' tag must be used to provide all addition information to implementers and users of a schema that can not be modeled within the schema itself. This includes further restrictions and additional complexities as well as any information that will be helpful in understanding the element. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 14] Framework for Netconf Data Models October 2004 Note that other means of documenting, including the construct are not as easily associated within specific elements and not necessarily understood by all tools. 6. Considerations for Predictable Modeling 6.1 Managed Object Representation The managed objects are represented in a hierarchical tree structure that organizes all available management objects in the managed entity. Each managed object is represented by a node or collection of nodes. Each Node is extension of type NodeType that allows definition of following properties. ACL: The access control information pertaining to the instance of element LastUpdated: The time/date when the last update of this instance took place The XML Schema representation of the NodeType is given below. An example of a node that describes a system description is shown below. The node extends NodeType and provides definition of maxAccess, status and gives description of this node. Book Information. Chisholm & Adwankar (Editor)Expires - March 2005 [Page 15] Framework for Netconf Data Models October 2004 An example of an instance of a book node is 6.2 Containers versus the Data There are potential benefits of this distinction for parsing algorithms as well implications for access control. This can be done using an attribute 'container', which can take a value of 'true' or 'false'. When not present, its value is assumed to be 'false'. [Editor's Note: This section needs to better answer the following questions: Do we need to distinguish between containers and data? How do we distinguish between containers and data? How do we expect containers to be treated or to behave differently?] 6.3 Defining Relationships Relationships between elements can be defined using XML containment, for example: 2 Chisholm & Adwankar (Editor)Expires - March 2005 [Page 16] Framework for Netconf Data Models October 2004 But if we wish to represent information about the individual books, it might be better to define that separately and then associate it the particular shelf. This section will describe the preferred method of defining this type of relationship. What, if any, implications these relationships has on creation, deletion and modifications needs to be well understood. 6.3.1 Element Relationships An appInfo element can be used to define what relationships this element has with other elements that are not implicit within its element hierarchy. 6.3.2 Instance Relationships 6.4 Specifying Statistics, Status and Configuration Information There may be potential value in being able to easily distinguish between configuration, status and statistical information within a data model. For example: 2 3 active numberOfBooks is a statistic, maximumNumberofBooks is a configurable option and usageStatus is status information. Alternatively, this information could have been defined using a specific design pattern that would have provided better understanding of nature of each piece of information without requiring specific knowledge of the context. For example Chisholm & Adwankar (Editor)Expires - March 2005 [Page 17] Framework for Netconf Data Models October 2004 3 active 2 7. Other Topics The items within this section may not necessarily belong within this specification, so may get moved elsewhere at a later date. It should be possible to discover a box and find out both is major software release numbers as well as the list of data models and their versions that are supported. 7.1 Schema Identity Information A schema must contain schema Identity element as part of the appinfo. The Identity provides schema information such as last update of this schema, organization, contact, description and revision history. The contact and revision information can occur multiple times in a schema identity. An example of identity element is as given below NetConf State Schema 2001-12-17T09:30:47-05:00 Example.com ExampleName ExampleAddress http://www.example.com 0000000 Any other Info The Description of NetConf State Schema Chisholm & Adwankar (Editor)Expires - March 2005 [Page 18] Framework for Netconf Data Models October 2004 2004-12-17T09:30:47-05:00 The first version of the schema The XML Schema data types corresponding to Schema Identity information are as below Chisholm & Adwankar (Editor)Expires - March 2005 [Page 19] Framework for Netconf Data Models October 2004 8. Relationship to Netconf Protocol The Netconf architecture supports a clear separation between content and protocol. This is an important architectural separation that should be maintained. That having been said, there are major advantages to ensuring that the content of Netconf is well behaved and predictable. Whether a Netconf implementation can be said to be compliant without also being compliant to the guidelines within this memo is an area of further study. The following examples illustrate the netconf protocol commands being executed against netmod compliant Schemas. 1. Merge Operation 2. Replace Operation Chisholm & Adwankar (Editor)Expires - March 2005 [Page 20] Framework for Netconf Data Models October 2004 3. Delete Operation //bk:book[bk:ISBN/@bk:value="0596002923"] 4. Create Operation Chisholm & Adwankar (Editor)Expires - March 2005 [Page 21] Framework for Netconf Data Models October 2004 5. Get Operation /bk:Catalog/bk:book[bk:ISBN/@bk:value="0596002921"] Chisholm & Adwankar (Editor)Expires - March 2005 [Page 22] Framework for Netconf Data Models October 2004 9. Security Considerations To be determined once specific aspects of this solution are better understood. In particular, the access control framework and the choice of transport will have a major impact on the security of the solution. 10. Acknowledgements This document is a result of discussions at IETF 59 and 60, as well as on the mailing list by the following people: Sharon Chisholm, David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Dan Romascanu, Andy Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria, Juergen Schoenwaelder and Andre Westerinen. 11. Authors' Address Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada Email: schishol@nortelnetworks.com Sandeep Adwankar Motorola 1301 East Algonquin Rd, MS IL02-2240, Schaumburg, IL 60196 USA EMail: sandeep.adwankar@motorola.com 12. References 12.1 Normative [NETCONF-PROTO] Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-03 (work in progress), June 2004. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", Chisholm & Adwankar (Editor)Expires - March 2005 [Page 23] Framework for Netconf Data Models October 2004 W3C REC REC-xml-20001006, October 2000. [XML-Schema-2] Biron, P., Malhotra A., "XML Schema Part 2: DataTypes", W3C REC REC-XMLSCHEMA-2-20010502, May 2001 [XPATH] "XML Path Language (XPath) Version 1.0", J. Clark and S. DeRose. W3C Recommendation, November 1999. [URN] Mealling, M., Masinter, L., Hardie, T. and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. 12.2 Informative References 13. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 i Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. ii Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Chisholm & Adwankar (Editor)Expires - March 2005 [Page 24]