draft-ietf-nfsv4-rpc-netid-00.txt		draft-ietf-nfsv4-rpc-netid-01.txt
	NFSv4 M. Eisler		NFSv4 M. Eisler
	Internet-Draft NetApp		Internet-Draft NetApp
	Intended status: Standards Track August 14, 2008		Updates: 1833 (if approved) August 18, 2008
	Expires: February 15, 2009		Intended status: Standards Track
			Expires: February 19, 2009
	IANA Considerations for RPC Net Identifiers		IANA Considerations for RPC Net Identifiers
	draft-ietf-nfsv4-rpc-netid-00.txt		draft-ietf-nfsv4-rpc-netid-01.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 34		skipping to change at page 1, line 35
	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 15, 2009.		This Internet-Draft will expire on February 19, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	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). This Internet-Draft updates, but does not
	replace, RFC1833.		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",
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	This section uses terms that are defined in [6].		This section uses terms that are defined in [6].
	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 [6].
	o RFC Required basis per section 4.1 of [6]. This RFC MUST be a		o Standards Action per section 4.1 of [6].
	Standards Track RFC, and so it is more precisely called the
	Standards Track RFC Required basis.
	Netids can be up to 2^31 - 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 zero to 8 octets long should be used		exhausted, the values of netids one to eight octets long should be
	for netids assigned on the Standards Track RFC Required basis.		used for netids assigned on the Standards Action basis. Assignments
	Assignments made on a First Come First Served basis should be		made on a First Come First Served basis should be assigned netids of
	assigned netids of length 9 to 128 octets more. All netids,		length 9 to 128 octets long. All netids, regardless of length, that
	regardless of length, that start with the prefixes "IETF" or "FCFS"		start with the prefixes "STDS" or "FCFS" are Reserved, in order to
	are Reserved, in order to extend the name space of either basis. In		extend the name space of either basis. In addition, to give IESG the
	addition, to give IESG the flexibility in the future to permit		flexibility in the future to permit Private and Experimental Uses,
	Private and Experimental Uses, all netids with the prefixes "PRIV" or		all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero
	"EXP" are Reserved. Exceptions to this policy can be authorized by a		length netid is Reserved. Some exceptions are listed in Table 2. A
	Designated Expert. 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 string 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 six
	fields for each First Come First Served assignment, and four fields		fields for each assignment made on a First Come First Served basis,
	for each Standards Track RFC Required 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_IETF",		netid constant name. Constant names starting with "NC_STDS",
	"NC_FCFS", "NC_PRIV", or "NC_EXP" 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 Track RFC		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. For assignments made on a First Come First Served basis a
	description, which can be up to 1024 US-ASCII characters (or more		description, which can be up to 1024 US-ASCII characters (or more
	if IANA permits) how the netid will be used. The description		if IANA permits) how the netid will be used. For assignments
	field is not included in assignments made on a Standards Track		made on a Standards Action basis, the description field is
	RFC Required basis.		provided to the Designated Expert to enable the review, but the
			description is not recorded in the registry, and IANA may dispose
			of the description once IESG approves the assignment.
	4. For assignments made on a First Come First Served basis, if		4. For assignments made on a First Come First Served basis, if
	applicable, a reference to a published description of the		applicable, a reference to a published description of the
	transport protocol (preferred), or a reference to a published use		transport protocol (preferred), or a reference to a published use
	of the transport protocol. This reference can consume up to 1024		of the transport protocol. This reference can consume up to 256
	octets (or more if IANA permits). For assignments made on a		octets (or more if IANA permits). For assignments made on a
	Standards Track RFC Required basis, the RFC number of the		Standards Action basis, the RFC number of the protocol the netid
	protocol the netid is associated with must be provided.		is associated with must be provided.
	5. For assignments made on a First Come First Served basis, if		5. For assignments made on a First Come First Served basis, if
	applicable, a reference to a published description of the network		applicable, a reference to a published description of the network
	protocol (preferred), or a reference to a published use of the		protocol (preferred), or a reference to a published use of the
	transport protocol. This reference can consume up to 1024 octets		transport protocol. This reference can consume up to 256 octets
	(or more if IANA permits). For assignments made on a Standards		(or more if IANA permits). For assignments made on a Standards
	Track RFC Required basis, if the previous field refers to a		Action basis, if the previous field refers to a transport
	transport protocol, the RFC number of the network protocol the		protocol, the RFC number of the network protocol the netid is
	netid is associated with must be provided.		associated with must be provided.
	6. For assignments made on a First Come First Served basis, a point		6. 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. The point of contact can
	consume up to 1024 octets (or more if IANA permits). Subject to		consume up to 256 octets (or more if IANA permits). Subject to
	authorization by a Designated Expert, the point of contact may be		authorization by a Designated Expert, the point of contact may be
	omitted for extraordinary situations, such as the registration of		omitted for extraordinary situations, such as the registration of
	a commonly used netid where the owner is in unknown. The point		a commonly used netid where the owner is in unknown. For
	of contact field is not included in assignments made on a		assignments made on a Standards Action basis the point of contact
	Standards Track RFC Required basis; however IESG, on the adviced		is always IESG.
	of a Designated Expert, must approve all assignments made on a
	Standards Track RFC Required basis, and thus is the implied point
	of contact for all such assignments.
	3.1. Initial Registry		3.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
	Track RFC Required basis in Table 2. These lists will change when		Action basis in Table 2. These lists will change when IANA registers
	IANA registers additional netids as needed, and the authoritative		additional netids as needed, and the authoritative list of registered
	list of registered netids will always live with IANA.		netids will always live with IANA.
	+-------------+--------------+---------------------+-----+----+-----+		+-------------+--------------+---------------------+-----+----+-----+
	| Netid | Constant | Description | PR | NR | PoC |		| Netid | Constant | Description | PR | NR | PoC |
	| | Name | | | | |		| | Name | | | | |
	+-------------+--------------+---------------------+-----+----+-----+		+-------------+--------------+---------------------+-----+----+-----+
	| "ticlts" | NC_TICLTS | The loop back | [7] | | |		| "ticlts" | NC_TICLTS | The loop back | [7] | | |
	| | | connectionless | | | |		| | | connectionless | | | |
	| | | transport used in | | | |		| | | transport used in | | | |
	| | | System V Release 4 | | | |		| | | System V Release 4 | | | |
	| | | and other operating | | | |		| | | and other operating | | | |
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	| | | System V Release 4 | | | |		| | | System V Release 4 | | | |
	| | | and other operating | | | |		| | | and other operating | | | |
	| | | systems. | | | |		| | | systems. | | | |
	+-------------+--------------+---------------------+-----+----+-----+		+-------------+--------------+---------------------+-----+----+-----+
	Table 1		Table 1
	PR: Protocol Reference. NR: Network protocol Reference. PoC: Point		PR: Protocol Reference. NR: Network protocol Reference. PoC: Point
	of Contact.		of Contact.
	+---------+---------------+--------------+--------------+		+---------+---------------+--------------+--------------+------+
	| Netid | Constant Name | PR | NR |		| Netid | Constant Name | PR | NR | PoC |
	+---------+---------------+--------------+--------------+		+---------+---------------+--------------+--------------+------+
	| "-" | NC_NOPROTO | RFC1833 [2] | |		| "-" | NC_NOPROTO | RFC1833 [2] | | IESG |
	| "dccp" | NC_DCCP | RFC4340 [8] | RFC0760 [9] |		| "dccp" | NC_DCCP | RFC4340 [8] | RFC0760 [9] | IESG |
	| "dccp6" | NC_DCCP6 | RFC4340 [8] | RFC2460 [10] |		| "dccp6" | NC_DCCP6 | RFC4340 [8] | RFC2460 [10] | IESG |
	| "icmp" | NC_ICMP | RFC0777 [11] | RFC0760 [9] |		| "icmp" | NC_ICMP | RFC0777 [11] | RFC0760 [9] | IESG |
	| "icmp6" | NC_ICMP6 | RFC0777 [11] | RFC2460 [10] |		| "icmp6" | NC_ICMP6 | RFC0777 [11] | RFC2460 [10] | IESG |
	| "rdma" | NC_RDMA | RFCTBD1 [5] | RFC0760 [9] |		| "rdma" | NC_RDMA | RFCTBD1 [5] | RFC0760 [9] | IESG |
	| "rdma6" | NC_RDMA6 | RFCTBD1 [5] | RFC2460 [10] |		| "rdma6" | NC_RDMA6 | RFCTBD1 [5] | RFC2460 [10] | IESG |
	| "sctp" | NC_SCTP | RFC2960 [12] | RFC0760 [9] |		| "sctp" | NC_SCTP | RFC2960 [12] | RFC0760 [9] | IESG |
	| "sctp6" | NC_SCTP6 | RFC2960 [12] | RFC2460 [10] |		| "sctp6" | NC_SCTP6 | RFC2960 [12] | RFC2460 [10] | IESG |
	| "tcp" | NC_TCP | RFC0675 [13] | RFC0760 [9] |		| "tcp" | NC_TCP | RFC0675 [13] | RFC0760 [9] | IESG |
	| "tcp6" | NC_TCP6 | RFC0675 [13] | RFC2460 [10] |		| "tcp6" | NC_TCP6 | RFC0675 [13] | RFC2460 [10] | IESG |
	| "udp" | NC_UDP | RFC0768 [14] | RFC0760 [9] |		| "udp" | NC_UDP | RFC0768 [14] | RFC0760 [9] | IESG |
	| "udp6" | NC_UDP6 | RFC0768 [14] | RFC2460 [10] |		| "udp6" | NC_UDP6 | RFC0768 [14] | RFC2460 [10] | IESG |
	+---------+---------------+--------------+--------------+		+---------+---------------+--------------+--------------+------+
	Table 2		Table 2
	3.2. Updating Registrations		3.2. Updating Registrations
	Per section 5.2 of [6] the point of contact is always permitted to		Per section 5.2 of [6] the point of contact 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
	any registration made on a First Come First Served basis. Only IESG,		any registration made on a First Come First Served basis, which
	on the advice of a Designated Expert, can update a registration made		normally is done when the PoC cannot be reached in order to make
	on a Standards Track RFC Required basis.		necessary updates. Examples where an update would be needed
			included, but are not limited to: the email address or other contact
			information becomes invalid; the reference to the corresponding
			protocol becomes obsolete or unavailable; and RFC1833 [2] is updated
			or replaced in such a way that the scope of netids 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.
	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.
	skipping to change at page 9, line 44		skipping to change at line 362
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 20 change blocks.
	67 lines changed or deleted		69 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/