[rfc-i] draft-iab-streams-headers-boilerplates-06 : overlooked details?

Olaf Kolkman olaf at NLnetLabs.nl
Mon Jan 26 01:52:20 PST 2009


On Jan 23, 2009, at 5:13 PM, Alfred HÎnes wrote:

> Folks,
> I have sent Olaf and Leslie a collection of nits I observed
> when I once more read the latest revisionof the RFC Boilerplate
> draft from scratch, and two more important observations.
>
> I fear these topics have been overlooked in the discussion so far.

>
> I quote literally from my message sent off-list:
>



Again Alfred, thanks for the NITS, I'm dealing with those off-list too.

You identified 2 issues, that have not been brought up before. And  
although we should have passed the done-is-done point I think that  
these points are substantive enough to address, while IMHO not really  
contentious, and since I am spinning the document for all the NITS I  
plan to address them as below.


>
> --------  start quote  --------
>
> However, I have one general concern, and one important suggestion:
>
> The boilerplate sentence
>  "Discussion and suggestions for improvement are requested."
> apparently now shall only be included for Experimental RFCs.
>
> In the past, it was generally applied, and I always understood
> it to be at the heart of the IETF process and culture.
> I don't recall that this topic has been discussed on the list,
> so it's dropping might have happened inadvertantly.  Please check.
> IMHO, Proposed Standards (for instance) would need feedback
> perhaps even more than Experimental documents; only for RFCs
> immediately published as Historic this clause makes less sense.
> In the case of Independent Submissions describing 3rd-party
> protocols, RFC publication might have been sought for just this
> goal, to start discussion in the IETF at large.
> According to my experience, even the IAB appreciates feedback
> to IAB Stream RFCs after publication.   :-)

This inconsistency seemed to have been introduced inadvertently.

I propose to _not_ have this information in the boilerplate but include
it explicitly in where the "Updates to this Reference" refers to (in  
section 3.4).


CONTEXT:
3.4.  Other structural information in RFCs

    RFCs contain other structural informational elements.  The RFC  
Editor
    is responsible for the positioning and layout of these structural
    element.  Note also that new elements may be introduced or obsoleted
    using a process consistent with [RFC4844].  These additions may or
    may not require documentation in an RFC.

    Currently the following structural information is available or is
    being considered for inclusion in RFCs:

   [...]
OLD:
   Updates to the RFC  A reference identifying where more information
       about the document can be found.  This may include information
       whether the RFC has been updated or obsoleted, the RFC's
       originating stream, a listing of possible errata, and information
       on how to submit errata as described in
       [I-D.rfc-editor-errata-process].

NEW:
   Updates to the RFC  A reference identifying where more information
       about the document can be found.  This may include information
       whether the RFC has been updated or obsoleted, the RFC's
       originating stream, a listing of possible errata, information  
about
       how to provide feedback and suggestion, and information on how to
       submit errata as described in [I-D.rfc-editor-errata-process].



By moving out of the boilerplate to this section there is a bit more  
leverage to, in the reference add stream specific information (you  
could think of a pointer to which WG developed the protocol) and keep  
it up to date (i.e. when the WG is not there and the comments should  
go to the area) without having to redefine headers in this document.


Obviously this is combined with


CONTEXT:
    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:
OLD:
    Experimental:  "This document defines an Experimental Protocol for
       the Internet community.  Discussion and suggestions for
       improvement are requested."
NEW:
    Experimental:  "This document defines an Experimental Protocol for
       the Internet community."


> In the 3rd paragraph of Section 2, the discussion I have observed
> might be better reflected by inserting "generally":
>
>   Documents published in streams other than the IETF Stream are not
>   reviewed by the IETF for such things as security, congestion  
> control,
>   or inappropriate interaction ...
> ---
>   Documents published in streams other than the IETF Stream are not
> |  generally reviewed by the IETF for such things as security,
>   ^^^^^^^^^^
>   congestion control, or inappropriate interaction ...
>


This suggestion seems appropriate and in the spirit of the discussion  
we had.

I'll be submitting version 07 shortly.



--Olaf



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20090126/a461711a/PGP.bin


More information about the rfc-interest mailing list