GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7451

Internet Engineering Task Force (IETF) S. Hollenbeck Request for Comments: 7451 Verisign Labs Category: Informational February 2015 ISSN: 2070-1721

    Extension Registry for the Extensible Provisioning Protocol

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 document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7451.

Copyright Notice

 Copyright (c) 2015 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
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Hollenbeck Informational [Page 1] RFC 7451 EPP Extension Registry February 2015

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Extension Specification and Registration Procedure  . . . . .   3
   2.1.  Extension Specification . . . . . . . . . . . . . . . . .   3
     2.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   3
   2.2.  Registration Procedure  . . . . . . . . . . . . . . . . .   4
     2.2.1.  Required Information  . . . . . . . . . . . . . . . .   4
     2.2.2.  Registration Form . . . . . . . . . . . . . . . . . .   6
     2.2.3.  Registration Processing . . . . . . . . . . . . . . .   8
     2.2.4.  Updating Registry Entries . . . . . . . . . . . . . .   8
 3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
 4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
 5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
   5.2.  Informative References  . . . . . . . . . . . . . . . . .  12
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
 Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

 Domain name registries implement a variety of operational and
 business models.  The differences in these models make it impossible
 to develop a "one size fits all" provisioning protocol; the
 Extensible Provisioning Protocol [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 RFC
 3735 [RFC3735].
 RFCs 3735 and 5730 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 as a result.
 An IANA registry can be used to help manage and coordinate the
 development of protocol extensions.  This document describes an IANA
 registry that will be used to coordinate the development of EPP
 extensions.

Hollenbeck Informational [Page 2] RFC 7451 EPP Extension Registry February 2015

2. Extension Specification and Registration Procedure

 This section describes the format of an IANA registry and the
 procedures used to populate and manage registry entries.

2.1. Extension Specification

 This registry uses the "Specification Required" policy described in
 RFC 5226 [RFC5226].  An English language version of the extension
 specification will be referenced from the registry, though non-
 English versions of the specification may also be provided.  Note
 that Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines
 for documenting EPP extensions.
 Note that the "Specification Required" policy implies review by a
 "designated expert".  Section 3 of RFC 5226 [RFC5226] describes the
 role of designated experts and the function they perform.

2.1.1. Designated Expert Evaluation Criteria

 A high-level description of the role of the designated expert is
 described in Section 3.2 of RFC 5226 [RFC5226].  Specific guidelines
 for the appointment of designated experts and the evaluation of EPP
 extensions 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 [RFC5226].  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], including the Security
 Considerations section of that document.  Expert evaluation should
 explicitly include consideration of the privacy consequences of
 proposed extensions, and, at a minimum, ensure that any privacy
 considerations are fully documented in the relevant specification(s).
 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 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

Hollenbeck Informational [Page 3] RFC 7451 EPP Extension Registry February 2015

 eppext mailing list.  If the specification for an extension is an
 IETF Standards Track document, no review is required by the
 designated expert.
 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 potential registrant who submits a request
 to register a new, un-deployed extension that includes similar
 functionality to an existing, registered extension should be made
 aware of the existing extension.  The registrant should be asked to
 reconsider their request given the existence of a similar extension.
 Should they decline to do so, perceived similarity should not be a
 sufficient reason for rejection as long as all other requirements are
 met.

2.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.

