1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4020.txt b/doc/rfc/rfc4020.txt
new file mode 100644
index 0000000..afe8850
--- /dev/null
+++ b/doc/rfc/rfc4020.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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).
+
+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 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
+   Action.
+
+   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
+   published).
+
+   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
+      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 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 with "shepherding Area Director".
+
+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 it is, 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.
+
+
+
+
+
+Kompella & Zinin         Best Current Practice                  [Page 3]
+
+RFC 4020        Early Allocation of Standard Code Points   February 2005
+
+
+   Note that Internet Drafts should not include a specific value of a
+   code point until this 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 backward compatible.
+
+   If at some point changes that are not backward compatible are
+   nonetheless required, a decision needs to be made as to whether
+   previously allocated code points must be deprecated (see section 3.3
+   for more information on code point deprecation).  The considerations
+   include aspects such as the 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 at which 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 "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 the
+   WG's plans 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).
+
+
+
+
+
+Kompella & Zinin         Best Current Practice                  [Page 4]
+
+RFC 4020        Early Allocation of Standard Code Points   February 2005
+
+
+   In particular, it is not IANA's responsibility to track the status of
+   allocations, their expiration, 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 approval by the IESG.
+
+4.  IANA Considerations
+
+   This document defines procedures for early allocation of code points
+   in the registries with the Standards Action policy and as such
+   directly affects IANA functions.
+
+5.  Normative References
+
+   [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+          Considerations Section in RFCs", BCP 26, RFC 2434, October
+          1998.
+
+6.  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 are
+   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.
+
+7.  Acknowledgements
+
+   Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their
+   input.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Zinin         Best Current Practice                  [Page 5]
+
+RFC 4020        Early Allocation of Standard Code Points   February 2005
+
+
+Authors' Addresses
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089 USA
+
+   EMail:  kireeti@juniper.net
+
+
+   Alex Zinin
+   Alcatel
+   701 E Middlefield Rd
+   Mountain View, CA 94043
+
+   EMail: zinin@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Zinin         Best Current Practice                  [Page 6]
+
+RFC 4020        Early Allocation of Standard Code Points   February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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
+   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 IETF's procedures with respect to rights in IETF 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.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Kompella & Zinin         Best Current Practice                  [Page 7]
+