Harald,
While I think this analysis and the distinctions you draw are
reasonable, I think the presentation in the document about the
difference between "A" and "B" is deeply flawed in that it seems
to present two options, neither of which is acceptable. Your
note hints about intermediate options (as, in fairness, does the
document introduction), but I don't see how we are going to get
there efficiently and with the clear backing of the community
that I think is necessary: the IETF list is not traditionally a
good mechanism for fine-tuning text.
In particular, if one concludes, as I gather you have, at an
"Scenario A", with no additional statements or constraints, is
insufficient, that doesn't suggest to me that we should go
nearly as far as "Scenario B" seems to suggest. As the
"Problem Statement" effort pointed out, the IETF has a somewhat
uncomfortable history of simply ignoring provisions of process
documents that prove uncomfortable (and BCP status doesn't seem
to help), so trying to bind the IETF and ISOC more strongly by
"legal" constraints may not mean much. I believe, nonetheless,
that clearer statements of mutual understanding and intent
(through MOUs or otherwise) are always helpful. I also note,
with Carl, the risk that "more up-front definition is sometimes
a good thing, but can also lead to a great deal of time solving
problems that don't exist".
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 I am left close to the question that prompted your response,
with little additional information from that response. I can't
parse the difference between "scenario A with MOU and maybe some
other things to be developed as needed" and "scenario B with MOU
but without pointless or risky tampering with how ISOC is
organized" ... that is, unless we take Scenario B as requiring
that everything be figured out and chiseled into granite before
we do anything. And I suggest (and will suggest in more detail
in an upcoming note) that anything that can wait long enough for
the granite-chiseling is something that probably doesn't need to
be done at all.
best,
john
--On Monday, 06 September, 2004 09:32 +0200 Harald Tveit
Alvestrand <harald@xxxxxxxxxxxxx> wrote:
> Following up on Leslie's mail of Friday, and a number of
> posters (Brian, Scott, Margaret) who have said something on
> the order of "I think I prefer A or B, but I don't understand
> the difference"..... my particular perspective..... in order
> to avoid misunderstandings, I'll define a few terms first, as
> used in this memo:
>
> - Bylaws (a bylaw?) is a document that tells how a formally
> constituted organization expects itself to behave.
>
> - An MOU is a document that tells the reader how two
> organizations are supposed to behave in relation to each other.
>
> - An IETF (Procedure) BCP is a document that tells the IETF
> how the IETF expects the IETF to behave. So it may be
> something like a bylaw for the IETF.
>...
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf