Re: Last Call: <draft-freytag-lager-variant-rules-02.txt> (Variant Rules) to Informational RFC

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

--On Tuesday, January 17, 2017 09:23 -0800 The IESG
<[e-mail]> 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 [e-mail] mailing lists by
> 2017-02-14. Exceptionally, comments may be sent to
> [e-mail] 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