[rfc-i] draft-iab-streams-headers-boilerplates-06 : overlooked details?
olaf at NLnetLabs.nl
Sun Feb 1 00:01:35 PST 2009
> 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.
John, you an I are in full agreement on the the tools: they bring
efficiency to the I-D authors, to the RFC editors and have made our
collective lives in the IETF document chain a little less miserable :-)
> 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 think that this is where we diverge, but only slightly.
In my opinion the document is now done. It sets what we expect and
what follows is implementation. That implementation should not be
managed through the documents. As mentioned before I would like to
sign off on the document. Put it on the RFC-queue and work with the
rfc-editor, the IESG, and the tools writers on the implementation,
those folk do 'meet' occasionally. Once those folk are collectively
happy and we did not discover issues that implied changes to the
document we can go forward and, with appropriate heads-up deploy the
tools and publish the RFC.
If issues are found, and they need changes in the document, then we
can bring those to the list. I have no intention to have changes,
beyond nits, sneak in the document during that implementation.
-------------- 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/20090201/bd1c95b7/PGP.bin
More information about the rfc-interest