[rfc-i] draft-iab-streams-headers-boilerplates-06 : overlooked details?

John C Klensin john+rfc at jck.com
Sun Feb 1 08:29:26 PST 2009

--On Sunday, February 01, 2009 9:01 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

>> And, IMO, that makes publication of this document --or even
>> formal handoff of the document from the IAB to the RFC
>> Editor-- inappropriate and undesirable until enough of the
>> details of expectations about boilerplate --in I-Ds as well
>> as RFCs-- are sorted out sufficiently that the various tools
>> and templates can be updated.   It is certainly plausible for
>> the IAB to take the position that I-D formats are the IESG's
>> problem and that this document need not address them.  But it
>> is not acceptable for the IAB to say "we are going to publish
>> this document and it is someone else's problem if our doing
>> so --and instructing the RFC Editor to comply with it--
>> causes disruption to the process of developing documents in
>> the IETF".
> I think that this is where we diverge, but only slightly.
> In my opinion the document is now done. It sets what we expect
> and what follows is implementation. That implementation should
> not be managed through the documents. As mentioned before I
> would like to sign off on the document. Put it on the
> RFC-queue and work with the rfc-editor, the IESG, and the
> tools writers on the implementation, those folk do 'meet'
> occasionally. Once those folk are collectively happy and we
> did not discover issues that implied changes to the document
> we can go forward and, with appropriate heads-up deploy the
> tools and publish the RFC.
> If issues are found, and they need changes in the document,
> then we can bring those to the list. I have no intention to
> have changes, beyond nits, sneak in the document during that
> implementation.


I accept your good intentions here and neither expect nor
predict that anything nefarious will happen.  However, as I
understand precedent and read RFC 4844 and 4845, you are
defining "done" in a peculiar way and suggesting a procedure
that violates the letter and spirit of those two specifications.

Your proposed procedure, as I understand from what you have said
above and several other times, is that the IAB approves the
document and forwards it to the RFC Editor for publication.
Then, if you conclude that things have changed, you make a
decision as to whether the changes should be taken to the list
and, if not, just put them through.

I believe that, if a document is forwarded to the RFC Editor for
publication, it is, well, forwarded to the RFC Editor for
publication.  Other than for normative reference holds, there
does not appear to be any mechanism for saying to the RFC
Editor: "this document is approved for publication, but not
really, and we will tell you when you can publish it or if we
want to change it further".

That model has some additional side-effects.  For example, there
are often attempts to evaluate RFC Editor performance by the
length of time that passes while documents sit in the queue.  We
sort of know how to adjust those statistics for normative
reference holds, but I don't know when to start counting for a
document for which the IAB says "put this in the queue but don't
publish it until we tell you to".

Consequently, accepting your definition of "done" as "I/we don't
want to mess with it any more", I believe that the IAB should do
one of two things at this stage:

(1) Put it aside until all of the various external ducks are
lined up, then hand it off to the RFC Editor (with an additional
community review if you think it necessary because of changes
that have been proposed in the interim).

(2) Create the equivalent of a normative reference to, e.g.,
some documents that actually specify what goes into I-Ds and how
the tools are to be structured (so that the community really
understands what the conditions for publication are) and then
pass the document to the RFC Editor.


More information about the rfc-interest mailing list