Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

bert hubert <bert.hubert@powerdns.com> Sun, 24 March 2019 12:04 UTC

Return-Path: <bert@hubertnet.nl>
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 A9015126C15 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 05:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6QkNnJZGiqGX for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 05:04:48 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82ACD126C01 for <dnsop@ietf.org>; Sun, 24 Mar 2019 05:04:47 -0700 (PDT)
Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id C5CBF9FB9E; Sun, 24 Mar 2019 12:04:44 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 9CC9DACEB9C; Sun, 24 Mar 2019 13:04:44 +0100 (CET)
Date: Sun, 24 Mar 2019 13:04:44 +0100
From: bert hubert <bert.hubert@powerdns.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Benno Overeinder <benno@NLnetLabs.nl>, dnsop@ietf.org
Message-ID: <20190324120444.GB22597@server.ds9a.nl>
References: <CAJE_bqdugE3oMqyHres4hwhs4-NpO8yW2FwGDrk2WDAtbweBiQ@mail.gmail.com> <23682.53436.400539.805166@gro.dd.org> <8ffa4b04-324a-36c8-a9ff-e0cda726a54c@NLnetLabs.nl> <841f8174-c7d5-c702-e6be-ccb9a7c2c048@redbarn.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <841f8174-c7d5-c702-e6be-ccb9a7c2c048@redbarn.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pzFWpvb7ttispkYczphCWyX_f8w>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 24 Mar 2019 12:04:51 -0000

On Sun, Mar 24, 2019 at 04:36:50AM -0700, Paul Vixie wrote:
> i object to serve-stale as proposed. my objection is fundamental and goes to
> the semantics. no editorial change would resolve the problem.

I too object.  This is partially due to the apparently unresolved IPR issue
from Akamai, who are known not to be shy asserting their IPR.

https://datatracker.ietf.org/ipr/3014/ notes an Akamai IPR claim and does
not yet provide a license suitable for use on an open internet.

https://patents.google.com/patent/US8583801B2/en & 

https://en.wikipedia.org/wiki/Akamai_Techs.,_Inc._v._Limelight_Networks,_Inc.
have some context. 

The mechanics are that once something is an RFC, operators require adherance
to it. This in turn is a boon for the IPR holder, and hurts everyone else.

My secondary objection is that the draft contains an example implementation
that then however uses normative words. This leads to pain with operators
demanding serve-stale compliance. Example algorithms should clearly be
examples and not tell us what we SHOULD do.

	Bert