--On Wednesday, 26 July, 2006 11:40 -0700 Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> wrote:
Given those actual or imagined chains of authority, it doesn't
take very many steps to get to "the IESG can tell ISOC what to
write into and 'RFC Editor' RFP and can tell the IAOC how to
interpret that contract". That is a problem because some of
us who believe in independent submissions believe that the
first and most important thing they should be independent of
IESG consensus.
When RFC 3932 was written, I thought this sentence was
the "meat" of the issue:
The new review model will have the IESG take responsibility
ONLY for checking for conflicts between the work of the
IETF and the documents submitted; soliciting technical
review is deemed to be the responsibility of the RFC
Editor.
For any independent review stream, I believe that the review by
the IESG is governed by this model. If the IESG and a
publisher of an independent stream disagree about whether
there is a conflict with the work of the IETF, we could still
have a problem, but I believe that this division of
responsibility is generally appropriate and has community
support.
I actually agree... and have never had any problem with that
statement in 3932. But there are two issues here and this is
only one of them.
At the other extreme, suppose that the IASA (or ISOC), at the
direction of :the IETF" (i.e., the IESG, with or without a
consensus call), issued an RFC that called for an
"independent" stream with conditions placed upon it that
permitted the IESG, without formally consulting the IETF
community, to block or indefinitely delay documents and
mandate that any text it liked was to be put in documents
that were published. There would then be some question as to
whether the entity for which the ISOC was requesting bids
could properly be known as "the RFC Editor" and that might
well raise the naming problem.
And here you've lost me. Updating RFC 3932 would require
a new consensus call to the IETF, since it is a BCP. I suppose
it could be argued that it applies only as long as the
publisher of the independent stream is called "the RFC Editor",
and an update to it if that name changes might be necessary.
But the IESG cannot change the rules by which it interacts
with the RFC Editor by RFP or SoW; it would have to get
consensus to do so from the IETF by publishing a new BCP.
And this is at the heart of the other issue. 3932 appears to do
two things. One is to define the role of the IESG in this
process and how that role is managed. Clearly, it is within the
authority of the IETF, and the IESG as interpreter of IETF
consensus, to do that. I don't think anyone has questioned
that.
The other is that, to some readers, it appears to impose binding
requirements on how the RFC Editor deals with input from the
IESG, either directly (as in "if we recommend that this text be
inserted, you must insert it or not publish") or indirectly (as
in "if you don't follow our recommendations, we will see to it
that your funding is cut off"). For those of us who believe
that it is important to the Internet that the RFC Editor
function as an independent, cooperating, entity rather than as a
subsidiary of the IETF, that level of requirement is not
acceptable (that consideration is the source of this discussion
about aspects of the RFP and what should, or should not, be in
it). While the IETF can attempt to establish links to
particular funding sources and apply leverage that way (which
some of us are trying to discourage), it is also beyond the
ability of the IETF to give itself the authority to impose such
requirements directly, any more than approval of a document as
an IETF Standard can force someone to conform to it.
There is a critical balance in this that has worked reasonably
well since before the IETF came into being. One of its elements
has historically been ongoing discussions between the RFC Editor
and the IAB in which agreements were reached about how to
proceed on things (rather than one party assuming that it has
the right or authority to dictate to the other). As I have said
before, I think that model, based on mutual respect and
cooperation, is a good one and that it has served the Internet
well. But there have periodically been efforts to change that
balance into one in which the RFC Editor is merely an IETF
contractor subject to the IETF's (potentially changing) will as
specified by the IESG. I believe that would be a very bad
change indeed and hence am pushing back on what I see as efforts
to push the RFP in that direction.
I know of no interest in changing the current consensus and no
desire to publish a new BCP; I also don't think such a BCP
would get consensus.
We may disagree about that, but I don't see resolving it as
necessary to moving forward with the task at hand.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf