containing a Response Class or Internal Class PDU be prepared for
sending.
a) It makes such a request according to the abstract service
primitive:
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- same as on incoming request
IN securityName -- same as on incoming request
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size sender can accept
IN stateReference -- reference to state
-- information presented with
-- the request
IN statusInformation -- success or errorIndication
-- error counter OID and value
-- when errorIndication
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- the length of the message
)
b) The cached information for the original request is retrieved
via the stateReference, including
- msgID,
- contextEngineID,
- contextName,
- securityModel,
- securityName,
- securityLevel,
- securityStateReference,
- reportableFlag,
- transportDomain, and
- transportAddress.
The SNMPv3 Message Processing Model does not allow cached data
to be overridden, except by error indications as detailed in
(3) below.
3) If statusInformation contains values for an OID/value combination
(potentially also containing a securityLevel value,
contextEngineID value, or contextName value), then
a) If reportableFlag is zero, then the original message is
discarded, and no further processing is done. A result of
FAILURE is returned. SNMPv3 Message Processing is complete.
b) If a PDU is provided, it is the PDU from the original request.
If possible, extract the request-id.
c) A Report PDU is prepared:
1) the varBindList is set to contain the OID and value from the
statusInformation
2) error-status is set to 0
3) error-index is set to 0.
4) request-id is set to the value extracted in step b)
Otherwise, request-id is set to 0
d) The errorIndication in statusInformation may be accompanied by
a securityLevel value, a contextEngineID value, or a
contextName value.
1) If statusInformation contains a value for securityLevel,
then securityLevel is set to that value, otherwise it is set
to noAuthNoPriv.
2) If statusInformation contains a value for contextEngineID,
then contextEngineID is set to that value, otherwise it is
set to the value of this entity's snmpEngineID.
3) If statusInformation contains a value for contextName, then
contextName is set to that value, otherwise it is set to the
default context of "" (zero-length string).
e) PDU is set to refer to the new Report-PDU. The old PDU is
discarded.
f) Processing continues with step 6) below.
4) If contextEngineID is not yet determined, then the contextEngineID
is determined, in an implementation-dependent manner, possibly
using the transportDomain and transportAddress.
5) If the contextName is not yet determined, the contextName is set
to the default context.
6) A scopedPDU is prepared from the contextEngineID, contextName, and
PDU.
7) msgGlobalData is constructed as follows
a) The msgVersion field is set to snmpv3(3).
b) msgID is set as determined in step 1 or 2 above.
c) msgMaxSize is set to an implementation-dependent value.
d) msgFlags are set as follows:
- If securityLevel specifies noAuthNoPriv, then authFlag and
privFlag are both set to zero.
- If securityLevel specifies authNoPriv, then authFlag is set
to one and privFlag is set to zero.
- If securityLevel specifies authPriv, then authFlag is set to
one and privFlag is set to one.
- If the PDU is from the Unconfirmed Class, then the
reportableFlag is set to zero.
- If the PDU is from the Confirmed Class then the
reportableFlag is set to one.
- All other msgFlags bits are set to zero.
e) msgSecurityModel is set to the value of securityModel
8) If the PDU is from the Response Class or the Internal Class, then
a) The specified Security Model is called to generate the message
according to the primitive:
statusInformation =
generateResponseMsg(
IN messageProcessingModel -- SNMPv3 Message Processing
-- Model
IN globalData -- msgGlobalData from step 7
IN maxMessageSize -- from msgMaxSize (step 7c)
IN securityModel -- as determined in step 7e
IN securityEngineID -- the value of snmpEngineID
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- as prepared in step 6)
IN securityStateReference -- as determined in step 2
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)
If, upon return from the Security Model, the statusInformation
includes an errorIndication, then any cached information about
the outstanding request message is discarded, and an
errorIndication is returned, so it can be returned to the
calling application. SNMPv3 Message Processing is complete.
b) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
9) If the PDU is from the Confirmed Class or the Notification Class,
then
a) If the PDU is from the Unconfirmed Class, then securityEngineID
is set to the value of this entity's snmpEngineID.
Otherwise, the snmpEngineID of the target entity is determined,
in an implementation-dependent manner, possibly using
transportDomain and transportAddress. The value of
securityEngineID is set to the value of the target entity's
snmpEngineID.
b) The specified Security Model is called to generate the message
according to the primitive:
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- SNMPv3 Message Processing Model
IN globalData -- msgGlobalData, from step 7
IN maxMessageSize -- from msgMaxSize in step 7 c)
IN securityModel -- as provided by caller
IN securityEngineID -- authoritative SNMP entity
-- from step 9 a)
IN securityName -- as provided by caller
IN securityLevel -- as provided by caller
IN scopedPDU -- as prepared in step 6
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
If, upon return from the Security Model, the statusInformation
includes an errorIndication, then the message is discarded, and
the errorIndication is returned, so it can be returned to the
calling application, and no further processing is done.
SNMPv3 Message Processing is complete.
c) If the PDU is from the Confirmed Class, information about the
outgoing message is cached, and a (implementation-specific)
stateReference is created. Information to be cached includes
the values of:
- sendPduHandle
- msgID
- snmpEngineID
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
d) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
7.2. Prepare Data Elements from an Incoming SNMP Message
This section describes the procedure followed to extract data from an
SNMPv3 message, and to prepare the data elements required for further
processing of the message by the Message Dispatcher.
1) The message is passed in from the Message Dispatcher according to
the abstract service primitive:
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID and value
-- when errorIndication
OUT stateReference -- reference to state information
-- to be used for a possible
) -- Response
2) If the received message is not the serialization (according to
the conventions of [RFC1906]) of an SNMPv3Message value, then the
snmpInASNParseErrs counter [RFC1907] is incremented, the message
is discarded without further processing, and a FAILURE result is
returned. SNMPv3 Message Processing is complete.
3) The values for msgVersion, msgID, msgMaxSize, msgFlags,
msgSecurityModel, msgSecurityParameters, and msgData are
extracted from the message.
4) If the value of the msgSecurityModel component does not match a
supported securityModel, then the snmpUnknownSecurityModels
counter is incremented, the message is discarded without further
processing, and a FAILURE result is returned. SNMPv3 Message
Processing is complete.
5) The securityLevel is determined from the authFlag and the
privFlag bits of the msgFlags component as follows:
a) If the authFlag is not set and the privFlag is not set, then
securityLevel is set to noAuthNoPriv.
b) If the authFlag is set and the privFlag is not set, then
securityLevel is set to authNoPriv.
c) If the authFlag is set and the privFlag is set, then
securityLevel is set to authPriv.
d) If the authFlag is not set and privFlag is set, then the
snmpInvalidMsgs counter is incremented, the message is
discarded without further processing, and a FAILURE result is
returned. SNMPv3 Message Processing is complete.
e) Any other bits in the msgFlags are ignored.
6) The security module implementing the Security Model as specified
by the securityModel component is called for authentication and
privacy services. This is done according to the abstract service
primitive:
statusInformation = -- errorIndication or success
-- error counter OID and
-- value if error
processIncomingMsg(
IN messageProcessingModel -- SNMPv3 Message Processing Model
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT securityStateReference -- reference to security state
) -- information, needed for
-- response
If an errorIndication is returned by the security module, then
a) If statusInformation contains values for an OID/value pair,
then generation of a Report PDU is attempted (see step 3 in
section 7.1).
1) If the scopedPDU has been returned from processIncomingMsg
then determine contextEngineID, contextName, and PDU.
2) Information about the message is cached and a
stateReference is created (implementation-specific).
Information to be cached includes the values of:
msgVersion,
msgID,
securityLevel,
msgFlags,
msgMaxSize,
securityModel,
maxSizeResponseScopedPDU,
securityStateReference
3) Request that a Report-PDU be prepared and sent, according
to the abstract service primitive:
result = -- SUCCESS or FAILURE
returnResponsePdu(
IN messageProcessingModel -- SNMPv3(3)
IN securityModel -- same as on incoming request
IN securityName -- from processIncomingMsg
IN securityLevel -- same as on incoming request
IN contextEngineID -- from step 6 a) 1)
IN contextName -- from step 6 a) 1)
IN pduVersion -- SNMPv2-PDU
IN PDU -- from step 6 a) 1)
IN maxSizeResponseScopedPDU -- from processIncomingMsg
IN stateReference -- from step 6 a) 2)
IN statusInformation -- from processIncomingMsg
)
b) The incoming message is discarded without further processing,
and a FAILURE result is returned. SNMPv3 Message Processing is
complete.
7) The scopedPDU is parsed to extract the contextEngineID, the
contextName and the PDU. If any parse error occurs, then the
snmpInASNParseErrs counter [RFC1907] is incremented, the security
state information is discarded, the message is discarded without
further processing, and a FAILURE result is returned. SNMPv3
Message Processing is complete. Treating an unknown PDU type is
treated as a parse error is an implementation option.
8) The pduVersion is determined in an implementation-dependent
manner. For SNMPv3, the pduVersion would be an SNMPv2-PDU.
9) The pduType is determined, in an implementation-dependent manner.
For RFC1905, the pduTypes include:
- GetRequest-PDU,
- GetNextRequest-PDU,
- GetBulkRequest-PDU,
- SetRequest-PDU,
- InformRequest-PDU,
- SNMPv2-Trap-PDU,
- Response-PDU,
- Report-PDU.
10) If the pduType is from the Response Class or the Internal Class,
then
a) The value of the msgID component is used to find the cached
information for a corresponding outstanding Request message.
If no such outstanding Request message is found, then the
security state information is discarded, the message is
discarded without further processing, and a FAILURE result is
returned. SNMPv3 Message Processing is complete.
b) sendPduHandle is retrieved from the cached information.
Otherwise, sendPduHandle is set to <none>, an implementation
defined value.
11) If the pduType is from the Internal Class, then
a) statusInformation is created using the contents of the
Report-PDU, in an implementation-dependent manner. This
statusInformation will be forwarded to the application
associated with the sendPduHandle.
b) The cached data for the outstanding message, referred to by
stateReference, is retrieved. If the securityModel or
securityLevel values differ from the cached ones, it is
important to recognize that Internal Class PDUs delivered at
the security level of noAuthNoPriv open a window of
opportunity for spoofing or replay attacks. If the receiver
of such messages is aware of these risks, the use of such
unauthenticated messages is acceptable and may provide a
useful function for discovering engine IDs or for detecting
misconfiguration at remote nodes.
When the securityModel or securityLevel values differ from
the cached ones, an implementation may retain the cached
information about the outstanding Request message, in
anticipation of the possibility that the Internal Class PDU
received might be illegitimate. Otherwise, any cached
information about the outstanding Request message message is
discarded.
c) The security state information for this incoming message is
discarded.
d) stateReference is set to <none>
e) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
12) If the pduType is from the Response Class, then
a) The cached data for the outstanding request, referred to by
stateReference, is retrieved, including
- snmpEngineID
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
b) If the values extracted from the incoming message differ from
the cached data, then any cached information about the
outstanding Request message is discarded, the incoming
message is discarded without further processing, and a
FAILURE result is returned. SNMPv3 Message Processing is
complete.
When the securityModel or securityLevel values differ from
the cached ones, an implementation may retain the cached
information about the outstanding Request message, in
anticipation of the possibility that the Response Class PDU
received might be illegitimate.
c) Otherwise, any cached information about the outstanding
Request message is discarded, and stateReference is set to
<none>.
d) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
13) If the pduType is from the Confirmed Class, then
a) If the value of securityEngineID is not equal to the value of
snmpEngineID, then the security state information is
discarded, any cached information about this message is
discarded, the incoming message is discarded without further
processing, and a FAILURE result is returned. SNMPv3 Message
Processing is complete.
b) Information about the message is cached and a stateReference
is created (implementation-specific). Information to be
cached includes the values of:
msgVersion,
msgID,
securityLevel,
msgFlags,
msgMaxSize,
securityModel,
maxSizeResponseScopedPDU,
securityStateReference
c) A SUCCESS result is returned. SNMPv3 Message Processing is
complete.
14) If the pduType is from the Unconfirmed Class, then A SUCCESS
result is returned. SNMPv3 Message Processing is complete.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Acknowledgements
This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG
members:
Harald Tveit Alvestrand (Maxware)
Dave Battle (SNMP Research, Inc.)
Alan Beard (Disney Worldwide Services)
Paul Berrevoets (SWI Systemware/Halcyon Inc.)
Martin Bjorklund (Ericsson)
Uri Blumenthal (IBM T. J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
Mike Daniele (Compaq Computer Corporation)
T. Max Devlin (Eltrax Systems)
John Flick (Hewlett Packard)
Rob Frye (MCI)
Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
David Harrington (Cabletron Systems Inc.)
Lauren Heintz (BMC Software, Inc.)
N.C. Hien (IBM T. J. Watson Research Center)
Michael Kirkham (InterWorking Labs, Inc.)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Joe Marzot (Nortel Networks)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Bob Moore (IBM)
Russ Mundy (TIS Labs at Network Associates)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reeder (TIS Labs at Network Associates)
David Reid (SNMP Research, Inc.)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Mike Thatcher (Independent Consultant)
Bert Wijnen (IBM T. J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team. Members
of that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
10. Security Considerations
The Dispatcher coordinates the processing of messages to provide a
level of security for management messages and to direct the SNMP PDUs
to the proper SNMP application(s).
A Message Processing Model, and in particular the V3MP defined in
this document, interacts as part of the Message Processing with
Security Models in the Security Subsystem via the abstract service
interface primitives defined in [RFC2571] and elaborated above.
The level of security actually provided is primarily determined by
the specific Security Model implementation(s) and the specific SNMP
application implementation(s) incorporated into this framework.
Applications have access to data which is not secured. Applications
should take reasonable steps to protect the data from disclosure, and
when they send data across the network, they should obey the
securityLevel and call upon the services of an Access Control Model
as they apply access control.
The values for the msgID element used in communication between SNMP
entities must be chosen to avoid replay attacks. The values do not
need to be unpredictable; it is sufficient that they not repeat.
When exchanges are carried out over an insecure network, there is an
open opportunity for a third party to spoof or replay messages when
any message of an exchange is given at the security level of
noAuthNoPriv. For most exchanges, all messages exist at the same
security level. In the case where the final message is an Internal
Class PDU, this message may be delivered at a level of noAuthNoPriv
or authNoPriv, independent of the security level of the preceding
messages. Internal Class PDUs delivered at the level of authNoPriv
are not considered to pose a security hazard. Internal Class PDUs
delivered at the security level of noAuthNoPriv open a window of
opportunity for spoofing or replay attacks. If the receiver of such
messages is aware of these risks, the use of such unauthenticated
messages is acceptable and may provide a useful function for
discovering engine IDs or for detecting misconfiguration at remote
nodes.
This document also contains a MIB definition module. None of the
objects defined is writable, and the information they represent is
not deemed to be particularly sensitive. However, if they are deemed
sensitive in a particular environment, access to them should be
restricted through the use of appropriately configured Security and
Access Control models.
11. References
[RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Introduction to
Community-based SNMPv2", RFC1901, January 1996.
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC2578, April 1999.
[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Protocol Operations for
Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1905, January 1996.
[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Transport Mappings for
Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1906, January 1996.
[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Management Information Base
for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1907 January 1996.
[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Coexistence between Version
1 and Version 2 of the Internet-standard Network
Management Framework", RFC1908, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC2028, October
1996.
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for describing SNMP Management Frameworks",
RFC2571, April 1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC2575, April 1999.
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMP
Applications", RFC2573, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC2570, April 1999.
12. Editors' Addresses
Jeffrey Case
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
USA
Phone: +1 423-573-1434
EMail: case@snmp.com
Dave Harrington
Cabletron Systems, Inc
Post Office Box 5005
Mail Stop: Durham
35 Industrial Way
Rochester, NH 03867-5005
USA
Phone: +1 603-337-7357
EMail: dbh@ctron.com
Randy Presuhn
BMC Software, Inc.
965 Stewart Drive
Sunnyvale, CA 94086
USA
Phone: +1 408-616-3100
EMail: randy_presuhn@bmc.com
Bert Wijnen
IBM T. J. Watson Research
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348-432-794
EMail: wijnen@vnet.ibm.com
13. Changes From RFC2272
The following change log records major changes from the previous
version of this document, RFC2272.
- Updated contact information for editors.
- Made parameter identification in prepareResponseMessage()
consistent, both internally and with architecture.
- Made references to processIncomingMsg() consistent, both
internally and with architecture.
- Deleted superfluous expectResponse parameter from
processIncomingMsg(), consistent with architecture.
- Fixed typos.
- Removed sending of a report PDU from step 4 on page 30 on RFC
2272.
- Use "PDU Class" terminology instead of directly using RFC1905
PDU types, in order to potentially allow use of new PDU types
in the future.
- Added intro document to references.
- Made various clarifications to the text.
- The handling of the reportableFlag has been made consistent.
- The acknowledgement list has been updated.
14. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 RFCEditor function is currently provided by the
Internet Society.