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

[神明達哉 <[e-mail]>]

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