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

From: [email-masked] (scott bradner)
Date: Sun, 12 Sep 2004 10:27:20 -0400 (EDT)

> If we follow the combo path, we also commit ourselves to breaking the
> function into multiple pieces - which may discriminate against a solution
> where other suppliers of services may be able to do "the whole thing" more
> effectively than they can do parts of it.

that may be the case but (imo) having some of the functions separable
gives us more flexibility in the future - for example there are
quite a few companies which run mailing lists as a core business - it
seems to me that we are in a stronger position to ensure that the
mailing list management function is well done by having alternative
vendors in the wings - I think this can be done for some specific 
functions (mailing list and meeting management seem to fit in this
category) while other functions would not be easily portable (for
example, the clerk function requires an extensive understanding 
of how the IETF works inside and would be quite hard to swap 
to a new vendor)

thus, I think that the combo way provides us the better way

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 12 Sep 2004 20:41:00 +0200

Exactly, I agree with Steve here.

> -----Original Message-----
> From: Steve Crocker [mailto:[email-masked]]
> Sent: Sunday, September 12, 2004 18:51
> To: 'Margaret Wasserman'; 'scott bradner'; [email-masked]
> Subject: RE: first steps (was The other parts of the report...)
> 
> 
> 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.
> 
> Steve
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Margaret Wasserman
> > Sent: Sunday, September 12, 2004 12:00 PM
> > To: scott bradner; [email-masked]
> > 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
> >

---

From: [email-masked]
Date: Tue, 14 Sep 2004 08:59:42 +0100

Perhaps it hasn't been said because it's obvious: operationally, if you ensure *simultaneous* placing and renewal of all the contracts for functional components, people have the opportunity to bid for as many functional components as they can handle.  

	Regards,

	Graham Travers

	International Standards Manager
	BT Group

	e-mail:   [email-masked]
	tel:      +44(0) 1359 235086
	mobile:   +44(0) 7808 502536
      HWB279, PO Box 200,London, N18 1ZF, UK

BT Group plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the BT Group plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
Sent: 12 September 2004 17:20
To: Harald Tveit Alvestrand; scott bradner; [email-masked]
Subject: Re: first steps (was The other parts of the report...)

Harald,

Let me try  a different answer from Scott's, with just about the same conclusion.  

At the risk of being too specific about this, the "meeting planning" function(s) and the "[standards] secretariat" one(s) have almost nothing to do with each other --other than, in our
case, some rather important history.   It would be very rare to
find one organization that would be equally skilled at actually doing both. Creating an opportunity for one organization to "win" a bid by strength in one area while dragging the other one
along is just looking for trouble.   Now it is still an open
question whether one wants to parse the situation into even more tasks, such as separating "secretariat" from "mailing lists" and/or "archiving and web site maintenance", and potentially different groups.  But those two task areas seem really different.

To further complicate things, I personally don't think the IETF has yet figured out enough about what it really wants from the secretariat part of the function and reached enough consensus on that to justify any RFP-writing.  In this respect, the material in The Report seems to me to be inadequate unless the definition of what the IETF wants from the secretariat is "whatever the IESG or its leadership decide they want on a given day".  That definition would, IMO, be bad for the IETF and would call the intelligence of anyone who would respond to the RFP into question (even though it would permit the IETF to have a lot of control). 

Now, if one separates out the tasks and constructs the RFPs and evaluation process properly, presumably nothing would prevent one organization from coming in and saying "we actually have all of these skills, can justify your giving us the whole cluster of tasks, and can give you a price break if you sign up with us for
more than one of then".   That is actually done fairly routinely
in some settings.  If there are viable candidates, it would give you what you seem to be looking for below without imposing a rather strange constraint on combinations of skills.

   john

--On Sunday, 12 September, 2004 16:16 +0200 Harald Tveit Alvestrand <[email-masked]> wrote:

> 
> 
> --On lørdag, september 11, 2004 17:06:53 -0400 scott bradner 
> <[email-masked]> 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)
> 
> 
> One thing that worries me about the "piecemeal" approach with some 
> functions under sole source is that for a long time we've been 
> operating with all functions in one body (except for RFC Editor and 
> IANA). There are some economies of scale with integrating those 
> functions.
> 
> function into multiple pieces - which may discriminate against a 
> solution where other suppliers of services may be able to do "the 
> whole thing" more effectively than they can do parts of it.
> 
> How much is this a problem?
> 
>