Re: [DNSOP] Working Group Last Call

Warren Kumari <warren@kumari.net> Thu, 20 October 2016 19:36 UTC

Return-Path: <warren@kumari.net>
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 5A3E61296B1 for <dnsop@ietfa.amsl.com>; Thu, 20 Oct 2016 12:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 ejAqQ9Q_RHEM for <dnsop@ietfa.amsl.com>; Thu, 20 Oct 2016 12:36:15 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A55129491 for <dnsop@ietf.org>; Thu, 20 Oct 2016 12:36:15 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id n189so114445852qke.0 for <dnsop@ietf.org>; Thu, 20 Oct 2016 12:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vKDvGDchUVuoN4rBOE532eWbXAplhKfNZGFkE/dZpAw=; b=hEiOxhPEOoByz+URQTSj/zXb6ok3GrmvZxHQVQs6oWKa4KhZQNdZNdAxRp8p4l/Zfi OdfbIWO7DPX6qe7FoSzwHTZJ9VTEzu9FCtZA18P5LaZcT/2SPeuvjtHCQh0/9bbmUs38 2AuJS0kDsiLPbz3z9cTMdye2A9PRQgs62z4kWwiSZtRzJUqrG8zRbb6B65ir0Tf+qoB7 679lRs5totdpOmHgGqAORZzbfmGOglQRQjZgIkm7CvbKHHe6jjSEKhlojhEXnTnMF0NT /AS313AbTgJLFKmpd/ENmKpcpZXcVFnh1zNqAsgMbGCe9s64vJJBR/s+4EFhv7sc/NNM YIjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vKDvGDchUVuoN4rBOE532eWbXAplhKfNZGFkE/dZpAw=; b=ZTrIdd3/9606zpQQlY6vAEdS/Id5IFzPqy1crMusVlJ7GVTNBg9Efe7voINkNsWp8k uSkR87podg59+qp1WPS6FoerUcMaqDwOmzDsElb/gVG76Slq36JCwjuJElZAurKABICM B+bQ3V82EkO3VhrvGvidjKo3S2PHwbnrx2z9lTyjp7F9BEY/z/R1itU28ZOqg10rPTIw D9eweFBkCqDOiBxO5T/AteJEvWGHyIij9Q8GQsWFWDKuFV1qN6UsfUoMcACxE+RQPQsc Vu6gF7o9hHeF7eVtZJXbyAgHw3TobjfcF1TJwdXiEJ+T/z0gDIc2LMFvDU6xgJP6W2wh iI2Q==
X-Gm-Message-State: ABUngvcgcwwgtk/JJoR1rEMBtpLRYsaDQdN101fq2CAb5P7Oozh7DAXBnK9739TcU5Ef5z0JdvJkxU0743VAJtUG
X-Received: by 10.233.237.209 with SMTP id c200mr1872253qkg.29.1476992174045; Thu, 20 Oct 2016 12:36:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 12:35:43 -0700 (PDT)
In-Reply-To: <CAHw9_i+kqj3Lr=cfMbS750ZjfgZ+LW0bhs7RUBisuvRKS9_W=g@mail.gmail.com>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <eda9f6f0-6ecc-9fcf-d961-d60d20831549@pletterpet.nl> <CAHw9_iLDY5=VS8Wc9onGZpQ9Z15k93RXrNGkv8ULS-9c9vHULA@mail.gmail.com> <5d4a8e88-4d50-07d7-e198-8530715b5c64@pletterpet.nl> <CAHw9_i+kqj3Lr=cfMbS750ZjfgZ+LW0bhs7RUBisuvRKS9_W=g@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 20 Oct 2016 15:35:43 -0400
Message-ID: <CAHw9_iLj3WxMGC82DiEm23BFWehFrAT31Cm1k7VWdOH+9zNhPw@mail.gmail.com>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PnabQ_jZBjaJ2VAJpTave-4qipA>
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: Thu, 20 Oct 2016 19:36:17 -0000

Hi all,

I think that I have addressed / incorporated everyone's comments.
If I have missed anything, please let me know, otherwise I believe
that this is done.

W

On Tue, Oct 18, 2016 at 12:06 PM, Warren Kumari <warren@kumari.net> wrote:
> [ Top-post ]
>
> Much thanks to Matthijs for providing text - I really apprecaite it. I
> have integrated / merged it.
>
> If anyone has additional wildcard text please let me know -- otherwise
> are we calling this cooked?
>
> W
>
> On Fri, Oct 14, 2016 at 8:44 AM, Matthijs Mekking
> <matthijs@pletterpet.nl> wrote:
>> 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
>>>
>>>
>>>
>>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf