Re: I-D Action: draft-iab-ccg-appoint-process-00.txt

John C Klensin <> Sat, 26 November 2016 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 774BC129476 for <>; Fri, 25 Nov 2016 16:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HAkiHMfr90Ob for <>; Fri, 25 Nov 2016 16:35:49 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90F8E129447 for <>; Fri, 25 Nov 2016 16:35:49 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cAQy0-000Gz1-AB; Fri, 25 Nov 2016 19:35:44 -0500
Date: Fri, 25 Nov 2016 19:35:39 -0500
From: John C Klensin <>
To: Andrew Sullivan <>
Subject: Re: I-D Action: draft-iab-ccg-appoint-process-00.txt
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Nov 2016 00:35:51 -0000


While I'm sympathetic to Dave's concern, I also want to see the
IAB have maximum flexibility to manage this situation as it
evolves.  Even though I hope they will never recur, some
historical patterns suggest that, at least until we are sure
that things are stable, entanglements with ICANN need to be very
carefully overseen and managed rather than, e.g., the "go
participate in their processes and, if something we should know
about comes up, tell us if they will let you" relationship that
has characterized the Board liaison relationship.  The idea that
these people "represent" the IETF reinforces that view.

Given that, it seems to me that, with all the language to the
effect that the CCG Representatives serve at the pleasure of the
IAB and can be removed at any time, it would be reasonable to
include some language about rotating terms and minimizing the
risk of needing to remove everyone at once.  At the same time,
the document says that people are expected to serve at least one
year; it is hard to talk about rotating terms with that
provision unless, e.g., we wanted to shuffle people in and out
every few months. 

Recommendation: Add to the end of Section 6 a statement
indicating that, before the second IETF meeting in 2018 (i.e.,
one year after the non-interim first set of Representatives are
appointed) the IETF will devise a mechanism for minimizing the
need to replace more than one representative at a time in the
normal course of events and announce that to the community.
That announcement would, of course, be subject to our normal
appeal procedures and/or insistence by the community that the
mechanism be incorporated into a revision of this document

Two additional suggestions:

(1) Given the discussion of conflicts, it appears to me that
some people might be perfectly ok as a Representative, but less
so for the co-chair position with its spokesperson implications.
So, if it can be done without messing up agreements reached with
ICANN, I believe that any IAB-appolnted Representative should be
obligated to get the advice and consent of the IAB before
volunteering to serve as co-chair.  How that is handled is best
left to the discretion of the IAB and unspecified in the
document: I can imagine your telling a Representative at the
time of appointment whether you would be comfortable having that
person serve as co-chair.  Alternately, if I read Section 1
correctly, why not have the IAB, rather than the three
Representatives, designate the co-chair?

(2) What is missing from this is a requirement for the
Representatives to deliver frequent reports to the IAB on any
relevant issues.  I don't believe specific time periods should
be in the document, but candidates need to understand that
keeping the IAB or its designee informed on a regular basis is
part of the job with removal likely if that does not occur.


--On Friday, November 25, 2016 6:56 PM -0500 Andrew Sullivan
<> wrote:

> 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