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
