[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 5665

NFSv4                                                          M. Eisler
Internet-Draft                                                    NetApp
Intended status: Standards Track                         August 14, 2008
Expires: February 15, 2009


              IANA Considerations for RPC Net Identifiers
                   draft-ietf-nfsv4-rpc-netid-00.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 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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



Eisler                  Expires February 15, 2009               [Page 1]

Internet-Draft                 RPC Netids                    August 2008


   document are to be interpreted as described in RFC 2119 [1].


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 15, 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  RFC Required basis per section 4.1 of [6].  This RFC MUST be a
      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
   that practical values for Standards Track protocols are not
   exhausted, the values of netids zero to 8 octets long should be used
   for netids assigned on the Standards Track RFC Required basis.
   Assignments made on a First Come First Served basis should be
   assigned netids of length 9 to 128 octets more.  All netids,
   regardless of length, that start with the prefixes "IETF" 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
   "EXP" are Reserved.  Exceptions to this policy can be authorized by a
   Designated Expert.  Some exceptions are listed in Table 2.  A



Eisler                  Expires February 15, 2009               [Page 3]

Internet-Draft                 RPC Netids                    August 2008


   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.

   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 First Come First Served assignment, and four fields
   for each Standards Track RFC Required 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.

   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_IETF",
       "NC_FCFS", "NC_PRIV", or "NC_EXP" 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 Track RFC
       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.  The description
       field is not included in assignments made on a Standards Track
       RFC Required basis.

   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 1024
       octets (or more if IANA permits).  For assignments made on a
       Standards Track RFC Required 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 1024 octets
       (or more if IANA permits).  For assignments made on a Standards



Eisler                  Expires February 15, 2009               [Page 4]

Internet-Draft                 RPC Netids                    August 2008


       Track RFC Required basis, if the previous field refers to a
       transport 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 1024 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.  The point
       of contact field is not included in assignments made on a
       Standards Track RFC Required basis; however IESG, on the adviced
       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

   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
   Track RFC Required 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 15, 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           |
         +---------+---------------+--------------+--------------+
         | "-"     | NC_NOPROTO    | RFC1833 [2]  |              |
         | "dccp"  | NC_DCCP       | RFC4340 [8]  | RFC0760 [9]  |
         | "dccp6" | NC_DCCP6      | RFC4340 [8]  | RFC2460 [10] |
         | "icmp"  | NC_ICMP       | RFC0777 [11] | RFC0760 [9]  |
         | "icmp6" | NC_ICMP6      | RFC0777 [11] | RFC2460 [10] |
         | "rdma"  | NC_RDMA       | RFCTBD1 [5]  | RFC0760 [9]  |
         | "rdma6" | NC_RDMA6      | RFCTBD1 [5]  | RFC2460 [10] |
         | "sctp"  | NC_SCTP       | RFC2960 [12] | RFC0760 [9]  |
         | "sctp6" | NC_SCTP6      | RFC2960 [12] | RFC2460 [10] |
         | "tcp"   | NC_TCP        | RFC0675 [13] | RFC0760 [9]  |
         | "tcp6"  | NC_TCP6       | RFC0675 [13] | RFC2460 [10] |
         | "udp"   | NC_UDP        | RFC0768 [14] | RFC0760 [9]  |
         | "udp6"  | NC_UDP6       | RFC0768 [14] | RFC2460 [10] |
         +---------+---------------+--------------+--------------+

                                  Table 2




Eisler                  Expires February 15, 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.  Only IESG,
   on the advice of a Designated Expert, can update a registration made
   on a Standards Track RFC Required 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.

   [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)



Eisler                  Expires February 15, 2009               [Page 7]

Internet-Draft                 RPC Netids                    August 2008


         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 15, 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Eisler                  Expires February 15, 2009               [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/