Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[RFC Editor]

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/rfc).  

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:
> 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, 
> ).
> 
> Best regards, Julian
> 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >>
> >> 
> >>  
> >> 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//rfc.html"
> >>
> >> Can we please recommend *not* to put a file extension into the URL?
> >>
> >> BR, Julian
> >> ...
> > 
> > Hi,
> > 
> > in the meantime I have finished a prototype implementation of the new 
> > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
> > available from , and 
> > requires the use of two new extension Processing Instructions to enable 
> > the new boilerplate:
> > 
> >   
> >   
> > 
> > (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
> > 
> >  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  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"?
> > 
> >[:]  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 parag

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Bob Braden]

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
  

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


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Dave CROCKER]

Bob Braden wrote:

Jim Schaad wrote:
Let's just get this published and go with what we have even if it does not 
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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Bob Braden wrote:

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


For tracking purposes, I just published draft-reschke-hab-00 
(), 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Alice Hagens]

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//rfc

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

RFC Editor/ah

On Nov 24, 2009, at 7:01 AM, Julian Reschke wrote:


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


Best regards, Julian

Julian Reschke wrote:

Julian Reschke wrote:




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//rfc.html"

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

BR, Julian
...


Hi,

in the meantime I have finished a prototype implementation of the new
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is
available from ,  
and
requires the use of two new extension Processing Instructions to  
enable

the new boilerplate:

  
  

(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

 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  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"?

   [:]  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
   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  Research
  Group of the Internet Research Task Force (IRTF)".

JRE: trailing dot missing in 2nd variant.


3.2.3.  Paragraph 3

   "Information about the current status of this document, any  
errata,

   and how t

RE: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Jim Schaad]

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


> -Original Message-
> From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest-
> boun...@rfc-editor.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 24, 2009 5:02 AM
> To: IETF discussion list; rfc-inter...@rfc-editor.org; xml2rfc
> Subject: [rfc-i] Important: do not publish "draft-iab-streams-headers-
> boilerplates-08" as is!
> 
> 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,
>  b.a2.test.xhtml>).
> 
> Best regards, Julian
> 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >>
> >>  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//rfc.html"
> >>
> >> Can we please recommend *not* to put a file extension into the URL?
> >>
> >> BR, Julian
> >> ...
> >
> > Hi,
> >
> > in the meantime I have finished a prototype implementation of the new
> > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is
> > available from ,
> and
> > requires the use of two new extension Processing Instructions to
> enable
> > the new boilerplate:
> >
> >   
> >   
> >
> > (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
> >
> >  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  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"?
> >
> >[:]  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 

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Julian Reschke wrote:

Bob Braden wrote:

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


For tracking purposes, I just published draft-reschke-hab-00 
(), 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.

...


In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, 
and I have updated my document with the current changes; see 
, in particular 
 (change 
list) and  
(diffs).


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Julian Reschke wrote:

...
In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, 
and I have updated my document with the current changes; see 
, in particular 
 (change 
list) and  
(diffs).

...


I just heard that the RFC 5741-to-be is not going to be fixed with 
respect to the stutter in the boilerplate, such as in:


-- snip --
3.1.6.2. Text of 'Status Of This Memo'


   This document is not an Internet Standards Track specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   This document is a product of the Internet Engineering Task Force
   (IETF).  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents approved by the
   IESG are candidate for any level of Internet Standards; see Section 2
   of RFC 5741.

   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/info/rfc.
-- snip --

(see ).

This problem was reported over three weeks ago. Are we really incapable 
to fix something simple like that within three weeks?



Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Olaf Kolkman]

Julian,

You wrote:
> 
> This problem was reported over three weeks ago. Are we really incapable 
> to fix something simple like that within three weeks?


We are at a point where making trivial changes to headers and boilerplates 
leads to discussion about more substantive matters and causes even more delay, 
folk wanted it done. It is unfortunate that the stutter (I agree its there and 
that its ugly) remains in the document. 

Headers and boilerplates lives on this tangent between community wishes, RFC 
oversight, and RFC Editor series continuity and style. Having learned from 
getting H&B done, I believe that in the future such efforts should be pulled by 
the RSE, with IAB oversight and not by the IAB with RFC-Editor input.


FWIW, the document allows the RFC editor  some headway in maintaining the 
language in the style guide.

