WDIFF

draft-kompella-zinin-early-allocation-02.txt --> rfc4020.txt

Network Working Group K. Kompella
Internet Draft
Request for Comments: 4020 Juniper Networks
Proposed
BCP: 100 A. Zinin
Category: Best Current Practice A. Zinin Alcatel
Expires: December 2004 June 2004
February 2005

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

Status of this 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

This document specifies an Internet Best Current Practices for the
Internet Engineering
Task Force (IETF), its areas, Community, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Distribution of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It this memo 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 unlimited.

Copyright (C) The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 where, for which, 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 a need to allocate code
points for various objects, messages 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 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 choose 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
inteoperability 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 standard, as
described below:

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

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

This gets in the way of the main purpose of standards, namely 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 as well as 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 makes make an early allocation of code points. The memo lays out the
conditions for early allocation allocation, as well as the process to be
followed; it also says how such these 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 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 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, 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 with "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 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, 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
code point until such this value has been formally allocated by IANA.

3.2. Follow-up 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
requested, to ensure that the changes are backwards backward compatible.

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

If the document progresses to the point when 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

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 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 allocated). The WG chairs are further responsible for
informing IANA when the deprecated code points can be completely de-allocated 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 or when they expire
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 the approval by the IESG.

4. IANA Considerations

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

Kompella & Zinin Best Current Practice [Page 5]

Internet Draft Early Allocation of Standard Codepoints June 2004

5. Normative References

[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998
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; 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

7. Acknowledgements

Many thanks to Bert Wijnen, Adrian Farrel 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:

EMail: kireeti@juniper.net

Alex Zinin
Alcatel
Email:
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 Notice Statement

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 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 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]

----