--- 1/draft-ietf-nfsv4-rpc-netid-02.txt 2008-08-20 07:16:00.000000000 +0200 +++ 2/draft-ietf-nfsv4-rpc-netid-03.txt 2008-08-20 07:16:00.000000000 +0200 @@ -1,20 +1,20 @@ NFSv4 M. Eisler Internet-Draft NetApp Updates: 1833 (if approved) August 19, 2008 Intended status: Standards Track Expires: February 20, 2009 IANA Considerations for RPC Net Identifiers and Universal Address Formats - draft-ietf-nfsv4-rpc-netid-02.txt + draft-ietf-nfsv4-rpc-netid-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -121,22 +121,22 @@ Since netids are not constructed in an explicit hierarchical manner, this document does not provide for Hierarchical Allocation of netids. Nonetheless, the octet "." in a netid string is Reserved for future possible provision of Hierarchical Allocation. The registry of netids is a list of assignments, each containing five fields for each assignment. 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 - to 128 octets long. + NOT conflict with any other netid. This string name can be 1 to + 128 octets long. 2. A constant name that can be used for software programs that wish to use the transport protocol associated with protocol. The name of the constant typically has the prefix: 'NC_', and a suffix equal to the upper case version of the netid. This constant name should be a constant that is valid in the 'C' programming language. This constant name MUST NOT conflict with any other netid constant name. Constant names with the prefix "NC_STDS", "NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved. Constant names with a prefix of "NC_" and a total length of 11 characters or @@ -246,21 +246,21 @@ | "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 | | "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | 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 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 same constraints and review as with new registrations." 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 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. @@ -328,21 +328,21 @@ | 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 + The registrant is 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 @@ -372,27 +372,27 @@ 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". + suffix, "p1.p2", is a textual form for representing a 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 in hexadecimal of + 0xC0000207 and there is a service listening on, in big endian order, + port 0xCB51 (decimal 52049) then the complete uaddr is + "192.0.2.7.203.81". 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