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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Nov 2016 10:49:29 +1300

Looks good. Just three comments.

Is there any reason this should not be a BCP? It discusses an IETF matter,
even though it comes from the IAB.

> 3.1.  Duration of Appointment
> 
>    Each of the CCG Representatives is expected to serve for at least a
>    year.  Each year the IAB will seek input from the IETF community to
>    determine whether a personnel change is appropriate.

Could you add something about the expectation being to arrange staggered
terms, so that a simultaneous turnover of all three members can be avoided?
This doesn't have to be a rule, just an intention.

> 
> 7.  IANA Considerations
> 
>    This document has no actions for IANA.
> 
>    {{{ RFC Editor: Please remove this section prior to publication. }}}

That request is inconsistent with https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-18#section-9.1

Regards
   Brian Carpenter

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Nov 2016 16:55:13 -0500

> This doesn't have to be a rule, just an intention.

The IAB's plan is to put that intention into its internal policies,
instead, on the grounds that it will be obvious to any competent IAB
that complete turnover is undesirable without tying a future IAB's
hands if something dramatic happens.  Is it enough that you know that?

A (for myself)

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Nov 2016 15:05:21 -0800

> hands if something dramatic happens.  Is it enough that you know that?

Andrew,

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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Nov 2016 18:56:14 -0500

Hi,

On Fri, Nov 25, 2016 at 03:05:21PM -0800, Dave Crocker wrote:

> 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
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Nov 2016 16:02:47 -0800

On 11/25/2016 3:56 PM, Andrew Sullivan wrote:
> So we
>     event some early alterations are needed.

ack. point taken. wfm. tnx.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Nov 2016 19:35:39 -0500

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
<[email-masked]> 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.
> 
> 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.
> 
> 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