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

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

I agree there is utility in stating whether a doc is standards track or
not standards track.

I don't agree that there is utility in explaining how each document has
been vetted - or not. Many independent-stream docs have been reviewed
more throughly and competently than some in the IETF stream. There is no
useful information in explaining the details of what makes a document
part of a given stream.

In either case, we don't need to explain the details in each document
(of how it is reviewed, or what each waypoint in the standards track
process means); we can easily point to other doc(s) that provide
details, just as other docs now provide the details of IPR issues

Joe

Cullen Jennings wrote:
> 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 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklJmy4ACgkQE5f5cImnZru/NwCeJgqa31qm4usRK6NNMCNnmdz3
ef4AnRcqSLrQURkK451C9pRoUv429sQ+
=TFpf
-----END PGP SIGNATURE-----