Re: The "Clerk" function and Standards throughput and quality

John C Klensin <john-ietf@jck.com> Thu, 07 October 2004 12:49 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 IAA12016; Thu, 7 Oct 2004 08:49:53 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFXsD-0001tq-G3; Thu, 07 Oct 2004 08:59:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXeF-0001V4-Qb; Thu, 07 Oct 2004 08:45:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXJQ-0006fk-GR for ietf@megatron.ietf.org; Thu, 07 Oct 2004 08:24:00 -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 IAA10402 for <ietf@ietf.org>; Thu, 7 Oct 2004 08:23:58 -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 1CFXT7-0000M0-JB for ietf@ietf.org; Thu, 07 Oct 2004 08:34:02 -0400
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1CFXJO-000F1r-3u; Thu, 07 Oct 2004 08:23:58 -0400
Date: Thu, 07 Oct 2004 08:23:55 -0400
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, ietf@ietf.org
Message-ID: <A5F683548DFE08A93FC54F4F@[192.168.2.227]>
In-Reply-To: <EA9E63E57AA9817F7F7228F8@askvoll.hjemme.alvestrand.no>
References: <23AB4F180D939FC980291347@scan.jck.com> <990C270B37EED7014A53D4E3@B50854F0A9192E8EC6CDA126> <BC3CD23742524284F7EC44AC@scan.jck.com> <A8EF0E1A5432B71E3F9AA932@askvoll.hjemme.alvestrand.no> <57088C56997A0D4816E39CE8@[192.168.2.227]> <EA9E63E57AA9817F7F7228F8@askvoll.hjemme.alvestrand.no>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Subject: Re: The "Clerk" function and Standards throughput and quality
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: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit


--On Thursday, October 07, 2004 7:53 AM +0200 Harald Tveit 
Alvestrand <harald@alvestrand.no> wrote:

>
>
> --On onsdag, oktober 06, 2004 17:50:04 -0400 John C Klensin
> <john-ietf@jck.com> wrote:
>
>>
>>
>> --On Wednesday, October 06, 2004 1:07 PM +0200 Harald Tveit
>> Alvestrand <harald@alvestrand.no> wrote:
>>
>>>
>>> I do think our thoughts run very much in parallel - I'll be
>>> interested to hear more of why you think the "scenario O"
>>> organizational format will make it hard to make those support
>>> functions work.
>>
>> Again a misunderstanding -- I don't see "Scenario O" as being
>> either better or worse in regard to the above than any other
>> scenario.  My concern is with the definition of the Clerk
>> function, which is scenario-independent.
>
> Thanks for the clarification!
>
> I thought you might be pointing at the "one staff member -
> rest of the work is contracts", which is a common feature to
> scenarios C and O. If "all" that is required is to modify the
> description of the "clerk" function, that needs to be done
> before we call for interested parties - it is not on the
> critical path to adopting one scenario for implementation
> (although all clarification early is good).

Harald,

I think the "one staff member" story is unrealistic as well. 
But, as you say, it is shared between C and O.  It is, by some 
creative definition-making, a bit easier for O because of the 
possibility of borrowing/sharing staff from/with ISOC.  But the 
fact remains that the document calls out several  more staff 
roles than the one employee it asks for.  Whether those staff 
members are "employees" or contractors working on an individual 
commitment basis (rather than hiring an organization to do the 
job without picking individual personnel) is, IMO, 
hair-splitting to make the staff look smaller, not a matter of 
substance.  It would be a matter of substance if it 
significantly changed either costs of management effort, but 
whether such people are employees or contractors doesn't help 
with the management and may actually increase costs.

This is one of my more general objections to the report -- in 
areas like the personnel one and how staffing roles are 
presented, it appears (intentionally or not) to be organized in 
such a way as to impede community understanding of what is being 
proposed.  But, again, this doesn't impact which Scenario is 
more appropriate, nor does it change the urgency or priorities 
of getting the relevant issues resolved.

    john
b


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