Re: [DNSOP] raising the bar: requiring implementations

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

At Wed, 4 Apr 2018 11:22:33 +0200,
Petr Špaček <[e-mail]> wrote:

> >> This is actually quite a good example of another problem:
> >> Client-subnet was documented for Informational purposes; it was
> >> already in wide use in the public internet and had an EDNS opt code
> >> codepoint allocated from the IANA registry.
> >>
> >> Nothing that happened in DNSOP or the IETF changed that, and I
> >> strongly suspect nothing that happened in DNSOP or the IETF could have
> >> changed it.
> >
> > We found issues in the client-subnet description (in the draft stages)
> > that were corrected before it became RFC - this involved some behavioral
> > changes. However, the opportunity was not given to address fundamental
> > design issues, so what's in the RFC largely documents the
> > implementations preceding it and still has issues. I didn't think
> > client-subnet was in wide use when it came to dnsop. Even today it
> > doesn't look like it's in wide use.

[...]

> I tend to agree with Mukund. What's the point of doing standards, if
> there is nothing to test against?

I also agree here.  Especially in the case of client-subnet, I
observed another (IMO) bad practice that seems to be abused quite
often recently: use the word of "informational" as an excuse for
dismissing suggestions.  The commonly seen logic is "this is just
intended to be an information document, just describing an existing
deployment in case that may be useful for others (and so any
significant changes should be rejected)".  But in actuality such a
spec is often used as a standard protocol spec that should be
interoperable among various different implementations.  And, IMO, that
was actually the case for ECS.

Another rhetoric often (ab)used in such a case is to say "a more
complete full standard will follow this informational document; we can
make significant changes at that point."  But in reality such a
followup task often doesn't even start.  Again, that's also the case
for ECS after nearly two years since the publication of RFC7871.

In the context of the camel discussion, I think we should use this
lesson for rejecting this kind of abusing the "informational" status.
We should not pretend it's really just for information when we
actually expect it will be used a "de facto" standard that is likely
to be implemented by various vendors.

--
JINMEI, Tatuya