Subject: [eppext] Benoit Claise's No Objection on draft-ietf-eppext-reg-08: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 02 Oct 2014 02:13:58 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-eppext-reg-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/

----------------------------------------------------------------------
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.