Re: [I18ndir] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

[John C Klensin <[e-mail]>]

--On Monday, 22 August, 2022 12:00 +0000 "Gould, James"
<[e-mail]> wrote:

> John, 
> 
> I will address your point (5), based on the prior thread that
> we had back in May
> (https://mailarchive.ietf.org/arch/msg/regext/G08akVkCjnXEPw8k
> 7NiCHbeEamo/), where I stated:
> 
> I don't agree that section 2.7 of RFC 5730 defines the only
> forms of extensibility that can ever be supported by EPP and
> by defining a new form of extensibility to solve a specific
> problem in EPP is disallowed or non-compliant with RFC 5730.

But, as I pointed out then and in my most recent note, you are
arguing against a position that has never (to my knowledge) been
taken.  5730 does not says "only ... ever".  What it does say is
"three".  Making that "four" (or even reverting to the longer
Informational list in RFC 3735) is a change/ update to 5730.

> In this case, the form of extensibility (Functional Extension)
> is formerly defined in draft-ietf-regext-epp-eai for clarity
> for use in solving the specific problem of EAI in EPP.  The
> intent is not to define a new form of extensibility to EPP in
> RFC 5730 to solve other similar problems.

And, again, while I would still believe this is an update/
change to EPP, I would be somewhat less concerned about the
issue if draft-ietf-regext-epp-eai explicitly explained why this
extension would not ever be needed for anything else.  It does
not.  A strong argument against doing so, as I think you pointed
out, is that it is not possible to predict the future.  However,
at this point, that turns this extension into a possibly
general-use one and brings us back to an update to 5730.


>  I agree if a
> Functional Extension is meant to be a new formal form of
> extensibility for use in other yet to be defined EPP
> extensions, then it would make sense to define it in a draft
> by itself, but that is not the case with
> draft-ietf-regext-epp-eai.

Noting that I did not mention the "separate document" issue in
my recent note (although that would be my personal preference),
your comment above implies that this is an informal (i.e.,
not-formal) form of extensibility, I have no idea what that
means in a standards track document. Certainly 5730 does not
define informal extensions in its section 2.7 (or, AFAICT,
anywhere else).

Let me see if I can explain why this apparently small issue
concerns me enough to want to be sure it is identified on Last
Call and considered by the IESG.  So as to not be entirely about
theorizing, I'm going to use a specific example of which the
IESG (at least) is painfully aware.  Without getting into the
details, there is a proposal to create a new URI type floating
around (draft name on request if that would be useful).  One of
its characteristics is inconsistent with most readings of RFC
3986, an Internet Standard, and there has been considerable
pushback as a result.  Now, suppose its author borrowed the
general outline of Section 4 of draft-ietf-regext-epp-eai-15 and
included a section in his specification that said that it
provided a syntax extension to 3986 and then proceeded to
describe that extension.   Then he claimed that he specified
that as an informal extension and that there was no proof that
anyone would use it for anything else and hence that his URI
type could be adopted in spite of what 3986 appears to say and
without updating 3986.

If your functional extension can really be made without updating
or changing 5730, then I don't see any basis for rejecting that
other proposal (rewritten that way) simply because it is
inconsistent with the 3986 syntax.

Now, importantly, I can see an argument for rejecting the "new
informal extension" URI proposal and not
draft-ietf-regext-epp-eai.  It is that the URI extension would
probably be disruptive to a large family of web and other
applications out there which depend on the existing syntax while
draft-ietf-regext-epp-eai affects only the registrar and
registry communities and that all of the users of EPP have
signed off on its being non-disruptive.  However, I have seen no
evidence that all users of EPP --presumably including ccTLDs who
have chosen to use it, perhaps without consulting the REGEXT
WG-- have been consulted about that, much less agreed.  That, in
turn, brings us, not to RFC 5730 but to RFC 7451.  The latter
says that a new extension requires only "Specification Required"
and expert review.  

A different way of looking at the question is that you are
trying to have it both ways: the IETF endorsement and approval
that goes with making the document standards track but on the
basis of agreement within a restricted community only
(registries and registrars for gTLDs ?).  I don't believe the
experts should approve this without an update to 5730 but, if it
really does not update/change 5730, then it is not clear why you
need standards track (and to put up with complaints from the
likes of me that, as written, it is not appropriate for that
status).

thanks,
   john