[rfc-i] Fwd: Comment on headers-and-boilerplates

[Cullen Jennings]

One of the most valuable things the IETF has is the brand around term  
RFC. People want to have their protocol be an RFC because that  
implements a level review and consensus around the solutions. People  
are often willing to give up change control of a proprietary protocol  
in trade for the type of acceptance that many RFCs imply. I want to be  
careful not to create an environment that slowly erodes away any value  
of an RFC.

Clearly there are people that think all RFC are standards, and we need  
to educate them, but these people do actually read the RFCs. They  
often implement them and they often specify them as requirements to  
other people that need to implement them. I regularly have to deal  
with vendors  and customers that are do not realize any RFC are  
different from others RFCs - I'm sure you have all had similar  
experiences. I think the boiler plates are really most important for  
the people that are not familiar with the streams and tracks. Because  
of this I would like whatever we choose to have a few properties (and  
it arguable that it already has all of these)

1) Things that are not standards track are identified as not an  
standard. I understand that argument that it's nuts try and list  
everything that something is not but I find it very useful to be able  
to point out a specific document and point out that it says it's not a  
standard right on the front page of the document. I think this  
negative property is worth identifying.

2) I want to differentiate the breadth and type of review that a  
document received. I want to clear identification of the different  
type of review an Informational or experimental document gets from  
IETF LC, vs IRTF, vs Independent.  For things that were not reviewed  
by IETF, I want to be clear there we not reviewed by the IETF. I am  
fine an IETF stream informational documents that are not IETF LC end  
up marked as not reviewing by IETF.

All of the things being proposed here are significantly weaker than  
what gets currently used on some documents. That being

       The IETF disclaims any knowledge of the
       fitness of this RFC for any purpose and in particular notes that
       the decision to publish is not based on IETF review for such
       things as security, congestion control, or inappropriate
       interaction with deployed protocols.

I understand the desire not to put such negative sounding language on  
everything, and I understand the total insanity of clamming that a  
document from the "Internet Congestion Control Research Group"  
authored by Sally Floyd would have a note on that indicates it was not  
reviewed for congestion control. But that said, I do think that on  
many documents we need to be clear about the limitations if they are  
going to be RFC.

For an Independent stream Information, today we would often have:
     This memo provides information for the Internet community. It  
does not specify an Internet standard of any kind. Distribution of  
this memo is unlimited.
     This RFC is not a candidate for any level of Internet Standard.  
The IETF disclaims any knowledge of the fitness of this RFC for any  
purpose and in particular notes that the decision to publish is not  
based on IETF review for such things as security, congestion control,  
or inappropriate interaction with deployed protocols. The RFC  
Editor    has chosen to publish this document at its discretion.  
Readers of this document should exercise caution in evaluating its  
value for implementation and deployment. See RFC 3932 for more  
information.

The middle ground text that Olaf send 12/12 would result in the  
following headers on

     This memo is not an Internet Standards Track specification; <it is
      published for other purposes>.

      This memo provides information for the Internet
       community.  This memo does not specify an Internet standard of  
any
       kind.

     This document 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.  It
     is not a product of the IETF stream and is therefore not a  
candidate
     for any level of Internet Standard; see section Section 2 of  
RFCXXXX.

I think I can live with this though I find the lack of cautionary  
statements somewhat troubling. I agree the word stream is a bit weird.  
I do think it is critical that it continues to say it is not an a  
product of the IETF and not a standard.

This was a very long winded email to get to the point of, I could live  
with the Olaf middle ground text send 12/12 and I'd be happy to see  
that rephrased to get rid of the word stream. But if we want to move  
text that does not say it is "not a product of IETF", then I would be  
arguing for an IESG note closer to the current text instead of having  
no IESG note. From a point of view of please make it easy for the IESG  
to be lazy, I would clearly prefer the IESG not having to think about  
IESG notes and believe that is better for everyone from authors,  to  
stake holders in other steams, to IESG.

Thanks, Cullen