[rfc-i] Wrapup of Fwd: Comment on headers-and-boilerplates
olaf at NLnetLabs.nl
Fri Jan 16 00:37:15 PST 2009
Thanks for sharing your concerns...
I've CC-ed the IAB, see my other note about posting the I-D and the
plan to have it approved on the next meeting. I think the IAB should
be aware of this discussion, I left your reasoning complete and
> I was suggesting something a little different and clearly
> complementary to the above. Specifically, my impression is
> that, for a given document, the final status section will
> consist of
> (1) A choice of category boilerplate (Standards Track,
> Informational, Experimental, Historic)*
> (2) A choice of track boilerplate (with some dependency
> on (1))
> (3) A choice of approval/ consensus level boilerplate
> (with some dependency on both (1) and (2)).
> (4) Possibly some choice of "updating" boilerplate, at
> least wrt to what URL gets referenced.
> Several of these probably interact with whether the document is
> an I-D or RFC as well.
The only element that currently interacts with the I-Ds is the stream
element. The "Status of this Memo" for I-Ds is not the subject of this
The two main factors that determine the boilerplate text are the
"stream" and the "category". There are a few rare special cases (IRTF
documents without consensus) that IMHO can be handled with editor notes.
> nk the community would benefit if, before the document
> becomes final, the IAB opened a discussion with various
> tool-builders (the xml2rfc, IDs-in-Word, and whomever is
> managing the nroff macros (if anyone)) groups come to mind, but
> there may be others), and with the RFC Editor, about how to
> implement the above so that the complexity for the
> document-writer and the possibility of mixups are both minimized.
Where I read: 'becomes final' as 'before it is published as an RFC'.
I agree that we have to advertise this change and work with the tools
builders before the RFC is put online and into effect but I do not
think that this is blocking for submission to the editor. Headers and
boilerplates should be guiding, the implementation should follow.
> Similarly, some discussion with the Secretariat and IESG may be
> in order about just exactly what is going to be checked at I-D
> submission time (and in the interfaces between the various
> streams and the Production House and between the Production
> House and the Publisher in the new RFC Editor Model) and sharing
> any conclusions with the community for discussion.
IMHO only the stream-definition would be checked at submission.
It is during the publishing phase that, based on stream and category,
boilerplate material is constructed (so this would be a RFC-Publisher
responsibility, as part making the RFC text consistent with the RFC
Style manual, and the RFC series).
> Put differently, we don't have the luxury here that exists with
> a Proposed Standard. We cannot say "well, there are no _known_
> technical defects, but we don't really have to determine/show
> that the specification can be implemented or deployed until we
> get to Draft": this has to work, and work the first time. And,
> as the community has recently discovered in another situation,
> finger-pointing (or statements like "not our fault; nothing that
> we can do about it") is not a useful substitute for
> problem-solving. So I am suggesting that the IAB accept the
> consequences of the fact that this document is part of a fairly
> complex document creation, editing, and posting system and that
> it take responsibility for being sure that all of the pieces of
> that system will fit cleanly and smoothly together.
As you know we are working on another project as well: the RFC Editor
model. There we followed the model you suggest above, not finalizing
by submitting the document to the editor. But allow clarification and
(relatively minor) changes while folk try to implement. I've heard
complaints about how that is handled too and I, personally, would not
like to put the stick in the ground so everybody knows what they are
In other words. I hope the IAB will submit the document to the Editor
shortly. Then we start to work with the RFC Editor and the tools folk
on the implementation, and once we are satisfied that we did not run
into a gigantic corner-case the RFC is published.
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/20090116/e803a8dc/PGP.bin
More information about the rfc-interest