draft-freytag-lager-variant-rules-05

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I have read draft-freytag-lager-variant-rules-05, which is in IETF LC.
I have a few comments.

I understand the purpose of this document to be, essentially, a good
practices document for designing variants, with a particular focus on
LGRs appropriate to domain names using IDNA.  I think it is a good
idea to have such a document, and the discussion this document has
received has not, as nearly as I can tell, been terribly clear about
whether such a thing is a good idea or is not.  It seems to me that it
is a good thing to offer advice to people in how to design their
policies, given that (e.g.) RFC 5890 and friends says that they do
need such a policy.  Since I'm one of the people who, as much as
anyone else, has failed to do his share of lifting on i18n the last
few years, I am acutely aware of the gap this document proposes to
fill.  Whether variants were a good idea in the first place is sort of
irrelevant: the fact is that we have them, and they seem unlikely to
go away as we attempt to internationalize protocols that were never
designed to adapt to normal natural language ways of thinking about
identification.

Therefore, overall I think this is a good document and that it should
be published as an RFC.  I think some of the prose is occasionally a
little hard to follow, but I also think that difficulty comes partly
from wrestling with precision.  I believe the precision is important
in this case, and I can't really come up with a way of making the text
better without affecting that precision.

At the same time, I wonder whether the document is setting itself too
great a task at the beginning, in expanding its applicability to any
internationalized identifier.  Indentifiers that are not label-based
are not obvious candidates for use with this approach.  Identifiers
that carry linguistic semantics may well not need this approach
either.  And after reading the document I'm not even sure that this
document really is applicable even to domain names that are not in the
DNS (in case we think we can distinguish between "domain names" and
"DNS-only domain names") or are not using IDNA.  I don't feel super
strongly about this, but maybe the Intro could say this instead:

OLD

   Label Generation Rulesets (LGRs) that define the set of permissible
   labels, may be applied to a variety of identifier systems, although
   to date, the most common use is to define policies for implementing
   Internationalized Domain Names (IDNs) for some zone of the Domain
   Name System (DNS).  Without restricting any of the more general
   applications of this document, the explanations and examples in this
   document may be stated in terms of IDNs.

NEW

   Label Generation Rulesets (LGRs) that define the set of
   permsissible labels may be applied to identifier systems that rely
   on labels, such as the Domain Name System (DNS, [RFC 1034] [RFC
   1035]).  To date, LGRs have mostly been used to define policies for
   implementing Internationalized Domain Names (IDNs) using IDNA2008
   [RFC 5890] [other ref's here] in the DNS.  This document aims to
   discuss the generation of LGRs for such circumstances, but the
   techniques and considerations here are almost certainly applicable
   to a wider range of internationalized identifiers.

Given the "good practices" thrust I think is here, section 3 seems to
go out of its way not to say, "Don't do that."  If the point of an LGR
is partly to make useful and comprehensible policies in a distributed
system like the Internet, then having a variant system where A~B and
B~C but !(C~A) is probably not that helpful.  So, while it is
_possible_ to have LGRs that do not exhibit transitivity or symmetry,
such uses had better be pretty well-contained if they are to be
useful.  Section 3 could say that more bluntly, I think.

In my opinion, section 14 is a clear example of why the idea of
"multiple LGRs" is harmful.  Given that people have come to believe in
them, this section needs to stay and it is probably fine.  But it sure
makes the whole system harder to follow.  As a consequence, the advice
at the end of §16 seems too weak:

OLD

   In summary, conditional contexts can be an essential tool, but some
   additional care must be taken to ensure that an LGR containing
   conditional contexts is well behaved.

I'd suggest instead

NEW

   In summary, conditional contexts can be useful for some cases, but
   additional care must be taken to ensure that an LGR containing
   conditional contexts is well behaved.  LGR designers would be well
   advised to avoid using conditional contexts and to prefer
   unconditional rules whenever practical, even though it will
   doubtless reduce the number of labels practically available.
 
I hope these remarks are helpful to the IESG and the document author.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]