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

Puneet Sood <puneets@google.com> Wed, 18 September 2019 15:10 UTC

Return-Path: <puneets@google.com>
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 D2109120972 for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 08:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 gNhZrcrpiXQQ for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 3BC6012098C for <dnsop@ietf.org>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id i18so7281210wru.11 for <dnsop@ietf.org>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LzElnKlGwzrDc4oasIok8FBM8BX/2BItxLHVXSW6PbU=; b=OvIGaBaQJVSNJ44904ytt56Q9qwGKzoFBTngFcpGMpRT9QTwk+Tt+yeZfDtvQJKhd6 iiWZW9DP2FqQPm9XvCufWGMqnyv5Rm4eRaPvGgXQsYQOeDR/gxBGiB8+kgrsm4uxb6un uxBeoTuyllmxYfWyfPk8XkKwVr0WFkNfJpP8chI/QqMptTkTIlbuP1C4B8gBwtuRfrqU Z9xs+1i2E7Jg5qHEQ9+SjDK0uMJQnaJuci04a2XzzSFcDEu+hsxypLeGltMHkW5/f9mM SWaNorWSedRxMefe4fYc6Ypuf05jUwfEpqrudvGrw7Qqf6QMUtf94IgM3vT02P0GAdea S0xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LzElnKlGwzrDc4oasIok8FBM8BX/2BItxLHVXSW6PbU=; b=Md5luKEruppyI5kK/4kqU1y3Lkfgru5gEk+3YnSH7VbpTKthPYG+ZEyAOVH9g4Ri+L c9RSAAGjX178xXrosi1Ij4wGARHHQlelRdtYK8JrGP2L2zsMvlrsW7DikhG3bFkO6Npw EzI7uhDbpaQuQxpoj/vBn/M7dkvogupyFo/PJZW2A+dI9hwBggMxO10ZOh9DQtti0D1t 9szwTrvMpkHQ0c/3bdgTBcsM8UbBDj7Bjt3zecOuOwjUrm1FDMyyGtf/JI0M4tKPP1zr Dzegc+wEE1toldq081B2Efom8SX06XeehutNqvwRhn8Q7oKIEI/qLLx5DKhXLfJkYrTA aJxw==
X-Gm-Message-State: APjAAAXRJ7S0mzD36P/aMwILMZnH7Lvb5b72Afe0fC0Zg3ODJ9xm0xn1 Iw1y6SHZ7isTYMM0OVUeBcFttBB1Sx0EZmaMNWtFwg==
X-Google-Smtp-Source: APXvYqyjwxoqwG/H6S84LobjKeJiPEC+QXx3ZeoolAfQAVQWApWf1grHovugjgtYvvIpZOkbHBe8q7sAYLyiWBYNQyI=
X-Received: by 2002:a5d:4241:: with SMTP id s1mr3439706wrr.101.1568819398282; Wed, 18 Sep 2019 08:09:58 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
In-Reply-To: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
From: Puneet Sood <puneets@google.com>
Date: Wed, 18 Sep 2019 11:09:18 -0400
Message-ID: <CA+9_gVueD9XT1Hin5imPjz8RbUkJUqc6rsRoXsSXTY+qPZHBhQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: draft-ietf-dnsop-serve-stale.all@ietf.org, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F3gQWRertDfEW_IDJPCJLOpxtU4>
Subject: Re: [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, 18 Sep 2019 15:10:07 -0000

Barry,

Thanks for the detailed review. The editorial comments and security
considerations comment will be addressed in a new draft I will be
pushing.

On Wed, Sep 11, 2019 at 12:06 PM Barry Leiba <barryleiba@computer.org> wrote:
>
> 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.
DONE

>
> — 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?
DONE

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

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

>
>    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….”
DONE

>
> — 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?:
>
> NEW
>       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
>       successful.
> END

Addressing along with Stephane's response.

>
> — Section 5 —
>
> “implementation dependent” needs a hyphen: “implementation-dependent”
DONE

>
> — 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
> clauses.)
DONE

>
>    existing cache state.  Some authoritative servers operators have said
>
> Either “authoritative server operators” or “authoritative servers’
> operators”; I think the former.
DONE

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

>
> — 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?

Added wording with suggested text from Stephane.

-Puneet

>
> --
> Barry