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 1 November 2019.
(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? Proposed
Standard - this document requests that the status of 'ipv4only.arpa" be
recorded in the Special-Use Domain Names registry as a name with special
properties.
(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
The specification for how a client discovers its local network's
NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for
this purpose, but in its Domain Name Reservation Considerations
section that specification indicates that the name actually has no
particularly special properties would require special handling, and
does not request IANA to record the name in the Special-Use Domain
Names registry.
Consequently, despite the well articulated special purpose of the
name, 'ipv4only.arpa' was not recorded in the Special-Use Domain
Names registry as a name with special properties.
This document describes the special treatment required, formally
declares the special properties of the name, and adds similar
declarations for the corresponding reverse mapping names.
Working Group Summary
This document is AD sponsored - it was considered for adoption in the DNSOP WG.
While there was no major controversy or objections, the WG didn't declined to
adopt it. Warren Kumari (as Ops AD) agreed to AD sponsor it, informed the DNSOP
WG / BEHAVE lists, and asked for feedback.
Document Quality
The document is clear and understandable - it corrects an oversight /
omission, and provides guidance to implementers. It also corrects / records
the status in an IANA registry.
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. The Document Shepherd / AD has reviewed the document and
discussed it with the DNSOP WG. The authors have incorporated feedback and I
believe it is now ready.
(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? No.
(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?
None.
(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.
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any discussion and conclusion regarding the IPR disclosures. No.
(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?
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
Nope.
(11) Identify any ID nits the Document Shepherd has found in this document.
Nits are to be expected - they are things like non-RFC6890-compliant example
addresses, date in the past, etc.
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A.
(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? Nope.
(15) Are there downward normative references references (see RFC 3967)?
Nope.
(16) Will publication of this document change the status of any existing RFCs?
The document updates RFC7050 by clarifying things, and also adding the name to
the SUDN registry.
(17) Describe the Document Shepherd's review of the IANA considerations section.
The document is largely a wrapper / justification for the IANA - it was
discussed with the IANA many moons ago...
(18) List any new IANA registries that require Expert Review for future
allocations. None.
(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, YANG modules, etc. Not applicable.
(20) If the document contains a YANG module...
None.