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, 神明達哉 <jin...@wide.ad.jp> wrote: > At Wed, 4 Apr 2018 11:22:33 +0200, > Petr Špaček <petr.spa...@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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
