Re: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice

"Stewart Bryant (stbryant)" <> Mon, 22 December 2014 07:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B3B41A89FC for <>; Sun, 21 Dec 2014 23:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OEkYaps7in9F for <>; Sun, 21 Dec 2014 23:25:58 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54A581A89FB for <>; Sun, 21 Dec 2014 23:25:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1708; q=dns/txt; s=iport; t=1419233158; x=1420442758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0TIGBrjaFqFZ7HxqJ0J0YGzQLGoClZ6yD2hDB41lg3s=; b=UAlXrkJJ4URD6sCLPe/4LzlaGdxTHSJCoZPd5yHBTHr81Js/GOkwCq2j 0XJVTBF7W0jYCR5n7ZY5+WZBbFKKRWP1eabrNuO+flyo4Uqqo6urvtbWf kwAfQcL3zhoYLZ9a/n/QniNESEe9Qwkc5H2cy2sULSfyiy0rsbQ+bLJmz U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,622,1413244800"; d="scan'208";a="381786966"
Received: from ([]) by with ESMTP; 22 Dec 2014 07:25:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sBM7PvLG014608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 07:25:57 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 01:25:57 -0600
From: "Stewart Bryant (stbryant)" <>
To: Jari Arkko <>
Subject: Re: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice
Thread-Topic: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice
Thread-Index: AQHQHVxnheIIscH/u0qfxKP1zns6C5ybNlTL
Date: Mon, 22 Dec 2014 07:25:56 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Dec 2014 07:26:00 -0000

Sent from my iPad

> On 21 Dec 2014, at 20:26, Jari Arkko <> wrote:
> Stewart,
>> I agree with the principle of this draft and agree that the IESG should
>> have the flexibility to structure the size of areas and the set the number
>> of ADs per area at an appropriate level.
> Thanks.
>> I do have a concern that when the number of ADs falls to one as there
>> can be issues of conflict of interest that need technical expertise to
>> resolve. There is also the issue of there being no natural AD for IETF
>> participants to turn to in such circumstances. It would be useful if
>> the proposed BCP gave a little guidance to cover such circumstances
>> such as considering the, perhaps temporary, merging of areas so
>> that there were three responsible ADs rather than just one.
> You mention one factor, but there are others, such as having someone to talk to, ability to deal with events like someone being sick or on vacation, and so on. Yet we’ve had one AD areas. And most ADs tend to have multiple areas of expertise from what I can see, even if their primary expertise is on one area. I think the IETF and the IESG are generally aware of these tradeoffs and issues. Anyway, we are not considering the creation of additional single-AD areas at this time :-)
> Jari


Yes, there are so many good reasons why it is useful for there to be at least 2 ADs to an area.

Regarding the creation of additional single-AD areas, I am puzzled because your recent public message to Nomcom stated that you wished to reduce APPs to a single AD. Has this position changed?