One document matched: draft-ietf-nfsv4-rpc-netid-01.txt
Differences from draft-ietf-nfsv4-rpc-netid-00.txt
NFSv4 M. Eisler
Internet-Draft NetApp
Updates: 1833 (if approved) August 18, 2008
Intended status: Standards Track
Expires: February 19, 2009
IANA Considerations for RPC Net Identifiers
draft-ietf-nfsv4-rpc-netid-01.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
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2009.
Abstract
This Internet-Draft lists IANA Considerations for RPC Network
Identifiers (netids). This Internet-Draft updates, but does not
replace, RFC1833.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Eisler Expires February 19, 2009 [Page 1]
Internet-Draft RPC Netids August 2008
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3
2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Initial Registry . . . . . . . . . . . . . . . . . . . . . 5
3.2. Updating Registrations . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . . 7
4.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Eisler Expires February 19, 2009 [Page 2]
Internet-Draft RPC Netids August 2008
1. Introduction and Motivation
The concept of an RPC ([3]) Network Identifier (netid) was introduced
in [2] for distinguishing universal network addresses of multiple
protocols. [2] states that a netid ``is defined by a system
administrator based on local conventions, and cannot be depended on
to have the same value on every system.'' Since the publication of
RFC1833, it has been found to be necessary that protocols like [4]
and [5] depend on consistent values of netids across every system,
and current practices tend to ensure this consistency. Thus, this
document identifies the considerations for IANA to establish a
registry of netids for RPC and specifies the initial content of the
registry.
2. Security Considerations
See section 9 of [6].
3. IANA Considerations
This section uses terms that are defined in [6].
IANA will create a registry called "ONC RPC Netids". The remainder
of this section describes the registry.
All assignments to the ONC RPC Netids registry are made on one of two
bases:
o First Come First Served basis per section 4.1 of [6].
o Standards Action per section 4.1 of [6].
Netids can be up to 2^32 - 1 octets in length. However, to ensure
that practical values for Standards Track protocols are not
exhausted, the values of netids one to eight octets long should be
used for netids assigned on the Standards Action basis. Assignments
made on a First Come First Served basis should be assigned netids of
length 9 to 128 octets long. All netids, regardless of length, that
start with the prefixes "STDS" or "FCFS" are Reserved, in order to
extend the name space of either basis. In addition, to give IESG the
flexibility in the future to permit Private and Experimental Uses,
all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero
length netid is Reserved. Some exceptions are listed in Table 2. A
recommended convention for netids corresponding to transports that
work over the IPv6 protocol is to have "6" as the last character in
the netid string name.
Eisler Expires February 19, 2009 [Page 3]
Internet-Draft RPC Netids August 2008
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 six
fields for each assignment made on a First Come First Served basis,
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
NOT conflict with any other netid. This string name can be zero
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 starting with "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
less should be for assignments made on the Standards Action
basis. The constant name can be 1 to 131 octets long.
3. For assignments made on a First Come First Served basis a
description, which can be up to 1024 US-ASCII characters (or more
if IANA permits) how the netid will be used. For assignments
made on a Standards Action basis, the description field is
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
applicable, a reference to a published description of the
transport protocol (preferred), or a reference to a published use
of the transport protocol. This reference can consume up to 256
octets (or more if IANA permits). For assignments made on a
Standards Action basis, the RFC number of the protocol the netid
is associated with must be provided.
5. For assignments made on a First Come First Served basis, if
applicable, a reference to a published description of the network
protocol (preferred), or a reference to a published use of the
transport protocol. This reference can consume up to 256 octets
(or more if IANA permits). For assignments made on a Standards
Action basis, if the previous field refers to a transport
Eisler Expires February 19, 2009 [Page 4]
Internet-Draft RPC Netids August 2008
protocol, the RFC number of the network protocol the netid is
associated with must be provided.
6. For assignments made on a First Come First Served basis, a point
of contact, including an email address. The point of contact can
consume up to 256 octets (or more if IANA permits). Subject to
authorization by a Designated Expert, the point of contact may be
omitted for extraordinary situations, such as the registration of
a commonly used netid where the owner is in unknown. For
assignments made on a Standards Action basis the point of contact
is always IESG.
3.1. Initial Registry
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
Action basis in Table 2. These lists will change when IANA registers
additional netids as needed, and the authoritative list of registered
netids will always live with IANA.
+-------------+--------------+---------------------+-----+----+-----+
| Netid | Constant | Description | PR | NR | PoC |
| | Name | | | | |
+-------------+--------------+---------------------+-----+----+-----+
| "ticlts" | NC_TICLTS | The loop back | [7] | | |
| | | connectionless | | | |
| | | transport used in | | | |
| | | System V Release 4 | | | |
| | | and other operating | | | |
| | | systems. Although | | | |
| | | this assignment is | | | |
| | | made on a First | | | |
| | | Come First Served | | | |
| | | basis and is fewer | | | |
| | | than 9 characters | | | |
| | | log, the exception | | | |
| | | is authorized. | | | |
Eisler Expires February 19, 2009 [Page 5]
Internet-Draft RPC Netids August 2008
| "ticots" | NC_TICOTS | The loop back | [7] | | |
| | | connection-oriented | | | |
| | | transport used in | | | |
| | | System V Release 4 | | | |
| | | and other operating | | | |
| | | systems. Although | | | |
| | | this assignment is | | | |
| | | made on a First | | | |
| | | Come First Served | | | |
| | | basis and is fewer | | | |
| | | than 9 characters | | | |
| | | log, the exception | | | |
| | | is authorized. | | | |
| "ticotsord" | NC_TICOTSORD | The loop back | [7] | | |
| | | connection-oriented | | | |
| | | with | | | |
| | | orderly-release | | | |
| | | transport used in | | | |
| | | System V Release 4 | | | |
| | | and other operating | | | |
| | | systems. | | | |
+-------------+--------------+---------------------+-----+----+-----+
Table 1
PR: Protocol Reference. NR: Network protocol Reference. PoC: Point
of Contact.
+---------+---------------+--------------+--------------+------+
| Netid | Constant Name | PR | NR | PoC |
+---------+---------------+--------------+--------------+------+
| "-" | NC_NOPROTO | RFC1833 [2] | | IESG |
| "dccp" | NC_DCCP | RFC4340 [8] | RFC0760 [9] | IESG |
| "dccp6" | NC_DCCP6 | RFC4340 [8] | RFC2460 [10] | IESG |
| "icmp" | NC_ICMP | RFC0777 [11] | RFC0760 [9] | IESG |
| "icmp6" | NC_ICMP6 | RFC0777 [11] | RFC2460 [10] | IESG |
| "rdma" | NC_RDMA | RFCTBD1 [5] | RFC0760 [9] | IESG |
| "rdma6" | NC_RDMA6 | RFCTBD1 [5] | RFC2460 [10] | IESG |
| "sctp" | NC_SCTP | RFC2960 [12] | RFC0760 [9] | IESG |
| "sctp6" | NC_SCTP6 | RFC2960 [12] | RFC2460 [10] | IESG |
| "tcp" | NC_TCP | RFC0675 [13] | RFC0760 [9] | IESG |
| "tcp6" | NC_TCP6 | RFC0675 [13] | RFC2460 [10] | IESG |
| "udp" | NC_UDP | RFC0768 [14] | RFC0760 [9] | IESG |
| "udp6" | NC_UDP6 | RFC0768 [14] | RFC2460 [10] | IESG |
+---------+---------------+--------------+--------------+------+
Table 2
Eisler Expires February 19, 2009 [Page 6]
Internet-Draft RPC Netids August 2008
3.2. Updating Registrations
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
"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
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.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995.
4.2. Informative References
[3] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
[4] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003.
[5] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
Transport for Remote Procedure Call",
draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[7] American Telephone and Telegraph Company, "UNIX System V,
Release 4 Programmer's Guide: Networking Interfaces, ISBN
0139470786", 1990.
Eisler Expires February 19, 2009 [Page 7]
Internet-Draft RPC Netids August 2008
[8] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[9] Postel, J., "DoD standard Internet Protocol", RFC 760,
January 1980.
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[11] Postel, J., "Internet Control Message Protocol", RFC 777,
April 1981.
[12] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[13] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of
Internet Transmission Control Program", RFC 675, December 1974.
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
Author's Address
Mike Eisler
NetApp
5765 Chase Point Circle
Colorado Springs, CO 80919
US
Phone: +1-719-599-9026
Email: mike@eisler.com
Eisler Expires February 19, 2009 [Page 8]
Internet-Draft RPC Netids August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Eisler Expires February 19, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-19 00:17:31 |