idnits 2.17.1 draft-nottingham-appsawg-happiana-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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...- registration procedures SHOULD allow...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2012) is 4431 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) == Missing Reference: 'RFC3986' is mentioned on line 112, but not defined == Missing Reference: 'RFC2026' is mentioned on line 148, but not defined == Outdated reference: A later version (-02) exists of draft-leiba-iana-policy-update-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Rackspace 4 Intended status: BCP March 1, 2012 5 Expires: September 2, 2012 7 Happy IANA: Making Large-Scale Registries More User-Friendly 8 draft-nottingham-appsawg-happiana-00 10 Abstract 12 Suggestions for IANA registries that have a broad audience, 13 particularly a non-IETF one. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 2, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Recommendations for Registration Procedures . . . . . . . . . . 3 51 2.1. Use the lowest barrier-to-entry registration procedure 52 possible . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Explain the expert reviewer function . . . . . . . . . . . 3 54 2.3. Clearly identify points of contact . . . . . . . . . . . . 3 55 2.4. Allow reservation . . . . . . . . . . . . . . . . . . . . . 4 56 2.5. Allow third-party registration . . . . . . . . . . . . . . 4 57 2.6. Have a 'status' field . . . . . . . . . . . . . . . . . . . 4 58 2.7. Have a simple procedure for updating contacts . . . . . . . 5 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Informative References . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 While the audience for many IANA registries is fairly narrow (often 67 being limited to those active in the IETF), there are some which are 68 used by broader groups. 70 These registries often see requests from third parties who aren't as 71 familiar with the operating procedures of the IETF nor IANA, and 72 therefore sometimes find the registration process frustrating. 74 This document makes recommendations for making such registries 75 friendlier to their users. They are not intended to be applied to 76 all registries. 78 2. Recommendations for Registration Procedures 80 2.1. Use the lowest barrier-to-entry registration procedure possible 82 Registries are most useful when they reflect the protocol elements 83 actually in use. However, some see them as having more of a 84 "gatekeeper" function, where they only reflect "approved" values that 85 are "good" (by some metric). 87 See also [I-D.leiba-iana-policy-update]. 89 2.2. Explain the expert reviewer function 91 Further to the above, registries that use expert reviewers are 92 encouraged to carefully define how that role works. Generally, it 93 should be seen as a shepherding function, rather than a filtering 94 one; the goal of the expert should be to facilitate registrations as 95 quickly as possible. 97 This may involve, for example, registering a protocol element that 98 isn't yet completely specified, in anticipation of updating it with 99 more accurate or complete information later. 101 2.3. Clearly identify points of contact 103 Registrants often multiple parties; e.g.,the IESG, the IANA and 104 sometimes an expert reviewer, depending on the registration process 105 chosen. 107 When this is the case, the point of contact for initial registration 108 should always be defined as IANA, and responsibility at each stage of 109 the registration process should be carefully identified. 111 Likewise, the document defining a new registry should provide a URL 112 [RFC3986] to the registry at IANA (coordinating allocation of the URL 113 with IANA as necessary). 115 2.4. Allow reservation 117 Protocols and their extensions are usually the product of a long 118 process. Authors often want to "hold" a value until they complete 119 their specification. To accommodate these cases, registries should 120 allow a value to be reserved for future use, and the registry should 121 reflect this as soon as possible (e.g, with a value of "reserved", 122 along with a note about the reservation). 124 2.5. Allow third-party registration 126 Unregistered values sometimes become commonly used. To maintain the 127 usefulness of the registry -- both as a reference as well as a 128 mechanism to avoid conflicts -- registration procedures SHOULD allow 129 registration of already deployed protocol elements by those other 130 than their creators. 132 When this happens, every effort should be made to properly attribute 133 the source, common use, and (if applicable) appropriate change 134 controller. 136 2.6. Have a 'status' field 138 Context is important in registries; it's important, for example, to 139 differentiate between reserved entries (as per above) and those that 140 have completed the process. 142 It is recommended that registries that require some level of 143 consensus (e.g., IETF Review) have the following potential statuses: 145 o Standard (registered through a consensus process) 146 o Reserved (held for future use) 147 o Obsoleted (mapping to the 'obsoleted' and 'historic' states in 148 [RFC2026]) 150 It is recommended that registries with lower requirements for 151 consensus (e.g., First Come First Served, Specification Required) use 152 the following: 154 o Registered (has been registered) 155 o Reserved (held for future use) 156 o Deprecated (has been withdrawn) 158 Note that these are only recommended defaults; registries may wish to 159 use additional or different statuses. 161 2.7. Have a simple procedure for updating contacts 163 Registrants' contact details should be able to be updated by 164 contacting IANA, even for registries which require a higher level of 165 consensus. 167 Likewise, non-disputed changes in control for a registration should 168 be defined as being handled exclusively by IANA. 170 3. Security Considerations 172 This document does not specify a protocol, and does not have direct 173 security impact. 175 4. IANA Considerations 177 This document does not directly impact IANA. 179 5. Informative References 181 [I-D.leiba-iana-policy-update] 182 Leiba, B., "Update of and Clarification to IANA Policy 183 Definitions in BCP 26", draft-leiba-iana-policy-update-01 184 (work in progress), October 2011. 186 Author's Address 188 Mark Nottingham 189 Rackspace 191 Email: mnot@mnot.net 192 URI: http://www.mnot.net/