AS112 Redirection Using DNAME
draft-ietf-dnsop-as112-dname-06
Yes
(Brian Haberman)
No Objection
(Alissa Cooper)
(Barry Leiba)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Stephen Farrell)
Note: This ballot was opened for revision 04 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-08-19 for -04)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
(was Discuss, Yes)
No Objection
No Objection
(2014-11-23 for -05)
Unknown
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 IESG member
No Objection
No Objection
(2014-08-20 for -04)
Unknown
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 IESG member
No Objection
No Objection
(for -04)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2014-08-21 for -04)
Unknown
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 IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-08-18 for -04)
Unknown
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 IESG member
No Objection
No Objection
(2014-11-24)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2014-08-21 for -04)
Unknown
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!