Special Use Domain Name 'ipv4only.arpa'
draft-cheshire-sudn-ipv4only-dot-arpa-17

[Ballot comment]
Thanks for the updates in the -17, addressing much more than just my Discuss point!

In Section 3.1, the sentence we now start with "Both for privacy reasons, and also because"
now has a grammar nit, since the "so" in the second clause is now superfluous.

[Ballot comment]
Thank you for the work put into this document. With the heavy load on this week telechat and all meetings related to the cancellation of the IETF-107 in-person meeting, I must admit that this review was not as thorough as I would hope :-(

Please find below some non-blocking COMMENTs and NITs.

Regards,

-éric

== COMMENTS ==
I agree with Barry's comment on the repetitions, and a rather verbose wording.

-- Section 3.1 --
For my own curiosity, is there an impact by application having their own "hardcoded" DNS recursive servers?

== NITS ==

-- Abstract and section 1 --
For non English-native speaker, I would suggest to add a "that" in "has no particularly special properties *that* would require special handling"

[Ballot comment]
** I appreciate that “.arpa” is “different” and that the behavior described in this draft is needed to make “things work”.  However, I’m a concerned about requiring hard-coded behavior contrary to the intent (understanding?) of the user especially due to the discussion in Section 3.1 of why users/configurations are overriding the network’s preference.  The text currently says:

Section 4.  Specifically: When querying for the name 'ipv4only.arpa', name resolution APIs and libraries should use the recursive resolver recommended by the network for the interface in question, rather than a recursive resolver configured manually,

Section 7.1.  Step 3.  Learning a network's NAT64 prefix is by its nature an interface-specific operation, and the special DNS query used to learn this interface-specific NAT64 prefix MUST be sent to the DNS recursive resolver address(es) the client learned via the configuration machinery for that specific client interface. 

Put in another way, this guidance could be read as “even though the user might have explicitly configured a given setting (a particular DNS server) on an interface, ignore that, and use untrusted input off the network.”.  Clearly this is a special case.  Nevertheless, IMO, this needs some explicit mention to belabor the obvious in the Security Considerations (on the order of something like):

-- Regardless of the user configured DNS setting, in this single case of resolving ipv4only.arpa, this setting will be ignored, in favor of the network provided configuration. This is acceptable because … <.arpa is special, etc.>

--  The network provided DNS server MUST NOT be used for anything other than ipv4only.arpa if the user has set another DNS server.

** Section 3.1. Per “However, it is becoming increasingly common for users to manually    override their default DNS configuration”, no disagreement on the phenomenon, but it is likely necessary to scope this to circumstances involving unmanaged endpoint outside of management enterprises.

** Section 3.1. Per the “corporate VPN client software” scenario where the VPN overrides the local network’s default configuration, this is also done outside of the corporate environment (e.g., on consumer-grade mobile device VPN services) to enhance privacy.

** Editorial
-- Abstract and Section 1.  Editorial.  Missing word.

OLD
“… but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties would require …”

NEW
“… but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties the would require …”

-- Section 2.  It was jarring for me to read that we expect that clients should “already know” something because an RFC exists.  I would have used softer language, perhaps like “conformant clients” and couched things as “expected behavior”.

-- Section 4.  Per “… so that software can legitimately implement the correct behavior necessary …”, using “legitimately” reads as judgement.  The underlying spec didn’t mark ‘ipv4only.arpa’ as special after all (which is the whole point of this document).

[Ballot discuss]
Thanks for producing this document, which fills a real need and is quite
well-written, my comment about its length notwithstanding.  Unfortunately,
I do have one pretty small point that I think requires a little bit more discussion,
to ensure that we produce a specification that is usable as written.

Section 7.1 imposes a requirement that "[i]terative resolvers [...] MUST
be configured to behave for these names either: (a) [...], or (b)
[...]".  There is no default choice given in the absence of
configuration, and it is unclear who this requirement is binding on in
any case.  Do all iterative resolvers necessarily have a human operator
that knows they are responsible for the configuration of the resolver?
Is the software author responsible for providing "default configuration"
to meet this requirement?  Let's discuss how this requirement is
intended to apply and whether that is achievable in practice.  (One of
the elided portions from the above quote is "commplying with this
specification", so perhaps the iterative recursive resolver softwares in
question would be implemented to ignore this specification in the
absence of such a configuration, as strange as that might seem.)

[Ballot comment]
This document is a lot longer than I expected from the Abstract!
(Specifically, I agree with Barry that it's repetitious in places, and
that I won't make more of a fuss about it.)

I suppose that if there is ever need for a "DS2" record this document
would need updating to allow that to be passed through as another
exception to what the DNS64 recursive resolver generates locally, but
that seems acceptable.

Abstract, Introduction

  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.

nit: "that would"

Section 3.1

  However, it is becoming increasingly common for users to manually
  override their default DNS configuration because they wish to use
  some other public recursive resolver on the Internet, which may offer
  better speed, better reliability, or better privacy than the local
  network's default recursive resolver.  At the time of writing,

[side note: this writing style implies that the list is exhaustive.  I
can't say for sure whether or not it is correct to do so :) ]

Section 3.2

[soapbox: it's hard for me to endorse referring to milliseconds as
"precious"]

Section 4

  on a particular physical or virtual interface.  Specifically: When
  querying for the name 'ipv4only.arpa', name resolution APIs and
  libraries should use the recursive resolver recommended by the
  network for the interface in question, rather than a recursive
  resolver configured manually, a recursive resolver configured by VPN
  software, or a full-service recursive resolver running on the local
  host.

Is there required to be a recursive resolver recommended by the network?
What should the behavior be in the absence of one?

  that they can avoid issuing unnecessary queries.  Network operators
  who wish to provide reliable, high performance service to their
  customers are strongly motivated to prefer DNS64 gateways that
  recognize the special 'ipv4only.arpa' name and apply the appropriate
  optimizations.

"strongly" feels ... well, perhaps a bit strong. :)

Section 5

Do we want to give a reference or details on how the "insecure
delegation" works?  ("No" is a fine answer, as it ought not be hard to
find...)

  One of the known concerns with DNS64 is that it conflicts with
  DNSSEC.  If DNSSEC is used to assert cryptographically that a name
  has no IPv6 AAAA records, then this interferes with using DNS64
  address synthesis to assert that those nonexistent IPv6 AAAA records
  do exist.

There is perhaps some philosophical debate about the scope to which
DNSSEC applies: even for the expected case here of the global ICANN DNS
root, we could of course assert that there are no such AAAA records in
that hierarchy, but with this name being registered as a SUDN it
properly lies outside the DNS root and thus outside that root of DNSSEC
authority.  In some sense, there is by definition no DNSSEC key material
that is authorized to make assertions about this name at all!  I don't
have a particular text suggestion here, though one might contemplate
"assert cryptographically [...] in the ICANN DNS root" and "do exist, in
the absence of knowledge that this name has special usage" or variations
thereof.

  The path from the authoritative server to the DNS64 recursive
  resolver (queries for IPv4 address records) need not be protected by
  DNSSEC, because the DNS64 recursive resolver already knows, by
  specification, what the answers are.  In principle, if this were a
  secure delegation, and 'ipv4only.arpa' were a signed zone, then the
  path from the authoritative server to the DNS64 recursive resolver
  would still work, but DNSSEC is not necessary here.  Run-time
  cryptographic signatures are not needed to verify compile-time
  constants.

(And thus, validating the signatures could only serve to introduce
failures into a system for minimal benefit.)

  The path from the DNS64 recursive resolver to the ultimate client
  (queries for IPv6 address records) *cannot* be protected by DNSSEC,
  because the DNS64 recursive resolver is synthesizing IPv6 address
  answers, and does not possess the secret key required to sign those
  answers.

"The secret key" being the one signing .arpa?

  Consequently, the 'ipv4only.arpa' zone MUST be an insecure
  delegation, to give NAT64/DNS64 gateways the freedom to synthesize

It is perhaps worth reiterating (shock! Me suggesting making the
document even longer!) that the ipv4only.arpa name is only used within
the NAT64 environment, so there are not other cases that might be able
to benefit from DNSSEC even if this one cannot.

Section 7.1

I'm not 100% I'm properly going through all the cases when an
application is aware of multiple networks and selectively producing
traffic with different source addresses.  We in this document impose the
requirement that the ipv4only.arpa answers used in generating outbound
traffic must come from the resolver recommended by the network on that
interface; is it definitely the case that an application that cares
about its source address is going to either get the right thing from the
OS or be doing NAT64 address synthesis, such that in other cases
applications (as stated) do not need to worry about the special behavior?
I guess I'm also unsure about the relationship between any name
resolution APIs (which we list as requiring the special behavior) the
application might be using and the application's source-address
selection.  Are name resolution APIs even tied to a particular
interface?

      Regardless of any manual client DNS configuration, DNS overrides
      configured by VPN client software, or any other mechanisms that
      influence the choice of the client's recursive resolver
      address(es) (including client devices that run their own local
      recursive resolver and use the loopback address as their
      configured recursive resolver address) all queries for
      'ipv4only.arpa' and any subdomains of that name MUST be sent to
      the recursive resolver learned from the network interface in
      question via IPv6 Router Advertisement Options for DNS
      Configuration [RFC8106], DNS Configuration options for DHCPv6
      [RFC3646], or other configuration mechanisms.  Because DNS

In a similar vein, suppose an application uses an existing name
resolution API that doesn't have an 'interface' parameter to try to look
up ipv4only.arpa.  What is supposed to happen?

      within that zone.  Making the 'ipv4only.arpa' zone a secure
      delegation would make it impossible for DNS64 recursive resolvers
      to create synthesized AAAA answers that won't fail DNSSEC
      validation, thereby defeating the entire purpose of the
      'ipv4only.arpa' name.

I suggest "impossible for DNS64 recursive resolvers to synthesize AAAA
answers that will be accepted by DNSSEC validating clients" to avoid the
double negative.

Section 7.2

  2.  Application software SHOULD NOT recognize these two reverse
      mapping names as special, and SHOULD NOT treat them differently.
      For example, if the user were to issue the Unix command
      "host 192.0.0.170" then the "host" command should call the name

I feel like I've been told that the `host` command is deprecated, but
cannot substantiate that claim.  (The most commonly suggested
alternative, `dig`, is also unsatisfactory for usage in a situation
where it requires a reference, due to the unfortunate expantion of the
name.)

Section 8

(Is the normative "MUST" really needed here?)

[Ballot comment]
Thanks for writing this document to correct the oversight in RFC7050. I do have a trivial nit that you might want to address (or feel free to ignore).

* Section 3.1

While talking about public recursive resolvers being used in IPv6-only networks with NAT64, using their IPv4 addresses as their identifier makes me cringe. I would greatly prefer if they are referred to by their common names. Something like this would work

At the time of writing, examples of widely known public recursive resolver services include Cloudflare Public DNS [DNS1], Google Public DNS [DNS8], and Quad9 [DNS9]

[Ballot comment]
One purely editorial comment:
In section 2:
"Instead, the DNS protocol has, in effect, been co-opted as
  an impromptu client-to-middlebox communication protocol,..."
To be honest this confused me initially because for a while I thought there actually is some kind of proprietary protocol people use here while it's rather a "neat" hack. I would recommend to rather first clearly explain how and why this is used than just calling it a "impromptu client-to-middlebox communication protocol" right from the beginning.

[Ballot comment]
I have a few editorial comments only, none of which require any response:

— Section 1.1 —
Please use the boilerplate directly from 8174: it was debated and worded as it is (citing BCP 14) intentionally.

— Section 2 —

  This is clearly not a typical DNS name.  In normal operation, clients
  never query for the two records that do in fact exist; instead
  clients query for records that are known to not exist, and then get
  positive answers to those abnormal queries.  Clients are using DNS to
  perform queries for this name, but they are certainly not using DNS
  to learn legitimate answers from the name's legitimate authoritative
  server.  Instead, the DNS protocol has, in effect, been co-opted as
  an impromptu client-to-middlebox communication protocol, to
  communicate with the NAT64/DNS64 [RFC6146] [RFC6147] gateway, if
  present, and request that it disclose the prefix it is using for IPv6
  address synthesis.

This paragraph strikes me as a combination of duplication and verbosity.  May I humbly suggest replacing it with something like this?:

NEW
This odd query behaviour comes not because clients are using DNS to learn legitimate answers from the name's legitimate authoritative server.  Instead, the DNS protocol has, in effect, been co-opted as an improvised client-to-middlebox communication protocol, to look for a NAT64/DNS64 [RFC6146] [RFC6147] gateway and, if one is present, to request that it disclose the prefix it is using for IPv6 address synthesis.
END

I’ll note that this isn’t the only place where this document repeats itself (another example is the second paragraph of Section 3.2, and another is the repetition of “the 'ipv4only.arpa' zone MUST be an insecure delegation” in Secton 5).  I’d prefer if the repeating repetitiousness were cleaned up, but I’m not going to push it further.

— Section 3.1 —

  At the time of writing,
  examples of widely known public recursive resolver services include
  1.1.1.1 [DNS1], 8.8.8.8 [DNS8], and 9.9.9.9 [DNS9].

What’s the value to this document or its readers to list these, in particular?  It seems to me that the text leading up to this is adequate, and that this sentence and the associated references should be struck.

[Ballot comment]
Notes for reviewers / background:
RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis") says[0] that you should resolver the "well-known IPv4-only
fully qualified domain name "ipv4only.arpa."" to determine the NAT64
prefix[1].

Unfortunately RFC7050 didn't request that the name "ipv4only.arpa" be
added to the Special Use Domain Name registry -- this document
rectifies this oversight.

I asked DNSOP (and BEHAVE) to review and provide feedback, and the
authors have addressed the comments. Some additional (largely supportive)
comments were received during IETF LC, and have been addressed as
well.

I figured some background / history might be helpful when you review
this document.

[0]: This is oversimplified, but good enough for this purpose.
[1]:  "one or more AAAA resource records indicates that the access
network is utilizing IPv6 address synthesis."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-cheshire-sudn-ipv4only-dot-arpa-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the three actions requested by this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, with the approval of the IAB, IANA will implement the changes requested in Section 7 for ipv4only.arpa

Second:
IANA will record the following names in the Special-Use Domain Names registry located at:
https://www.iana.org/assignments/special-use-domain-names/

ipv4only.arpa.
170.0.0.192.in-addr.arpa.
171.0.0.192.in-addr.arpa.

Third:
IANA will record the following IPv4 addresses in the IPv4 Special-Purpose Address Registry located at:
https://www.iana.org/assignments/iana-ipv4-special-registry/

192.0.0.170
192.0.0.171

Question: As these addresses are part of allocations already in the registry, is this document meant to be added as a reference to these entries?

192.0.0.170/32, 192.0.0.171/32 NAT64/DNS64 Discovery

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2020-02-17):

From: The IESG
To: IETF-Announce
CC: warren@kumari.net, draft-cheshire-sudn-ipv4only-dot-arpa@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Special Use Domain Name 'ipv4only.arpa') to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'Special Use Domain Name 'ipv4only.arpa''
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.

  As a result of this omission, in cases where software needs to give
  this name special treatment in order for it to work correctly, there
  was no clear mandate authorizing software authors to implement that
  special treatment.  Software implementers were left with the choice
  between not implementing the special behavior necessary for the name
  queries to work correctly, or implementing the special behavior and
  being accused of being noncompliant with some RFC.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-cheshire-sudn-ipv4only-dot-arpa/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-cheshire-sudn-ipv4only-dot-arpa/ballot/


No IPR declarations have been submitted directly on this I-D.

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.

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.
[ PENDING -- MAIL SENT:  2020-01-18 ]


(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

(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.