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