Network Working Group J. Schoenwaelder
Internet-Draft TU Braunschweig
Expires: October 10, 2001 April 11, 2001
SNMP Payload Compression
draft-irtf-nmrg-snmp-compression-01.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 October 10, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo defines a mechanism for lossless compression of SNMP
payloads. Compression is especially useful when retrieving large
amounts of data or when SNMP encryption is being used over a
transport which provides data compression.
Schoenwaelder Expires October 10, 2001 [Page 1]
Internet-Draft SNMP Payload Compression April 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Compressed Payload . . . . . . . . . . . . . . 4
3.1 Compression as an SNMPv3 Encryption Algorithm . . . . . . 4
3.2 Indicating Compression in the msgFlags . . . . . . . . . . 4
3.3 Compression as a new PDU Type . . . . . . . . . . . . . . 5
4. Negotiating Compression Algorithms . . . . . . . . . . . . 6
5. Compression Algorithms . . . . . . . . . . . . . . . . . . 6
5.1 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 OID Delta Compression (ODC) . . . . . . . . . . . . . . . 7
5.2.1 ODC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2 ODC Examples . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2.1 Simple Substitutions . . . . . . . . . . . . . . . . . . . 10
5.2.2.2 Range Substitutions . . . . . . . . . . . . . . . . . . . 11
5.2.2.3 Substitutions and Truncations . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . 15
Schoenwaelder Expires October 10, 2001 [Page 2]
Internet-Draft SNMP Payload Compression April 2001
1. Introduction
This memo defines mechanisms for lossless compression of SNMP
payloads. Compression is useful when retrieving large amounts of
management data since the BER encoding used by SNMP is not very space
efficient and the payload tends to have a high degree of redundancy.
SNMP payload compression is especially useful when retrieving large
amounts of data. In particular, compression allows command
responders to put more data into responses to bulk retrieval
requests, which can significantly reduce the overall number of
transactions needed to retrieve a certain amount of data [5].
SNMP payload compression is also useful when SNMP encryption is used.
Encrypting the SNMP payload causes the data to be random in nature,
rendering compression at lower protocol layers (e.g., IP Payload
Compression Protocol [2]) ineffective. If both compression and
encryption are required, then compression should be applied before
encryption.
2. Requirements
A solution for SNMP payload compression has to satisfy the following
requirements:
1. Compression must happen before encryption if compression is used
together with encryption. Compression is most useful if there
are regular patterns in the data. It is the nature of encryption
algorithms to destroy any regular pattern and hence encrypted
data does not compress very well.
2. SNMP payload compression should be able to support multiple
compression algorithms. This implies that SNMP engines must be
able to negotiate the compression algorithm they are using.
Instead of carrying a compression algorithm identifier in every
protocol message, it seems more effective to indicate compression
algorithms in a MIB module (similar to authentication or
encryption algorithms in SNMPv3).
3. Each SNMP message is compressed and decompressed by itself
without any relation to other SNMP messages ("stateless
compression"), as SNMP messages may arrive out of order or not
arrive at all.
4. The size of a compressed SNMP message must never exceed the size
of the uncompressed SNMP message ("non-expansion policy"). A
sender may send an uncompressed SNMP message if an attempt to
compress the message produces a result which is longer than the
Schoenwaelder Expires October 10, 2001 [Page 3]
Internet-Draft SNMP Payload Compression April 2001
uncompressed SNMP message. An SNMP engine configured to receive
compressed SNMP messages must thus also accept uncompressed SNMP
messages.
5. The abstract syntax of compressed SNMP messages must be defined
using ASN.1. This ensures that a compressed SNMP message has a
valid ASN.1/BER encoding which simplifies the integration into
existing SNMP toolkits.
6. It is desirable to define common compression algorithms in order
to achieve interoperability. The compression algorithms should
be openly available and they should represent different trade-
offs between compression efficiency and CPU efficiency.
3. Identifying Compressed Payload
It is necessary to distinguish between compressed and uncompressed
SNMP payload. There are several ways to implement this. The
following sections discuss alternatives that have been considered.
3.1 Compression as an SNMPv3 Encryption Algorithm
The idea behind the first approach is to treat compression as an
additional SNMPv3 encryption algorithm. In fact, compression as well
as encryption can both be treated as a loss-less data transformation.
This approach has the following advantages / disadvantages:
+ No change required to the SNMPv3 specifications.
+ Compression of the complete ScopedPDU.
- Support of N encryption algorithms and M compression algorithms
leads to N*M possible combinations.
- Compression requires authentication since there is no noAuthPriv
security level.
- Does not work with older and widely deployed versions of SNMP
(SNMPv1, SNMPv2c).
3.2 Indicating Compression in the msgFlags
To avoid some of the drawbacks of the previous approach, one can
treat compression independent of encryption by allocating an unused
bit in the msgFlags [3]) to indicate whether compression is used or
not. However, RFC 2572 [3]) says in section 6.4:
Schoenwaelder Expires October 10, 2001 [Page 4]
Internet-Draft SNMP Payload Compression April 2001
The remaining bits in msgFlags are reserved, and must be set to zero
when sending a message and should be ignored when receiving a
message.
Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in
section 7.2 step 5) that other bits in the msgFlags are set to zero
or ignored. This means that this alternative can not be supported by
an implementation which is strictly compliant to RFC 2572 [3].
In summary, this approach has the following advantages /
disadvantages:
+ Combination of M compression and N encryption algorithms possible
without having to define N*M algorithms.
+ Compression can be used with or without encryption or
authentication.
+ Compression of the complete ScopedPDU.
- Not strictly compliant to the current SNMPv3 specifications.
- Does not work with older widely deployed versions of SNMP (SNMPv1,
SNMPv2c).
3.3 Compression as a new PDU Type
The third alternative is to restrict compression to PDUs rather than
ScopedPDUs and to introduce a new PDU type for compressed payloads.
RFC 1157 [4] defines the SNMPv1 message header as follows:
Message ::= SEQUENCE {
version INTEGER { version-1(0) },
community OCTET STRING,
data ANY -- e.g., PDUs if trivial authentication
-- is being used
}
Similarly, RFC 2572 [3] defines the ScopedPDU as follows:
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in RFC 1905
}
This means that a new PDU could be defined which holds the compressed
Schoenwaelder Expires October 10, 2001 [Page 5]
Internet-Draft SNMP Payload Compression April 2001
version of a PDU:
CompressedPDU ::= [42] IMPLICIT OCTET STRING
-- contains a compressed PDU
It is important to analyze how a compliant SNMP implementation
behaves when it receives an unknown PDU type. From a formal point of
view, any PDU which is a valid BER serialization of an ASN.1 type
must be accepted since the data portion is of the ASN.1 type ANY. In
practice, most SNMP implementations will only recognize the PDU types
defined in the SNMP specifications.
The SNMPv3 message processing model [3] defines in section 7.2 step
7) that parse errors while decoding the ScopedPDU cause the packet to
be discarded after incrementing snmpInASNParseErrs. Even an
implementation which is capable to decode arbitrary PDUs will have
problems to determine the pduType as defined in section 7.2 step 9).
This basically means that a compliant SNMPv3 engine will simply
discard compressed PDUs.
The SNMPv1 specification [4] defines in section 4.1 second step (4)
that parse errors while decoding the PDU will cause the SNMP engine
to drop the PDU. Hence, it can be expected that most implementations
will simply drop a compressed PDU.
In summary, this approach has the following advantages /
disadvantages:
+ Combination of M compression and N encryption algorithms possible
without having to define N*M algorithms.
+ Compression can be used with or without encryption or
authentication.
+ Works with every version of SNMP.
- Not strictly compliant to the current SNMPv3 specifications.
- Compression of the PDU rather than the ScopedPDU.
4. Negotiating Compression Algorithms
[TBD]
5. Compression Algorithms
Schoenwaelder Expires October 10, 2001 [Page 6]
Internet-Draft SNMP Payload Compression April 2001
5.1 DEFLATE
The DEFLATE algorithm is a well-know compression algorithm which
achieves good compression ratios and which is used for example in RFC
2394 for IP payload compression. It is also used on the World Wide
Web to compress documents before transmission over HTTP.
Using DEFLATE for SNMP payload compression however shows some
undesirable aspects. First, DEFLATE compression is relatively CPU
intensive. Furthermore, the DEFLATE algorithm requires to transmit a
dictionary, which reduces the compression efficiency for small
messages. On the other hand, DEFLATE compresses both names and
values and may achieve particularly good compression if the encoded
values show a similar structure.
Experiments with DEFLATE show that it should not be used on
relatively short SNMP messages. Furthermore, DEFLATE introduces
significant delays due to the compression computations. Finally,
estimating message sizes is hard with DEFLATE since there is no upper
bound for the message length addition if one adds another varbind.
This has impacts in particular on the getbulk PDU implementation. It
is therefore not recommended to adopt DEFLATE compression.
5.2 OID Delta Compression (ODC)
SNMP payloads use OIDs to represent the names of SNMP variables. The
amount of space used for encoding these OIDs frequently exceeds the
space needed to represent the values identified by the OIDs.
Furthermore, subsequent OIDs usually have many sub-identifier in
common.
The OID Delta Compression (ODC) algorithm has been designed to reduce
the OID overhead inherent in SNMP messages. The general idea is to
encode an OID as a delta to the previous OID. The ODC algorithm only
achieves a reduction in the SNMP naming information. It does not
compress the data of MIB variables, even if the value itself is an
OID. (The reason for not compressing OID values is that they are (a)
relatively infrequent and (b) compressing value OIDs has negative
impact on the compression achieved for the following variable name.)
In many cases (e.g., when retrieving large tables which basically
contain numbers), the achieved compression ratio is significant while
the CPU cycles spent on the compression algorithm itself are very
small.
5.2.1 ODC Algorithm
The ODC algorithm encodes OID deltas using three mechansisms:
Schoenwaelder Expires October 10, 2001 [Page 7]
Internet-Draft SNMP Payload Compression April 2001
1. Substitution of a single sub-identifier values at a certain
position. A sub-identifier substitution is encoded as follows:
0 7 8
+---------------+--------------------------//-+
| s-offset | BER encoded sub-identifier |
+---------------+--------------------------//-+
s-offset Defines the offset of the sub-identifier to
substitute. The offset value is in the range
0-0x7f. The value 0 refers to the first OID
sub-identifier.
2. Substitution of ranges of sub-identifiers at a given starting
position. A substitution of a range of sub-identifiers is
encoded as follows:
0 7 8 15 16
+---------------+---------------+--------------------------//-+
| r-offset | r-length | BER encoded sub-identifiers |
+---------------+---------------+--------------------------//-+
r-offset Defines the offset of the sub-identifier range
to substitute. The offset value has the most
significant bit set and is in the range
0x80-0xff. The value 0x80 refers to the first
OID sub-identifier.
r-length Defines the number of BER encoded sub-identifiers
that follow the r-length field and which will
be substituted. The range of the r-length field
is 0x01-0x7f.
3. Truncation of OIDs (which may shorten or enlarge OIDs). A
truncation, which may only appear at the end, is encoded as
follows:
0 7
+---------------+
| t-length |
+---------------+
t-length Defines the new length of the OID in the range
0x01-0x7f. The t-length value specifies the number
if sub-identifiers minus 1. Hence, the value 0x01
identifies an OID which consists of two
sub-identifiers. Truncation may be used to shorten
or enlarge an OID. New sub-identifiers will have
the value 0 if an OID is enlarged.
Schoenwaelder Expires October 10, 2001 [Page 8]
Internet-Draft SNMP Payload Compression April 2001
An ODC compressed OID is simply the combination of several sub-
identifier or sub-identifier range substitutions followed by an
optional truncation. Note that substitutions can increase the size
of the OID if the offset or range specifies sub-identifier positions
outside of the previous OID. New sub-identifiers without an explicit
value assignement will have the value 0. An ODC compressed OID is
distinguished from a normal OID by introducing the following new
ASN.1 type:
CompOID ::= [42] IMPLICIT OCTET STRING
A high-level description of the compression algorithm is as follows:
1. Loop through the SNMP PDU until you find an OID name value pair
(varbind).
2. If it is the first varbind, make a copy of the OID, pass it to
the output buffer and continue with the next varbind.
3. Otherwise, compute the delta to the last OID and BER encode it
into the CompOID value.
4. If the CompOID representation is larger than the OID, pass the
OID to the output buffer, else pass the CompOID to the output
buffer.
5. Update the last OID and goto step 2 if there are additional
varbinds.
Some SNMP implementations use a reverse encoding scheme where PDUs
are encoded from the end to the beginning. The ODC algorithm can
also be used efficiently in this case by using an OID look-ahead of 1
varbind.
A high-level description of the decompression algorithm is as
follows:
1. Loop through the SNMP PDU until you find an OID name value pair
(varbind).
2. If the varbind name contains an uncompressed OID, pass it to the
output buffer and continue with the next varbind.
3. Otherwise, if the varbind name contains a compressed OID, loop
through the compressed OID value doing the following:
1. If the first byte is in the range 0-0x7f and there are more
bytes, then decode the following byte(s) as a BER encoded
Schoenwaelder Expires October 10, 2001 [Page 9]
Internet-Draft SNMP Payload Compression April 2001
sub-identifier and perform a sub-identifier substitution.
2. If the first byte is in the range 0x80-0xff, then read the
following byte as the r-length value. Decode the following
r-length BER encoded sub-identifier and perform a range
substitution.
3. If the first byte is in the range 0x01-0x7f and there are no
more bytes, then perform a truncation.
4. Pass the decoded OID to the output buffer.
5. Update the last OID and goto step 2 if there are additional
varbinds.
5.2.2 ODC Examples
This section shows some example ODC encodings. It is provided to
better understand how ODC encodings work. It is not intended to give
a formal analysis of the compression ratios that can be achieved on
arbitrary SNMP payload.
5.2.2.1 Simple Substitutions
Lets assume a command generator uses getbulk operations to retrieve
the tcpConnTable of the TCP-MIB. A good manager will do that by
retrieving the tcpConnState column. The command responder will
return a sequence of tcpConnState (1.3.6.1.2.1.6.13.1.1) values:
tcpConnState.0.0.0.0.21.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.22.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.23.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.98.0.0.0.0.0 = listen(2)
The BER encoding of this varbind list is the following sequence of
bytes:
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:15:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:16:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
Schoenwaelder Expires October 10, 2001 [Page 10]
Internet-Draft SNMP Payload Compression April 2001
00:00:00:00:17:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:62:00:00:00:00:00 // instance identifier
02:01:02 // value
Using ODC compression, the following sequence of bytes would be used:
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:15:00:00:00:00:00 // instance identifier
02:01:02 // value
30:07 // sequence
2a:02:0E:16 // substitution
02:02:02 // value
30:07 // sequence
2a:02:0E:17 // substitution
02:01:02 // value
30:07 // sequence
2a:02:0E:62 // substitution
02:01:02 // value
In this particular example, the total size of the encoded varbind
list drops from 104 bytes to 53 bytes.
5.2.2.2 Range Substitutions
This example expands the previous example by showing how range
substitutions work. In this example, we assume that the command
responder will return a sequence of tcpConnState values with
different IP addresses in the instance identifier:
tcpConnState.134.169.34.190.50054.130.240.64.53.80 = closeWait(8)
tcpConnState.134.169.34.190.50366.212.185.76.85.80 = closeWait(8)
tcpConnState.134.169.34.190.53370.134.169.34.117.6000 = established(5)
tcpConnState.134.169.34.190.56398.134.169.34.190.120 = closeWait(8)
The BER encoding of this varbind list is the following sequence of
bytes:
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:87:06: // instance
81:02:81:70:40:35:50 // identifier
02:01:08 // value
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
Schoenwaelder Expires October 10, 2001 [Page 11]
Internet-Draft SNMP Payload Compression April 2001
81:06:81:29:22:81:3E:83:89:3E: // instance
81:54:81:39:4C:55:50 // identifier
02:01:08 // value
30:20 // sequence
06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:A0:7A: // instance
81:06:81:29:22:75:AE:70 // identifier
02:01:05 // value
30:20 // sequence
06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:B8:4E: // instance
81:06:81:29:22:81:3E:78 // identifier
02:01:08 // value
Using ODC compression, the following sequence of bytes would be used:
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:87:06: // instance
81:02:81:70:40:35:50 // identifier
02:01:08 // value
30:10 // sequence
2A:0B:8E:05: // range
83:89:3E:81:54:81:39:4C:55 // substitution
02:01:08 // value
30:12 // sequence
2A:0D:8E:06: // range
83:A0:7A:81:06:81:29:22:75:AE:70 // substitution
02:01:05 // value
30:0E // sequence
2A:09:0E:83:A0:7A // substitution
92:02:81:3E:78 // range substitution
02:01:08 // value
In this particular example, the total size of the encoded varbind
list drops from 134 bytes to 87 bytes.
5.2.2.3 Substitutions and Truncations
This example assumes that a command generator retrieves the
ipNetToMediaTable defined in the IP-MIB using a getbulk on
ipNetToMediaPhysAddress (1.3.6.1.2.1.4.22.1.2) and ipNetToMediaType
(1.3.6.1.2.1.4.22.1.4) pairs. The following values might be returned
for a system which only has one entry in the cache:
ipNetToMediaPhysAddress.2.224.8.8.0 = 01:00:5E:08:08:00
ipNetToMediaType.2.224.8.8.0 = dynamic(3)
ipNetToMediaNetAddress.2.224.8.8.0 = 224.8.8.0
Schoenwaelder Expires October 10, 2001 [Page 12]
Internet-Draft SNMP Payload Compression April 2001
ipRoutingDiscards.0 = 0
Note that the getbulk overshoots and retrieves the following
instances in lexicographic order, which is an ipNetToMediaNetAddress
(1.3.6.1.2.1.4.22.1.3) and an ipRoutingDiscards (1.3.6.1.2.1.4.23)
instance.
The BER encoding of this varbind list is the following sequence of
bytes:
30:19 // sequence
06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress
02:81:60:08:08:00 // instance identifier
04:06:01:00:5E:08:08:00 // value
30:14 // sequence
06:0F:2B:06:01:02:01:04:16:01:04: // ipNetToMediaType
02:81:60:08:08:00 // instance identifier
02:01:03 // value
30:17 // sequence
06:10:2B:06:01:02:01:04:16:01:03: // ipNetToMediaNetAddress
02:81:60:08:08:00 // instance identifier
40:04:E0:08:08:00 // value
30:0D // sequence
06:08:2B:06:01:02:01:04:17 // ipRoutingDiscards
00 // instance identifier
41:01:00 // value
Using ODC compression, the following sequence of bytes would be used:
30:19 // sequence
06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress
02:81:60:08:08:00 // instance identifier
04:06:01:00:5E:08:08:00 // value
30:07 // sequence
2A:02:09:04 // substitution
02:01:03 // value
30:0A // sequence
2A:02:09:04 // substitutions
40:04:E0:08:08:00 // value
30:0A // sequence
2A:05:87:02:23:00: // range substitution
08 // truncation
41:01:00 // value
In this particular example, the total size of the encoded varbind
list drops from 89 bytes to 60 bytes.
Schoenwaelder Expires October 10, 2001 [Page 13]
Internet-Draft SNMP Payload Compression April 2001
6. Acknowledgments
This document is the result of discussions within the Network
Management Research Group (NMRG). of the Internet Research Task
Force[6] (IRTF). Special thanks go to Luca Deri, Wes Hardacker,
Jean-Philippe Martin-Flatin, Joe Marzot, Aiko Pras, Ron Sprenkels,
Frank Strauss, and Bert Wijnen for their comments and suggestions.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.
[3] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[5] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB
Data", Simple Times 7(1), March 1999.
[6] <http://www.irtf.org/>
Author's Address
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
Schoenwaelder Expires October 10, 2001 [Page 14]
Internet-Draft SNMP Payload Compression April 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Schoenwaelder Expires October 10, 2001 [Page 15]