Extension Registry for the Extensible Provisioning Protocol
draft-ietf-eppext-reg-10

[Ballot comment]
The document shows a warning in idnits.

  == Unused Reference: 'RFC3986' is defined on line 441, but no explicit
    reference was found in the text

---

I cleared my Discuss. Pete indicated that this will be progressed as Informational

[Ballot comment]
This seems wrong:

  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.

If you have a man-in-the-middle, they can presumably modify messages in both directions.  But as Kathleen said, the normal process of review should catch problems of this sort. If that fails, and an erroneous registration occurs, the registrant will see the incorrect IANA registry entry.  So this will serve as an out-of-band mechanism for detecting attacks of this type, since the MITM presumably won't be able to spoof the SSL cert from the IANA web site.

[Ballot discuss]

I believe that there are some uses of EPP that have been
mooted or even put in place that are considerd by quite a few
folks as being quite privacy unfriendly.  If so (and please
correct me if I'm wrong) that indicates that the DEs need to
explicitly include consideration of the privacy consequences
of proposed extensions and that DEs ought at minimum require
that any privacy considerations are fully documented in the
relevant specification(s). If it were up to me, I'd probably
go further on that and ask that the DEs try to ensure that
the world is more privacy friendly, but I suspect that'd be
beyond IETF consensus.

[Ballot comment]
Please see Suzanne's OPS-DIR review below:

Per the usual warning,

“I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.”

Summary: ready with a couple of minor concerns

This document doesn’t document new protocol, instead it attempts to close a gap in the existing EPP protocol, specifically its provisions for extensions, to improve interoperability. The mechanism discussed is an IANA registry for documenting EPP extensions, with expert review (“Specification Required”) as the gate.

The support for interoperability provided seems good. The process does not provide directly for review of extensions that may be similar in their effects or for any attempt to harmonize similar or conflicting extensions, but (per the Shepherd’s writeup) it was judged preferable to keep the process relatively lightweight so people would choose to document their extensions rather than simply choosing not to bother. This is a reasonable accommodation to the real world, in which EPP was written to be easily extensible in support of a range of operational and business models, often by entities who are not primarily software or networking players and wouldn’t necessarily be willing to execute a painful or costly process for registering EPP extensions that may not even be intended for wide use.

The Shepherd’s writeup covered the questions I would have regarding guidelines to the Expert.

As an editorial nit, Sec. 2.2.3 and 2.2.4 both move between second person (instructions to the submitter of a proposed registry entry) and third person description of the process.

I also have some confusion about one of the fields in the proposed registry. It’s not clear to me exactly what purpose is served by the “Active”/“Inactive” flag:

The definition of “active”/“inactive” in 2.2.1:

        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.


doesn’t seem fully consistent with the text in 2.2.4:

        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.


This seems to assume that “availability of the specification” is closely related to whether the extension is “available for use,” but I’m not sure either term is sufficiently clear as an instruction to IANA, the Expert, or potential registrants for entries in the registry. However, there may be an understanding in place between IANA and the IESG on how to manage “availability of the specification” as a factor in “Specification Required” registries. If this is clear to IANA and to the WG (which I know includes potential experts) as sufficient guidance, I suggest clarifying it if possible in the document. If not, I would wonder if the field needs to be more clearly defined, or is simply not necessary.

The question above is, however, a very minor point in the big picture, which is that we’re trying to get people to document their EPP extensions and this document gives them a relatively lightweight but useful way to do so.

The Shepherd’s writeup raises the question of whether this document should be Standards Track or Informational. I tend to think that a document establishing an IANA registry, with a registration policy that isn’t simply FCFS, be Standards Track, but as this one doesn’t involve assignment of unique codepoints out of a number space— just text strings—that detail doesn’t seem critical.

[Ballot comment]
the security considerations section doesn't have anything to do with the protocol or the registry, nor is it instruction to iana, if it was it would be in the iana considerations section.

[Ballot discuss]
[Cleared the bit about IANA as Pete now has it in his Discuss]

Last time we went through a similar document, the IESG asked me why I
was running it as Standards track when Informational seemed to be good
enough and there was no description of protocol behavior in the
document. Additionally, the IESG seemed to think that this sort of
document might usefully be tagged as updating the RFC(s) that define
the registries it discusses.

Personally, I find it hard to care about this point and I am not asking
the author to make any changes. But I would like to take advantage of
the IESG telechat to ask the IESG to try to be a little consistent! I
will remove this part of the Discuss during the telechat.

[Ballot discuss]
Holding a Discuss for IANA's request of 9/30

> NOTE: Please update the next version to include the revisions
> raised in ticket 782732 during Last Call.

[Ballot comment]
This is just a comment as I don't have any issues with the security considerations, just a question.  Aren't the security considerations addressed by the expert review required?  The registry won't just get amended as a result of an email request.  The rest of the process should help.

Please respond to the SecDir review and suggestions as well, thanks:
https://www.ietf.org/mail-archive/web/secdir/current/msg05091.html

Yoav had a similar comment, so how about the following text for the Security Considerations section:

"Security Considerations

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

Thanks.

[Ballot comment]
This is just a comment as I don't have any issues with the security considerations, just a question.  Aren't the security considerations addressed by the expert review required?  The registry won't just get amended as a result of an email request.  The rest of the process should help.

Please respond to the SecDir review and suggestions as well, thanks:
https://www.ietf.org/mail-archive/web/secdir/current/msg05091.html

Thanks.

[Ballot comment]
This is just a comment as I don't have any issues with the security considerations, just a question.  Aren't the security considerations addressed by the expert review required?  The registry won't just get amended as a result of an email request.  The rest of the process should help.

Thanks.

[Ballot discuss]
Holding a Discuss for IANA's request of 9/30

> NOTE: Please update the next version to include the revisions
> raised in ticket 782732 during Last Call.

Please resolve the issues to IANA's satisfaction and update the document as necessary.

---

Last time we went through a similar document, the IESG asked me why I
was running it as Standards track when Informational seemed to be good
enough and there was no description of protocol behavior in the
document. Additionally, the IESG seemed to think that this sort of
document might usefully be tagged as updating the RFC(s) that define
the registries it discusses.

Personally, I find it hard to care about this point and I am not asking
the author to make any changes. But I would like to take advantage of
the IESG telechat to ask the IESG to try to be a little consistent! I
will remove this part of the Discuss during the telechat.

[Ballot comment]
The document shows a warning in idnits.

  == Unused Reference: 'RFC3986' is defined on line 441, but no explicit
    reference was found in the text

[Ballot comment]
Does the WG want to put any limitations on the Reference portion of the registry entry?  I was wondering how useful the Reference field would be if the link was: 1) behind a paywall, 2) restricted to "members", or 3) not publicly available.

