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

John C Klensin john+rfc at jck.com
Mon Jan 12 07:43:23 PST 2009



--On Monday, January 12, 2009 9:48 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

>...
>> Finally, to reduce the risk of a variation on the IPR
>> boilerplate debacle, I hope that, before publication of the
>> next version of your draft, the IAB will consult with the
>> tools team to be sure that they have, or are confident that
>> they can develop, a plan and code for dealing with all of the
>> variations and combinations of text implied by your outline.
>> 
> 
> The introduction reads:
> "The changes introduced by this memo should be implemented as
> soon as practically possible after the document has been
> approved for publication."
> 
> When reading "as soon as possible" I always think "but not
> sooner" to me it is clear that all involved need to be ready:
> RFC Editor, tools team, &c, &c.

Understood and appreciated.

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.

I think 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.

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.

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.

regards,
   john

* It is not clear to me that we have ever formally abolished FYI
RFCs at the BCP level.  We just stopped creating new ones.  If
that impression is correct, the IAB should either move to
formally get rid of them now  or they should be at least
minimally reflected in this document and the RFC Editor Model
one.    I don't think the relevant text should be significantly
different from the Informational text --in some sense, FYIs are
just a special case of Informational -- but ignoring them is the
sort of thing that gets us into trouble when we least expect it.



More information about the rfc-interest mailing list