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:
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.
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.
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:
DNS root and top-level domain LGRs are published and available:
(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?
(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?
(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.
(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.