draft-ietf-isms-tmsm-14.txt   draft-ietf-isms-tmsm-15.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Updates: 3411,3412,3414,3417 J. Schoenwaelder Updates: 3411,3412,3414,3417 J. Schoenwaelder
(if approved) Jacobs University Bremen (if approved) Jacobs University Bremen
Intended status: Standards Track October 14, 2008 Intended status: Standards Track November 1, 2008
Expires: April 17, 2009 Expires: May 5, 2009
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-14 draft-ietf-isms-tmsm-15
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2009. This Internet-Draft will expire on May 5, 2009.
Abstract Abstract
This document defines a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411. Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document defines a subsystem to contain Transport Models, This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work comparable to other subsystems in the RFC3411 architecture. As work
is being done to expand the transports to include secure transports is being done to expand the transports to include secure transports
such as SSH and TLS, using a subsystem will enable consistent design such as SSH and TLS, using a subsystem will enable consistent design
and modularity of such Transport Models. This document identifies and modularity of such Transport Models. This document identifies
skipping to change at page 6, line 27 skipping to change at page 6, line 27
In the first approach, an individual could sit on his front porch In the first approach, an individual could sit on his front porch
waiting for intruders. In the second approach, he could hire an waiting for intruders. In the second approach, he could hire an
employee , schedule the employee, position the employee to guard what employee , schedule the employee, position the employee to guard what
he wants protected, hire a second guard to cover if the first gets he wants protected, hire a second guard to cover if the first gets
sick, and so on. In the third approach, he could hire a security sick, and so on. In the third approach, he could hire a security
company, tell them what he wants protected, and leave the details to company, tell them what he wants protected, and leave the details to
them. Considerations of hiring and training employees, positioning them. Considerations of hiring and training employees, positioning
and scheduling the guards, arranging for cover, etc., are the and scheduling the guards, arranging for cover, etc., are the
responsibility of the security company. The individual therefore responsibility of the security company. The individual therefore
achieves the desired security, with no significant effort... achieves the desired security, with no significant effort with no
significant effort on his part other than identifying requirements
and verifying the quality of service being provided.
The User-based Security Model (USM) as defined in [RFC3414] largely The User-based Security Model (USM) as defined in [RFC3414] largely
uses the first approach - it provides its own security. It utilizes uses the first approach - it provides its own security. It utilizes
existing mechanisms (e.g., SHA), but provides all the coordination. existing mechanisms (e.g., SHA), but provides all the coordination.
USM provides for the authentication of a principal, message USM provides for the authentication of a principal, message
encryption, data integrity checking, timeliness checking, etc. encryption, data integrity checking, timeliness checking, etc.
USM was designed to be independent of other existing security USM was designed to be independent of other existing security
infrastructures. USM therefore requires a separate principal and key infrastructures. USM therefore requires a separate principal and key
management infrastructure. Operators have reported that deploying management infrastructure. Operators have reported that deploying
skipping to change at page 11, line 38 skipping to change at page 11, line 38
The introduction of secure transports also affects the The introduction of secure transports also affects the
responsibilities and order of processing within the RFC3411 responsibilities and order of processing within the RFC3411
architecture. While the steps are the same, they may occur in a architecture. While the steps are the same, they may occur in a
different order, and may be done by different subsystems. With the different order, and may be done by different subsystems. With the
existing RFC3411 architecture, security processing starts when the existing RFC3411 architecture, security processing starts when the
Message Processing Model decodes portions of the encoded message to Message Processing Model decodes portions of the encoded message to
extract parameters that identify which Security Model should handle extract parameters that identify which Security Model should handle
the security-related tasks. the security-related tasks.
A secure transport performs those security functions on the message, A secure transport performs those security functions on the message,
*before* the message is decoded. Note that some of these functions *before* the message is decoded. Some of these functions might then
might then be repeated by the selected Security Model. be repeated by the selected Security Model.
3.2.1.3. Passing Information between SNMP Engines 3.2.1.3. Passing Information between SNMP Engines
A secure Transport Model will establish an authenticated and/or A secure Transport Model will establish an authenticated and/or
encrypted tunnel between the Transport Models of two SNMP engines. encrypted tunnel between the Transport Models of two SNMP engines.
After a transport layer tunnel is established, then SNMP messages can After a transport layer tunnel is established, then SNMP messages can
be sent through the tunnel from one SNMP engine to the other. be sent through the tunnel from one SNMP engine to the other.
Transport Models MAY support sending multiple SNMP messages through Transport Models MAY support sending multiple SNMP messages through
the same tunnel. the same tunnel.
skipping to change at page 12, line 51 skipping to change at page 12, line 51
registry "SNMP Transport Domains". registry "SNMP Transport Domains".
A Security Model is also responsible to specify, via the A Security Model is also responsible to specify, via the
securityLevel parameter, whether incoming messages have been securityLevel parameter, whether incoming messages have been
authenticated and/or encrypted, and to ensure that outgoing messages authenticated and/or encrypted, and to ensure that outgoing messages
are authenticated and/or encrypted based on the value of are authenticated and/or encrypted based on the value of
securityLevel. securityLevel.
The introduction of a secure transport protocol means that the The introduction of a secure transport protocol means that the
translation from a mechanism-specific identity to a tmSecurityName translation from a mechanism-specific identity to a tmSecurityName
and tmSecurityLevel will be done by a Transport Model. A Security and tmTransportSecurityLevel will be done by a Transport Model. A
Model may have multiple sources for determining the principal and Security Model may have multiple sources for determining the
desired security services, and a particular Security Model may or may principal and desired security services, and a particular Security
not utilize the tmSecurityName mapping and tmSecurityLevel proposed Model may or may not utilize the tmSecurityName mapping and
by the Transport Model when deciding the value of the securityName tmTransportSecurityLevel proposed by the Transport Model when
and securityLevel to be passed to the Message Processing Model. deciding the value of the securityName and securityLevel to be passed
to the Message Processing Model.
3.2.3. Security Parameter Passing Requirements 3.2.3. Security Parameter Passing Requirements
A Message Processing Model might unpack SNMP-specific security A Message Processing Model might unpack SNMP-specific security
parameters from an incoming message before calling a specific parameters from an incoming message before calling a specific
Security Model to handle the security-related processing of the Security Model to handle the security-related processing of the
message. When using a secure Transport Model, some security message. When using a secure Transport Model, some security
parameters might be extracted from the transport layer by the parameters might be extracted from the transport layer by the
Security Model before the message is passed to the Message Processing Transport Model before the message is passed to the Message
Subsystem.. Processing Subsystem.
This document describes a cache mechanism (see Section 5), into which This document describes a cache mechanism (see Section 5), into which
the Transport Model puts information about the transport and security the Transport Model puts information about the transport and security
parameters applied to a transport connection or an incoming message, parameters applied to a transport connection or an incoming message,
and a Security Model may extract that information from the cache. A and a Security Model may extract that information from the cache. A
tmStateReference is passed as an extra parameter in the ASIs between tmStateReference is passed as an extra parameter in the ASIs between
the Transport Subsystem, the Message Processing and Security the Transport Subsystem, the Message Processing and Security
Subsystems, to identify the relevant cache. This approach of passing Subsystems, to identify the relevant cache. This approach of passing
a model-independent reference is consistent with the a model-independent reference is consistent with the
securityStateReference cache already being passed around in the securityStateReference cache already being passed around in the
skipping to change at page 15, line 15 skipping to change at page 15, line 17
parameters of these ASIs might be used to guide the selection of the parameters of these ASIs might be used to guide the selection of the
appropriate transport session to use for a given request. appropriate transport session to use for a given request.
The transportDomain and transportAddress identify the transport The transportDomain and transportAddress identify the transport
connection to a remote network node. Elements of the transport connection to a remote network node. Elements of the transport
address (such as the port number) can be used to select different address (such as the port number) can be used to select different
sessions for particular request types. For example, UDP ports 161 sessions for particular request types. For example, UDP ports 161
and 162 have typically been used to separate SNMP notifications from and 162 have typically been used to separate SNMP notifications from
other request/response traffic. other request/response traffic.
The securityName identifies which security principal to communicate The tmSecurityName identifies which security principal to communicate
with at that address (e.g., different NMS applications), and the with at that address (e.g., different NMS applications), and the
securityLevel might permit selection of different sets of security tmRequestedSecurityLevel might permit selection of different sets of
properties for different purposes (e.g., encrypted SETs vs. non- security properties for different purposes (e.g., encrypted SETs vs.
encrypted GETs). non-encrypted GETs).
In summary, a unique combination of transportDomain, In summary, a unique combination of transportDomain,
transportAddress, securityName, and securityLevel could serve to transportAddress, securityName, and securityLevel could serve to
identify a given transport session. Different values for any of identify a given transport session. Different values for any of
these parameters would imply the use of a different session. these parameters would imply the use of a different session.
However, because the handling of transport sessions is specific to However, because the handling of transport sessions is specific to
each transport model, some transport models MAY restrict the each transport model, some transport models MAY restrict the
applicability of these parameters for selecting an associated applicability of these parameters for selecting an associated
transport session. transport session.
skipping to change at page 15, line 44 skipping to change at page 15, line 46
3.3.2. Session Establishment Requirements 3.3.2. Session Establishment Requirements
SNMP applications provide the transportDomain, transportAddress, SNMP applications provide the transportDomain, transportAddress,
securityName, and securityLevel to be used to create a new session. securityName, and securityLevel to be used to create a new session.
If the Transport Model cannot provide at least the requested level of If the Transport Model cannot provide at least the requested level of
security, the Transport Model SHOULD discard the message and SHOULD security, the Transport Model SHOULD discard the message and SHOULD
notify the dispatcher that establishing a session and sending the notify the dispatcher that establishing a session and sending the
message failed. Similarly, if the session cannot be established, message failed. Similarly, if the session cannot be established,
then the message should be discarded and the dispatcher notified. then the message SHOULD be discarded and the dispatcher notified.
Transport session establishment might require provisioning Transport session establishment might require provisioning
authentication credentials at an engine, either statically or authentication credentials at an engine, either statically or
dynamically. How this is done is dependent on the transport model dynamically. How this is done is dependent on the transport model
and the implementation. and the implementation.
3.3.3. Session Maintenance Requirements 3.3.3. Session Maintenance Requirements
A Transport Model can tear down sessions as needed. It might be A Transport Model can tear down sessions as needed. It might be
necessary for some implementations to tear down sessions as the necessary for some implementations to tear down sessions as the
skipping to change at page 16, line 48 skipping to change at page 16, line 48
take a message observed on one session, and successfully replay this take a message observed on one session, and successfully replay this
on another session. on another session.
A good security protocol would also protect against replay attacks A good security protocol would also protect against replay attacks
within a session; that is, an attacker could not take a message within a session; that is, an attacker could not take a message
observed on a session, and successfully replay this later in the same observed on a session, and successfully replay this later in the same
session. One approach would be to use sequence information within session. One approach would be to use sequence information within
the protocol, allowing the participants to detect if messages were the protocol, allowing the participants to detect if messages were
replayed or reordered within a session. replayed or reordered within a session.
Note that if a secure transport session is closed between the time a If a secure transport session is closed between the time a request
request message is received, and the corresponding response message message is received, and the corresponding response message is sent,
is sent, then the response message SHOULD be discarded, even if a new then the response message SHOULD be discarded, even if a new session
session has been established. The SNMPv3 WG decided that this should has been established. The SNMPv3 WG decided that this should be a
be a SHOULD architecturally, and it is a security-model-specific SHOULD architecturally, and it is a security-model-specific decision
decision whether to REQUIRE this. whether to REQUIRE this.
SNMPv3 was designed to support multiple levels of security, SNMPv3 was designed to support multiple levels of security,
selectable on a per-message basis by an SNMP application, because, selectable on a per-message basis by an SNMP application, because,
for example, there is not much value in using encryption for a for example, there is not much value in using encryption for a
Commander Generator to poll for potentially non-sensitive performance Commander Generator to poll for potentially non-sensitive performance
data on thousands of interfaces every ten minutes; the encryption data on thousands of interfaces every ten minutes; the encryption
might add significant overhead to processing of the messages. might add significant overhead to processing of the messages.
Some Transport Models might support only specific authentication and Some Transport Models might support only specific authentication and
encryption services, such as requiring all messages to be carried encryption services, such as requiring all messages to be carried
skipping to change at page 19, line 26 skipping to change at page 19, line 26
request, and setting up the authorization parameters. It is request, and setting up the authorization parameters. It is
therefore necessary for the Transport Model to include this therefore necessary for the Transport Model to include this
information in the tmStateReference cache, so that it is accessible information in the tmStateReference cache, so that it is accessible
to the Security Model. to the Security Model.
o transportDomain: the transport protocol (and hence the Transport o transportDomain: the transport protocol (and hence the Transport
Model) used to receive the incoming message Model) used to receive the incoming message
o transportAddress: the source of the incoming message. o transportAddress: the source of the incoming message.
Note that the ASIs used for processing an outgoing message all The ASIs used for processing an outgoing message all include explicit
include explicit transportDomain and transportAddress parameters. transportDomain and transportAddress parameters. The values within
These fields within the tmStateReference cache will typically not be the securityStateReference cache might override these parameters for
used for outgoing messages. outgoing messages.
5.2.2. securityName 5.2.2. securityName
There are actually three distinct "identities" that can be identified There are actually three distinct "identities" that can be identified
during the processing of an SNMP request over a secure transport: during the processing of an SNMP request over a secure transport:
o transport principal: the transport-authenticated identity, on o transport principal: the transport-authenticated identity, on
whose behalf the secure transport connection was (or should be) whose behalf the secure transport connection was (or should be)
established. This value is transport-, mechanism- and established. This value is transport-, mechanism- and
implementation- specific, and is only used within a given implementation- specific, and is only used within a given
Transport Model. Transport Model.
o tmSecurityName: a human-readable name (in snmpAdminString format) o tmSecurityName: a human-readable name (in snmpAdminString format)
representing this transport identity. This value is transport- representing this transport identity. This value is transport-
and implementation-specific, and is only used (directly) by the and implementation-specific, and is only used (directly) by the
Transport and Security Models. Transport and Security Models.
o securityName: a human-readable name (in snmpAdminString format) o securityName: a human-readable name (in snmpAdminString format)
representing the SNMP principal in a model-independent manner. representing the SNMP principal in a model-independent manner.
o Note that the transport principal may or may not be the same as The transport principal may or may not be the same as the
the tmSecurityName. Similarly, the tmSecurityName may or may not tmSecurityName. Similarly, the tmSecurityName may or may not be the
be the same as the securityName as seen by the Application and same as the securityName as seen by the Application and Access
Access Control subsystems. In particular, a non-transport-aware Control subsystems. In particular, a non-transport-aware Security
Security Model will ignore tmSecurityName completely when Model will ignore tmSecurityName completely when determining the SNMP
determining the SNMP securityName. securityName.
o However it is important that the mapping between the transport However it is important that the mapping between the transport
principal and the SNMP securityName (for transport-aware Security principal and the SNMP securityName (for transport-aware Security
Models) is consistent and predictable, to allow configuration of Models) is consistent and predictable, to allow configuration of
suitable access control and the establishment of transport suitable access control and the establishment of transport
connections. connections.
5.2.3. securityLevel 5.2.3. securityLevel
There are two distinct issues relating to security level as applied There are two distinct issues relating to security level as applied
to secure transports. For clarity, these are handled by separate to secure transports. For clarity, these are handled by separate
fields in the tmStateReference cache: fields in the tmStateReference cache:
skipping to change at page 20, line 41 skipping to change at page 20, line 41
5.2.4. Session Information 5.2.4. Session Information
For security reasons, if a secure transport session is closed between For security reasons, if a secure transport session is closed between
the time a request message is received and the corresponding response the time a request message is received and the corresponding response
message is sent, then the response message SHOULD be discarded, even message is sent, then the response message SHOULD be discarded, even
if a new session has been established. The SNMPv3 WG decided that if a new session has been established. The SNMPv3 WG decided that
this should be a SHOULD architecturally, and it is a security-model- this should be a SHOULD architecturally, and it is a security-model-
specific decision whether to REQUIRE this. specific decision whether to REQUIRE this.
When processing an outgoing message, if tmSameSecurity is true, then
the tmSessionID MUST match the current transport session, otherwise
the message MUST be discarded, and the dispatcher notified that
sending the message failed.
o tmSameSecurity: this flag is used by a transport-aware Security o tmSameSecurity: this flag is used by a transport-aware Security
Model to indicate whether the Transport Model MUST enforce this Model to indicate whether the Transport Model MUST enforce this
restriction. restriction.
o tmSessionID: in order to verify whether the session has changed, o tmSessionID: in order to verify whether the session has changed,
the Transport Model must be able to compare the session used to the Transport Model must be able to compare the session used to
receive the original request with the one to be used to send the receive the original request with the one to be used to send the
response. This typically requires some form of session response. This typically requires some form of session
identifier. This value is only ever used by the Transport Model, identifier. This value is only ever used by the Transport Model,
so the format and interpretation of this field are model-specific so the format and interpretation of this field are model-specific
and implementation-dependent. and implementation-dependent.
When processing an outgoing message, if tmSameSecurity is true, then
the tmSessionID MUST match the current transport session, otherwise
the message MUST be discarded, and the dispatcher notified that
sending the message failed.
6. Abstract Service Interfaces 6. Abstract Service Interfaces
Abstract service interfaces have been defined by RFC 3411 to describe Abstract service interfaces have been defined by RFC 3411 to describe
the conceptual data flows between the various subsystems within an the conceptual data flows between the various subsystems within an
SNMP entity, and to help keep the subsystems independent of each SNMP entity, and to help keep the subsystems independent of each
other except for the common parameters. other except for the common parameters.
This document introduces a couple of new ASIs to define the interface This document introduces a couple of new ASIs to define the interface
between the Transport and Dispatcher Subsystems, and extends some of between the Transport and Dispatcher Subsystems, and extends some of
the ASIs defined in RFC3411 to include transport-related information. the ASIs defined in RFC3411 to include transport-related information.
This document follows the example of RFC3411 regarding the release of This document follows the example of RFC3411 regarding the release of
state information, and regarding error indications. state information, and regarding error indications.
1) The release of state information is not always explicitly 1) The release of state information is not always explicitly
specified in a transport model. As a general rule, if state specified in a transport model. As a general rule, if state
information is available when a message gets discarded, the message- information is available when a message gets discarded, the message-
state information should also be released, and if state information state information should also be released, and if state information
is available when a session is closed, the session state information is available when a session is closed, the session state information
should also be released. Note that keeping sensitive security should also be released. Keeping sensitive security information
information longer than necessary might introduce potential longer than necessary might introduce potential vulnerabilities to an
vulnerabilities to an implementation. implementation.
2)An error indication in statusInformation will typically include the 2)An error indication in statusInformation will typically include the
OID and value for an incremented error counter. This may be OID and value for an incremented error counter. This may be
accompanied by values for contextEngineID and contextName for this accompanied by values for contextEngineID and contextName for this
counter, a value for securityLevel, and the appropriate state counter, a value for securityLevel, and the appropriate state
reference if the information is available at the point where the reference if the information is available at the point where the
error is detected. error is detected.
6.1. sendMessage ASI 6.1. sendMessage ASI
skipping to change at page 30, line 14 skipping to change at page 30, line 14
used. If the SNMPv3 message specifies the User-based Security used. If the SNMPv3 message specifies the User-based Security
Model (USM), access controls will be based on the USM user. If Model (USM), access controls will be based on the USM user. If
the SNMPv3 message specifies the Transport Security Model (TSM), the SNMPv3 message specifies the Transport Security Model (TSM),
access controls will be based on the principal authenticated by access controls will be based on the principal authenticated by
the transport. the transport.
8. IANA Considerations 8. IANA Considerations
IANA is requested to create a new registry in the Simple Network IANA is requested to create a new registry in the Simple Network
Management Protocol (SNMP) Number Spaces. The new registry should be Management Protocol (SNMP) Number Spaces. The new registry should be
called "SNMP Transport Domains". This registry iwill contain ASCII called "SNMP Transport Domains". This registry will contain ASCII
strings of one to four characters to identify prefixes for strings of one to four characters to identify prefixes for
corresponding SNMP transport domains. Each transport domain requires corresponding SNMP transport domains. Each transport domain requires
an OID assignment under snmpDomains [RFC2578] . Values are to be an OID assignment under snmpDomains [RFC2578] . Values are to be
assigned via RFC2434 "Specification Required". assigned via RFC2434 "Specification Required".
The registry should be populated with the following initial entries: The registry should be populated with the following initial entries:
Registry Name: SNMP Transport Domains Registry Name: SNMP Transport Domains
Reference: [RFC2578] [RFC3417] [XXXX] Reference: [RFC2578] [RFC3417] [XXXX]
Registration Procedures: Specification Required Registration Procedures: Specification Required
skipping to change at page 31, line 4 skipping to change at page 31, line 4
people for their contributions to the process: people for their contributions to the process:
The authors of submitted Security Model proposals: Chris Elliot, Wes The authors of submitted Security Model proposals: Chris Elliot, Wes
Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David
Perkins, Joseph Salowey, and Juergen Schoenwaelder. Perkins, Joseph Salowey, and Juergen Schoenwaelder.
The members of the Protocol Evaluation Team: Uri Blumenthal, The members of the Protocol Evaluation Team: Uri Blumenthal,
Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla.
WG members who performed detailed reviews: Jeffrey Hutzelman, Bert WG members who performed detailed reviews: Jeffrey Hutzelman, Bert
Wijnen, Tom Petch, Wes Hardaker, and Dave Shields. Wijnen, Tom Petch, Wes Hardaker, and Dave Shield.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for [RFC2119] Bradner, S., "Key words for
use in RFCs to Indicate use in RFCs to Indicate
Requirement Levels", Requirement Levels",
BCP 14, RFC 2119, BCP 14, RFC 2119,
March 1997. March 1997.
skipping to change at page 35, line 18 skipping to change at page 35, line 18
open issues section before publishing this document as an RFC. (If open issues section before publishing this document as an RFC. (If
it is not empty, please send it back to the editor to resolve. it is not empty, please send it back to the editor to resolve.
o o
Appendix C. Change Log Appendix C. Change Log
NOTE to RFC editor: Please remove this change log before publishing NOTE to RFC editor: Please remove this change log before publishing
this document as an RFC. this document as an RFC.
Changes from -14- to -15-
o editorial changes and reorganization
Changes from -13- to -14-
o
Changes from -12- to -13- Changes from -12- to -13-
o moved conventions after Internet Standard framework, for o moved conventions after Internet Standard framework, for
consistency with related documents. consistency with related documents.
o editorial changes and reorganization o editorial changes and reorganization
Changes from -10- to -12- Changes from -10- to -12-
o clarified relation to other documents. o clarified relation to other documents.
 End of changes. 20 change blocks. 
47 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/