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

[Ballot comment]
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.

[Ballot comment]
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.)

[Ballot comment]
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").

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-freytag-lager-variant-rules-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-freytag-lager-variant-rules@ietf.org, Scott Hollenbeck , shollenbeck@verisign.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Variant Rules) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:
- 'Variant Rules'
  as Informational RFC

Some comments were raised in IETF LC about how this document relates
to RFC 7940. The document was updated to clarify that.
This is a Second IETF LC to make IETF community aware of changes
to this draft.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Rules for validating identifier labels and alternate representations
  of those labels (variants) are known as "Label Generation Rulesets"
  (LGRs); they are used for the implementation of identifier systems
  such as Internationalized Domain Names (IDNs).  This document
  describes ways of designing Label Generation Rulesets (LGRs) that
  support variant labels.  In designing LGRs, it is important to ensure
  that the label generation rules are consistent and well-behaved in
  the presence of variants.  The design decisions can then be expressed
  using the XML representation of LGRs that is defined in RFC7940.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the charter of the group to do this work. No controversial issues were identified on the working group mailing list, but no support was expressed, either. There were no last call review comments received from anyone on the working group mailing list.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from knowledgeable IETF participants inlcuding Paul Hoffman, John Klensin (see text below regarding John's review) and Andrew Sullivan. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django); Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant technical issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version. The -04 version was published to address comments received from John Klensin. The -05 version was published after a discussion of the -04 version, and with this version the Document Shepherd believes the document should be subjected to another IETF last call due to the breadth of changes made in the -04 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I would have liked to have received comments from members of the working group mailing list, but participation in the working group faded over time and no last call comments were received. Similarly, feedback from implementers would have been very valuable, but none was received. I am concerned that the lack of feedback may be an indication of a lack of interest or consensus within the IETF community, and the lack of interest or consensus may make IETF stream publication questionable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time. John shared comments on 14 February. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document. The author updated the document to add content and published the -03 version to address feedback received up to that point.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

John Klensin's comments should be reviewed thoroughly since his conclusion at the time was that the document should not be published in the IETF stream. I have no other specific concerns or issues that have not been described elsewhere in this write-up.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document. There has been no feedback from the community of implementers, but there are multiple implementations. There has been no expression of support or concern on the LAGER working group mailing list, so there is no available measurement of consensus within the IETF community.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

John Klensin's review raised issues that the author attempted to address in updates to the document. The areas of conflict have been discussed among the concerned parties via email and in person. John suggested that the revisions to the -03 version were likely to be substantial enough to warrant another last call; I concur, (a second last call was started on 17 April). John also indicated that he may appeal any decision to publish this document in the IETF Stream if it appears to modify or extend RFC 7940, a standards-track specification.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in an early version of the document that was first submitted to the IESG. Both have been corrected and no ID nits exist in the current version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the charter of the group to do this work. No controversial issues were identified, but no support was expressed, either. There were no review comments received from anyone on the working group mailing list.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from three knowledgeable IETF participants, Paul Hoffman, John Klensin (see text below regarding John's review) and Andrew Sullivan. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant technical issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I would have liked to have received comments from members of the working group mailing list, but participation in the working group faded over time and no last call comments were received. Similarly, feedback from implementers would have been very valuable, but none was received. I am concerned that the lack of feedback may be an indication of a lack of interest or consensus within the IETF community, and the lack of interest or consensus may make IETF stream publication questionable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time. John shared comments on 14 February. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document. The author updated the document to add content and published the -03 version to address feedback received up to that point.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

John Klensin's comments should be reviewed thoroughly since his conclusion is that the document should not be published in the IETF stream. I have no other specific concerns or issues that have not been described elsewhere in this write-up.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document. There has been no feedback from the community of implementers, but there are multiple implementations. There has been no expression of support or concern on the LAGER working group mailing list, so there is no available measurement of consensus within the IETF community.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

