[rfc-i] Fwd: Comment on headers-and-boilerplates
touch at ISI.EDU
Wed Dec 17 16:37:02 PST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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
> 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
> for any level of Internet Standard; see section Section 2 of
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rfc-interest