Re: Appointment of a Transport Area Director

Eric Burger <eburger@standardstrack.com> Sun, 03 March 2013 12:38 UTC

Return-Path: <eburger@standardstrack.com>
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 EEEBC21F86CD; Sun, 3 Mar 2013 04:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.312
X-Spam-Level:
X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fr54TzkXlGC; Sun, 3 Mar 2013 04:38:01 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 54CAD21F86BC; Sun, 3 Mar 2013 04:38:01 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:52494 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UC8Ay-0007aY-Dv; Sun, 03 Mar 2013 04:38:00 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_79F81348-F74C-43AA-A329-294445A7A03D"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Appointment of a Transport Area Director
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <919840EE-BEC8-4F82-8D3C-B116698A4262@gmx.net>
Date: Sun, 03 Mar 2013 07:37:59 -0500
Message-Id: <1D88E6E9-33DE-4C4D-89F4-B0B762155D6F@standardstrack.com>
References: <21B86E13-B8DA-4119-BBB1-B5EE6D2B5C1D@ietf.org> <51330179.3040500@gmail.com> <919840EE-BEC8-4F82-8D3C-B116698A4262@gmx.net>
To: IETF Chair <chair@ietf.org>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
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: Sun, 03 Mar 2013 12:38:02 -0000

There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed.

Since I believe neither is the case, it sounds like the IESG requirements are too tight.

On Mar 3, 2013, at 4:15 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Brian, you are essentially saying that the Nomcom should "ignore the requirements". 
> 
> I believe we would attract more candidates right from the beginning if we lower the requirements.
> 
> The transport area has historically had a this strong emphasis on congestion control expertise for at least one of the serving transport ADs and this requirement seems to reduce the pool of available candidates quite severely. 
> 
> Ciao
> Hannes
> 
> On Mar 3, 2013, at 9:53 AM, Brian E Carpenter wrote:
> 
>> On 03/03/2013 05:00, IETF Chair wrote:
>> ...
>>> advance.  Since this discussion could lead to a change in the IESG
>>> requirements, the IESG encourages the community to take part in this
>>> discussion so that any changes are based on broad community input.
>> 
>> When there is a choice between nominating nobody, and nominating someone
>> with excellent IETF experience and management skills, but who is not a
>> recognised specialist in the narrow technical area concerned, I believe
>> that standing advice to the NomCom should be to appoint such a candidate.
>> 
>> Also the standing advice to the confirming body should be to confirm
>> such a nominee.
>> 
>> We are too hung up on our narrow specialisations in the IETF.
>> 
>>  Brian
>