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

["Gould, James" <[e-mail]>]

John,

How about if we change the approach to use the well-understood command-response extension? 

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 8/22/22, 10:39 AM, "John C Klensin" <[e-mail]> wrote:



    --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://secure-web.cisco.com/1FFl2HRtn03OI1uYW4OziM8X04xwiZaDpI6faRMrp_sl_k6uI813q1FID15MuTI_qCAIZCvskSJNkX6vl0E5foP5RDE2qD3XFsqzlhRu5bPMBHMAEVwrJkL4b-tuANrfjDEae41xnlGu989Mjm1TylOs0lVZf1xIX3RrHkxB7tzLKCjLNHB9ftB-gJZTALg1JVE8GL1o7ig4AmEyWQ3MpxOCAQXiAU1S0qYBA1tM4iPywnScxlQOaYrsmD2ur5oe7/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FG08akVkCjnXEPw8k
    > 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