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
- The "Clerk" function and Standards throughput and… John C Klensin
- Re: The "Clerk" function and Standards throughput… Harald Tveit Alvestrand
- Re: The "Clerk" function and Standards throughput… John C Klensin
- Re: The "Clerk" function and Standards throughput… Harald Tveit Alvestrand
- Re: The "Clerk" function and Standards throughput… John C Klensin
- Re: The "Clerk" function and Standards throughput… Harald Tveit Alvestrand
- Re: The "Clerk" function and Standards throughput… John C Klensin
- Re: The "Clerk" function and Standards throughput… Carl Malamud
- Re: The "Clerk" function and Standards throughput… John C Klensin
- RE: The "Clerk" function and Standards throughput… Tony Hain
- Re: The "Clerk" function and Standards throughput… Carl Malamud