Network Working Group S. Hollenbeck Internet-Draft Verisign Labs Intended status: Standards Track March 11, 2014 Expires: September 12, 2014 Extension Registry for the Extensible Provisioning Protocol draft-ietf-eppext-reg-02 Abstract The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Hollenbeck Expires September 12, 2014 [Page 1] Internet-Draft EPP Extension Registry March 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Extension Specification and Registration Procedure . . . . . 3 3.1. Extension Specification . . . . . . . . . . . . . . . . . 3 3.1.1. Designated Expert Evaluation Criteria . . . . . . . . 3 3.2. Registration Procedure . . . . . . . . . . . . . . . . . 4 3.2.1. Required Information . . . . . . . . . . . . . . . . 4 3.2.2. Registration Form . . . . . . . . . . . . . . . . . . 5 3.2.3. Registration Processing . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.1. Acronyms and Abbreviations EPP: Extensible Provisioning Protocol IANA: Internet Assigned Numbers Authority IPR: Intellectual Property Rights 2. Introduction Domain name registries implement a variety of operational and business models. The differences in these models made it impossible to develop a "one size fits all" provisioning protocol, so the Extensible Provisioning Protocol (EPP, [RFC5730]) was designed to focus on a minimal set of common functionality with built-in extension capabilities that allow new features to be specified on an "as needed" basis. Guidelines for extending EPP are documented in Informational RFC 3735 [RFC3735]. Hollenbeck Expires September 12, 2014 [Page 2] Internet-Draft EPP Extension Registry March 2014 RFCs 5730 and 5735 do not describe how extension development can be managed and coordinated. This has led to a situation in which server operators can develop different extensions to address similar needs, such as the provisioning of Value Added Tax (VAT) information. Clients then need to support multiple extensions that serve similar purposes, and interoperability suffers. An IANA registry can be used to help manage and coordinate the development of protocol extensions. This document describes an IANA registry that can be used to coordinate the development of EPP extensions. 3. Extension Specification and Registration Procedure This section describes the format of an IANA registry and the procedures used to populate and manage registry entries. 3.1. Extension Specification The "Specification Required" policy described in RFC 5226 [RFC5226] MUST be followed. Extension specifications MUST be written and available in the English language. Non-English specifications are OPTIONAL. Note that the "Specification Required" policy implies review by a Designated Expert. Section 3 of RFC 5226 describes the role of Designated Experts and the function they perform. 3.1.1. Designated Expert Evaluation Criteria A high-level description of the role of the Designated Expert is described in Section 3.2 RFC 5226. Specific guidelines for the appointment of Designated Experts and evaluation of EPP extension are provided here. The IESG should appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts as described in Section 3.2 of RFC 5226. The pool should have a single administrative chair who is appointed by the IESG. The designated experts should use the existing eppext mailing list (eppext@ietf.org) for public discussion of registration requests. This implies that the mailing list should remain open after the work of the EPPEXT working group has concluded. Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735]. The results of the evaluation should be shared via email with the registrant and the eppext mailing list. Issues discovered during the evaluation can be corrected by the registrant and those corrections can be submitted to Hollenbeck Expires September 12, 2014 [Page 3] Internet-Draft EPP Extension Registry March 2014 the designated experts until the designated experts explicitly decide to accept or reject the registration request. The designated experts must make an explicit decision and that decision must be shared via email with the registrant and the eppext mailing list. Designated experts should be permissive in their evaluation of requests to register extensions that have been implemented and deployed by at least one registry/registrar pair. This implies that it may indeed be possible to register multiple extensions that provide the same functionality. Requests to register extensions that have not been deployed should be evaluated with a goal of reducing functional duplication. A request to register a new, undeployed extension that duplicates the functionality of an existing, deployed extension should be rejected with guidance provided to the requestor to consider the existing, deployed extension. 3.2. Registration Procedure The registry contains information describing each registered extension. Registry entries are created and managed by sending forms to IANA that describe the extension and the operation to be performed on the registry entry. 3.2.1. Required Information Name of Extension: A case-insensitive text string that contains the name of the extension specification. Specification Location: A URL [RFC3986] that describes the location of the specification. Registrant Name and Email Address: The case-insensitive name and email address of the person that is responsible for managing the registry entry. TLDs: A case-insensitive text string description of the top-level domain (or domains) for which the extension has been specified. "Any" or "ANY" MUST be used if the extension is not associated with a specific top-level domain. Multiple TLDs SHOULD be specified as a list of domain names separated by commas, e.g. ".com, .net". IPR Disclosure: Either "None", "NONE", or a URL that describes the location of an IPR disclosure document. Depending on the type of specification the IPR disclosure MAY be filed with the IETF in accordance with RFCs 3979 [RFC3979] as updated by RFC 4879 [RFC4879]. Non-IETF IPR disclosures MUST clearly identify the claimed intellectual property rights and terms of use. "None" or "NONE" Hollenbeck Expires September 12, 2014 [Page 4] Internet-Draft EPP Extension Registry March 2014 indicates that the extension is freely available for use with no claimed intellectual property rights. Notes: Either "None", "NONE", or other text that describes optional notes to be included with the registered extension. 3.2.2. Registration Form The required information MUST be formatted consistently using the following form: -----BEGIN FORM----- Name of Extension: (quotes are OPTIONAL) Specification Location: Registrant Name and Email Address: , TLDs: "Any"|"ANY"| IPR Disclosure: "None"|"NONE"| Notes: "None"|"NONE"| -----END FORM----- Hollenbeck Expires September 12, 2014 [Page 5] Internet-Draft EPP Extension Registry March 2014 Example form with RFC specification: -----BEGIN FORM----- Name of Extension: "An Extension RFC for the Extensible Provisioning Protocol (EPP)" Specification Location: http://tools.ietf.org/html/rfcXXXX Registrant Name and Email Address: John Doe, jdoe@example.com TLDs: Any IPR Disclosure: None Notes: None -----END FORM----- Example form with non-RFC specification: -----BEGIN FORM----- Name of Extension: "An Example Extension for the .example Top-Level Domain" Specification Location: http://www.example.com/html/example-epp-ext.txt Registrant Name and Email Address: John Doe, jdoe@example.com TLDs: .example IPR Disclosure: http://www.example.com/ipr/example-epp-ext-ipr.html Notes: None -----END FORM----- Hollenbeck Expires September 12, 2014 [Page 6] Internet-Draft EPP Extension Registry March 2014 3.2.3. Registration Processing Each registration form sent to IANA MUST contain a single record for incorporation into the registry. The form will be sent via email to by the extension registrant. It MUST have a subject line indicating whether the enclosed form represents an insertion of a new record (indicated by the word "INSERT" in the subject line) or a replacement of an existing record (indicated by the word "MODIFY" in the subject line). At no time can a record be deleted from the registry. 4. IANA Considerations IANA is requested to create a new protocol registry to manage EPP extensions. The information to be registered and the procedures to be followed in populating the registry are described in Section 3. Name of registry: Extensions for the Extensible Provisioning Protocol Required information: See Section 3.2.1. Review process: "Specification Required" as described in RFC 5226 [RFC5226]. Size, format, and syntax of registry entries: See Section 3.2.1. Initial assignments and reservations: -----BEGIN FORM----- Name of Extension: "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)" Specification Location: http://tools.ietf.org/html/rfc3915 Registrant Name and Email Address: Scott Hollenbeck, shollenbeck@verisign.com TLDs: Any IPR Disclosure: None Notes: None -----END FORM----- Hollenbeck Expires September 12, 2014 [Page 7] Internet-Draft EPP Extension Registry March 2014 -----BEGIN FORM----- Name of Extension: "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)" Specification Location: http://tools.ietf.org/html/rfc4114 Registrant Name and Email Address: Scott Hollenbeck, shollenbeck@verisign.com TLDs: Any IPR Disclosure: None Notes: None -----END FORM----- -----BEGIN FORM----- Name of Extension: "ENUM Validation Information Mapping for the Extensible Provisioning Protocol" Specification Location: http://tools.ietf.org/html/rfc5076 Registrant Name and Email Address: Bernie Hoeneisen, bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch TLDs: Any IPR Disclosure: None Notes: None -----END FORM----- Hollenbeck Expires September 12, 2014 [Page 8] Internet-Draft EPP Extension Registry March 2014 -----BEGIN FORM----- Name of Extension: "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" Specification Location: http://tools.ietf.org/html/rfc5910 Registrant Name and Email Address: James Gould, jgould@verisign.com TLDs: Any IPR Disclosure: None Notes: None -----END FORM----- In addition, the form used to populate and manage the registry is to be added to the table of Protocol Registration Forms maintained by IANA. 5. Security Considerations Using email to deliver forms to IANA carries a risk of registry entries being created or updated by an attacker who is able to spoof the email address of a legitimate extension registrant. This risk can be mitigated by replying to received messages with a request to confirm the requested action. The reply will be delivered to the specified registrant, who can validate or refute the request. 6. Acknowledgements The information described in the registry is based on a suggestion posted to the provreg mailing list by Jay Daley in August 2013. The author would like to acknowledge the following individuals for their contributions to this document: TBD. 7. References Hollenbeck Expires September 12, 2014 [Page 9] Internet-Draft EPP Extension Registry March 2014 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. 7.2. Informative References [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004. Appendix A. Change Log Initial -00: First working group version. -01: Added initial registry entries to Section 4. -02: Spelling corrections. Added Section 3.1.1. Added "Notes" field to the registration template. Author's Address Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Hollenbeck Expires September 12, 2014 [Page 10]