Re: [I18ndir] Secdir last call review of draft-klensin-idna-rfc5891bis-05

John C Klensin <john-ietf@jck.com> Tue, 03 September 2019 21:47 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081161200B6; Tue, 3 Sep 2019 14:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnx4OI03OWpc; Tue, 3 Sep 2019 14:47:30 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF7F12002E; Tue, 3 Sep 2019 14:47:30 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1i5Ge8-000L3c-M4; Tue, 03 Sep 2019 17:47:28 -0400
Date: Tue, 03 Sep 2019 17:47:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Paul Wouters <paul@nohats.ca>, secdir@ietf.org
cc: draft-klensin-idna-rfc5891bis.all@ietf.org, iesg@ietf.org, i18ndir@ietf.org
Message-ID: <3B79ACC1CBCD8540E819481A@PSB>
In-Reply-To: <156747952912.12965.18139183538869398923@ietfa.amsl.com>
References: <156747952912.12965.18139183538869398923@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/gM0vqn6_dVPRAyaTyw1PiB5f9mE>
Subject: Re: [I18ndir] Secdir last call review of draft-klensin-idna-rfc5891bis-05
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 21:47:33 -0000

Paul,

Noting the arrival of this review 4 1/2 days after the IETF Last
Call nominally closed, and copying the IESG rather than the IETF
list as a result...  I also would have tried to write a shorter
and less complete response had there been a week or so for any
remaining issues or lack or clarify to be the subject of
additional discussion.

--On Monday, September 2, 2019 19:58 -0700 Paul Wouters via
Datatracker <noreply@ietf.org> wrote:

> Reviewer: Paul Wouters
> Review result: Has Nits
> 
> I have reviewed this document as part of the security
> directorate's  ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written
> primarily for the benefit of the security area directors.
>  Document editors and WG chairs should treat  these comments
> just like any other last call comments.
> 
> This document collects IDNA  information from Errata's,
> external information such as ICANN, and some wisdom gathered
> since RFC 5891 was published and presents this set of
> information for operations of domains to make their domains
> more secure with respect to IDNA and its (ab)use.
> 
> The Security Section is a clear summary that states the
> operators should really heed the advise of this document (and
> the documents references and updated)
> 
> Issue:
> 
> It seems the document asks for the IANA Consideration section
> to be removed. Instead, it should keep the Section but use the
> text along the lines of  " This document has no IANA
> actions.". This helps people who are looking through various
> RFC's to find IANA considerations.

Until and unless the rules are changed to require IANA
Considerations sections in all IETF Stream documents, this is a
judgment call.  Your preference is noted but at least this
author believes that the omission of an essentially trivial
statement is more helpful to many users then including it and
keeps documents shorter.  I note that we have several section
titles, including one for Internationalization, that are
routinely omitted if the document has nothing to say that would
call for such a section.

> Minor issues:
> 
> I find the term "For-profit domain" very confusing as .pizza
> is a very much for profit domain. Normally, the terms "Generic
> domain" and "Brand domain" although I guess the latter is
> usually avoided in written text. While the term is described
> to mean a Generic Domain, I think it would be better to use
> Generic domain instead of For-profit domain.

"For-profit" was chosen after multiple discussions about the
best term and was chosen, in part, because it is not in common
use.  IIR, we started with "public domain", a term that is
widely used but, unfortunately, use inconsistently wrt
definitions.  I've personally never seen or heard "brand domain"
used prior to your note but I travel in different circles than
the domainer community.    "Generic" does not work for several
reasons.  First, the term has been used since RFC 1591 and
earlier to make the distinction at the top level from
country-code domains (see https://www.iana.org/domains/root/db
as an example) .  If "sponsored" (a term ICANN started using
around 2000) or "brand" are useful at the top level, they are
presumably subsets of "generic". Second, to use your example, a
"pizza" TLD is generic in the "not a ccTLD" sense, but not in
others (I gather than there are places where a claim that
something was a "generic pizza" would be considered culturally
offensive).  

In the interest of time and space, I won't go on much further,
but remember that this document, like all of the IDNA core
documents, is intended to be applicable to every zone in the
DNS, not just the root or maybe the behavior of TLDs vis-a-via
the names they allocate or delegate.   The main point of this
document, the relevant text in the base IDNA documents, and some
of the language in RFC 1591 is that registries (a term that
comes from early DNS documents is that is repeated in RFC 1591,
and that appears in RFC 8499) are responsible for whatever
strings they register and that they should take that
responsibility seriously.   For IDN purposes and in the core
IDNA documents, that statement took the form of "if you don't
understand the implications of a particular string, including
the writing system implications, don't allow it".   While rarely
explicit, that rule is followed in an overwhelming fraction of
the zones in the DNS.  Most enterprise and organization zones
allocate subdomains using names and terms (or abbreviations for
them) that make sense to them.  They are doing the right thing
and don't need this I-D or the language in the base IDNA
documents to tell them to do that or help with it.   The
problems mostly seem to occur in domains (gTLD, ccTLD, and
deeper in the tree alike) that are dependent on the number of
domains they sell for their income and support.   Probably
because they have incentives to sell more and more names that a
registry that is operated as a public service or on a strict
cost recovery basis typically does not, the former groups have
far less incentive to push boundaries.   Again the offenders
include both traditional ccTLDs, traditional gTLDs, and many or
most of the "new TLDs" created by ICANN in recent years as well
as some situations deeper in the tree -- not all of them,
clearly, but some.

