Extension Registry for the Extensible Provisioning Protocol
draft-ietf-eppext-reg-08
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (eppext WG) | |
|---|---|---|---|
| Author | Scott Hollenbeck | ||
| Last updated | 2014-10-02 (Latest revision 2014-09-08) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
Ready with Nits
OPSDIR Last Call review
Has Issues
GENART Last Call review
Ready
SECDIR Last Call review
Has Nits
|
||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | James Galvin | ||
| Shepherd write-up | Show Last changed 2014-07-27 | ||
| IESG | IESG state | IESG Evaluation::Revised I-D Needed | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. |
||
| Responsible AD | Pete Resnick | ||
| Send notices to | eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org | ||
| IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-eppext-reg-08
Network Working Group S. Hollenbeck
Internet-Draft Verisign Labs
Intended status: Standards Track September 8, 2014
Expires: March 12, 2015
Extension Registry for the Extensible Provisioning Protocol
draft-ietf-eppext-reg-08
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 March 12, 2015.
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 March 12, 2015 [Page 1]
Internet-Draft EPP Extension Registry September 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . 5
2.2.3. Registration Processing . . . . . . . . . . . . . . . 7
2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. 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].
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.
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.
Hollenbeck Expires March 12, 2015 [Page 2]
Internet-Draft EPP Extension Registry September 2014
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 appear in the registry, though non-English
versions of the specification can 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 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 RFC 5226. Specific guidelines for the
appointment of Designated Experts and 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. 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
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. 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
Hollenbeck Expires March 12, 2015 [Page 3]
Internet-Draft EPP Extension Registry September 2014
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 text string that contains the
name of the extension specification.
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 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>".
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" if there
Hollenbeck Expires March 12, 2015 [Page 4]
Internet-Draft EPP Extension Registry September 2014
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 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 available for use.
The "Inactive" status is used for extensions that are not implemented
or are otherwise not available for use.
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.
2.2.2. Registration Form
The required information must be formatted consistently using the
following form. Form field names and values may appear on the same
line:
-----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 Expires March 12, 2015 [Page 5]
Internet-Draft EPP Extension Registry September 2014
Example form with RFC specification:
-----BEGIN FORM-----
Name of Extension:
"An Extension RFC for the Extensible Provisioning Protocol (EPP)"
Document Status:
Standards Track
Reference:
http://tools.ietf.org/html/rfcXXXX
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:
-----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 Expires March 12, 2015 [Page 6]
Internet-Draft EPP Extension Registry September 2014
2.2.3. Registration Processing
Send each registration form to IANA with a single record for
incorporation into the registry. The form will be sent via email to
<iana@iana.org> by the extension registrant, and will 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.
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 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. Entries for which a specification becomes consistently
unavailable over time should be marked "Inactive" by the designated
expert until such time as the specification again becomes reliably
available.
3. 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 2.
Name of registry: Extensions for the Extensible Provisioning Protocol
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:
Hollenbeck Expires March 12, 2015 [Page 7]
Internet-Draft EPP Extension Registry September 2014
-----BEGIN FORM-----
Name of Extension:
"Domain Registry Grace Period Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status:
Standards Track
Reference:
http://tools.ietf.org/html/rfc3915
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"E.164 Number Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status:
Standards Track
Reference:
http://tools.ietf.org/html/rfc4114
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
-----END FORM-----
Hollenbeck Expires March 12, 2015 [Page 8]
Internet-Draft EPP Extension Registry September 2014
-----BEGIN FORM-----
Name of Extension:
"ENUM Validation Information Mapping for the
Extensible Provisioning Protocol"
Document Status:
Standards Track
Reference:
http://tools.ietf.org/html/rfc5076
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status:
Standards Track
Reference:
http://tools.ietf.org/html/rfc5910
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
-----END FORM-----
Hollenbeck Expires March 12, 2015 [Page 9]
Internet-Draft EPP Extension Registry September 2014
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.
4. 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.
5. Acknowledgements
The information described in the registry is based on a suggestion
posted to the provreg mailing list by Jay Daley in August 2013.
6. References
6.1. Normative References
[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.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
6.2. Informative References
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
Provisioning Protocol (EPP)", RFC 3735, March 2004.
Hollenbeck Expires March 12, 2015 [Page 10]
Internet-Draft EPP Extension Registry September 2014
Appendix A. Change Log
Initial -00: First working group version.
-01: Added initial registry entries to Section 3.
-02: Spelling corrections. Added Section 2.1.1. Added "Notes"
field to the registration template.
-03: Added reference to Section 2.1 of RFC 3735 in Section 2.1.
-04: Added "Status" field to the registration template. Fixed typo
in Section 2.1.1. Reformatted examples and initial registry
entries.
-05: Added text to clarify how existing registry entries can and
can't be edited.
-06: Modified text in Section 2.1.1 to make it clear that it is
possible to register functionally similar extensions.
-07: Address WG last call comments.
-08: Address AD review comments.
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 March 12, 2015 [Page 11]