One document matched: draft-iesg-iana-considerations-00.txt

INTERNET-DRAFT                                             Thomas Narten
                                                                     IBM
<draft-iesg-iana-considerations-00.txt>          Harald Tveit Alvestrand
                                                                 UNINETT
                                                         October 6, 1997

       Guidelines for Writing an IANA Considerations Section in RFCs

                 <draft-iesg-iana-considerations-00.txt>


Status of this Memo

   This document is an Internet-Draft. 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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft expires April 6, 1998.


Abstract

   Many protocols make use of identifiers consisting of constants and
   other well-known values. Even after a protocol has been defined and
   deployment has begun, new values may need to be assigned (e.g., a new
   option type in DHCP).  To insure that such quantities have unique
   values, their assignment must be administered by a central authority.
   In the Internet, that role is provided by the Internet Assigned
   Numbers Authority (IANA).

   In order for the IANA to manage a given numbering space prudently, it
   needs guidelines describing the conditions under which new values can
   be assigned. If the IANA is expected to play a role in the management
   of a numbering space, the IANA must be given clear and concise



draft-iesg-iana-considerations-00.txt                         [Page 1]

INTERNET-DRAFT                                           October 6, 1997


   guidelines describing that role.  This document discusses issues that
   should be considered in formulating an identifier assignment policy
   and provides guidelines to document authors on the specific text that
   must be included in documents that place demands on the IANA.















































draft-iesg-iana-considerations-00.txt                         [Page 2]

INTERNET-DRAFT                                           October 6, 1997


   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    3

   2.  Issues To Consider.......................................    4

   3.  What To Put In Documents.................................    6

   4.  Security Considerations..................................    6

   5.  References...............................................    6

   6.  Authors' Addresses.......................................    7


1.  Introduction

   Many protocols make use of fields that contain constants and other
   well-known values (e.g., the Protocol field in the IP header [IP] or
   MIME types in mail messages [MIME]). Even after a protocol has been
   defined and deployment has begun, new values may need to be assigned
   (e.g., a new option type in DHCP [DHCP]).  To insure that such fields
   have unique values, their assignment must be administered by a
   central authority. In the Internet, that role is provided by the
   Internet Assigned Numbers Authority (IANA).

   In order for the IANA to manage a given numbering space prudently, it
   needs guidelines describing the conditions under which new values
   should be assigned. This document provides guidelines to authors on
   what sort of text should be added to their documents, and reviews
   issues that should be considered in formulating an appropriate policy
   for assigning identifiers.

   Not all name spaces require centralized administration. In some
   cases, it is possible to delegate a name space in such a way that
   further assignments can be made independently and with no further
   (central) coordination. In the Domain Name System, for example, the
   IANA only deals with assignments at the higher-levels, while
   subdomains are administered by the organization to which the space
   has been delegated. As another example, Object Identifiers (OIDs) as
   defined by the ITU are also delegated [XXX reference].  When a name
   space can be delegated, the IANA only deals with assignments at the
   top level.






draft-iesg-iana-considerations-00.txt                         [Page 3]

INTERNET-DRAFT                                           October 6, 1997


2.  Issues To Consider

   The primary issue to consider in managing a numbering space is its
   size. If the space is small and limited in size, assignments must be
   made carefully to insure that the space doesn't become exhausted. On
   the other hand, it may be perfectly reasonable to hand out new values
   to anyone that wants one, if the space is essentially unlimited. Even
   when the space is essentially unlimited, however, it may be desirable
   to have a minimal review to prevent hoarding of the space. For
   example, if the space consists of text strings, it may be desirable
   to prevent organizations from obtaining large sets of strings that
   correspond to the "best" names (e.g., existing company names).

   A second consideration is whether it makes sense to delegate the name
   space in some manner. This route should be pursued when appropriate,
   as it lessens the burden on the IANA for dealing with assignments.

   In most cases, some review of prospective allocations is appropriate,
   and the first question to answer is who should perform the review.
   In some cases, it is reasonable for the IANA to review prospective
   assignments.  In such cases, the IANA will need specific guidelines
   on what types of requests it should grant, and what information must
   be provided before a request of an assigned number will be
   considered. Note that the IANA will not define such a policy; it
   should be given a set of guidelines that allow it to make allocation
   decisions with little subjectivity. The following are example
   policies, some of which are in use today:

      Free For All - For local use only, with the type and purpose
             defined by the local site. No attempt is made to prevent
             multiple sites from using the same value in different (and
             incompatible) ways. There is no need for IANA to review
             such assignments and assignments are not generally useful
             for interoperability.

             Examples: Site-specific options in DHCP [DHCP] have
             significance only within a single site.

      Hierarchical allocation - Delegated managers can assign
             identifiers provided they have been given control over that
             part of the identifier space.  IANA controls the top levels
             of the namespace according to one of the other policies.

             Examples: DNS names

      First Come First Served - Anyone can obtain an identifier, so long
             as they provide a point of contact and a brief description
             of what the identifier would be used for.  For numbers, the



