[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