[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 4020

Network Working Group                                        K. Kompella
Internet Draft                                          Juniper Networks
Proposed Category: Best Current Practice                        A. Zinin
                                                                 Alcatel
Expires: December 2004                                         June 2004


          Early IANA Allocation of Standards Track Codepoints
              draft-kompella-zinin-early-allocation-02.txt


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668

   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.



Abstract

   This memo discusses earlier allocation of code points by IANA as a
   remedy to the problem created by the "Standards Action" IANA policy
   for protocols where, by the IETF process, implementation and
   deployment experience is desired or required prior to publication.









Kompella & Zinin          Best Current Practice                 [Page 1]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


1. Introduction

   In Standards Track RFCs, there is often the need to allocate code
   points for various objects, messages or other protocol entities so
   that implementations can interoperate.  Many of these code point
   spaces have registries handled by the Internet Assigned Number
   Authority (IANA).  Several IANA allocation policies are described in
   RFC 2434 [2434].  Some of them, such as First Come First Served or
   Expert Review, do not require a formal IETF action before the IANA
   performs allocation.  However, in situations where codepoints are a
   scarce resource and/or the IETF community is willing to retain tight
   control of the protocol, policies such as IESG Approval, IETF
   Consensus, or Standards Action have been used.  The Standards Action
   policy represents a problem in situations where implementation and/or
   deployment experience are desired or required for the Standards
   Action.

   To break the deadlock, "pre-RFC" implementations simply choose some
   code points; these may turn out to be different from those later
   assigned by IANA.  To make matters worse, these "pre-RFC"
   implementations are often deployed.  This creates several potential
   inteoperability problems between early implementations and
   implementations of the final standard as described below:

   1. IANA allocates codepoints different from what early
      implementations assumed would be allocated.  Early implementations
      won't interoperate with standard ones.

   2. IANA allocates codepoints silently used for other extensions.
      Different extensions will collide.

   This gets in the way of the main purpose of standards, namely to
   facilitate interoperable implementations.

   It is easy to say that pre-RFC implementations should be kept private
   and not be deployed; however, both the length of the standards
   process as well as the immense value of early implementations and
   early deployments suggest finding a better solution.  As an example,
   in the case of documents produced by Working Groups in the Routing
   Area, a pre-RFC implementation is highly desirable and sometimes even
   required, and early deployments provide useful feedback on the
   technical and operational quality of the specification.

   This memo proposes that, under strictly controlled circumstances,
   IANA makes an early allocation of code points.  The memo lays out the
   conditions for early allocation as well as the process to be
   followed; it also says how such allocations are dealt with in the
   event of a failure in the process (such as the RFC not being



Kompella & Zinin          Best Current Practice                 [Page 2]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


   published).

   This memo only addresses the early allocation of code points from
   spaces whose allocation policy is "Standards Action" [2434] AND have
   been amended to permit early allocation.  This permission must be
   granted by the IESG, and code spaces with permission for early
   allocation must be marked as such in the IANA registry.


2. Conditions for Early Allocation

   The following conditions must hold before a request may be made for
   early allocation of code points:

   a) The code points must be from a space designated as "Standards
      Action", amended by IESG approval to permit Early Allocation.

   b) The format, semantics, processing and other rules related to
      handling the protocol entities defined by the code points
      (henceforth called "specifications") must be adequately described
      in an Internet draft that is proposed as Standards Track.

   c) The specifications of these code points must be stable, i.e., if
      there is a change, implementations based on the earlier and later
      specifications must be seamlessly interoperable.

   d) There is sufficient interest in early (pre-RFC) implementation and
      deployment in the community.

   If conditions (a) or (b) are not met, then the processes in this memo
   do not apply.


3. Process for Early Allocation

   There are three processes associated with early allocation: making
   the request for code points; following up on the request; and
   revoking an early allocation.  It cannot be emphasized enough that
   these processes must have a minimal impact on IANA itself, or they
   will not be feasible.

   The processes as described below assume that the document in question
   is the product of an IETF Working Group.  If this is not the case,
   replace "WG chairs" below by "shepherding Area Director".







Kompella & Zinin          Best Current Practice                 [Page 3]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


