I have read the -07 version and I think this document is ready for publication.
I do still think that the end of section 4 and start of section 5 is too similar and can be combined such that it only quotes RFC 4035 one time. Perhaps Section 5 can just start with: 5. Aggressive use of Cache This document relaxes the restriction given in Section 4.5 of [RFC4035], see Section 7 for more detail. If the negative cache of the validating resolver has sufficient... Best regards, Matthijs On 15-12-16 15:55, Warren Kumari wrote: > > > On Thu, Dec 15, 2016 at 9:38 AM Bob Harold <[email protected] > <mailto:[email protected]>> wrote: > > > On Wed, Dec 14, 2016 at 8:53 AM, Stephane Bortzmeyer > <[email protected] <mailto:[email protected]>> wrote: > > On Tue, Dec 13, 2016 at 02:13:27PM -0500, > tjw ietf <[email protected] <mailto:[email protected]>> wrote > a message of 94 lines which said: > > > This starts a Working Group Last Call for: > > "Aggressive use of NSEC/NSEC3" > > draft-ietf-dnsop-nsec-aggressiveuse > > I've read -07 and I believe it is OK and ready for publication. > All my > (many) remarks have been addressed, I think. > > Two details: > > > [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first > steps to > > using NXDOMAIN information for more effective caching > > IMHO, RFC 8020 supersedes draft-vixie-dnsext-resimprove, so it > is not > necessary to mention both. If you prefer to do so for historical > completeness, may be you should mention them in the chronological > order? > > > Yup, I think that having them both is useful, both for historical > purposes, but also because resimprove contains much worth reading -- I > like you swapping the order suggestion... > > > > As these benefits are only accrued by those using DNSSEC, it is > > hoped that these techniques will lead to more DNSSEC deployment. > > This sentence should really be deleted. It seems to imply that > DNSSEC > cannot work on its own merits and need extra arguments. "NSEC > aggressive use of caching"'s goal is not to promote DNSSEC, it is to > improve the DNS! > > > That was certainly not the intent, but rather what Bob had suggested > below -- this adds yet another point to the "how to justify spending the > $$$ to management / bean-counters" list. I *do* understand where you are > coming from, but am not sure how to word something appropriate -- would > "These benefits are only accrued by those using DNSSEC, it is hoped that > these techniques will speed the deployment of DNSSEC validation". > That makes it more clear that DNSSEC is the right thing to do anyway, > and that this just helps us get there faster? > > > I would like to respectfully disagree. I read the sentence as > saying that this adds one more benefit to running DNSSEC, which > makes people like me want to move DNSSEC closer to the top of my > priority list. > > > Yup, that was the intent - many people want to deploy, but need to > juggle priorities, or convince bean-counters why this is the right thing > to do. Waving the security flag makes them shrug, but pointing how this > might help save money gets more management buy-in for the ask. > > W > (Yes, I did use "management buy-in for the ask." in an IETF mail. It was > oddly thrilling :-)) > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
