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(_at_)anvilwalrusden(_dot_)com> 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