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 ajs@xxxxxxxxxxxxxxxxxx