Colleagues,

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.

best,

Suzanne