Skip to main content

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!