Network Working Group Julije Ozegovic Internet-Draft University of Split Expires: January 1, 2004 July 1, 2003. ROHC Formal Notation Requirements draft-ozegovic-rohc-fn-requirements-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Internet-Draft will expire on August 28, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Ozegovic Expires January 1, 2004 [Page 1] Internet-Draft ROHC Formal Notation Requirements July 2003 Abstract This draft describes requirements expected to be achieved with profile formal notation system for ROHC. The RObust Header Compression (ROHC) [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. The role of formal notation is to provide a simple method for ROHC profile specification. It is to be used in the phase of profile refinement to achieve maximal compression ratio possible, as well as in the phase of software implementation to provide unambiguous profile specification. Note This is a preliminary specification. It is documented in this draft for two main reasons. 1. To encourage discussion regarding the formal notation requirements 2. To contribute to formal notation development effort. Ozegovic Expires January 1, 2004 [Page 2] Internet-Draft ROHC Formal Notation Requirements July 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope of ROHC formal notation. . . . . . . . . . . . . . 6 3.1. Human requirements . . . . . . . . . . . . . . . . . . . 7 3.2. Machine requirements . . . . . . . . . . . . . . . . . . 7 3.3. Profile Interpretation . . . . . . . . . . . . . . . . . 7 4. Formal notation requirements . . . . . . . . . . . . . . 8 4.1 Packet classification parameters . . . . . . . . . . . . 8 4.1.1. Profile selection. . . . . . . . . . . . . . . . . . . . 8 4.1.2. Context selection. . . . . . . . . . . . . . . . . . . . 9 4.2. Profile specification. . . . . . . . . . . . . . . . . . 9 4.2.1. Profile specification degrees of freedom . . . . . . . . 10 4.2.1.1. No degrees of freedom. . . . . . . . . . . . . . . . . . 10 4.2.1.2. Half degree of freedom on input. . . . . . . . . . . . . 10 4.2.1.3. One degree of freedom on input with read on demand . . . 10 4.2.1.4. One degree of freedom on input with advance read . . . . 11 4.2.1.5. One degree of freedom on output. . . . . . . . . . . . . 11 4.2.1.6. Some freedom on input and one degree of freedom on output11 4.2.2. Notation with field processing postponement. . . . . . . 11 4.2.2.1. Field postponement and simultaneous specification. . . . 12 4.2.2.2. Field postponement and separate specification. . . . . . 12 4.2.3. Notation with random access fields and read on demand. . 13 4.3. Compressed header structure. . . . . . . . . . . . . . . 14 4.3.1. Order of compressed fields . . . . . . . . . . . . . . . 14 4.3.2. Order of indicator bits. . . . . . . . . . . . . . . . . 14 4.3.3. Profile preprocessing. . . . . . . . . . . . . . . . . . 15 4.4. Context manipulation . . . . . . . . . . . . . . . . . . 16 5. Notation extensions. . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . 18 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . 18 10. Full Copyright Statement . . . . . . . . . . . . . . . . 19 Ozegovic Expires January 1, 2004 [Page 3] Internet-Draft ROHC Formal Notation Requirements July 2003 1. Introduction The ROHC working group effort to provide robust header compression framework resulted in several documents. Within these, the state machine and profile are specified using "RFC box notation", actually a simple graphical representation with additional English explanation where needed. The profile refinement and specification clarity were achieved by implementing changes in English text. Alternative solution for profile specification was introduced in Efficient Protocol Independent Compression (EPIC-Lite) [2] on the basis of Bachus-Naur form (BNF) [3]. The proposed BNF formal language induced lot of discussion because of its stack oriented functionality. In a two stack model, particular field processing is postponed by pushing its value to the "control stack". The authors of EPIC introduced "A Formal Notation for Header Compression" [4] where explicit stack manipulations are avoided with the "LABEL" concept. Instead of using second stack, postponed field value is stored in a variable defined by LABEL method. This way, particular field processing can be postponed to the more appropriate time. Simultaneously, alternative "Generic Header Compression Notation for ROHC" [5] was proposed with its hierarchical header extension of EPIC concept. Uncompressed header structure definition is separated from actual compression. Based on ROHC WG discussions improved version of [4], the "Protocol Enabled BNF-Based Language (PEBBLE)" [6] is published to be the official ROHC starting point for formal notation development. This work resulted in "Formal Notation for Robust Header Compression (ROHC-FN)" [7], which served the role of template text for San Francisco IETF-56 formal notation discussions. IETF-56 was the place where a necessity for "Formal notation requirements" was recognized [8]. Ozegovic Expires January 1, 2004 [Page 4] Internet-Draft ROHC Formal Notation Requirements July 2003 2. Terminology 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. Profile A ROHC [1] profile is a description of how to compress a certain protocol stack over a certain type of link. Each profile includes one or more sets of header formats and a state machine to control the compressor and the decompressor. Header format A header format describes how to compress each field in the chosen protocol stack. When more than one format is available, particular fields can be compressed using a choice among several encoding methods. Uncompressed header structure An uncompressed header structure describes the position and length of each field of the header. The position can be defined relative to the beginning of header, to the beginning of option or to the end of previous field. Compressed header structure A compressed header structure describes how to compose the compressed header. It consists of two parts: a bit pattern of indicator flags to indicate to the decompressor which format is being used, and a list of compressed versions of each field. Indicator flags A bit pattern to indicate which format is being used to build a compressed packet. Indicator flags can be scattered inside the list of compressed fields or concentrated (and possibly encoded) at the beginning of the list. The combination of the two can be used. For better efficiency, indicator flags can be encoded in groups called header format sets. Ozegovic Expires January 1, 2004 [Page 5] Internet-Draft ROHC Formal Notation Requirements July 2003 Context The context is memory which stores one or more previous values of fields in the uncompressed header. The compressor and decompressor both maintain a copy of the context, and fields can be compressed relative to their stored values for better compression efficiency. Encoding method An encoding method is a procedure for compressing fields. Control method An control method is a procedure for controlling the compression of particular header. Library of encoding and control methods The library of encoding and control methods contains a number of commonly used procedures that can be called to compress fields in the chosen protocol stack. Formal notation extensibility To provide completeness for future protocols coverage, new encoding and control methods can be added to the library if they are needed. 3. Scope of ROHC formal notation The ROHC formal notation is developed to ease completion of the following tasks and goals: 1. Profile writing 2. Profile refinement 3. Profile human readability 4. Profile compactness 5. Profile machine readability 6. Profile validation 7. Profile clarity 8. Hand written code generation 9. Machine automated code generation 10. Profile interpretation Ozegovic Expires January 1, 2004 [Page 6] Internet-Draft ROHC Formal Notation Requirements July 2003 3.1. Human requirements From the above, human ROHC user can benefit of human readability, clarity and compactness for profile writing and refinement, and for hand written code generation. 3.2. Machine requirements Machine ROHC processing can benefit of machine readability for profile validation, automated code generation and profile interpretation. 3.3. Profile Interpretation Profile interpretation is a method of profile execution which enables the profile to be downloaded to compressor and decompressor. This way, new profiles can be introduced without need to download new compressor and decompressor software. In profile interpretation environment, processing is organized in two phases: 1. Offline processing - profile interpretation to build necessary data structures and parameters 2. Online processing - profile usage for compression and decompression To optimize offline processing, profile can be enhanced with preprocessed parameters. Opposite to the profile interpretation is (hand or machine) profile implementation in code. This way, new profiles can be introduced by installation of new compressor and decompressor software. Ozegovic Expires January 1, 2004 [Page 7] Internet-Draft ROHC Formal Notation Requirements July 2003 4. Formal notation requirements The scope of formal notation can be achieved if formal notation system developed can be used for the following tasks: 1. Specification of packet classification parameters 2. Specification of uncompressed header structure 3. Specification of header format 4. Specification of compressed header structure 5. Specification of context management 6. Specification of notation extensions 4.1 Packet classification parameters Packet classification procedure is performed on uncompressed packet header to achieve two goals: 1. Recognize protocol stack (profile) to which packet belongs 2. Recognize packet flow (context) to which packet belongs Packet classification is currently considered to be implementation specific. This situation is acceptable, unless formal notation system is intended for profile interpretation. In profile interpreting systems, the main achievement is the ability to download a new profile in machine readable form to the compressor and decompressor, instead of installing the new software with new profile hard coded. In such a system, it can be foreseen that new profile can support a totally new, previously unsupported protocol stack. In this case, it is essential that formally specified profile submits enough information to recognize a new type of header structure. The packet classification actually takes place on compressor side. Under ROHC framework, decompressor uniquely classifies compressed packets using Context Identifier (CID). 4.1.1. Profile selection To recognize protocol stack, some information from or for link layer can be used. Different link layer protocols can use different codes. To support multiple link subsystems, protocol ID codes must be specified. The following example is one possible: Ozegovic Expires January 1, 2004 [Page 8] Internet-Draft ROHC Formal Notation Requirements July 2003 MEDIA = Ethernet Protocol_ID = MEDIA = PPP Protocol_ID = To verify protocol stack, some information can be checked inside the uncompressed header, e.g. version and protocol fields to recognize IPv4/TCP stack. For example, failure of VALUE encoding in IR packet can indicate wrong profile selection. Alternatively, profile checking can be defined explicitly: Profile_check = 4.1.2. Context selection After the profile classification, context selection is performed. To recognize packet flow (context), some fields inside the uncompressed header must be checked against the existing contexts for profile selected. If a match is found among the existing contexts, packet is assumed to belong to already established context (and state machine). Otherwise, a new context is created and profile is negotiated with decompressor. Context selection parameters specify packet flow recognition granularity. Fine granularity can be achieved using e.g.: Context_check = while coarse granularity is possible using e.g.: Context_check = Flow selection granularity is a method for context reusability control. 4.2. Profile specification The profile specification consists of three different parts: 1. Uncompressed header structure specification 2. Header format specification 3. Compressed header structure specification Ozegovic Expires January 1, 2004 [Page 9] Internet-Draft ROHC Formal Notation Requirements July 2003 The three are not totally independent and need to be interrelated carefully. The readability and compactness as well as flexibility of profile writing depends on proper notation balance. 4.2.1. Profile specification degrees of freedom The profile writing can be seen as a process with several degrees of freedom. Profile writer can ask for maximal freedom, i.e. to specify uncompressed header structure, header format and compressed header structure independently. However, not all that freedom is needed. Especially, it is not needed to reorder compressed header fields, because it is natural to decompress the header in reverse order than the compression was done. Another problem is the achievement of decompressablility for every compressed packet. The following degrees of freedom are possible: 4.2.1.1. No degrees of freedom System reads, compresses and packs fields as ordered in uncompressed header. This system can not yield optimal compression, because original field ordering for particular protocol stack is not designed for optimal compression. 4.2.1.2. Half degree of freedom on input System reads, compresses and packs fields as ordered in the uncompressed header, but can postpone processing of particular field. This can yield optimal compression. Redundant information is present in profile. Systems like EPIC-Lite, PEBBLE and ROHC_FN belong to this category. 4.2.1.3. One degree of freedom on input with read on demand System reads fields randomly when needed by compressor. This makes it possible to compress and pack fields in optimal order. The actual format is evaluated at the compression time, so there is no additional information exchange between the field reading and compressing processes. Ozegovic Expires January 1, 2004 [Page 10] Internet-Draft ROHC Formal Notation Requirements July 2003 4.2.1.4. One degree of freedom on input with advance read System parses uncompressed headers to fields in advance. This makes it possible to compress and pack fields in optimal order. The actual format is partly evaluated in advance, so complex information exchange between the field reading and compressing processes takes place. 4.2.1.5. One degree of freedom on output System reads and compresses fields as ordered in the uncompressed header, but packs compressed fields in arbitrary order. This system can not yield optimal compression, because original field ordering for particular protocol stack is not designed for optimal compression. It must be noted that freedom on output deals with compressed fields ordering only. The placement of indicator bits can be independent of field ordering. 4.2.1.6. Some freedom on input and one degree of freedom on output This system combines freedom on input and output. However, it is natural to decompress the compressed header in the reverse order than compression was done. Freedom on output is not absolutely needed. From the analysis above, it can be evaluated that systems with half or with full freedom on input and read on demand are the ones acceptable. 4.2.2. Notation with field processing postponement In systems with half degree freedom on input, fields are read as ordered in uncompressed header and then postponed for later processing (EPIC-Lite, ROHC_FN). System can be used to achieve optimal compression. The good property of postponement system is its simplicity. The uncompressed header structure and header format can be specified simultaneously or separately. Ozegovic Expires January 1, 2004 [Page 11] Internet-Draft ROHC Formal Notation Requirements July 2003 4.2.2.1. Field postponement and simultaneous specification In simultaneous structure and format specification, header fields are not explicitly named, and human readability suffers. To improve readability, profile writers tend to use compression functions and name them by field names. Such functions are declared later in the profile. In complex profiles like IP/TCP, function declarations are far away from the place of usage, and profile is actually human unreadable. Another drawback in simultaneous specification is redundancy of parameters. The length of the same field is declared in all methods related to this field. For example: header = function1 function2 ------------- function1 = method11(length) | method12(length) where "length" is actually declared two times. More elaborate examples can be found in published EPIC-lite [2] profiles. 4.2.2.2. Field postponement and separate specification In separate structure and format specification, header fields are explicitly named with lengths (in bits) declared. Later, field value can be compressed immediately or postponed for later compression. In the following example, some_field1 is read and compressed immediately, and some_field2 is postponed for later compression and possible multiple usage: some_field1 = FIELD(length1) some_field2 = FIELD(length2) ------------- header = some_field1 method11 | method12 POSTPONE some_field2 ------------- some_field2 method21 | method22 This way, most header field compressions will be declared inline. Decompressor can be made intelligent enough to know whether to store uncompressed value to local variable, to use it as a parameter, or to restore it to the uncompressed header field (exactly like in LABEL concept). Ozegovic Expires January 1, 2004 [Page 12] Internet-Draft ROHC Formal Notation Requirements July 2003 However, to increase readability and to make the parser simpler, explicit label usage methods can be introduced: some_field1 = FIELD(length1) some_field2 = FIELD(length2) ------------- header = some_field1 method11 | method12 POSTPONE some_field2 ------------- method(some_field2) ------------- ACTIVATE some_field2 method21 | method22 In this example, POSTPONE method is used to indicate that the field value is to be stored in local variable when compressing, and restored from local variable when decompressing. ACTIVATE method is used to submit the value from local variable to standard parameter path for compression, and to store decompressed value to local variable after decompression. Among the POSTPONE - ACTIVATE pair of methods, field value can be used as an input parameter for any appropriate method at will, and can be changed if needed. The functional parameter passing: method(some_field2) is optimal, because compression and decompression behavior is internal to the method invoked. 4.2.3. Notation with random access fields and read on demand In systems with one degree freedom on input and read on demand, fields lengths and positions are declared and named in advance, but actual contents read takes place at the moment of compression. System can be used to achieve optimal compression. The good property of random access is that advanced field declaration and naming avoids redundancy and improves readability. However, profile must include separate declaration of all fields. Problem can be encountered with optional fields, whose positions can vary. These fields can not be freely accessed, but only within the option to which they belong. Their position is declared not relative to the beginning of the header, but relative to the beginning of the option. Ozegovic Expires January 1, 2004 [Page 13] Internet-Draft ROHC Formal Notation Requirements July 2003 For example: some_field = FIELD(length, offset) ------------- header = some_field method1 | method2 ------------- The "offset" parameter can be declared explicitly, or implicitly as a sum of previously declared fields. This way, most header field compressions will be declared inline, and only complex ones will need function declarations. Actual field contents read is performed when "some_field" is executed, and data together with length parameter are transferred to compression methods. Optional fields can be read inside the option processing structures. Random access fields usage assumes knowledge of uncompressed header length at the decompression time. The issue of variable length options must be considered appropriately. It can be foreseen that profile writer should take care of option length communication to the decompressor, when option length is not available from the format used. 4.3. Compressed header structure Compressed header structure consists of two specifications: 1. Order of compressed fields 2. Order of indicator bits 4.3.1. Order of compressed fields The order of compressed fields is optimal when it is equal to the order of compression. 4.3.2. Order of indicator bits Order of indicator bits depends on model of compressed packet chosen. At the moment, several models are proposed: ROHC3095, Ordinary Huffman, Hierarchical Huffman etc. It is possible that new models emerge in the future. Ozegovic Expires January 1, 2004 [Page 14] Internet-Draft ROHC Formal Notation Requirements July 2003 At IETF-56 it was proposed to define compressed packet structure in profile using syntax like: TCP_IP_PACKET = ROHC3095(TCP_IP_function) This approach makes it possible to use combinations of structures: TCP_IP_PACKET = Ordinary_Huffman(IP_function) Ordinary_Huffman(TCP_function) or TCP_IP_PACKET = ROHC3095(IP_function) Ordinary_Huffman(TCP_function) Finally, generic profiles are possible: PACKET = Ordinary_Huffman(Ipv4_function | Ipv6_function) Ordinary_Huffman(TCP_function | UDP_function | SCTP_function) Ordinary_Huffman(RTP_function | Null) In generic profile, packet classification takes place on layer by layer basis. The point of communication between the header format choice and compressed header packing is a list of field compression choices that accompanies the list of compressed fields. List of choices can be used to encode header format (like in Huffman) or to generate ROHC3095 compressed header. 4.3.3. Profile preprocessing In complex indicator bits coding system, like Huffman is, lot of processing is needed in the offline phase of the interpreting system, or during the code generation of the conventional (hard coded) system. This processing is mainly concerned with mapping between a list of field compression choices and actual indicator bits code words. This mapping is unique for the profile. It is necessary to calculate it only once, after the profile is standardized, and before it is used (interpreted or hard coded). It can be of benefit to submit preprocessed indicator bits encoding mapping in a standard form together with the profile itself. Interpretive systems can be made less complex, and hard coding process can be made easier to software developers. Interoperability between different implementation can easier be achieved. Ozegovic Expires January 1, 2004 [Page 15] Internet-Draft ROHC Formal Notation Requirements July 2003 4.4. Context manipulation The context is memory which stores one or more previous values of fields in the uncompressed header. Besides header fields, context can contain some control data. Context is generally updated with each new packet. Compressor can maintain more than one context to improve robustness. In practice, situation is more complex. The following method behavior is possible: 1. New context is formed as a copy of current one 2. Method updates context value (encoding and some control methods) 3. Method does not manipulate context (some control method) 4. Method skips context update on demand 5. Context update is skipped when field does not exist in uncompressed header Context updating declaration must be part of method definition. This way, context behavior can be formally specified. Context update skipping can be specified when encoding method is invoked for particular field. Context for options actually consists of all optional fields, whether present in current packet or not. For the optional field that does not exist, old option value is kept. It is natural that fields from different options do not share the same context field. However, at least one protocol is known (DCCP) where field that carries common information (ACK) is a part of option (specific header). In two packet types of DCCP, ACK is not present. This field should use the same context value when present. The solution is to declare context value to be "common" to all equally named fields in various options (specific headers). Context update must be skipped when field in question is not present, in a manner that all previously stored values are preserved (i.e. context "rotates", but skipped field does not). Decompressor must keep previous value. Ozegovic Expires January 1, 2004 [Page 16] Internet-Draft ROHC Formal Notation Requirements July 2003 5. Notation extensions Formal notation should be applicable to future protocols, and thus must keep completeness as well as efficacy in profile writing. Three levels of extendibility are foreseen: 1. Profile level (the highest level) 2. Method level (encoding, control and basic) 3. Programming level (the lowest level) Programming extendibility level is the fundamental one. Programming languages are expected to be complete. This level is used to introduce new methods (basic, encoding, or control) from scratch. A method should be provided to declare new encoding method needed through the profile. However, no guarantee is provided that new method will satisfy the requirement for functionality and decompressability. These issues remain responsibility of method writer. Method level extensibility provides a method to build a new encoding method using basic methods. The difference compared to the encoding functions is that new method becomes part of set of encoding methods and is adequately treated with indicator bits. Again, no guarantee is provided for decompressability. Finally, the highest level is profile writing itself. 7. Security Considerations This draft describes a requirements for ROHC formal notation. See [1] for the security issues raised by robust header compression. 8. Acknowledgements The authors would like to acknowledge the many people who have helped with issues relating to ROHC and formal notation. These include Carsten Bormann, Max Riegel, Christian Schmidt, Richard Price, Abigail Surtees, and Mark West. We also acknowledge members of the FESB EPIC team, who made an effort to provide open source implementation of EPIC-Lite. Ozegovic Expires January 1, 2004 [Page 17] Internet-Draft ROHC Formal Notation Requirements July 2003 9. References [1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and Zheng, H., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] Price, R., Hancock, R., Ollis, P., Surtees, A. and West, M., "Framework for EPIC-lite", draft-ietf-rohc-epic-lite-01.txt (work in progress), February 2002. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] R. Price, A. Surtees, M. West "A Formal Notation for Header Compression" draft-west-rohc-formal-notation-00.txt (work in progress), June 2002. [5] Hongbin Liao, Qian Zhang, Wenwu Zhu: "Generic Header Compression Notation for ROHC" (work in progress), June 2002. [6] Richard Price, Abigail Surtees, Mark A West: "Protocol-Enabled BNF-Based LanguagE (PEBBLE)" daft-ietf-rohc-formal-notation-00.txt>, October 2002. [7] Richard Price, Abigail Surtees, Mark A West: "Formal Notation for Robust Header Compression (ROHC-FN)" , March 2003. [8] Carsten Borman et. al.: "The slides from IETF-56 ROHC meeting" http://www.dmn.tzi.org/ietf/rohc/rohc-56.pdf, March 2003. 10. Authors' Addresses Julije Ozegovic University of Split FESB Split R. Boskovica bb 21000 SPLIT Croatia Phone: +385 (0)21 305725 EMail: julije@fesb.hr Ozegovic Expires January 1, 2004 [Page 18] Internet-Draft ROHC Formal Notation Requirements July 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ozegovic Expires January 1, 2004 [Page 19]