draft-ietf-isms-tmsm-13.txt   draft-ietf-isms-tmsm-14.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 August 27, 2008 Intended status: Standards Track October 14, 2008
Expires: February 28, 2009 Expires: April 17, 2009
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-13 draft-ietf-isms-tmsm-14
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 February 28, 2009. This Internet-Draft will expire on April 17, 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 2, line 18 skipping to change at page 2, line 18
1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4 1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8
3.1. Message Security Requirements . . . . . . . . . . . . . . 8 3.1. Message Security Requirements . . . . . . . . . . . . . . 8
3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8
3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Architectural Modularity Requirements . . . . . . . . 9 3.2.1. Architectural Modularity Requirements . . . . . . . . 9
3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12
3.2.3. Security Parameter Passing Requirements . . . . . . . 12 3.2.3. Security Parameter Passing Requirements . . . . . . . 13
3.2.4. Separation of Authentication and Authorization . . . . 13 3.2.4. Separation of Authentication and Authorization . . . . 13
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14
3.3.1. Session Selection . . . . . . . . . . . . . . . . . . 14 3.3.1. Session Selection . . . . . . . . . . . . . . . . . . 14
3.3.2. Session Establishment Requirements . . . . . . . . . . 15 3.3.2. Session Establishment Requirements . . . . . . . . . . 15
3.3.3. Session Maintenance Requirements . . . . . . . . . . . 15 3.3.3. Session Maintenance Requirements . . . . . . . . . . . 16
3.3.4. Message security versus session security . . . . . . . 16 3.3.4. Message security versus session security . . . . . . . 16
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17
5. Cached Information and References . . . . . . . . . . . . . . 17 5. Cached Information and References . . . . . . . . . . . . . . 17
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Transport information . . . . . . . . . . . . . . . . 18 5.2.1. Transport information . . . . . . . . . . . . . . . . 19
5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19
5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20 5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20
5.2.4. Session Information . . . . . . . . . . . . . . . . . 20 5.2.4. Session Information . . . . . . . . . . . . . . . . . 20
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 20 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 21 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 21
6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 22 6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 22
6.2.1. Message Processing Subsystem Primitives . . . . . . . 22 6.2.1. Message Processing Subsystem Primitives . . . . . . . 22
6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 23 6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 23
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25
6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26 6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26
6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26 6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26
6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27 6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Coexistence, Security Parameters, and Access Control . . . 29 7.1. Coexistence, Security Parameters, and Access Control . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 32 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 33
A.1. Define an Abstract Service Interface . . . . . . . . . . . 33 A.1. Define an Abstract Service Interface . . . . . . . . . . . 33
A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 33 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 34
A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 33 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 34
A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
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 [RFC3411]. Network Management Protocol (SNMP) architecture defined in [RFC3411].
This document identifies and describes some key aspects that need to This document identifies and describes some key aspects that need to
be considered for any Transport Model for SNMP. be considered for any Transport Model for SNMP.
1.1. The Internet-Standard Management Framework 1.1. The Internet-Standard Management Framework
skipping to change at page 12, line 34 skipping to change at page 12, line 34
The Message Processing Subsystem relies on a Security Model, such as The Message Processing Subsystem relies on a Security Model, such as
USM, to play a role in security that goes beyond protecting the USM, to play a role in security that goes beyond protecting the
message - it provides a mapping between the security-model-specific message - it provides a mapping between the security-model-specific
principal for an incoming message to a security-model independent principal for an incoming message to a security-model independent
securityName which can be used for subsequent processing, such as for securityName which can be used for subsequent processing, such as for
access control. The securityName is mapped from a mechanism-specific access control. The securityName is mapped from a mechanism-specific
identity, and this mapping must be done for incoming messages by the identity, and this mapping must be done for incoming messages by the
Security Model before it passes securityName to the Message Security Model before it passes securityName to the Message
Processing Model via the processIncoming ASI. Processing Model via the processIncoming ASI.
Documents defining a new transport domain MUST define a prefix that
will be prepended to all passed tmSecurityNames. The prefix MUST
include from one to four ASCII characters, not including a ":" (ASCII
0x3a) character. A tmSecurityName is constructed by concatenating
the prefix and a ":" (ASCII 0x3a) character followed by a non-empty
identity in an snmpAdminString compatible format. Transport domains
and their corresponding prefixes are coordinated via the IANA
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 tmSecurityLevel will be done by a Transport Model. A Security
Model may have multiple sources for determining the principal and Model may have multiple sources for determining the principal and
skipping to change at page 14, line 8 skipping to change at page 14, line 17
Model that is access-control-model-dependent. Model that is access-control-model-dependent.
A Transport Model does not know which Security Model will be used for A Transport Model does not know which Security Model will be used for
an incoming message, so cannot know how the securityName and an incoming message, so cannot know how the securityName and
securityLevel parameters will be determined. It can propose an securityLevel parameters will be determined. It can propose an
authenticated identity (via the tmSecurityName field), but there is authenticated identity (via the tmSecurityName field), but there is
no guarantee that this value will be used by the Security Model. For no guarantee that this value will be used by the Security Model. For
example, non-transport-aware Security Models will typically determine example, non-transport-aware Security Models will typically determine
the securityName (and securityLevel) based on the contents of the the securityName (and securityLevel) based on the contents of the
SNMP message itself. Such Security Models will simply not know that SNMP message itself. Such Security Models will simply not know that
the tmStateReference cache exists.. the tmStateReference cache exists.
Further, even if the Transport Model can influence the choice of Further, even if the Transport Model can influence the choice of
securityName, it cannot directly determine the authorization allowed securityName, it cannot directly determine the authorization allowed
to this identity. If two different Transport Model each authenticate to this identity. If two different Transport Model each authenticate
a transport principal, that are then both mapped to the same a transport principal, that are then both mapped to the same
securityName, then these two identities will typically be afforded securityName, then these two identities will typically be afforded
exactly the same authorization by the Access Control Model. exactly the same authorization by the Access Control Model.
The only way for the Access Control Model to differentiate between The only way for the Access Control Model to differentiate between
identities based on the underlying Transport Model, would be for such identities based on the underlying Transport Model, would be for such
skipping to change at page 21, line 32 skipping to change at page 21, line 43
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
The sendMessage ASI is used to pass a message from the Dispatcher to The sendMessage ASI is used to pass a message from the Dispatcher to
the appropriate Transport Model for sending. the appropriate Transport Model for sending. In the diagram in
section 4.6.1 of RFC 3411, the sendMessage ASI defined in this
In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI document replaces the text "Send SNMP Request Message to Network".
defined in this document replaces the text "Send SNMP Request Message In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP
to Network". In section 4.6.2, the sendMessage ASI replaces the text Message to Network"
"Send SNMP Message to Network"
If present and valid, the tmStateReference refers to a cache If present and valid, the tmStateReference refers to a cache
containing transport-model-specific parameters for the transport and containing transport-model-specific parameters for the transport and
transport security. How the information in the cache is used is transport security. How a tmStateReference is determined to be
transport-model-dependent and implementation-dependent. How a present and valid is implementation-dependent. How the information
tmStateReference is determined to be present and valid is in the cache is used is transport-model-dependent and implementation-
implementation-dependent. dependent.
This may sound underspecified, but a transport model might be This may sound underspecified, but a transport model might be
something like SNMP over UDP over IPv6, where no security is something like SNMP over UDP over IPv6, where no security is
provided, so it might have no mechanisms for utilizing a securityName provided, so it might have no mechanisms for utilizing a
and securityLevel. tmStateReference cache.
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
skipping to change at page 25, line 28 skipping to change at page 25, line 28
OUT securityParameters -- filled in by Security Module OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) reference to transport state OUT tmStateReference -- (NEW) reference to transport state
) )
) )
6.3. The receiveMessage ASI 6.3. The receiveMessage ASI
The receiveMessage ASI is used to pass a message from the Transport
Subsystem to the Dispatcher. In the diagram in section 4.6.1 of RFC
3411, the receiveMessage ASI replaces the text "Receive SNMP Response
Message from Network". In section 4.6.2, the receiveMessage ASI
replaces the text "Receive SNMP Message from Network".
When a message is received on a given transport session, if a cache When a message is received on a given transport session, if a cache
does not already exist for that session, the Transport Model might does not already exist for that session, the Transport Model might
create one, referenced by tmStateReference. The contents of this create one, referenced by tmStateReference. The contents of this
cache are discussed in section 5. How this information is determined cache are discussed in section 5. How this information is determined
is implementation- and transport-model-specific. is implementation- and transport-model-specific.
In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI "Might createone" may sound underspecified, but a transport model
replaces the text "Receive SNMP Response Message from Network". In might be something like SNMP over UDP over IPv6, where transport
section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP security is not provided, so it might not create a cache.
Message from Network"
This may sound underspecified, but a transport model might be
something like SNMP over UDP over IPv6, where no security is
provided, so it might have no mechanisms for determining a
securityName and securityLevel.
The Transport Model does not know the securityModel for an incoming The Transport Model does not know the securityModel for an incoming
message; this will be determined by the Message Processing Model in a message; this will be determined by the Message Processing Model in a
message-processing-model-dependent manner. message-processing-model-dependent manner.
The receiveMessage ASI is used to pass a message from the Transport
Subsystem to the Dispatcher.
statusInformation = statusInformation =
receiveMessage( receiveMessage(
IN transportDomain -- origin transport domain IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address IN transportAddress -- origin transport address
IN incomingMessage -- the message received IN incomingMessage -- the message received
IN incomingMessageLength -- its length IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
6.4. Changes to RFC3411 Incoming ASIs 6.4. Changes to RFC3411 Incoming ASIs
skipping to change at page 30, line 12 skipping to change at page 30, line 12
specified in the msgSecurityParameters field of the message (per specified in the msgSecurityParameters field of the message (per
RFC3412), regardless of the transport mapping or transport model RFC3412), regardless of the transport mapping or transport model
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
This document requires no action by IANA. IANA is requested to create a new registry in the Simple Network
Management Protocol (SNMP) Number Spaces. The new registry should be
called "SNMP Transport Domains". This registry iwill contain ASCII
strings of one to four characters to identify prefixes for
corresponding SNMP transport domains. Each transport domain requires
an OID assignment under snmpDomains [RFC2578] . Values are to be
assigned via RFC2434 "Specification Required".
The registry should be populated with the following initial entries:
Registry Name: SNMP Transport Domains
Reference: [RFC2578] [RFC3417] [XXXX]
Registration Procedures: Specification Required
Each domain is assigned a MIB-defined OID under snmpDomains
Prefix snmpDomain Reference
------- ----------------------------- ---------
udp snmpUDPDomain RFC3417
clns snmpCLNSDomain RFC3417
cons snmpCONSDomain RFC3417
ddp snmpDDPDomain RFC3417
ipx snmpIPXDomain RFC3417
prxy rfc1157Domain RFC3417
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
9. Acknowledgments 9. Acknowledgments
The Integrated Security for SNMP WG would like to thank the following The Integrated Security for SNMP WG would like to thank the following
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. Wijnen, Tom Petch, Wes Hardaker, and Dave Shields.
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.
[RFC2578] McCloghrie, K., Ed.,
Perkins, D., Ed., and J.
Schoenwaelder, Ed.,
"Structure of Management
Information Version 2
(SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC3411] Harrington, D., Presuhn, [RFC3411] Harrington, D., Presuhn,
R., and B. Wijnen, "An R., and B. Wijnen, "An
Architecture for Describing Architecture for Describing
Simple Network Management Simple Network Management
Protocol (SNMP) Management Protocol (SNMP) Management
Frameworks", STD 62, Frameworks", STD 62,
RFC 3411, December 2002. RFC 3411, December 2002.
[RFC3412] Case, J., Harrington, D., [RFC3412] Case, J., Harrington, D.,
Presuhn, R., and B. Wijnen, Presuhn, R., and B. Wijnen,
skipping to change at page 32, line 20 skipping to change at page 33, line 5
[RFC4251] Ylonen, T. and C. Lonvick, [RFC4251] Ylonen, T. and C. Lonvick,
"The Secure Shell (SSH) "The Secure Shell (SSH)
Protocol Architecture", Protocol Architecture",
RFC 4251, January 2006. RFC 4251, January 2006.
[RFC4741] Enns, R., "NETCONF [RFC4741] Enns, R., "NETCONF
Configuration Protocol", Configuration Protocol",
RFC 4741, December 2006. RFC 4741, December 2006.
[I-D.ietf-isms-transport-security-model] Harrington, D., "Transport [I-D.ietf-isms-transport-security-model] Harrington, D. and W.
Hardaker, "Transport
Security Model for SNMP", d Security Model for SNMP", d
raft-ietf-isms-transport- raft-ietf-isms-transport-
security-model-08 (work in security-model-09 (work in
progress), July 2008. progress), October 2008.
[I-D.ietf-isms-secshell] Harrington, D. and J. [I-D.ietf-isms-secshell] Harrington, D., Salowey,
Salowey, "Secure Shell J., and W. Hardaker,
Transport Model for SNMP", "Secure Shell Transport
draft-ietf-isms-secshell-11 Model for SNMP",
draft-ietf-isms-secshell-12
(work in progress), (work in progress),
July 2008. October 2008.
[I-D.ietf-syslog-protocol] Gerhards, R., "The syslog [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog
Protocol", draft-ietf- Protocol", draft-ietf-
syslog-protocol-23 (work in syslog-protocol-23 (work in
progress), September 2007. progress), September 2007.
Appendix A. Why tmStateReference? Appendix A. Why tmStateReference?
This appendix considers why a cache-based approach was selected for This appendix considers why a cache-based approach was selected for
passing parameters. passing parameters.
 End of changes. 25 change blocks. 
51 lines changed or deleted 91 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/