[rfc-i] headers and boilerplates last minute proposal

[SM]

Hi Leslie,
At 16:38 07-04-2009, Leslie Daigle wrote:
> > 3.  RFC Structural Elements
>
>OLD (-07) TEXT:
><empty>
>
>NEW TEXT:
>
>This section describes the elements that are commonly found in RFCs
>published today.  For the sake of clarity, this document specifies the
>elements precisely as a specification.  However, this is not intended to
>cast the current format in stone.  Details of formatting are decided by
>the RFC Editor.  Substantive changes to the header and boilerplate
>structure and content may be undertaken in the future, and are subject
>to general oversight and review by the IAB.

Quoting Section 6 of draft-iab-streams-headers-boilerplates-07:

   "The RFC Editor is responsible for maintaining the consistency of the
    RFC series.  To that end the RFC Editor maintains a style manual."

The last two sentences, taken together, reduces the role of RFC 
Editor to decisions about "details of formatting".  It is also 
inconsistent with Items 5 and 8 of Section 3.1 of 
draft-iab-rfc-editor-model-04.  One of the responsibilities of the 
RFC Series Editor (see -rfc-editor-model) is to:

    "Taking proposed changes to the community, and work with the IAB
     so that the IAB can ensure that there is sufficient community
     review before the policy is adopted."

You could change the last sentence and leave it to the above 
paragraph in the rfc-editor-model to cover oversight and review by 
the IAB.  One possible issue is that the quoted paragraph mentions 
that only policy is subject to review.  Is the RFC Style Manual a 
policy matter?  I don't think so.  The review by the IAB could be 
covered by amending Item 3 of Section 3.1 of the rfc-editor-model.  I 
think it's better to have the structure and content separate (of a 
RFC) in one document and have the roles and responsibilities in a 
different document.

I suggest:

   This section describes the elements that are commonly found in RFCs
   published today.  For the sake of clarity, this document specifies the
   elements precisely as a specification.  However, this is not intended to
   cast the current format in stone.  Details of formatting are decided by
   the RFC Editor.  Changes to the header and boilerplate structure and content
   may be undertaken in the future subject to Internet community review.

It is implied that the IAB can ensure that there is adequate review.

>OLD (-07) text:
>
> >       Other types of relations may be defined elsewhere.
>
>NEW text:
>
>Other types of relationships may be defined by the RFC Editor and may
>appear in future RFCs.

How about leaving the definition to the RFC Style Manual.  I suggest:

Other types of relationships may be defined in the RFC Style Guide.

The rfc-editor-model document mentions a "RFC Style Manual" whereas 
this draft refers to a "RFC Style Guide".  Could "RFC Style Guide" be 
used for consistency?


>OLD (-07) text:
>
> >    From now on, the "Status of This Memo" will start with a single
>
>NEW text:
>
>Upon approval of this document, the "Status of This Memo" will start
>with a single

I assume that approval means upon publication of this document (as a 
RFC).  I suggest:

   "The "Status of This Memo" will start with a single ..."

>OLD (-07) text:
>
> >    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
> >
> >
> >
> > Daigle, et al.          Expires September 3, 2009               [Page 6]
> >
> > Internet-Draft     RFC Streams, Headers, Boilerplates         March 2009
> >
> >
> >    will be defined as part of RFC stream definitions.  Initial text, for
> >    current streams, is provided below.
>
>
>NEW text:
>
>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.  From now on, these paragraphs
>will be defined as part of RFC stream definitions.  Initial text, for
>current streams, is provided below.

Section 3.2.2 covers all the streams.  My understanding is that any 
proposed change has to go through the RFC Editor as he/she is 
responsible for ensuring consistency.  It is redundant to mention 
"review and oversight by the RFC Editor".  As for oversight by the 
IAB, that would be covered by the paragraph at the beginning of 
Section 3 of this draft.

I suggest:

   received.  This is defined on a per-stream basis.  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.

At 09:55 09-04-2009, Leslie Daigle wrote:
>My focus with the "upon approval" text below was to get the emphasis off
>"forever" in the -07 text.  That is, the -07 text had words like "from
>now on".
>
>To get off "forever", we have to talk about the here and now.
>
>If not "upon approval", or "upon publication", what's a better way to
>capture that?

If there are any changes to headers and boilerplates in future, it 
might be through an update of this document.  Generally, changes are 
implemented once a draft becomes an RFC.  It's better not to go in 
the level of detail where the document specifies exactly when the 
change should take effect.  The IAB can coordinate with the RFC 
Editor and see whether to withhold publication, for example, until 
the necessary changes are in place.

Regards,
-sm