3.1. Request

   The process for requesting and obtaining early allocation of code
   points is as follows:

   1) The authors (editors) of the document submit a request for early
      allocation to the Working Group chairs, specifying which code
      points require early allocation and which document they should be
      assigned to.

   2) The WG chairs determine whether the conditions for early
      allocations described in section 2 are met, particularly
      conditions (c) and (d).

   3) The WG chairs gauge whether there is consensus within the WG that
      early allocation is appropriate in the case of the given document.

   4) If so, with the approval of the Area Director(s), the WG chairs
      request IANA to make an early allocation.

   5) IANA makes an allocation from the appropriate registry, marking it
      as "temporary", valid for a period of one year from the date of
      allocation. The date of allocation should also be recorded in the
      registry and made visible to the public.

   Note that Internet Drafts should not include a specific value of a
   code-point until such value has been formally allocated by IANA.

3.2. Follow-up

   It is the responsibility of the document authors and the Working
   Group chairs to review changes in the document, and especially in the
   specifications of the code points for which early allocation was
   requested to ensure that the changes are backwards compatible.

   If at some point changes that are not backwards compatible are
   nonetheless required, a decision needs to be made whether previously
   allocated codepoints must be deprecated or not (see section 3.3 for
   more information on codepoint deprecation).  The considerations
   include such aspects as possibility of existing deployments of the
   older implementations and hence the possibility for a collision
   between older and newer implementations in the field.

   If the document progresses to the point when IANA normally makes code
   point allocations, it is the responsibility of the authors and the WG
   chairs to remind IANA that there were early allocations, and of the
   code point values so allocated, in the IANA Considerations section of
   the RFC-to-be.  Allocation is then just a matter of removing the



Kompella & Zinin          Best Current Practice                 [Page 4]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


   "temporary" tag from the allocation description.

3.3. Expiry

   If early allocations expire before the document progresses to the
   point where IANA normally makes allocations, the authors and WG
   chairs may follow an abbreviated version of the process in section
   3.1 to request renewal of the code points.  At most one renewal
   request may be made; thus, authors should choose carefully when the
   original request is to be made.

   As an exception to the above rule, under rare circumstances, more
   than one allocation renewal may be justified. All such renewal
   requests must be reviewed by the IESG. The renewal request to the
   IESG must include the reasons why such renewal is necessary, and what
   the WG's plans are regarding the specification.

   If a follow-up request is not made, or the document fails to progress
   to a Standards Track RFC, the WG chairs are responsible for informing
   IANA that the code points are to be marked "deprecated" (and are not
   to be allocated); the WG chairs are further responsible for informing
   IANA when the deprecated code points can be completely de-allocated
   (i.e., made available for new allocations).

   In particular, it is not IANA's responsibility to track the status of
   allocations or when they expire or when they may be re-allocated.

   Note that if a document is submitted for review to the IESG and at
   the time of submission some early allocations are valid (not
   expired), these allocations should not be expired while the document
   is under IESG consideration or waiting in the RFC Editor's queue
   after the approval by the IESG.


4. IANA Considerations

   This document defines procedures for early allocation of codepoints
   in the registries with the Standards Action policy, and as such
   directly affects IANA functions.












Kompella & Zinin          Best Current Practice                 [Page 5]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


Normative References

   [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998



Security Considerations

   It is important to keep in mind 'denial of service' attacks on IANA
   as a result of the processes in this memo.  There are two that
   immediately obvious: depletion of code space by early allocations;
   and process overloading of IANA itself.  The processes described here
   attempt to alleviate both of these, but they should be subject to
   scrutiny to ensure this.


Acknowledgments

   Many thanks to Bert Wijnen, Adrian Farrel and Bill Fenner for their
   input.


Authors' Addresses

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089 USA
   Email:  kireeti@juniper.net

   Alex Zinin
   Alcatel
   Email:  zinin@psg.com


Full Copyright Notice

   Copyright (C) The Internet Society (2004).  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 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



Kompella & Zinin          Best Current Practice                 [Page 6]

Internet Draft   Early Allocation of Standard Codepoints       June 2004


   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.












































Kompella & Zinin          Best Current Practice                 [Page 7]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/