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

Leslie Daigle leslie at thinkingcat.com
Mon Dec 8 10:45:44 PST 2008


So, what is "the IETF"?  At different times, and for different purposes, 
it refers either to the IETF standards process, or  a loose 
confederation of organizations that play in this space.

To rationalize these texts so that they are all aligned, I would suggest:

1/ The text in the IRTF Stream header ("It is not a product of the 
IETF") is wrong.  At most, it should be "It is not a product of an IETF 
WG or IESG approved activity".  Or, "It is not a product of the IETF 
Standards Process".  Or, nothing (see below).

2/ The text in the IAB Stream header should be aligned with the IRTF 
text, as well.

3/ It should be clear(er) what is expected for any potential future RFC 
Stream.


That is -- if the point of having additional text in the Independent 
Stream is to make it very plain that it is _independent_, then it is the 
only stream that really needs to say "This is not a product of the 
IETF"; and the text should be removed from the IRTF Stream; the IRTF is 
not completely independent of the IETF general process.

If the point is to make it plain that IRTF and Independent (and IAB) 
Stream documents are not products of the IETF standards process -- look 
at the headers in their collective entirety, not just the 
stream-specific stuff.  And note that we are already getting heavily 
redundant to the point of obscuring the message.  For example, an 
Independent document (which can only be Informational or Experimental) 
is slated to read:


	STATUS OF THIS MEMO

	This memo is not an Internet Standards Track specification,
	it is published for informational 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 therefore not a candidate for any level
	of Internet Standard; see section Section 2 of RFCXXXX.


How is this not clear that it is not a product of the IETF?  How does 
mentioning the IETF help?

For reference, this is what an IRTF header is currently slated to look like:


	STATUS OF THIS MEMO

	This memo is not an Internet Standards Track specification,
	it is published for informational purposes.

	This memo provides information for the Internet community.
	This memo does not specify an Internet standard of any kind.

	This document is a product of the Internet Research
	Task Force (IRTF).  The IRTF publishes the results of Internet-
	related research and development activities.  These results
	might not be suitable for deployment.  This document has
	been approved for publication by the IRSG.  It is not a
	product of the IETF and is therefore not a candidate for any
	level of Internet Standard; see section Section 2 of RFCXXXX.

In addition a sentence indicating the consensus base within the
IRTF may be added:
	"This RFC represents the consensus of the
	<insert_name> Research Group of the Internet Research Task Force
	(IRTF)." or alternatively "This RFC represents the individual
	opinion(s) of one or more members of the <insert_name> Research
	Group of the Internet Research Task Force (IRTF)".


THREE TIMES it says it's not an Internet Standard.



Yes, rationalization of these texts may be in order.  I don't agree that 
shoe-horning extra phrases  about "not IETF" is the right direction.

Leslie.


[Section 3.2, from draft-iab-streams-headers-boilerplates-03:]
> 3.2.  The Status of this Memo
> 
>    The "Status of This Memo" describes the category of the RFC,
>    including the distribution statement.  This text is included
>    irrespective of the source stream of the RFC.
> 
>    From now on, the "Status of This Memo" will start with a single
>    sentence describing the status.  It will also include a statement
>    describing the stream-specific review of the material (which is
>    stream-dependent).  This is an important component of status, insofar
>    as it clarifies the breadth and depth of review, and gives the reader
>    an understanding of how to consider its content.
> 
>    The first paragraph of the Status of this Memo section contains a
>    single sentence, clearly standing out.  It depends on the category of
>    the document.
> 
>       This memo is an Internet Standards Track document.
> 
>       This memo documents an Internet Best Current Practice
> 
>       This memo is not an Internet Standards Track specification, <it is
>       published for other purposes>.
> 
>    For Informational, Experimental, Historic and future categories of
>    RFCs, the RFC editor will maintain an appropriate text for <it is
>    published for other purposes>.  For example, with an Informational
>    document this could read "it is published for informational
>    purposes".
> 
>    The second paragraph contains text as follows that is specific to the
>    initial category:
> 
>    Standards Track:  "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."
> 
>    Best Current Practice:  "This document specifies an Internet Best
>       Current Practices 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."
> 
> 
> 
> 
> 
> Daigle, et al.           Expires April 23, 2009                 [Page 6]
> 
>  
> Internet-Draft     RFC Streams, Headers, Boilerplates       October 2008
> 
> 
>    Experimental:  "This memo defines an Experimental Protocol for the
>       Internet community.  This memo does not specify an Internet
>       standard of any kind.  Discussion and suggestions for improvement
>       are requested."
> 
>    Informational:  "This memo provides information for the Internet
>       community.  This memo does not specify an Internet standard of any
>       kind. "
> 
>    Historic:  "This memo defines a Historic Document for the Internet
>       community.  It does not specify an Internet standard of any kind."
> 
>    Note that the texts in paragraph 1 and 2 of the boilerplate indicate
>    the initial status of a document.  During their lifetime documents
>    can change status to e.g.  Historic.  This cannot be reflected in the
>    document itself and will need be reflected in the information refered
>    to in Section 3.4.
> 
>    The third paragraph of the "Status of This Memo" will now include a
>    paragraph describing the type of review and exposure the document has
>    received.  This is defined on a per-stream basis.  From now on, these
>    paragraphs will be defined as part of RFC stream definitions.
> 
>    The following texts may be updated if the stream definitions are
>    updated, but initial paragraphs for the existing streams are:
> 
>    IETF Stream:  "This document is a product of the Internet Engineering
>       Task Force (IETF). "
> 
>       If there has been an IETF consensus call per IETF process, an
>       additional sentence should be added: "This document represents a
>       consensus of the IETF community.  It has received public review
>       and has been approved for publication by the Internet Engineering
>       Steering Group."
> 
>    IAB Stream:  "This document is a product of the Internet Architecture
>       Board (IAB), and represents information that the IAB has deemed
>       valuable to provide for permanent record.  This document has been
>       approved for publication by the IAB and is therefore not a
>       candidate for any level of Internet Standard; see section
>       Section 2 of RFCXXXX."
> 
>    IRTF Stream:  "This document is a product of the Internet Research
>       Task Force (IRTF).  The IRTF publishes the results of Internet-
>       related research and development activities.  These results might
>       not be suitable for deployment.  This document has been approved
>       for publication by the IRSG.  It is not a product of the IETF and
>       is therefore not a candidate for any level of Internet Standard;
> 
> 
> 
> Daigle, et al.           Expires April 23, 2009                 [Page 7]
> 
>  
> Internet-Draft     RFC Streams, Headers, Boilerplates       October 2008
> 
> 
>       see section Section 2 of RFCXXXX."
> 
>       In addition a sentence indicating the consensus base within the
>       IRTF may be added: "This RFC represents the consensus of the
>       <insert_name> Research Group of the Internet Research Task Force
>       (IRTF)." or alternatively "This RFC represents the individual
>       opinion(s) of one or more members of the <insert_name> Research
>       Group of the Internet Research Task Force (IRTF)".
> 
>    Independent Stream:  "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
>       therefore not a candidate for any level of Internet Standard; see
>       section Section 2 of RFCXXXX."





Olaf Kolkman wrote:
> 
> 
> [Forwarded with permission]
> 
> As for the question below, it was neither oversight nor conscious 
> decision, it takes consensus on the list to reach the latter.
> 
> I'd like to draw conclusion in about a week from now, silence will be 
> interpreted as consent for the proposed edit.
> 
> --Olaf
> 
> 
> Begin forwarded message:
> 
>> From: Jari Arkko <jari.arkko at piuha.net>
>> Date: December 4, 2008 7:11:57 PM GMT+01:00
>> To: IAB <iab at iab.org>
>> Cc: IESG <iesg at ietf.org>
>> Subject: Comment on headers-and-boilerplates
>>
>> Dear IAB,
>>
>> The IESG reviewed RFC 3932bis document in our telechat today. Some of 
>> the discussion made us look again at headers-and-boilerplates in detail.
>>
>> My assumption had been that for non-IETF documents, the boilerplate 
>> text would be saying that the document is (a) not a candidate for an 
>> Internet standard and (b) that the document is not a product of the 
>> IETF. We used the IRTF template as an example in our discussion. But 
>> then later I was surprised to find out that for the independent 
>> stream, it only says (a), not (b). We were wondering if this is an 
>> oversight or a conscious decision.
>>
>> I would like to see both parts there, actually. This was the opinion 
>> from everyone on the call as well*.
>>
>> If you agree, is there time to change the boilerplates document? I am 
>> referring to the last paragraph in Section 3.2. One possible way to 
>> change it would be
>>
>> OLD:
>> It is therefore not a candidate for any level of Internet Standard
>> NEW:
>> It is therefore not a product of the IETF and not a candidate for
>> any level of Internet Standard
>>
>> Jari
>>
>> *) There were two ADs who had other comments on the 3932bis & 
>> boilerplate changes. They may be contacting the IAB as well, 
>> individually.
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------


More information about the rfc-interest mailing list