--Olaf

[top-post, full context below.]





On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote:

> Julian Reschke wrote:
>> ...
>> In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, 
>> and I have updated my document with the current changes; see 
>> , in particular 
>>  (change 
>> list) and  
>> (diffs).
>> ...
> 
> I just heard that the RFC 5741-to-be is not going to be fixed with 
> respect to the stutter in the boilerplate, such as in:
> 
> -- snip --
> 3.1.6.2. Text of 'Status Of This Memo'
> 
> 
>This document is not an Internet Standards Track specification; it is
>published for the historical record.
> 
>This document defines a Historic Document for the Internet community.
>This document is a product of the Internet Engineering Task Force
>(IETF).  It has been approved for publication by the Internet
>Engineering Steering Group (IESG).  Not all documents approved by the
>IESG are candidate for any level of Internet Standards; see Section 2
>of RFC 5741.
> 
>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/info/rfc.
> -- snip --
> 
> (see ).
> 
> This problem was reported over three weeks ago. Are we really incapable 
> to fix something simple like that within three weeks?
> 
> 
> Best regards, Julian
> ___
> rfc-interest mailing list
> rfc-inter...@rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

 

Olaf M. KolkmanNLnet Labs
   Science Park 140, 
http://www.nlnetlabs.nl/   1098 XG Amsterdam

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Brian E Carpenter]

> FWIW, the document allows the RFC editor  some headway in maintaining the 
> language in the style guide.

Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate,
exactly as for the Trust-maintained boilerplate.

For now, there are indeed weasel words such as:
  "However, this is not
   intended to specify a single, static format.  Details of formatting
   are decided by the RFC Editor."

  "These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below."

I think this gives the RSE, in conjunction with the tools maintainers,
reasonable flexibility.

I also note:

  "The changes introduced by this memo should be implemented as soon as
   practically possible after the document has been approved for
   publication."

which is presumably intended to allow the tools some time to catch up,
again requiring RSE/tools coordination.

Regards
   Brian Carpenter


On 2009-12-22 23:50, Olaf Kolkman wrote:
> 
> Julian,
> 
> You wrote:
>> This problem was reported over three weeks ago. Are we really incapable 
>> to fix something simple like that within three weeks?
> 
> 
> We are at a point where making trivial changes to headers and boilerplates 
> leads to discussion about more substantive matters and causes even more 
> delay, folk wanted it done. It is unfortunate that the stutter (I agree its 
> there and that its ugly) remains in the document. 
> 
> Headers and boilerplates lives on this tangent between community wishes, RFC 
> oversight, and RFC Editor series continuity and style. Having learned from 
> getting H&B done, I believe that in the future such efforts should be pulled 
> by the RSE, with IAB oversight and not by the IAB with RFC-Editor input.
> 
> 
> FWIW, the document allows the RFC editor  some headway in maintaining the 
> language in the style guide.
> 
> --Olaf
> 
> [top-post, full context below.]
> 
> 
> 
> 
> 
> On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote:
> 
>> Julian Reschke wrote:
>>> ...
>>> In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, 
>>> and I have updated my document with the current changes; see 
>>> , in particular 
>>>  (change 
>>> list) and  
>>> (diffs).
>>> ...
>> I just heard that the RFC 5741-to-be is not going to be fixed with 
>> respect to the stutter in the boilerplate, such as in:
>>
>> -- snip --
>> 3.1.6.2. Text of 'Status Of This Memo'
>>
>>
>>This document is not an Internet Standards Track specification; it is
>>published for the historical record.
>>
>>This document defines a Historic Document for the Internet community.
>>This document is a product of the Internet Engineering Task Force
>>(IETF).  It has been approved for publication by the Internet
>>Engineering Steering Group (IESG).  Not all documents approved by the
>>IESG are candidate for any level of Internet Standards; see Section 2
>>of RFC 5741.
>>
>>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/info/rfc.
>> -- snip --
>>
>> (see ).
>>
>> This problem was reported over three weeks ago. Are we really incapable 
>> to fix something simple like that within three weeks?
>>
>>
>> Best regards, Julian
>> ___
>> rfc-interest mailing list
>> rfc-inter...@rfc-editor.org
>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 
>  
> 
> Olaf M. KolkmanNLnet Labs
>Science Park 140, 
> http://www.nlnetlabs.nl/   1098 XG Amsterdam
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Russ Housley]

