[rfc-i] Fwd: Comment on headers-and-boilerplates
fluffy at cisco.com
Wed Dec 17 14:22:21 PST 2008
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.
More information about the rfc-interest