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

John C Klensin john+rfc at jck.com
Fri Jan 16 11:15:41 PST 2009

--On Friday, January 16, 2009 9:37 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

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

Thanks.  Most of this seems sensible (which does not imply that
I completely agree).  But one comment below.

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

One of the hallmarks of the IETF since its inception has been an
exceptionally open process, where all key decisions are exposed
to the community and available for comment.  It is clear from
the debate over implementation of RFC 5378 that the community
has strong views about what constitutes a key decision even if
there is no consensus on that point.

It seems to me that you, presumably with the support of the IAB,
are moving in directions that would change that open process
model to one in which some general ideas, without details (or
with hand-waving about the details) are discussed in public.
After that, sorting out the details are handed off to some very
private process.  The community has no visibility into that
process while it is ongoing (which might be ok), but also has no
clear review, approval, or appeal path once conclusions are
reached.  Things just pop out the other end and become effective
and, if there are problems, we end up with serious constipation
in the publication or other processes (see Bob Braden's recent
note to authors of documents scheduled for publication after 10
November but on which significant work was done prior to that

When I extrapolate from several conversations with you, I know
it is not your intent to start running private or hidden
processes, but consider the effects of:

	* The IAB produces an RFC Editor model that, in the
	interest of efficiency, simplicity, and brevity, leaves
	out many details.  The IAB expects the community to
	agree to that model, loose ends and unspecified areas
	and all, and then hand it off to the IAOC and an
	"drafting group" so that the details can be resolved.
	The result is that a draft RFI --which the IAOC
	originally did not intend to expose to the community at
	all before sending out to potential vendors-- that still
	contains the hand-waving, the loose ends, and that does
	not reflect details that would be important to someone
	who actually has to implement the process but that the
	"Model" omitted.  Given the agreement at IETF 74 that
	there would be an opportunity for community comment on
	the RFI before it goes to vendors, perhaps we will get
	the RFI straightened out, but there is no way to assure
	that it will accurately reflect what the IAB and the
	community would have intended from the Model if all of
	the details where there.
	* Here you say "before it is published as an RFC" and
	apparently suggest that the sequence of events is (i)
	the IAB proposes and the community agrees to something
	that is "guiding", (ii) the document goes to the RFC
	Editor, (iii) while the document is sitting in the RFC
	Editor queue, you work with tool-builders, the RFC
	Editor, and others to get the details right (a process
	that is invisible to the community), (iv) when you are
	all happy (a private determination), you publish a final
	document, perhaps with pragmatic changes the community
	has not had an opportunity to review.

Maybe I'm just being unreasonably fussy, but this doesn't seem
right to me.  Indeed, it feels a little like pushing a security
protocol toward the RFC Editor with language in it that says "a
hash is computed here" on the assumption that the type of hash
can somehow be sorted out in the editing process and that the
decision won't have side-effects elsewhere.

Either that, or I don't really understand what you are

> 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).

But we have been pushing very hard, with some success, to have
the RFC Editor function use the same tools that authors use.  It
would be a major setback to that approach if the RFC Editor
function had to take a document in xml2rfc form, patch it with
boilerplate that could not be generated by the xml2rfc
processors available to document authors, and then, e.g.,
repaginate the document with other internal tools.    I assume
you don't intend that either, but it makes "during the
publishing phase" a little more subtle than the sentence above

Also, if I correctly read either the "Model" document or the
current version of the draft RFI, the RFC-Publisher is expected
to edit, but not make _any_ policy decisions.   If that is
correct, the boilerplate to be applied has to be fully
specified, at least by reference, before the document leaves the
stream authority (unless the document is to be passed by the RFC
Series Editor on its way to the RFC-Publisher, in which case it
must be fully specified by the time the RFC Series Editor gets
through with it).  If it is not correct, then there are really
serious deficiencies in both the Model document and the draft
RFI.  And, to be clear, it is exactly this type of issue that
causes my frequent claim that the various pieces of this puzzle
still contain a great deal of hand-waving.

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

Certainly I prefer that to having the document published --and
implemented in published RFCs-- without first checking for
"gigantic corner-cases".  However, I worry that, if one uses
this particular process model and cases (gigantic or otherwise)
are discovered that require document changes, the community will
have about the same opportunity to review those changes that it
has with AUTH48 chances, i.e., little or none.

best regards,

More information about the rfc-interest mailing list