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

John C Klensin john+rfc at jck.com
Sat Jan 31 12:44:12 PST 2009

--On Saturday, January 31, 2009 13:22 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

> What are your thoughts about Klensin's point 3.
> Personally I think that this document is about the headers and
> boilerplates of RFCs. Not about Internet-Drafts. (Don;t think
> we have such crisp definitions for Internet-Drafts).
> Also I think that there are a few things that the RFC Editor
> will need to be aware off to create the appropriate
> boilerplate, but I don;t think there is any wizzard science
> here.
> Stream, category, and type of consensus (for IETF and IRTF
> streams) that is at first sight all that goes into the mix.


I think you are missing the main part of my concern about the
relationship between this document and I-Ds.  From my point of
view, the two most important positive contributions to IETF
productivity in the last decade have been the introduction of
xml2rfc and the ability of the RFC Editor to actually work in
that format.  The community has not thanked the people
responsible for either innovation nearly enough -- while I would
oppose making it a requirement, I believe that the vast majority
of I-Ds are prepared today using xml2rfc and that being able to
work directly in a format the RFC Editor uses has significantly
reduced errors in the "AUTH48" review and approval process and
may even have improved the speed with which documents move
through the RFC production process as compared to manual
conversion of a text file to nroff and doing the editing there.

A third major productivity enhancement has come from the ability
to use tools other than xml2rfc itself to process the XML I-D
source files and, perhaps as a consequence, inspiring others to
develop tools based on MS Word and other contemporary document
production systems.  Those are Good Things too.

But those changes and the relationship it implies between RFCs
and I-Ds means that there is no such thing as "things that the
RFC Editor will need ... to create the appropriate boilerplate".
Unless I completely misunderstand how the RFC Editor staff works
these days, if the RFC Editor needs to create boilerplate, paste
it in, and structure the text to include it, we are back to
significant manual processing in nroff... and we are back to the
point at which an RFC format cannot be produced directly from
XML, that the XML->HTML pieces of those tools cannot accurately
render an RFC, and probably that those who are revising
documents cannot start with the XML form of the RFC and easily
convert back to I-D format.  All of those things are possible
and convenient today.

Although perhaps others disagree, I believe that the
productivity degradation that we would suffer, as a community,
from the loss of those facilities would, in any consideration of
tradeoffs, far outweigh the other advantages of this document
and anything that depends on it (or that it depends on).

I am convinced, based on experience with getting RFCs back into
a form in which they can be edited into revision I-Ds, that
being able to switch boilerplate by changing a few of the
parameters to a single element of an XML source file has become
an essential feature of how a good deal of work gets done in the

And, IMO, that makes publication of this document --or even
formal handoff of the document from the IAB to the RFC Editor--
inappropriate and undesirable until enough of the details of
expectations about boilerplate --in I-Ds as well as RFCs-- are
sorted out sufficiently that the various tools and templates can
be updated.   It is certainly plausible for the IAB to take the
position that I-D formats are the IESG's problem and that this
document need not address them.  But it is not acceptable for
the IAB to say "we are going to publish this document and it is
someone else's problem if our doing so --and instructing the RFC
Editor to comply with it-- causes disruption to the process of
developing documents in the IETF".

> I am traveling and meeting for almost the whole month of
> February. Having fun... nah.. not right now.

You have my sympathy.


More information about the rfc-interest mailing list