Re: IETF areas re-organisation steps

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 20 January 2015 14:55 UTC

Return-Path: <hallam@gmail.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 17A0B1B2DB6 for <ietf@ietfa.amsl.com>; Tue, 20 Jan 2015 06:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BzEuQsTcWnMJ for <ietf@ietfa.amsl.com>; Tue, 20 Jan 2015 06:55:51 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DD41B2DB5 for <ietf@ietf.org>; Tue, 20 Jan 2015 06:55:46 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id gq15so10266729lab.12 for <ietf@ietf.org>; Tue, 20 Jan 2015 06:55:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3GtZodKqRv0KL8EsJ1HLBSQ200XJ1Os0vSTryDnIpyc=; b=Mw9WC+yIoO6YJrGJsa2vpntzH2Ubj6Z0PlNiPc6Bh09byiQX/t4Vwqqx1aQNpwVbUa MbzovY+ZRKEepdeQmJkGRmOU7s/emf5DwUNONs+fLWmqfTMzHLlkOqjL1plEWsq9tX8M mxJ0Cmg9ZbhFS+44keHV3wdQkQOgIttPqseqgOcm1MLmokJnRbTxAQBS54o+JVvM6Im0 WaHWAgsndxwSq3b1SenvnljGTX/lkcLlneoB7O9GPGqoky56YOTA3XjFZu0W23x5aooy CgCOqe9DvARBledmJ19cobquQ7Y4rg4JpzCimJ3A0N+pPTrIJ7W5c8ePdi3rebLAbT0q Oe2Q==
MIME-Version: 1.0
X-Received: by 10.152.28.194 with SMTP id d2mr38836240lah.85.1421765745317; Tue, 20 Jan 2015 06:55:45 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Tue, 20 Jan 2015 06:55:45 -0800 (PST)
In-Reply-To: <54BDDFC3.6000106@bogus.com>
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net> <54AC505B.8090802@nostrum.com> <8EFCB6B4-0D95-459E-A316-DB29C3945A33@cooperw.in> <DM2PR0201MB09604D5A8DBF0D315E6DA7BAC34A0@DM2PR0201MB0960.namprd02.prod.outlook.com> <33740FEA-AEA1-4933-A17C-50B92C7619F0@gmail.com> <DM2PR0201MB0960F339E10E51FD0153DDF4C34A0@DM2PR0201MB0960.namprd02.prod.outlook.com> <CAHbuEH5SONtcY2ENQ8rdqqYJ01YVFFU+1+UR9W3R++eYxmGhjQ@mail.gmail.com> <CAMm+LwhAMRKLZ7HyM-1pq5mENNDxEfvYGo0e+WwVZ-wd60qguw@mail.gmail.com> <54BDDFC3.6000106@bogus.com>
Date: Tue, 20 Jan 2015 09:55:45 -0500
X-Google-Sender-Auth: 6QIjAxTXhYlRJAeyTMdCI5Jd990
Message-ID: <CAMm+LwgDJ=SLsS05iEz8G4GEHeC4CE54Dbde_Ohwk0nABwhk7g@mail.gmail.com>
Subject: Re: IETF areas re-organisation steps
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: joel jaeggli <joelja@bogus.com>
Content-Type: multipart/alternative; boundary="089e0160b420341f1b050d16a2af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/SybQVu4UTrgXoIoR8cL0L7mqMMw>
Cc: "ietf@ietf.org" <ietf@ietf.org>, Larry Masinter <masinter@adobe.com>
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: Tue, 20 Jan 2015 14:55:53 -0000

On Mon, Jan 19, 2015 at 11:55 PM, joel jaeggli <joelja@bogus.com> wrote:

> On 1/19/15 6:55 PM, Phillip Hallam-Baker wrote:
> > Before we go too far with this, it just occurred to me that implicit in
> > the discussion to date has been the notion that an AD spends most of
> > their time managing WGs.
>
> There's an enormous fraction of this activity that is devoted to
> spherding documents through post-working group stages, reviewing other
> documents prior to the telechat's that punctuate iesg review. and
> triaging  documents where there are seriously problems. Those are not
> by-in-large tied up in working group management.


Absolutely. But the point I was making is that every draft has security
implications while an application draft that has routing implications
almost certainly needs slapping with something.

Sorry to sound like a broken record on this, but I think we are making a
lot of work for ourselves by not having a reference architecture. This
creates work at the WG level as each WG goes off and makes its own
interpretation of the architectural principles. Then the IESG starts with a
set of divergent documents and tries to make sense of them.

I have been trying to do write a reference architecture to describe it to
non Internet folk and I am rather surprised to find that the Internet
architecture as currently deployed can be described in a reasonably compact
and clean model[*] without resorting to calling firewalls, NAT, VPN, SDN
etc. blasphemies.

It is counterproductive to have a WG spend time deciding how to apply JSON,
etc. and then have those decisions overridden at the IESG level to get
consistency between specs. I want the consistency, just at a lower human
cost.

One approach that might help would be for the IESG to maintain a wiki with
prior feedback from ADs sorted into some form of structure. This would then
serve as precedent folk could look up. Another pathology I really dislike
is when certain individuals wait till the AD is out of the room and then
tell the WG what the IESG is going to demand (which is frequently rather
different to what they actually say). So basically the same thing as
minutes but structured somehow.



[*] About the same number of elements as the standard model of particle
physics.