Subject: Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2009 13:00:48 +1300

This version satisfies all my concerns with previous versions. Thanks!

Regards
   Brian Carpenter

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Nov 2009 06:01:35 +0100

<http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08#section-3.2.3> 
says:

    "Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/<static-path>/rfc<rfc-no>.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Nov 2009 21:49:58 -0800

At 6:01 AM +0100 11/18/09, Julian Reschke wrote:
><http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08#section-3.2.3> says:
>

+1. "http://www.rfc-editor.org/<static-path>/rfc<rfc-no>" is just fine, and is what we agreed to before.

--Paul Hoffman, Director
--VPN Consortium

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Nov 2009 13:38:14 +0100

Julian Reschke wrote:
> ...

Hi,

in the meantime I have finished a prototype implementation of the new 
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
available from <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>, and 
requires the use of two new extension Processing Instructions to enable 
the new boilerplate:

   <?rfc-ext h-a-b="yes"?>
   <?rfc-ext consensus="no"?>

(where the first enables the new format, while the second provides the 
information about whether there was consensus, something the current 
xml2rfc format doesn't provide).

I haven't found any problems in addition to what was reported before, 
except for a trailing dot in one of the boilerplate statements, and 
cases of repeating sentence beginnings -- maybe all of this can be fixed 
during AUTH48 (although I'd prefer to see this in a new draft for 
community review).

For the record, here's a complete summary:

-- snip --
3.1.  The title page header

    <document source>  This describes the area where the work originates.
       Historically, all RFCs were labeled Network Working Group.
       "Network Working Group" refers to the original version of today's
       IETF when people from the original set of ARPANET sites and
       whomever else was interested -- the meetings were open -- got
       together to discuss, design and document proposed protocols
       [RFC0003].  Here, we obsolete the term "Network Working Group" in
       order to indicate the originating stream.

       The <document source> is the name of the RFC stream, as defined in
       [RFC4844] and its successors.  At the time of this publication,
       the streams, and therefore the possible entries are:

       *  Internet Engineering Task Force

       *  Internet Architecture Board

       *  Internet Research Task Force

       *  Independent

JRE: as discussed earlier: should this be "Independent Submission"
instead of "Independent"?

    [<RFC relation>:<RFC number[s]>]  Some relations between RFCs in the
       series are explicitly noted in the RFC header.  For example, a new
       RFC may update one or more earlier RFCs.  Currently two
       relationships are defined: "Updates", and "Obsoletes" [RFC2223].
       Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
       Other types of relationships may be defined by the RFC Editor and
       may appear in future RFCs.

JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".

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, subject to general
    review and oversight by the RFC Editor and IAB.  There is a specific
    structure defined here to ensure there is clarity about review
    processes and document types.  These paragraphs will need to be
    defined and maintained 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."

    Historic:  "This document defines a Historic Document for the
       Internet community."

JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?

       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)".

JRE: trailing dot missing in 2nd variant.

3.2.3.  Paragraph 3

JRE: please do not bake a file extension into the permanent URL (see also
<http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)

-- snip --

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Nov 2009 14:01:56 +0100

Hi,

I just created five test cases representing the appendices A.1 to A.5. 
Turns out that the text in the examples is not in sync with the 
definitions in Section 3 (see, for instance, 
<http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.rfc.hab.a2.test.xhtml>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Nov 2009 16:00:48 +0100

> Is it too late to fix this?

To illustrate the problem: for "IETF Experimental, with Consensus Call", 
we get:

"This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering Task 
Force (IETF). It represents the consensus of the IETF community..."

I think

"This document defines an Experimental Protocol for the Internet 
community. It is a product of the Internet Engineering Task Force (IETF) 
and represents the consensus of the IETF community..."

would read much better.

Best regards, Julian

---

From: RFC Editor <[email-masked]>
Date: Tue, 24 Nov 2009 17:07:34 -0800

Hi Julian,

I went through version -08 of the headers-boilerplates document and
attempted to put together all of the possible combinations of text for
the "Status of This Memo."   I believe the attached file is a complete
list of these possibilities, based on the text in Section 3.   

Please note that I have updated the URLs to match that of the existing
metadata pages that were created in response to this document
(http://www.rfc-editor.org/info/rfcXXXX).  

The RFC Editor hopes that the IAB will agree to update the URLs
(throughout) and the text in Appendix A to reflect the appropriate
text from the corresponding Stream/Status/Consensus in the attached
file during the editing process.  

Please feel free to check the attached files, as manual error is
possible.

Hope this is of some help! Thanks!

Sandy

On Tue, Nov 24, 2009 at 02:01:56PM +0100, Julian Reschke wrote:
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Nov 2009 09:32:34 +0100

Jim Schaad wrote:
> Let's just get this published and go with what we have even if it does not
> necessarily read real pretty.  The text of the strings can be updated at a
> later point by a modification of the RFC Style Guide if there are enough
> complaints about how the text looks.  Given that it is boilerplate, I
> personally don't care that it does not flow.
> 
> Jim

1) The text in the current draft is inconsistent. Please fix it. This is 
purely editorial.

2) Changing the boilerplate again adds another code path to all tools 
that need to produce it, requires additional test cases and so on (keep 
in mind that the tools we are written so that they can produce the 
correct boilerplate for historic documents as well). BTW I think we need 
a volunteer for xml2rfc.tcl to implement this anyway; it will not 
magically happen unless somebody digs into the TCL code and implements it.

Best regards, Julian

---

From: Bob Braden <[email-masked]>
Date: Thu, 26 Nov 2009 13:32:55 -0800

> personally don't care that it does not flow.
Jim,

Understood, but the RFC Editor does care how it flows.  We would like to 
get it as nearly right as possible, going out of the gate.

Bob Braden

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Nov 2009 14:10:54 -0800

Bob Braden wrote:
>> necessarily read real pretty.  

"Ready Fire Aim"  has characterized the pattern of IPR work on this topic in 
recent years, and the results have been exactly as messy as one would predict.

This is a running system.  Changes need to be made cautiously, with an eye 
towards safe and correct operations.

We -- the part of the IETF that has been imposing changes -- haven't been doing 
that very well.

We should fix that, before we blast out more problematic changes.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Nov 2009 13:21:51 +0100

> get it as nearly right as possible, going out of the gate.

For tracking purposes, I just published draft-reschke-hab-00 
(<http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html>), which 
contains the headers and boilerplates for the 19 cases Sandy has 
identified. Note that the contents for these cases is auto-generated by 
the experimental version of rfc2629.xslt.

I plan to update rfc2629.xslt and this draft as the RFC Editor 
fine-tunes the text for draft-iab-streams-headers-boilerplates. This 
will give us easy-to-read diffs on tools.ietf.org.

Best regards, Julian

---

From: Alice Hagens <[email-masked]>
Date: Tue, 24 Nov 2009 11:20:14 -0600

> Can we please recommend *not* to put a file extension into the URL?

The text can be updated - there is no file extension. The URL is of  
the form:
http://www.rfc-editor.org/<static-path>/rfc<rfc-no>

For example:
http://www.rfc-editor.org/info/rfc2026

RFC Editor/ah

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 24 Nov 2009 22:50:54 -0800

Jim

> -----Original Message-----
> From: [email-masked] [mailto:rfc-interest-
> [email-masked]] On Behalf Of Julian Reschke
> Sent: Tuesday, November 24, 2009 5:02 AM
> To: IETF discussion list; [email-masked]; xml2rfc
> Subject: [rfc-i] Important: do not publish "draft-iab-streams-headers-
> boilerplates-08" as is!
> 
> Hi,
>