draft-ietf-nfsv4-rpc-netid-04.txt		draft-ietf-nfsv4-rpc-netid-05.txt
	NFSv4 M. Eisler		NFSv4 M. Eisler
	Internet-Draft NetApp		Internet-Draft NetApp
	Updates: 1833 (if approved) December 3, 2008		Updates: 1833 (if approved) December 10, 2008
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 6, 2009		Expires: June 13, 2009
	IANA Considerations for RPC Net Identifiers and Universal Address		IANA Considerations for RPC Net Identifiers and Universal Address
	Formats		Formats
	draft-ietf-nfsv4-rpc-netid-04.txt		draft-ietf-nfsv4-rpc-netid-05.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 36		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 6, 2009.		This Internet-Draft will expire on June 13, 2009.
	Abstract		Abstract
	This Internet-Draft lists IANA Considerations for RPC Network		This Internet-Draft lists IANA Considerations for RPC Network
	Identifiers (netids) and RPC Universal Network Addresses (uaddrs).		Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
	This Internet-Draft updates, but does not replace, RFC1833.		This Internet-Draft updates, but does not replace, RFC1833.
	Requirements Language		Requirements Language
	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 RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3		1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
	2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3		2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 3		3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3		4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3
	4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 5		4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 6
	4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7		4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7
	4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7		4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7
	4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8		4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8
	4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9		4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9
	4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9		4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9
	4.3. Cross Referencing Between the Netid and Format Registry . 10		4.3. Cross Referencing Between the Netid and Format Registry . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 11		5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	5.2. Informative References . . . . . . . . . . . . . . . . . . 11		5.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12		Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction and Motivation		1. Introduction and Motivation
	The concepts of an RPC (defined in RFC1831 [4]) Network Identifier		The concepts of an RPC (defined in RFC1831 [4]) Network Identifier
	(netid) and an RPC Universal Address (uaddr) were introduced in		(netid) and an RPC Universal Address (uaddr) were introduced in
	RFC1833 [2] for distinguishing network addresses of multiple		RFC1833 [2] for distinguishing network addresses of multiple
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	in RFC1833.) Since the publication of RFC1833, it has been found		in RFC1833.) Since the publication of RFC1833, it has been found
	that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent		that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent
	values of netids and representations of uaddrs. Current practices		values of netids and representations of uaddrs. Current practices
	tend to ensure this consistency. Thus, this document identifies the		tend to ensure this consistency. Thus, this document identifies the
	considerations for IANA to establish registries of netids and uaddr		considerations for IANA to establish registries of netids and uaddr
	formats for RPC and specifies the initial content of the two		formats for RPC and specifies the initial content of the two
	registries.		registries.
	2. Acknowledgements		2. Acknowledgements
	Lars Eggert and Juergen Schoenwaelder reviewed the document and gave		Lars Eggert, Juergen Schoenwaelder, and Robert Sparks reviewed the
	valuable feed back for improving its readability.		document and gave valuable feed back.
	3. Security Considerations		3. Security Considerations
	Since this document is only concerned with the IANA management of the		Since this document is only concerned with the IANA management of the
	Network Identifier (netid) and Universal Network Addresses (uaddrs)		Network Identifier (netid) and Universal Network Addresses (uaddrs)
	format registry, it raises no new security issues.		format registry, it raises no new security issues.
	4. IANA Considerations		4. IANA Considerations
	This section uses terms that are defined in RFC5226 [7].		This section uses terms that are defined in RFC5226 [7].
	4.1. IANA Considerations for Netids		4.1. IANA Considerations for Netids
	IANA will create a registry called "ONC RPC Netids". The remainder		IANA will create a registry called "ONC RPC Netids". The remainder
	of this section describes the registry.		of this section describes the registry.
	All assignments to the ONC RPC Netids registry are made on one of two		All assignments to the ONC RPC Netids registry are made on one of two
	bases:		bases:
	o First Come First Served basis per section 4.1 of RFC5226.		o A First Come First Served basis subregistry per section 4.1 of
			RFC5226.
	o Standards Action per section 4.1 of RFC5226.		o A Standards Action basis subregistry per section 4.1 of RFC5226.
	Netids can be up to 2^32 - 1 octets in length. However, to ensure		The XDR encoding allows netids to be up to 2^32 - 1 octets in length,
	that practical values for Standards Track protocols are not		but the registry will only allow a much shorter length. Assignments
	exhausted, the values of netids one to eight octets long should be		made on a Standards Action basis should be assigned netids one to
	used for netids assigned on the Standards Action basis. Assignments		eight octets long. Assignments made on a First Come First Served
	made on a First Come First Served basis should be assigned netids of		basis should be assigned netids nine to 128 octets long. Some
	length 9 to 128 octets long. All netids, regardless of length, that		exceptions are listed in Table 2.
	start with the prefixes "STDS" or "FCFS" are Reserved, in order to
	extend the name space of either basis. In addition, to give IESG the		Some portion of the netid name space is Reserved:
	flexibility in the future to permit Private and Experimental Uses,
	all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero		o All netids, regardless of length, that start with the prefixes
	length netid is Reserved. Some exceptions are listed in Table 2. A		"STDS" or "FCFS" are Reserved, in order to extend the name space
	recommended convention for netids corresponding to transports that		of either Standards Action or First Come First Served bases.
			o To give IESG the flexibility in the future to permit Private and
			Experimental Uses, all netids with the prefixes "PRIV" or "EXPE"
			are Reserved.
			o To prevent confusion with the control protocol by the same name
			[8], netids with the prefix "ICMP" are Reserved.
			o Since netids are not constructed in an explicit hierarchical
			manner, this document does not provide for Hierarchical Allocation
			of netids. Nonetheless, all netids containing the octet "." are
			Reserved for future possible provision of Hierarchical Allocation.
			o The zero length netid is Reserved.
			A recommended convention for netids corresponding to transports that
	work over the IPv6 protocol is to have "6" as the last character in		work over the IPv6 protocol is to have "6" as the last character in
	the netid's name.		the netid's name.
	Since netids are not constructed in an explicit hierarchical manner,		There are two subregistries of netids, one for Standards Action
	this document does not provide for Hierarchical Allocation of netids.		assignments, and one for First Come First Serve assignments. Each
	Nonetheless, the octet "." in a netid string is Reserved for future		registry of netids is a list of assignments, each containing five
	possible provision of Hierarchical Allocation.
	The registry of netids is a list of assignments, each containing five
	fields for each assignment.		fields for each assignment.
	1. A US-ASCII string name that is the actual netid. This name MUST		1. A US-ASCII string name that is the actual netid. The netid
	NOT conflict with any other netid. This string name can be 1 to		should be one to eight octets long for the Standards Action
	128 octets long.		subregistry, and should be nine to 128 octets long for the First
			Come First Served subregistry. The netid MUST NOT conflict with
			any other registered netid. Despite the fact that netids are
			case sensitive, the netid, when mapped to all upper case MUST NOT
			conflict with the value of any other registered netid after the
			registered netid is mapped to upper case. In addition, when
			mapped to upper case, the prefix of the netid MUST NOT be equal
			to a Reserved prefix.
	2. A constant name that can be used for software programs that wish		2. A constant name that can be used for software programs that wish
	to use the transport protocol associated with protocol. The name		to use the transport protocol associated with protocol. The name
	of the constant typically has the prefix: 'NC_', and a suffix		of the constant typically has the prefix: "NC_", and a suffix
	equal to the upper case version of the netid. This constant name		equal to the upper case version of the netid. This constant name
	should be a constant that is valid in the 'C' programming		should be a constant that is valid in the 'C' programming
	language. This constant name MUST NOT conflict with any other		language. This constant name MUST NOT conflict with any other
	netid constant name. Constant names with the prefix "NC_STDS",		netid constant name. Constant names with the prefix "NC_STDS",
	"NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved. Constant names		"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved.
	with a prefix of "NC_" and a total length of 11 characters or		Constant names with a prefix of "NC_" and a total length of 11
	less should be for assignments made on the Standards Action		characters or less should be for assignments made on the
	basis. The constant name can be 1 to 131 octets long.		Standards Action basis. The constant "NC_" is Reserved. The
			constant name can be one to 131 octets long.
	3. A description and/or a reference to a description of the how the		3. A description and/or a reference to a description of the how the
	netid will be used. For assignments made on a First Come First		netid will be used. For assignments made on a First Come First
	Served basis the description should include, if applicable, a		Served basis the description should include, if applicable, a
	reference to the transport and network protocols corresponding to		reference to the transport and network protocols corresponding to
	the netid. For assignments made on a Standards Action basis, the		the netid. For assignments made on a Standards Action basis, the
	description field must include the RFC numbers of the protocol		description field must include the RFC numbers of the protocol
	associated with the netid, including if applicable, RFC numbers		associated with the netid, including if applicable, RFC numbers
	of the transport and network protocols. This field can be up to		of the transport and network protocols.
	1024 octets. If more space is required, an RFC should be
	published.
	4. A point of contact of the registrant. The point of contact can		4. A point of contact of the registrant. For assignments made on a
	consume up to 256 octets (or more if IANA permits). For		First Come First Served basis,
	assignments made on a First Come First Served basis,
	* the point of contact should include an email address.		* the point of contact should include an email address.
	* subject to authorization by a Designated Expert, the point of		* subject to authorization by a Designated Expert, the point of
	contact may be omitted for extraordinary situations, such as		contact may be omitted for extraordinary situations, such as
	the registration of a commonly used netid where the owner is		the registration of a commonly used netid where the owner is
	unknown.		unknown.
	For assignments made on a Standards Action basis the point of		For assignments made on a Standards Action basis the point of
	contact is always IESG.		contact is always determined by IESG.
	5. A numerical value, used to cross reference the netid assignment		5. A numerical value, used to cross reference the netid assignment
	with an assignment in the uaddr format registry (see		with an assignment in the uaddr format registry (see
	Section 4.2). If the registrant is registering a netid that		Section 4.2). If the registrant is registering a netid that
	cross references an existing assignment in the uaddr format		cross references an existing assignment in the uaddr format
	registry, then the registrant provides the actual value of the		registry, then the registrant provides the actual value of the
	cross reference along with the date the registrant retrieved the		cross reference along with the date the registrant retrieved the
	cross reference value from the uaddr format registry. If the		cross reference value from the uaddr format registry. If the
	registrant is registering both a new netid and new uaddr format,		registrant is registering both a new netid and new uaddr format,
	then the registrant provides a value of TBD1 in the netid		then the registrant provides a value of TBD1 in the netid
	request, and uses TBD1 in the the uaddr format request. IANA		request, and uses TBD1 in the the uaddr format request. IANA
	will then substitute TBD1 for cross reference number IANA		will then substitute TBD1 for cross reference number IANA
	allocates.		allocates.
	4.1.1. Initial Registry		4.1.1. Initial Registry
	The initial list of netids is broken into those assigned on a First		The initial list of netids is broken into two subregistries: those
	Come First Serve basis in Table 1 and those assigned on a Standards		assigned on a First Come First Serve basis in Table 1 and those
	Action basis in Table 2. These lists will change when IANA registers		assigned on a Standards Action basis in Table 2. These lists will
	additional netids as needed, and the authoritative list of registered		change when IANA registers additional netids as needed, and the
	netids will always live with IANA.		authoritative list of registered netids will always live with IANA.
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	| Netid | Constant | Description and/or | PoC | CR |		| Netid | Constant | Description and/or | PoC | CR |
	| | Name | Reference | | |		| | Name | Reference | | |
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	| "-" | NC_NOPROTO | RFC1833 [2], | | 1 |		| "-" | NC_NOPROTO | RFC1833 [2], | | 1 |
	| | | Section 4.2.3.2 of | | |		| | | Section 4.2.3.2 of | | |
	| | | RFCTBD2 | | |		| | | RFCTBD2 | | |
	| "ticlts" | NC_TICLTS | The loop back | | 0 |		| "ticlts" | NC_TICLTS | The loop back | | 0 |
	| | | connectionless transport | | |		| | | connectionless transport | | |
	| | | used in System V Release | | |		| | | used in System V Release | | |
	| | | 4 and other operating | | |		| | | 4 and other operating | | |
	| | | systems. Although this | | |		| | | systems. Although this | | |
	| | | assignment is made on a | | |		| | | assignment is made on a | | |
	| | | First Come First Served | | |		| | | First Come First Served | | |
	| | | basis and is fewer than 9 | | |		| | | basis and is fewer than | | |
	| | | characters long, the | | |		| | | nine characters long, the | | |
	| | | exception is authorized. | | |		| | | exception is authorized. | | |
	| | | See [8]. | | |		| | | See [9]. | | |
	| "ticots" | NC_TICOTS | The loop back | | 0 |		| "ticots" | NC_TICOTS | The loop back | | 0 |
	| | | connection-oriented | | |		| | | connection-oriented | | |
	| | | transport used in System | | |		| | | transport used in System | | |
	| | | V Release 4 and other | | |		| | | V Release 4 and other | | |
	| | | operating systems. See | | |		| | | operating systems. See | | |
	| | | [8]. Although this | | |		| | | [9]. Although this | | |
	| | | assignment is made on a | | |		| | | assignment is made on a | | |
	| | | First Come First Served | | |		| | | First Come First Served | | |
	| | | basis and is fewer than 9 | | |		| | | basis and is fewer than | | |
	| | | characters long, the | | |		| | | nine characters long, the | | |
	| | | exception is authorized. | | |		| | | exception is authorized. | | |
	| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |		| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
	| | | connection-oriented with | | |		| | | connection-oriented with | | |
	| | | orderly-release transport | | |		| | | orderly-release transport | | |
	| | | used in System V Release | | |		| | | used in System V Release | | |
	| | | 4 and other operating | | |		| | | 4 and other operating | | |
	| | | systems. See [8]. | | |		| | | systems. See [9]. | | |
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	Table 1: Initial First Come First Serve Netid Assignments		Table 1: Initial First Come First Serve Netid Assignments
	PoC: Point of Contact. CR: Cross Reference to the Uaddr Format		PoC: Point of Contact. CR: Cross Reference to the Uaddr Format
	Registry.		Registry.
	+---------+--------------+------------------------------+------+----+		+---------+--------------+------------------------------+------+----+
	| Netid | Constant | RFC(s) and Description (if | PoC | CR |		| Netid | Constant | RFC(s) and Description (if | PoC | CR |
	| | Name | needed) | | |		| | Name | needed) | | |
	+---------+--------------+------------------------------+------+----+		+---------+--------------+------------------------------+------+----+
	| "dccp" | NC_DCCP | RFC4340 [9] RFC0760 [10] | IESG | 2 |		| "dccp" | NC_DCCP | RFC4340 [10] RFC0791 [11] | IESG | 2 |
	| "dccp6" | NC_DCCP6 | RFC4340 [9] RFC2460 [11] | IESG | 3 |		| "dccp6" | NC_DCCP6 | RFC4340 [10] RFC2460 [12] | IESG | 3 |
	| "icmp" | NC_ICMP | RFC0777 [12] RFC0760 [10] | IESG | 4 |		| "rdma" | NC_RDMA | RFCTBD1 [6] RFC0791 [11] | IESG | 2 |
	| "icmp6" | NC_ICMP6 | RFC0777 [12] RFC2460 [11] | IESG | 4 |		| "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [12] | IESG | 3 |
	| "rdma" | NC_RDMA | RFCTBD1 [6] RFC0760 [10] | IESG | 2 |		| "sctp" | NC_SCTP | RFC2960 [13] RFC0791 [11] | IESG | 2 |
	| "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [11] | IESG | 3 |		| "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [12] | IESG | 3 |
	| "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 |		| "tcp" | NC_TCP | RFC0793 [14] RFC0791 [11] | IESG | 2 |
	| "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 |		| "tcp6" | NC_TCP6 | RFC0793 [14] RFC2460 [12] | IESG | 3 |
	| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |		| "udp" | NC_UDP | RFC0768 [15] RFC0791 [11] | IESG | 2 |
	| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |		| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [12] | IESG | 3 |
	| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |
	| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |
	+---------+--------------+------------------------------+------+----+		+---------+--------------+------------------------------+------+----+
	Table 2: Initial Standards Action Netid Assignments		Table 2: Initial Standards Action Netid Assignments
	4.1.2. Updating Registrations		4.1.2. Updating Registrations
	Per section 5.2 of RFC5226 the registrant is always permitted to		Per section 5.2 of RFC5226 the registrant is always permitted to
	update a registration made on a First Come First Served basis		update a registration made on a First Come First Served basis
	"subject to the same constraints and review as with new		"subject to the same constraints and review as with new
	registrations." IESG or a Designated Expert is permitted to update		registrations." IESG or a Designated Expert is permitted to update
	skipping to change at page 8, line 16		skipping to change at page 8, line 16
	The registry of formats is a list of assignments, each containing		The registry of formats is a list of assignments, each containing
	four fields for each assignment.		four fields for each assignment.
	1. The basis for the assignment, which can be either FCFS for First		1. The basis for the assignment, which can be either FCFS for First
	Come First Served assignments, or STDS for Standards Action		Come First Served assignments, or STDS for Standards Action
	assignments.		assignments.
	2. A description and/or reference to a description of the actual		2. A description and/or reference to a description of the actual
	uaddr format. Assignments made on a Standards Action basis		uaddr format. Assignments made on a Standards Action basis
	always have a reference to an RFC. This field can be up to 1024		always have a reference to an RFC.
	octets. If more space is required, an RFC should be published.
	3. For assignments made on a First Come First Served basis, a point		3. For assignments made on a First Come First Served basis, a point
	of contact, including an email address. The point of contact can		of contact, including an email address. Subject to authorization
	consume up to 256 octets (or more if IANA permits). Subject to		by a Designated Expert, the point of contact may be omitted for
	authorization by a Designated Expert, the point of contact may be		extraordinary situations, such as the registration of a commonly
	omitted for extraordinary situations, such as the registration of		used format where the owner is unknown. For assignments made on
	a commonly used format where the owner is unknown. For		a Standards Action basis, the point of contact is always
	assignments made on a Standards Action basis the point of contact		determined by IESG.
	is always IESG.
	4. A numerical value, used to cross reference the format assignment		4. A numerical value, used to cross reference the format assignment
	with an assignment in the netid registry. The registrant		with an assignment in the netid registry. The registrant
	provides a value of TBD1 for the cross reference filed when		provides a value of TBD1 for the cross reference field when
	requesting an assignment. IANA will assign TBD1 to a real value.		requesting an assignment. IANA will assign TBD1 to a real value.
	All requests for assignments to the format registry must undergo		All requests for assignments to the format registry on a Standards
	Expert Review. All requests for assignments made on a Standards		Action basis must undergo Expert Review and must be approved by IESG.
	Action basis must be approved by IESG.
	4.2.1. Initial Registry		4.2.1. Initial Registry
	The initial list of formats is in Table 3. This lists will change		The initial list of formats is in Table 3. This lists will change
	when IANA registers additional formats as needed, and the		when IANA registers additional formats as needed, and the
	authoritative list of registered formats will always live with IANA.		authoritative list of registered formats will always live with IANA.
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	| Basis | Description and/or Reference | PoC | CR |		| Basis | Description and/or Reference | PoC | CR |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	| FCFS | System V Release 4 loopback transport uaddr | | 0 |		| FCFS | System V Release 4 loopback transport uaddr | | 0 |
	| | format. Section 4.2.3.1 of RFCTBD2 | | |		| | format. Section 4.2.3.1 of RFCTBD2 | | |
	| FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 |		| FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 |
	| | of RFCTBD2 | | |		| | of RFCTBD2 | | |
	| STDS | Uaddr format for IPv4 transports. | IESG | 2 |		| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
	| | Section 4.2.3.3 of RFCTBD2 | | |		| | Section 4.2.3.3 of RFCTBD2 | | |
	| STDS | Uaddr format for IPv6 transports. | IESG | 3 |		| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
	| | Section 4.2.3.4 of RFCTBD2 | | |		| | Section 4.2.3.4 of RFCTBD2 | | |
	| STDS | Uaddr formation for ICMP. Section 4.2.3.5 of | IESG | 4 |
	| | RFCTBD2 | | |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	Table 3: Initial Format Assignments		Table 3: Initial Format Assignments
	4.2.2. Updating Registrations		4.2.2. Updating Registrations
	The registrant is always permitted to update a registration made on a		The registrant is always permitted to update a registration made on a
	First Come First Served basis "subject to the same constraints and		First Come First Served basis "subject to the same constraints and
	review as with new registrations.", but as with new registrations,		review as with new registrations." IESG is permitted to update any
	any requested changes to any field other the point of contact		registration made on a First Come First Served basis, which normally
	requires Expert Review. IESG or a Designated Expert is permitted to		is done when the PoC cannot be reached in order to make necessary
	update any registration made on a First Come First Served basis,		updates. Examples where an update would be needed include, but are
	which normally is done when the PoC cannot be reached in order to		not limited to: the email address or other contact information
	make necessary updates. Examples where an update would be needed		becomes invalid; the reference to the format description becomes
	include, but are not limited to: the email address or other contact		obsolete or unavailable; and RFC1833 is updated or replaced in such a
	information becomes invalid; the reference to the format description		way that the scope of uaddr formats changes, requiring additional
	becomes obsolete or unavailable; and RFC1833 is updated or replaced		fields in the assignment.
	in such a way that the scope of uaddr formats changes, requiring
	additional fields in the assignment.
	Only IESG, on the advice of a Designated Expert, can update a		Only IESG, on the advice of a Designated Expert, can update a
	registration made on a Standards Action basis.		registration made on a Standards Action basis.
	4.2.3. Uaddr Formats		4.2.3. Uaddr Formats
	4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports		4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports
	Although RFC1833 specifies the uaddr as the XDR data type string		Although RFC1833 specifies the uaddr as the XDR data type string
	(hence, limited to US-ASCII), implementations of the System V Release		(hence, limited to US-ASCII), implementations of the System V Release
	skipping to change at page 9, line 49		skipping to change at page 9, line 41
	of octets.		of octets.
	4.2.3.2. Uaddr Format for Netid "-"		4.2.3.2. Uaddr Format for Netid "-"
	There is no address format for netid "-". This netid is apparently		There is no address format for netid "-". This netid is apparently
	for internal use for supporting some implementations of RFC1833.		for internal use for supporting some implementations of RFC1833.
	4.2.3.3. Uaddr Format for Most IPv4 Transports		4.2.3.3. Uaddr Format for Most IPv4 Transports
	Most transport protocols that operate over IPv4 use 16 bit port		Most transport protocols that operate over IPv4 use 16 bit port
	numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP		numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP
	[15]. The format of the uaddr for the above 16 bit port transports		[15]. The format of the uaddr for the above 16 bit port transports
	(when used over IPv4) is the US-ASCII string:		(when used over IPv4) is the US-ASCII string:
	h1.h2.h3.h4.p1.p2		h1.h2.h3.h4.p1.p2
	The prefix, "h1.h2.h3.h4", is the standard textual form for		The prefix, "h1.h2.h3.h4", is the standard textual form for
	representing an IPv4 address, which is always four octets long.		representing an IPv4 address, which is always four octets long.
	Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,		Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
	the first through fourth octets each converted to ASCII-decimal. The		the first through fourth octets each converted to ASCII-decimal. The
	suffix, "p1.p2", is a textual form for representing a service port.		suffix, "p1.p2", is a textual form for representing a service port.
	skipping to change at page 10, line 22		skipping to change at page 10, line 15
	Assuming big-endian ordering, p1 and p2 are, respectively, the first		Assuming big-endian ordering, p1 and p2 are, respectively, the first
	and second octets each converted to ASCII-decimal. For example, if a		and second octets each converted to ASCII-decimal. For example, if a
	host, in big-endian order, has an address in hexadecimal of		host, in big-endian order, has an address in hexadecimal of
	0xC0000207 and there is a service listening on, in big endian order,		0xC0000207 and there is a service listening on, in big endian order,
	port 0xCB51 (decimal 52049) then the complete uaddr is		port 0xCB51 (decimal 52049) then the complete uaddr is
	"192.0.2.7.203.81".		"192.0.2.7.203.81".
	4.2.3.4. Uaddr Format for Most IPv6 Transports		4.2.3.4. Uaddr Format for Most IPv6 Transports
	Most transport protocols that operate over IPv6 use 16 bit port		Most transport protocols that operate over IPv6 use 16 bit port
	numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP		numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP
	[15]. The format of the uaddr for the above 16 bit port transports		[15]. The format of the uaddr for the above 16 bit port transports
	(when used over IPv6) is the US-ASCII string:		(when used over IPv6) is the US-ASCII string:
	x1:x2:x3:x4:x5:x6:x7:x8.p1.p2		x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
	The suffix "p1.p2" is the service port, and is computed the same way		The suffix "p1.p2" is the service port, and is computed the same way
	as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The		as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The
	prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for		prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for
	representing an IPv6 address as defined in Section 2.2 of RFC4291		representing an IPv6 address as defined in Section 2.2 of RFC4291
	[3]. Additionally, the two alternative forms specified in Section		[3]. Additionally, the two alternative forms specified in Section
	skipping to change at page 11, line 29		skipping to change at page 11, line 22
	[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol		[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol
	Specification Version 2", RFC 1831, August 1995.		Specification Version 2", RFC 1831, August 1995.
	[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,		[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
	C., Eisler, M., and D. Noveck, "Network File System (NFS)		C., Eisler, M., and D. Noveck, "Network File System (NFS)
	version 4 Protocol", RFC 3530, April 2003.		version 4 Protocol", RFC 3530, April 2003.
	[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access		[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
	Transport for Remote Procedure Call",		Transport for Remote Procedure Call",
	draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008.		draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008.
	[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.		Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
	[8] American Telephone and Telegraph Company, "UNIX System V,		[8] Postel, J., "Internet Control Message Protocol", STD 5,
			RFC 792, September 1981.
			[9] American Telephone and Telegraph Company, "UNIX System V,
	Release 4 Programmer's Guide: Networking Interfaces, ISBN		Release 4 Programmer's Guide: Networking Interfaces, ISBN
	0139470786", 1990.		0139470786", 1990.
	[9] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion		[10] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
	Control Protocol (DCCP)", RFC 4340, March 2006.		Control Protocol (DCCP)", RFC 4340, March 2006.
	[10] Postel, J., "DoD standard Internet Protocol", RFC 760,		[11] Postel, J., "Internet Protocol", STD 5, RFC 791,
	January 1980.		September 1981.
	[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[12] Postel, J., "Internet Control Message Protocol", RFC 777,
	April 1981.
	[13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,		[13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
	H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.		H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
	Paxson, "Stream Control Transmission Protocol", RFC 2960,		Paxson, "Stream Control Transmission Protocol", RFC 2960,
	October 2000.		October 2000.
	[14] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of		[14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
	Internet Transmission Control Program", RFC 675, December 1974.		September 1981.
	[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	Appendix A. RFC Editor Notes		Appendix A. RFC Editor Notes
	[RFC Editor: please remove this section prior to publication.]		[RFC Editor: please remove this section prior to publication.]
	[RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx		[RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx
	where xxxx is the RFC number assigned to the document referenced in		where xxxx is the RFC number assigned to the document referenced in
End of changes. 40 change blocks.
	108 lines changed or deleted		117 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/