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

[Paul Vixie <[e-mail]>]

神明達哉 wrote:
> At Wed, 15 Nov 2017 05:41:04 +0000,
> P Vix<[e-mail]>  wrote:
>
>>> 1) when the request explicitly signals it is ok;
>>> 2) when the request groks EDNS but might or might not understand
>>>    a staleness option; or
>>> 3) in all cases.
>>>
>>> My current understanding is that you and Paul are of position 1, while
>>> I'm at 3.  At first glance 2 would appear to be pretty nearly the same
>>> as 3 as far as its permissive toward unaware clients, but
>>> significantly it does at least provide signal you could still access
>>> via protocol debugging (dig, tcpdump, etc).
>> I expect you to implement 3. I expect us to document 1.
>
> Realistically, I expect virtually everyone will implement 3, given how
> this kind of feature is sold in the marketing context.  ,,,

me too. that's why, in:

https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f

...i wrote:

> therefore a "serve stale" team within IETF-DNSOP was convened, to try to
> standardize the methods and signal patterns necessary to extend the
> usability lifetime of records when their authority servers are not
> reachable at the time of normal TTL-based expiry. most of us recognize
> that TTL's will continue to be stretched no matter what changes are or
> are not made to the specification, and so we expect the resulting RFC to
> document current practice _without recommending it_ and to also document
> a new practice _with recommendations_ as to its proper uses.

comments would be very welcome.

-- 
P Vixie