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