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

Dave Lawrence <tale@dd.org> Mon, 25 March 2019 19:58 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 32912120077 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 12:58:20 -0700 (PDT)
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 YAk4FqqiCvJh for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 12:58:18 -0700 (PDT)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CB6120044 for <dnsop@ietf.org>; Mon, 25 Mar 2019 12:58:17 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id 352808EB9B; Mon, 25 Mar 2019 15:58:17 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23705.13017.200224.74243@gro.dd.org>
Date: Mon, 25 Mar 2019 15:58:17 -0400
From: Dave Lawrence <tale@dd.org>
To: dnsop@ietf.org
In-Reply-To: <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> <20190324120444.GB22597@server.ds9a.nl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/q9ttEkglMlD3_Hu-06v0QftgUUw>
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: Mon, 25 Mar 2019 19:58:20 -0000

bert hubert writes:
> 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.

This is definitely a problem.  Even though Akamai had previously
agreed to specify under what IETF-acceptable terms the IPR would be
made available, it clearly hasn't yet specified them.  I've contacted
them to get a timeline on when the legal department can take care of
this, and the first order response is that the DNS team is trying to
get the ball rolling again with legal this week.

> 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.

As previously noted in this very thread, at least one of the authors,
Puneet, agrees with you.  When I wrote the text that way it was
because of the also not-unreasonable viewpoint that if someone were to
be implementing the example then the text could be considered
normative as to how to do that.  It's even softened by having no MUSTs
at all, just SHOULD.  In addition, I'm dubious as to the claim that
people would cause meaningful pain to demand compliance with an
example, and not be adequately refuted when it is pointed out to them
that it is a clearly marked as an example.

That said, since I had waffled on it myself at time of composition and
I don't actually have a very strong feeling about it, in the end
wouldn't fight over downcasing it.  Yet I think it should be settled
at a level above dnsop because ultimately it's an issue that should be
consistent across IETF documentation.  Unless there's already an
explicitly stated IETF policy about this, and not just ad hoc past
cases to point to, I think it is best to sort out with the RFC editor.