Re: [I18ndir] draft-klensin-idna-rfc5891bis

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

Alissa,

Thanks for your note.  There are three important reasons why you
have not heard back from me on your second point or this
document more generally:

(1)  I continue to believe that language with the meaning of
"you SHOULD do X but, if you cannot, then..." not only does not
violate some principle about what the IETF cannot do in a
consensus document, but is something we have done several times
in the past.  Now there _is_ a problem: the existing text in
RFCs 5890-5892 and 5894 essentially says that registries and
registrars MUST behave in certain ways.  That text not only had
consensus in the IETF but, as I pointed out in my note to Scott,
was the subject of semi-formal agreements with and among ICANN
and relevant constituencies.  Part of what prompted this
document was that requirement is being ignored at the top levels
of the DNS, ICANN has chosen to not enforce it or feels unable
to do so, and we (not just Asmus and I) believed that some
clarification was in order to allow moving forward with other
IDN work.  Now, in terms of what the IETF does in more usual
circumstances, we might reasonably say to ourselves "well, that
MUST is not being followed, let's amend/update the base
documents to make it a SHOULD with or without text explaining
why following the SHOULD would be a good idea".  There are three
problems with that approach in this case.  First, for such a
statement to work in the IETF, "not being followed" would
normally be accompanied by "and there has been no damage".  But
damage (that some consider serious) has occurred with
opportunities for clear interoperability and/or security
problems: the MUST-level requirement in the text is consistent
with the principle that MUST should be used when the alternative
is interoperability problems.   Second, in the community at
issue, SHOULD would be almost certain to be interpreted as
"unless we think it is against our best interests (whether
financial or otherwise)", thereby opening the door wide to
precisely the type of abuses draft-klensin-idna-rfc5891bis is
intended to mitigate.  The third problem isn't nearly as
important in principle but the long-ago decision to break
IDNA2008 into four (or five) documents would make explicitly
relaxing that requirement a lot of work that I don't see anyone
stepping forward to do (see (2) below).

So, to me, some variation on "you SHOULD do X and, if you don't,
you should consider..." language is The Right Thing To Do and we
should be working on how to make that work even if it is a bit
unusual.

(2) If we start rewriting that text, especially in subtle ways,
I think it would be very unwise to go forward --it would be
reasonable to say that I would be afraid of doing so-- without
very careful and collective review by a group of people whose
perspectives bear on all aspects of the IDNA situation.  While
not as strong as I would have liked, the intent of the I18N
Directorate was, at least in part, to provide exactly that sort
of review.  As far as I can tell, it has been almost completely
disfunctional since early in 2020, reaching a point sometime
last summer where neither Pete, nor Peter, nor Barry were even
responding to questions about how to proceed.  While the fixes
for your first concern (and some of the issues raised by Ben and
others) did not make any changes that I considered potentially
substantive (Asmus's comment about the changes not affecting the
substantial points is consistent with that), I do not think it
wise to move forward with this document except in the context of
a way to make that kind of review.  At present, I don't have any
good ideas about where that would come from, at least within the
IETF.

(3) This document, if approved, would serve two proposes.  The
first is really about ICANN and its problems.  If someone
violated the rules and their intent in a way that caused injury,
the document and what it points out about the earlier ones would
create a much more firm foundation for legal action against the
relevant registry and/or ICANN over the damaging behavior.  I
don't like it when things are done that way but, absent the
protocol police, the situation here should not be very different
than the exposure of a company that contracts to deliver a
working implementation of TCP/IP and then delivers something
that does not conform to our specs and, as a result, won't
interoperate.  Perhaps that is not the IETF's problem and we
should walk away but, from at least one reasonable perspective,
getting things to work together and helping identify the
problems when they don't is why we write standards.  The second
is to lay another key part of the foundation for other work on
IDNA that is clearly (at least to the likes of me, Asmus, and
Patrik and presumably to those who pushed for updated IANA
tables and the work that led to RFC 8753) needed at this point.
But, if the IETF is not going to do that work -- and both the
observation that two sets of reviews that should have been done
under RFC 8753 have not happened and the current state of the
directorate may be strong hints that it is either not inclined
or not able to do so -- then it may well be that putting more
energy into erecting a better foundation that will not be built
upon is not a good investment of time or energy.  

I fortunately was not asked on Tuesday whether the IETF was
dealing with some particular i18n issue because I probably would
have needed to reply that the IETF was apparently not interested
and that, if they thought the problem was important, they either
needed to supply a lot more expertise to the IETF (and hope they
would be accepted) or to figure out another venue for addressing
the issues.  However, unless we figure out how to do things
differently, it is only a matter of time before that question is
asked.

Your thoughts (and those of others who receive this) welcome.

Have a good Thanksgiving.
    john


 

--On Wednesday, November 25, 2020 14:51 -0500 Alissa Cooper
<[e-mail]> wrote:

> (I'm going through my list of outstanding DISCUSS positions
> today, thus this email.)
> 
> The changes proposed below address my first DISCUSS point
> well. I don't think I've seen a proposal to address my
> second DISCUSS point.
> 
> Best,
> Alissa
> 
> 
>> On Jul 17, 2020, at 4:01 PM, Asmus Freytag
>> <[e-mail]> wrote:
>> 
>> John,
>> 
>> on quick review, I think the proposed tweaks don't affect the
>> substantial points.
>> 
>> A./
>> 
>> PS: note that many of the issues are related to a different
>> distinction: whether the registry accepts registrations from
>> unrelated entities or not. A third-level domain may only
>> accept "in-house" registrations and would in that case not be
>> exposed to bad-faith registrations. All other registries, no
>> matter whether commercial or not, face the issue of bad-faith
>> registrations (spoofing attempts and other attacks).
>> 
>> Some may have less (business) incentive to do something about
>> it, but just because something is a ccTLD or a gTLD run by a
>> non-profit doesn't mean that they can't be exposed to this by
>> "ignorance". Now, some of the worst offenders are ccTLDs that
>> are "rented out"; some of them even register domains that
>> aren't PVALID ...
>> 
>> A./
>> 
>> On 7/17/2020 12:02 PM, John C Klensin wrote:
>>> 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]> <mailto:[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
>>> 
>> 
>