Dave:

I agree with Birain's assessment. The RFC Editor can handle this 
issue without delaying publication of the document.


Russ

At 02:39 PM 12/22/2009, Dave CROCKER wrote:

Brian,

This seems worth being a bit pedantic about, to make sure we all 
share the same
understanding:  I take your interpretation to mean that the RFC 
Editor can, on
their own initiative, fix the problem(s) that Julan has raised and 
that it does

not require changes to the about-to-be-published document.

Is that correct?  Do others agree?  (I hope so.)

d/

On 12/22/2009 11:23 AM, Brian E Carpenter wrote:
>> FWIW, the document allows the RFC editor  some headway in 
maintaining the language in the style guide.

...
> For now, there are indeed weasel words such as:
>"However, this is not
> intended to specify a single, static format.  Details of formatting
> are decided by the RFC Editor."
>
>"These paragraphs will need to be
> defined and maintained as part of RFC stream definitions.  Initial
> text, for current streams, is provided below."
>
> I think this gives the RSE, in conjunction with the tools maintainers,
> reasonable flexibility.



--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
rfc-interest mailing list
rfc-inter...@rfc-editor.org
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Bob Hinden]

On Dec 22, 2009, at 12:08 PM, Russ Housley wrote:

> Dave:
> 
> I agree with Birain's assessment. The RFC Editor can handle this issue 
> without delaying publication of the document.

+1

Bob


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Jari Arkko]

All,


I agree with Birain's assessment. The RFC Editor can handle this issue without 
delaying publication of the document.



+1
  


Me too. Publish the RFC. Please.

Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Olaf Kolkman]

On Dec 22, 2009, at 8:39 PM, Dave CROCKER wrote:

> Brian,
> 
> This seems worth being a bit pedantic about, to make sure we all share the 
> same understanding:  I take your interpretation to mean that the RFC Editor 
> can, on their own initiative, fix the problem(s) that Julan has raised and 
> that it does not require changes to the about-to-be-published document.
> 
> 
> Is that correct?  Do others agree?  (I hope so.)
> 


FWIW, I do. As long as those changes are stylistic, editorial, and not so 
substantive that they cause the various streams to be uneasy with those changes.


And in reply to Brian:
> Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate,
> exactly as for the Trust-maintained boilerplate.

That is what I intended with:  I believe that in the future such efforts should 
be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor 
input




--Olaf (personal title)



> d/
> 
> On 12/22/2009 11:23 AM, Brian E Carpenter wrote:
>>> FWIW, the document allows the RFC editor  some headway in maintaining the 
>>> language in the style guide.
> ...
>> For now, there are indeed weasel words such as:
>>   "However, this is not
>>intended to specify a single, static format.  Details of formatting
>>are decided by the RFC Editor."
>> 
>>   "These paragraphs will need to be
>>defined and maintained as part of RFC stream definitions.  Initial
>>text, for current streams, is provided below."
>> 
>> I think this gives the RSE, in conjunction with the tools maintainers,
>> reasonable flexibility.
> 
> 
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net

 

Olaf M. KolkmanNLnet Labs
   Science Park 140, 
http://www.nlnetlabs.nl/   1098 XG Amsterdam

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Jim Schaad]

I have long held this view

Jim


> -Original Message-
> From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest-
> boun...@rfc-editor.org] On Behalf Of Bob Hinden
> Sent: Tuesday, December 22, 2009 12:41 PM
> To: Russ Housley
> Cc: Olaf Kolkman; xml2...@lists.xml.resource.org; IETF discussion list;
> Bob Hinden; rfc-inter...@rfc-editor.org; dcroc...@bbiw.net
> Subject: Re: [rfc-i] Important: do not publish "draft-iab-streams-
> headers-boilerplates-08" as is!
> 
> 
> On Dec 22, 2009, at 12:08 PM, Russ Housley wrote:
> 
> > Dave:
> >
> > I agree with Birain's assessment. The RFC Editor can handle this
> issue without delaying publication of the document.
> 
> +1
> 
> Bob
> 
> 
> 
> ___
> rfc-interest mailing list
> rfc-inter...@rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf