Wijnen, Bert (Bert) wrote:
Aaron,
I hope you had noticed that I stated that IF we were to choose
between A and B, that my preference would be for B. And indeed,
the below argument for C would then be (one of) my reason(s) for
choosing B over A.
I am not sure that C creates really so much more "distance" as what we
would create with B. Some of the extra safeguards that I see we would
want with B would also create some "distance".
The benefit of C is (in my opinion) that it does not assume a default
(strong) relationship, but that it requires both organisations to
actively want to continue/renew the relationship every so many years.
And such checkpoints are nice and good points where the relationship
can (and in my view will) be evaluated and if any friction has developed
then at such checkpoints the friction can (timely and naturally) be
corrected.
That is true enough, but is it really enough to justify the overhead
costs and work of creating a new legal entity? Certainly the agreements
under scenario B (or even A) should include "explosive bolts" in case
the IETF becomes unsatisfied, and regular reviews are an execllent idea.
Brian
Thanks, Bert
-----Original Message-----
From: Aaron Falk [mailto:falk@xxxxxxx]
Sent: Monday, September 06, 2004 02:53
To: Wijnen, Bert (Bert)
Cc: Scott Bradner; ietf@xxxxxxxx
Subject: Re: Options for IETF administrative restructuring
On Sep 3, 2004, at 3:06 PM, Wijnen, Bert (Bert) wrote:
If we were to go for option C, then in my personal view, it would have the
serious benefit that we are ALWAYS (from day 1) responsible to make sure
things work well. And we need to re-negotiate every so often if we want
to keep the relationships that we have or if we want to change them.
So in my view we would run far less risk to ever get in a similar situation
as where we are today. Yep... initially it will cost us some more money and
effort I suspect. But I think it is worth the price.
Bert-
It seems to me that this is an argument for option B as well s C. My
take from the history you laid out is that what was missing was a
clearly articulated set of relationships which defined roles and
responsibilities (and possibly instructions for disentangling if things
went bad. AFAICT, this could just as easily be put into option B
without creating an (imo undesirable) increased distance between IETF
and ISOC.
--aaron
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf