The other parts of the report....

Harald Tveit Alvestrand <harald@alvestrand.no> Fri, 10 September 2004 07:39 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 DAA00524; Fri, 10 Sep 2004 03:39:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5g4C-0008GI-Mp; Fri, 10 Sep 2004 03:43:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5fyL-0006JP-U0; Fri, 10 Sep 2004 03:37:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5ft5-0005Nv-59 for ietf@megatron.ietf.org; Fri, 10 Sep 2004 03:32:03 -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 DAA00061 for <ietf@ietf.org>; Fri, 10 Sep 2004 03:32:01 -0400 (EDT)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5fx6-00088i-64 for ietf@ietf.org; Fri, 10 Sep 2004 03:36:12 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D6BD61BDE for <ietf@ietf.org>; Fri, 10 Sep 2004 09:31:31 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16397-08 for <ietf@ietf.org>; Fri, 10 Sep 2004 09:31:29 +0200 (CEST)
Received: from [192.168.1.4] (145.80-202-211.nextgentel.com [80.202.211.145]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99D8161AD5 for <ietf@ietf.org>; Fri, 10 Sep 2004 09:31:29 +0200 (CEST)
Date: Fri, 10 Sep 2004 09:31:29 +0200
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: ietf@ietf.org
Message-ID: <B459811FDF975D96B27DB3C9@askvoll.hjemme.alvestrand.no>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Subject: 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.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit

Now that we have had a long and informed debate about the question of 
organizational form of the IETF administrative support structure, I feel 
that I know a lot more about what can achieve IETF consensus on the 
subject....

However, that's not the only thing in the consultant report. I wonder if 
those other parts are "so obvious that we should just do them", "too far 
off to be worth commenting on", or whether people haven't yet gotten to 
them?

I'm particularly thinking of the following (from the index):

     3.1   Recommendation 1: Hire An Administrative Director  . . . . 20
     3.2   Recommendation 2: Establish Contracts for Core Services  . 21
       3.2.1   Details of Potential RFP Components  . . . . . . . . . 24
     3.3   Recommendation 3: Provide Timely and Uniform Financial
           Reporting  . . . . . . . . . . . . . . . . . . . . . . . . 27
     3.4   Recommendation 4: More Focus on Archives . . . . . . . . . 28

and the following from section 3.2:

   There are thus a spectrum of options available within the extremes of
   RFP and sole source procurement.  This report recommends one of the
   following three strategies:
   o  *Strategy 1.* Issue an RFP for all core secretariat services.
      This would allow the current provider to bid and thus establish
      contract terms upon a successful bid, but would also allow other
      vendors to compete.
   o  *Strategy 2.* Attempt to negotiate a sole source procurement on
      all of the functions, but after a designated time-out period
      (e.g., 30 days), if the negotiation is not successful, issue an
      RFP.  The term of the sole source procurement could be a subject
      of the negotiation, or a fixed term (e.g., 1 year) could be
      established a priori.  The intention would be to issue an RFP for
      the subsequent contractual period.
   o  *Strategy 3.* Some combination of the two above options.  For
      example, attempt a sole source procurement on two of the three
      functions, and issue an RFP for the third.

......

   Thus, the author of this report recommends that, if a hybrid strategy
   of attempting a sole source contract on two functions and an RFP is
   used for the third function, that core network services is a good
   candidate for an RFP and meeting planning and "Clerk" functions would
   be a good candidate for sole source procurement negotiations.

I feel some urgency to make sure that we have meeting arrangements in place 
for 2005 - without imperiling our ability to make the best long-term 
choices for the IETF.

So - I'd like some coments here.

Help?

                         Harald



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf