idnits 2.17.1 draft-kompella-zinin-early-allocation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 252 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7248 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet Draft Juniper Networks 4 Proposed Category: Best Current Practice A. Zinin 5 Alcatel 6 Expires: December 2004 June 2004 8 Early IANA Allocation of Standards Track Codepoints 9 draft-kompella-zinin-early-allocation-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This memo discusses earlier allocation of code points by IANA as a 37 remedy to the problem created by the "Standards Action" IANA policy 38 for protocols where, by the IETF process, implementation and 39 deployment experience is desired or required prior to publication. 41 1. Introduction 43 In Standards Track RFCs, there is often the need to allocate code 44 points for various objects, messages or other protocol entities so 45 that implementations can interoperate. Many of these code point 46 spaces have registries handled by the Internet Assigned Number 47 Authority (IANA). Several IANA allocation policies are described in 48 RFC 2434 [2434]. Some of them, such as First Come First Served or 49 Expert Review, do not require a formal IETF action before the IANA 50 performs allocation. However, in situations where codepoints are a 51 scarce resource and/or the IETF community is willing to retain tight 52 control of the protocol, policies such as IESG Approval, IETF 53 Consensus, or Standards Action have been used. The Standards Action 54 policy represents a problem in situations where implementation and/or 55 deployment experience are desired or required for the Standards 56 Action. 58 To break the deadlock, "pre-RFC" implementations simply choose some 59 code points; these may turn out to be different from those later 60 assigned by IANA. To make matters worse, these "pre-RFC" 61 implementations are often deployed. This creates several potential 62 inteoperability problems between early implementations and 63 implementations of the final standard as described below: 65 1. IANA allocates codepoints different from what early 66 implementations assumed would be allocated. Early implementations 67 won't interoperate with standard ones. 69 2. IANA allocates codepoints silently used for other extensions. 70 Different extensions will collide. 72 This gets in the way of the main purpose of standards, namely to 73 facilitate interoperable implementations. 75 It is easy to say that pre-RFC implementations should be kept private 76 and not be deployed; however, both the length of the standards 77 process as well as the immense value of early implementations and 78 early deployments suggest finding a better solution. As an example, 79 in the case of documents produced by Working Groups in the Routing 80 Area, a pre-RFC implementation is highly desirable and sometimes even 81 required, and early deployments provide useful feedback on the 82 technical and operational quality of the specification. 84 This memo proposes that, under strictly controlled circumstances, 85 IANA makes an early allocation of code points. The memo lays out the 86 conditions for early allocation as well as the process to be 87 followed; it also says how such allocations are dealt with in the 88 event of a failure in the process (such as the RFC not being 89 published). 91 This memo only addresses the early allocation of code points from 92 spaces whose allocation policy is "Standards Action" [2434] AND have 93 been amended to permit early allocation. This permission must be 94 granted by the IESG, and code spaces with permission for early 95 allocation must be marked as such in the IANA registry. 97 2. Conditions for Early Allocation 99 The following conditions must hold before a request may be made for 100 early allocation of code points: 102 a) The code points must be from a space designated as "Standards 103 Action", amended by IESG approval to permit Early Allocation. 105 b) The format, semantics, processing and other rules related to 106 handling the protocol entities defined by the code points 107 (henceforth called "specifications") must be adequately described 108 in an Internet draft that is proposed as Standards Track. 110 c) The specifications of these code points must be stable, i.e., if 111 there is a change, implementations based on the earlier and later 112 specifications must be seamlessly interoperable. 114 d) There is sufficient interest in early (pre-RFC) implementation and 115 deployment in the community. 117 If conditions (a) or (b) are not met, then the processes in this memo 118 do not apply. 120 3. Process for Early Allocation 122 There are three processes associated with early allocation: making 123 the request for code points; following up on the request; and 124 revoking an early allocation. It cannot be emphasized enough that 125 these processes must have a minimal impact on IANA itself, or they 126 will not be feasible. 128 The processes as described below assume that the document in question 129 is the product of an IETF Working Group. If this is not the case, 130 replace "WG chairs" below by "shepherding Area Director". 132 3.1. Request 134 The process for requesting and obtaining early allocation of code 135 points is as follows: 137 1) The authors (editors) of the document submit a request for early 138 allocation to the Working Group chairs, specifying which code 139 points require early allocation and which document they should be 140 assigned to. 142 2) The WG chairs determine whether the conditions for early 143 allocations described in section 2 are met, particularly 144 conditions (c) and (d). 146 3) The WG chairs gauge whether there is consensus within the WG that 147 early allocation is appropriate in the case of the given document. 149 4) If so, with the approval of the Area Director(s), the WG chairs 150 request IANA to make an early allocation. 152 5) IANA makes an allocation from the appropriate registry, marking it 153 as "temporary", valid for a period of one year from the date of 154 allocation. The date of allocation should also be recorded in the 155 registry and made visible to the public. 157 Note that Internet Drafts should not include a specific value of a 158 code-point until such value has been formally allocated by IANA. 160 3.2. Follow-up 162 It is the responsibility of the document authors and the Working 163 Group chairs to review changes in the document, and especially in the 164 specifications of the code points for which early allocation was 165 requested to ensure that the changes are backwards compatible. 167 If at some point changes that are not backwards compatible are 168 nonetheless required, a decision needs to be made whether previously 169 allocated codepoints must be deprecated or not (see section 3.3 for 170 more information on codepoint deprecation). The considerations 171 include such aspects as possibility of existing deployments of the 172 older implementations and hence the possibility for a collision 173 between older and newer implementations in the field. 175 If the document progresses to the point when IANA normally makes code 176 point allocations, it is the responsibility of the authors and the WG 177 chairs to remind IANA that there were early allocations, and of the 178 code point values so allocated, in the IANA Considerations section of 179 the RFC-to-be. Allocation is then just a matter of removing the 180 "temporary" tag from the allocation description. 182 3.3. Expiry 184 If early allocations expire before the document progresses to the 185 point where IANA normally makes allocations, the authors and WG 186 chairs may follow an abbreviated version of the process in section 187 3.1 to request renewal of the code points. At most one renewal 188 request may be made; thus, authors should choose carefully when the 189 original request is to be made. 191 As an exception to the above rule, under rare circumstances, more 192 than one allocation renewal may be justified. All such renewal 193 requests must be reviewed by the IESG. The renewal request to the 194 IESG must include the reasons why such renewal is necessary, and what 195 the WG's plans are regarding the specification. 197 If a follow-up request is not made, or the document fails to progress 198 to a Standards Track RFC, the WG chairs are responsible for informing 199 IANA that the code points are to be marked "deprecated" (and are not 200 to be allocated); the WG chairs are further responsible for informing 201 IANA when the deprecated code points can be completely de-allocated 202 (i.e., made available for new allocations). 204 In particular, it is not IANA's responsibility to track the status of 205 allocations or when they expire or when they may be re-allocated. 207 Note that if a document is submitted for review to the IESG and at 208 the time of submission some early allocations are valid (not 209 expired), these allocations should not be expired while the document 210 is under IESG consideration or waiting in the RFC Editor's queue 211 after the approval by the IESG. 213 4. IANA Considerations 215 This document defines procedures for early allocation of codepoints 216 in the registries with the Standards Action policy, and as such 217 directly affects IANA functions. 219 Normative References 221 [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 222 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 224 Security Considerations 226 It is important to keep in mind 'denial of service' attacks on IANA 227 as a result of the processes in this memo. There are two that 228 immediately obvious: depletion of code space by early allocations; 229 and process overloading of IANA itself. The processes described here 230 attempt to alleviate both of these, but they should be subject to 231 scrutiny to ensure this. 233 Acknowledgments 235 Many thanks to Bert Wijnen, Adrian Farrel and Bill Fenner for their 236 input. 238 Authors' Addresses 240 Kireeti Kompella 241 Juniper Networks 242 1194 N. Mathilda Ave 243 Sunnyvale, CA 94089 USA 244 Email: kireeti@juniper.net 246 Alex Zinin 247 Alcatel 248 Email: zinin@psg.com 250 Full Copyright Notice 252 Copyright (C) The Internet Society (2004). This document is subject 253 to the rights, licenses and restrictions contained in BCP 78, and 254 except as set forth therein, the authors retain all their rights." 256 "This document and the information contained herein are provided on 257 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 258 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 259 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 260 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 261 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 264 Acknowledgement 266 Funding for the RFC Editor function is currently provided by the 267 Internet Society.