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

[Asmus Freytag <[e-mail]>]

On 5/1/2017 12:26 PM, Andrew Sullivan wrote:
> 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.
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
> 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.
And in particular as a new ID propose to help reinforce that responsibility.
>   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.

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.
>
> 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.
I don't have any objection to making a change like that.
>
> 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.

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".
>
> 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 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./
>
> Best regards,
>
> A
>