Early IANA Allocation of Standards Track Code Points
RFC 4020

Document Type RFC - Best Current Practice (March 2005; No errata)
Obsoleted by RFC 7120
Also known as BCP 100
Was draft-kompella-zinin-early-allocation (individual in rtg area)
Authors Kireeti Kompella  , Alex Zinin 
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4020 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Bill Fenner
Send notices to (None)
Network Working Group                                        K. Kompella
Request for Comments: 4020                              Juniper Networks
BCP: 100                                                        A. Zinin
Category: Best Current Practice                                  Alcatel
                                                           February 2005

          Early IANA Allocation of Standards Track Code Points

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   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 for which, by the IETF process, implementation and
   deployment experience is desired or required prior to publication.

1.  Introduction

   In Standards Track RFCs, there is often a 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 code points 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

   To break the deadlock, "pre-RFC" implementations have sometimes
   simply chosen some "seemingly unused" 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 interoperability problems between early

Kompella & Zinin         Best Current Practice                  [Page 1]
RFC 4020        Early Allocation of Standard Code Points   February 2005

   implementations and implementations of the final standard, as
   described below:

   1. IANA allocates code points different from those that early
      implementations assumed would be allocated.  Early implementations
      won't interoperate with standard ones.

   2. IANA allocates code points used silently 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 should not be deployed; however, both the length of the standards
   process and 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 make 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 these allocations are dealt with in the
   event of a failure in the process (such as the RFC not being

   This memo only addresses the early allocation of code points from
   spaces whose allocation policy is "Standards Action" [2434] AND that
   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.

Kompella & Zinin         Best Current Practice                  [Page 2]
RFC 4020        Early Allocation of Standard Code Points   February 2005

   c) The specifications of these code points must be stable; i.e., if
      there is a change, implementations based on the earlier and later
Show full document text