John Klensin's review raised issues that the author will attempt to address in an update to the document. The areas of conflict have been discussed among the concerned parties via email. John suggested that the revisions were likely to be substantial enough to warrant another last call; I concur. He also indicated that he may appeal any decision to publish this document in the IETF Stream if it appears to modify or extend RFC 7940, a standards-track specification.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist in the current version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the charter of the group to do this work. No controversial issues were identified, but no support was expressed, either. There were no review comments received from anyone on the working group mailing list.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from three knowledgeable IETF participants, Paul Hoffman, John Klensin (see text below regarding John's review) and Andrew Sullivan. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant technical issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I would have liked to have received comments from members of the working group mailing list, but participation in the working group faded over time and no last call comments were received. Similarly, feedback from implementers would have been very valuable, but none was received. I am concerned that the lack of feedback may be an indication of a lack of interest or consensus within the IETF community, and the lack of interest or consensus may make IETF stream publication questionable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time. John shared comments on 14 February. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document. The author updated the document to add content and published the -03 version to address feedback received up to that point.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

John Klensin's comments should be reviewed thoroughly since his conclusion is that the document should not be published in the IETF stream. I have no other specific concerns or issues that have not been described elsewhere in this write-up.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document. There has been no feedback from the community of implementers, but there are multiple implementations. There has been no expression of support or concern on the LAGER working group mailing list, so there is no available measurement of consensus within the IETF community.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

John Klensin's review raised issues that the author will attempt to address in an update to the document. The areas of conflict have been discussed among the concerned parties via email. John suggested that the revisions were likely to be substantial enough to warrant another last call; I concur. He also indicated that he may appeal any decision to publish this document in the IETF Stream.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist in the current version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

