Skip to main content

Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels
draft-freytag-lager-variant-rules-06

Yes


No Objection

(Alia Atlas)
(Deborah Brungard)
(Suresh Krishnan)
(Terry Manderson)

Abstain


Note: This ballot was opened for revision 03 and is now closed.

Warren Kumari
Abstain
Comment (2017-05-22 for -05) Unknown
Having somewhat followed the variants discussions in the IETF and ICANN,  I have primarily learnt 2 things: 
1: variants are subtle, complex, controversial and deeply political; and 
2:  John Klensin, Vint, Patrik and Andrew know way more about them than me, have thought deeply about both the problem space, and the political / long term implications; their opinion in this space should be respected.

I have read the document, and, *as far as I understand it*, the technique / methodology in it seems reasonable and sane; however, the LC comments from John and Vint concern me, and I think that they really should be properly addressed - I'm hoping that there has been (possibly off-list) discussion regarding John's concerns? From my reading, the updates to the Introduction do not really address his issue.
 
The response to the IETF LC was primarily John's (and some support of his position). Unless my search foo failed, I have not found much discussion on prior versions - this makes me concerned that this will be used to justify that variants are safe without much review or consensus from those schooled in the art.

I do not feel technically qualified to be hold a DISCUSS on the document, and so I'm balloting ABSTAIN - *I* do not see support for advancing the document in the IETF, but understand that others may differ.
Alexey Melnikov Former IESG member
Yes
Yes (2017-06-05 for -05) Unknown
John's comment are partially based on misreading of the document. Various clarifications were done to the Introduction, so I believe this version addresses John's concerns.

I am open to suggestions about whether

1) IESG should re-open the LAGER WG to process this document. (I closed LAGER last year because its done all work and this document wasn't on my radar.)

 or 

2) Send this document to Nevil for processing in ISE.
Adam Roach Former IESG member
No Objection
No Objection (2017-06-05 for -05) Unknown
I know enough about Unicode, IDN, and ICANN politics to know that I *don't* know enough to usefully weigh in on John Klensin's suggestions to reconstitute LAGER or send this document through the ISE.

That said, this document appears to describe a system for defining and evaluating rules. I can see how the rules themselves might be problematic (this document does not define any such rules), but I can't see how describing the tools for creating and evaluating such rules would itself give rise to issues directly. If the notion here is that we don't want to give people a language on the premise that they might use that language to say problematic things, I don't think I agree. If the objections being raised are more subtle than that, then I'm afraid they're lost on me. I can't find ground to object.

Editorial comments:

This document seems to have the short version of the title ("Using Variants in Label Generation Rulesets"), which appears on every page, swapped with the long version of the title ("Variant Rules"), which appears on the front page (and typically in external citations).

The introduction says "Section Section 7" (with a duplicated "Section").
Alia Atlas Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2017-06-06 for -05) Unknown
I'm fine with this document advancing, but I think it would be better if folks who have commented on the document off-list would express their support for it on ietf@ietf (or another public list), assuming they do support its publication. The question of re-opening the LAGER working group seems like the wrong question to me; I think the real question is whether the document has undergone sufficient review and whether, among those who have reviewed it, IETF consensus to advance the document could be claimed. It sounds from the shepherd write-up as though a number of folks who were involved in the LAGER WG have reviewed the document, but if more review is needed then those reviews can be solicited without the need to re-open the WG. It's not as if the LAGER WG had a ton of participants when it was open anyway.

So, I would say that more review, or notes to a public list about reviews already conducted, would be advisable to make a stronger case for publishing this as an IETF consensus document.
Ben Campbell Former IESG member
No Objection
No Objection (2017-06-05 for -05) Unknown
I agree with Adam's top level comments. I also agree with Andrew's comments [1] and hope the authors adopt his suggested edits.

[1] https://mailarchive.ietf.org/arch/msg/ietf/po47ZJR1xWuxFx_h-8IRTvYBTwo/?qid=42e9c225ee22ddb75ab2a412b597afce

Some specific comments:

Substantive:

- Section 1: Is the term "applied for label" defined somewhere? I can infer the meaning from context, but it would be better to be explicit.

-3:
I'm confused by this section. Section 2 says that variant relationships are effectively symmetric and transitive, but then this section says some are not. Or more to the point, section 2 says that variant relationships are effectively equivilancies, and this section talks about relationships where that is not true. That seems like a contradiction. I note Andrew's comment that the sort of relationships contemplated in section 3 should be avoided, and the authors indication they would consider stronger language. Please count this as a vote in favor of that.

-7, "In   the former case we would like to allocate only the label OOO, but in   the latter case, we would like to also allow the allocation of either   the original label OOO ..."

I assume that is an "example" policy for the sake of discussion. As written, it could be taken as general guidance.

-11: The section starts out with " But what if we started from AOA", but then later says "O is the original scode point". Is the difference between "starting from" and "original" well defined somewhere?

Editorial:

General: I gather after quite a bit of reading that the authors intend the label placeholders herein have certain meanings, e.g. "O" for "original". At least, there are sections that seem to operate from that assumption. But I cannot find any text saying that explicitly. Along those lines, ar the mappings towards the end of section 7 intended to apply throughout the document? Again, some sections seem to assume that, but I don't see it stated explicitly.

-1, "It tacitly assumes that any LGR will be expressed using the   XML representation defined in [RFC7940] and therefore conform to any   requirements stated therein."
It's not tacit anymore once you say it :-)

"However, the reader is expected to   have some familiarity with the concepts described in that RFC (see   Section 4)."
Section 4 of that RFC, or of this document?

-9: Does this section assume the mappings from section 7? (See general editorial comment above.)
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-06-07 for -05) Unknown
I wouldn't be opposed to reopening LAGER to deal with the questions raised, per Alexey's comment.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-02-15 for -03) Unknown
- I found this in the shepherd write-up: "John Klensin's comments should be reviewed thoroughly since his conclusion is that the document should not be published in the IETF stream." Was this discussed? If there are actual concerns about the amount of review performed and limited attention to reach IETF consensus, maybe this document should go to the ISE instead?

- I think the title could be extended e.g. Guidance on designing Label Generation Rulesets (LGR) supporting variant lables
Suresh Krishnan Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -05) Unknown