RE: Scenario C or Scenario O ?

"Tony Hain" <> Fri, 24 September 2004 05:25 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA24918; Fri, 24 Sep 2004 01:25:46 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CAihU-0001xg-6e; Fri, 24 Sep 2004 01:32:56 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CAiTa-0003uF-CN; Fri, 24 Sep 2004 01:18:34 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CAiSf-0003nq-9s for; Fri, 24 Sep 2004 01:17:37 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA22910 for <>; Fri, 24 Sep 2004 01:17:36 -0400 (EDT)
Message-Id: <>
Received: from ([] by with esmtp (Exim 4.33) id 1CAiZQ-0001k7-NS for; Fri, 24 Sep 2004 01:24:47 -0400
Received: from eaglet ( by with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <S6DA77> for <> from <>; Thu, 23 Sep 2004 22:20:27 -0700
From: Tony Hain <>
To: 'Sally Floyd' <>,
Date: Thu, 23 Sep 2004 22:17:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcShsDuhlxvTOycMR5S6I11LTAw8lQAGFn0Q
In-Reply-To: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Subject: RE: Scenario C or Scenario O ?
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: 7bit

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.

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.



> -----Original Message-----
> From: [] On Behalf Of
> Sally Floyd
> Sent: Thursday, September 23, 2004 1:34 PM
> To:
> 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
> _______________________________________________
> Ietf mailing list

Ietf mailing list