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

[P Vix <[e-mail]>]

On November 14, 2017 9:13:29 PM PST, Dave Lawrence <[e-mail]> wrote:
>Paul Vixie writes:
>> i'm of the opposite view. we should not change behaviour without 
>> explicit signaling. if that means it takes 10 years to reach 50% 
>> penetration, like EDNS did, then that's the cost of doing business.
>
>Just so I'm clear, am I understanding correctly from this that you
>believe a recursive server should only fall back to stale data from
>cache if the request explicitly included a staleness option?

Yes. I know that coherency does not rank high in a cdn operator's priority queue, but the dns has other users also.

>I ask because Bob's comment that started this thread was exploring
>being able to signal staleness back when OPT was included in the
>request but the option being defined by the draft wasn't included.

Ah.

>To me this makes three different positions we're trying to reach
>consensus about, for allowing fallback to stale either:
>
>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.

2 would be chaos, helping nobody.

>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.