Re: Upcoming: further thoughts on where from here

sob@harvard.edu (scott bradner) Wed, 22 September 2004 00:37 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16004; Tue, 21 Sep 2004 20:37:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9vEw-00020Z-O1; Tue, 21 Sep 2004 20:44:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9v5U-0004w2-5H; Tue, 21 Sep 2004 20:34:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9v4l-0004lZ-U4 for ietf@megatron.ietf.org; Tue, 21 Sep 2004 20:33:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15820 for <ietf@ietf.org>; Tue, 21 Sep 2004 20:33:38 -0400 (EDT)
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9vBF-0001xz-4u for ietf@ietf.org; Tue, 21 Sep 2004 20:40:21 -0400
Received: by newdev.harvard.edu (Postfix, from userid 501) id 783E1A569C; Tue, 21 Sep 2004 20:33:07 -0400 (EDT)
To: ietf@ietf.org
Message-Id: <20040922003307.783E1A569C@newdev.harvard.edu>
Date: Tue, 21 Sep 2004 20:33:07 -0400 (EDT)
From: sob@harvard.edu (scott bradner)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Subject: Re: Upcoming: further thoughts on where from here
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2

High order bit:  To me Scenario C contains significant complexity and
risk when compared to Scenario O while providing, in my opinion, no
useful advantages.

some observations:
Both Scenarios depend on the development of a job description for an
admin director of some kind - as has been mentioned on this list by
others I do not think we are all that close to an understanding of what
this job entails.

Both Scenarios depend on the development of descriptions of the tasks to
be contracted for (email service, IETF clerk function etc) - imo, the
timing to accomplish this task is, at best, aggressively optimistic in
the Scenario C document considering the pace of the discussion to date. 

In both Scenarios I could see developing the job description 1st, doing
a job search and, assuming a reasonable candidate could be found, having
the person be hired by the ISOC with a mission to finish up the task
descriptions.  But I do not see it as likely that a description could be
agreed to, the job advertised, an appropriate person found, hired and be
available to start in less than 3 months

I would expect that it would take some time, a month or two, after the
person comes on board before final task descriptions would be ready (it
would seem to be quite important for the admin director to be involved
in finalizing the task descriptions since he or she would be responsible
for ensuring that the contractor(s) provide the services described.

To me that means we are well into the preparations for the "march"
meeting before we might be ready to issue the RFP(s).  That leads me to
the inescapable conclusion that Foretec must be retained to run that
meeting (and maybe the following meeting), and that retention should 
happen asap so that there is no confusion after the DC meeting.

The Scenario C document says that there are 3 prerequisites required
before the option of a corporation can be "considered viable at all"
	1/ IETF consensus on the plan
	2/ ISOC agreement on a support "contract"
	3/ assurance that a corporation would be tax exempt

re: 1/ Considering the level of participation in this discussion on the
IETF list I do not see how one could assert that there was IETF
consensus without an explicit discussion at an IETF plenary - I do not
think that just issuing a last call (as envisioned by the Scenario C
document) would be seen by about anyone as an adequate involvement of
the community.  

re: 2/ the use of the term "contract" to describe an agreement to be a
supporter feels a bit funny to me but, certainly, a common understanding
of the ISOC/IETF relationship would have to be reached (as I mentioned
before, I think there will be a lot of working out of details to come to
such a common understanding )  - it is true that a common understanding
of the relationship would also have to be developed in Scenario O But I
think that would be easier since Scenario O is more of an evolution of
our current relationship not inventing a new one out of whole cloth.

Also, the "contract," as envisioned in the Scenario C document, looks
like it boils down to "ISOC agrees to provide $75K/month."  That seems
to be a very unlikely contract - the ISOC needs to ensure that monies
that it donates are used for purposes that fit within the ISOC's bylaws
and tax exempt role.  I would expect that the ISOC would have to do a
bit more due diligence during the budget process than to blindly accept
the proposed budget numbers.

re: 3/ Of course, there can be no assurance that a corporation will be
tax exempt unless 1/ it already is, or 2/ the IRS rules that it is.
Scenario O covers the 1st case since the ISOC is already tax exempt.
The only way to be sure in Scenario C is to wait until the IRS acts and
that could be many months.  If the 3rd item is truly a prerequisite
then, even if we incorporated the IASF (not a name that rolls of the
tongue) next week the IRS might not rule until next summer.

bottom line: I see lots of risks, many of which are noted in the
document, with the Scenario C approach.  I also see a lot of unknowns
that would need to be worked out. - but on the other side I see nothing
in the Scenario C document that says what advantages there are in
following Scenario C that overcome the risks and unknowns.   In earlier
discussions on this list some of the proponents of the Scenario C
approach basically said that it would make them feel better to have
fewer bolts to blow if we ever decided to get a divorce from the ISOC.
I do not agree that it would take any less time under  Scenario C to
blow the bolts than what is described in Scenario O (considering the
fact that the IETF would have to develop a fundraising arm, far from an
easy task as the ISOC found out).

The Scenario C document more strongly leads me to the conclusion that
forming a separate corporation is the wrong way to go for the IETF.

That is not to say that I think the Scenario O proposal is perfect, I do
not and will have comments on that at a later time, but still the
conclusion is clear to me.

Scott

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf