Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

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 <rharolde@umich.edu
> <mailto:rharolde@umich.edu>> wrote:
> 
> 
>     On Wed, Dec 14, 2016 at 8:53 AM, Stephane Bortzmeyer
>     <bortzmeyer@nic.fr <mailto:bortzmeyer@nic.fr>> wrote:
> 
>         On Tue, Dec 13, 2016 at 02:13:27PM -0500,
>          tjw ietf <tjw.ietf@gmail.com <mailto:tjw.ietf@gmail.com>> 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
>     DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 