< draft-ietf-ospf-dynamic-hostname-04.txt		draft-ietf-ospf-dynamic-hostname-05.txt >
	OSPF WG S. Venkata		OSPF WG S. Venkata
	Internet-Draft Google Inc.		Internet-Draft Google Inc.
	Intended status: Standards Track S. Harwani		Intended status: Standards Track S. Harwani
	Expires: December 19, 2009 C. Pignataro		Expires: January 13, 2010 C. Pignataro
	Cisco Systems		Cisco Systems
	D. McPherson		D. McPherson
	Arbor Networks, Inc.		Arbor Networks, Inc.
	June 17, 2009		July 12, 2009
	Dynamic Hostname Exchange Mechanism for OSPF		Dynamic Hostname Exchange Mechanism for OSPF
	draft-ietf-ospf-dynamic-hostname-04		draft-ietf-ospf-dynamic-hostname-05
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 December 19, 2009.		This Internet-Draft will expire on January 13, 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	This document defines a new OSPF Router Information (RI) TLV that		This document defines a new OSPF Router Information (RI) TLV that
	allows OSPF routers to flood their hostname-to-Router ID mapping		allows OSPF routers to flood their hostname-to-Router ID mapping
	information across an OSPF network to provide a simple and dynamic		information across an OSPF network to provide a simple and dynamic
	mechanism for routers running OSPF to learn about symbolic hostnames		mechanism for routers running OSPF to learn about symbolic hostnames
	just like for routers running IS-IS. This mechanism is applicable to		just like for routers running IS-IS. This mechanism is applicable to
	both OSPFv2 and OSPFv3.		both OSPFv2 and OSPFv3.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Specification of Requirements . . . . . . . . . . . . . . . 4		1.1. Specification of Requirements . . . . . . . . . . . . . . 4
	2. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 4		2. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 4
	3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 5		3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 6		3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 7
	3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . . 7		3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . 7
	4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 7		4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	OSPF uses a 32-bit Router ID to uniquely represent and identify a		OSPF uses a 32-bit Router ID to uniquely represent and identify a
	node in the network. For management and operational reasons, network		node in the network. For management and operational reasons, network
	operators need to check the status of OSPF adjacencies, entries in		operators need to check the status of OSPF adjacencies, entries in
	the routing table and the content of the OSPF link state database.		the routing table and the content of the OSPF link state database.
	It is obvious that, when looking at diagnostic information, numerical		When looking at diagnostic information, numerical representations of
	representations of Router IDs (e.g., dotted-decimal or hexadecimal		Router IDs (e.g., dotted-decimal or hexadecimal representations) are
	representations) are less clear to humans than symbolic names.		less clear to humans than symbolic names.
	One way to overcome this problem is to define a hostname-to-Router ID		One way to overcome this problem is to define a hostname-to-Router ID
	mapping table on a router. This mapping can be used bidirectionally		mapping table on a router. This mapping can be used bidirectionally
	(e.g., to find symbolic names for Router IDs, and to find Router IDs		(e.g., to find symbolic names for Router IDs, and to find Router IDs
	for symbolic names) or unidirectionally (e.g., to find symbolic		for symbolic names) or unidirectionally (e.g., to find symbolic
	hostnames for Router IDs). Thus every router has to maintain a table		hostnames for Router IDs). Thus every router has to maintain a table
	with mappings between router names and Router IDs.		with mappings between router names and Router IDs.
	These tables need to contain all names and Router IDs of all routers		These tables need to contain all names and Router IDs of all routers
	in the network. If these mapping tables are built by static		in the network. If these mapping tables are built by static
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	One way to build this table of mappings is by static definitions.		One way to build this table of mappings is by static definitions.
	The problem with static definitions is that the network administrator		The problem with static definitions is that the network administrator
	needs to keep updating the mapping entries manually as the network		needs to keep updating the mapping entries manually as the network
	changes; this approach does not scale as the network grows, since		changes; this approach does not scale as the network grows, since
	there needs to be an entry in the mapping table for each and every		there needs to be an entry in the mapping table for each and every
	router in the network, on every router in the network. Thus, this		router in the network, on every router in the network. Thus, this
	approach greatly suffers from maintainability and scalability		approach greatly suffers from maintainability and scalability
	considerations.		considerations.
	Another approach is having a centralized location where the name-to-		Another approach is having a centralized location where the name-to-
	Router ID mapping can be kept. DNS can be used for the same. A		Router ID mapping can be kept. The DNS could be used for this. A
	disadvantage with this centralized solution is that it is a single		disadvantage with this centralized solution is that it is a single
	point of failure; and although enhanced availability of the central		point of failure; and although enhanced availability of the central
	mapping service can be designed, it may not be able to resolve the		mapping service can be designed, it may not be able to resolve the
	hostname in the event of reachability or network problems, which can		hostname in the event of reachability or network problems, which can
	be particularly problematic in times of problem resolution. Also,		be particularly problematic in times of problem resolution. Also,
	the response time can be an issue with the centralized solution,		the response time can be an issue with the centralized solution,
	which can be equally problematic. If DNS is used as the centralized		which can be equally problematic. If the DNS is used as the
	mapping table, a network operator may desire a different name mapping		centralized mapping table, a network operator may desire a different
	than the existing in the DNS, or new routers may not yet be in DNS.		name mapping than the existing mapping in the DNS, or new routers may
			not yet be in the DNS.
	Additionally for OSPFv3, in native IPv6 deployments, the 32-bit		Additionally for OSPFv3, in native IPv6 deployments, the 32-bit
	Router ID value will not map to IPv4-addressed entities in the		Router ID value will not map to IPv4-addressed entities in the
	network, nor will it be DNS resolvable (see Section 4).		network, nor will it be DNS resolvable (see Section 4).
	The third solution that we have defined in this document is to make		The third solution that we have defined in this document is to make
	use of the protocol itself to carry the name-to-Router ID mapping in		use of the protocol itself to carry the name-to-Router ID mapping in
	a TLV. Routers that understand this TLV can use it to create the		a TLV. Routers that understand this TLV can use it to create the
	symbolic name-to-Router ID mapping and Routers who don't understand		symbolic name-to-Router ID mapping and Routers that don't understand
	can simply ignore it. This specification provides these semantics		can simply ignore it. This specification provides these semantics
	and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF		and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF
	Router Information (RI) LSA ([RFC4970]).		Router Information (RI) Link State Advertisement (LSA) ([RFC4970]).
	3. Implementation		3. Implementation
	This extension makes use of the Router Information (RI) Opaque LSA		This extension makes use of the Router Information (RI) Opaque LSA
	defined in [RFC4970] for both OSPFv2 and OSPFv3, by defining a new		defined in [RFC4970] for both OSPFv2 and OSPFv3, by defining a new
	OSPF Router Information (RI) TLV: The Dynamic Hostname TLV.		OSPF Router Information (RI) TLV: The Dynamic Hostname TLV.
	The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt		The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt
	of the TLV a router may decide to ignore this TLV, or to install the		of the TLV a router may decide to ignore this TLV, or to install the
	symbolic name and Router ID in its hostname mapping table.		symbolic name and Router ID in its hostname mapping table.
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 16 ¶
	The format of Dynamic Hostname TLV is as follows:		The format of Dynamic Hostname TLV is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hostname ... |		| Hostname ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type Dynamic Hostname TLV Type (TBD, see Section 6)		Type Dynamic Hostname TLV Type (TBD, see Section 6)
	Length Total length of the hostname (value field) in octets, not		Length Total length of the hostname (value field) in octets, not
	including the optional padding.		including the optional padding.
	Value Hostname, a string of 1 to 255 octets, padded to 4-octet		Value Hostname, a string of 1 to 255 octets, padded with zeroes to
	alignment, encoded in the US-ASCII charset.		4-octet alignment, encoded in the US-ASCII charset.
	Routers that do not recognize the Dynamic Hostname TLV Type, ignore		Routers that do not recognize the Dynamic Hostname TLV Type, ignore
	the TLV (see [RFC4970]).		the TLV (see [RFC4970]).
	The value field identifies the symbolic hostname of the router		The value field identifies the symbolic hostname of the router
	originating the LSA. This symbolic name can be the FQDN for the		originating the LSA. This symbolic name can be the Fully Qualified
	router, it can be a subset of the FQDN, or it can be any string		Domain Name (FQDN) for the Router ID, it can be a subset of the FQDN,
	operators want to use for the router. The use of FQDN or a subset of		or it can be any string operators want to use for the router. The
	it is strongly recommended. The content of this value is a domain		use of FQDN or a subset of it is strongly recommended since it can be
	name, see [RFC2181]. The string is not null-terminated. The Router		beneficial to correlate the OSPF dynamic hostname and the DNS
	ID of this router is derived from the LSA header, in the Advertising		hostname. The format of the DNS hostname is described in [RFC1035]
	Router field of the Router Information (RI) Opaque LSA.		and [RFC2181]. If there is no DNS hostname for the Router ID, the
			Router ID does not map to an IPv4-addressed entity (e.g., see
			Section 4), or an alternate OSPF dynamic hostname naming convention
			is desired, any string with significance in the OSPF routing domain
			can be used. The string is not null-terminated. The Router ID of
			this router is derived from the LSA header, in the Advertising Router
			field of the Router Information (RI) Opaque LSA.
	The Value field is encoded in 7-bit ASCII. If a user-interface for		The Value field is encoded in 7-bit ASCII. If a user-interface for
	configuring or displaying this field permits Unicode characters, that		configuring or displaying this field permits Unicode characters, that
	user-interface is responsible for applying the ToASCII and/or		user-interface is responsible for applying the ToASCII and/or
	ToUnicode algorithm as described in [RFC3490] to achieve the correct		ToUnicode algorithm as described in [RFC3490] to achieve the correct
	format for transmission or display.		format for transmission or display.
	The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3.		The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3.
	3.1.1. Flooding Scope		3.1.1. Flooding Scope
	The Dynamic Hostname TLV MAY be advertised within an area-local or AS		The Dynamic Hostname TLV MAY be advertised within an area-local or
	scope Router Information (RI) LSA. But the Dynamic Hostname TLV		autonomous system (AS) scope Router Information (RI) LSA. But the
	SHOULD NOT be advertised into an area in more than one RI LSA		Dynamic Hostname TLV SHOULD NOT be advertised into an area in more
	irrespective of the scope of the LSA.		than one RI LSA irrespective of the scope of the LSA.
	In other words, if a router originates a Dynamic Hostname TLV with an		In other words, if a router originates a Dynamic Hostname TLV with an
	IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped		IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped
	Dynamic Hostname TLV except into any attached Not-So-Stubby Area		Dynamic Hostname TLV except into any attached Not-So-Stubby Area
	(NSSA) area(s). Similarly, if a router originates area-scoped		(NSSA) area(s). Similarly, if a router originates area-scoped
	Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT		Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT
	send AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname TLV		send AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname TLV
	is advertised in more than one LSA (e.g., multiple area-scoped LSAs,		is advertised in more than one LSA (e.g., multiple area-scoped LSAs,
	or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname SHOULD		or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname SHOULD
	be the same.		be the same.
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 30 ¶
	5. Security Considerations		5. Security Considerations
	Since the hostname-to-Router ID mapping relies on information		Since the hostname-to-Router ID mapping relies on information
	provided by the routers themselves, a misconfigured or compromised		provided by the routers themselves, a misconfigured or compromised
	router can inject false mapping information, including a duplicate		router can inject false mapping information, including a duplicate
	hostname for different Router IDs. Thus, this information needs to		hostname for different Router IDs. Thus, this information needs to
	be treated with suspicion when, for example, doing diagnostics about		be treated with suspicion when, for example, doing diagnostics about
	a suspected security incident.		a suspected security incident.
			There is potential confusion from name collisions if two routers use
			and advertise the same Dynamic Hostname. Name conflicts are not
			crucial and therefore there is no generic conflict detection or
			resolution mechanism in the protocol. However, a router that detects
			that a received hostname is the same as the local one can issue a
			notification or a management alert.
			The use of the FQDN as OSPF dynamic hostname potentially exposes
			geographic or other commercial information that can be deduced from
			the hostname when sent in the clear. OSPFv3 supports confidentiality
			via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated
			over IPsec tunnels if confidentiality is required.
	This document raises no other new security issues for OSPF. Security		This document raises no other new security issues for OSPF. Security
	considerations for the base OSPF protocol are covered in [RFC2328]		considerations for the base OSPF protocol are covered in [RFC2328]
	and [RFC5340]. The use of authentication for the OSPF routing		and [RFC5340]. The use of authentication for the OSPF routing
	protocols is encouraged.		protocols is encouraged.
	6. IANA Considerations		6. IANA Considerations
	IANA maintains the "OSPF Router Information (RI) TLVs" registry		IANA maintains the "OSPF Router Information (RI) TLVs" registry
	reachable at [IANA-RI]. An additional OSPF Router Information TLV		reachable at [IANA-RI]. An additional OSPF Router Information TLV
	Type is defined in Section 3. It is required to be assigned by IANA		Type is defined in Section 3. It is required to be assigned by IANA
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 22 ¶
	Registry Name: OSPF Router Information (RI) TLVs		Registry Name: OSPF Router Information (RI) TLVs
	Type Value Capabilities Reference		Type Value Capabilities Reference
	----------- -------------------------------------- ---------		----------- -------------------------------------- ---------
	TBD OSPF Dynamic Hostname This document		TBD OSPF Dynamic Hostname This document
	7. Acknowledgments		7. Acknowledgments
	The authors of this document do not make any claims on the		The authors of this document do not make any claims on the
	originality of the ideas described. This document adapts format and		originality of the ideas described. This document adapts format and
	text from similar work done in IS-IS [RFC2763]; we would like to		text from similar work done in IS-IS [RFC5301] (obsoletes [RFC2763]);
	thank Naiming Shen and and Henk Smit, authors of that document.		we would like to thank Naiming Shen and and Henk Smit, authors of
			[RFC2763].
	The authors would also like to thank Acee Lindem, Abhay Roy, Anton		The authors would also like to thank Acee Lindem, Abhay Roy, Anton
	Smirnov, and Dave Ward for their valuable comments and suggestions.		Smirnov, and Dave Ward for their valuable comments and suggestions.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 46 ¶
	[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.		[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
	Shaffer, "Extensions to OSPF for Advertising Optional		Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 4970, July 2007.		Router Capabilities", RFC 4970, July 2007.
	8.2. Informative References		8.2. Informative References
	[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path		[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path
	First v2 (OSPFv2) Parameters", April 2009,		First v2 (OSPFv2) Parameters", April 2009,
	<http://www.iana.org/assignments/ospfv2-parameters>.		<http://www.iana.org/assignments/ospfv2-parameters>.
			[RFC1035] Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, November 1987.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, July 1997.		Specification", RFC 2181, July 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism		[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
	for IS-IS", RFC 2763, February 2000.		for IS-IS", RFC 2763, February 2000.
	[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,		[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)",		"Internationalizing Domain Names in Applications (IDNA)",
	RFC 3490, March 2003.		RFC 3490, March 2003.
			[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
			for OSPFv3", RFC 4552, June 2006.
			[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
			Mechanism for IS-IS", RFC 5301, October 2008.
	[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, July 2008.		for IPv6", RFC 5340, July 2008.
	Authors' Addresses		Authors' Addresses
	Subbaiah Venkata		Subbaiah Venkata
	Google Inc.		Google Inc.
	Email: svenkata@google.com		Email: svenkata@google.com
	URI: http://www.google.com		URI: http://www.google.com
End of changes. 18 change blocks.
	43 lines changed or deleted		74 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/