idnits 2.17.00 (12 Aug 2021) /tmp/idnits55121/draft-nottingham-registry-custodian-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 : ---------------------------------------------------------------------------- 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 (July 5, 2012) is 3606 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 July 5, 2012 4 Intended status: Standards Track 5 Expires: January 6, 2013 7 Managing IANA Registries with Custodians 8 draft-nottingham-registry-custodian-00 10 Abstract 12 This document specifies an opt-in augmentation to the Well-Known IANA 13 Policy Definitions; appointing a "Custodian". 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 January 6, 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 . . . . . . . . . . . . . . . . 4 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 This document specifies an opt-in augmentation to the Well-Known IANA 63 Policy Definitions [RFC5226]; appointing a "Custodian". 65 The custodial process is designed to be used when a registry is 66 likely to have a large number of entries from outside the standards 67 community, because it gives an individual limited powers to maintain 68 the registry's contents, while still having a low bar to entry. 70 The goal of a custodial registry is to reflect deployment experience 71 as closely as possible; in other words, if a protocol element is in 72 use on the Internet, it ought to appear in the registry. 74 It is a non-goal to use the registry as a measure of quality (e.g., 75 allowing only "good" registrations, imposing architectural 76 constraints onto registrations). 78 Usually, a registry defined as Expert Review or Specification 79 Required will define the Expert as a Custodian. However, registries 80 with more stringent requirements can also use this process. 82 1.1. Notational Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119, BCP 14 87 [RFC2119] and indicate requirement levels for compliant CoAP 88 implementations. 90 2. The Custodian's Role 92 The Custodian's primary duty is to maintain the registry's contents 93 by assisting new registrations, updating existing entries, and making 94 new registrations when a protocol element is widely deployed but 95 unregistered. 97 As such, they have considerable power, in that they can make material 98 changes to the registry content without oversight, beyond that 99 offered by the community at large. 101 However, in practice this power is quite limited. The Custodian is 102 not charged with acting as a gatekeeper, nor imposing requirements on 103 new registrations. Rather, they are responsible for assuring that 104 the registry is kept up-to-date, reflecting the reality of 105 deployment. 107 In particular, a Custodian: 109 o MAY make suggestions to new registrations (e.g., "have you 110 considered...?") 111 o MUST NOT act as a "gatekeeper" to the registry (e.g., refusing 112 registrations based upon perceived or actual architectural or 113 aesthetic issues) 114 o SHOULD consult with the community (using a nominated mailing list) 115 when there are disputes or questions about pending or existing 116 registrations 117 o MAY proactively document values in common use (usually, reflected 118 in the registration status, e.g., "provisional") 119 o MAY update contact details and specification references, in 120 consultation with the registrants 121 o MAY update change control for a registration, with appropriate 122 consent or community consensus, as appropriate 123 o MAY annotate registrations (e.g., with implementation notes, 124 additional context) 125 o MAY update the status of a registration (e.g., to "deprecated", 126 "obsoleted") as appropriate 127 o SHOULD announce significant changes to the mailing list, for 128 community review 130 Members of the community who disagree with a Custodian's actions MAY 131 appeal to the Area Director(s) identified by the registry. However, 132 such appeals will be judged upon the criteria above, along with any 133 criteria specific to the registry and/or its chosen registration 134 policy. 136 3. Specifying Custodial Registries 138 Registries established with a [RFC5226] policy can refer to this 139 specification if they wish to use a custodial process. 141 Such registries still need to specify a base policy for 142 registrations; suitable policies in [RFC5226] include Expert Review 143 and Specification Required (in both cases, the Designated Expert 144 would be the Custodian, and this specification would fulfil the 145 requirement to define review criteria). 147 It is also possible to specify a custodial process for registries 148 with more stringent policies; e.g., IETF Review. In these cases, the 149 Custodian can still register new protocol elements to reflect non- 150 standard protocol elements in common use, but MUST identify them with 151 an appropriate status (e.g., "non-standard"). 153 Registries using the custodial process: 155 o SHOULD define a 'status' (or functionally similar) field that 156 indicates registration disposition, and SHOULD enumerate possible 157 values. 158 o SHOULD nominate a mailing list for discussion of registrations; 159 usually, this will be a pre-existing list (rather than a dedicated 160 one). 161 o MUST nominated the area whose Area Directors are responsible for 162 appointing Custodians and handling appeals. 163 o SHOULD identify the URL of the registry in their specification 164 o SHOULD give IANA as the point of contact for new registrations 166 4. IANA Considerations 168 For custodial registries, IANA: 170 o MUST send requests for registrations to the Custodian 171 o SHOULD respond to requests from the Custodian promptly 172 o SHOULD notify the responsible Area Directors if the Custodian is 173 unresponsive 174 o MUST provide an easily editable Web page about the registry to the 175 Custodian (e.g., a "wiki"), and link to it from the registry page 176 o MUST provide the capacity for the Custodian to annotate individual 177 registry entries (e.g., a "wiki" page for each entry) 179 5. Security Considerations 181 TBD. 183 6. References 185 6.1. Normative References 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 6.2. Informative References 192 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 193 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 194 May 2008. 196 Author's Address 198 Mark Nottingham 200 Email: mnot@mnot.net 201 URI: http://www.mnot.net/