Shepherd writeup
draft-cheshire-sudn-ipv4only-dot-arpa-17

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. 



Back