idnits 2.17.00 (12 Aug 2021) /tmp/idnits38412/draft-ietf-eppext-reg-10.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 (December 3, 2014) is 2719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational December 3, 2014 5 Expires: June 6, 2015 7 Extension Registry for the Extensible Provisioning Protocol 8 draft-ietf-eppext-reg-10 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 June 6, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Extension Specification and Registration Procedure . . . . . 3 55 2.1. Extension Specification . . . . . . . . . . . . . . . . . 3 56 2.1.1. Designated Expert Evaluation Criteria . . . . . . . . 3 57 2.2. Registration Procedure . . . . . . . . . . . . . . . . . 4 58 2.2.1. Required Information . . . . . . . . . . . . . . . . 4 59 2.2.2. Registration Form . . . . . . . . . . . . . . . . . . 5 60 2.2.3. Registration Processing . . . . . . . . . . . . . . . 8 61 2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 8 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 6.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 Domain name registries implement a variety of operational and 74 business models. The differences in these models made it impossible 75 to develop a "one size fits all" provisioning protocol, so the 76 Extensible Provisioning Protocol (EPP, [RFC5730]) was designed to 77 focus on a minimal set of common functionality with built-in 78 extension capabilities that allow new features to be specified on an 79 "as needed" basis. Guidelines for extending EPP are documented in 80 Informational RFC 3735 [RFC3735]. 82 RFCs 3735 and 5730 do not describe how extension development can be 83 managed and coordinated. This has led to a situation in which server 84 operators can develop different extensions to address similar needs, 85 such as the provisioning of Value Added Tax (VAT) information. 86 Clients then need to support multiple extensions that serve similar 87 purposes, and interoperability suffers. 89 An IANA registry can be used to help manage and coordinate the 90 development of protocol extensions. This document describes an IANA 91 registry that can be used to coordinate the development of EPP 92 extensions. 94 2. Extension Specification and Registration Procedure 96 This section describes the format of an IANA registry and the 97 procedures used to populate and manage registry entries. 99 2.1. Extension Specification 101 This registry uses the "Specification Required" policy described in 102 RFC 5226 [RFC5226]. An English language version of the extension 103 specification will referenced from the registry, though non-English 104 versions of the specification can also be provided. Note that 105 Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for 106 documenting EPP extensions. 108 Note that the "Specification Required" policy implies review by a 109 Designated Expert. Section 3 of RFC 5226 describes the role of 110 Designated Experts and the function they perform. 112 2.1.1. Designated Expert Evaluation Criteria 114 A high-level description of the role of the Designated Expert is 115 described in Section 3.2 RFC 5226. Specific guidelines for the 116 appointment of Designated Experts and evaluation of EPP extensions 117 are provided here. 119 The IESG should appoint a small pool of individuals (perhaps 3 - 5) 120 to serve as designated experts as described in Section 3.2 of RFC 121 5226. The pool should have a single administrative chair who is 122 appointed by the IESG. The designated experts should use the 123 existing eppext mailing list (eppext@ietf.org) for public discussion 124 of registration requests. This implies that the mailing list should 125 remain open after the work of the EPPEXT working group has concluded. 127 Extensions should be evaluated for architectural soundness using the 128 guidelines described in RFC 3735 [RFC3735], including the Security 129 Considerations section of that document. Expert evaluation should 130 explicitly include consideration of the privacy consequences of 131 proposed extensions, and, at a minimum, ensure that any privacy 132 considerations are fully documented in the relevant specification(s). 134 The results of the evaluation should be shared via email with the 135 registrant and the eppext mailing list. Issues discovered during the 136 evaluation can be corrected by the registrant and those corrections 137 can be submitted to the designated experts until the designated 138 experts explicitly decide to accept or reject the registration 139 request. The designated experts must make an explicit decision and 140 that decision must be shared via email with the registrant and the 141 eppext mailing list. If the specification for an extension is an 142 IETF Standards Track document, no review is required by the 143 Designated Expert. 145 Designated experts should be permissive in their evaluation of 146 requests to register extensions that have been implemented and 147 deployed by at least one registry/registrar pair. This implies that 148 it may indeed be possible to register multiple extensions that 149 provide the same functionality. Requests to register extensions that 150 have not been deployed should be evaluated with a goal of reducing 151 functional duplication. A potential registrant who submits a request 152 to register a new, un-deployed extension that includes similar 153 functionality to an existing, registered extension should be made 154 aware of the existing extension. The registrant should be asked to 155 reconsider their request given the existence of a similar extension. 156 Should they decline to do so perceived similarity should not be a 157 sufficient reason for rejection as long as all other requirements are 158 met. 160 2.2. Registration Procedure 162 The registry contains information describing each registered 163 extension. Registry entries are created and managed by sending forms 164 to IANA that describe the extension and the operation to be performed 165 on the registry entry. 167 2.2.1. Required Information 169 Name of Extension: A case-insensitive, ASCII text string that 170 contains the name of the extension specification. Non-ASCII 171 representations of the extension name can be included in the "Notes" 172 described below. 174 Document Status: The document status ("Informational", "Standards 175 Track", etc.) of the specification document. For documents that are 176 not RFCs, this will always be "Informational". 178 Reference: A reference to the specification of this extension. This 179 could be an RFC number or some other pointer to the document defining 180 the extension. 182 Registrant Name and Email Address: The name and email address of the 183 person that is responsible for managing the registry entry. If the 184 registration is of an IETF Standards Track document, this can simply 185 be listed as "IESG, ". 187 TLDs: A text string containing the top-level domain name (or domain 188 names), including the preceding ".", for which the extension has been 189 specified (e.g., ".org"). If there are multiple TLDs, they are given 190 as a list of domain names separated by commas, (e.g. ".com, .net"). 191 Internationalized Domain Name (IDN) TLDs should be specified in 192 A-label [RFC5890] format. If the extension is not associated with a 193 specific top-level domain, the case-insensitive text string "Any" can 194 be used to indicate that. 196 IPR Disclosure: A pointer to any Intellectual Property Rights (IPR) 197 disclosure document(s) related to this extension, or "None" if there 198 are no such disclosures. This can be an IPR disclosure filed with 199 the IETF in accordance with RFC 3979 [RFC3979] as updated by RFC 4879 200 [RFC4879] if the extension is part of an IETF Contribution, or can be 201 other IPR disclosure documents identifying the claimed intellectual 202 property rights and terms of use for extensions that are not part of 203 an IETF Contribution. 205 Status: Either "Active" or "Inactive". The "Active" status is used 206 for extensions that are currently implemented and in use. The 207 "Inactive" status is used for extensions that are not implemented or 208 are otherwise not being used. 210 Notes: Either "None" or other text that describes optional notes to 211 be included with the registered extension. If the Status value is 212 "Inactive" text should be included to describe how and when this 213 state was reached. 215 2.2.2. Registration Form 217 The required information must be formatted consistently using the 218 following form. Form field names and values may appear on the same 219 line: 221 -----BEGIN FORM----- 222 Name of Extension: 223 (quotes are optional) 225 Document Status: 227 Reference: 229 Registrant Name and Email Address: 230 , 232 TLDs: "Any"| 234 IPR Disclosure: "None"| 236 Status: "Active"|"Inactive" 237 Notes: "None"| 238 -----END FORM----- 239 Example form with RFC specification: 241 -----BEGIN FORM----- 242 Name of Extension: 243 "An Extension RFC for the Extensible Provisioning Protocol (EPP)" 245 Document Status: 246 Standards Track 248 Reference: 249 http://tools.ietf.org/html/rfcXXXX 251 Registrant Name and Email Address: 252 IESG, 254 TLDs: Any 256 IPR Disclosure: None 258 Status: Active 260 Notes: None 261 -----END FORM----- 263 Example form with non-RFC specification: 265 -----BEGIN FORM----- 266 Name of Extension: 267 "An Example Extension for the .example Top-Level Domain" 269 Document Status: 270 Informational 272 Reference: 273 http://www.example.com/html/example-epp-ext.txt 275 Registrant Name and Email Address: 276 John Doe, jdoe@example.com 278 TLDs: .example 280 IPR Disclosure: 281 http://www.example.com/ipr/example-epp-ext-ipr.html 283 Status: Active 285 Notes: None 286 -----END FORM----- 288 2.2.3. Registration Processing 290 Registrants should send each registration form to IANA with a single 291 record for incorporation into the registry. Send the form via email 292 to , and include a subject line indicating whether the 293 enclosed form represents an insertion of a new record (indicated by 294 the word "INSERT" in the subject line) or a replacement of an 295 existing record (indicated by the word "MODIFY" in the subject line). 296 At no time can a record be deleted from the registry. On receipt of 297 the registration request, IANA will initiate review by the designated 298 expert(s), who will evaluate the request using the criteria in 299 Section 2.1.1, in consultation with the eppext mailing list. 301 2.2.4. Updating Registry Entries 303 When submitting changes to existing registry entries, include text in 304 the "Notes" field of the registration form describing the change. 305 Under normal circumstances, registry entries are only be updated by 306 the registrant. If the registrant becomes unavailable or otherwise 307 unresponsive, the designated expert can submit a registration form to 308 IANA to update the registrant information. Entries can change state 309 from "Active" to "Inactive" and back again as long as state change 310 requests conform to the processing requirements identified in this 311 document. In addition to entries that become "Inactive" due to a 312 lack of implementation, entries for which a specification becomes 313 consistently unavailable over time should be marked "Inactive" by the 314 designated expert until such time as the specification again becomes 315 reliably available. 317 3. IANA Considerations 319 IANA is requested to create a new protocol registry to manage EPP 320 extensions. This registry should appear under its own heading on 321 IANA's protocol listings, using the same title as the name of the 322 registry. The information to be registered and the procedures to be 323 followed in populating the registry are described in Section 2. 325 Name of registry: Extensions for the Extensible Provisioning Protocol 327 Section at http://www.iana.org/protocols: 328 Registry Title: Extensions for the Extensible Provisioning Protocol 329 Registry Name: Extensions for the Extensible Provisioning Protocol 330 Registration Procedure: Specification Required 331 Reference: this draft 333 Required information: See Section 2.2.1. 335 Review process: "Specification Required" as described in RFC 5226 336 [RFC5226]. 338 Size, format, and syntax of registry entries: See Section 2.2.1. 340 Initial assignments and reservations: 342 -----BEGIN FORM----- 343 Name of Extension: 344 "Domain Registry Grace Period Mapping for the 345 Extensible Provisioning Protocol (EPP)" 347 Document Status: 348 Standards Track 350 Reference: 351 http://tools.ietf.org/html/rfc3915 353 Registrant Name and Email Address: 354 IESG, 356 TLDs: Any 358 IPR Disclosure: None 360 Status: Active 362 Notes: None 363 -----END FORM----- 364 -----BEGIN FORM----- 365 Name of Extension: 366 "E.164 Number Mapping for the 367 Extensible Provisioning Protocol (EPP)" 369 Document Status: 370 Standards Track 372 Reference: 373 http://tools.ietf.org/html/rfc4114 375 Registrant Name and Email Address: 376 IESG, 378 TLDs: Any 380 IPR Disclosure: None 382 Status: Active 384 Notes: None 385 -----END FORM----- 387 -----BEGIN FORM----- 388 Name of Extension: 389 "ENUM Validation Information Mapping for the 390 Extensible Provisioning Protocol" 392 Document Status: 393 Standards Track 395 Reference: 396 http://tools.ietf.org/html/rfc5076 398 Registrant Name and Email Address: 399 IESG, 401 TLDs: Any 403 IPR Disclosure: None 405 Status: Active 407 Notes: None 408 -----END FORM----- 409 -----BEGIN FORM----- 410 Name of Extension: 411 "Domain Name System (DNS) Security Extensions Mapping for the 412 Extensible Provisioning Protocol (EPP)" 414 Document Status: 415 Standards Track 417 Reference: 418 http://tools.ietf.org/html/rfc5910 420 Registrant Name and Email Address: 421 IESG, 423 TLDs: Any 425 IPR Disclosure: None 427 Status: Active 429 Notes: None 430 -----END FORM----- 432 In addition, the form used to populate and manage the registry is to 433 be added to the table of Protocol Registration Forms maintained by 434 IANA. 436 4. Security Considerations 438 This document introduces no new security considerations to EPP. 439 However, extensions should be evaluated according to the Security 440 Considerations of RFC 3735 [RFC3735]. 442 5. Acknowledgements 444 The information described in the registry is based on a suggestion 445 posted to the provreg mailing list by Jay Daley in August 2013. 447 6. References 449 6.1. Normative References 451 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 452 Technology", BCP 79, RFC 3979, March 2005. 454 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 455 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 458 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 459 May 2008. 461 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 462 STD 69, RFC 5730, August 2009. 464 [RFC5890] Klensin, J., "Internationalized Domain Names for 465 Applications (IDNA): Definitions and Document Framework", 466 RFC 5890, August 2010. 468 6.2. Informative References 470 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 471 Provisioning Protocol (EPP)", RFC 3735, March 2004. 473 Appendix A. Change Log 475 Initial -00: First working group version. 476 -01: Added initial registry entries to Section 3. 477 -02: Spelling corrections. Added Section 2.1.1. Added "Notes" 478 field to the registration template. 479 -03: Added reference to Section 2.1 of RFC 3735 in Section 2.1. 480 -04: Added "Status" field to the registration template. Fixed typo 481 in Section 2.1.1. Reformatted examples and initial registry 482 entries. 483 -05: Added text to clarify how existing registry entries can and 484 can't be edited. 485 -06: Modified text in Section 2.1.1 to make it clear that it is 486 possible to register functionally similar extensions. 487 -07: Address WG last call comments. 488 -08: Address AD review comments. 489 -09: Address IETF last call and IESG review comments. 490 -10: Re-address IETF last call and IESG review comments. Added text 491 to note that the extension name must be represented using ASCII 492 characters. 494 Author's Address 496 Scott Hollenbeck 497 Verisign Labs 498 12061 Bluemont Way 499 Reston, VA 20190 500 US 502 Email: shollenbeck@verisign.com 503 URI: http://www.verisignlabs.com/