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

John C Klensin <john-ietf@jck.com> Sun, 12 September 2004 16:22 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 MAA24029; Sun, 12 Sep 2004 12:22:21 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6XBw-0003Tu-C1; Sun, 12 Sep 2004 12:27:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6X5X-00047Z-Vd; Sun, 12 Sep 2004 12:20:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6X51-0003tZ-8S for ietf@megatron.ietf.org; Sun, 12 Sep 2004 12:19:55 -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 MAA23827 for <ietf@ietf.org>; Sun, 12 Sep 2004 12:19:52 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6X9W-0003R0-8v for ietf@ietf.org; Sun, 12 Sep 2004 12:24:35 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1C6X4t-0004TM-2F; Sun, 12 Sep 2004 12:19:47 -0400
Date: Sun, 12 Sep 2004 12:19:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, scott bradner <sob@harvard.edu>, ietf@ietf.org
Message-ID: <00A7150A4512700F34111641@scan.jck.com>
In-Reply-To: <EFB15D2F62C4D0CBEC54E5A4@askvoll.hjemme.alvestrand.no>
References: <20040911210653.A62C48958A@newdev.harvard.edu> <EFB15D2F62C4D0CBEC54E5A4@askvoll.hjemme.alvestrand.no>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
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.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: quoted-printable

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