Andrew,
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.
best,
john
--On Friday, November 25, 2016 6:56 PM -0500 Andrew Sullivan
<ajs@xxxxxxxxxxxxxxxxxx> 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