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

Carl Malamud <> Sun, 12 September 2004 19:06 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA05038; Sun, 12 Sep 2004 15:06:26 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C6Zkj-0006Ke-HH; Sun, 12 Sep 2004 15:11:09 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C6Ze7-0004Oh-Dm; Sun, 12 Sep 2004 15:04:19 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C6ZZp-0007RU-RI for; Sun, 12 Sep 2004 14:59:53 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA04603 for <>; Sun, 12 Sep 2004 14:59:52 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C6ZeN-0006Fr-FI for; Sun, 12 Sep 2004 15:04:35 -0400
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id i8CIxF6Y001195; Sun, 12 Sep 2004 11:59:15 -0700 (PDT)
Received: (from carl@localhost) by (8.12.2/8.12.2/Submit) id i8CIxF3A001194; Sun, 12 Sep 2004 11:59:15 -0700 (PDT)
From: Carl Malamud <>
Message-Id: <>
In-Reply-To: <>
To: John C Klensin <>
Date: Sun, 12 Sep 2004 11:59:14 -0700
Organization: Memory Palace Press
X-Winch: Warn 9.5i
X-Mailer: ELM [version 2.4ME+ PL94 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand <>, scott bradner <>,
Subject: Re: first steps (was The other parts of the report...)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit

Hi John -

> 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.   

Agreed, with the addition of Steve Crocker's point about the
meeting agenda being part of what you call the "[standards] secretariat"
and what I termed the "Clerk's Office".

> 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.  

I agree with you.  My personal view is that a better strategy
for that piece is to attempt to negotiate a sole source contract
with CNRI.  I don't think we understand the process (indeed
we probably haven't defined the process enough) to do an RFP.
Just my view, and there are reasonable opinions to the contrary.

> 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.

That's kind of how I wrote the RFP.  Again, just my personal view,
it didn't seem prudent or wise to attempt to change all of our
horses in mid-stream.  Of course, if we'd like to stick with CNRI
with some functions, it is important that we begin a dialogue
with them.  It isn't easy for them since they aren't sure what
the IETF would like to do.

I've seen several comments that the mailing list or web presence
functions seem pretty straightforward to issue an RFI (a request
for information) to see what our options are.  By drawing a
broader brush than just mail or web, I think we could get a
pretty good idea of what kind of support we might get in the
way of good proposals.  That's why I recommended a broader
"network presence" function be considered.

In summary, I outlined three pieces:

1. meeting planning
2. core network
3. clerk's office

We could do sole source procurement on 0-3 of those pieces, or
an RFP on 0-3 of those pieces, or we could pick a different
decomposition.  I don't think you can do both a sole source 
procurement and an RFP on the same piece, though, so that is a 
decision point.  And, there is a bit of urgency to make that
decision since it is hard to move forward during a
transition period.  (I used the word "urgent" instead
of, say, "panic" ... we do have some time to get this right,
but it would be nice to move along with all due deliberate



Ietf mailing list