IETF Logo Mail Archive

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

Paul Wouters <paul@nohats.ca> Thu, 07 September 2017 18:28 UTC

Return-Path: <paul@nohats.ca>
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 3550A132940 for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 11:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 PeCxkw4kP9ns for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 11:28:36 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA13126DD9 for <dnsop@ietf.org>; Thu, 7 Sep 2017 11:28:36 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xp88y36nMzFSp; Thu, 7 Sep 2017 20:28:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1504808914; bh=VZ/j+Zcd2lwv0eJtsMs8wUoLtUg7yBUmdtTjkHuoUaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dck4P/V7J8rTVyOc0MnyXzPB02NgZPAaDTTwe/unNQu5XfLWwa+zxyW1ORU+t9yvy Blw9YMqaIUkam1ZrDRboHiEtKDydvs4D/8KnclN6epJsa4LMVb94wLVuNFMEHs2V+i zbX2WfuBrs6aKwpdRL2FC7fyA3iF3GbGdNHGoY0I=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XlIA0PILk6UB; Thu, 7 Sep 2017 20:28:33 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 Sep 2017 20:28:32 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D64754EF55; Thu, 7 Sep 2017 14:28:31 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D64754EF55
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BC26D40B850E; Thu, 7 Sep 2017 14:28:31 -0400 (EDT)
Date: Thu, 07 Sep 2017 14:28:31 -0400
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
In-Reply-To: <B1CDAB08-6A2A-4D76-B3FB-0B267382930A@hopcount.ca>
Message-ID: <alpine.LRH.2.21.1709071428060.27006@bofh.nohats.ca>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <20170907154234.3z2zbju2sciiy7wr@nic.fr> <B1CDAB08-6A2A-4D76-B3FB-0B267382930A@hopcount.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/43MTzgiZYCUIvkeTgq2i35VOT7Q>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
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: Thu, 07 Sep 2017 18:28:38 -0000

On Thu, 7 Sep 2017, Joe Abley wrote:

> I hear that. I don't have a strong opinion about whether serving stale data in general is desirable or abhorrent. However, the pragmatist in me says that people are already implementing things like this anyway, and a standard approach is better for all concerned than a fragmented set of uncomfortably-different implementations, which will surely make troubleshooting problems harder.
>
> I also think if a standard specification can be obtained it ought to include appropriate instrumentation to allow a response to indicate whether data is stale or not. This seems to me just one example of a set of additional components we might expect the working group to come up with, which in my mind is a good reason to make it a working group document.
>
> I support adoption with all of that in mind.

Agreed.

Paul

v2.23.0 | Report a Bug | By Email