Hi, Shumon, On Wed, Sep 14, 2016 at 8:47 PM, Shumon Huque <shu...@gmail.com> wrote:
> On Wed, Sep 14, 2016 at 6:05 PM, Spencer Dawkins at IETF < > spencerdawkins.i...@gmail.com> wrote: > >> Hi, Shumon, >> >> On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque <shu...@gmail.com> wrote: >> >>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> 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? >>>> >>> >>> Yes, agreed. How about? >>> >>> "This document updates portions of RFC 1034 and RFC 2308". >>> >> >> That would work for me. "portions of" is implicit in Updates, because if >> you were updating all of those RFCs you'd probably be Obsoleting them, but >> I wouldn't object to saying "portions of". >> > > Ah, good point :-) I'm fine with dispensing with "portions of" in that > case. > > >>>> 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 >>>> expires.) >>>> >>>> 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. >>>> >>> >>> There was a long discussion on list about this point, but the quick >>> summary is that it is mostly for performance. For implementations that use >>> a flat data structure like a hash table, it is much more work to invalidate >>> all cache entries under the NXDOMAIN eliciting node. I believe Section 6 of >>> the draft does discuss this issue. Maybe we can make it clearer, or let us >>> know if you have any specific suggestions for doing so. >>> >> >> Just providing a hint would have worked for me, and a forward pointer to >> Section 6 would be even better. Perhaps something like >> >> 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 >> expires, since this may avoid additional processing when an NXDOMAIN >> cut is received. Section 6 provides more information about this. >> > >> But you're more likely to get the text right than I am ... >> > > Your proposed text sounds good to me (although I'd replace your "NXDOMAIN > cut" with "NXDOMAIN response" in the penultimate sentence above). > "But you're more likely to get the text right than I am ..." :D Thanks for getting it right! Spencer > > >> 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). >>>> >>> >>> The section is attempting to say that it is NOT OK to use the SOA record >>> owner name. We could make that clearer. >>> >>> I would personally be okay with removing this section also. I can't >>> recall what discussion happened that caused this scenario to be included - >>> maybe Stephane remembers. >>> >> >> Do The Right Thing, of course. >> >> Thanks for considering my comments! >> > > Sure - and thanks for the comments! > > -- > Shumon Huque > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
