Last Call Review of draft-ietf-eppext-reg-08
review-ietf-eppext-reg-08-opsdir-lc-woolf-2014-10-02-00

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