Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Dave Lawrence <tale@dd.org> Wed, 15 November 2017 04:54 UTC

Return-Path: <tale@dd.org>
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 2FD88128B4E for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sdsKHobEdliP for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:54:27 -0800 (PST)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC601201F8 for <dnsop@ietf.org>; Tue, 14 Nov 2017 20:54:27 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 250443F442; Tue, 14 Nov 2017 23:54:26 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23051.51330.101425.365809@gro.dd.org>
Date: Tue, 14 Nov 2017 23:54:26 -0500
From: Dave Lawrence <tale@dd.org>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <alpine.LRH.2.21.1711142311430.29343@bofh.nohats.ca>
References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <CA+nkc8B1sVhjbn1xYu4rQNgUZGgeaqnVjW=U0nmpRdu6rvXU2Q@mail.gmail.com> <23051.40720.908131.277454@gro.dd.org> <CAHXf=0oQTVe3LFdkGLYH0XL4Vg1Fm5JdnOaOCJ59zwiMkk6MVw@mail.gmail.com> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <alpine.LRH.2.21.1711142311430.29343@bofh.nohats.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/14_m-MFsHBiSIRGt0yFprZvFxtA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt
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, 15 Nov 2017 04:54:28 -0000

tale:
>> It is significantly less operationally beneficial if it demands EDNS.

Paul, and echoed by Paul:
> i'm of the opposite view. we should not change behaviour without
> explicit signaling.

I've opened this as an issue to track toward WG consensus and suspect
that, unless strong consensus for one view or the other obviously
emerges on the list, that we'll be looking for a hum on it in London.

On the practical side, private implementations are of course going to
easily evade any MUST that could eventually make its way here and
still be seamlessly interoperable with clients.  The restriction's
effect would mainly be binding for implementations claiming the
strictest compliance.