Re: Appointment of a Transport Area Director

"Loa@pi.nu" <loa@pi.nu> Mon, 04 March 2013 15:47 UTC

Return-Path: <loa@pi.nu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC321F8C20 for <ietf@ietfa.amsl.com>; Mon, 4 Mar 2013 07:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.652
X-Spam-Level:
X-Spam-Status: No, score=-99.652 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phkfhcvC5hIN for <ietf@ietfa.amsl.com>; Mon, 4 Mar 2013 07:47:31 -0800 (PST)
Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8867A21F85F3 for <ietf@ietf.org>; Mon, 4 Mar 2013 07:47:30 -0800 (PST)
Received: from [192.168.1.84] (90-227-238-197-no15.business.telia.com [90.227.238.197]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 9B5177FE07; Mon, 4 Mar 2013 16:47:27 +0100 (CET)
References: <21B86E13-B8DA-4119-BBB1-B5EE6D2B5C1D@ietf.org> <51330179.3040500@gmail.com> <919840EE-BEC8-4F82-8D3C-B116698A4262@gmx.net> <1D88E6E9-33DE-4C4D-89F4-B0B762155D6F@standardstrack.com> <D4D47BCFFE5A004F95D707546AC0D7E91F77BA46@SACEXCMBX01-PRD.hq.netapp.com> <3CB8992B-212A-4776-95FE-71CA1E382FFF@standardstrack.com> <513376DB.7000200@dcrocker.net> <E22ACC99-B465-4769-8B59-BB98A7BA93DF@gmx.net> <79E77523-3D92-4CE9-8689-483D416794EF@standardstrack.com> <D4D47BCFFE5A004F95D707546AC0D7E91F780D2F@SACEXCMBX01-PRD.hq.netapp.com> <071C6ED7-352C-4E74-A483-F5E7A3270FA5@gmail.com> <C726E531-57DC-4C42-9053-1394983126D6@vigilsec.com>
In-Reply-To: <C726E531-57DC-4C42-9053-1394983126D6@vigilsec.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <62A175EA-01D1-466B-95BC-C506830D0CBD@pi.nu>
X-Mailer: iPhone Mail (10B146)
From: "Loa@pi.nu" <loa@pi.nu>
Subject: Re: Appointment of a Transport Area Director
Date: Mon, 04 Mar 2013 16:47:25 +0100
To: Russ Housley <housley@vigilsec.com>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 15:47:32 -0000

+1, if anything we need to  move away from the ITU model. 

/Loa

Skickat från min iPhone

4 mar 2013 kl. 16:26 skrev Russ Housley <housley@vigilsec.com>:

> 
> 
> The leadership in the ITU does not read the documents.  Why?  Their job is to make sure that the process was followed.
> 
> The IESG needs to make sure the process was followed too.  But, the IESG also has a quality check job.  I would hate for this debate to lead to a step toward the ITU model.
> 
> Russ
> 
> 
> On Mar 4, 2013, at 8:38 AM, Ralph Droms wrote:
> 
>> 
>> On Mar 4, 2013, at 8:07 AM 3/4/13, "Eggert, Lars" <lars@netapp.com> wrote:
>> 
>>> Hi,
>>> 
>>> On Mar 4, 2013, at 13:18, Eric Burger <eburger@standardstrack.com> wrote:
>>>> I will say it again - the IETF is organized by us.  Therefore, this situation is created by us.  We have the power to fix it.  We have to want to fix it.  Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it.
>>> 
>>> what is "the fix"?
>> 
>> I think part of the fix is to consider more than just the IESG.  We need to take look at the work across the IETF that goes into producing our documents and see if we can redistribute or reduce that work to lessen the workload on ADs ... if the goal is, indeed, to reduce the time commitment on individual ADs.
>> 
>>> 
>>> The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out.
>> 
>> But that model doesn't scale.  What about, for example, ensuring the quality in the documents as they come out of the WGs?, which distributes the work rather than concentrating it in IESG?
>> 
>>> This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time.
>> 
>> Agreed.
>>> 
>>> I don't see how we can maintain the quality of our output if we turn the AD position into a management job.
>>> Especially when technical expertise is delegated to bodies that rely on volunteers. Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, and it's also difficult to get them to stick to deadlines. They're volunteers, after all. 
>>> 
>>> And, as Joel said earlier, unless we delegate the right to raise and clear discusses to the directorates as well, the AD still needs to be able to understand and defend a technical argument on behalf of a reviewer. If there is a controversy, the time for that involvement dwarfs the time needed for the initial review.
>> 
>> Sure, for any specific issue.  My personal experience is that I spend more time on the ordinary review processes than I do summing up the time on extra-ordinary technical arguments.
>> 
>>> 
>>> There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents...
>>> 
>>> Lars      
>> 
>> - Ralph
>> 
>> 
>