Re: [DNSOP] raising the bar: requiring implementations

What is work: An "informational" document being used as standard is people
taking a submitted (expired) draft as "standard"?

Tim

On Thu, Apr 5, 2018 at 1:39 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Wed, 4 Apr 2018 11:22:33 +0200,
> Petr Špaček <petr.spacek@nic.cz> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>