(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?
The working group request is to publish this document as a Proposed
Standard RFC, and the title page header notes that the intended status is
"Standards Track". This is the proper type of RFC because this document
describes the format, contents, and semantics of Domain Name Registration
Data (DNRD) escrow deposits for a domain name registry and
interoperability is required between producers and consumers of these
escrow deposits.
(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
This document specifies the format, contents and semantics of Domain Name
Registration Data (DNRD) escrow deposits for a domain name registry.
These escrow deposists are intended to provide a source of backup data to
reconstitute a domain name registry in the unlikely situation of
unrecoverable data loss.
Working Group Summary
This document was first published as an individual submission
Internet-Draft in March, 2012. It was adopted by the REGEXT working group
in June, 2019. A working group last call was started on 20 September,
2019. Multiple people expressed support for progression of the document.
The authors of the document found interoperability issues during the
working group last call and had to produce a new version. The authors
thought that the changes were not substantive, but there were enough of
them to warrant a second working group last call. That last call was
initiated on 26 October and ended on 8 November. This second last call
was extended to 22 November due to a lack of last call feedback. The
second last call was completed successfully with multiple expressions of
support and no expressions of concern.
Document Quality
The data format specifications contained in this document have been
implemented in support of more than 1,200 generic Top-Level Domains. In
addition, domain registry service provider transitions using data files
that conform to this specification have been completed.
Personnel
The Document Shepherd is Scott Hollenbeck. The Responsible Area Director
is Barry Leiba.
(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.
I read the document in detail and provided my review to the working group
on 2 December 2019:
https://mailarchive.ietf.org/arch/msg/regext/TjRlL9OygsrZ_BXjnJDs7UeHRJk
All of my review feedback has been addressed as of January 10, 2020.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. The document was first written in March 2012 and it has been
implemented by a large number of domain registry operators who produce
escrow deposits for ICANN. The document completed a working group last
call on 4 October 2019. Eight individuals expressed support for
publication of the document and no dissent was recorded. This last call
identified an interoperability issue and a number of editorial issues, so
a new version of the document was produced and a second working group
last call was started on 26 October 2019. There were no expressions of
concern raised during the working group last call process.
(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 AD is asking for further review from the Internationalization
Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
UTF-16. The working group cites RFC 5730, Section 5, and aligns with that.
The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
well over 10 years old. Other opinions will be useful.
(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 WG 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 with this document.
(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, each author has provided their confirmation:
Gustavo Lozano:
https://mailarchive.ietf.org/arch/msg/regext/Exp1DCFY4ThYg3hLTS5qSVbaOeo
James Gould:
https://mailarchive.ietf.org/arch/msg/regext/5Uaic4BNlra03VtoKKb2evAvt-g
Chethan Thippeswamy:
https://mailarchive.ietf.org/arch/msg/regext/FQ_r1SOY1wxFP-dNTknYPPM9fx0
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
I could not find any IPR disclosures on the IETF IPR disclosure page
(https://datatracker.ietf.org/ipr/). Given that there are no known
disclosures, there has been no discussion of IPR disclosures.
(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?
Multiple people expressed support for the document, but it's more of a
"concurrence of a few individuals" situation (primarily those associated
with ICANN's generic Top-Level Domain program) than the WG as a whole.
(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.)
No one has threatened an appeal or expressed extreme discontent.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The idnits tool notes normative references to non-RFC documents. These
are to ISO and ITU documents for which a normative reference is
appropriate.
(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
The document requests IANA registration of an XML namespace and an XML
schema. These are subject to expert review.
(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?
There are no normative references to documents that are not ready for
advancement or are otherwise in an unclear state.
(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.
The document includes normative references to an ISO specification (ISO
Standard 3166) and an ITU specification (ITU-T Recommendation E.164). The
document also includes a normative reference to BCP 14. All other
normative references are to Standards Track documents.
(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 WG
considers it unnecessary.
No, this 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 8126).
The document requests IANA registration of an XML namespace and an XML
schema. These are subject to expert review. I've reviewed the
registration requests and suggested a modification:
"The IANA Considerations section requests registration of multiple XML
namespaces and XML schemas. For example,
urn:ietf:params:xml:ns:rdeCsv-1.0 and
urn:ietf:params:xml:schema:rdeCsv-1.0. Recent convention has been to
include “epp” in the URIs for EPP-associated namespaces and schemas, e.g.
urn:ietf:params:xml:ns:epp:<identifier>. That convention should be
followed here, making the requested values
urn:ietf:params:xml:ns:epp:rdeCsv-1.0 and
urn:ietf:params:xml:schema:epp:rdeCsv-1.0."
The authors have declined to make this change due to the large number of
deployed, operational implementations.
(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.
This document does not create any new IANA registries.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
I worked with one of the authors to perform automated checks of the
examples and schema specifications. The result of those checks was posted
to the working group mailing list on 10 December 2019:
https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s
All of the needed updates have been completed.