Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-nsec-aggressiveuse-09: (with COMMENT)

Warren Kumari <warren@kumari.net> Wed, 24 May 2017 21:25 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 353CE129B21 for <dnsop@ietfa.amsl.com>; Wed, 24 May 2017 14:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] 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 3LMkuBkx027R for <dnsop@ietfa.amsl.com>; Wed, 24 May 2017 14:25:24 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 84BA2129BC6 for <dnsop@ietf.org>; Wed, 24 May 2017 14:25:23 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id x71so82442534vkd.0 for <dnsop@ietf.org>; Wed, 24 May 2017 14:25:23 -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:content-transfer-encoding; bh=b6rTqI1dtyN2nrnzXzuOa9YRSI9Hyi1naQfopa6i7wY=; b=JIWy0tGAWPjJRJ8eVzmrTV5YRpKs+8TY1EuuAGKz1mlXq5xfFfVkhhrT+DmfwLrYag k/pi1GIOb7+qtqEMjCJmeyi8VBtNGNKxKdci96gzlifoiiSrlJ8b0MK/f+YmFOU1MUSc KIFKGw4KJOCtMjF0dvwC6+L4EOvcmZt1qZB2TznUoz/QPge9f8X5gJ591ipoEpZj7Mrc rOOFll9VtMCglMYW6EMJOg92NK9RfQ2e7oEYP5LCB7DZEE3G3zM1/q55nRTe7pezVPBB A6QBIE1Def1AAXf/kfqBqy71FJm6mINnqqOoYhY2wo601ogJYrGlA8iN1O6mG1bquxPI VZjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b6rTqI1dtyN2nrnzXzuOa9YRSI9Hyi1naQfopa6i7wY=; b=ddXwbNDCIk5XyRhO+eMPvL/vUv8hMwl3U/hd4eADBjXP//jfHHegL+HtkouZZWroPv gSboZyyYE4n8oR948NE37FD6yq1Fy4Oy7v6sQODFC1tGymfbl4+dsZuRWYHP9czOsp57 5M54hlyhYJasjlcFeUOSmLV5mVd1oXkLvfEYEM6x4bhiK9GfUwnitViPKhe+0aW0qsJQ S5OZupPgGk3YAP8hXrYvsYzLTD7P04HL3w38SL3rXi+kvle/ROeytpeF02wp04WaWeLq zkghPoYakhmFwt9V92Fr3baLD9aX6nRCt7Kh73XnS6u1Uus+F6CKRO3Zt28bK2YNe0Zu dK2Q==
X-Gm-Message-State: AODbwcARDpVQjmp21w5XLYXOIyz/MkULkNu70opNntjfe5w1+9dd1k7O +DRzbV/c2V0ka8dlB1F74pXQkQIgVy4J
X-Received: by 10.31.173.142 with SMTP id w136mr15075295vke.125.1495661122475; Wed, 24 May 2017 14:25:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.71.83 with HTTP; Wed, 24 May 2017 14:24:42 -0700 (PDT)
In-Reply-To: <149546704472.24735.15566276762755962935.idtracker@ietfa.amsl.com>
References: <149546704472.24735.15566276762755962935.idtracker@ietfa.amsl.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 24 May 2017 17:24:42 -0400
Message-ID: <CAHw9_iLnRv8c8_H2K9JgRLzfjEr3Hb-fPij0Lt9UzXoEuMJ8gQ@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6Z4cR5zZ5lvbK2G81yxnLyirm2Y>
Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-nsec-aggressiveuse-09=3A_=28with_COMMENT=29?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 May 2017 21:25:26 -0000

On Mon, May 22, 2017 at 11:30 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
>
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dnsop-nsec-aggressiveuse-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> One smallish, unimportant editorial comment:
> In section 5, e.g.: "If the negative cache of the validating resolver has
> sufficient
>    information to validate the query, the resolver SHOULD use NSEC,
>    NSEC3 and wildcard records aggressively."
> it seems like the word "aggressive" has some meaning which was at least
> not clear to me. Is there a difference in negative caching and aggressive
> negative caching? If this word should provide any additional information
> on what to do could you maybe further explain?



Yup, you are right - aggressively wasn't well defined.
I've just submitted a new version with:
"the resolver SHOULD use NSEC, NSEC3 and wildcard records
aggressively." -> "the resolver SHOULD use NSEC, NSEC3 and wildcard
records to synthesize answers as described in this document".

It also addresses the other IESG comments (basically remove parens
around a bit in the intro, and also explicitly ask the RFC Editor to
remove the bits in square brackets ""Ed note: Text inside square
brackets ([])"...

W




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