[rfc-i] Wrapup of Fwd: Comment on headers-and-boilerplates
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.
> (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...
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