Subject: draft-freytag-lager-variant-rules-05

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 May 2017 15:26:29 -0400

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
[email-masked]

---

From: Asmus Freytag <[email-masked]>
Date: Mon, 1 May 2017 13:02:19 -0700

On 5/1/2017 12:26 PM, Andrew Sullivan wrote:
> whether such a thing is a good idea or is not.
Correct, most of the encouragement (i.e. "this is a good idea to have 
such a
document") has been received off-line from people otherwise on this list 
and
hence is not been 'visible'.
>   It seems to me that it
> need such a policy.
And in particular as a new ID propose to help reinforce that responsibility.
>   Since I'm one of the people who, as much as

Variants come in two flavors that have very different implications. Many 
people
think of *allocatable* variants first. These are problematic in many 
ways and
are in a way visible to the users of the DNS. There are a limited 
constellation
of linguistic conditions where they represent an appropriate choice.

In contrast, *blocked* variants make certain labels mutually exclusive. 
This
directly affects applicants (and registries) in that some particular 
label may
no longer be available. Ordinary users are not affected, other than perhaps
positively by not having to deal with two labels that display 
identically, etc.

The motivation for these two types of variants is rather different. The 
way I
would put it: since we have the variant mechanism, and since we have, with
RFC 7940 for the first time a universal way to specify them, that is not
implicitly to a given geographic region, we might as well consider the 
benefits
(particularly of *blocked* variants) to increase robustness of the DNS,
even for regions where *allocatable* variants are not a relevant issue.

But to do that, we need to know the distinction between these two types
and the implications of ways to specify variant relations. That is what this
document tries to convey.
>     to a wider range of internationalized identifiers.
I don't have any objection to making a change like that.
> useful.  Section 3 could say that more bluntly, I think.

I was asked the same question recently "is it allowed to have 
non-symmetric or non-
transitive" variant definitions. My best answer, essentially came out as 
"while such
things can be specified, symmetric and transitive definitions have such 
advantages
it's simply common sense to require them."

And the advantages that I was thinking of had to do with optimized 
evaluation of
these LGRs, but making policies "useful and comprehensible policies in a 
distributed
system like the Internet," is an important issue as well.

So, I'd concur and would be happy to tweak the language to be more "blunt".
>     doubtless reduce the number of labels practically available.
I would have no objection to changing the language in this way.
> I hope these remarks are helpful to the IESG and the document author.
I certainly found them very helpful,

Thanks,
A./