idnits 2.17.1 draft-leiba-iana-policy-update-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5226, but the abstract doesn't seem to directly say this. It does mention RFC5226 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5226, updated by this document, for RFC5378 checks: 2004-08-09) -- 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 (April 24, 2012) is 4378 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 5226 (if approved) April 24, 2012 5 Intended status: BCP 6 Expires: October 26, 2012 8 Update of and Clarification to IANA Policy Definitions in BCP 26 9 draft-leiba-iana-policy-update-02 11 Abstract 13 Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration 14 policies that might be used in documents with IANA actions, and 15 defines some well-known policy terms. This document clarifies the 16 usage of these terms, and discourages the use of overly restrictive 17 registration policies. 19 The author is working with IANA on an update to BCP 26, and this 20 document's contents will be folded into that effort. While that's in 21 process, this draft will be kept alive for reference. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 26, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 BCP 26 [RFC5226] presents a number of guidelines for IANA 76 considerations in RFCs. Section 4.1, in particular, is devoted to 77 registration policies, and the policy terminology it defines is 78 widely used. Whether or not RFCs use the specific terms defined 79 therein, there is a habit of applying the more restrictive policies 80 across the board, resulting in registries that require RFC, and even 81 Standards Track RFCs, for registries for which lighter weight 82 policies might be more appropriate. 84 2. Discussion 86 BCP 26 section 4.1 defines this set of registration policies: 88 1. Private Use 89 2. Experimental Use 90 3. Hierarchical Allocation 91 4. First Come First Served 92 5. Expert Review (or Designated Expert) 93 6. Specification Required 94 7. RFC Required 95 8. IETF Review 96 9. Standards Action 97 10. IESG Approval 99 Beginning with "First Come First Served", they are in approximately 100 increasing order of strictness: 102 4. No review, minimal documentation. 103 5. Expert review, sufficient documentation for review. 104 6. Expert review, significant and stable documentation. 105 7. Any RFC publication, perhaps in Independent stream. 106 8. RFC publication, IETF stream only. 107 9. Standards-Track RFC publication. 109 In considering which of policies 4 through 9 to apply, it's important 110 to get the right balance of review and ease of registration. In many 111 cases, those needing to register items will not be IETF participants; 112 requests often come from other standards organizations, from 113 organizations not directly involved in standards, from ad-hoc 114 community work (from an open-source project, for example), and so on. 115 We must not make registration policies and procedures unnecessarily 116 difficult to navigate, unnecessarily costly (in terms of time and 117 other resources), nor unnecessarily subject to denial. 119 While it is sometimes necessary to restrict what gets registered (for 120 limited resources such as bits in a byte or numbers within a 121 relatively small range, or for items for which unsupported values can 122 be damaging to protocol operation), in many cases having items 123 registered is more important than putting restrictions on the 124 registration. A pattern of denial through overly strict review 125 criteria, or because of excessive cost in time and effort to get 126 through the process, discourages people from even attempting to 127 register their items. And failure to have in-use items registered 128 adversely affects the protocols in use on the Internet. 130 In particular, because policies 7 through 9 require involvement of 131 working groups, directorates, and/or communities of former working- 132 group participants to be actively involved and to support the effort, 133 requests frequently run into concerns that "it's not worth doing a 134 Standards-Track RFC for something this trivial," when, in fact, that 135 requirement was created by the working group in the first place, with 136 its choice of a Standards Action policy for the registry. Indeed, 137 publishing any RFC is costly, and a Standards Track RFC is especially 138 so, requiring a great deal of community time for review and 139 discussion, IETF-wide last call, involvement of the entire IESG as 140 well a concentrated time and review from the sponsoring AD, review 141 and action by IANA, and RFC-Editor processing. 143 3. Best Practice 145 Working groups and other document developers should use care in 146 selecting appropriate registration policies when their documents 147 create registries. They should select the least strict policy that 148 suits a registry's needs, and look for specific justification for 149 policies stricter than Specification Required. Examples of 150 situations that might merit RFC Required, IETF Review, or Standards 151 Action include 153 o Registries of limited resources, such as bits in a byte (or in two 154 bytes, or four), or numbers in a limited range. In these cases, 155 allowing registrations that haven't been carefully reviewed and 156 agreed by community consensus could too quickly deplete the 157 allowable values. 159 o Registries for which thorough community review is necessary to 160 avoid extending or modifying the protocol in ways that could be 161 damaging. One example is in defining new command codes, as 162 opposed to options that use existing command codes: the former 163 might require a strict policy, where a more relaxed policy could 164 be adequate for the latter. Another example is in defining things 165 that change the semantics of existing operations. 167 There will be other cases, as well, of course; must assessment and 168 judgment is needed. It's not the intent, here, to put limits on the 169 applicability of particular registration policies, but to recommend 170 laxity, rather than strictness, in general, and to encourage document 171 developers to think carefully about each registry before deciding on 172 policies. 174 BCP 26, in its description of "IESG Approval", suggests that the IESG 175 "can (and should) reject a request if another path for registration 176 is available that is more appropriate and there is no compelling 177 reason to use that path." The IESG should give similar consideration 178 to any registration policy more stringent than Specification 179 Required, asking for justification and ensuring that more relaxed 180 policies have been considered, and the strict policy is the right 181 one. This is a situation that will -- and should -- involve a 182 substantive discussion between the IESG and the working group, 183 chairs, document editors, and/or document shepherd. The important 184 point, again, is not to relax the registration policy just to get the 185 document through quickly, but to carefully choose the right policy 186 for each registry. 188 Accordingly, document developers need to anticipate this and document 189 their considerations for choosing the specified policy. Ideally, 190 they should include that in the document. At the least, it should be 191 included in the shepherd writeup for the document, and in any case 192 the document shepherd should ensure that the selected policies have 193 been justified before sending the document to the IESG. 195 When specifications are revised, registration policies should be 196 reviewed in light of experience since the policies were set. It is 197 also possible to produce a small document at any time, which 198 "updates" the original specification and changes registration 199 policies. In either case, a policy can be relaxed or made more 200 strict, as appropriate to the actual situation. 202 Once again, it cannot be stressed enough that this must not be a 203 mechanical process, but one to which the document developers apply 204 thought, consideration, assessment, and judgment in choosing the 205 right policy for each registry. 207 The recommendations in this section apply whether the terms defined 208 in BCP 26 are used, or whether the document contains its own policy 209 definitions. The point, again, is not to limit registration 210 policies, but to ensure that the policies selected are appropriate, 211 and that proper consideration has been given to the level of 212 strictness required by them. 214 4. Security Considerations 216 See the Security Considerations section in BCP 26 [RFC5226], and note 217 that improper definition and application of IANA registration 218 policies can introduce both interoperability and security issues. It 219 is critical that registration policies be considered carefully and 220 separately for each registry. Overly restrictive policies can result 221 in the lack of registration of code points and parameters that need 222 to be registered, while overly permissive policies can result in 223 inappropriate registrations. Striking the right balance is an 224 important part of document development. 226 5. IANA Considerations 228 This document has no IANA actions. 230 6. Acknowledgements 232 Cyrus Daboo, Alexey Melnikov, Thomas Narten, Pete Resnick, and Peter 233 St. Andre were involved in early discussion of these issues. 235 7. Normative References 237 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 238 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 239 May 2008. 241 Author's Address 243 Barry Leiba 244 Huawei Technologies 246 Phone: +1 646 827 0648 247 Email: barryleiba@computer.org 248 URI: http://internetmessagingtechnology.org/