At Thu, 16 Nov 2017 22:02:33 -0800, Paul Vixie <p...@redbarn.org> wrote:
> > 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. This (including the entire message) looks reasonable to me, as long as we mean it, i.e., we actually seriously work on the "new practice" as a followup wg task, rather than just using it as an excuse to publish the current serve-stale draft. But I'd note there might be some confusion here (perhaps only for me, though). I've been having the impression that we are talking about "signalling" between the stub and caching (usually recursive) server, perhaps because it's a followup of this message: https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html But your suggestion is signalling (mainly) between caching and authoritative servers, right? I thought recommending to allow fallback to stale >>> 1) when the request explicitly signals it is ok; between stub and caching wasn't realistic, as I didn't see a strong incentive for the developers and users of stub (except for protocol-savvy kinds). That's why I was pessimistic in my previous message. I see more reality if it's about signalling between caching and authoritative since, as you pointed out, there may also be incentive for authoritative operators to adopt the "new practice". -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
