Re: Mashing areas [Re: IETF areas re-organisation steps]

Ted Lemon <> Sat, 27 December 2014 13:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D0921AD5A5 for <>; Sat, 27 Dec 2014 05:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pXZTdH9bTKd0 for <>; Sat, 27 Dec 2014 05:50:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 489861AD5A1 for <>; Sat, 27 Dec 2014 05:50:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by (Postfix) with ESMTPS id E5207DA0309 for <>; Sat, 27 Dec 2014 13:50:09 +0000 (UTC)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by (Postfix) with ESMTP id BDDAA53E088; Sat, 27 Dec 2014 05:50:09 -0800 (PST)
Received: from [] ( by CAS-02.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Sat, 27 Dec 2014 05:50:03 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Mashing areas [Re: IETF areas re-organisation steps]
From: Ted Lemon <>
In-Reply-To: <>
Date: Sat, 27 Dec 2014 06:49:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <>
To: John C Klensin <>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: []
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: Sat, 27 Dec 2014 13:50:42 -0000

On Dec 26, 2014, at 5:23 PM, John C Klensin <> wrote:
> But the differences area assignments make can have effects on
> the Internet that go far beyond the management/steering of the
> IETF.  As an example, at and before the time of RRC 1123, the
> DNS was considered an application.   At some point, it was
> reassigned into the Internet area (I don't remember the reasons
> but recall them being a little bit arbitrary).  A lot of the
> focus since then has been on DNS features and operations as ends
> in themselves. Questions like "how will this be used", "how will
> it affect users", and "what will be the implications on the
> Internet's applications architecture" have sometimes (or often)
> gotten lost in the process.   It is also the case that there has
> never been a lot of deep database expertise in the IETF, but
> there has almost always been more of it among active Apps area
> participants than in the Internet area and that, too, has design
> consequences, especially when discussions break out about, e.g.,
> how far DNS-style aliases can reasonably be extended or what the
> implications are of flattening a hierarchical database
> architecture.  Sometimes those discussions don't even happen, at
> least until it is too late -- I think that is another
> consequence of area choices. 

I find your arguments unconvincing as they relate to the reorg that's being discussed, because there are _always_ blind spots.   Expecting Area Directors to be omniscient doesn't scale--there just aren't enough of us that are.

That said, I think that your observation here is correct, and ought to be addressed.   I just don't agree that it leads to the conclusion you drew.   What you are describing here is the classic cross-area review problem.   If ADs workloads allowed for it, perhaps we would do a better job at this.   I can certainly imagine a change in structure where each working group has a responsible AD, but also a second AD who tries to pay attention to what the working group is doing, from a different area.   What I just said isn't the actual solution, because ADs don't currently have that much bandwidth, but perhaps there's a pony in there somewhere.