IETF Logo Mail Archive

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 07 December 2016 02:32 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 4472C129626; Tue, 6 Dec 2016 18:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8uWF9dXl1vkr; Tue, 6 Dec 2016 18:32:38 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 76E5E129582; Tue, 6 Dec 2016 18:32:35 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id a10so289212595ywa.3; Tue, 06 Dec 2016 18:32:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PnhIzWZB8q5Slt6dpE5T4tEy4uMvvz53cQOqH64/dto=; b=RDyj0uiK0cbKbGdlrA7POEHYR+JeLXLy42xO2C9UNFWZARwHN5XA5Y7AYA+B66i0JQ +y9LyvP5GEnGumeADHBVmU37WACj0AMbSFbz+Ee4+ZKe943vsX98bv3InRYeJcM4BS+G d4FAYgBaO4rdvsmERuKXtfi7uJJQ4EIEGu6MrQtOBZRekNlohIoI36pehAsZuJJQNAt+ iBatBfooIrBLG8wANeLYyhrOhw3lYVoFFIFtzXtX+nStMDfOBcoYOk89h4AGoH9SUNRi 0Yh6hvSkRIRCNot4H+zfxZJwDgDBIe57ogKMHsJQKIL2PHDPPn6/j7/634i+P+9QvB05 LHzA==
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=PnhIzWZB8q5Slt6dpE5T4tEy4uMvvz53cQOqH64/dto=; b=WLTUgPilNGIA3fsdRQiZdoufclcwhQY0PvO2wXMNK0e+cmGMIaCTz/oViMsnFNeGOO 4TRz55kGm2IFf4hLMPj9Thbmg8LfTI0tll3sd1kBcM5xs5224A4aI1rLN2LSjf7IJ/Nr Ew4HbB4ST6giit5DVgSQlEi+39Gd27Lb+cj3g4z+eVdUlhD05nmVUksG+7fUpYOnKAmx 7CAPLqCXIhqVXqpOWF41dAUscn6zLAWRK6ZAW3Zu3WQB8H46Y6fOR/9qUW6+tKmLnJxj 5HoIBPpzHhFOo1wblrRu/Icuxfr6/xzUlWtZOreFgdv6D0lCg3SroHnmqSQjGxbBKOD4 tdkQ==
X-Gm-Message-State: AKaTC026n8PdrSYyEJagQFqeOtLl6FOlUlYyoDFW16GYQcyjXyiv2CtkKauWto9FMwUwGpp6JMeNb9lX29jUMw==
X-Received: by 10.13.253.6 with SMTP id n6mr67871625ywf.26.1481077954698; Tue, 06 Dec 2016 18:32:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.176.5 with HTTP; Tue, 6 Dec 2016 18:32:34 -0800 (PST)
In-Reply-To: <339F67B8-B76F-469C-9E22-8EAB8B2E672B@vpnc.org>
References: <148046227837.11642.8747586791761273945.idtracker@ietfa.amsl.com> <339F67B8-B76F-469C-9E22-8EAB8B2E672B@vpnc.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 06 Dec 2016 20:32:34 -0600
Message-ID: <CAKKJt-eF=MtwXLtRBU-1PngmM2iBtVm+inik7MWq4U6XCpAeCg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="94eb2c06b164600598054308557b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w3xho4w75Ig6ac-YRLpSAoyh5tg>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dnsop-resolver-priming@ietf.org
Subject: Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)
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: Wed, 07 Dec 2016 02:32:40 -0000

Hi, Paul,

On Tue, Dec 6, 2016 at 1:08 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Thanks for your comments and for having no objections to the document.
> This message follows up on the comments.
>
> --Paul Hoffman
>

Deleted down to


> On 30 Nov 2016, at 22:48, Spencer Dawkins wrote:
>
> I find myself curious about both SHOULDs in
>>
>>    Resolver software SHOULD treat the response to the priming query as a
>>    normal DNS response, just as it would use any other data fed to its
>>    cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
>>
>> Do you think these SHOULDs (especially the first one) are required for
>> interoperation?
>>
>
> Yes.
>
> I'm wondering (1) why they aren't MUSTs, and (2) why RFC
>> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs,
>> what happens if the resolver software violates them?
>>
>
> We cannot tell. For the first one, if a resolver treats the response to
> the priming query in a special way, we don't know what "special" means.


I'm somewhat curious about why this isn't a MUST, but ... ok.


> For the second one, if a resolver expects exactly 13 NS RRs and gets
> fewer, we don't know what it will do (fail to come up? retry incessantly?
> ...?)
>

I'm really curious about why this is not a MUST - can anything good happen
when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you
can assess the risks of doing it". Is that possible, in this case?

Spencer

v2.23.0 | Report a Bug | By Email