draft-ietf-nfsv4-rpc-netid-02.txt		draft-ietf-nfsv4-rpc-netid-03.txt
	NFSv4 M. Eisler		NFSv4 M. Eisler
	Internet-Draft NetApp		Internet-Draft NetApp
	Updates: 1833 (if approved) August 19, 2008		Updates: 1833 (if approved) August 19, 2008
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 20, 2009		Expires: February 20, 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-02.txt		draft-ietf-nfsv4-rpc-netid-03.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 4, line 20		skipping to change at page 4, line 20
	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 five		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. 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 1 to
	to 128 octets long.		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 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", 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
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |		| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |
	| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |		| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |
	| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |		| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |
	| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |		| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |
	+---------+--------------+------------------------------+------+----+		+---------+--------------+------------------------------+------+----+
	Table 2: Initial Standards Action Netid Assignments		Table 2: Initial Standards Action Netid Assignments
	3.1.2. Updating Registrations		3.1.2. Updating Registrations
	Per section 5.2 of [7] the registrant always permitted to update a		Per section 5.2 of [7] the registrant is always permitted to update a
	registration made on a First Come First Served basis "subject to the		registration made on a First Come First Served basis "subject to the
	same constraints and review as with new registrations." IESG or a		same constraints and review as with new registrations." IESG or a
	Designated Expert is permitted to update any registration made on a		Designated Expert is permitted to update any registration made on a
	First Come First Served basis, which normally is done when the PoC		First Come First Served basis, which normally is done when the PoC
	cannot be reached in order to make necessary updates. Examples where		cannot be reached in order to make necessary updates. Examples where
	an update would be needed include, but are not limited to: the email		an update would be needed include, but are not limited to: the email
	address or other contact information becomes invalid; the reference		address or other contact information becomes invalid; the reference
	to the corresponding protocol becomes obsolete or unavailable; and		to the corresponding protocol becomes obsolete or unavailable; and
	RFC1833 [2] is updated or replaced in such a way that the scope of		RFC1833 [2] is updated or replaced in such a way that the scope of
	netids changes, requiring additional fields in the assignment.		netids changes, requiring additional fields in the assignment.
	skipping to change at page 8, line 40		skipping to change at page 8, line 40
	| STDS | Uaddr format for IPv6 transports. | IESG | 3 |		| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
	| | Section 3.2.3.4 of RFCTBD2 | | |		| | Section 3.2.3.4 of RFCTBD2 | | |
	| STDS | Uaddr formation for ICMP. Section 3.2.3.5 of | IESG | 4 |		| STDS | Uaddr formation for ICMP. Section 3.2.3.5 of | IESG | 4 |
	| | RFCTBD2 | | |		| | RFCTBD2 | | |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	Table 3: Initial Format Assignments		Table 3: Initial Format Assignments
	3.2.2. Updating Registrations		3.2.2. Updating Registrations
	The registrant 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.", but as with new registrations,
	any requested changes to any field other the point of contact		any requested changes to any field other the point of contact
	requires Expert Review. IESG or a Designated Expert is permitted to		requires Expert Review. IESG or a Designated Expert is permitted to
	update any registration made on a First Come First Served basis,		update any registration made on a First Come First Served basis,
	which normally is done when the PoC cannot be reached in order to		which normally is done when the PoC cannot be reached in order to
	make necessary updates. Examples where an update would be needed		make necessary updates. Examples where an update would be needed
	include, but are not limited to: the email address or other contact		include, but are not limited to: the email address or other contact
	information becomes invalid; the reference to the format description		information becomes invalid; the reference to the format description
	becomes obsolete or unavailable; and RFC1833 [2] is updated or		becomes obsolete or unavailable; and RFC1833 [2] is updated or
	skipping to change at page 9, line 36		skipping to change at page 9, line 36
	numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP		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		[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 TCP and UDP		suffix, "p1.p2", is a textual form for representing a service port.
	service port. Assuming big-endian ordering, p1 and p2 are,		Assuming big-endian ordering, p1 and p2 are, respectively, the first
	respectively, the first and second octets each converted to ASCII-		and second octets each converted to ASCII-decimal. For example, if a
	decimal. For example, if a host, in big-endian order, has an address		host, in big-endian order, has an address in hexadecimal of
	of 0x0A010307 and there is a service listening on, in big endian		0xC0000207 and there is a service listening on, in big endian order,
	order, port 0x020F (decimal 527), then the complete uaddr is		port 0xCB51 (decimal 52049) then the complete uaddr is
	"10.1.3.7.2.15".		"192.0.2.7.203.81".
	3.2.3.4. Uaddr Format for Most IPv6 Transports		3.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 [9], 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
End of changes. 5 change blocks.
	12 lines changed or deleted		12 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/