Re: [DNSOP] Working Group Last Call

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 14 October 2016 12:44 UTC

Return-Path: <matthijs@pletterpet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF6E12981F for <dnsop@ietfa.amsl.com>; Fri, 14 Oct 2016 05:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeLHESfuvvI8 for <dnsop@ietfa.amsl.com>; Fri, 14 Oct 2016 05:44:51 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45700129818 for <dnsop@ietf.org>; Fri, 14 Oct 2016 05:44:51 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:d9d4:42e4:a681:d4bf] (unknown [IPv6:2001:981:19be:1:d9d4:42e4:a681:d4bf]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 148DDAE76; Fri, 14 Oct 2016 14:44:49 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: Warren Kumari <warren@kumari.net>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <eda9f6f0-6ecc-9fcf-d961-d60d20831549@pletterpet.nl> <CAHw9_iLDY5=VS8Wc9onGZpQ9Z15k93RXrNGkv8ULS-9c9vHULA@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <5d4a8e88-4d50-07d7-e198-8530715b5c64@pletterpet.nl>
Date: Fri, 14 Oct 2016 14:44:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAHw9_iLDY5=VS8Wc9onGZpQ9Z15k93RXrNGkv8ULS-9c9vHULA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bmYmYkbVe2aeCr8WlQdks3__USY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 12:44:54 -0000

Hi Warren,

On 08-10-16 00:57, Warren Kumari wrote:
> On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking <matthijs@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
> 
> 
>