NXDOMAIN: There Really Is Nothing Underneath

Note: This ballot was opened for revision 04 and is now closed.

(Ben Campbell) Yes

Comment (2016-09-09 for -04)
No email
send info
One minor question: In section 2,  paragraph 3, which behavior is "this behavior"? The continuing to use cached data under the cut, or the cached non-existence itself?

(Spencer Dawkins) Yes

Comment (2016-09-14 for -04)
No email
send info
I honestly look forward to reading DNSOPS drafts because they are uniquely chatty, and this one is no exception (awesome document title, dude). That said, 

   This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
   updates both of them.
being "a bit modified" is like being a bit dead (either you're dead or you're not), so maybe that's TOO chatty? 

This draft was very clear to me, as a non-DNS reader. Thanks for that.

Just for my own education, 

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply.  (Until the TTL of this cached data
I found myself wondering why this behavior is allowed. Is this a performance thing, that you continue to respond normally until normal TTL expiration happens with no special processing required, or is this about the non-tree cache implementations described in Section 6, or is there more to it than that? Perhaps that's worth a word or two explaining.

In this text in Appendix A, 

   Even if the accompanying SOA record is
   for example only, one cannot infer that foobar.example is
   nonexistent.  The accompanying SOA indicates the apex of the zone,
   not the closest existing domain name.
it's not clear that this practice is OK, and (especially from the example that will be deleted), it seems dodgy to the uninitiated. Perhaps it's worth saying so clearly (if it is, in fact, OK).

(Stephen Farrell) Yes

(Joel Jaeggli) Yes

(Terry Manderson) Yes

Comment (2016-09-13 for -04)
No email
send info
In a very poor attempt at not showing my own geek level too much here, this document was a pleasure to read, well constructed, and a perfect fit for the ambiguity in 1034. Thank you!!

(Alexey Melnikov) Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-09-15 for -04)
No email
send info
I like the sections 3.1 and 3.2.
These are in line with the recent discussion on the wgchairs mailing list, and https://tools.ietf.org/html/draft-wilde-updating-rfcs-00.
Copying erik.wilde@dret.net

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Alvaro Retana No Objection