2.2.1. Required Information

 Name of Extension: A case-insensitive, ASCII text string that
 contains the name of the extension specification.  Non-ASCII
 representations of the extension name can be included in the "Notes"
 described below.
 Document Status: The document status ("Informational", "Standards
 Track", etc.) of the specification document.  For documents that are
 not RFCs, this will always be "Informational".
 Reference: A publicly available reference to the specification of
 this extension.  This could be an RFC number or some other pointer to
 the document defining the extension.
 Registrant Name and Email Address: The name and email address of the
 person that is responsible for managing the registry entry.  If the
 registration is of an IETF Standards Track document, this can simply
 be listed as "IESG, <iesg@ietf.org>".

Hollenbeck Informational [Page 4] RFC 7451 EPP Extension Registry February 2015

 TLDs: A text string containing the top-level domain name (or domain
 names), including the preceding ".", for which the extension has been
 specified (e.g., ".org").  If there are multiple TLDs, they are given
 as a list of domain names separated by commas, (e.g. ".com", ".net").
 Internationalized Domain Name (IDN) TLDs should be specified in
 A-label [RFC5890] format.  If the extension is not associated with a
 specific top-level domain, the case-insensitive text string "Any" can
 be used to indicate that.
 IPR Disclosure: A pointer to any Intellectual Property Rights (IPR)
 disclosure document(s) related to this extension, or "None" may be
 used if there are no such disclosures.  This can be an IPR disclosure
 filed with the IETF in accordance with RFC 3979 [RFC3979] as updated
 by RFC 4879 [RFC4879] if the extension is part of an IETF
 Contribution, or it can be other IPR disclosure documents identifying
 the claimed intellectual property rights and terms of use for
 extensions that are not part of an IETF Contribution.
 Status: Either "Active" or "Inactive".  The "Active" status is used
 for extensions that are currently implemented and in use.  The
 "Inactive" status is used for extensions that are not implemented or
 are otherwise not being used.
 Notes: Either "None" or other text that describes optional notes to
 be included with the registered extension.  If the Status value is
 "Inactive", text should be included to describe how and when this
 state was reached.

Hollenbeck Informational [Page 5] RFC 7451 EPP Extension Registry February 2015

2.2.2. Registration Form

 The required information must be formatted consistently using the
 following registration form.  Form field names and values may appear
 on the same line.
  1. —-BEGIN FORM—–

Name of Extension:

  <text string> (quotes are optional)
  Document Status: <document status>
  Reference: <RFC number, URL, etc.>
  Registrant Name and Email Address:
  <registrant name>, <email address>
  TLDs: "Any"|<one or more TLD text strings separated by commas>
  IPR Disclosure: "None"|<URL>
  Status: "Active"|"Inactive"
  Notes: "None"|<optional text>
  -----END FORM-----

Hollenbeck Informational [Page 6] RFC 7451 EPP Extension Registry February 2015

 Example form with RFC specification:
  1. —-BEGIN FORM—–

Name of Extension:

  "An Extension RFC for the Extensible Provisioning Protocol (EPP)"
  Document Status:
  Standards Track
  Reference:
  RFC XXXX
  Registrant Name and Email Address:
  IESG, <iesg@ietf.org>
  TLDs: Any
  IPR Disclosure: None
  Status: Active
  Notes: None
  -----END FORM-----
 Example form with non-RFC specification:
  1. —-BEGIN FORM—–

Name of Extension:

  "An Example Extension for the .example Top-Level Domain"
  Document Status:
  Informational
  Reference:
  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
  Status: Active
  Notes: None
  -----END FORM-----

Hollenbeck Informational [Page 7] RFC 7451 EPP Extension Registry February 2015

2.2.3. Registration Processing

 Registrants should send each registration form to IANA with a single
 record for incorporation into the registry.  Send the form via email
 to <iana@iana.org> or complete the online form found on the IANA web
 site.  The subject line should indicate 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.  On receipt of the
 registration request, IANA will initiate review by the designated
 expert(s), who will evaluate the request using the criteria in
 Section 2.1.1 in consultation with the eppext mailing list.

2.2.4. Updating Registry Entries

 When submitting changes to existing registry entries, include text in
 the "Notes" field of the registration form describing the change.
 Under normal circumstances, registry entries are only to be updated
 by the registrant.  If the registrant becomes unavailable or
 otherwise unresponsive, the designated expert can submit a
 registration form to IANA to update the registrant information.
 Entries can change state from "Active" to "Inactive" and back again
 as long as state-change requests conform to the processing
 requirements identified in this document.  In addition to entries
 that become "Inactive" due to a lack of implementation, entries for
 which a specification becomes consistently unavailable over time
 should be marked "Inactive" by the designated expert until the
 specification again becomes reliably available.

3. IANA Considerations

 IANA has created the "Extensions for the Extensible Provisioning
 Protocol (EPP)" registry to manage EPP extensions.  This registry has
 its own heading on IANA's protocol listings.  The information to be
 registered and the procedures to be followed in populating the
 registry are described in Section 2.
 Name of registry: Extensions for the Extensible Provisioning Protocol
 (EPP)
   Section at http://www.iana.org/protocols:
     Registry Title: Extensions for the Extensible Provisioning
                     Protocol (EPP)
     Registry Name: Extensions for the Extensible Provisioning
                    Protocol (EPP)
     Registration Procedure: Specification Required
     Reference: this document

Hollenbeck Informational [Page 8] RFC 7451 EPP Extension Registry February 2015

 Required information: See Section 2.2.1.
 Review process: "Specification Required" as described in RFC 5226
 [RFC5226].
 Size, format, and syntax of registry entries: See Section 2.2.1.
 Initial assignments and reservations:
  1. —-BEGIN FORM—–

Name of Extension:

     "Domain Registry Grace Period Mapping for the
     Extensible Provisioning Protocol (EPP)"
     Document Status:
     Standards Track
     Reference:
     RFC 3915
     Registrant Name and Email Address:
     IESG, <iesg@ietf.org>
     TLDs: Any
     IPR Disclosure: None
     Status: Active
     Notes: None
     -----END FORM-----

Hollenbeck Informational [Page 9] RFC 7451 EPP Extension Registry February 2015

  1. —-BEGIN FORM—–

Name of Extension:

     "E.164 Number Mapping for the
     Extensible Provisioning Protocol (EPP)"
     Document Status:
     Standards Track
     Reference:
     RFC 4114
     Registrant Name and Email Address:
     IESG, <iesg@ietf.org>
     TLDs: Any
     IPR Disclosure: None
     Status: Active
     Notes: None
     -----END FORM-----
  1. —-BEGIN FORM—–

Name of Extension:

     "ENUM Validation Information Mapping for the
     Extensible Provisioning Protocol"
     Document Status:
     Standards Track
     Reference:
     RFC 5076
     Registrant Name and Email Address:
     IESG, <iesg@ietf.org>
     TLDs: Any
     IPR Disclosure: None
     Status: Active
     Notes: None
     -----END FORM-----

Hollenbeck Informational [Page 10] RFC 7451 EPP Extension Registry February 2015

  1. —-BEGIN FORM—–

Name of Extension:

     "Domain Name System (DNS) Security Extensions Mapping for the
     Extensible Provisioning Protocol (EPP)"
     Document Status:
     Standards Track
     Reference:
     RFC 5910
     Registrant Name and Email Address:
     IESG, <iesg@ietf.org>
     TLDs: Any
     IPR Disclosure: None
     Status: Active
     Notes: None
     -----END FORM-----
 In addition, the form used to populate and manage the registry will
 be added to the table of Protocol Registration Forms maintained by
 IANA.

4. Security Considerations

 This document introduces no new security considerations to EPP.
 However, extensions should be evaluated according to the Security
 Considerations of RFC 3735 [RFC3735].

5. References

5.1. Normative References

 [RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
            Technology", BCP 79, RFC 3979, March 2005,
            <http://www.rfc-editor.org/info/rfc3979>.
 [RFC4879]  Narten, T., "Clarification of the Third Party Disclosure
            Procedure in RFC 3979", BCP 79, RFC 4879, April 2007,
            <http://www.rfc-editor.org/info/rfc4879>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008, <http://www.rfc-editor.org/info/rfc5226>.

Hollenbeck Informational [Page 11] RFC 7451 EPP Extension Registry February 2015

 [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
            STD 69, RFC 5730, August 2009,
            <http://www.rfc-editor.org/info/rfc5730>.
 [RFC5890]  Klensin, J., "Internationalized Domain Names for
            Applications (IDNA): Definitions and Document Framework",
            RFC 5890, August 2010,
            <http://www.rfc-editor.org/info/rfc5890>.

5.2. Informative References

 [RFC3735]  Hollenbeck, S., "Guidelines for Extending the Extensible
            Provisioning Protocol (EPP)", RFC 3735, March 2004,
            <http://www.rfc-editor.org/info/rfc3735>.

Acknowledgements

 The information described in the registry is based on a suggestion
 posted to the provreg mailing list by Jay Daley in August 2013.

Author's Address

 Scott Hollenbeck
 Verisign Labs
 12061 Bluemont Way
 Reston, VA  20190
 US
 EMail: shollenbeck@verisign.com
 URI:   http://www.verisignlabs.com/

Hollenbeck Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7451.txt · Last modified: 2015/02/03 05:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki