[rfc-i] headers and boilerplates last minute proposal

John C Klensin john+rfc at jck.com
Tue Mar 10 21:00:05 PDT 2009



--On Monday, March 09, 2009 12:27:02 -0400 Leslie Daigle
<leslie at thinkingcat.com> wrote...

> Hi Olaf,
> 
> I'm highly supportive of making sure the RFC Editor has
> adequate room to  do their work, which does include ensuring
> appropriate look and feel.
>...

Leslie, as the IAB member responsible for raising the issue and
proposing text similar to this as a solution, let me try to
respond.    I've actually got two separate issues, but they
interconnect.

Without trying to talk about the pieces into which it is
proposed to split the RFC Editor, I think there is a fundamental
tension here between "RFC Editor as an independent entity,
working in partnership with the IAB and the various streams" and
"RFC Editor as someone's employee / not-very-independent
contractor, subject to very close direction and supervision".
While that tension has existed in this process since RFC 4844
was being written (or earlier), the various documents, including
4844 and the RFC Editor Model draft (but IMO not this one), have
consistently taken the first position.  I believe that position
is appropriate.

However, if we are serious about it, then the _entire_ style
manual has got to be an RFC Editor responsibility, not just
whatever you intend by "look and feel".  The IAB should have
review authority and responsibility, and that should extend to
being able to say, e.g., "no, there was a reason why we
suggested putting that text in that place" or even "those
particular words were important, please use them", but not to
micromanaging the RFC Editor by supplying and imposing parts of
the Style Manual.  

The purpose of the suggested paragraph (in this regard) was to
get (and keep) the IAB out of  the Style Manual writing business
and the micromanagement business in general.  As I have told the
IAB, I'm concerned both about getting roles mixed up and about
whether the IAB will have, and will want to allocate, sufficient
bandwidth to apply this level of management and intervention
long-term.  As a member of the community (not yet an IAB member)
I think that making a long-term commitment to allocating IAB
bandwidth that way would be a mistake.  I hope you agree.  I
think better fixes to the document than that paragraph are
possible (see below), but they would have required much more
extensive rewriting.  Based on Olaf's guidance that it was
important to get this out, I suggested a global patch.

So that is the first of the two issues.
 
> However, I believe the proposed text is too vague, and subject
> to  misinterpretation.  Reading it without the context that
> created it, this  reads to me as saying "Despite the fact that
> this looks like a  specification, it isn't;  and any and all
> parts of it may change  randomly and without the kind of
> community discussion that lead to this  version."

I suggest that, if the RFC Editor starts blowing off
constructive and specific suggestions from the IAB (or anyone
else) without careful consideration, community discussion, etc.,
there is an operational and contractual problem quite
independent of, and much more serious than, this document.
Certainly the current RFC Editor has not done so and I do not
believe it has occurred in the entire history of the series.
It would be a problem that started with either a fatally bad
breakdown of RFC Editor functions and relations and cumulated in
a choice of RFC Editor (or RFC Editor components) who felt no
responsibility to the community, could not be managed, and was
inclined to go off on its/their own regardless of community
input.  If the IAOC and/or IAB make choices that bad, I don't
believe the specificity in this document will help much.   So I
can't get, in any practical way, from anything that was said in
the note Olaf circulated to "change randomly".  

If you are anticipating that sort of problem, I don't think the
fix lies here but in an update to 4844 (which I believe is
adequate, but you may not), modifications to the "RFC Editor
Model" document, and/or specific contractual language in the RFP
and beyond (reviewed and vetted by the community) that makes it
clear that the RFC Editor is supposed to pay careful attention
when the IAB says something reasonable, to give the IAB the
benefit of the doubt about what is reasonable, to pay attention
to the reasoning behind the suggestions as well as the
suggestions themselves, to raise issues that might be
controversial on this list or in other forums, and generally to
engage in a dialogue about anything that is controversial or
likely to become controversial.  Again, I have no reason to
believe that such text should be necessary for any entity who
should be given any part of the RFC Editor pie, but YMMD.

> The document already indicated where the RFC Editor had final
> say over  wording, and indicated that such wording was
> "initial values".  If the  document needs to be clearer about
> what is, or is not changeable text,  or the contexts in which
> further input is needed/not applicable, let's  make it clearer
> in the appropriate places.

