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

Cullen Jennings fluffy at cisco.com
Tue Jan 13 10:09:51 PST 2009


I can live with this. I don't think further discussion is going to  
greatly change the positions of anyone so lets go with this.

On Jan 10, 2009, at 1:27 AM, Olaf Kolkman wrote:

>
>
>
>
>
> Folk,
>
> Having caught up with the whole thread I think I got a feel for  
> where consensus is going.
>
> Jari's 3 point summary is a good hook to respond to:
>
>> Our debate is fundamentally about to what extent the boilerplate  
>> needs
>> to be explicit. In particular:
>>
>> 1) Does the boilerplate explain the situation, refer to another RFC  
>> for
>> the explanation, or just state the name of the stream and leave it  
>> at that?
>>
>> 2) Does the boilerplate explicitly call out that non stds track
>> documents are not standards?
>>
>> 3) Does the boilerplate explicitly note that non-IETF documents are  
>> not
>> the product of the IETF?
>
>
> With respect to (3) my reading of where consensus is heading is that  
> non-IETF documents should not mention that they are not the product  
> of the IETF.
>
> My reading wrt (2) is that there are no objections to explicitly  
> saying that a document is not a STD track document.
>
> With respect to (1) my reading is that folk do not want a long  
> expose: crisp, clear and non-condescending are the keywords. It  
> seems that folk do not mind a reference.
>
> With that in mind I arrive at section 3.2. as included below. I also  
> included a few examples of how boilerplates will look (they will be  
> in Appendix A of the document)
>
> I realize this is a bit more verbose than what Joe Touch was  
> suggestion, but I think this level of verbosity provides a bit more  
> clarity at the cost of crispness. I guess its a value call.
>
> Please respond if you cannot consent or if you consent under a wee  
> bit of protest. A "Works For Me" response is welcome too. I plan to  
> update the draft somewhere around June 16 and then close the issue.  
> In the mean time you can use http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-iab-streams-headers-boilerplates-04.txt&url2=http://www.secret-wg.org/draft-streams-headers-boilerplates.txt 
>  to look at diffs.
>
>
> --Olaf
>
>
> ------ Start --------
> 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.
>
> 3.2.1.  Paragraph 1
>
>   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.
>
>   For 'Standards Track' documents:  This is an Internet Standards  
> Track
>      document.
>
>   For 'Best Current Practices' documents:  This memo documents an
>      Internet Best Current Practice
>
>   For other categories  This document 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>.  Initial values are:
>
>   Informational:   it is published for informational purpoases."
>
>   Historic:   it is published for historical purpoases."
>
>   Experimental:   it is published for experimental purpoases."
>
> 3.2.2.  Paragraph 2
>
>   The second 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, although there  
> is a
>   specific structure defined here to ensure there is clarity about
>   review processes and document types.  From now on, these paragraphs
>   will be defined as part of RFC stream definitions.  Initial text,  
> for
>   current streams, is provided below.
>
>   The paragraph may include some text that is specific to the initial
>   document category, as follows: when a document is Experimental or
>   Historic the second paragraph opens with:
>
>   Experimental:  "This document defines an Experimental Protocol for
>      the Internet community.  Discussion and suggestions for
>      improvement are requested."
>
>   Historic:  "This document defines a Historic Document for the
>      Internet community.
>
>   The text that follows is stream dependent -- these are initial  
> values
>   and may be updated by stream definition document updates.
>
>   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: "It 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.
>
>   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.
>
>      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 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.
>
>   For non-IETF stream a reference to Section 2 of this RFC is added
>   with the following sentence: "Documents approved for publication by
>   the [stream approver -- currently, one of: "IAB", "IRSG", or "RFC
>   Editor"] are not a candidate for any level of Internet Standard; see
>   Section 2 of RFCXXXX."
>
> 3.2.3.  Paragraph 3
>
>   The boilerplate ends with a reference to where further relevant
>   information can be found: "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." the
>   exact wording is subject to change by the RFC Editor.
>
> 3.2.4.  Noteworthy
>
>   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.
>
> 3.3.  Additional Notes
>
>   Exceptionally, a review and publication process may prescribe
>   additional notes that will appear as labelled notes after the  
> "Status
>   of This Memo".
>
>   While this has been a common feature of recent RFCs, it is the goal
>   of this document to make the overall RFC structure adequately clear
>   to remove the need for such notes, or at least make their usage  
> truly
>   exceptional.
> ----- END ------------
>
>
>
> The Examples:
>
>
> Appendix A.  Some Example 'Status of this Memo' boileplates
>
> A.1.  IETF Standards Track
>
>   The boilerplate for a Standards Track document that (by definition)
>   has been subject to an IETF consensus call
>
> ------------------------------------------------------------------------
> Status of this Memo
>
>    This is an Internet Standards Track document.
>
>    This document is a product of the Internet Engineering Task Force
>    (IETF).  It represents a consensus of the IETF community.  It has
>    received public review and has been approved for publication by
>    the Internet Engineering Steering Group.
>
>    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.
> ------------------------------------------------------------------------
>
> A.2.  IETF Experimental
>
>   The boilerplate for an Experimental document that has been subject  
> to
>   an IETF consensus call
>
> ------------------------------------------------------------------------
> Status of this Memo
>
>    This document is not an Internet Standards Track specification; it
>    has been published for Experimental purposes.
>
>    This document defines an Experimental Protocol for the Internet
>    community.  Discussion and suggestions for improvement are
>    requested.  This document is a product of the Internet Engineering
>    Task Force (IETF).  It represents a consensus of the IETF
>    community.  It has received public review and has been approved
>    for publication by the Internet Engineering Steering Group.
>
>    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.
> ------------------------------------------------------------------------
>
> A.3.  IAB Informational
>
>   The boilerplate for an Informational IAB document
>
> ------------------------------------------------------------------------
> Status of this Memo
>
>    This document is not an Internet Standards Track specification; it
>    has been published for Informational purposes.
>
>    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. Documents approved for
>    publication by IAB are not a candidate for any level of Internet
>    Standard; see Section 2 of RFCXXXX."
>
>    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.
> ------------------------------------------------------------------------
>
> A.4.  IAB Informational
>
>   The boilerplate for an Informational IAB document
>
> ------------------------------------------------------------------------
> Status of this Memo
>
>    This document is not an Internet Standards Track specification; it
>    has been published for Informational purposes.
>
>    This 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.  Documents approved for
>    publication by RFC Editor are not a candidate for any level of
>    Internet Standard; see Section 2 of RFCXXXX."
>
>    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.
> ------------------------------------------------------------------------
>
> A.5.  IRTF Experimental
>
>   The boilerplate for an Experimental document that has been produced
>   by the IRTF and for which there was no RG consensus.  This variation
>   is the most verbose boilerplate in the current set.
>
>
>
>
>
>
>
> Daigle, et al.            Expires July 14, 2009                [Page  
> 13]
> Internet-Draft     RFC Streams, Headers, Boilerplates       January  
> 2009
>
>
> ------------------------------------------------------------------------
> Status of this Memo
>
>    This document is not an Internet Standards Track specification; it
>    has been published for Experimental purposes.
>
>    This document defines an Experimental Protocol for the Internet
>    community.  Discussion and suggestions for improvement are
>    requested. 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 RFC represents the individual
>    opinion(s) of one or more members of the BLAFOO Research Group of
>    the Internet Research Task Force (IRTF).  Documents approved for
>    publication by IRTF are not a candidate for any level of Internet
>    Standard; see Section 2 of RFCXXXX."
>
>
>    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.
> ------------------------------------------------------------------------
>
>
>
>
> -----------------------------------------------------------
> Olaf M. Kolkman                        NLnet Labs
>                                       Science Park 140,
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
>
> NB: The street at which our offices are located has been
> renamed to the above.
>
>
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest



More information about the rfc-interest mailing list