Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]

Dave Lawrence <> Fri, 01 March 2019 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A29A130EBE for <>; Fri, 1 Mar 2019 12:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Ua6EM_xQ9rL for <>; Fri, 1 Mar 2019 12:54:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CF231200B3 for <>; Fri, 1 Mar 2019 12:54:40 -0800 (PST)
Received: by (Postfix, from userid 102) id 85C581B3B6; Fri, 1 Mar 2019 15:54:39 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Fri, 1 Mar 2019 15:54:39 -0500
From: Dave Lawrence <>
In-Reply-To: <>, <>
References: <> <> <> <> <>
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]
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: Fri, 01 Mar 2019 20:54:44 -0000

Paul Hoffman writes:
> I'm not sure a standards track document that updates RFC 1034/1035
> should be recommending a minimum TTL. 

As previously noted, we're making no such recommendation and that will
be clarified.  The first definition of "resolution recheck timer" in
section 5 does already say that it regards failed lookups, but it
seems that adding that distinction later is also warranted.

> The document is actively confusing about recommendations.

Before we go pushing around whole sections of text, could anyone
please comment on whether they find it "actively confusing about
recommendations"?  Yes, they appear in a couple of different sections,
for different reasons -- as described in the text the example method
presented is just one possible way of doing things, with the core idea
and the standards-relevant changes being distinct.

The recommendations, however, are not in conflict with each other and
I'm really not clear myself on where the criticism that they are
confusing comes from.  The mention of the explicit word "recommended"
in section 6/6.1 is just reiterating the value described in section 5,
and in the broader sense of recommendations section 6.1 is meant as
how the recommendations were made.  (Personally I'd renumber 6.1 -> 7,
7 -> 8, etc, but  that's a minor separate issue.)  Putting that
discussion in a separate discussion doesn't bog down the basic
description of the sample implementation.

I don't object to reorganization in principle, if it makes notable
gains, but I can't really fix what I don't understand the problem is.