[I18ndir] FWD: comments on: draft-klensin-idna-rfc5891bis (Klensin-Hollenbeck)

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

My response to Scott earlier today, as promised...

---------- Forwarded Message ----------
Date: Friday, July 17, 2020 15:02 -0400
From: John C Klensin <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>om>,
[e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: draft-klensin-idna-rfc5891bis

Scott,

Trying to find the right balance on further fine-tuning of the
text is too complex for me to get my mind around right now or,
given other commitments, this afternoon.  I will try to do so
over the weekend, but please think about the following in the
interim.  I am assuming from the change from "profits" to
"revenues" in on the changes below that you have already seen my
response to Ben Kaduk's note earlier this week.  If you have
not, let me know and I will forward a copy.

This I-D does not impose or recommend any restrictions that are
not present in the 2010 IDNA2008 documents.  IIR (I can find my
notes if necessary and try to bring Cary Karp into the
discussion if needed), those restrictions were discussed with
you and Chuck Gomes at the time and the text worked out with you
on that basis.  The document is intended to do three things:

(1) Point out that the provisions for registries taking
responsibility for what they are registering whether those
registries are for TLDs (either gTLD or ccTLD), for so-called
"public" domains, or for zones deep in the tree.  Those
provisions are not rooted in IDNA in any way. They go back at
least to RFC 1591. ICANN still claims to draw authority from
that document and, while I can't remember ever seeing those
documents (I have seen and have copies of some of the documents
from that period), Jon Postel told me and others when we were
reviewing 1591 in the light of the then-evolving IANA transition
plans that the provisions of 1591 were incorporated by reference
into the InterNIC agreement with what was then Network
Solutions.   You or your colleagues may also recall
conversations while Tina Dam was heading ICANN's staff IDN
efforts about registries identifying the scripts or other
collections of characters they were going to allow and then
taking responsibility for using those those lists.  You will
also recall that the "registries must have policies" rule, a
variation on the same principles (including those discussed in
(2) below) were called out in both RFC 4690 (Sections 2.2.7 and
the IESG statement cited in its Section 1.6.1).   Those
discussions resulted in signoff by the gNSO and ICANN Board and
resulted in the rather peculiar IANA IDN script registry (see
the response to Ben) or whatever it is called these days. 

In summary, this is all really old news, representing both
bedrock IANA DNS policies and rough agreement between the IETF
and ICANN communities.  YMMD, but I don't see it as being in
anyone's interest, especially not Verisign's, to rock that
particular boat or flotilla of boats.

(2) To do something that Alissa was also concerned about but
which your changes do not seem to address.  That is, more or
less, to say "those are the rules/standard; if you are not going
to follow them, or able to follow them, these are suggestions
that may help protect the Internet and its users".  While I
agree that statements about what people should do if they decide
to not conform to an IETF Technical Specification are unusual, I
don't think they are nearly as unusual as Alissa's comment
implies.  In particular, they are not that much different from a
specification that says something equivalent to "SHOULD do X
except when special circumstances apply, then do...".  While we
haven't done that very often either, I note that there have been
periodic suggestions, at least since RFCs 2026 and 2119 were
published, that the rules about use of SHOULD (or SHOULD NOT) be
tightened to require either a statement about the circumstances
in which the specified action is not required or can be relaxed,
a statement about what should (sic) be done instead, or both.
In this case, some of the language in the current document was
developed to reflect conversations with Chuck and others about
that original IDNA IDN registry and in the 2006 time frame, and
again during the brief period when I was consulting for
Verisign, about, among other things, the difficulties a "don't
register what you don't understand" rule posed to a registry who
believed that it had some obligation to register labels in a way
that was strictly non-discriminatory toward potential
registrants across the globe but which couldn't possibly have
significant local expertise on all scripts and writing systems.

(3) To provide, at least for relevant scripts and writing
systems, pointers to the ICANN "LGR" work (including the MSR
and, by extension, Asmus's "troublesome characters" work) as a
possible starting point for registries that did not have deep
understanding of a particular script or writing system
("language" if you prefer, but you have been around this stuff
long enough to appreciate the distinction) on being relatively
responsible while not strictly conforming to the "don't register
anything you don't understand" rule that is very clear to anyone
who reads the IDNA2008 specs carefully (or who was part of the
discussions with the gNSO that contributed to them).

>From an IETF standpoint, this document says what it says and
represents sufficient consensus for publication or not (noting
that drafts of it have been around and discussed intermittently
since 2016 and that it did get through both i18n directorate
review (for whatever that might be worth) and IETF Last Call
before the IESG found some language questionable).  It the IETF
consensus is different, it should go away.   If the document
dies the death of 1000 cuts, we are back to the requirement of
the original IDNA2008 specifications that a registry, any
registry, is non-conforming if it registers and delegates an IDN
label that uses a code point sequence it does not fully
understand.

More when I have reviewed the proposed changes -- some or all of
them may turn out to be completely consistent with the above --
but, until I can do so, I wanted to be sure that you (and, as
appropriate, your colleagues) understand where I, and this
document, are coming from and why diluting it, and the
distinctions it makes, significantly would be a problem.

best regards,
    john



--On Friday, July 17, 2020 15:45 +0000 "Hollenbeck, Scott"
<[e-mail]> wrote:

> John, Asmus: sorry for this coming very late in the review
> process, but earlier this week I had some of the product
> people at Verisign express some concern with a few snippets of
> text in the subject document. They're along the lines of
> Alyssa's discuss, so I've cc'd her and Barry as the sponsoring
> AD as well. I'd like to ask you to consider a few text change
> proposals.
> 
> OLD:
> 4. Considerations for Domains Operated Primarily for the
> Financial Benefit of the Registry Owner or Operator
> Organization
> 
> NEW:
> 4. Considerations for Domain Name Registry Operators and
> Registry Operator Service Providers
> 
> OLD:
> Zones operating primarily as all or part of a business of
> selling names for the financial benefit of entities
> responsible for the registry
> 
> NEW:
> Zones operating primarily as all or part of a commercial
> domain name registry
> 
> OLD:
> By contrast, in a zone in which the profits  are derived
> exclusively, or almost exclusively, from selling or reserving
> (including "blocking") names, there may be perceived
> incentives to register whatever names would-be registrants
> "want" or fears that any restrictions will cut into the
> available namespace.  In such situations, restrictions are
> unlikely to be applied unless they meet at least one of two
> criteria: (i) they are easy to apply and can be applied
> algorithmically or otherwise automatically and/or (ii) there
> is clear evidence that the particular label would cause harm.
> 
> NEW:
> By contrast, in a zone in which the revenues are derived from
> registering names, there may be perceived incentives to be
> less conservative regarding some of the restrictions discussed
> above in this document. In such situations, restrictions are
> unlikely to be applied unless they meet at least one of the
> two criteria: (i) there are easy to apply and can be applied
> algorithmically or otherwise automatically and/or (ii) there
> is clear evidence that the particular label would cause harm.
> 
> Do these change proposals work for you?
> 
> Scott


---------- End Forwarded Message ----------