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

Donald Eastlake <d3e3e3@gmail.com> Fri, 19 December 2014 01:57 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F21A8AA4 for <trill@ietfa.amsl.com>; Thu, 18 Dec 2014 17:57:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 n_Bh9JksXz6C for <trill@ietfa.amsl.com>; Thu, 18 Dec 2014 17:57:28 -0800 (PST)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA6D1A7005 for <trill@ietf.org>; Thu, 18 Dec 2014 17:57:27 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id nt9so10606371obb.5 for <trill@ietf.org>; Thu, 18 Dec 2014 17:57:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=wK6J3DyMRcQ/NJc21MTRLrVFfLwuIp38qPcfhihCDu0=; b=jHyxTNPPp9nr6ZSXA+tzysUp4inoEMjFO8cDMixqGo3tndzyPOIozrwLJEDbgbiM7e llZcTkNepPSfZP1hNfzTqsebvPlaDF2JIKHiLEDXw1GSVP4MMIo/jscb6TPO4iU61sok hwokjM35qqU9RFlC4dnK+iyfkml6KareThvWwwcGR84cef1/8p297zLS5XYGkE3YDeR1 4j9aNO+bO8lFD7o4aWCVKxt2I9x+fnuOhL19vI7fPXBmxP3xSfTT+nUtMcx2KYSj0tY+ 7WAEVnieCHbnsi+UuF3uT/P2+85nkl+n/N/dYgYaIlDQc/6N6KyrHNJ21LFdoZAL6YEE kf3g==
X-Received: by 10.202.57.196 with SMTP id g187mr3118243oia.16.1418954247081; Thu, 18 Dec 2014 17:57:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.147.105 with HTTP; Thu, 18 Dec 2014 17:57:06 -0800 (PST)
In-Reply-To: <CAF4+nEE7Eg-JE-vDCzq4YwXDzcfT=L4TUuR34AXMwrNS-t_OjQ@mail.gmail.com>
References: <20141208235300.6525.3418.idtracker@ietfa.amsl.com> <CAKKJt-em11hqDhHK1joyo7fEVO=uktmfnd5fZpPQ2dT-yiN7Wg@mail.gmail.com> <CAF4+nEE7Eg-JE-vDCzq4YwXDzcfT=L4TUuR34AXMwrNS-t_OjQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 18 Dec 2014 20:57:06 -0500
Message-ID: <CAF4+nEG2hdM=8rc3-jJkZE-pLeoiLcw63aqTEkZgsU1AcYef=w@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/oPfUR8hWYDoI95AkgZjx0I0niPs
Subject: Re: [trill] Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 01:57:29 -0000

Sorry, sent to wrong list :-(
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Dec 18, 2014 at 5:57 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> On Thu, Dec 18, 2014 at 5:47 PM, Spencer Dawkins at IETF
> <spencerdawkins.ietf@gmail.com> wrote:
>> There's really nothing as awesome as sending Last Call comments on your own
>> draft. You should try it some time ... or not.
>>
>> But please see below.
>>
>> ...
>>
>> I had a chat with Scott Bradner today, and Scott asked me to explain some
>> history in a different way. The text he questioned was this:
>>
>> OLD
>>
>>    In the distant past, all IETF Areas had a single Area Director.  The
>>    movement from single Area Directors in an Area to pairs of Area
>>    Directors in most Areas happened over a period of years (for
>>    reference, see http://www.ietf.org/iesg/past-members.html), as part
>>    of the IESG organizing itself to do the work the IESG is chartered to
>>    do.
>>
>> END
>>
>> Scott said that changes in the number of Area Directors assigned to a given
>> Area during "the modern era", post Kobe, wasn't quite the linear progression
>> I described, and suggested (my words, trying to capture his thoughts),
>> something more like this:
>>
>> NEW
>>
>> While it's true that recent IESGs have had two Area Directors in each Area
>> except for the General Area, the number of Area Directors in each Area has
>> varied since https://www.ietf.org/rfc/rfc1396.txt (for reference, see
>> http://www.ietf.org/iesg/past-members.html).
>>
>> This variation was due to a number of factors, including workload and
>> personal preferences, and happened as a natural part of the IESG organizing
>> itself to do the work the IESG is chartered to do.
>>
>> At one point, the IESG placed three Area Directors in a single Area (Scott
>> Bradner, Deirdre Kostick, and Michael O'Dell, in the Operational &
>> Management Requirements Area, between IETF 36 and IETF 37 in 1996).
>
> I think it is a good change to the text. It grounds the change to the
> limit on the number of ADs in real events.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>
>> END
>>
>> I wouldn't mind hearing people's opinions about making this change as part
>> of Last Call, and I don't think the rest of the IESG would mind, either ...
>>
>> Thanks!
>> Spencer
>>
>>> Abstract
>>>
>>>
>>>    This document removes a limit on the number of Area Directors who
>>>    manage an Area in the definition of "IETF Area".  This document
>>>    updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).
>>>
>>>...