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

Andrew G. Malis agmalis at gmail.com
Mon Jan 12 08:34:57 PST 2009


Olaf,

Looks great. One minor nit: The header and first line in section A.4
is wrong, and should read:

"A.4.  RFC Editor Informational

  The boilerplate for an Informational RFC Editor document"

Looks like you just had a copy and paste bug.

Other than that, this works for me.

Cheers,
Andy


On Sat, Jan 10, 2009 at 3:27 AM, Olaf Kolkman <olaf at nlnetlabs.nl> 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