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-enhttps://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+Projecthttps://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-enhttps://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.