[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