IESG/Authors/WG Chairs:

IANA has a question about the actions and note a about the registration process described in draft-ietf-eppext-reg-08. Please see below.

Upon approval of this document, IANA understands that there is a single action which must be completed.

This document creates a new registry called "Extensions for the Extensible Provisioning Protocol."

The new registry will be managed via Specification Required as defined by RFC 5226. The information to be contained in the new registry is specified in section 2.2.1 of the approved document.

IANA Question --> Should this registry be created at an existing URL? If not, does it also require a new heading at http://www.iana.org/protocols, or does it fit under an existing heading?

These are the initial registrations:

Extension Name: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
Document Status: Standards Track
Reference: [ RFC3915 ]
Registrant Name and Email Address: IESG,
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

Extension Name: E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
Document Status: Standards Track
Reference: [ RFC5114 ]
Registrant Name and Email Address: IESG,
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

Extension Name: ENUM Validation Information Mapping for the Extensible Provisioning Protocol
Document Status: Standards Track
Reference: [ RFC5910 ]
Registrant Name and Email Address: IESG,
TLDs:
IPR Disclosure: None
Status: Active
Notes: None

A word about the registration procedure: we understand that more than one expert will be designated, that registrations will be discussed on a mailing list, and that an expert will send their decision to IANA when the discussion is complete. The document also states that applicants should initiate the process by sending their requests to IANA. It isn't clear, though, whether IANA should be forwarding those requests to one of the experts or to the mailing list. We're wondering whether it would be more efficient for applicants to send their requests directly to the mailing list.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extension Registry for the Extensible Provisioning Protocol) to Proposed Standard


The IESG has received a request from the Extensible Provisioning Protocol
Extensions WG (eppext) to consider the following document:
- 'Extension Registry for the Extensible Provisioning Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ballot/


No IPR declarations have been submitted directly on this I-D.

Extension Registry for the Extensible Provisioning Protocol
draft-ietf-eppext-reg-07


This document is submitted for consideration as a Proposed Standard.


Technical Summary

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.


Working Group Summary

One issue that was discussed at length by the working group is whether
or not "Specification Required" was a sufficient IANA policy for this
registry.  Of concern was the question of whether or not extensions to
EPP should be reviewed for the purpose of harmonizing extensions that
may be similar.  After considerable debate it was the consensus of the
working group that there was unlikely to be sufficient motivation in
the industry to harmonize extensions as compared to publishing a
specification describing the extension.


Document Quality

The Document Shepherd did a thorough editorial and technical review
of the document, and resolved any issues brought up during WGLC.

The Document Shepherd does not have any concerns about the depth
or breath of the reviews.

This document requests IANA to create a new protocol registry to
manage EPP extensions.  All requirements for such a request have been
met.  A detailed review by IANA is suggested.


Personnel

Jim Galvin (co-chair of the working group) is the Document Shepherd.
Pete Resnick is the responsible Area Director.