idnits 2.17.00 (12 Aug 2021) /tmp/idnits38317/draft-nottingham-registry-custodian-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 7, 2012) is 3567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft August 7, 2012 4 Intended status: Standards Track 5 Expires: February 8, 2013 7 Custodial Review Criteria for Designated Experts 8 draft-nottingham-registry-custodian-01 10 Abstract 12 This document specifies a set of review criteria for IANA registry 13 Designated Experts. 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 February 8, 2013. 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 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 51 2. The Custodian's Role . . . . . . . . . . . . . . . . . . . . . 3 52 3. Specifying Custodial Registries . . . . . . . . . . . . . . . . 5 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 This document specifies a set of review criteria for IANA registry 63 Designated Experts [RFC5226]. 65 They are designed to be used when a registry is likely to have a 66 large number of registrations from outside the IETF community, 67 because they give the Designated Expert(s) limited powers to maintain 68 the registry's contents, while still having a low bar to entry. 70 Colloquially, such a Designated Expert is known as a "Custodian." 72 The goal of a registry using them is to reflect deployment with the 73 registry as closely as possible; in other words, if a protocol 74 element is in use on the Internet, it ought to appear in the 75 registry. 77 It is a non-goal to use the registry as a measure of quality (e.g., 78 allowing only "good" registrations, imposing architectural 79 constraints onto registrations). 81 As such, these review criteria are not appropriate for all 82 registries. 84 A registry defined as Expert Review or Specification Required can 85 define the Expert's role as that of a Custodian by referencing this 86 document. 88 1.1. Notational Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. The Custodian's Role 96 The Custodian's primary duty is to maintain the registry's contents 97 by assisting new registrations, updating existing entries, and making 98 new registrations when a protocol element is widely deployed but 99 unregistered. 101 As such, they have considerable power, in that they can make material 102 changes to the registry content without oversight, beyond that 103 offered by the community at large. 105 However, in practice this power is quite limited. The Custodian is 106 not charged with acting as a gatekeeper, nor imposing requirements on 107 new registrations. Rather, they are responsible for assuring that 108 the registry is kept up-to-date, reflecting the reality of 109 deployment. 111 In particular, a Custodian: 113 o MAY make suggestions to new registrations (e.g., "have you 114 considered...?") 115 o MUST NOT act as a "gatekeeper" to the registry (e.g., refusing 116 registrations based upon perceived or actual architectural or 117 aesthetic issues) 118 o MUST respect additional requirements placed upon registrations by 119 the registry definition when making decisions 120 o SHOULD consult with the community (using a nominated mailing list) 121 when there are disputes or questions about pending or existing 122 registrations 123 o MAY proactively document values in common use (usually, reflected 124 in the registration status, e.g., "provisional") 125 o MAY update contact details and specification references, in 126 consultation with the registrants 127 o MAY update change control for a registration, with appropriate 128 consent or community consensus, as appropriate 129 o MAY annotate registrations (e.g., with implementation notes, 130 additional context) 131 o MAY update the status of a registration (e.g., to "deprecated", 132 "obsoleted") as appropriate 133 o SHOULD announce significant changes to the mailing list, for 134 community review 136 Additionally, for Specification Required registries, a Custodian: 138 o MAY approve registrations when it is, in their judgement, apparent 139 that a specification will be published 140 o MAY consider specifications other than standards as meeting 141 "Specification Required". References are encouraged to be 142 reasonably stable, but references stability on its own SHOULD NOT 143 be an impediment to registration, because the Custodian(s) MAY 144 update it as necessary. 146 Members of the community who disagree with a Custodian's actions MAY 147 appeal to the Area Director(s) identified by the registry. However, 148 such appeals will be judged upon the criteria above, along with any 149 criteria specific to the registry and/or its chosen registration 150 policy. 152 3. Specifying Custodial Registries 154 Registries established with a [RFC5226] Expert Review or 155 Specification Required policy can refer to this specification if they 156 wish to nominate the guidelines described here as review criteria for 157 Designated Expert(s). 159 Registries using the custodial process: 161 o SHOULD define a 'status' (or functionally similar) field that 162 indicates registration disposition, and SHOULD enumerate possible 163 values. 164 o SHOULD nominate a mailing list for discussion of registrations; 165 usually, this will be a pre-existing list (rather than a dedicated 166 one). 167 o MUST nominate the area whose Area Directors are responsible for 168 appointing Custodians and handling appeals. 169 o SHOULD identify the URL of the registry in their specification. 170 o SHOULD give IANA as the point of contact for new registrations. 171 o MAY place additional requirements upon registrations (e.g., 172 syntactic constraints, clear guidelines for appropriate use) 174 4. IANA Considerations 176 For custodial registries, IANA: 178 o MUST send requests for registrations to the Custodian 179 o SHOULD respond to requests from the Custodian promptly 180 o SHOULD notify the responsible Area Directors if the Custodian is 181 unresponsive 182 o MUST provide an easily editable Web page about the registry to the 183 Custodian (e.g., a "wiki"), and link to it from the registry page 184 o MUST provide the capacity for the Custodian to annotate individual 185 registry entries (e.g., a "wiki" page for each entry) 187 5. Security Considerations 189 A Custodian has a considerable amount of leeway regarding the 190 contents of the registry, because they can effect a change in it 191 merely by asking IANA to do so. Therefore, registries that contain 192 security-sensitive information are advised to consider whether this 193 could form the basis of an attack; e.g., if an implementation 194 retrieves and utilises the contents of the registry automatically. 196 6. References 197 6.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 6.2. Informative References 204 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 205 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 206 May 2008. 208 Author's Address 210 Mark Nottingham 212 Email: mnot@mnot.net 213 URI: http://www.mnot.net/