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.


    <https://www.rfc-editor.org/rfc/rfc9548.html#section-2>

I expect the standard boiler plate to evolve, but this will be gated on some Trust-related changes.

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

Attachment: OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key

Attachment: 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

Reply via email to