[rfc-i] [IAB] Headers and Boilerplates is done.

John C Klensin john+rfc at jck.com
Thu Nov 19 10:30:05 PST 2009


Olaf,

My agreement to this document "months ago" was based on the what
I thought was general agreement that the precise layout and
language to be used was a matter for the RSE and Style Manual.
In other words, the document provided specific guidance for
material that was expected to be present but not requirements
for the literal inclusion of that text.

One of the several advantages of that approach is that changes
to further spell out the names of the streams for clarity, such
as those suggested by Bob Braden, could be made without having
to go through an extended consensus process to revise this
document.  I would hope that an RSE would consult with the IAB
and the broader  community before making a change as sweeping as
the removal of statements about deployment and implementation as
Bob Hinden suggests, but I would hope that would not require
revising this specification either.

I thing Joe Touch is at least half-right.  If these sections and
specific wording are matters of explicit community consensus,
then it is entirely inappropriate to make AUTH48 changes that
don't reflect community review and consensus.  My conclusion
from that, however, is that the community consensus should focus
on guidance to the RFC Editor, not specific, finely-tuned,
wording.  If that is the case, then we don't need AUTH48
changes, we just need to have the Style Manual updated as and
when appropriate.

The perfect may be the enemy of the good, but in-depth editing
by committee (or, worse, by the whole community) is the enemy of
even the half-decent.

The first paragraph of Section 6 of the document now reads:

	"The RFC Editor is responsible for maintaining the
	consistency of the RFC series.  To that end the RFC
	Editor maintains a style manual [RFC-style].  In this
	memo we mention a few explicit structural elements that
	the RFC editor needs to maintain.  The conventions for
	the content and use of all current and future elements
	are to be documented in the style manual."

I can read that as giving the RFC Editor precisely the
flexibility that the discussion above anticipates.   I can also
read it as "this stuff is absolutely fixed, the RFC Editor is
instructed to copy it into the style manual, but can then make
other changes as long as this text is not affected".   However
it is resolved, that ambiguity is unacceptable: we need to be at
least as clear here as we have been in RFC 4844 and 5620 about
what the RFC Editor can and cannot do without a supporting,
formally published, consensus document.

    john

p.s. the draft which we are discussing seems to have expired in
October and to have an obsolete list of IAB members.




--On Thursday, November 19, 2009 10:57 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

>...
> Frankly and personally, yes, these comments are (too) late for
> consideration.
> 
> I have not gone back to the list to regain state but we had a
> long discussion about statements about deployment and
> implementation and found a rough consensus. The document has
> been approved months ago and would have been published and
> implemented if it where not for the MISREF on RFC3239bis.
> 
> I can't assess whether your suggestions are beyond the point
> where perfect is the enemy of the good or critical to the
> process.
> 
> 
> -- Olaf
> 
> 
> ________________________________________________________ 
> 
> Olaf M. Kolkman                        NLnet Labs
>                                        Science Park 140, 
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
> 






More information about the rfc-interest mailing list