I will just note that recently independent RFCs have additional statements to make clear that the work is not a product of the IETF. For example:
Although this document has been discussed widely in the IETF community (see the Acknowledgements section), it represents the views of the author, not community consensus.
or
This Independent Submission is not a standard nor does it have IETF community consensus.
In the case of cryptography, the statements are considerably stronger:
Caution: This specification is not a standard and does not have IETF community consensus. It makes use of a cryptographic algorithm that is a national standard for Russia. Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses.I expect the standard boiler plate to evolve, but this will be gated on some Trust-related changes.<https://www.rfc-editor.org/rfc/rfc9548.html#section-2>
Eliot On 01.12.2024 22:50, Jay Daley wrote:
On 2 Dec 2024, at 08:15, Brian E Carpenter<brian.e.carpen...@gmail.com> wrote: There's nothing new about Informational RFCs that are a (re)publication of an external specification. That was covered in RFC 2026 section 4.2.2: Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. It certainly was a bit ambiguous when you couldn't tell from the text of the RFC whether it was that kind of Informational or the normal kind that originated in the IETF. But that changed when the Independent RFC series was formalized.Except that we now have two very different meanings for 'informational' that we only distinguish in the boilerplate, making it hard to spot - 'IETF-wide consensus informational' and ’Independent, no consensus, informational'. That could be addressed by boilerplate but that is not written for people external to the IETF to understand clearly, suffering instead from the recurring issue that we write externally directed words with a focus on getting internal agreement to their correctness above all else. viz:This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841."This is a contribution to the RFC Series, independently of any other RFC stream." means very little to anyone not quite deeply engaged in the IETF. If we rewrote this boilerplate, aiming for far greater understanding by those who are not engaged in the IETF, then it would read something like: "This RFC is an informational document published independently of the IETF and was not edited, reviewed or approved by the IETF. It is not an Internet Standard, nor is it eligible to become one at a later date, and should not be referenced as such. Any views expressed in this RFC are solely those of the authors and not the IETF." Jay
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org