draft-ietf-grow-geomrt-00.txt		draft-ietf-grow-geomrt-01.txt
	Global Routing Operations Working T. Manderson		Global Routing Operations Working T. Manderson
	Group ICANN		Group ICANN
	Internet-Draft September 8, 2010		Internet-Draft December 14, 2010
	Intended status: Informational		Intended status: Informational
	Expires: March 12, 2011		Expires: June 17, 2011
	MRT BGP routing information export format with geo-location extensions		MRT BGP routing information export format with geo-location extensions
	draft-ietf-grow-geomrt-00.txt		draft-ietf-grow-geomrt-01.txt
	Abstract		Abstract
	This document extends the Border Gateway Protocol (BGP) MRT export		This document extends the Border Gateway Protocol (BGP) MRT export
	format for routing information to include terrestrial coordinates.		format for routing information to include terrestrial coordinates.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on March 12, 2011.		This Internet-Draft will expire on June 17, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Geo-location aware MRT Routing Information Type . . . . . . . 5		3. Geo-location aware MRT Routing Information Subtype . . . . . . 5
	4. TABLE_DUMP_v2+GEO Type . . . . . . . . . . . . . . . . . . . . 6		3.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 5
	5. Implementation Note . . . . . . . . . . . . . . . . . . . . . 9		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Research is underway that analyzes the network behavior of routing		Research is underway that analyzes the network behavior of routing
	protocol transactions from routing information base snapshots in		protocol transactions from routing information base snapshots in
	relation to geographical coordinates. Specifically the BGP routing		relation to geographical coordinates. Specifically the BGP routing
	protocol is the subject of study and the analysis has been		protocol is the subject of study and the analysis has been
	significantly aided by the availability and extension of the "MRT		significantly aided by the availability and extension of the "MRT
	format" [I-D.ietf-grow-mrt] originally defined in the MRT		format" [I-D.ietf-grow-mrt] originally defined in the MRT
	Programmer's Guide [MRT PROG GUIDE].		Programmer's Guide [MRT PROG GUIDE].
	This memo documents an extension to the "MRT format"		This memo documents an extension to the "MRT format"
	[I-D.ietf-grow-mrt] and introduces an additional definition of a MRT		[I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
	Type field and related Subtype fields.		Subtype field.
	3. Geo-location aware MRT Routing Information Type
	The following additional Type is defined for the TABLE_DUMP_v2+GEO
	format, which extends the TABLE_DUMP_V2 type.
	[TYPE NUMBER] TABLE_DUMP_v2+GEO		3. Geo-location aware MRT Routing Information Subtype
	The TYPE NUMBER, an FCFS entry from the future IANA MRT registry is		The additional Subtype is defined for the TABLE_DUMP_v format, which
	yet to be assigned.		extends the TABLE_DUMP_V2 type.
	4. TABLE_DUMP_v2+GEO Type		3.1. GEO_PEER_TABLE
	The TABLE_DUMP_v2+GEO Type updates the TABLE_DUMP_v2 Type to include		The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include
	Geo-location information in the form of WGS84 [WGS 84] formatted		Geo-location information in the form of WGS84 [WGS 84] formatted
	coordinates. The following subtypes as used with the TABLE_DUMP_V2		coordinates. The MRT subtypes would be as follows.
	Type, are used in the TABLE_DUMP_v2+GEO Type and their formats have
	been augmented to include the WGS84 coordinates.
	1 PEER_INDEX_TABLE		1 PEER_INDEX_TABLE
	2 RIB_IPV4_UNICAST		2 RIB_IPV4_UNICAST
	3 RIB_IPV4_MULTICAST		3 RIB_IPV4_MULTICAST
	4 RIB_IPV6_UNICAST		4 RIB_IPV6_UNICAST
	5 RIB_IPV6_MULTICAST		5 RIB_IPV6_MULTICAST
	6 RIB_GENERIC		6 RIB_GENERIC
			7 GEO_PEER_TABLE
	The extended PEER_INDEX_TABLE MRT record provides the BGP ID of the		The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
	collector, the latitude and longitude in WGS84 [WGS 84] format, an		Its latitude and longitude in WGS84 [WGS 84] format, and a list of
	optional view name, and a list of indexed peers.		indexed peers.
	The format and function of the Collector BGP ID, the View Name Length		The format and function of the Collector BGP ID, Peer Count are as
	and View Name, Peer Count are as defined by the TABLE_DUMP_V2 MRT		defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format.
	format [I-D.ietf-grow-mrt].		[I-D.ietf-grow-mrt].
	The Collector Latitude and Collector Longitude are the geographical		The Collector Latitude and Collector Longitude are the geographical
	coordinates of the collector in WGS84 [WGS 84] datum decimal degrees		coordinates of the collector in WGS84 [WGS 84] datum decimal degrees
	format stored as a single precision float in the 32 bits allocated to		format stored as a single precision float in the 32 bits allocated to
	the Latitude and Longitude.		the Collector Latitude and Collector Longitude. The latitude and
			longitude may be a Not A Number (NAN) for situations where the geo-
	0 1 2 3		location of the collector is considered private. The Collector
	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		Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84]
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		datum coordinate and NAN values.
	| Collector BGP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Collector Latitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Collector Longitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| View Name Length | View Name (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The format of the peer entries is shown below. The PEER_INDEX_TABLE
	record contains Peer Count peer entries.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Type |		| Collector BGP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer BGP ID |		| Collector Latitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Collector Longitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS (variable) |		| Peer Count | Peer entries (variable)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Latitude |		The format of the peer entries is shown below. The Peer Type and the
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT
	| Peer Longitude |		[I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		entries in GEO_PEER_TABLE MUST match the order and number as existing
			in the PEER_INDEX_TABLE.
	The Peer Type, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer		0 1 2 3
	Longitude fields are repeated as indicated by the Peer Count field.		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
	The position of the Peer in the PEER_INDEX_TABLE is used as an index		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number		| Peer Type |
	begins with 0.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Peer BGP ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Peer Latitude |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Peer Longitude |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Peer Latitude and Peer Longitude are the geographical coordinates		The Peer Latitude and Peer Longitude are the geographical coordinates
	of the collector in WGS84 [WGS 84] datum decimal degrees format		of the peer in WGS84 [WGS 84] datum decimal degrees format stored as
	stored as a single precision float in the 32 bits allocated to the		a single precision float in the 32 bits allocated to the Peer
	Latitude and Longitude.		Latitude and Peer Longitude. The latitude and longitude may be a Not
			A Number (NAN) for situations where the geo-location of the peer is
	The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT		considered private. The Peer Latitude and Peer Longitude MUST NOT be
	format [I-D.ietf-grow-mrt].		a mix of WGS84 [WGS 84] datum coordinate and NAN values for a single
			Peer.
	The records which follow the PEER_INDEX_TABLE record constitute the
	RIB entries and their formats remain unchanged from TABLE_DUMP_V2+
	GEO.
	That is the common format for the RIB_IPV4_UNICAST,
	RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains
	as defined for TABLE_DUMP_V2 and the header is shown below for
	informational purposes only.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Prefix (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Entry Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Similarly the the RIB_GENERIC format is unchanged and is shown here:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address Family Identifier |Subsequent AFI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Network Layer Reachability Information (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Entry Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The RIB entries that follow the RIB entry headers are also unchanged
	from MRT [I-D.ietf-grow-mrt]:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Index |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originated Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attribute Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BGP Attributes... (variable)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5. Implementation Note
	In implementation of the formats above where a Collector has an
	assigned Latitude and Longitude but a Peer does not. It is currently
	recommended that the Collector's coordinates are replicated in the
	Peer's Latitude and Longitude. The inquiring researcher can then
	make the decision on the interpretation of the routes 'as seen' at
	those coordinates, or disregard any geographical information for the
	peer based on the comparison of the Collector and Peer coordinates.
	The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's
	Latitude and Longitude have not been defined.
	6. Acknowledgements		4. Acknowledgements
	Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, and		Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard
	Jeffrey Haas for reviewing this document.		Barnes, and Jeffrey Haas for reviewing this document.
	This document describes a small portion of the research towards the		This document describes a small portion of the research towards the
	author's PhD.		author's PhD.
	7. IANA Considerations		5. IANA Considerations
	This section requests the Internet Assigned Numbers Authority (IANA)		This section requests the Internet Assigned Numbers Authority (IANA)
	register the Type code values (as FCFS as defined in the "MRT format"		register the additional Subtype code value as:
	[I-D.ietf-grow-mrt] and Subtype code values related to the
	TABLE_DUMP_v2+GEO type as an entry in the MRT namespaces, in
	accordance with BCP 26, RFC 5226 [RFC5226].
	8. Security Considerations		7 GEO_PEER_TABLE
			in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values
			related to the TABLE_DUMP_v2 type in the MRT namespace, in accordance
			with BCP 26, RFC 5226 [RFC5226].
			6. Security Considerations
	This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields		This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields
	that are of a descriptive nature and provide information that is		that are of a descriptive nature and provide information that is
	useful in the analysis of routing systems. As such, the author		useful in the analysis of routing systems. As such, the author
	believes that they do not constitute an additional security risk.		believes that they do not constitute an additional security risk. It
			is recommended that the operators of the BGP collector and Peers
			consider their own privacy concerns before supplying geographical
			coordinates in MRT dumps.
	9. References		7. References
	9.1. Normative References		7.1. Normative References
	[I-D.ietf-grow-mrt]		[I-D.ietf-grow-mrt]
	Blunk, L., Karir, M., and C. Labovitz, "MRT routing		Blunk, L., Karir, M., and C. Labovitz, "MRT routing
	information export format", draft-ietf-grow-mrt-11 (work		information export format", draft-ietf-grow-mrt-13 (work
	in progress), March 2010.		in progress), September 2010.
	[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.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	9.2. Informative References		7.2. Informative References
	[MRT PROG GUIDE]		[MRT PROG GUIDE]
	Labovitz, C., "MRT Programmer's Guide", November 1999,		Labovitz, C., "MRT Programmer's Guide", November 1999,
	<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.		<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
	[WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic		[WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic
	System 1984", January 2000, <http://earth-info.nga.mil/		System 1984", January 2000, <http://earth-info.nga.mil/
	GandG/publications/tr8350.2/wgs84fin.pdf>.		GandG/publications/tr8350.2/wgs84fin.pdf>.
	Author's Address		Author's Address
End of changes. 28 change blocks.
	155 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/