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

Paul Vixie <paul@redbarn.org> Tue, 26 March 2019 09:00 UTC

Return-Path: <paul@redbarn.org>
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 9A417120296 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 02:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyd6vXqwvf7J for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 02:00:33 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498F212030D for <dnsop@ietf.org>; Tue, 26 Mar 2019 02:00:33 -0700 (PDT)
Received: from [192.168.20.236] (unknown [194.126.205.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 409E2892C6; Tue, 26 Mar 2019 09:00:31 +0000 (UTC)
To: Puneet Sood <puneets@google.com>
Cc: Benno Overeinder <benno@nlnetlabs.nl>, IETF DNSOP WG <dnsop@ietf.org>
References: <CAJE_bqdugE3oMqyHres4hwhs4-NpO8yW2FwGDrk2WDAtbweBiQ@mail.gmail.com> <23682.53436.400539.805166@gro.dd.org> <8ffa4b04-324a-36c8-a9ff-e0cda726a54c@NLnetLabs.nl> <841f8174-c7d5-c702-e6be-ccb9a7c2c048@redbarn.org> <CA+9_gVtb2YU6Hr-eqnm4u-=bsFKRANdc_m5=oe7sLPQ-xbLf0A@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <a4f8ff42-c596-3d45-75bf-1bb955b5c9b3@redbarn.org>
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: <CA+9_gVtb2YU6Hr-eqnm4u-=bsFKRANdc_m5=oe7sLPQ-xbLf0A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v_qBz3EdVFCsyoPGB-yxUff2YkY>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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: 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 <paul@redbarn.org> 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
>> https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, 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.

> https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-04 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