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

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

I agree with Adrian that this should be Informational.

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.

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.

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.

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.

Thanks for speedily addressing my discuss.

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.