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

Dave Crocker <dhc@dcrocker.net> Fri, 19 December 2014 16:14 UTC

Return-Path: <dhc@dcrocker.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 3E3641A6F9B for <ietf@ietfa.amsl.com>; Fri, 19 Dec 2014 08:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PXVkLiDvLnxW for <ietf@ietfa.amsl.com>; Fri, 19 Dec 2014 08:14:16 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FDA1A1AF1 for <ietf@ietf.org>; Fri, 19 Dec 2014 08:14:16 -0800 (PST)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sBJGE7Ni021974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2014 08:14:10 -0800
Message-ID: <54944EC8.1030800@dcrocker.net>
Date: Fri, 19 Dec 2014 08:14:00 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: stbryant@cisco.com, ietf@ietf.org
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
References: <20141208235300.6525.3418.idtracker@ietfa.amsl.com> <549402E2.3010209@cisco.com>
In-Reply-To: <549402E2.3010209@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Dec 2014 08:14:11 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Y2y_Q2AJ1esKhwHiKSkRTlXZOw0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Fri, 19 Dec 2014 16:14:17 -0000

On 12/19/2014 2:50 AM, Stewart Bryant wrote:
> 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.


Although you said "such as", there is an underling challenge of figuring
out meaningful and appropriate handling choices.  And the example you
gave is in fact the one being offered by the IESG.  And there are no
alternatives to that being discussed.

The premise of 'areas' is that the subjects are different.  The base of
knowledge for one area is different from another area.

How does merging disparate subjects provide cover for the one lacking an
alternative AD?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net