draft-ietf-ecrit-dhc-lost-discovery-02.txt		draft-ietf-ecrit-dhc-lost-discovery-03.txt
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track J. Polk		Intended status: Standards Track J. Polk
	Expires: January 9, 2008 Cisco		Expires: November 30, 2008 Cisco
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	July 8, 2007		May 29, 2008
	A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service		A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service
	Translation Protocol (LoST) Discovery Procedure		Translation Protocol (LoST) Discovery Procedure
	draft-ietf-ecrit-dhc-lost-discovery-02.txt		draft-ietf-ecrit-dhc-lost-discovery-03.txt
	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 38		skipping to change at page 1, line 38
	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 January 9, 2008.		This Internet-Draft will expire on November 30, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Location-to-Service Translation Protocol (LoST) describes an XML-		The Location-to-Service Translation Protocol (LoST) describes an XML-
	based protocol for mapping service identifiers and geospatial or		based protocol for mapping service identifiers and geospatial or
	civic location information to service contact Uniform Resource		civic location information to service contact Uniform Resource
	Locators (URLs). LoST servers can be located anywhere but a		Locators (URLs). LoST servers can be located anywhere but a
	placement closer to the end host, e.g., in the access network, is		placement closer to the end host, e.g., in the access network, is
	desireable. Such a LoST server placement provides benefits in		desireable. Such a LoST server placement provides benefits in
	disaster situations with intermittent network connectivity regarding		disaster situations with intermittent network connectivity regarding
	skipping to change at page 2, line 18		skipping to change at page 2, line 14
	This document describes how a LoST client can discover a LoST server		This document describes how a LoST client can discover a LoST server
	using the Dynamic Host Configuration Protocol (DHCP).		using the Dynamic Host Configuration Protocol (DHCP).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3		3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3
	4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4		4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4
	5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 4		5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 5
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. IANA Consideration for DHCPv4 Option . . . . . . . . . . . 6		7.1. IANA Consideration for DHCPv4 Option . . . . . . . . . . . 6
	7.2. IANA Consideration for DHCPv6 Option . . . . . . . . . . . 6		7.2. IANA Consideration for DHCPv6 Option . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	10.2. Informative References . . . . . . . . . . . . . . . . . . 7		10.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Location-to-Service Translation Protocol (LoST)		The Location-to-Service Translation Protocol (LoST)
	[I-D.ietf-ecrit-lost] describes an XML-based protocol for mapping		[I-D.ietf-ecrit-lost] describes an XML-based protocol for mapping
	service identifiers and geospatial or civic location information to		service identifiers and geospatial or civic location information to
	service contact Uniform Resource Locators (URLs).		service contact Uniform Resource Locators (URLs).
	In order to interact with a LoST server, the LoST client finally		In order to interact with a LoST server, the LoST client eventually
	needs to know its IP address. Several mechanisms can be used to		needs to discover the server's IP address. Several mechanisms can be
	learn this address, including manual configuration. In environments		used to learn this address, including manual configuration. In
	where the access network itself either deploys a LoST server or knows		environments where the access network itself either deploys a LoST
	a third party that operates a LoST server DHCP can provide the end		server or knows a third party that operates a LoST server, DHCP can
	host with a domain name. This domain name is then used as input to		provide the end host with a domain name. This domain name is then
	the DNS-based resolution mechanism described in LoST		used as input to the DNS-based resolution mechanism described in LoST
	[I-D.ietf-ecrit-lost] that reuses the URI-enabled NAPTR specification		[I-D.ietf-ecrit-lost] that reuses the URI-enabled NAPTR specification
	(see [RFC4848]).		(see [RFC4848]).
	This document specifies a DHCPv4 and a DHCPv6 option that allows LoST		This document specifies a DHCPv4 and a DHCPv6 option that allows LoST
	clients to discover local LoST servers.		clients to discover local LoST servers.
	Section 2 provides terminology. Section 4 describes the DHCPv4		Section 2 provides terminology. Section 3 shows the encoding of the
	option while Section 5 describes the DHCPv6 option, with the same		domain name. Section 4 describes the DHCPv4 option while Section 5
	functionality. IANA and Security Considerations complete the		describes the DHCPv6 option, with the same functionality. IANA and
	document in Section 7 and Section 8.		Security Considerations complete the document in Section 7 and
			Section 8.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119		and "OPTIONAL" are to be interpreted as described in RFC 2119
	[RFC2119].		[RFC2119].
	Within this document, we use terminology from		Within this document, we use terminology from [RFC5012] and
	[I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-lost].		[I-D.ietf-ecrit-lost].
	3. Domain Name Encoding		3. Domain Name Encoding
	This section describes the encoding of the domain name used in the		This section describes the encoding of the domain name used in the
	DHCPv4 option shown in Section 4 and also used in the DHCPv6 option		DHCPv4 option shown in Section 4 and also used in the DHCPv6 option
	shown in Section 5.		shown in Section 5.
	The domain name is encoded according to Section 3.1 of RFC 1035		The domain name is encoded according to Section 3.1 of RFC 1035
	[RFC1035] whereby each label is represented as a one octet length		[RFC1035] whereby each label is represented as a one octet length
	field followed by that number of octets. The domain name ends with		field followed by that number of octets. Since every domain name
	the null label of the root, a domain name is terminated by a length		ends with the null label of the root, a domain name is terminated by
	byte of zero. The high order two bits of every length octet MUST be		a length byte of zero. The high order two bits of every length octet
	zero, and the remaining six bits of the length field limit the label		MUST be zero, and the remaining six bits of the length field limit
	to 63 octets or less. To simplify implementations, the total length		the label to 63 octets or less. To simplify implementations, the
	of a domain name (i.e., label octets and label length octets) is		total length of a domain name (i.e., label octets and label length
	restricted to 255 octets or less.		octets) is restricted to 255 octets or less.
	For DHCPv4 only: If the length of the domain name exceeds the
	maximum permissible within a single option (i.e., 254 octets), then
	the domain name MUST be represented in the DHCP message as specified
	in [RFC3396].
	4. LoST Server DHCPv4 Option		4. LoST Server DHCPv4 Option
	The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035])		The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035])
	fully-qualified domain name to be used by the LoST client to locate a		fully-qualified domain name to be used by the LoST client to locate a
	LoST server.		LoST server.
	The DHCP option for this encoding has the following format:		The DHCP option for this encoding has the following format:
	Code Len LoST Server Domain Name		Code Len LoST Server Domain Name
	+-----+-----+-----+-----+-----+-----+-----+----		+-----+-----+-----+-----+-----+-----+-----+----
	| TBD | n | s1 | s2 | s3 | s4 | s5 | ...		| TBD1| n | s1 | s2 | s3 | s4 | s5 | ...
	+-----+-----+-----+-----+-----+-----+-----+----		+-----+-----+-----+-----+-----+-----+-----+----
	Figure 1: LoST FQDN DHCPv4 Option		Figure 1: LoST FQDN DHCPv4 Option
			The values s1, s2, s3, etc. represent the domain name labels in the
			domain name encoding. Note that the length field in the DHCPv4
			option represents the length of the entire domain name encoding,
			whereas the length fields in the domain name encoding (see Section 3)
			is the length of a single domain name label.
	Code: OPTION_V4_LOST (TBD1)		Code: OPTION_V4_LOST (TBD1)
	Len: Length of the 'LoST Server Domain Name' field		Len: Length of the 'LoST Server Domain Name' field
	in octets; variable.		in octets; variable.
	LoST server Domain Name: The domain name of the LoST		LoST server Domain Name: The domain name of the LoST
	server for the client to use.		server for the client to use.
			A DHCPv4 client MAY request a LoST server domain name in an Parameter
			Request List option, as described in [RFC2131].
	The encoding of the domain name is described in Section 3.		The encoding of the domain name is described in Section 3.
	Only a single domain name MUST be present in the DHCPv4 option.		This option contains a single doamin name, and as such MUST contain
			precisely one root label.
	5. LoST Server DHCPv6 Option		5. LoST Server DHCPv6 Option
	This document defines a DHCPv6 options to carry a domain name.		This section defines a DHCPv6 option to carry a domain name.
	The DHCPv6 option has the format shown in Figure 3.		The DHCPv6 option has the format shown in Figure 2.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OPTION_V6_LOST | option-length |		| OPTION_V6_LOST | option-length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LoST Server Domain Name |		| LoST Server Domain Name |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: DHCPv6 Option for LoST Server Domain Name List		Figure 2: DHCPv6 Option for LoST Server Domain Name List
	option-code: OPTION_V6_LOST (TBD2)		option-code: OPTION_V6_LOST (TBD2)
	option-length: Length of the 'LoST Server Domain Name' field		option-length: Length of the 'LoST Server Domain Name' field
	in octets; variable.		in octets; variable.
	LoST server Domain Name: The domain name of the LoST		LoST server Domain Name: The domain name of the LoST
	server for the client to use.		server for the client to use.
	A DHCPv6 client MAY request a LoST server domain name in an Options		A DHCPv6 client MAY request a LoST server domain name in an Options
	Request Option (ORO), as described in [RFC3315].		Request Option (ORO), as described in [RFC3315].
	A DHCPv4 client MAY request a LoST server domain name in an Parameter
	Request List option, as described in [RFC2131].
	The encoding of the domain name is described in Section 3.		The encoding of the domain name is described in Section 3.
	Only a single domain name MUST be present in the DHCPv6 option.		This option contains a single doamin name, and as such MUST contain
			precisely one root label.
	6. Example		6. Example
	This section shows an example of a DHCPv4 option where the DHCP		This section shows an example of a DHCPv4 option where the DHCP
	server wants to offer the "example.com" domain name to the client as		server wants to offer the "example.com" domain name to the client as
	input to the U-NAPTR LoST discovery procedure. This domain name		input to the U-NAPTR LoST discovery procedure. This domain name
	would be encoded as follows:		would be encoded as follows:
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	|TBD|13 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |		|TBD1|13 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	Figure 5: Example for a LoST FQDN DHCPv4 Option		Figure 3: Example for a LoST FQDN DHCPv4 Option
	7. IANA Considerations		7. IANA Considerations
	7.1. IANA Consideration for DHCPv4 Option		7.1. IANA Consideration for DHCPv4 Option
	The following DHCPv4 option code for the Location-to-Service		The following DHCPv4 option code for the Location-to-Service
	Translation Protocol (LoST) server option must be assigned by IANA:		Translation Protocol (LoST) server option must be assigned by IANA:
	Option Name Value Described in		Option Name Value Described in
	-----------------------------------------------		-----------------------------------------------
	OPTION_V4_LOST TBD Section 4		OPTION_V4_LOST TBD1 Section 4
	7.2. IANA Consideration for DHCPv6 Option		7.2. IANA Consideration for DHCPv6 Option
	IANA is requested to assign the following DHCPv6 option codes for the		IANA is requested to assign the following DHCPv6 option codes for the
	Location-to-Service Translation Protocol (LoST) options:		Location-to-Service Translation Protocol (LoST) options:
	Option Name Value Described in		Option Name Value Described in
	------------------------------------------------		------------------------------------------------
	OPTION_V6_LOST TBD Section 5		OPTION_V6_LOST TBD2 Section 5
	8. Security Considerations		8. Security Considerations
	If an adversary manages to modify the response from a DHCP server or		If an adversary manages to modify the response from a DHCP server or
	insert its own response, a LoST client could be led to contact a		insert its own response, a LoST client could be led to contact a
	rogue LoST server under the control of the adversary or be given an		rogue LoST server under the control of the adversary or be given an
	invalid address. These threats are documented in		invalid address. These threats are documented in [RFC5069]. The
	[I-D.ietf-ecrit-security-threats]. The security considerations in		security considerations in [RFC2131], [RFC2132] and [RFC3315] are
	[RFC2131], [RFC2132] and [RFC3315] are applicable to this document.		applicable to this document.
			With respect to the LoST security mechanisms please refer to
			[I-D.ietf-ecrit-lost].
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Andrew Newton and Leslie Daigle for		The authors would like to thank Andrew Newton and Leslie Daigle for
	their draft review. We would like to particularly thank Andrew		their draft review and Andy for the proposed simplifications.
	Newton for the simplifications he proposed.
	Mark Stapp did the document review of this document for the DHC		Mark Stapp and David W. Hankins did the document review for the DHC
	working group as part of the joint working group last call.		working group as part of the joint working group last call.
			We would like to thank Vijay K. Gurbani for the Gen-ART review.
			Furthermore, we would like to thank Russ Housley, Tim Polk, Jari
			Arkko, and Christian Vogt.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	skipping to change at page 7, line 33		skipping to change at page 7, line 35
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the		[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
	Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,		Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
	November 2002.		November 2002.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ecrit-lost]		[I-D.ietf-ecrit-lost]
	Hardie, T., "LoST: A Location-to-Service Translation		Hardie, T., Newton, A., Schulzrinne, H., and H.
	Protocol", draft-ietf-ecrit-lost-05 (work in progress),		Tschofenig, "LoST: A Location-to-Service Translation
	March 2007.		Protocol", draft-ietf-ecrit-lost-10 (work in progress),
			May 2008.
	[I-D.ietf-ecrit-requirements]
	Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",
	draft-ietf-ecrit-requirements-13 (work in progress),
	March 2007.
	[I-D.ietf-ecrit-security-threats]
	Taylor, T., "Security Threats and Requirements for
	Emergency Call Marking and Mapping",
	draft-ietf-ecrit-security-threats-04 (work in progress),
	April 2007.
	[RFC4848] Daigle, L., "Domain-Based Application Service Location		[RFC4848] Daigle, L., "Domain-Based Application Service Location
	Using URIs and the Dynamic Delegation Discovery Service		Using URIs and the Dynamic Delegation Discovery Service
	(DDDS)", RFC 4848, April 2007.		(DDDS)", RFC 4848, April 2007.
			[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
			Emergency Context Resolution with Internet Technologies",
			RFC 5012, January 2008.
			[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
			Shanmugam, "Security Threats and Requirements for
			Emergency Call Marking and Mapping", RFC 5069,
			January 2008.
	Authors' Addresses		Authors' Addresses
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	skipping to change at page 8, line 28		skipping to change at page 8, line 28
	James Polk		James Polk
	Cisco		Cisco
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082		Richardson, Texas 75082
	US		US
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Phone: +49 89 636 40390		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.priv.at
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 9, line 44		skipping to change at line 369
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 33 change blocks.
	76 lines changed or deleted		80 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/