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/