draft-ietf-nfsv4-rpc-netid-01.txt		draft-ietf-nfsv4-rpc-netid-02.txt
	NFSv4 M. Eisler		NFSv4 M. Eisler
	Internet-Draft NetApp		Internet-Draft NetApp
	Updates: 1833 (if approved) August 18, 2008		Updates: 1833 (if approved) August 19, 2008
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 19, 2009		Expires: February 20, 2009
	IANA Considerations for RPC Net Identifiers		IANA Considerations for RPC Net Identifiers and Universal Address
	draft-ietf-nfsv4-rpc-netid-01.txt		Formats
			draft-ietf-nfsv4-rpc-netid-02.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 35		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 February 19, 2009.		This Internet-Draft will expire on February 20, 2009.
	Abstract		Abstract
	This Internet-Draft lists IANA Considerations for RPC Network		This Internet-Draft lists IANA Considerations for RPC Network
	Identifiers (netids). This Internet-Draft updates, but does not		Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
	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. Security Considerations . . . . . . . . . . . . . . . . . . . . 3		2. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Initial Registry . . . . . . . . . . . . . . . . . . . . . 5		3.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3
	3.2. Updating Registrations . . . . . . . . . . . . . . . . . . 7		3.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 5
	4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7
	4.1. Normative References . . . . . . . . . . . . . . . . . . . 7		3.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7
	4.2. Informative References . . . . . . . . . . . . . . . . . . 7		3.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2.2. Updating Registrations . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		3.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9
			3.3. Cross Referencing Between the Netid and Format Registry . 10
			4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
			4.1. Normative References . . . . . . . . . . . . . . . . . . . 10
			4.2. Informative References . . . . . . . . . . . . . . . . . . 10
			Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 11
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
			Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction and Motivation		1. Introduction and Motivation
	The concept of an RPC ([3]) Network Identifier (netid) was introduced		The concepts of an RPC [4] Network Identifier (netid) and an RPC
	in [2] for distinguishing universal network addresses of multiple		Universal Address (uaddr) were introduced in [2] for distinguishing
	protocols. [2] states that a netid ``is defined by a system		network addresses of multiple protocols and representing those
	administrator based on local conventions, and cannot be depended on		addresses in a canonical form. [2] states that a netid ``is defined
	to have the same value on every system.'' Since the publication of		by a system administrator based on local conventions, and cannot be
	RFC1833, it has been found to be necessary that protocols like [4]		depended on to have the same value on every system.'' (The netid is
	and [5] depend on consistent values of netids across every system,		contained in the field r_netid of the data type rpcb_entry, and the
	and current practices tend to ensure this consistency. Thus, this		uaddr is contained in the field r_addr of the same data type, where
	document identifies the considerations for IANA to establish a		rpcb_entry is defined in [2].) Since the publication of [2], it has
	registry of netids for RPC and specifies the initial content of the		been found to be necessary that protocols like [5] and [6] depend on
	registry.		consistent values of netids and representations of uaddrs. Current
			practices tend to ensure this consistency. Thus, this document
			identifies the considerations for IANA to establish registries of
			netids and uaddr formats for RPC and specifies the initial content of
			the two registries.
	2. Security Considerations		2. Security Considerations
	See section 9 of [6].		See section 9 of [7].
	3. IANA Considerations		3. IANA Considerations
	This section uses terms that are defined in [6].		This section uses terms that are defined in [7].
			3.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 [6].		o First Come First Served basis per section 4.1 of [7].
	o Standards Action per section 4.1 of [6].		o Standards Action per section 4.1 of [7].
	Netids can be up to 2^32 - 1 octets in length. However, to ensure		Netids can be up to 2^32 - 1 octets in length. However, to ensure
	that practical values for Standards Track protocols are not		that practical values for Standards Track protocols are not
	exhausted, the values of netids one to eight octets long should be		exhausted, the values of netids one to eight octets long should be
	used for netids assigned on the Standards Action basis. Assignments		used for netids assigned on the Standards Action basis. Assignments
	made on a First Come First Served basis should be assigned netids of		made on a First Come First Served basis should be assigned netids of
	length 9 to 128 octets long. All netids, regardless of length, that		length 9 to 128 octets long. All netids, regardless of length, that
	start with the prefixes "STDS" or "FCFS" are Reserved, in order to		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		extend the name space of either basis. In addition, to give IESG the
	flexibility in the future to permit Private and Experimental Uses,		flexibility in the future to permit Private and Experimental Uses,
	all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero		all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero
	length netid is Reserved. Some exceptions are listed in Table 2. A		length netid is Reserved. Some exceptions are listed in Table 2. A
	recommended convention for netids corresponding to transports that		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 string name.		the netid's name.
	Since netids are not constructed in an explicit hierarchical manner,		Since netids are not constructed in an explicit hierarchical manner,
	this document does not provide for Hierarchical Allocation of netids.		this document does not provide for Hierarchical Allocation of netids.
	Nonetheless, the octet "." in a netid string is Reserved for future		Nonetheless, the octet "." in a netid string is Reserved for future
	possible provision of Hierarchical Allocation.		possible provision of Hierarchical Allocation.
	The registry of netids is a list of assignments, each containing six		The registry of netids is a list of assignments, each containing five
	fields for each assignment made on a First Come First Served basis,		fields for each assignment.
	and five fields for each assignment made on a Standards Action basis.
	Regardless of basis, all six fields must be provided to IANA.
	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. This name MUST
	NOT conflict with any other netid. This string name can be zero		NOT conflict with any other netid. This string name can be zero
	to 128 octets long.		to 128 octets long.
	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 starting with "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", or "NC_EXPE" are reserved. Constant names
	with a prefix of "NC_" and a total length of 11 characters or		with a prefix of "NC_" and a total length of 11 characters or
	less should be for assignments made on the Standards Action		less should be for assignments made on the Standards Action
	basis. The constant name can be 1 to 131 octets long.		basis. The constant name can be 1 to 131 octets long.
	3. For assignments made on a First Come First Served basis a		3. A description and/or a reference to a description of the how the
	description, which can be up to 1024 US-ASCII characters (or more		netid will be used. For assignments made on a First Come First
	if IANA permits) how the netid will be used. For assignments		Served basis the description should include, if applicable, a
	made on a Standards Action basis, the description field is		reference to the transport and network protocols corresponding to
	provided to the Designated Expert to enable the review, but the		the netid. For assignments made on a Standards Action basis, the
	description is not recorded in the registry, and IANA may dispose		description field must include the RFC numbers of the protocol
	of the description once IESG approves the assignment.		associated with the netid, including if applicable, RFC numbers
			of the transport and network protocols. This field can be up to
			1024 octets. If more space is required, an RFC should be
			published.
	4. For assignments made on a First Come First Served basis, if		4. A point of contact of the registrant. The point of contact can
	applicable, a reference to a published description of the		consume up to 256 octets (or more if IANA permits). For
	transport protocol (preferred), or a reference to a published use		assignments made on a First Come First Served basis,
	of the transport protocol. This reference can consume up to 256
	octets (or more if IANA permits). For assignments made on a
	Standards Action basis, the RFC number of the protocol the netid
	is associated with must be provided.
	5. For assignments made on a First Come First Served basis, if		* the point of contact should include an email address.
	applicable, a reference to a published description of the network
	protocol (preferred), or a reference to a published use of the
	transport protocol. This reference can consume up to 256 octets
	(or more if IANA permits). For assignments made on a Standards
	Action basis, if the previous field refers to a transport
	protocol, the RFC number of the network protocol the netid is
	associated with must be provided.
	6. For assignments made on a First Come First Served basis, a point		* subject to authorization by a Designated Expert, the point of
	of contact, including an email address. The point of contact can		contact may be omitted for extraordinary situations, such as
	consume up to 256 octets (or more if IANA permits). Subject to		the registration of a commonly used netid where the owner is
	authorization by a Designated Expert, the point of contact may be		unknown.
	omitted for extraordinary situations, such as the registration of
	a commonly used netid where the owner is in unknown. For
	assignments made on a Standards Action basis the point of contact
	is always IESG.
	3.1. Initial Registry		For assignments made on a Standards Action basis the point of
			contact is always IESG.
			5. A numerical value, used to cross reference the netid assignment
			with an assignment in the uaddr format registry (see
			Section 3.2). If the registrant is registering a netid that
			cross references an existing assignment in the uaddr format
			registry, then the registrant provides the actual value of the
			cross reference along with the date the registrant retrieved the
			cross reference value from the uaddr format registry. If the
			registrant is registering both a new netid and new uaddr format,
			then the registrant provides a value of TBD1 in the netid
			request, and uses TBD1 in the the uaddr format request. IANA
			will then substitute TBD1 for cross reference number IANA
			allocates.
			3.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 those assigned on a First
	Come First Serve basis in Table 1 and those assigned on a Standards		Come First Serve basis in Table 1 and those assigned on a Standards
	Action basis in Table 2. These lists will change when IANA registers		Action basis in Table 2. These lists will change when IANA registers
	additional netids as needed, and the authoritative list of registered		additional netids as needed, and the authoritative list of registered
	netids will always live with IANA.		netids will always live with IANA.
	+-------------+--------------+---------------------+-----+----+-----+		+-------------+--------------+---------------------------+-----+----+
	| Netid | Constant | Description | PR | NR | PoC |		| Netid | Constant | Description and/or | PoC | CR |
	| | Name | | | | |		| | Name | Reference | | |
	+-------------+--------------+---------------------+-----+----+-----+		+-------------+--------------+---------------------------+-----+----+
	| "ticlts" | NC_TICLTS | The loop back | [7] | | |		| "-" | NC_NOPROTO | RFC1833 [2], | | 1 |
	| | | connectionless | | | |		| | | Section 3.2.3.2 of | | |
	| | | transport used in | | | |		| | | RFCTBD2 | | |
	| | | System V Release 4 | | | |		| "ticlts" | NC_TICLTS | The loop back | | 0 |
	| | | and other operating | | | |		| | | connectionless transport | | |
	| | | systems. Although | | | |		| | | used in System V Release | | |
	| | | this assignment is | | | |		| | | 4 and other operating | | |
	| | | made on a First | | | |		| | | systems. Although this | | |
	| | | Come First Served | | | |		| | | assignment is made on a | | |
	| | | basis and is fewer | | | |		| | | First Come First Served | | |
	| | | than 9 characters | | | |		| | | basis and is fewer than 9 | | |
	| | | log, the exception | | | |		| | | characters long, the | | |
	| | | is authorized. | | | |		| | | exception is authorized. | | |
	| "ticots" | NC_TICOTS | The loop back | [7] | | |		| | | See [8]. | | |
	| | | connection-oriented | | | |		| "ticots" | NC_TICOTS | The loop back | | 0 |
	| | | transport used in | | | |		| | | connection-oriented | | |
	| | | System V Release 4 | | | |		| | | transport used in System | | |
	| | | and other operating | | | |		| | | V Release 4 and other | | |
	| | | systems. Although | | | |		| | | operating systems. See | | |
	| | | this assignment is | | | |		| | | [8]. Although this | | |
	| | | made on a First | | | |		| | | assignment is made on a | | |
	| | | Come First Served | | | |		| | | First Come First Served | | |
	| | | basis and is fewer | | | |		| | | basis and is fewer than 9 | | |
	| | | than 9 characters | | | |		| | | characters long, the | | |
	| | | log, the exception | | | |		| | | exception is authorized. | | |
	| | | is authorized. | | | |		| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
	| "ticotsord" | NC_TICOTSORD | The loop back | [7] | | |		| | | connection-oriented with | | |
	| | | connection-oriented | | | |		| | | orderly-release transport | | |
	| | | with | | | |		| | | used in System V Release | | |
	| | | orderly-release | | | |		| | | 4 and other operating | | |
	| | | transport used in | | | |		| | | systems. See [8]. | | |
	| | | System V Release 4 | | | |		+-------------+--------------+---------------------------+-----+----+
	| | | and other operating | | | |
	| | | systems. | | | |
	+-------------+--------------+---------------------+-----+----+-----+
	Table 1		Table 1: Initial First Come First Serve Netid Assignments
	PR: Protocol Reference. NR: Network protocol Reference. PoC: Point		PoC: Point of Contact. CR: Cross Reference to the Uaddr Format
	of Contact.		Registry.
	+---------+---------------+--------------+--------------+------+		+---------+--------------+------------------------------+------+----+
	| Netid | Constant Name | PR | NR | PoC |		| Netid | Constant | RFC(s) and Description (if | PoC | CR |
	+---------+---------------+--------------+--------------+------+		| | Name | needed) | | |
	| "-" | NC_NOPROTO | RFC1833 [2] | | IESG |		+---------+--------------+------------------------------+------+----+
	| "dccp" | NC_DCCP | RFC4340 [8] | RFC0760 [9] | IESG |		| "dccp" | NC_DCCP | RFC4340 [9] RFC0760 [10] | IESG | 2 |
	| "dccp6" | NC_DCCP6 | RFC4340 [8] | RFC2460 [10] | IESG |		| "dccp6" | NC_DCCP6 | RFC4340 [9] RFC2460 [11] | IESG | 3 |
	| "icmp" | NC_ICMP | RFC0777 [11] | RFC0760 [9] | IESG |		| "icmp" | NC_ICMP | RFC0777 [12] RFC0760 [10] | IESG | 4 |
	| "icmp6" | NC_ICMP6 | RFC0777 [11] | RFC2460 [10] | IESG |		| "icmp6" | NC_ICMP6 | RFC0777 [12] RFC2460 [11] | IESG | 4 |
	| "rdma" | NC_RDMA | RFCTBD1 [5] | RFC0760 [9] | IESG |		| "rdma" | NC_RDMA | RFCTBD1 [6] RFC0760 [10] | IESG | 2 |
	| "rdma6" | NC_RDMA6 | RFCTBD1 [5] | RFC2460 [10] | IESG |		| "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [11] | IESG | 3 |
	| "sctp" | NC_SCTP | RFC2960 [12] | RFC0760 [9] | IESG |		| "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 |
	| "sctp6" | NC_SCTP6 | RFC2960 [12] | RFC2460 [10] | IESG |		| "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 |
	| "tcp" | NC_TCP | RFC0675 [13] | RFC0760 [9] | IESG |		| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |
	| "tcp6" | NC_TCP6 | RFC0675 [13] | RFC2460 [10] | IESG |		| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |
	| "udp" | NC_UDP | RFC0768 [14] | RFC0760 [9] | IESG |		| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |
	| "udp6" | NC_UDP6 | RFC0768 [14] | RFC2460 [10] | IESG |		| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |
	+---------+---------------+--------------+--------------+------+		+---------+--------------+------------------------------+------+----+
	Table 2		Table 2: Initial Standards Action Netid Assignments
	3.2. Updating Registrations		3.1.2. Updating Registrations
	Per section 5.2 of [6] the point of contact is always permitted to		Per section 5.2 of [7] the registrant always permitted to update a
	update a registration made on a First Come First Served basis		registration made on a First Come First Served basis "subject to the
	"subject to the same constraints and review as with new		same constraints and review as with new registrations." IESG or a
	registrations." IESG or a Designated Expert is permitted to update		Designated Expert is permitted to update any registration made on a
	any registration made on a First Come First Served basis, which		First Come First Served basis, which normally is done when the PoC
	normally is done when the PoC cannot be reached in order to make		cannot be reached in order to make necessary updates. Examples where
	necessary updates. Examples where an update would be needed		an update would be needed include, but are not limited to: the email
	included, but are not limited to: the email address or other contact		address or other contact information becomes invalid; the reference
	information becomes invalid; the reference to the corresponding		to the corresponding protocol becomes obsolete or unavailable; and
	protocol becomes obsolete or unavailable; and RFC1833 [2] is updated		RFC1833 [2] is updated or replaced in such a way that the scope of
	or replaced in such a way that the scope of netids changes, requiring		netids changes, requiring additional fields in the assignment.
	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.
			3.2. IANA Considerations for Uaddr Formats
			IANA will create a registry called "ONC RPC Uaddr Format Registry"
			(called the "format registry" for the remainder of this document).
			The remainder of this section describes the registry.
			All assignments to the format registry are made on one of two bases:
			o First Come First Served basis per section 4.1 of [7].
			o Standards Action per section 4.1 of [7].
			The registry of formats is a list of assignments, each containing
			four fields for each assignment.
			1. The basis for the assignment, which can be either FCFS for First
			Come First Served assignments, or STDS for Standards Action
			assignments.
			2. A description and/or reference to a description of the actual
			uaddr format. Assignments made on a Standards Action basis
			always have a reference to an RFC. This field can be up to 1024
			octets. If more space is required, an RFC should be published.
			3. For assignments made on a First Come First Served basis, a point
			of contact, including an email address. The point of contact can
			consume up to 256 octets (or more if IANA permits). Subject to
			authorization by a Designated Expert, the point of contact may be
			omitted for extraordinary situations, such as the registration of
			a commonly used format where the owner is unknown. For
			assignments made on a Standards Action basis the point of contact
			is always IESG.
			4. A numerical value, used to cross reference the format assignment
			with an assignment in the netid registry. The registrant
			provides a value of TBD1 for the cross reference filed when
			requesting an assignment. IANA will assign TBD1 to a real value.
			All requests for assignments to the format registry must undergo
			Expert Review. All requests for assignments made on a Standards
			Action basis must be approved by IESG.
			3.2.1. Initial Registry
			The initial list of formats is in Table 3. This lists will change
			when IANA registers additional formats as needed, and the
			authoritative list of registered formats will always live with IANA.
			+-------+-----------------------------------------------+------+----+
			| Basis | Description and/or Reference | PoC | CR |
			+-------+-----------------------------------------------+------+----+
			| FCFS | System V Release 4 loopback transport uaddr | | 0 |
			| | format. Section 3.2.3.1 of RFCTBD2 | | |
			| FCFS | Uaddr format for NC_NOPROTO. Section 3.2.3.2 | | 1 |
			| | of RFCTBD2 | | |
			| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
			| | Section 3.2.3.3 of RFCTBD2 | | |
			| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
			| | Section 3.2.3.4 of RFCTBD2 | | |
			| STDS | Uaddr formation for ICMP. Section 3.2.3.5 of | IESG | 4 |
			| | RFCTBD2 | | |
			+-------+-----------------------------------------------+------+----+
			Table 3: Initial Format Assignments
			3.2.2. Updating Registrations
			The registrant always permitted to update a registration made on a
			First Come First Served basis "subject to the same constraints and
			review as with new registrations.", but as with new registrations,
			any requested changes to any field other the point of contact
			requires Expert Review. IESG or a Designated Expert is permitted to
			update any registration made on a First Come First Served basis,
			which normally is done when the PoC cannot be reached in order to
			make necessary updates. Examples where an update would be needed
			include, but are not limited to: the email address or other contact
			information becomes invalid; the reference to the format description
			becomes obsolete or unavailable; and RFC1833 [2] is updated or
			replaced 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
			registration made on a Standards Action basis.
			3.2.3. Uaddr Formats
			3.2.3.1. Uaddr Format for System V Release 4 Loopback Transports
			Although [2] identifies the uaddr as data type string (hence, limited
			to US-ASCII), implementations of the System V Release 4 loopback
			transports will use an opaque string of octets. Thus format of a
			loopback transport address is any non-zero length array of octets.
			3.2.3.2. Uaddr Format for Netid "-"
			There is no address format for netid "-". This netid is apparently
			for internal use for supporting some implementations of [2].
			3.2.3.3. Uaddr Format for Most IPv4 Transports
			Most transport protocols that operate over IPv4 use 16 bit port
			numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
			[15]. The format of the uaddr for the above 16 bit port transports
			(when used over IPv4) is the US-ASCII string:
			h1.h2.h3.h4.p1.p2
			The prefix, "h1.h2.h3.h4", is the standard textual form for
			representing an IPv4 address, which is always four octets long.
			Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
			the first through fourth octets each converted to ASCII-decimal. The
			suffix, "p1.p2", is a textual form for representing a TCP and UDP
			service port. Assuming big-endian ordering, p1 and p2 are,
			respectively, the first and second octets each converted to ASCII-
			decimal. For example, if a host, in big-endian order, has an address
			of 0x0A010307 and there is a service listening on, in big endian
			order, port 0x020F (decimal 527), then the complete uaddr is
			"10.1.3.7.2.15".
			3.2.3.4. Uaddr Format for Most IPv6 Transports
			Most transport protocols that operate over IPv6 use 16 bit port
			numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
			[15]. The format of the uaddr for the above 16 bit port transports
			(when used over IPv6) is the US-ASCII string:
			x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
			The suffix "p1.p2" is the service port, and is computed the same way
			as with uaddrs for transports over IPv4 (see Section 3.2.3.3). The
			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 [3].
			Additionally, the two alternative forms specified in Section 2.2 of
			[3] are also acceptable.
			3.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6
			As ICMP is not a true transport, there is no uaddr format for ICMP.
			The netid assignments "icmp" and "icmp6" and their shared uaddr
			"format" are listed to prevent any registrant from allocating the
			netids "icmp" and "icmp6" for a purpose that would likely cause
			confusion.
			3.3. Cross Referencing Between the Netid and Format Registry
			The last field of the netids registry is used to cross reference with
			the last field of the format registry. IANA is under no obligation
			to maintain same numeric value in cross references when updating each
			registry; i.e. IANA is free to "re-number" these corresponding
			fields. However, if IANA does so, both the netid and format
			registries must be updated atomically.
	4. References		4. References
	4.1. Normative References		4.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",		[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
	RFC 1833, August 1995.		RFC 1833, August 1995.
			[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, February 2006.
	4.2. Informative References		4.2. Informative References
	[3] 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.
	[4] 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.
	[5] 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-08 (work in progress), April 2008.
	[6] 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.
	[7] American Telephone and Telegraph Company, "UNIX System V,		[8] 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.
	[8] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion		[9] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
	Control Protocol (DCCP)", RFC 4340, March 2006.		Control Protocol (DCCP)", RFC 4340, March 2006.
	[9] Postel, J., "DoD standard Internet Protocol", RFC 760,		[10] Postel, J., "DoD standard Internet Protocol", RFC 760,
	January 1980.		January 1980.
	[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[11] Postel, J., "Internet Control Message Protocol", RFC 777,		[12] Postel, J., "Internet Control Message Protocol", RFC 777,
	April 1981.		April 1981.
	[12] 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.
	[13] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of		[14] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of
	Internet Transmission Control Program", RFC 675, December 1974.		Internet Transmission Control Program", RFC 675, December 1974.
	[14] 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
			[RFC Editor: please remove this section prior to publication.]
			[RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx
			where xxxx is the RFC number assigned to the document referenced in
			[6].]
			[RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy
			where yyyy is the RFC number assigned to this document.]
	Author's Address		Author's Address
	Mike Eisler		Mike Eisler
	NetApp		NetApp
	5765 Chase Point Circle		5765 Chase Point Circle
	Colorado Springs, CO 80919		Colorado Springs, CO 80919
	US		US
	Phone: +1-719-599-9026		Phone: +1-719-599-9026
	Email: mike@eisler.com		Email: mike@eisler.com
End of changes. 41 change blocks.
	154 lines changed or deleted		332 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/