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

Jari Arkko <jari.arkko@piuha.net> Sun, 21 December 2014 20:26 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB661A878C for <ietf@ietfa.amsl.com>; Sun, 21 Dec 2014 12:26:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHObHrNEIzVp for <ietf@ietfa.amsl.com>; Sun, 21 Dec 2014 12:26:23 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id DF2FD1A8788 for <ietf@ietf.org>; Sun, 21 Dec 2014 12:26:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 189C92CED0; Sun, 21 Dec 2014 22:26:21 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkfBLy-mcC1x; Sun, 21 Dec 2014 22:26:20 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 388F82CC4D; Sun, 21 Dec 2014 22:26:20 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_38FEE7EB-3873-4155-817A-BAE30333EACF"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
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
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <549402E2.3010209@cisco.com>
Date: Sun, 21 Dec 2014 22:26:18 +0200
Message-Id: <89EE0E1E-DBD5-4537-B9E1-57F0295B1EE6@piuha.net>
References: <20141208235300.6525.3418.idtracker@ietfa.amsl.com> <549402E2.3010209@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/auW5SjGKnmWqnDEIri3uFn7DcUU
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Dec 2014 20:26:26 -0000

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