[rfc-i] Wrapup of Fwd: Comment on headers-and-boilerplates

Olaf Kolkman olaf at NLnetLabs.nl
Mon Jan 12 00:48:32 PST 2009

On Jan 12, 2009, at 4:07 AM, John C Klensin wrote:
> (1) In your proposed text, please change all instances of
> "purpoases" to "purposes" or, if you prefer, "porpoises", which
> has rather a nice ring to it.


> (2) I have no idea what publishing a document for "experimental
> purposes" might mean.   Perhaps "...published for examination,
> experimental implementation, and evaluation." is closer to what
> you are looking for.  The other statements could be similarly
> tuned, e.g., "...published for the historical record" is better
> than "...published for historical purposes", but this one stood
> out as the most awkward.

Sound reasonable...

> (3) One of the nice features of the approach in this I-D is that
> it avoids scattering boilerplate throughout the document.  The
> proposed Section 3.2.3 is apparently opposite to that trend,
> creating a requirement for a new 'Updates to the RFC' section in
> every document.  Since we do not modify RFCs, I suggest that
> whatever you have in mind for that section should be short and
> compact enough that it should simply be inserted as paragraph 3
> of "Status", rather than placed elsewhere with a reference.

I see where you are coming from. The intention was to capture what is  
also in section 3.4 of the document.

<quote from="the draft">

3.4.  Other structural information in RFCs

    RFCs contain other structural informational elements.  The RFC  
    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

    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

So the intention is really that a reference to an external URL is  
entered there. I think that moving the text from 3.4 to 3.2.3 is  

> Finally, to reduce the risk of a variation on the IPR
> boilerplate debacle, I hope that, before publication of the next
> version of your draft, the IAB will consult with the tools team
> to be sure that they have, or are confident that they can
> develop, a plan and code for dealing with all of the variations
> and combinations of text implied by your outline.

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

When reading "as soon as possible" I always think "but not sooner" to  
me it is clear that all involved need to be ready: RFC Editor, tools  
team, &c, &c.


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.

-------------- 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/20090112/fdccd637/PGP.bin

More information about the rfc-interest mailing list