[Ballot comment]
- 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

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the charter of the group to do this work. No controversial issues were identified, but no support was expressed, either. There were no review comments received from anyone on the working group mailing list.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from three knowledgeable IETF participants, Paul Hoffman, John Klensin (see text below regarding John's review) and Andrew Sullivan. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant technical issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I would have liked to have received comments from members of the working group mailing list, but participation in the working group faded over time and no last call comments were received. Similarly, feedback from implementers would have been very valuable, but none was received. I am concerned that the lack of feedback may be an indication of a lack of interest or consensus within the IETF community, and the lack of interest or consensus may make IETF stream publication questionable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time. John shared comments on 14 February. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document. The author updated the document to add content and published the -03 version to address feedback received up to that point.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

John Klensin's comments should be reviewed thoroughly since his conclusion is that the document should not be published in the IETF stream. I have no other specific concerns or issues that have not been described elsewhere in this write-up.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document. There has been no feedback from the community of implementers, but there are multiple implementations.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist in the current version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified. There were also no review comments received from anyone on the working group mailing list.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants, John Klensin and Andrew Sullivan. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I would have liked to have received comments from members of the working group mailing list, but participation in the working group faded over time. Feedback from implementers would have been very valuable, but none was received.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time. John shared comments on 14 February. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document. The author updated the document to add content and published the -03 version to address feedback received up to that point.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

John Klensin's comments should be reviewed thoroughly. I have no other specific concerns or issues that have not been described elsewhere in this write-up.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document. There has been no feedback from the community of implementers, but there are multiple implementations.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist in the current version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

https://www.icann.org/resources/pages/second-level-lgr-2015-06-21-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Assuming that all of the requested reviewers respond, no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time; feedback received from the others will be shared here when available. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Assuming that all of the requested reviewers respond, no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Paul declined due to a lack of available time; feedback received from the others will be shared here when available. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant issues were found, but a need to add introductory context was identified. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Assuming that all of the requested reviewers respond, no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan, John Klensin, and Paul Hoffman. Their feedback will be shared here when available. Suzanne Woolf volunteered to review the document from a DNS perspective after she read my review. Suzanne's review echoed a comment of my own describing the need to add context to the beginning of the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-freytag-lager-variant-rules-02.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review of the -03 version was completed on 24 January 2017 and results were sent to the IETF mailing list, the document author, and the area director. No significant issues were found. An early review of the -02 version identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed and incorporated in the -03 version.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, the type of RFC is indicated in the page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review is in progress. An early review identified a need to address minor ID nits and to add text to the security considerations section; those tasks were completed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no identified controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two ID nits were identified in the version of the document that was submitted to the IESG. Both have been corrected and no ID nits exist.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, in page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

DNS root and top-level domain LGRs are published and available:

https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR+Project

https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review is in progress. I believe that the security considerations section needs some text. Given that the abstract talks about "well behaved" labels, you should think about the risks associated with labels that aren't well behaved. Are there any security issues that present themselves through the use of this technology? Can it be used, misused, or abused to create security issues?

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two nits have been identified. They have been shared with the author for correction.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not status change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, in page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts:

https://www.icann.org/public-comments/lgr-second-level-2016-06-07-en

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review is in progress. I believe that the security considerations section needs some text. Given that the abstract talks about "well behaved" labels, you should think about the risks associated with labels that aren't well behaved. Are there any security issues that present themselves through the use of this technology? Can it be used, misused, or abused to create security issues?

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two nits have been identified. They have been shared with the author for correction.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not status change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, in page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

The XML Schema specified in RFC 7940 has been used to create 28 published reference LGRs for the second level developed by Sheypa under ICANN contract, and about a dozen communities are preparing or have published proposed Root Zone LGRs for their scripts.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review is in progress. I believe that the security considerations section needs some text. Given that the abstract talks about "well behaved" labels, you should think about the risks associated with labels that aren't well behaved. Are there any security issues that present themselves through the use of this technology? Can it be used, misused, or abused to create security issues?

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Two nits have been identified. They have been shared with the author for correction.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not status change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, in page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it. The document shepherd is Scott Hollenbeck. The responsible Area Director is Alexey Melnikov. No expert reviews are required, but the shepherd did solicit reviews from two knowledgeable IETF participants. Marc Blanchet identified the following implementations: Viagenie developed a front-end interface under ICANN contract that is now open-sourced (see https://github.com/icann/lgr-core, https://github.com/icann/lgr-django; Asmus Freytag as part of ICANN Integration Panel work (not released as far as we know); Wil Tan as part of ICANN Integration Panel work (not released as far as we know).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A detailed review is in progress. I believe that the security considerations section needs some text. Given that the abstract talks about "well behaved" labels, you should think about the risks associated with labels that aren't well behaved. Are there any security issues that present themselves through the use of this technology? Can it be used, misused, or abused to create security issues?

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The shepherd solicited reviews from Andrew Sullivan and John Klensin. Their feedback will be shared here when available.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues that have not been described elsewhere in this writeup.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes, and the author states that there is no IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No IPR disclosure is required.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no controversy or discontent with these recommendations. There is no known risk of appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits have been identified.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no content in the document that requires formal review by designated experts.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not status change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language specifications in the document, but there are examples given using the syntax specified in RFC 7940.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Informational; yes, in page header. If published, this RFC will provide guidance to implementers of RFC 7940.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Abstract

This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels.  Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels.  Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved.  While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

This document was developed after the LAGER working group completed its work and was closed. Notice of the work was sent to the working group mailing list, but there was no interest in extending the work of the group to do this work. No controversial issues were identified.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director?

The document largely reflects experience gathered from implementing RFC 7940 and creating rulesets based on it.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

N/A?

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

No IPR to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Earlier versions of this document have been published in the context of projects defining label generation rulesets for the root zone and references label generation rulesets for the second level and its contents reflect the experience gained from these multi-stakeholder projects. The projects follow the recommendations laid out here.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There has been no controversy or discontent with these recommendations.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

The document does not status change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

TBD

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, draft-freytag-lager-variant-rules@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Variant Rules) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Variant Rules'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document gives guidance on designing well-behaved Label
  Generation Rulesets (LGRs) that support variant labels.  Typical
  examples of labels and LGRs are IDNs and zone registration policies
  defining permissible IDN labels.  Variant labels are labels that are
  either visually or semantically indistinguishable from an applied for
  label and are typically delegated together with the applied-for
  label, or permanently reserved.  While [RFC7940] defines the
  syntactical requirements for specifying the label generation rules
  for variant labels, additional considerations apply that ensure that
  the label generation rules are consistent and well-behaved in the
  presence of variants.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ballot/


No IPR declarations have been submitted directly on this I-D.