Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Bob Harold <> Tue, 14 November 2017 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64B4C1273E2 for <>; Tue, 14 Nov 2017 08:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id axnvNBvEJstX for <>; Tue, 14 Nov 2017 08:06:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 841521271FD for <>; Tue, 14 Nov 2017 08:06:47 -0800 (PST)
Received: by with SMTP id s11so10225767pgc.5 for <>; Tue, 14 Nov 2017 08:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYVdps3Tjc0Ii2tN63EwBlYQZJSD8X22vv20YJ38L1I=; b=px6nkoSNe0mLlOw95TGKbtAVhEAP3vZ0/L/+c766et8xmfVZg2OvEqAB4lsH66Eglp ptnUoV5Ede9ucCqPeAzT0ANfGmpN1Yg2j0veRB9F+oL/2lI/AzPMBPtTqK3uH5VapOD0 14ng0wCDfbexID3b4fCQjR2LZGXZIv+Y7awwF/EyMXWjMvEDgooqVkBbFwDf4roDUR8R h8Yf3fnuN+tqaK2c12f5w/UhUuK103zxHE6oP4rQSmlR5h0plgtjjbIty8eB8wb+zzs4 5ox0cpbwFzw7CSfFTVZGM0ibrJ3YgfVotacloBpHmRLXcZVlYgu+gh7C3tY5Ba+ReZVs ylyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fYVdps3Tjc0Ii2tN63EwBlYQZJSD8X22vv20YJ38L1I=; b=bluAzlt9VNscgGURUEQBxQCNlRTYyxYnII0ci37UiuV/AcM71Ht14X3mJvSe+MywIC JhlzBnNmZ+iCiZD9RMmHyOuw2V904yStNsc/CwtT+bhNkheepNLF/Pn66FZao6235+z3 scbFo4Fn31BomXKcOgIBPQAbqBnWZA5pJpjyLodv6KmyeAOhfyOhAusFOfsX+ud2mB2u yE/4bRzlI0mO5UkeOWSyLMhG0zUilcek0HEpBFeQJf3/7iDF9ket9myWam7/M3dFee3w 5krNs7XEDqBkZf259dIuuLArIcRESu9wDJH34WFgqBf2SU4WlwssCvwbtSkaU/uCo0eP csKQ==
X-Gm-Message-State: AJaThX7B49xgUqOw+eP3VfluEzQlqYhib0EuLpAHIwFQlHj66suaKsPg spf6HtaiZ/E/J71irx3N55wxTrDtwIs2DkFIFxvrDA==
X-Google-Smtp-Source: AGs4zMYuqNeNqPe+zoZ5TU8G8nhnQBc9Ke+NnXpj3XZy9PQlj2k39nc9nXZsr80/79U14vnb15WGvn9+W9XDhqvco/Y=
X-Received: by with SMTP id a61mr11630019plc.338.1510675606845; Tue, 14 Nov 2017 08:06:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 14 Nov 2017 08:06:45 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Bob Harold <>
Date: Tue, 14 Nov 2017 11:06:45 -0500
Message-ID: <>
To: Dave Lawrence <>
Content-Type: multipart/alternative; boundary="94eb2c11a6c0ead171055df392a5"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2017 16:06:54 -0000

On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence <> wrote:

> Dave Lawrence writes:
> > The main changes, based on previous feedback, are:
> >
> > * Clarifying what the action is for Standards Track;
> > * Describing the algorithm previously proposed (and still included) as
> >   one example way of achieving the goals; and,
> > * Adding a rough proposal for an EDNS option that could be used for
> >   explicit signalling.
> >
> > That last item will be fleshed out more if there's demonstrated
> > interest from implementers in having such a thing.
> At the moment I'll observe there are no open issues against the draft,
> which is my comically passive-aggressive way of pointing out that it
> is obviously perfect and so let's just move it along to Last Call.
> This is now your opportunity to correspondingly observe that someone
> is wrong on the Internet and to respond appropriately.  At the very
> least, we'd like to know whether there is sufficient support for
> pursuing the EDNS option or just to take it back out (and leave the
> rest of the obviously perfect document as-is).
> Thanks in advance for any feedback,
> tale

I think signaling between the client and resolver is important.  I am a
little concerned about yet another option that the client might want to
send with every query.  Can the existence of *any* EDNS option from the
client be taken to mean that EDNS options are understood in general, and
the resolver is ok to respond with this ENDS option, which the client might
not understand but will not choke on?

Signalling between the resolver and authoritative server gets more
complicated.  Probably a good idea, but if the defaults are reasonable, it
probably won't need to be used often.

Bob Harold