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

[Dave Lawrence <[e-mail]>]

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?

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.

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).