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]

 




--On Monday, 06 September, 2004 19:57 +0200 Harald Tveit
Alvestrand <harald@xxxxxxxxxxxxx> wrote:

> Thanks, John!
> 
> --On 6. september 2004 12:08 -0400 John C Klensin
> <john-ietf@xxxxxxx> wrote:
> 
>> 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.
> 
> It seems to me that we are rapidly converging on one point of
> total IETF consensus:
> 
>   Putting the IETF administrative function under ISOC requires
> a documented 
>   IETF-ISOC agreement (call it an MoU, a contract or something
> else - it IS
>   a document, it IS an agreement and it DOES have two parties).
> 
> Agreed?

I think so, although I think, given some of the text in the
report and some other conversations, that I would add to "DOES
have two parties", "each of whom is assumed to be acting in good
faith, out of good intentions, and with the best interests of
the other in mind".   I don't know that needs to be explicit,
and I think those conditions are generally met today, but, as I
tried to say in my note, relying on legal agreements to protect
us if there isn't general agreement about behavior strikes me as
a bad idea.   And, incidentally, if there is a problem in that
area, I think we would hit it with Scenario C as well.

> The thing that left me most uncomfortable with Scenario B as
> described was that it presented a smorgasboard of options
> ("here are ten menu choices - take your pick"), where some of
> them (the MoU) were totally obvious, and some had (in my mind)
> severe disadvantages. So we can't say "we go for scenario B"
> and have the discussion be finished, we have to be able to say
> "Options 1, 3, 5 and 7 make sense, the rest does not, and
> besides, here's option 17 that wasn't in the original
> document".

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.

     john


_______________________________________________

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]