At Wed, 15 Nov 2017 05:41:04 +0000, P Vix <p...@redbarn.org> 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. Open-source reference implementations may implement 1 if it actually becomes the standard behavior, but I bet any serious large-scale user of those implementations will make a custom change to disable that part. I'd be sad about that, but that's quite likely to be the reality. I don't want the IETF to standardize a bad practice, and in that sense I'd personally prefer option 1 (or something that shares its spirit). But, as an engineering group, if there's basically no chance to deploy it I don't see a point of bothering to standardize it. So, if we choose to document option 1, I'd like to know the plan of this group of its deployability. Is it that we optimistically think that nearly all stub resolvers eventually (in 5-10 years?) support the signaling option and enable it by default, and then server implementations will gradually start honoring the standard (and until then we'll just grumble about the deployment of non-compliant implementations)? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
