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

[Olaf Kolkman]

John,

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  
responded inline.
>
>
> 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  
draft.

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  
working off.

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







-----------------------------------------------------------
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...
Name: PGP.sig
Type: application/pgp-signature
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