[rfc-i] Fwd: Comment on headers-and-boilerplates
olaf at NLnetLabs.nl
Fri Dec 19 02:30:41 PST 2008
I am in listening mode, not ready yet to call consensus on this issue,
in part because (full disclosure) I think there is value in clarifying
what is and what is not IETF reviewed. What I am afraid of is that if
there is no such clarification there might be more IESG notes that are
far less precisely worded than that what we can achieve here.
While rfc3932bis gets rid of the mandatory IESG note _because_ of the
definition in this document
"In exceptional cases, when the relationship of the document to the
IETF standards process might be unclear, the IESG response may be
accompanied by a clarifying IESG note and a request that the RFC
Editor include the IESG note in the document if the document is
This is where Cullen can clarify: What kind of IESG note would you
think would appear, under which circumstances, and with what frequency.
Happy season &c
PS: Rob, thanks for suggesting text.
FWIW: the use of the term memo is to bring it in use with the title of
the section. I don't think
there is substantive differences between the use of 'this document' or
'this memo', I take guidance from native speakers here.
[top-post, no comments below]
On Dec 18, 2008, at 10:23 PM, Rob Sayre wrote:
> On 12/18/08 2:24 AM, Cullen Jennings wrote:
>> We are talking about document quality and a brand reflection of
>> that. I would be the first to agree that there are awful documents
>> that came through the IETF stream and that many good documents have
>> come though other streams. However, what people are looking for is
>> the understanding of the process that leads to quality that is in
>> the IETF stream - I'm not saying better or worse, just a
>> consistency of the quality.
> Disagree--I wrote that the quality of the IETF stream varies wildly.
>> The quality control process of this stream is widely understood and
>> very transparent.
> Disagree. If that were true, we wouldn't be having this discussion.
> Unlike some other people, I am fine with one sentence along the
> lines of
> "This document does not specify an Internet standard of any kind."
> on all non-standards track documents. That seems very clear to me.
> In other words, I think your point 2:
> "I want to differentiate the breadth and type of review that a
> document received."
> is superfluous, given a sentence stating that a document is not a
> standard. The text that Olaf sent on 12/12 repeats that the document
> is not a standard 3 times. This repetition is unwarranted. Is there
> a desire for the text to be long, so it seems more serious? (honest
> Below is my proposal for an Independent stream document. It is drawn
> from Olaf's 12/12 text. It covers the fact the document is not a
> standard, and points out that there are no assertions of value.
> This document does not specify an Internet standard of any
> kind; <it is published for other purposes>.
> The RFC Editor has chosen to publish this document at its
> discretion and makes no statement about its value for
> implementation or deployment. See Section 2 of RFCXXXX.
> Is this text insufficient in some way?
> Here are the cuts I made to Olaf's proposed text:
> cut: "This memo is not an Internet Standards Track
> add: "This document does not specify an Internet standard of
> any kind;"
> rationale: The phrasing I pulled from the second into the first
> paragraph is clearer for reader unfamiliar with the RFC series.
> cut: "This memo provides information for the Internet
> community. This memo does not specify and Internet standard of any
> rationale: Covered by status Informational, and the first paragraph.
> Also uses the term memo instead of document, for no apparent reason.
> cut: "This document is a contribution to the RFC Series,
> independently of any other RFC stream."
> rationale: First portion is obvious, second portion is inaccurate/
> cut: "It is not a product of the IETF stream and is therefore
> not a candidate for any level of Internet Standard;"
> rationale: Redundant, misleading (IETF stream documents might not be
> standards track), negative.
> - Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20081219/bca37b64/PGP.bin
More information about the rfc-interest