RE: first steps (was The other parts of the report...)

"Steve Crocker" <> Sun, 12 September 2004 16:53 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA25675; Sun, 12 Sep 2004 12:53:11 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C6Xfn-0003y6-83; Sun, 12 Sep 2004 12:57:55 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C6XZJ-0000Ad-Kv; Sun, 12 Sep 2004 12:51:13 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C6XYj-0008Vs-Bf for; Sun, 12 Sep 2004 12:50:37 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA25626 for <>; Sun, 12 Sep 2004 12:50:34 -0400 (EDT)
Received: from ([] helo=EXECDSL.COM) by with esmtp (Exim 4.33) id 1C6XdF-0003w9-Gq for; Sun, 12 Sep 2004 12:55:18 -0400
Received: from [] (HELO SCROCKER) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7556338; Sun, 12 Sep 2004 12:49:52 -0400
From: Steve Crocker <>
To: 'Margaret Wasserman' <>, 'scott bradner' <>,
Date: Sun, 12 Sep 2004 12:50:30 -0400
Message-ID: <004801c498e8$9d0917f0$6401a8c0@SCROCKER>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2742.200
In-reply-to: <p06020401bd6a1b55497f@[]>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
Subject: RE: first steps (was The other parts of the report...)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit

A brief comment on one specific aspect of meeting planning...

In broad terms, the planning for a meeting is partionable, rather
cleanly, into two pieces.  One is the "envelope" of arranging for the
hotel, an inventory of large and small meeting rooms, the terminal room,
the external network connectivity, the food and perhaps a few other
things I've left out.  This "envelope" is reasonably constant and
reasonably easy to specify.

The other part of meeting planning is the assignment of WGs, BOFs and
other events to the specific rooms.  This requires intimate knowledge of
the areas and other relationships to avoid scheduling conflicts, work
out priorities and maintain communication with all the relevant people.

I believe the former could be farmed out, if desired, although this gets
a bit complicated because it includes finding sponsors and making
arrangements for appropriate Internet service.  The latter is tied quite
closely, in my opinion, to the year round support of the WGs and IESG.

I don't have an opinion as to whether the envelope part of the meeting
planning *should* be farmed out to a separate organization.  I'm only
commenting here that the tasks divide reasonably cleanly.  That is, to
first order, an IETF meeting needs a plenary room, about ten working
group rooms, a terminal room, and a handful of side rooms for auxiliary
purposes.  That's a spec that can be sent out to hotels and meeting
planners around the world.


> -----Original Message-----
> From: [] On 
> Behalf Of Margaret Wasserman
> Sent: Sunday, September 12, 2004 12:00 PM
> To: scott bradner;
> Subject: Re: first steps (was The other parts of the report...)
> Hi Scott,
> At 5:06 PM -0400 9/11/04, scott bradner wrote:
> >imo it would least disruptive to follow option #3 (combo 
> path) and try 
> >to negotiate a sole source contract with Foretec/CNRI for what Carl 
> >called the clerk function and maybe some other functions 
> (imo it would 
> >be better to outsorce the management of the mailing lists and their 
> >archives to a company in that business)
> Mailing list management and web hosting (not content) are two obvious 
> candidates for separate contracts if we choose to go with a 
> multi-part RFP process.  These items are quite independent and 
> non-IETF specific.
> Meeting planning is another chunk that could be considered 
> separately, but the way we do it today has a lot of tie-ins to IETF 
> activities -- rules/notices about WG vs. BOF scheduling, proceedings, 
> network, terminal rooms, multicast, sponsorship, etc.  So, if we 
> outsource the meeting planning separately from the "clerk" function, 
> we would have to carefully define the line between the two,  and that 
> line may not be quite where it lies inside Foretec today.
> Also, even if we somehow outsource a few of the more 
> separable/generic tasks independently, there is still a large amount 
> of IETF-specific work that needs to be done by someone -- I-D 
> handling, supporting the IESG review/approval process, handling IPR 
> notices, keeping track of WG charters, maintaining our web content, 
> etc.  It would not be easy to outsource these functions to multiple 
> groups.  It would require extensive effort to define the interfaces 
> between the different functions, and a lot of duplicate work to train 
> multiple groups in the details of the IETF processes and culture.
> I have some concerns that if we try to break off a few of the simpler 
> chunks, the effort of coordinating between those chunks may be larger 
> than the benefits that would accrue from allowing competition in the 
> mailing list management, web hosting and meeting planning areas.  So, 
> this is something we should think about carefully.  A multi-part RFP 
> process that allows organizations to submit multi-part bids (i.e.  if 
> we run the clerk's office,  we will also do meeting planning for $XXX 
> ) might give us some insight into whether ecomomies of scale make it 
> cheaper to go with a single provider for all services, or if it 
> actually works out that it is cheaper/better for some functions to be 
> provided by people who specialize in them.
> Margaret
> _______________________________________________
> Ietf mailing list

Ietf mailing list