Re: On the difference between scenarios A and B in Carl's report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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:
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.
[and]
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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]