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

John C Klensin john+rfc at jck.com
Sun Feb 1 11:51:26 PST 2009


Julian,

First, thanks for speaking up directly.  It has been a couple of
years since I've tried looking at the source and can only guess
what you folks are wrestling with internally.   A few comments
below...

--On Sunday, February 01, 2009 19:33 +0100 Julian Reschke
<julian.reschke at gmx.de> wrote:

>... 
> Indeed.
> 
> As one of the tool implementors, what I'm looking for is:
> 
> - stability  (if we revise the RFC boilerplate, can we
> *please* do that to I-D boilerplate at the *same* point of
> time?) (*)

I think the community needs this, not just the implementers.

> - clear instructions
> 
> - optimally, no *additional* heuristics for determining the
> boilerplate for existing documents (look at the source of
> xml2rfc.tcl and/or rfc2629.xslt...)

I am hoping for an additional argument or two to the <rfc>
element that would specify the stream and approval level/species
and clear rules about what gets generated from each combination,
with no heuristics at all.  Not only can I not identify, with
any confidence, those arguments and what should be generated for
them with RFCs, there does not appear to be sufficient
information in the document for me to be convinced that is
possible.  And the situation is, of course, worse for I-Ds which
the document sort of hopes someone will address sometime. 

> - sufficient time to implement and test the changes

One of the other reasons I'm pushing back on the "give it to the
RFC Editor and ask them to hold it until we say 'publish'" is
that it lends itself to "publish this on Monday and use that
form in all documents published thereafter".  I'm fairly sure
the is not what Olaf intends, but the comments about the RFC
Editor pasting in new text seem to me to vastly underestimate
the amount of work and number of people who need to be involved,
testing, etc.

> (*) while we're at it, it would be totally cool if we could
> get the front-matter/author/contributor/acknowledgments issue
> resolved as well.

My understanding, which may be incorrect, is that the RFC Editor
has reached a tentative conclusion about the best way to handle
that.   I don't know where that conclusion in terms of such
steps as "announce it for final comment", "figure out if IAB
approval is needed and ask them if it is", "IAB consideration
and approval", and "work with the tool implementers to develop a
deployment plan".   I hope that no one thinks the changes need a
flag-day switchover (unlike the current model for handling IPR
and other boilerplate), but it is obvious that some coordination
among tools and with other changes would be a good idea.

   john



More information about the rfc-interest mailing list