--On Wednesday, 26 July, 2006 11:40 -0700 Ted Hardie <hardie@xxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf