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

Paul Vixie <> Tue, 26 March 2019 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A417120296 for <>; Tue, 26 Mar 2019 02:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyd6vXqwvf7J for <>; Tue, 26 Mar 2019 02:00:33 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 498F212030D for <>; Tue, 26 Mar 2019 02:00:33 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 409E2892C6; Tue, 26 Mar 2019 09:00:31 +0000 (UTC)
To: Puneet Sood <>
Cc: Benno Overeinder <>, IETF DNSOP WG <>
References: <> <> <> <> <>
From: Paul Vixie <>
Message-ID: <>
Date: Tue, 26 Mar 2019 02:00:29 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.12
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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, 26 Mar 2019 09:00:36 -0000

Puneet Sood wrote on 2019-03-25 08:07:
> Hi Paul,
> On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie <> wrote:
>> i object to serve-stale as proposed. my objection is fundamental and
>> goes to the semantics. no editorial change would resolve the problem.
>> i would withdraw that objection if this draft incorporates section 2 of
>>, to wit:
> I went back and read the discussion on this draft and I could not find
> consensus on adopting it at that time.

noone understood it. there was no reply, positive or negative, to my 
proposal that the WG adopt it. it dropped like a brick, in silence.

i believe that the issues are, now, nine years later, better understood.

> ... I do not think adding it to the
> serve-stale draft will make path for adoption for either the
> serve-stale draft or these recommendations easier.

understood. we disagree, but, i understand your position.

> section 5
> (page 6, paragraph 2) talks about refreshing the delegation. Quote:
> + When no authorities are able to be reached during a resolution
> +   attempt, the resolver SHOULD attempt to refresh the delegation and
> +   restart the iterative lookup process with the remaining time on the
> +   query resolution timer.  This resumption should be done only once
> +   during one resolution effort.
> Maybe there are fewer, specific bits from your draft which would be
> appropriate in the serve-stale context? Would you be willing to
> discuss those?

yes, certainly. the text i quoted from the 2010 resimprove draft was the 
result of implementation experience, and touches on necessary details, 
which are at the moment missing from serve-stale. i'll be very happy to 
discuss these, though regrettably, i could only be in prague for sunday, 
and so i'll miss any side meetings or working group discussions this 
time. no disrespect is intended by my absence, i had other obligations.

P Vixie