< draft-ietf-isms-dtls-tm-03.txt		draft-ietf-isms-dtls-tm-04.txt >
	ISMS W. Hardaker		ISMS W. Hardaker
	Internet-Draft Sparta, Inc.		Internet-Draft Sparta, Inc.
	Intended status: Standards Track December 23, 2009		Intended status: Standards Track December 30, 2009
	Expires: June 26, 2010		Expires: July 3, 2010
	Transport Layer Security (TLS) Transport Model for SNMP		Transport Layer Security (TLS) Transport Model for SNMP
	draft-ietf-isms-dtls-tm-03.txt		draft-ietf-isms-dtls-tm-04.txt
	Abstract		Abstract
	This document describes a Transport Model for the Simple Network		This document describes a Transport Model for the Simple Network
	Management Protocol (SNMP), that uses either the Transport Layer		Management Protocol (SNMP), that uses either the Transport Layer
	Security protocol or the Datagram Transport Layer Security (DTLS)		Security protocol or the Datagram Transport Layer Security (DTLS)
	protocol. The TLS and DTLS protocols provide authentication and		protocol. The TLS and DTLS protocols provide authentication and
	privacy services for SNMP applications. This document describes how		privacy services for SNMP applications. This document describes how
	the TLS Transport Model (TLSTM) implements the needed features of a		the TLS Transport Model (TLSTM) implements the needed features of a
	SNMP Transport Subsystem to make this protection possible in an		SNMP Transport Subsystem to make this protection possible in an
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	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 June 26, 2010.		This Internet-Draft will expire on July 3, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19		4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19
	4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19		4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19
	4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19		4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19
	5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20		5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
	5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20		5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20
	5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20		5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20
	5.1.2. Transport Processing for Incoming SNMP Messages . . . 22		5.1.2. Transport Processing for Incoming SNMP Messages . . . 22
	5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23		5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23
	5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24		5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24
	5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27		5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
	6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 27		6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28
	6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28		6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
	6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28		6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
	6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28		6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
	6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28		6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
	6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 28		6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29
	6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29		6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
	6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29		6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
	7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29		7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
	8. Operational Considerations . . . . . . . . . . . . . . . . . . 50		8. Operational Considerations . . . . . . . . . . . . . . . . . . 51
	8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51		8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
	8.2. Notification Receiver Credential Selection . . . . . . . . 51		8.2. Notification Receiver Credential Selection . . . . . . . . 51
	8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 51		8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52
	8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52		8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 52		9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
	9.1. Certificates, Authentication, and Authorization . . . . . 52		9.1. Certificates, Authentication, and Authorization . . . . . 53
	9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53		9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53
	9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 53		9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 57		12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
	12.2. Informative References . . . . . . . . . . . . . . . . . . 58		12.2. Informative References . . . . . . . . . . . . . . . . . . 58
	Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59		Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
	A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59		A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 60
	A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60		A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
	Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61		Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
	Appendix C. Target and Notificaton Configuration Example . . . . 62		Appendix C. Target and Notificaton Configuration Example . . . . 62
	C.1. Configuring the Notification Generator . . . . . . . . . . 63		C.1. Configuring the Notification Generator . . . . . . . . . . 63
	C.2. Configuring the Command Responder . . . . . . . . . . . . 63		C.2. Configuring the Command Responder . . . . . . . . . . . . 63
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
	1. Introduction		1. Introduction
	It is important to understand the modular SNMPv3 architecture as		It is important to understand the modular SNMPv3 architecture as
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	provided by the Dispatcher in the sendMessage() Abstract Service		provided by the Dispatcher in the sendMessage() Abstract Service
	Interface (ASI) and input from the tmStateReference cache. The		Interface (ASI) and input from the tmStateReference cache. The
	(D)TLS Transport Model converts that information into suitable		(D)TLS Transport Model converts that information into suitable
	security parameters for (D)TLS and establishes sessions as needed.		security parameters for (D)TLS and establishes sessions as needed.
	The elements of procedure in Section 5 discuss these concepts in much		The elements of procedure in Section 5 discuss these concepts in much
	greater detail.		greater detail.
	3.3. Notifications and Proxy		3.3. Notifications and Proxy
	(D)TLS sessions may be initiated by (D)TLS clients on behalf of		(D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP
	command generators, notification originators, proxy forwarders or		appplications that initiate communications, such as command
	other applications. Command generators are frequently operated by a		generators, notification originators, proxy forwarders. Command
	human, but notification originators and proxy forwarders are usually		generators are frequently operated by a human, but notification
	unmanned automated processes. The targets to whom notifications and		originators and proxy forwarders are usually unmanned automated
	proxied requests should be sent is typically determined and		processes. The targets to whom notifications and proxied requests
	configured by a network administrator.		should be sent is typically determined and configured by a network
			administrator.
	The SNMP-TARGET-MIB module [RFC3413] contains objects for defining		The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
	management targets, including transportDomain, transportAddress,		management targets, including transportDomain, transportAddress,
	securityName, securityModel, and securityLevel parameters, for		securityName, securityModel, and securityLevel parameters, for
	notification generator, proxy forwarder, and SNMP-controllable		notification generator, proxy forwarder, and SNMP-controllable
	command generator applications. Transport domains and transport		command generator applications. Transport domains and transport
	addresses are configured in the snmpTargetAddrTable, and the		addresses are configured in the snmpTargetAddrTable, and the
	securityModel, securityName, and securityLevel parameters are		securityModel, securityName, and securityLevel parameters are
	configured in the snmpTargetParamsTable. This document defines a MIB		configured in the snmpTargetParamsTable. This document defines a MIB
	module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to		module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to
	skipping to change at page 26, line 18 ¶		skipping to change at page 26, line 18 ¶
	3) Once a (D)TLS secured session is established and both sides have		3) Once a (D)TLS secured session is established and both sides have
	verified the authenticity of the peer's certificate (e.g.		verified the authenticity of the peer's certificate (e.g.
	[RFC5280]) then each side will determine and/or check the		[RFC5280]) then each side will determine and/or check the
	identity of the remote entity using the procedures described		identity of the remote entity using the procedures described
	below.		below.
	a) The (D)TLS server side of the connection identifies the		a) The (D)TLS server side of the connection identifies the
	authenticated identity from the (D)TLS client's principal		authenticated identity from the (D)TLS client's principal
	certificate using configuration information from the		certificate using configuration information from the
	tlstmCertToTSNTable mapping table. The resulting derived		tlstmCertToTSNTable mapping table. The (D)TLS server MUST
	tmSecurityName is recorded in the tmStateReference cache as		request and expect a certificate from the client and MUST NOT
	tmSecurityName. The details of the lookup process are fully		accept SNMP messages over the (D)TLS session until the client
	described in the DESCRIPTION clause of the		has sent a certificate and it has been authenticated. The
	tlstmCertToTSNTable MIB object. If any verification fails in		resulting derived tmSecurityName is recorded in the
	any way (for example because of failures in cryptographic		tmStateReference cache as tmSecurityName. The details of the
	verification or because of the lack of an appropriate row in		lookup process are fully described in the DESCRIPTION clause
	the tlstmCertToTSNTable) then the session establishment MUST		of the tlstmCertToTSNTable MIB object. If any verification
	fail, the snmpTlstmSessionInvalidClientCertificates object is		fails in any way (for example because of failures in
			cryptographic verification or because of the lack of an
			appropriate row in the tlstmCertToTSNTable) then the session
			establishment MUST fail, the
			snmpTlstmSessionInvalidClientCertificates object is
	incremented and processing stops.		incremented and processing stops.
	b) The (D)TLS client side of the connection MUST verify that		b) The (D)TLS client side of the connection MUST verify that
	authenticated identity of the (D)TLS server's presented		authenticated identity of the (D)TLS server's presented
	certificate is the expected certificate.		certificate is the expected certificate. The (D)TLS client
			MUST NOT transmit SNMP messages until the server certificate
			has been authenticated and the client certificate has been
			transmitted.
	If the connection is being established from configuration		If the connection is being established from configuration
	based on SNMP-TARGET-MIB configuration then the procedures in		based on SNMP-TARGET-MIB configuration then the procedures in
	the tlstmAddrTable DESCRIPTION clause should be followed to		the tlstmAddrTable DESCRIPTION clause should be followed to
	determine the if the presented identity matches the		determine if the presented identity matches the expectations
	expectations of the configuration. Path validation		of the configuration. Path validation procedures (like those
	procedures (like those defined in [RFC5280]) MUST be		defined in [RFC5280]) MUST be followed. If a server identity
	followed. If a server identity name has been configured in		name has been configured in the tlstmAddrServerIdentity
	the tlstmAddrServerIdentity column then this reference		column then this reference identity must be compared against
	identity must be compared against the presented identity (for		the presented identity (for example using procedures
	example using procedures described in		described in [I-D.saintandre-tls-server-id-check]).
	[I-D.saintandre-tls-server-id-check]).
	If the connection is being established for other reasons then		If the connection is being established for other reasons then
	configuration and procedures outside the scope of this		configuration and procedures outside the scope of this
	document should be followed.		document should be followed.
	(D)TLS provides assurance that the authenticated identity has		(D)TLS provides assurance that the authenticated identity has
	been signed by a trusted configured certificate authority.		been signed by a trusted configured certificate authority.
	If verification of the server's certificate fails in any way		If verification of the server's certificate fails in any way
	(for example because of failures in cryptographic		(for example because of failures in cryptographic
	verification or the presented identity did not match the		verification or the presented identity did not match the
	expected named entity) then the session establishment MUST		expected named entity) then the session establishment MUST
	fail, the snmpTlstmSessionInvalidServerCertificates object is		fail, the snmpTlstmSessionInvalidServerCertificates object is
	incremented and processing stops.		incremented and processing stops.
	4) The (D)TLS-specific session identifier is set in the sessionID of		4) The TLSTM-specific session identifier (tlstmSessionID) is set in
	the tmStateReference passed to the TLS Transport Model to		the sessionID of the tmStateReference passed to the TLS Transport
	indicate that the session has been established successfully and		Model to indicate that the session has been established
	to point to a specific (D)TLS session for future use.		successfully and to point to a specific (D)TLS session for future
			use.
	Servers that wish to support multiple principals at a particular port		Servers that wish to support multiple principals at a particular port
	SHOULD make use of the Server Name Indication extension defined in		SHOULD make use of the Server Name Indication extension defined in
	Section 3.1 of [RFC4366]. Supporting this will allow, for example,		Section 3.1 of [RFC4366]. Supporting this will allow, for example,
	sending notifications to a specific principal at a given TCP, UDP or		sending notifications to a specific principal at a given TCP, UDP or
	SCTP port.		SCTP port.
	5.4. Closing a Session		5.4. Closing a Session
	The TLS Transport Model provides the following primitive to close a		The TLS Transport Model provides the following primitive to close a
	skipping to change at page 29, line 44 ¶		skipping to change at page 30, line 6 ¶
	FROM SNMPv2-TC		FROM SNMPv2-TC
	MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP		MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
	FROM SNMPv2-CONF		FROM SNMPv2-CONF
	SnmpAdminString		SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB		FROM SNMP-FRAMEWORK-MIB
	snmpTargetParamsName, snmpTargetAddrName		snmpTargetParamsName, snmpTargetAddrName
	FROM SNMP-TARGET-MIB		FROM SNMP-TARGET-MIB
	;		;
	tlstmMIB MODULE-IDENTITY		tlstmMIB MODULE-IDENTITY
	LAST-UPDATED "200912230000Z"		LAST-UPDATED "200912300000Z"
	ORGANIZATION "ISMS Working Group"		ORGANIZATION "ISMS Working Group"
	CONTACT-INFO "WG-EMail: isms@lists.ietf.org		CONTACT-INFO "WG-EMail: isms@lists.ietf.org
	Subscribe: isms-request@lists.ietf.org		Subscribe: isms-request@lists.ietf.org
	Chairs:		Chairs:
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Campus Ring 1		Campus Ring 1
	28725 Bremen		28725 Bremen
	Germany		Germany
	skipping to change at page 30, line 44 ¶		skipping to change at page 31, line 4 ¶
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this MIB module is part of RFC XXXX;		This version of this MIB module is part of RFC XXXX;
	see the RFC itself for full legal notices."		see the RFC itself for full legal notices."
	-- NOTE to RFC editor: replace XXXX with actual RFC number		-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- for this document and remove this note		-- for this document and remove this note
			REVISION "200912300000Z"
	REVISION "200912230000Z"
	DESCRIPTION "The initial version, published in RFC XXXX."		DESCRIPTION "The initial version, published in RFC XXXX."
	-- NOTE to RFC editor: replace XXXX with actual RFC number		-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- for this document and remove this note		-- for this document and remove this note
	::= { snmpModules xxxx }		::= { snmpModules xxxx }
	-- RFC Ed.: replace xxxx with IANA-assigned number and		-- RFC Ed.: replace xxxx with IANA-assigned number and
	-- remove this note		-- remove this note
	-- ************************************************		-- ************************************************
	-- subtrees of the TLSTM-MIB		-- subtrees of the TLSTM-MIB
	skipping to change at page 51, line 30 ¶		skipping to change at page 51, line 37 ¶
	Implementations SHOULD limit the lifetime of established sessions		Implementations SHOULD limit the lifetime of established sessions
	depending on the algorithms used for generation of the master session		depending on the algorithms used for generation of the master session
	secret, the privacy and integrity algorithms used to protect		secret, the privacy and integrity algorithms used to protect
	messages, the environment of the session, the amount of data		messages, the environment of the session, the amount of data
	transferred, and the sensitivity of the data.		transferred, and the sensitivity of the data.
	8.2. Notification Receiver Credential Selection		8.2. Notification Receiver Credential Selection
	When an SNMP engine needs to establish an outgoing session for		When an SNMP engine needs to establish an outgoing session for
	notifications, the snmpTargetParamsTable includes an entry for the		notifications, the snmpTargetParamsTable includes an entry for the
	snmpTargetParamsSecurityName of the target. However, the receiving		snmpTargetParamsSecurityName of the target. Servers that wish to
	SNMP engine (Server) does not know which (D)TLS certificate to offer		support multiple principals at a particular port SHOULD make use of
	to the Client so that the tmSecurityName identity-authentication will		the Server Name Indication extension defined in Section 3.1 of
	be successful.		[RFC4366]. Without the Server Name Indication the receiving SNMP
			engine (Server) will not know which (D)TLS certificate to offer to
			the Client so that the tmSecurityName identity-authentication will be
			successful.
	One solution is to maintain a one-to-one mapping between certificates		Another solution is to maintain a one-to-one mapping between
	and incoming ports for notification receivers. This can be handled		certificates and incoming ports for notification receivers. This can
	at the notification originator by configuring the snmpTargetAddrTable		be handled at the notification originator by configuring the
	(snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the		snmpTargetAddrTable (snmpTargetAddrTDomain and
	receiving SNMP engine to monitor multiple incoming static ports based		snmpTargetAddrTAddress) and requiring the receiving SNMP engine to
	on which principals are capable of receiving notifications.		monitor multiple incoming static ports based on which principals are
			capable of receiving notifications.
	Implementations MAY also choose to designate a single Notification		Implementations MAY also choose to designate a single Notification
	Receiver Principal to receive all incoming notifications or select an		Receiver Principal to receive all incoming notifications or select an
	implementation specific method of selecting a server certificate to		implementation specific method of selecting a server certificate to
	present to clients.		present to clients.
	8.3. contextEngineID Discovery		8.3. contextEngineID Discovery
	Most command responders have contextEngineIDs that are identical to		Most command responders have contextEngineIDs that are identical to
	the USM securityEngineID. USM provides a discovery service that		the USM securityEngineID. USM provides a discovery service that
	skipping to change at page 56, line 51 ¶		skipping to change at page 57, line 14 ¶
	to publication.		to publication.
	11. Acknowledgements		11. Acknowledgements
	This document closely follows and copies the Secure Shell Transport		This document closely follows and copies the Secure Shell Transport
	Model for SNMP defined by David Harrington and Joseph Salowey in		Model for SNMP defined by David Harrington and Joseph Salowey in
	[RFC5292].		[RFC5292].
	This document was reviewed by the following people who helped provide		This document was reviewed by the following people who helped provide
	useful comments (in alphabetical order): Andy Donati, Pasi Eronen,		useful comments (in alphabetical order): Andy Donati, Pasi Eronen,
	David Harrington, Jeffrey Hutzelman, Alan Luchuk, Randy Presuhn, Ray		David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy
	Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield.		Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield.
	This work was supported in part by the United States Department of		This work was supported in part by the United States Department of
	Defense. Large portions of this document are based on work by		Defense. Large portions of this document are based on work by
	General Dynamics C4 Systems and the following individuals: Brian		General Dynamics C4 Systems and the following individuals: Brian
	Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John		Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
	Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,		Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
	Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.		Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
	12. References		12. References
End of changes. 21 change blocks.
	56 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/