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/