So, for any zone that naturally behaves as the documents being
updated by this one specify, i.e., that doesn't delegate
anything the registry doesn't understand thoroughly, this
document is a non-issue.  It is important for domains that don't
intend to follow that guidance but who intend to register IDNs
anyway.  This is guidance primarily for them and to keep them
and the Internet out of horrible trouble, and "for-profit" is
the closest we could get.  And, before you ask, we didn't say
that in so many words because we are aware that the boundaries
are not absolute and we didn't want to be over-broad.

If you have better suggestions about terminology, they would be
welcome... at least as long as they do not result in delaying
processing and approval of this document.  

>   Registries choosing to make exceptions -- allow code points
> that   recommendations such as the MSR do not allow -- should
> make such   decisions only with great care and only if they
> have considerable   understanding of, and great confidence in,
> their appropriateness.
> 
> This paragraph seems really to say "Registries SHOULD NOT make
> exceptions" and seems a good place for some RFC 2119 wording.

While the language was a compromise -- Asmus is inclined to be
somewhat more restrictive and directive than I am -- "SHOULD
NOT" is definitely not appropriate.   

One of my favorite examples, and one that came up several times
in the discussions leading to IDNA2008, has to do with
characters from archaic scripts.  IDNA2008, after long
discussion, allows them.  ICANN won't allow them in the root
(for good reason) and discourages them at the second level (also
for good reason, although it is more controversial) and hence
they are not in the MSR.  But, if one had a museum or academic
department with a specialty in those scripts or the languages
and cultures with which they are associated, subdomains with
those characters might make perfectly good sense (and the
"understand what you register" requirement is probably easily
met).
 

> I find the term "registry" in this document confusing, as it
> could refer to an "IANA registry", "script registry" or
> "domain registry". Perhaps always spell this out to make the
> context clearer?  Or alternatively, perhaps introduce the term
> Registry (with captial R)  and use that to refer to domain
> registries.

See above.

> [ID.draft-klensin-idna-unicode-review] is in progress.  Its
> status    should be checked in conjunction with application of
> the present    specification.
> 
> I think this is meant as informational to the RFC Editor ?
> Perhaps these documents should go out as a cluster?

Yes, it is informational to the RFC Editor.  And, yes, it is not
an accident that the two documents went out for Last Call at the
same time and are being evaluated concurrently.  My hope is to
see both to them in the RFC Editor's hands at the same time,
whether they are explicitly handled as a cluster or not.

> Note I find some documents are references within [square
> brackets] but not all of them, even some RFC's are in brackets
> and others are not. Please make this consistent.

I think you will find that all documents are cited (with the
square brackets) at least once.  After many discussions over the
years with the RFC Editor, subsequent mentions of the same
document are not handled as citations if that would make the
text awkward (in the opinion of the authors).  The RFC Editor
certainly has the right to dispute those choices during their
editing pass.  If you have identified references to documents
that do no appear in citations at all, please tell us about them
and they will be fixed.  If you are disputing the policy, take
it up with the RFC Editor.

On checking on your comment, I did catch one instance of a
reference in square bracket that was not properly set up as a
citation.  It is now fixed in the working version but, unless
the AD directs otherwise, I'm not going to repost for this
rather trivial problem that I'm confident the RFC Editor would
have caught.

>       The algorithm and rules of RFCs 5891 and 5892
> 
> missing xref's to the RFCs?

Nope.  Cited with xrefs in the same section, two paragraphs
earlier.  See above.

>      registries SHOULD normally consult
> 
> Either use "SHOULD" or "normally", not both? It's a little odd.

This document is a little odd in the sense that, in a more
perfect world, it should be completely unnecessary.  If there
were greater understanding of and consensus about the issues
associated with IDNs in the various communities that want to use
them and will encounter them, we would not be bothering with it
(much of that is explained above).   In particular, the IETF
usually avoids publishing documents that say "you MUST do X,
but, if you don't, then you SHOULD do Y or Z.  But that is
precisely the position this document is in with MUST language in
the base IDNA RFCs that a number of registries have chosen to
ignore for business or other reasons.   Given that, language
that is "a little odd" is probably predictable.    

>    to fully satisfy the mandate set out above
> 
> Instead of mandate, which is a bit generic and confusing, why
> not refer to the mentioned "IAB guidance", which I think it is
> referring to ?

Because it isn't referring to the IAB guidance or, more
specifically, is referring to parts of it and some other things.
Suggested better language would be welcome, again subject to the
request/ suggestion above.

 
>     may provide useful guidance.


> Remove the word "may"

"may" was intentional.   Those documents are completely
irrelevant if one of the script or language-specific RFCs are
considered.  Whether the MSR is relevant or not below the root
or in a zone for which ICANN does not have authority is
controversial.    If everyone agreed that it was relevant, this
document could be replaced by something much shorter that would
say "regardless of what IDNA allows, no characters or character
sequences are permitted unless they exclusively use one of the
scripts that ICANN has considered as part of the VIP/ LGR
process and by the MSR and other ICANN recommendations and rules
that derive from that process".  But, for a number of reasons
including those that are at least hinted at above, there is no
such agreement,