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

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

(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