3 ms·
> And because people often misunderstand RFCs as being "official": >> This document is not an Internet Standards Track specification; it is published for infor
by throw0101d 2y ago
> And because people often misunderstand RFCs as being "official":
>> This document is not an Internet Standards Track specification; it is published for informational purposes.
I guess we should stop using NAT then, because it is also 'only' informational and not standards-track:
* https://datatracker.ietf.org/doc/html/rfc1631 https://datatracker.ietf.org/doc/html/rfc1631
* https://datatracker.ietf.org/doc/html/rfc3022 https://datatracker.ietf.org/doc/html/rfc3022
- chrismorgan 2y agoWithout thinking too deeply about it, NAT isn’t defining a protocol or any kind of specification, it’s just describing a common pattern, something that is entirely implementation detail and which can vary a lot. There isn’t actually anything to standardise in it! > This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Yep, that sounds completely factual to me. Is it a similar situation for RFC 9180? I’m not delving into it so I don’t know whether it’s something concretely and compatibly implementable, or just a broad description of an approach, but even if it is the latter, it probably could have been something concretely and compatibly implementable, so I’m reasonably sure it’s still a different situation from NAT, where, by nature, nothing directly connected to it is suitable for Standards Track.
- throw0101d 2y agoOn some networking forums I've gotten grief for mentioning NPTv6 because it was experimental: * https://datatracker.ietf.org/doc/html/rfc6296 https://datatracker.ietf.org/doc/html/rfc6296 I wonder if these people would consider informational better or worse than experimental. (At the time I didn't know NA(P)T44 was 'only' informational, so was not able to bring it up as a 'counter-argument'.)