Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Dave Lawrence <> Tue, 03 December 2019 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37B4F120220; Tue, 3 Dec 2019 10:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b4uOzk4P4KPJ; Tue, 3 Dec 2019 10:24:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC98A1201E5; Tue, 3 Dec 2019 10:24:06 -0800 (PST)
Received: by (Postfix, from userid 0) id D90BBB8AA8; Tue, 3 Dec 2019 13:24:05 -0500 (EST)
Received: by (Postfix, from userid 102) id 99E9BB81A1; Mon, 2 Dec 2019 17:42:23 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 2 Dec 2019 17:42:23 -0500
From: Dave Lawrence <>
In-Reply-To: <>
References: <>
Archived-At: <>
Subject: Re: [DNSOP] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2019 18:24:08 -0000

Thank you very much for your review, Mirja.

> 1) It seems to me that this sentence in section 7 should/could
> actually be phrased as a normative requirement in this document: "it
> is not necessary that every client request needs to trigger a new
> lookup flow in the presence of stale data, [...]"

I agree.  We had a lot of back-and-forth in the working group about
normative language in this document, and but for the Standards Action
section.  I'm personally in support of more of it, but ended up having
to strip out existing instances of normative language based on working
group consensus.

> 2) I find the Implementation Status section (8) actually quite
> interesting for this document and maybe it should be considered to
> keep it in the document for final publication.

I personally am in favor of this, not just for this document but for
all RFCs.   RFC 6982 recommends that the section be removed, but I'd
be happy to help evolve that recommendation.