Re: Out-of-area ADs [Re: IETF areas re-organisation steps]

Nico Williams <nico@cryptonector.com> Mon, 29 December 2014 08:37 UTC

Return-Path: <nico@cryptonector.com>
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 453071A0047 for <ietf@ietfa.amsl.com>; Mon, 29 Dec 2014 00:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.856
X-Spam-Level:
X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 SnOZJgfUfTJh for <ietf@ietfa.amsl.com>; Mon, 29 Dec 2014 00:37:31 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 90A801A0149 for <ietf@ietf.org>; Mon, 29 Dec 2014 00:35:37 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 38C0A36006D for <ietf@ietf.org>; Mon, 29 Dec 2014 00:35:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=cB8e1ROG6co2QbtkdnO/ d4VX774=; b=n7FdzvNIRhvltk9efpQq7gU6FS5SrM2HYIcFgisUjfco8pUMzmss LjXxEaekTg2TK0r0e2m2Yj9OGcFWstbbBAJXWZu80+PhBFcWLjUGqhSgRKCgEw2H pRZ/P9+IzCnbAIvdip+L2oB3hgJJ7yO6qwJGfEGQNfPCbXD4tv8jAxM=
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 0FD2F36006B for <ietf@ietf.org>; Mon, 29 Dec 2014 00:35:37 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id n12so18228791wgh.8 for <ietf@ietf.org>; Mon, 29 Dec 2014 00:35:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.74.108 with SMTP id s12mr95352351wiv.28.1419842136040; Mon, 29 Dec 2014 00:35:36 -0800 (PST)
Received: by 10.217.7.206 with HTTP; Mon, 29 Dec 2014 00:35:35 -0800 (PST)
In-Reply-To: <20141229001241.GD24442@localhost>
References: <5614C286-0CD2-4DAD-A846-510EE38D1B9A@ietf.org> <549DAE1C.5080400@gmail.com> <54A02C8A.3020707@qti.qualcomm.com> <54A04CDC.8020009@dcrocker.net> <54A05568.705@gmail.com> <20141228201401.GB24442@localhost> <54A07420.2030507@dcrocker.net> <20141229001241.GD24442@localhost>
Date: Mon, 29 Dec 2014 02:35:35 -0600
Message-ID: <CAK3OfOhYNdQa_7ovfrZUgv+YwxN0VriYP8x9ztDd7ZM6vce=ig@mail.gmail.com>
Subject: Re: Out-of-area ADs [Re: IETF areas re-organisation steps]
From: Nico Williams <nico@cryptonector.com>
To: "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary="f46d043c81e627eace050b56c274"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/y3JTAfolhfC5DxU-peEE5LVij1c
Cc: "ietf@ietf.org" <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: Mon, 29 Dec 2014 08:37:34 -0000

It occurs to me that my proposal is rather selfish, actually: motivated by
difficulty for a relative outsider (I don't follow very many WGs)
in understanding the actual proposal.  I'd have read a fair bit of
datatracker records and mailing list archive content to begin to understand
some reassignment proposals, and/or talk to a number of people.  The flip
side is that infrequent mass reassignments must seem like a lot less work
to the IESG.  Each lone reassignment would have to be guaranteed to be real
cheap, or the concept won't fly.  But we are also not fond of light-weight
processes here.

Given this, I think I will now butt-out, even if the IESG and IETF end
up adopting something like my suggestion.