3 ms·

(2022.) And because people often misunderstand RFCs as being "official": > This document is not an Internet Standards Track specification; it is published for

(2022.) And because people often misunderstand RFCs as being "official": > This document is not an Internet Standards Track specification; it is published for informational purposes. > This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

marshray 2y ago
Organizations making decisions about technology investments involving large amounts of money do care about this designation when making decisions.
deleted 2y ago
[deleted]
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 ago
  Without 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 ago
    On 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'.)
ekr____ 2y ago
Yes, the situation is somewhat confusing. RFCs produced by the IRTF are not IETF standards. However, as a practical matter, when the IETF wants to specify cryptographic algorithms, it has the Cryptographic Forum Research Group (part of IRTF) do it. HPKE is one such case, but see also X25519 (RFC 7748), Verifiable Random Functions (RFC 9381), etc. The CFRG has its own consensus development process that terminates in RFCs which are then treated more or less as standards even they are formally not. This doesn't apply to other IRTF RFCs, which generally aren't treated as having any special status.

marshray 2y ago

Organizations making decisions about technology investments involving large amounts of money do care about this designation when making decisions.

deleted 2y ago

[deleted]

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 ago
Without 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 ago
  On 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'.)

ekr____ 2y ago

Yes, the situation is somewhat confusing. RFCs produced by the IRTF are not IETF standards. However, as a practical matter, when the IETF wants to specify cryptographic algorithms, it has the Cryptographic Forum Research Group (part of IRTF) do it. HPKE is one such case, but see also X25519 (RFC 7748), Verifiable Random Functions (RFC 9381), etc. The CFRG has its own consensus development process that terminates in RFCs which are then treated more or less as standards even they are formally not. This doesn't apply to other IRTF RFCs, which generally aren't treated as having any special status.