Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Wed, 06 January 2016 12:34 UTC

Return-Path: <sara@sinodun.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 341411B2AA9; Wed, 6 Jan 2016 04:34:37 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 7u3SQ2hylitb; Wed, 6 Jan 2016 04:34:36 -0800 (PST)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FF81B2AA4; Wed, 6 Jan 2016 04:34:36 -0800 (PST)
Received: from [62.232.251.194] (port=10695 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from <sara@sinodun.com>) id 1aGnIH-0001Fj-OX; Wed, 06 Jan 2016 12:34:28 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <20160106082114.20998.93683.idtracker@ietfa.amsl.com>
Date: Wed, 06 Jan 2016 12:34:28 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8150CA35-12AA-4098-AEEF-631ABD7020CE@sinodun.com>
References: <20160106082114.20998.93683.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/9zjn02RP3tmaHQODoC09XBCmf0E>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-5966bis@ietf.org, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)
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: Wed, 06 Jan 2016 12:34:37 -0000

> On 6 Jan 2016, at 08:21, Barry Leiba <barryleiba@computer.org> wrote:
> 
> -- Section 5 --
> 
>   This requirement is hereby relaxed.  Stub resolvers and recursive
>   resolvers MAY elect to send either TCP or UDP queries depending on
>   local operational reasons.  TCP MAY be used before sending any UDP
>   queries.  If it already has an open TCP connection to the server it
>   SHOULD reuse this connection.  In essence, TCP ought to be considered
>   a valid alternative transport to UDP, not purely a fallback option.
> 
> The "If it already has" in the fourth sentence was clear in the original
> 
> 5966 text, but doesn't work here: there's no clear antecedent to "it".  
> Please make it "If the resolver already has”.

Ack.

> 
> In the last sentence, I think we should say "not purely a retry option,"
> 
> as this isn't really "fallback" in the sense we usually use the term.

OK.

> 
> -- Section 6.1.1 --
> 
>   However it
>   is common practice for clients to close the TCP connection after
>   sending a single request
> 
> In the light of edns-tcp-keepalive, do we really want to say this?  It's
> 
> true, but it sounds like a recommendation.  Maybe we might say something
> 
> like, "Clients often close the TCP connection after sending a single 
> request, but see [draft-ietf-dnsop-edns-tcp-keepalive]." ?

Well, this ‘Current Practices” section was trying to document what happens today, and to my knowledge keepalive isn’t implemented in any production software yet. We do reference the keepalive draft in the ‘Recommendations: Idle Timeouts” section though.

Perhaps we could change this to “However, at the time of writing it is common practice...” ?

Sara.