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:


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,
>> 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,

>> 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

Reply via email to