draft-iesg-iana-considerations-00.txt                         [Page 4]

INTERNET-DRAFT                                           October 6, 1997


             exact value is generally assigned by the IANA, with names,
             specific names are usually requested.

             Examples: MIME types, TCP and UDP port numbers.

      Documentation Required - Values and their meaning must be
             documented in an RFC or other permanent reference, in
             sufficient detail so that interoperability between
             independent implementations is possible.

             Examples: XXX

      IESG Action - IESG must explicitly approve new values.

             Examples: XXX

      Standards Action - Only identifiers that have been documented in
             standards track RFCs approved by the IESG will be
             registered.

             Examples: XXX

   In some cases, it may be appropriate for the IANA to serve as a
   point-of-contact for publishing information about numbers that have
   been assigned, without actually having it evaluate and grant
   requests.  For example, it is useful (and sometimes necessary) to
   discuss proposed additions on a mailing list dedicated to the purpose
   (e.g., the ietf-types@iana.org for media types) or on a mailing list
   associated with an IETF Working Group.  Since the IANA cannot
   participate in all of these mailing lists and cannot determine if or
   when such discussion reaches a consensus, the IANA will rely on a
   designated subject matter expert to advise it in these matters.
   Consequently, the IANA should be directed to forward the requests it
   receives to a specific point-of-contact or mailing list (i.e., a
   mailing list set up specifically for the purpose of discussing such
   requests) and act upon the returned recommendation from the
   designated subject matter expert. In all cases, it is the designated
   subject matter expert that the IANA relies on for an authoritative
   response.

   Of course, combinations of the above are also possible. When defining
   new DHCP option types [DHCP], for example, the IANA assigns options
   to anyone, with the stipulation that the number will be returned to
   the IANA should the option fail to gain acceptance.

   In some cases, it may make sense to partition the number space into
   several categories, with assignments out of each category handled
   differently. For example, the DHCP option space [DHCP] is split into



draft-iesg-iana-considerations-00.txt                         [Page 5]

INTERNET-DRAFT                                           October 6, 1997


   two parts. Option numbers in the range of 1-127 are globally unique
   and assigned according to the Documentation Required policy described
   earlier, while options number 128-254 are "site specific", i.e., Free
   For All.


3.  What To Put In Documents

   The previous section presented some issues that should be considered
   in formulating a policy for assigning well-known numbers and other
   protocol constants. It is the Working Group and/or document author's
   job to formulate an appropriate policy and specify it in the
   appropriate document. In some cases, having an "IANA Considerations"
   section may be appropriate. Such a section should state clearly:

      - who reviews an application for an assigned number. If a request
        should be reviewed by a designated subject matter expert,
        contact information for that person should be provided. If the
        request should also be reviewed by a specific mailing list (such
        as the ietf-types@iana.org for media types), that mailing
        address should be specified.

      - if the IANA is expected to review requests itself, sufficient
        guidance must be provided so that the requests can be evaluated
        with minimal subjectivity.

   Finally, it is quite acceptable to pick one of the example policies
   cited above and refer to it by name.  For example, a document could
   say something like:

        numbers are allocated as First Come First Served as defined in
        [RFC ASSIGN]

   XXX: give pointers to 3 or 4 particularly good examples in existing
   RFCs?  1) DHCP options seems reasonable.  Others?


4.  Security Considerations

   There are no known security issues raised by this document.

5.  References

     [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP
             Vendor Extensions, RFC 2132, March 1997.

     [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981.




draft-iesg-iana-considerations-00.txt                         [Page 6]

INTERNET-DRAFT                                           October 6, 1997


     [MIME] N. Freed, J. Klensin & J. Postel, Multipurpose Internet Mail
             Extension (MIME) Part Four: Registration Procedures. RFC
             2048, November, 1996.




6.  Authors' Addresses

   Thomas Narten
   IBM Corporation
   3039 Cornwallis Ave.
   PO Box 12195 - BRQA/502
   Research Triangle Park, NC 27709-2195

   Phone: 919-254-7798
   EMail: narten@raleigh.ibm.com

   Harald Tveit Alvestrand
   UNINETT
   P.O.Box 6883 Elgeseter
   N-7002 TRONDHEIM
   NORWAY

   Phone: +47 73 59 70 94
   EMail: Harald.T.Alvestrand@uninett.no

























draft-iesg-iana-considerations-00.txt                         [Page 7]