Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

神明達哉 <jinmei@wide.ad.jp> Thu, 15 October 2015 17:00 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 349CF1A802E for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 10:00:45 -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 zDZPTIp2o0mx for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 10:00:44 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 4A0381A21A5 for <dnsop@ietf.org>; Thu, 15 Oct 2015 10:00:43 -0700 (PDT)
Received: by igbdj2 with SMTP id dj2so16637955igb.1 for <dnsop@ietf.org>; Thu, 15 Oct 2015 10:00:42 -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:content-transfer-encoding; bh=mc2fHgPKzdCD49euqRxojjQOZU6HDO1Xy7KuIam9qOI=; b=unAY5rItLX3rBvaWa183c20ZbZIo8BrhxVanX/7ZTukVmwfoxVCQBPtfsmpXzYN7Hr ZH74qgeKpbLiq+y5NwMH6t96cz9/z3J1ln5QIgGfdtuaA+facIcCStEv0Joh8nDzgnWJ fSL+OiKUkqk+GOJ0MP5EKJhwykZrnlgLCgeA6gyMVCGonnaOmzSucsgcQdWtxls0PUae c4CCQY1ndv9t3y1Xuc69gvEhFDUyIoKXua7jvdYq59Ifyp+uwkG3sZo46Vf3ELv5lV7u rMCe3F/39I65CdMnr0zw01nIboSGrcOQcEDMiEB5ILpwOUFxgPx9G5Sfjapg6cl3Wzkq TyPA==
MIME-Version: 1.0
X-Received: by 10.50.112.100 with SMTP id ip4mr12461775igb.78.1444928442538; Thu, 15 Oct 2015 10:00:42 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.12 with HTTP; Thu, 15 Oct 2015 10:00:42 -0700 (PDT)
In-Reply-To: <870D0139-5AC0-481C-8225-BB8752FDBB40@sinodun.com>
References: <5612D8BA.1080307@gmail.com> <CAJE_bqevRz0W7w507kkxp9MQjyGPjBjHOu_+EAe_T+t0kXsdmg@mail.gmail.com> <B724E834-63BC-4233-850C-EE0D52DFCC3B@sinodun.com> <CAJE_bqdmWC8Wryjd2BwsidOEJY05ci-WUftLQyBOw3hB5b3+Fg@mail.gmail.com> <870D0139-5AC0-481C-8225-BB8752FDBB40@sinodun.com>
Date: Thu, 15 Oct 2015 10:00:42 -0700
X-Google-Sender-Auth: NPtLytx04KDfKxsmygy3XVjoG10
Message-ID: <CAJE_bqe7bUJRLCv7ZhB63F=priaCnmq0A6K2EakxK1Tb3yRTJA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Sara Dickinson <sara@sinodun.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/i6j6gELe4d04o7FOu5P7LsSGHk8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive
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: Thu, 15 Oct 2015 17:00:45 -0000

At Thu, 15 Oct 2015 16:32:40 +0100,
Sara Dickinson <sara@sinodun.com> wrote:

> My hesitation here is that if it is a SHOULD, then I think the
> document would need a bit more detail regarding what ‘regularly’
> means, rather than simply saying the precise behaviour is out of
> scope. I like to think that when something is specified as a SHOULD
> then it should be relatively easy to determine if an implementation
> is compliant with that requirement, and without specifying more
> detail here I don’t think that would be easy. Do you have any
> thoughts on that?  IIRC there were some discussions among the
> authors about this prior to the -02 version and we deliberately left
> this out because how to time these subsequent signals isn’t
> obvious. However maybe this isn’t really necessary and the above
> text is acceptable.

I see your point.  But whether the updated notification from the
server works relies on whether the client includes an OPT RR in
subsequent queries, ambiguity on the latter can easily lead to
interoperability problem.  So I thought this should be at least
clearly documented and RFC2119 keywords are helpful exactly in such a
situation.  I personally do not think a SHOULD inevitably requires
more specific text about the frequency, although I see some others may
have a different opinion.

That said, I just realized I misunderstood one related part...

> A couple of details to consider:
>
> 1) If the client is regularly sending messages with an EDNS0 OPT RR,
> then the server can respond to these by adding the
> edns-tcp-keepalive option and there is no need for the client to
> specifically send the edns-tcp-keepalive option in the query.

...I incorrectly thought the client needs to keep including the
edns-tcp-keepalive option.  I'm not sure if we can reasonably assume
clients generally include an EDNS OPT RR even if they have no other
particular reason to do so than the issue we're discussing here.  If
we can assume that, the text can be loosened.  But we probably cannot
rely on the current implementation behavior on this topic, so I think
it's safer to at least mention it explicitly in some way.

> The best wording I can come up with to try to cover this is:
>
> If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically
> in any further messages it sends during the TCP session.
> This will increase the chance of the client being notified should the server modify the timeout associated with a session.

I'm fine with this.  Also, if the use of 'SHOULD' really triggers
controversy on whether to be more specific about "periodically", I'm
fine with avoiding an RFC2119 keyword, too.

--
JINMEI, Tatuya