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

Harald Tveit Alvestrand <> Mon, 13 September 2004 10:09 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id GAA12308; Mon, 13 Sep 2004 06:09:42 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C6nqy-00045g-6V; Mon, 13 Sep 2004 06:14:35 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C6njr-00036l-G3; Mon, 13 Sep 2004 06:07:11 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C6nht-0002xJ-VJ for; Mon, 13 Sep 2004 06:05:11 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id GAA12164 for <>; Mon, 13 Sep 2004 06:05:06 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C6nmW-000425-Fq for; Mon, 13 Sep 2004 06:09:59 -0400
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 4F58C61B92; Mon, 13 Sep 2004 12:04:35 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 30684-07; Mon, 13 Sep 2004 12:04:33 +0200 (CEST)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id D37AE61AD4; Mon, 13 Sep 2004 12:04:32 +0200 (CEST)
Date: Mon, 13 Sep 2004 12:04:21 +0200
From: Harald Tveit Alvestrand <>
To: John C Klensin <>,
Message-ID: <06FA98100EA238EA6546E721@B50854F0A9192E8EC6CDA126>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mulberry/3.1.5 (Win32)
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
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: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit

--On 12. september 2004 12:19 -0400 John C Klensin <> 

> 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 would question that.
It is true that we have not collected enough information in one place to 
get  a proper description, but if you add together:

- the Tao of IETF
- the current public descriptions of IESG and IETF procedures
- the (expired) draft-iesg-procedures document
- the list of things that we expect the secretariat to archive, publish and 
update (WG charters, IPR statements, liaison statements, I-Ds, meeting 

I actually think we are reasonably close to a description.

I had one series of conversations where I tried to explain what the 
secretariat does, and ended up with a puzzled "but where's the big 
expensive problem?" - our activities may be far less extraordinary than we 
may think.

One reason why we've done less on this activity than on the organizational 
structure is, I believe, because there's no real big gotcha here - we know 
approximately what the secretariat does; on the other hand, we have 
uncovered some real disagreement on how control of the support functions 
SHOULD be organized - and unless we resolve that, talking about the content 
of the secretariat contract is meaningless - we can't make a contract 
without having a basis from which to make it.

And that's what the "scenarios" threads are all about.


Ietf mailing list