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

John C Klensin john+rfc at jck.com
Sun Jan 11 19:07:24 PST 2009



--On Saturday, 10 Jan 2009 09:27:50 +0100, Olaf Kolkman
<olaf at NLnetLabs.nl> wrote

> Folk,
> 
> Having caught up with the whole thread I think I got a feel
> for where   consensus is going.
>...
> With respect to (3) my reading of where consensus is heading
> is that   non-IETF documents should not mention that they are
> not the product of   the IETF.
>...

Olaf,

I can live with this, and I really like the distinction between
documents published in the IETF track and those that have been
formally reviewed in the IETF and shown evidence of community
consensus.

I would make a few suggestions, but don't consider any but the
first to be showstoppers.

(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.
Doing that also makes things a bit easier for tool-writers and
RFC authors, since the forward reference would presumably
require that a section number be inserted into what is otherwise
fixed-text boilerplate.

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.

    john



More information about the rfc-interest mailing list