GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp100

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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp100.txt · Last modified: 2005/02/17 18:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki