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,
- Re: [I18ndir] Secdir last call review of draft-kl… John C Klensin
- Re: [I18ndir] Secdir last call review of draft-kl… Paul Wouters
- Re: [I18ndir] Secdir last call review of draft-kl… Barry Leiba
- Re: [I18ndir] Secdir last call review of draft-kl… Paul Wouters