--On Tuesday, January 17, 2017 09:23 -0800 The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from an individual submitter > to consider the following document: > - 'Variant Rules' > <draft-freytag-lager-variant-rules-02.txt> as Informational > RFC > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@xxxxxxxx mailing lists by > 2017-02-14. Exceptionally, comments may be sent to > iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Summary: This document should not be published in the IETF Stream, at least in its present form, proposed status, and relationship to other documents. An explanation and some alternatives appear below. Details: This is a difficult document for me to review for multiple reasons, including a conviction that the intentions are the very best but that the document is artificially constrained by essentially political decisions taken outside the IETF or any other process that would meet traditional IETF criteria for openness, transparency, fairness, and rough consensus. For IETF decision-making, a largely procedural issue is as, or perhaps more, important. The document bears a relationship to the standards-track RFC 7940 that is confusing at best. The "Document Quality" section of the proposed approval notice starts "The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it". That is a worthy goal and entirely consistent with the "rough consensus and running code" principle. The author has done what I believe is a laudable job of coming up with a semi-mathematical and testable alternative to the rather lengthy, complex, and less easily validated and texted, XML of RFC 7940. If the document were submitted to the ISE as a "I think this would be a better way to do things while meeting the same goals as RFC 7940" or even as "this is what ICANN is doing (or proposes to do) and the community should know about it" piece, I'd have little or no objection to it. However, as an IETF stream document that apparently is intended to replace (or at least provide an alternative to) large sections of 7940 with a different strategy, either -- it should be a standards-track document that explicitly updates and replaces those portions of 7940, with all of the documentation and explanation the IESG requires of such updates. OR -- it should be a standards-track document that provides an alternative to 7940 and that explains the choices and tradeoffs. As an IETF Stream Informational specification, it is an apparent IETF Informational document that encourages the practice of something other than an IETF Proposed Standard that addresses the same topics and requirements, with no Applicability Statement or other guidance as to when or if it should be applied. I do not believe it should be published on that basis. Without descending into details and nitpicking, there are also a pair of technical problems. (1) As RFC 7940 points out, the concept of "variant" and hence the relationships needed to express the "increased requirements of contemporary IDN variant policies" [RFC7940, Section 9] has moved considerably beyond the definition of that term and concept in RFC 3743 (aka "the JET specification"). This document further refines the description of those relationships. However, if one is going to move beyond the JET concept -- one tailored to the relationship between Simplified and Traditional Chinese characters and not about, e.g., visual confusion at all -- it is not clear that there is a technical basis for saying "these things are variants and those others are not". The "others" can include synonyms, translations, orthographic variations that cannot be expressed in simple character (or even character sequence) mappings, and so on. ICANN made a serious of decisions (IMO, some of them almost by accident and others by side-effect or more political reasons) as to what kinds of relationships might be considered variant candidates, at least for the root zone. The grammar proposed in this document (and the one of 7940) exclude those other, non-ICANN-sanctioned, relationships and cannot, in general, represent them in spite of the fact that they might be quite appropriate (as least for blocking) in non-root zones and have been used in exactly that way (indeed, two of the key areas of friction between IDNA2008 and Unicode UTS #46 can be seen in exactly those terms). To a certain extent, that is a criticism of 7940 rather than this document, but there is an important difference, at least IMO: The grammar of 7940 is essentially descriptive and, like most good XML structures, could easily be expanded with additional elements or element components if the need arose. It is far less clear how one would expand a quasi-mathematical grammar, especially one that is heavily dependent on special operator symbos and strict typologies, like this one. Even if one were to figure out how to expand this as requirements evolve outside ICANN's control, such extensions would raise questions of how to keep this document and 7940 synchronized. That issue might be another reason for standards track status and either a more explicit discussion of relationships and mapping; one or more IANA registries or operators, types, and elements; or both. (2) Independent of the web and the convenience of HTTP redirect facilities, it is not only not clear how to implement delegated variants in a way taht is not damaging to the Internet and the DNS. The opportunities for combinatorial explosion and consequent operational and zone management problems in all but a few very special cases (including, historically, the one that at least some of the JET designers had in mind) are considerable. The ICANN solution of "just delegate them all to the same party and make it their problem" may be satisfactory from their corporate point of view, but is not a way to make the Internet work better, especially in the context of potentially hundreds of names that have to be kept synchronized in a way that leads to consistent behavior across all protocols. RFC 7940 exposes some of this problem as well, but, again, is rather more descriptive than this document, which moves much closer to a set of executable tests that establish what is valid (and presumably reasonable) and what is not. I, and a few others, have suggested in other contexts that "variant" has become part of a magical ritual in which one looks at a complex DNS-related problem, solemnly chants the word a propitious number of times, and the problem is then assumed to disappear or be solved. The issues above are only a few of the cases to which variations on that ritual have been applied. Unless the IETF has better solutions than magic, it should not be legitimizing the magical thinking by publishing documents that appear to encourage delegation of "variants". Two additional nits, the first an important procedural one and both to provide illustrative examples that this document would need work even if none of the considerations above applied. (i) At least since RFC 3552, we have not allowed documents in the IETF stream that say "There are no security considerations for this memo.". And yet that is exactly what Section 18 has to say. (ii) Section 16 ("Corresponding XML Notation") is a good idea, but, rather than providing a comprehensive mapping, it essentially says "here are some examples of the mapping between notations; everything else is left as an exercise for the reader". I think that is confusing and unfortunate but, if it really is what the IETF and the author want to do, it should be made much more explicit. thanks, John Klensin