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

sob@harvard.edu (scott bradner) Sun, 12 September 2004 14:33 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 KAA18534; Sun, 12 Sep 2004 10:33:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6VUR-0001oK-Uv; Sun, 12 Sep 2004 10:38:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6VMr-0007Iq-2J; Sun, 12 Sep 2004 10:30:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6VKd-00070D-OW for ietf@megatron.ietf.org; Sun, 12 Sep 2004 10:27: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 KAA18117 for <ietf@ietf.org>; Sun, 12 Sep 2004 10:27:53 -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 1C6VP6-0001j4-1y for ietf@ietf.org; Sun, 12 Sep 2004 10:32:35 -0400
Received: by newdev.harvard.edu (Postfix, from userid 501) id 5EB0D8A941; Sun, 12 Sep 2004 10:27:20 -0400 (EDT)
To: ietf@ietf.org
Message-Id: <20040912142720.5EB0D8A941@newdev.harvard.edu>
Date: Sun, 12 Sep 2004 10:27:20 -0400
From: sob@harvard.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

> 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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf