idnits 2.17.1 draft-hollenbeck-epp-ext-reg-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 (October 18, 2013) is 3842 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 normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4879 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft Verisign Labs 4 Intended status: Standards Track October 18, 2013 5 Expires: April 21, 2014 7 Extension Registry for the Extensible Provisioning Protocol 8 draft-hollenbeck-epp-ext-reg-00 10 Abstract 12 The Extensible Provisioning Protocol (EPP) includes features to add 13 functionality by extending the protocol. It does not, however, 14 describe how those extensions are managed. This document describes a 15 procedure for the registration and management of extensions to EPP 16 and it specifies a format for an IANA registry to record those 17 extensions. 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 April 21, 2014. 36 Copyright Notice 38 Copyright (c) 2013 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. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Extension Specification and Registration Procedure . . . . . 3 57 3.1. Extension Specification . . . . . . . . . . . . . . . . . 3 58 3.2. Registration Procedure . . . . . . . . . . . . . . . . . 3 59 3.2.1. Required Information . . . . . . . . . . . . . . . . 3 60 3.2.2. Registration Form . . . . . . . . . . . . . . . . . . 4 61 3.2.3. Registration Processing . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 1.1. Acronyms and Abbreviations 79 EPP: Extensible Provisioning Protocol 80 IANA: Internet Assigned Numbers Authority 81 IPR: Intellectual Property Rights 83 2. Introduction 85 Domain name registries implement a variety of operational and 86 business models. The differences in these models made it impossible 87 to develop a "one size fits all" provisioning protocol, so the 88 Extensible Provisioning Protocol (EPP, [RFC5730]) was designed to 89 focus on a minimal set of common functionality with built-in 90 extension capabilities that allow new features to be specified on an 91 "as needed" basis. Guidelines for extending EPP are documented in 92 Informational RFC 3735 [RFC3735]. 94 RFCs 5730 and 5735 do not describe how extension development can be 95 managed and coordinated. This has led to a situation in which server 96 operators can develop different extensions to address similar needs, 97 such as the provisioning of Value Added Tax (VAT) information. 98 Clients then need to support multiple extensions that serve similar 99 purposes, and interoperability suffers. 101 An IANA registry can be used to help manage and coordinate the 102 development of protocol extensions. This document describes an IANA 103 registry that can be used to coordinate the development of EPP 104 extensions. 106 3. Extension Specification and Registration Procedure 108 This section describes the format of an IANA registry and the 109 procedures used to populate and manage registry entries. 111 3.1. Extension Specification 113 The "Specification Required" policy described in RFC 5226 [RFC5226] 114 MUST be followed. Extension specifications MUST be written and 115 available in the English language. Non-English specifications are 116 OPTIONAL. 118 Note that the "Specification Required" policy implies review by a 119 Designated Expert. Section 3 of RFC 5226 describes the role of 120 Designated Experts and the function they perform. 122 3.2. Registration Procedure 124 The registry contains information describing each registered 125 extension. Registry entries are created and managed by sending forms 126 to IANA that describe the extension and the operation to be performed 127 on the registry entry. 129 3.2.1. Required Information 131 Name of Extension: A case-insensitive text string that contains the 132 name of the extension specification. 134 Specification Location: A URL [RFC3986] that describes the location 135 of the specification. 137 Registrant Name and Email Address: The case-insensitive name and 138 email address of the person that is responsible for managing the 139 registry entry. 141 TLDs: A case-insensitive text string description of the top-level 142 domain (or domains) for which the extension has been specified. 143 "Any" or "ANY" MUST be used if the extension is not associated with a 144 specific top-level domain. Multiple TLDs SHOULD be specified as a 145 list of domain names separated by commas, e.g. ".com, .net". 147 IPR Disclosure: Either "None", "NONE", or a URL that describes the 148 location of an IPR disclosure document. Depending on the type of 149 specification the IPR disclosure MAY be filed with the IETF in 150 accordance with RFCs 3979 [RFC3979] as updated by RFC 4879 [RFC4879]. 151 Non-IETF IPR disclosures MUST clearly identify the claimed 152 intellectual property rights and terms of use. "None" or "NONE" 153 indicates that the extension is freely available for use with no 154 claimed intellectual property rights. 156 3.2.2. Registration Form 158 The required information MUST be formatted consistently using the 159 following form: 161 -----BEGIN FORM----- 162 Name of Extension: 163 (quotes are OPTIONAL) 165 Specification Location: 166 168 Registrant Name and Email Address: 169 , 171 TLDs: 172 "Any"|"ANY"| 174 IPR Disclosure: 175 "None"|"NONE"| 176 -----END FORM----- 177 Example form with RFC specification: 179 -----BEGIN FORM----- 180 Name of Extension: 181 "An Extension RFC for the Extensible Provisioning Protocol (EPP)" 183 Specification Location: 184 http://tools.ietf.org/html/rfcXXXX 186 Registrant Name and Email Address: 187 John Doe, jdoe@example.com 189 TLDs: 190 Any 192 IPR Disclosure: 193 None 194 -----END FORM----- 196 Example form with non-RFC specification: 198 -----BEGIN FORM----- 199 Name of Extension: 200 "An Example Extension for the .example Top-Level Domain" 202 Specification Location: 203 http://www.example.com/html/example-epp-ext.txt 205 Registrant Name and Email Address: 206 John Doe, jdoe@example.com 208 TLDs: 209 .example 211 IPR Disclosure: 212 http://www.example.com/ipr/example-epp-ext-ipr.html 213 -----END FORM----- 215 3.2.3. Registration Processing 217 Each registration form sent to IANA MUST contain a single record for 218 incorporation into the registry. The form will be sent via email to 219 by the extension registrant. It MUST have a subject 220 line indicating whether the enclosed form represents an insertion of 221 a new record (indicated by the word "INSERT" in the subject line) or 222 a replacement of an existing record (indicated by the word "MODIFY" 223 in the subject line). At no time can a record be deleted from the 224 registry. 226 4. IANA Considerations 228 IANA is requested to create a new protocol registry to manage EPP 229 extensions. The information to be registered and the procedures to 230 be followed in populating the registry are described in Section 3. 232 Name of registry: Extensions for the Extensible Provisioning Protocol 234 Required information: See Section 3.2.1. 236 Review process: "Specification Required" as described in RFC 5226 237 [RFC5226]. 239 Size, format, and syntax of registry entries: See Section 3.2.1. 241 Initial assignments and reservations: None. 243 In addition, the form used to populate and manage the registry is to 244 be added to the table of Protocol Registration Forms maintained by 245 IANA. 247 5. Security Considerations 249 Using email to deliver forms to IANA carries a risk of registry 250 entires being created or updated by an attacker who is able to spoof 251 the email address of a legitimate extension registrant. This risk 252 can be mitigated by replying to received messages with a request to 253 confirm the requested action. The reply will be delivered to the 254 specified registrant, who can validate or refute the request. 256 6. Acknowledgements 258 The information described in the registry is based on a suggestion 259 posted to the provreg mailing list by Jay Daley in August 2013. 261 The author would like to acknowledge the following individuals for 262 their contributions to this document: TBD. 264 7. References 265 7.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 271 Technology", BCP 79, RFC 3979, March 2005. 273 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 274 Resource Identifier (URI): Generic Syntax", STD 66, RFC 275 3986, January 2005. 277 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 278 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 280 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 281 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 282 May 2008. 284 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 285 STD 69, RFC 5730, August 2009. 287 7.2. Informative References 289 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 290 Provisioning Protocol (EPP)", RFC 3735, March 2004. 292 Appendix A. Change Log 294 Initial -00: Initial version. 296 Author's Address 298 Scott Hollenbeck 299 Verisign Labs 300 12061 Bluemont Way 301 Reston, VA 20190 302 US 304 Email: shollenbeck@verisign.com 305 URI: http://www.verisignlabs.com/