IETF Logo Mail Archive

Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

神明達哉 <jinmei@wide.ad.jp> Sat, 17 October 2015 01:34 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C328B1A896B for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 18:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 1QnzzIp92MoD for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 18:34:41 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 A71461A896A for <dnsop@ietf.org>; Fri, 16 Oct 2015 18:34:41 -0700 (PDT)
Received: by iow1 with SMTP id 1so142190455iow.1 for <dnsop@ietf.org>; Fri, 16 Oct 2015 18:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gJpzSqUfXS5Yzz+TIcxRAI45C9NKck/mE7njIHZsXoQ=; b=FFE+eMDdir8J1TR4WBxLRfuPjdM2DAI5AWjm24i3mHM6G+3YebTsEE/Fi/5NkTnAB/ LwXgGe3KCECI+UPCvOrDIVWcuLQXpLnd1rM+iaa0Zj5y/tV91Yv8mW3Jq5j/7cK6EWU4 erK7wzh1AzcPQVggcAvqxYvnIPl5+vQ0UDeWTbUtikk3o0fsOkbinZMtbg2n1OR1Mt5f +ph3Sd+6LTP3TLmm3dMXSOmVtOLL2yOwH8R5kcsY9UWMRM28E1f2RqFhhgf3yM+aRVpO uxd8F/bblvrODBZK0ftaqHlJRMWreRqhf8+iFzpfiDVbyYVF22x5u1yxlGTEUf9kifKy AgSA==
MIME-Version: 1.0
X-Received: by 10.107.13.4 with SMTP id 4mr19508574ion.178.1445045681106; Fri, 16 Oct 2015 18:34:41 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.12 with HTTP; Fri, 16 Oct 2015 18:34:40 -0700 (PDT)
In-Reply-To: <d2f5212cbf9b4f46a5cae9f3af3f1f50@mxph4chrw.fgremc.it>
References: <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org> <20151016161831.58bdf78d@pallas.home.time-travellers.org> <56211942.20206@redbarn.org> <CAJE_bqcxjC=zS8tj6tKGX18UeEFm6GHcyRhjC7AFdh3x9-L=vA@mail.gmail.com> <d2f5212cbf9b4f46a5cae9f3af3f1f50@mxph4chrw.fgremc.it>
Date: Fri, 16 Oct 2015 18:34:40 -0700
X-Google-Sender-Auth: 4tiGcV0hwGHlz4VBUF1P9ttNSts
Message-ID: <CAJE_bqcUKnOHsVw0fPOpQ=3gH_EN-v1zQWX3VhZ5Xxp1vMqfSQ@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/bUs4A23fxELQa00mVIZZrqmyFi0>
Cc: Shane Kerr <shane@time-travellers.org>, dnsop WG <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 17 Oct 2015 01:34:42 -0000

At Fri, 16 Oct 2015 17:07:27 +0000,
"Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com> wrote:

> Let's see, millions of full-service resolvers, times the
> packet-count differential between UDP and TCP, times the average
> reload/restart frequency of those full-service resolvers per
> day/week/month. Can't a case be made from sheer volume?

I've not checked the validity of the math, but even if that's valid, I
believe a SHOULD is enough for such a purpose.  Sane implementations
would honor that, and insane implementations would do whatever they
want whether it's a SHOULD or MUST.

> > > I have separate issue, which is this text:
> > >
> > >     The priming query MUST be sent over UDP (section 6.1.3.2 of
> > >     [RFC1123]).

My interpretation of this was that since the support for TCP was a
SHOULD in section 6.1.3.2 of RFC1123 trying TCP could result in an
interoperability problem (hence the MUST).  And what I tried to say is
that now that the support for TCP is a REQUIRED this MUST looks like a
'super-strong recommendation'.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email