Actually, it does not indicate that.  It is extremely specific
and prescriptive, down to the format of the headers.  It does
say "Initial text" in 3.2.2, but it is unclear about how rigid
that text is and about the updating procedures, and then says
"...may be updated by stream definition document updates" a
situation that could create a "too many masters" situation for
the RFC Editor  (and that implies relationships that lie
properly within the scope of the RFC Editor Model document
and/or RFC4844bis.  If you want this to be an IAB document,
stemming from the IAB's oversight role, every one of those
statements would, at least, have to require IAB sign-off on the
stream documents (or whatever) that give direction to the RFC
Editor.  Put differently, if the streams are able to instruct
the RFC Editor with regard to specific text or format without
IAB signoff, one has created a management nightmare for both the
RFC Editor and the IAB.  

In addition, because instruction of the type implied from the
stream controllers would be direction at the level of which
paragraphs fall where and in what order --rather than
recommendations to be incorporated into the overall style
manual-- I'd still complain about micromanagement.  That may not
be what you intended, but it is consistent with what the
document says.

Most of the rest of the document reads like a specification,
with very specific and directive language (not like anything
that could be construed as initial text that could be updated as
part of, e.g., a style manual process) until one gets to Section
3.4, where it says "The RFC Editor is responsible for the
positioning and layout of these structural element".  There,
please note that, in addition to the grammatical problem (which
I assume the RFC Editor would catch and fix if that is still
permitted), the implication is that the RFC Editor is not part
of the process of _defining_ those structural elements, only for
figuring out where they go (and one of those elements may be
subject to legal requirements and constraints, so the choices
may be more limited than the statement implies).   That is
inconsistent with the Style Manual responsibility and the
general responsibility of the RFC Editor to assure the integrity
and stylistic consistency of the series.  

One could devise other approaches and reflect them in this
document with fairly extensive rewrites but the easy solution is
exactly what the RFC Editor Model document and 4844 seem to
anticipate -- to engage the RFC Editor in the planning and
specification process so there are no surprises about what comes
out, but to formally view all of these things as more-or-less
strong input to the RFC Editor and the Style Manual process.

All of that could be fixed section-by-section, but I don't
believe that it would be a fast patch, guaranteed to be
error-free the first time.  Hence the suggestion of a patch
rather than a rewrite although, if there were no time
constraints and an opportunity for multiple review cycles, I
would prefer the rewrite.   

That issue also leads directly to my second concern.  The IETF
has an extremely poor track record for getting this sort of
thing right on the first try and without implementation and
deployment experience.  That is not just my pessimism showing
through; the recent requirement that certain text appear on the
first page of RFCs and I-Ds when, in practice, it won't fit
there given other required material for that page, is an
excellent, and I fear typical, example.  With this document,
there has been a bit of a dance about the possibility of queuing
it with the RFC Editor for publication but with the intent of
making substantive changes at AUTH48 if problems were noticed on
implementation (a procedure to which I also objected, both weeks
ago on this list and in the IAB -- because AUTH48 edits are
invisible to the community, I believe it is important to not set
any precedents for that phase being used for anything but
corrections to editing difficulties introduced in, or not caught
by, the RFC Editing process).

That track record suggests that, if problems are found with this
document after publication, we should not require new RFCs
(updating this one or providing new stream-specific
recommendations) to get them fixed.  We would, instead, be far
better off if the problem could be pointed out to the RFC
Editor, a fix proposed by the RFC Editor and quickly reviewed by
the IAB, and then implemented.  The document, as written without
the new paragraph, appears to make that nearly impossible.  The
added flexibility that would come with unambiguously returning
the style manual (all of it) to the primary control of the RFC
Editor (I should not need to keep saying this, but "subject to
IAB review to the extent the IAB considers necessary") isn't an
invitation to "random changes" at the whim of some capricious
RFC Editor but an opportunity for flexibility and the rapid
application of good sense when it is appropriate.

> Page layouts were discussed considerably on this list, at
> least to the  extent of determining which parts were headers
> and which were elsewhere  in boilerplate (or, even, not in
> boilerplate).  While I certainly  acknowledge that the RFC
> Editor should have the ability to adjust the  series, it is
> important to indicate how the import of the opinions 
> expressed in this discussion will be factored into future
> changes.

And the document does not do that.  It does explain some (but
only some) of the reasoning for those decisions, but does not
specify any change model that would, of necessity, factor those
considerations in.  Historically, the RFC Editor has been better
at institutional memory and consistency of behavior than most
other elements of the IETF community.  If and as that changes
with new contracts, new models, and perhaps more rapid turnover,
we need to find ways to preserve information like the opinions
to which you refer --either in appendices to the style manual,
in RFCs that offer guidance and principles, or elsewhere.  But
it should be in materials that are less focused on specifying
very specific text and instructions as to where to put it.  In
other words, we are agreed about the principle you express
above.  I just do not believe that a document with this content
and organization is the way to do that and, precisely because it
is focused on text and not descriptions of "opinions expressed"
and consensus reached, that it might actually turn out to be
pathological is it is not precisely correct.

Again, my individual first preference is a rewrite of the
document to better reflect the principles you are advocating, to
make the boundaries of authority and responsibility completely
clear, and to clearly specify a change process that does not
require new RFCs for obvious cases.   I prefer the patching
paragraph only if there is a time constraint on getting this
finished and out the door, which I have been assured that there
is.

regards,
     john



More information about the rfc-interest mailing list