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

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

John, 

To clarify the "we" in the statement "Based on your feedback, we agree to revise the draft to be a command-response extension and to refer to an SMTPUTF8 address instead of an EAI address." are the co-editors (me and Dmitry).  We (co-editors) are attempting to address your feedback based on the scope of the draft that was discussed in the WG.  Changing of the cardinality (one to many) to support an SMTPUFT8 address in addition to an ASCII address was first brought up by you during the IETF last call.  It sounds like you agree that an ASCII address is not required, which is good.  Where we (co-editors) and you disagree is your proposal of changing the cardinality of the e-mail addresses in EPP, which is a material change that we (co-editors)  don't believe is warranted.  If there is the need to change the cardinality of e-mail addresses in EPP, then a new EPP extension can be created for that purpose.  That is not intended to do handwaving, but to state how things are handled in EPP.  My point around the FOA and RFC 9154 was meant to show that the concern you raised is not a current issue and should not be an issue in the future.  

We can agree to disagree on the cardinality proposal.  I would like to hear from others on this topic. 

Thanks,

-- 
 
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/30/22, 3:44 PM, "John C Klensin" <[e-mail]> wrote:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

    (TL;DR summary at end)

    --On Tuesday, August 30, 2022 12:18 +0000 "Gould, James"
    <[e-mail]> wrote:

    > John,
    > 
    > You claim that the registrant's e-mail address in the registry
    > is critical to the transfer process and therefore an ASCII
    > address must always be provided.

    That is not what I said and I have explained, several times now,
    that I have not said or claimed it.  What I have said is that,
    if a non-ASCII email address is to be supported, there should be
    provision --as part of this change, not some handwaving about
    future possible extensions-- for an all-ASCII alternative to be
    provided.

    >  The EPP credential used to
    > authorize a transfer is not the e-mail address, but the
    > Authorization Information.  I'm aware of the Form of
    > Authorization (FOA) that relies on the registrant's e-mail
    > address, which is currently deferred for the gaining registrar
    > (registrar ABC in your example).  RFC 9154 "EPP Secure
    > Authorization Information for Transfer" was created to enhance
    > the security of the Authorization Information, which should
    > result in reducing or removing the dependency on the FOA from
    > the gaining registrar and the use case that you're concerned
    > with.  

    This is all wonderful.  But unless you are prepared to show that
    RFC 9154 has been universally adopted, all the above does is to
    strengthen the case for allowing for (again, I did not say
    "requiring in practice") an all-ASCII alternative address when a
    non-ASCII one is supplied.  And, even if you could show that
    level of adoption, it would have nothing to do with all of the
    other uses of information that might reasonably be expected to
    be in registry databases.

    > You also claim that if the draft does not change the
    > cardinality of the e-mail address in EPP that it's not a
    > proper candidate for processing as an IETF standards track
    > document.  Adding support for EAI addresses as a first-class
    > alternative to ASCII addresses in EPP is an important change
    > that warrants an IETF standards track document.  

    I didn't say that either.  I'm not even convinced that
    "cardinality of the e-mail address" is relevant.   I believe it
    was you who claimed that, since that cardinality was not
    changed, there was no need to show this document as updating
    5730.    What I have tried to say on that subject, several
    times, is that draft-ietf-regext-epp-eai is either making a
    substantive change to 5730 or it is purely supplemental to it.
    If it is making a substantive change, then it must be identified
    as updating 5730.

    It is fairly clear to me that, if a document said "there are
    three ways" and one adds a fourth, that it is a change
    ("update").  Contrary to an earlier claim from you about what I
    said, I never claimed that the document said "there can be only
    three".

    Of course, if you are dropping the "functional extension" idea
    and moving to one of the extension types specified in 5730, that
    issue is, of course, moot.

    > For an EAI address to be stored in the registry database, it
    > needs to pass through 3 levels of policy.  The registry policy
    > needs to support receiving either an ASCII address or an EAI
    > address.  The registrar policy needs to support collecting an
    > EAI address as an alternative to or in additional to an ASCII
    > address, and support passing the EAI address to an EAI-enabled
    > registry.  The registrant decides, according to their policy,
    > to provide an EAI address to the registrar.  The protocol
    > should not override these policy decisions by mandating an
    > ASCII address always be provided.

    Ok.  Really interesting.  And almost completely irrelevant to
    this particular specification and protocol, as you have
    indicated in the past.  You have left several actors whom I
    consider important out of your explanation, but that is almost
    completely irrelevant as well.  I even agree about the last
    sentence but, while I will again point out that the experience
    with SMTPUTF8 addresses (outside narrowly defined contexts)
    would recommend providing such addresses, neither I (nor, as far
    as I can remember), anyone else has recommended "mandating"
    them, much less overriding any policy decisions.  Instead, the
    recommendation has, consistently, been that the protocol for
    passing along non-ASCII addresses (I note that you continue to
    use "EAI address" above) if the relevant actors decide to do
    that also make provision for passing along all-ASCII ones should
    those actors make that decision.

    If I try to rephrase that into the language of your paragraph
    above, if any of the relevant actors, including those I believe
    you have omitted, decide that a non-ASCII email address is not
    acceptable unless an ASCII alternative is supplied, the protocol
    should not override that policy decision by making it impossible
    to provide such an address, at least without going back to the
    IETF and trying to initiate additional work that, because it was
    not designed when the protocol specification was approved, might
    turn out to be more kludge-like than desirable.

    > In line with Universal Acceptance (UA), what
    > draft-ietf-regext-epp-eai does is to enable the servers
    > (registries) and clients (registrars) to pass EAI addresses as
    > first-class citizens to ASCII addresses in EPP, with the
    > appropriate signaling and behavior obligations.

    I was not aware that the IETF had accepted the efforts of the UA
    effort as binding technical judgments rather than, e.g.,
    promotional efforts from another community.   References to that
    work and its conclusions are notably missing from the document.
    I recommend that we not go there.

    > Based on your feedback, we agree to revise the draft to be a
    > command-response extension and to refer to an SMTPUTF8 address
    > instead of an EAI address.  Changing the cardinality of the
    > e-mail addresses in EPP to continue to support an ASCII
    > address is required policy is not in line with the purpose
    > this draft.

    Could you, or the WG Chairs, please explain "we" as used in the
    paragraph above?  I just took a quick look at the REGEXT mailing
    list archive and there is no evidence of any discussion in the
    WG -- the only relevant messages are those copied from this list
    discussion.   I also note that the minutes of the REGEXT meeting
    from IETF 114 say, in part, 

    	"This document has quite some discussion in the
    	IETF-wide last call, and issues reported from: i18ndir,
    	secdir and artart LC.

    	"No in-meeting comments beyond the above."

    So, whomever "we" is, it presumably is not the WG who forwarded
    this document to the IESG for publication approval and that has
    tracked it closely since, approving of each change.   I also
    note that, despite the changes you outline above, the Shepherd's
    report has not been updated since April.


    TL;DR summary, as promised...

    I appreciate the changes you have outlined above.  I should
    perhaps wait for a new draft, and perhaps a new Shepherd report,
    before commenting further, but, assuming those changes will be
    as I am assuming, there is only one remaining
    technical/substantive issue and that is whether, if you are
    going to provide for transmitting a non-ASCII email address in
    the protocol, you should also make provision for supplying a
    non-ASCII alternative in the protocol as well.   Such provision
    would be consistent with the recommendations and experience of
    the EAI WG as well as several of the examples I have tried to
    supply; not providing it is inconsistent with both.  You will
    please note that the previous sentence does not say "required to
    use" -- that is clearly a policy matter -- only that the
    provision should be there.

    At this point, there is a separate issue, which is whether,
    given almost no evidence of WG discussion of this document after
    it was adopted (converted from draft-belyavskiy-epp-eai) and
    certainly not after external reviews started to be requested,
    this is properly processed as a WG document with the strong
    assumption of consensus within the WG rather than as an
    individual submission by the authors, perhaps one that the WG
    decided was a good idea in principle.

    thanks,
       john