Re: I-D Action: draft-iab-ccg-appoint-process-00.txt
Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 25 November 2016 23:56 UTC
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66220129504 for <ietf@ietfa.amsl.com>; Fri, 25 Nov 2016 15:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 aLjqVbZe7P2N for <ietf@ietfa.amsl.com>; Fri, 25 Nov 2016 15:56:17 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id B7F51127058 for <ietf@ietf.org>; Fri, 25 Nov 2016 15:56:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 53498112A8 for <ietf@ietf.org>; Fri, 25 Nov 2016 23:56:17 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Qr1BTjHUzR for <ietf@ietf.org>; Fri, 25 Nov 2016 23:56:16 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 8D59F10A27 for <ietf@ietf.org>; Fri, 25 Nov 2016 23:56:16 +0000 (UTC)
Date: Fri, 25 Nov 2016 18:56:14 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ietf@ietf.org
Subject: Re: I-D Action: draft-iab-ccg-appoint-process-00.txt
Message-ID: <20161125235614.GH68855@mx2.yitter.info>
References: <148009401131.22717.9124100512985996998.idtracker@ietfa.amsl.com> <99a16936-f0c5-6add-cbff-95f0d3164cad@gmail.com> <20161125215513.GG68855@mx2.yitter.info> <02115aa3-497d-c1aa-1afa-076243476e6a@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <02115aa3-497d-c1aa-1afa-076243476e6a@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nIA7V1PkwycbrWie-T5p3HGe83w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Nov 2016 23:56:19 -0000
Hi, On Fri, Nov 25, 2016 at 03:05:21PM -0800, Dave Crocker wrote: > While I suspect that what you describe is sufficient in practical terms, > operationally, there is nonetheless such a long-established practice of > including this bit of procedural requirement into a foundational document > like this that it seems quite odd not to have it. There. Thanks for the feedback, and I'm sure the IAB will take it into account. For whatever it's worth, the way it's phrased was not an accident. The problem that I see, at least, is that this group to which we are appointing is quite a new one to us. This is for a few reasons: 1. The IETF Trust is organized for the _benefit_ of the IETF, but this activity of it concerns the interests of two other operational communities. The CCG is there to advise the Trust on behalf of the three OCs (three CCG members for each OC). So we feel it's a little delicate, especially at the beginning; and we want to be sure there isn't any foundational document issue in the event some early alterations are needed. (In my personal opinion, a number of the procedures around the IANA transition were someone overspecified, presumably because of the difficulty of fixing things in the names operational community post-transition. Fortunately, our community doesn't have that problem and I'd like to ensure the maximum potential for flexibility now, when we are most likely to need it.) 2. One of the wrinkles about the CCG is that each co-chair is empowered to speak on behalf of its respective community without necessarily having to consult with anyone. I understand the practical reasons by this was necessary, but particularly in the early going it could become a source of contention, and again the opportunity for maximal flexibility seemed important. 3. It is super strange for the IAB to be appointing people to a joint body that is designed explicitly to be "representative" and that has voting. I suppose the liaison to the ICANN board is like this, but that liaison can't vote. This novelty again suggests to me that, while we have this basic plan in mind, we might find that things work rather differently than we expected. To me, it'd be better to get started with the barest minimum specified, see how it goes, and then do an update later once things are clearly stable. This is just my personal opinion, note, and I'm not speaking for the IAB. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… Brian E Carpenter
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… Andrew Sullivan
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… Dave Crocker
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… Andrew Sullivan
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… Dave Crocker
- Re: I-D Action: draft-iab-ccg-appoint-process-00.… John C Klensin