RE: Scenario C or Scenario O ?
"Tony Hain" <firstname.lastname@example.org> Fri, 24 September 2004 05:25 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [22.214.171.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24918; Fri, 24 Sep 2004 01:25:46 -0400 (EDT)
Received: from megatron.ietf.org ([126.96.36.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAihU-0001xg-6e; Fri, 24 Sep 2004 01:32:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAiTa-0003uF-CN; Fri, 24 Sep 2004 01:18:34 -0400
Received: from odin.ietf.org ([188.8.131.52] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAiSf-0003nq-9s for email@example.com; Fri, 24 Sep 2004 01:17:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [184.108.40.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22910 for <firstname.lastname@example.org>; Fri, 24 Sep 2004 01:17:36 -0400 (EDT)
Received: from bdsl.220.127.116.11.gte.net ([18.104.22.168] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAiZQ-0001k7-NS for email@example.com; Fri, 24 Sep 2004 01:24:47 -0400
Received: from eaglet (127.0.0.1:4373) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <S6DA77> for <firstname.lastname@example.org> from <email@example.com>; Thu, 23 Sep 2004 22:20:27 -0700
From: Tony Hain <firstname.lastname@example.org>
To: 'Sally Floyd' <email@example.com>, firstname.lastname@example.org
Date: Thu, 23 Sep 2004 22:17:14 -0700
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
Subject: RE: Scenario C or Scenario O ?
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-Spam-Score: 0.8 (/)
Well to be clear, I bothered to comment on scenario O since I believe it is really the only viable path. It id always nice to do the 'independent' thing, but basic economics says it won't fly in the short term, and will always be more costly than O in the long term. A non-profit corporation that has no cash reserves going in and is responsible for a collection of tasks that recent budgets show exceeds available income is demanding failure. Even if that were not an issue, the hidden costs of benefits & insurance, accountants & tax filings, etc. are much higher for a single person company than adding one person to an existing company. (I assume no matter how this goes we are really talking about a single person. Yes there are comments about growing it, but if we really believe in a modular pod that can be moved at a moments notice, the only realistic way to pull that off is for a single person to manage contracts that can be canceled or transferred because one person can quit/rehire without substantial effort.) So the bottom line is basic economics argue for O over C. /rant It is time for the IETF to grow out of its adolescent stupor and recognize that it is neither invincible nor all-powerful. It is one player in grand enterprise, and has the potential to do well if it accepts that 'going it alone' is not the goal. Each time administrative issues or external relationships come up there is an outcry of 'we can do it alone'. On the face of it this is nonsense, yet it persists like a child persists in defying a parent. If we were simply asking ISOC to take over, I could understand (but would probably still disagree with) the resistance. As I read it scenario O provides all the perceived independence benefits of C, with reduced costs (both short and long term), lower risk, and a clearer interface for those organizations that currently provide funding for the RFC Editor/IANA and related activities (and it already borders on too confusing for the funding bodies). Scenario C says nothing more than 'we can do this alone' without recognizing the real long term consequences. It is time to grow up and recognize the limits of the organization and focus on the core competencies. rant/ Tony > -----Original Message----- > From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of > Sally Floyd > Sent: Thursday, September 23, 2004 1:34 PM > To: email@example.com > Subject: Scenario C or Scenario O ? > > I think that either Scenario is perfectly workable, but my > own preference is for Scenario C. I have read the email from John and > others about the possible dangers of incorporation, and the added > complexity, etc., and they strike me as valid concerns about Scenario > C. But my own inclinations are to agree with Ted Hardie's > comments about functional differentiation, posted September 7. > > For me one of the goals would be for the administrative > support functions to be provided in a manner that was as simple, > straightforward, and un-encumbered *as possible* (given that neither > scenario is either simple, straightforward, or un-encumbered). And > my best guess, right now, is that having the IETF's administrative > support functions as separate as possible from the more complex > (and considerably more important) policy and education missions of > ISOC would be a good thing for accomplishing the administrative > support functions. (It also makes perfect sense to me that > others would not see Scenario C as the more simple, straightforward, > or unencumbered of the two approaches, looking from a different lens, > so probably those aren't particularly useful words to introduce...) > > - Sally > http://www.icir.org/floyd/ > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf