RE: Options for IETF administrative restructuring

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.

Thanks, Bert

> -----Original Message-----
> From: Aaron Falk [mailto:falk@ISI.EDU]
> Sent: Monday, September 06, 2004 02:53
> To: Wijnen, Bert (Bert)
> Cc: Scott Bradner; ietf@ietf.org
> 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf