Hi Warren, On 08-10-16 00:57, Warren Kumari wrote: > On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking <matth...@pletterpet.nl> > wrote: >> All, >> >> I reviewed this draft and while it is shaping up nicely, I don't think it is >> quite ready for publication: >> >> 1. As John pointed out earlier, the document makes an inconsistent use of >> RFCC 2119 keywords, and we need to decide whether to use MAY or SHOULD. >> Looking at the definitions of the keywords again I am leaning towards MAY, >> but given the described benefits I could see how SHOULD would be >> appropriate. Either way, it should be consistent. Also, the used keyword for >> NSEC should not be different than that for NSEC3. > > Ok, I *think* that I have this correct, but it MAY still be muddled. :-)
It is still muddled :( In Section 5: [SHOULD] If the validating resolver's cache has sufficient information to validate the query, the resolver SHOULD use NSEC/NSEC3/wildcard records aggressively. In Section 5.1 NSEC: [SHOULD] Implementations which support aggressive use of NSEC SHOULD enable this by default. In Section 5.1 NSEC3: [MAY] A validating resolver implementation MAY support aggressive use of NSEC3. If it does support aggressive use of NSEC3, it SHOULD enable this by default. In Section 5.2 Wildcards: [MAY] As long as the validating resolver can determine that a name would not exist without the wildcard match, it MAY synthesize an answer for that name using the cached deduced wildcard. An implementation MAY support aggressive use of wildcards. >> 2. In addition to the first point, I don't think it is appropriate to use >> RFC 2119 keywords to dictate name server configuration. Mentioning it would >> be useful to have configuration options for enabling and disabling this >> functionality seems okay, but drop the RFC 2119 formalities. > > I think that we came to agreement further down-thread that it is OK to > have this. If you disagree with this, please provide some text.... The argument for this being OK is that there exist other RFCs that do that. Personally I find that is not a very convincing argument :) There is PR with suggested text: https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/3 In here everything in Section 5 is a SHOULD, and key words related to configurations are downgraded to lower case. >> 3. In section 6 on Benefits, it says "currently around 65% of queries to >> Root Name servers result in NXDOMAIN responses." This is quickly outdated, [SNIP] >> >> A similar layout for NSEC3 should be provided, and I am willing to provide >> that if this layout is accepted. > > So, I have incorporated a number of changes around this section, and > much of it has been rewritten. I *think* that this is now clearer, and > covers your concern -- however, I've been staring at the same text for > many hours, and shuffling text back and forth, and so I may simply be > confused. Please let me know if you still think it needs changing. > W Yes, this is indeed much clearer, and takes away my concerns. The mentioned PR has some minor changes with respect to this though. Best regards, Matthijs > > >> >> Best regards, >> Matthijs >> >> >> On 22-09-16 14:19, Tim Wicinski wrote: >>> >>> All >>> >>> This draft has been worked on and it seems that the Working Group is >>> happy with the updates that have been made and I feel it's ready for the >>> next step. >>> >>> This starts a Working Group Last Call for: >>> "Aggressive use of NSEC/NSEC3" >>> draft-ietf-dnsop-nsec-aggressiveuse >>> >>> Current versions of the draft is available here: >>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ >>> >>> Please review the draft and offer relevant comments. Also, if someone >>> feels the document is *not* ready for publication, please speak out with >>> your reasons. >>> >>> It's currently marked as "Proposed Standard", so if folks feel >>> differently then please speak up. >>> >>> >>> This starts a two week Working Group Last Call process, and ends at >>> midnight 7 October 2016 UTC. >>> >>> thanks >>> tim >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
