RE: first steps (was The other parts of the report...)
graham.travers@bt.com Tue, 14 September 2004 08:17 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 EAA14090; Tue, 14 Sep 2004 04:17:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C78a6-0008Qy-Ma; Tue, 14 Sep 2004 04:22:31 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C78Ib-0003D3-2u; Tue, 14 Sep 2004 04:04:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C78Dl-0002P7-Mt for ietf@megatron.ietf.org; Tue, 14 Sep 2004 03:59:26 -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 DAA12775 for <ietf@ietf.org>; Tue, 14 Sep 2004 03:59:24 -0400 (EDT)
From: graham.travers@bt.com
Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C78Id-000855-7R for ietf@ietf.org; Tue, 14 Sep 2004 04:04:27 -0400
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 14 Sep 2004 08:59:43 +0100
Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 08:59:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Sep 2004 08:59:42 +0100
Message-ID: <3D67CCA7D63E714B980D21A038EEA08E0F1529E7@i2km02-ukbr.domain1.systemhost.net>
Thread-Topic: first steps (was The other parts of the report...)
Thread-Index: AcSY5PxGIb9/B0dxSze1fooKsrTsjwBSy8Zg
To: john-ietf@jck.com, harald@alvestrand.no, sob@harvard.edu, ietf@ietf.org
X-OriginalArrivalTime: 14 Sep 2004 07:59:43.0376 (UTC) FILETIME=[CB566100:01C49A30]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable
Subject: RE: first steps (was The other parts of the report...)
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.3 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: quoted-printable
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: graham.travers@bt.com 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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of John C Klensin Sent: 12 September 2004 17:20 To: Harald Tveit Alvestrand; scott bradner; ietf@ietf.org 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 <harald@alvestrand.no> wrote: > > > --On lørdag, september 11, 2004 17:06:53 -0400 scott bradner > <sob@harvard.edu> 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. > > 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. > > How much is this a problem? > > > _______________________________________________ > 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 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- first steps (was The other parts of the report...) scott bradner
- Re: first steps (was The other parts of the repor… Harald Tveit Alvestrand
- Re: first steps (was The other parts of the repor… scott bradner
- Re: first steps (was The other parts of the repor… Margaret Wasserman
- Re: first steps (was The other parts of the repor… John C Klensin
- RE: first steps (was The other parts of the repor… Steve Crocker
- RE: first steps (was The other parts of the repor… Wijnen, Bert (Bert)
- Re: first steps (was The other parts of the repor… Carl Malamud
- What we need done (Re: first steps (was The other… Harald Tveit Alvestrand
- Re: first steps (was The other parts of the repor… John C Klensin
- Re: What we need done (Re: first steps (was The o… avri
- Re: first steps (was The other parts of the repor… Dave Crocker
- Re: first steps (was The other parts of the repor… Harald Tveit Alvestrand
- Re: first steps (was The other parts of the repor… Harald Tveit Alvestrand
- Re: first steps (was The other parts of the repor… Dave Crocker
- RE: first steps (was The other parts of the repor… graham.travers
- RE: first steps (was The other parts of the repor… graham.travers
- RE: first steps (was The other parts of the repor… Steve Crocker
- RE: first steps (was The other parts of the repor… Joel Jaeggli
- IETF 62 (was: Re: first steps) Spencer Dawkins
- Re: IETF 62 (was: Re: first steps) shogunx
- Re: IETF 62 (was: Re: first steps) Michael Richardson
- Re: IETF 62 (was: Re: first steps) Michael Richardson
- Re: IETF 62 (was: Re: first steps) Tim Chown
- Re: IETF 62 (was: Re: first steps) william(at)elan.net
- Re: IETF 62 (was: Re: first steps) Hadmut Danisch
- Re: IETF 62 (was: Re: first steps) Henrik Levkowetz
- Re: IETF 62 (was: Re: first steps) Dick St.Peters
- Re: IETF 62 Lars Eggert
- Re: IETF 62 Sam Hartman
- Re: IETF 62 Lars Eggert
- Re: IETF 62 John C Klensin
- Re: IETF 62 Lars Eggert
- Re: IETF 62 (was: Re: first steps) Mark Allman
- RE: Meeting locations (was IETF 62) Robin Uyeshiro
- Re: IETF 62 Scott Michel
- Re: IETF 62 Michael D Frisch
- Re: IETF 62 Ted Faber