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