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

Bob Hinden bob.hinden at nokia.com
Mon Dec 15 16:03:59 PST 2008


Olaf,

> I realize I am in the awkward position of holding the pen and  
> moderating the discussion I am trying to thread the line of holding  
> the pen and having an own (sometimes strong) opinion carefully.  
> Having said that, my comments are in-line.


Thanks, I understand your position.

>>>
>>
>> I would add something like:
>>
>>    If this is an approved IETF standards track document, an  
>> additional
>>    sentence should be added:  "This document is an IETF Standard."
>>
>> The one that is an IETF standard should say so very clearly, as  
>> opposed to the ones that are not having to include the negative.
>
> The first and the second paragraph of the Status of this Memo  
> section already clarify this.
>
> For a Internet Standards track document they read:
> ---
> Status of this Memo
>
> This memo is an Internet Standards Track document.
> This document specifies an Internet standards track protocol for the  
> Internet community. Please see the "Updates to the RFC" section of  
> this document for information on where to find the status of this  
> document and the availability of errata for this memo.
> ----
>
> In all honesty, I feel very reluctant to reopen those paragraphs;  
> this document has past all review and approval steps. Also, note  
> that "IETF Standard" has no particular meaning, "Internet Standards  
> Track" does.
>
> As Leslie argued before... adding "This is an Internet Standard" to  
> the 3rd paragraph is repetitive.


I agree that it doesn't need to say it is an Internet Standard  
multiple times in the boiler plate.


> As for your suggestion:
>>
>> s/ 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 observe that your suggestion removes the reference to section 2 of  
> RFC XXXX (section 2 of what is not the streams, headers, and  
> boilerplates) which intends to give readers who want to know the  
> details a reference. That is a substantive change: that reference  
> was there by careful design removing the reference impacts the  
> usefulness of the document.
>
>
> Have a look at the current version:
> http://tools.ietf.org/id/draft-iab-streams-headers- 
> boilerplates-04.txt section 3.2
>
> The structure of the 3rd paragraph in the status of this memo is for  
> non IETF-stream
>
> [this document is] reviewed by <bla-foo> therefore not a candidate  
> for any level of Internet Standard; see section 2 of RFC XXX.
>
> Except for the IRTF stream where it says:
> [this document is] reviewed by the IRTF.  It is not a product of the  
> IETF and is therefore not a candidate for any level of Internet  
> Standard;
>
> Jari's original question was, AFAIU: "why this inconsistency"?
>
> My strawman was to use the form:
>
> [this document is] reviewed by <bla-foo>.  It is not a product of  
> the IETF stream and is therefore not a candidate for any level of  
> Internet Standard;
>
> Your suggestion is:
> [this document is] reviewed by <bla-foo>. [end]
>
>
> I think that bringing all the above in line we end up with a  
> statement similar to this for all non-IETF streams.
>
> [this document is] reviewed by <bla-foo> therefore not a candidate  
> for any level of Internet Standard; see section 2 of RFC XXX.

As you I think you know from my earlier email, I don't think the text  
of the form "It is not a product of the IETF stream and is therefore  
not a candidate for any level of Internet Standard;" should be there.

I don't have any objections to including a reference to RFCXXXX (aka  
draft-iab-streams-headers-boilerplates-04.txt) and agree it is a good  
idea to keep this reference as it explains the thinking behind the  
headers and boilerplate.

Note, as I read <draft-iab-streams-headers-boilerplates-04.txt> again,  
I think it is very IETF centric.  That is, it looks at the world as  
the IETF as the center, as opposed to looking at all of the streams  
and describing them independently.  I could propose changes to fix  
this.  I think this draft is needed to describe the reasons for  
changing the headers and boilerplate, but I think it needs to  
represent the streams more evenly.  I note that the text from the  
Introduction:

   "Chiefly, there is a requirement that RFCs published as part of the  
IETF's review process not be easily confused with RFCs that may have  
had a very different review and approval process."
I don't think this problem is as serious to justify saying the other  
streams are not IETF standards.  Further, the confusion about the  
meaning of an RFC can not be fixed by adding this text.  If it could,  
the problem wouldn't exist.


>>> Note that standards track documents can only be published through  
>>> the IETF stream.
>>> Therefore any non-IETF stream contains the following  
>>> clarification: It is not a product
>>> of the IETF stream and is therefore not a candidate for any level of
>>> Internet Standard". That sentence also implies that the document  
>>> has not been
>>> approved for publication by the Internet Engineering Steering  
>>> Group after an IETF consensus
>>> process."
>>
>> Remove the above paragraph.  I don't think it is necessary.
>>
>
> This was only a straw-man, to try and clarify why the word "stream"  
> is used. I'm not attached to it. Its main need was to suggest a  
> sensible default for when new streams are defined in the future.

I don't think it too big a deal, but it is another example of the IETF  
centric view in this draft.

Thanks,
Bob






More information about the rfc-interest mailing list