[DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

Barry Leiba <barryleiba@computer.org> Wed, 11 September 2019 16:06 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DC155120A5F; Wed, 11 Sep 2019 09:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.923
X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6ZGb9bnzYxfe; Wed, 11 Sep 2019 09:06:41 -0700 (PDT)
Received: from mail-io1-f66.google.com (mail-io1-f66.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4FD120043; Wed, 11 Sep 2019 09:06:36 -0700 (PDT)
Received: by mail-io1-f66.google.com with SMTP id m11so47116843ioo.0; Wed, 11 Sep 2019 09:06:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=vhoK2s80ipsMoDSV8u8DakySCIM6joCVUqfV17/Z7PA=; b=T9OpkhLThmbZwLNIZmNgbvhJK4qBPNuXxqRfD/XryFc8WXb/Qd2ZCNf1x91eMGnb02 sYvZxGzUhi8og6uP8Nq3ZsEN+DXA1CMpYOlQA8su+MeiSvz26iz/jNcQ3G+++MArdtdE k6UKWR8DfDb4kLDr/s7MfG8LNTaKkf/fS/NIQoYuCnXOOXIZG4MkyGMB+sKNCcQeWQSw 7qXApbgCa3JqJBAQFufkOlB+DHza9iftVUEGPeIf1iHsk/z7mh3azQ1xxBzTtFBbG7qf OdAsIw7msj/cPTpYAdj0qk8s7anpbvaNPAQz22K5yIk5PTNtiJNMyfqg+mIWhDyP5dCr YAyw==
X-Gm-Message-State: APjAAAXz6pWXlr8VmYCnDwB/7KEumrXICeK84WfgnFJentGFRshvvR6s BKNZI7DCcxa74pNawd2r1zOZnBquCssP6ktCtkrydDPo
X-Google-Smtp-Source: APXvYqyMEaVGmvYMGP3kgIEneCpeJnrZDW9nyp+EV2jjkcO7F0JVBiJq2qHtCGSkWBa6GZNPYUUR4tmx7EBox8GiKt0=
X-Received: by 2002:a02:9a12:: with SMTP id b18mr37935687jal.70.1568217995290; Wed, 11 Sep 2019 09:06:35 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 11 Sep 2019 12:06:23 -0400
Message-ID: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
To: draft-ietf-dnsop-serve-stale.all@ietf.org
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GEZyn9H_Cb5-zQaxaYdRyclEivc>
Subject: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07
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: Wed, 11 Sep 2019 16:06:44 -0000

I am handling this document as responsible AD, as Warren is a
co-author and so must recuse himself.  I’m not sure how I missed the
publication request, but miss it I did, and thanks to Warren for
pinging me.

Thanks for a very well-written and clear document.  I have only some
minor editorial comments and a couple of questions, all of which can
be addressed along with any last-call comments that come along.  I’ll
request last call right after I send this message.

— Abstract —

   data can be kept in the cache beyond the TTL expiry, and also updates
   RFC 2181 by interpreting values with the high order bit set as being
   positive, rather than 0, and also suggests a cap of 7 days.

The chain of “and also”s feels awkward; I would remove the first one,
so “…TTL expiry, updates RFC 2181…”.  (I might remove the second
“also” as well, as “and suggests” is fine without it.)  This text is
also in the Introduction, so whatever change is made in the Abstract
should be made in the Introduction too.

— Introduction —

   This document proposes that the definition of the TTL be explicitly
   expanded to allow for expired data to be used in the exceptional

This isn’t wrong, but for a standards-track document we would usually
say, “This document expands the definition of the TTL to explicitly
allow for…”.  It will be published as a Proposed Standard, so I guess
the “proposed” part can just come from there, yes?

— Section 3 —

   This is again not [RFC2119]-normative
   language, but does convey the natural language connotation that data

In my ongoing effort to disabuse people of the idea that language has
to have BCP 14 key words in order to be normative, I would prefer that
this say, “This wording again does not contain BCP 14 key words,
but…,” because I do believe the quoted text is normative.

   Several recursive resolver operators currently use stale data for
   answers in some way, including Akamai.

Misplaced modifier:
   Several recursive resolver operators, including Akamai, currently
   use stale data for answers in some way.

   collective operational experience is that it provides significant
   benefit with minimal downside.

The antecedent to “it” is unclear (it could refer to Apple MacOS or
the Happy Eyeballs algorithm or mDNSResponder).  Better to say, “…is
that using stale data can provide….”

— Section 4 —

      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired.

I wonder if it makes sense to be more explicit here that one isn’t
meant to keep using expired data forever, but is expected to keep
trying to refresh it.  So, maybe?:

      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired until an authoritative refresh is

— Section 5 —

“implementation dependent” needs a hyphen: “implementation-dependent”

— Section 6 —

   fact that no other RCODEs which a resolver normally encounters makes
   any assertions regarding the name in the question

Number agreement: “make any assertions”  (I would also change “which”
to “that”, but I’m picky about using “that” to introduce restrictive

   existing cache state.  Some authoritative servers operators have said

Either “authoritative server operators” or “authoritative servers’
operators”; I think the former.

   their servers are responding with errors like ServFail instead of
   giving true authoritative answers.  Implementers MAY decide to return
   stale answers in this situation.

It might be good for the last paragraph in Section 4, with the
“SHOULD”, to have a forward reference to this explanation.

— Section 10 —

Is another possible new security consideration that bad actors could
DDoS authoritative servers with the explicit intent of having stale
cached information used for longer, perhaps to extend the life of a
cache-poisoning attack or some such?