AS112 Redirection Using DNAME
RFC 7535
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Brian Haberman; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document, but time to stop "proposing" things, and start "defining" or "describing". This document proposes a more flexibl approach for sinking queries And other examples. Oh, and s/flexibl/flexible/ --- In Section 2 Some or all of the existing AS112 nodes should be extended to support these new nameserver addresses, and to host the EMPTY.AS112.ARPA zone. I wondered about "should" in this sentence. Is there an objective to this, or a philosophical reason, or...?
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) (was Discuss, Yes) No Objection
Draft 05 added text aimed at Ted Hardie's comments. was Holding the dicsuss until a rev that addresses ted hardie's indivual comments is complete for the record. My own personal comments, were the document to come back for last call, would be a request for additional discussion of cache poisoning considerations in the absence of DNSSEC in the security considerations section, some clarifications in the language of section 4's discussion of replacement of the existing infrastruction and a request for expansion of the text in Section 5. There may be other comments from others, of course, were the document's scope highlighted in the last call. Thanks for your consideration, was Holding the dicsuss for pete until IAB question is resolved. was: Discuss (2014-08-21 for -04) A strictly procedural point that I haven't seen anyone else comment on. Section 7 says that the address delegation will require IAB approval. Is the IESG tracking that, or is that an IANA thing to track, or is it done, or what? Comment (2014-08-21 for -04) In the document writeup, the shepherd suggests that there was some ambivalence regarding the status of this document, and suggested that perhaps Experimental would be appropriate, even though they landed on Informational. I think Experimental is exactly right, with an eye toward moving this to BCP eventually. (See my comments on 6304bis.) from scott bradner: opsdir review. in the 2nd paragraph of section 3.3 - remove the comment about the IPv6 testing environment and the note about the IANA request in the 2nd paragraph of section 4.2 - add a forward reference to section 4.4. Routing Software
(Kathleen Moriarty; former steering group member) No Objection
Once my questions in RFC6304bis are addressed, I think I'm good with this draft. Thanks for you work on the draft!
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
In the document writeup, the shepherd suggests that there was some ambivalence regarding the status of this document, and suggested that perhaps Experimental would be appropriate, even though they landed on Informational. I think Experimental is exactly right, with an eye toward moving this to BCP eventually. (See my comments on 6304bis.)
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
Some very minor nits: In this text in the abstract: The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily. when this draft is approved, the first sentence won’t be true, will it? Could you think about how you want the RFC to say this? The corresponding text in the Introduction may also benefit from the same thinking: AS112 nameserver operators are only loosely-coordinated, and hence adding support for a new zone (or, correspondingly, removing support for a zone that is no longer delegated to the AS112 nameservers) is difficult to accomplish with accuracy; testing AS112 nameservers remotely to see whether they are configured to answer authoritatively for a particular zone is similarly challenging since AS112 nodes are distributed using anycast [RFC4786]. Nit: s/flexibl /flexible / In this text: 6. DNAME Deployment Considerations DNAME was specified a significant time following the original ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementations of [RFC1035], and hence universal deployment cannot be expected. This didn’t parse well for me. Perhaps “was specified years after the original implementations of”? In this text: 9. Security Considerations This document presents no known additional security concerns to the Internet. For security considerations relating to AS112 service in general, see [RFC6304bis]. is the first paragraph saying “no additional considerations beyond http://tools.ietf.org/html/draft-ietf-dnsop-rfc6304bis-00#section-8” or "no additional considerations beyond [RFC6304]"? I’m not sure how to read it.
(Stephen Farrell; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
The abstract on this document is way too long. You don't need to explain everything; just give enough of a hook that people who should read the document will. At its current length, it's unlikely anyone will read the abstract. E.g.: AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records. Otherwise, looks good!