I don't think (and maybe we're in agreement here) that what you're describing is captured at all in the current set of scenarios. In my reading of Scenarios A & B, the suggestion is that ISOC takes on the administrative work more-or-less directly. "B" differs from "A" in that it calls for more IETF involvement in the management of the organization that is (then) directing the administrative work. I.e., allowing realtime course correction to make sure that ISOC and IETF administration keep flying in formation in ways that are mutually acceptable.
Putting an MoU-like agreement on the table could shift the "center of gravity" of the responsibility for the future of the administrative activity further from the centre of the ISOC organization. The further out it gets, the less sense it makes to undertake (anything like) the other mechanisms in Scenario B that get IETF participation right into the ISOC organization.
Now, I (as a generic IETF participant) would want to see a real draft of such an MoU before I called it a scenario and had an opinion as to whether I thought it could solve the problems we're looking at. Since you clearly stated that the other Scenario B mechanisms make no sense to you, I'm thinking you might have a clear idea of the sorts of things that would be reasonable in such a document.
By the way, it doesn't seem to make a lot of sense to me, personally, to talk about an MoU between ISOC and "the IETF", which either doesn't exist or is an activity of ISOC. I wonder if this is something that would be better framed as an IETF process document -- requires IETF consensus process to change, and ISOC BoT approval to put into effect, per our current rules.
Leslie.
John C Klensin wrote:
[and]If we are to understand Scenario B as "identical to Scenario A, but [with a bit] more up-front work is put into defining the relationship." (bracketed text mine, not Carl's) than I think we may be getting close to agreement on Scenario B (at least among those two choices). But, if Scenario B really means adoption of a significant fraction of the "mechanisms" described on page 33 of the I-D, then it would be, at least for me, a non-starter. A fairly specific MOU (Mechanism 5) seems fine, but, as the text points out, it is hard to imagine even Scenario A without it. But most of the rest of those "mechanisms" seem to me to be strange, actively harmful to either the IETF or ISOC, very risky to the fact and appearance of an independent standards process, or some combination of those unfortunate characteristics.
So, to get a stake in the ground, only the MOU "mechanism" makes obvious sense to me. The others seem either harmful or sufficiently muddled in the details of what they might mean that I think significant clarification would be needed to even evaluate them properly. And I think I'd like to see more discussion about what real problem we are trying to solve before I'd think that added effort would be worth putting in.
--
-------------------------------------------------------------------
"Reality:
Yours to discover."
-- ThinkingCat
Leslie Daigle
leslie@xxxxxxxxxxxxxxx
-------------------------------------------------------------------
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf