Hi Jari - Thanks for the leading questions. I'll comment below, but also I've
posted http://datatracker.ietf.org/doc/draft-stjohns-alt-3777bis/ which
provides suggested text for most of the items I listed below. I wrote this a
while back, but decided there wasn't sufficient interest to open up 3777. The
document is mostly complete - I think I still had to rework the timeline to
comply with the interim changes documents.
At 05:32 PM 9/15/2014, Jari Arkko wrote:
Michael,
Your list is good and worth working on. Thank you!
I do have some comments and questions though.
1) Update 3777 to merge in the various changes that have been posted. (this
rev)
2) Add text to fix the revealed-broken recall process
Remind me what this is about.
This was related to the painful process we started to implement to resolve the
IAOC issue. Basically, even at the beginning of the process we started finding
problems (e.g. petitioner's couldn't serve on the recall committee turned out
to have some warts). I looked at the process as described in 3777 and realized
that it would take most of 2 months to complete the process and concluded that
a long drawn out process was bad for the IETF. That led to the text in the
above document to shorten various process related actions (selection of the
recall committee comes from last nomcom volunteer list as a suggestion).
3) Add text to fill out what constitutes a vacancy. E.g.
a) Vacancy by term completion
b) Vacancy by resignation
c) Vacancy by death or incapacity
d) Vacancy by recall
e) Vacancy by expulsion
Seems reasonable. What are you thinking of under e)?
See the document, basically any member (except the IETF chair) is subject to
explusion by a 2/3 vote of the member of their body. I added a confirmation
step requiring 2/3 agreement by the related confirming body - but thinking
about it, that may not be appropriate. Generally, even elected bodies have a
way to remove members that are disruptive, or are in violation of law or
general standards of behavior.
The IETF chair exception is that he/she is chair of all the actions of the
IETF, not just the IESG as a body. Recall is still available and more
appropriate.
4) Add text to fix disconnects between what the Nomcom and the confirming
bodies believe to be true with respect to:
a) what is and is not confidential about a candidate with respect to the
confirming body
b) what MUST be provided to the confirming bodies
c) what MAY be provided
d) what must be provided to the nomcom by the confirming body on
rejection of candidates (my take, simply the fact of rejection)
e) that the rejection of a candidate is NOT a failure of process.
Agree about e). It can be that the confirming body simply has more
information. And I understand that items a) through d) have been a source of
discussion between nomcom and the confirming bodies in some cases. However, I
am wondering if we can specify useful, general rules about what must be
provided. Is there a working practice that we believe could be taken on?
I added text to the document based on my experiences on both sides of the
issue - as a Nomcom chair, past chair and member and as an IAB member.
In the final analysis, the confirming body, if it fails to get the information
it wants/needs, generally has no alternative but to reject the candidate.
Setting expectations on both sides of the information exchange *prior* to
getting to that point I think would resolve most of the issues. I *really*
hope to never see this go to mediation again.
5) [This one is one of my hot buttons, but is somewhat controversial. It's
based in part on my belief that the "we all participate as individuals,
rather than members of company" trope is no longer even minimally true,
especially for more recent participants.] Rework the Nomcom selection
process to minimize the statistical affects of one or more companies each
comprising large portions of the Nomcom volunteer pool. [Statistically, if
a company has 30% of the volunteers, they have an 85% chance of having 2
nomcom members, a 97% chance of having at least 1].
I do think the IETF still has a lot of individual opinion and ?best for the
internet? flavour in it. But we all are coloured by our affiliations and other
associations. Some to smaller, some to greater extent. Not sure we should
label the recent participants in this respect any more than others.
In any case, I agree with your point about needing to shield the nomcom for
over-extended influence from any particular party. The question is of course
if there?s anything we can do about it. Do you have a suggestion?
Yup - text in the above document. Basically, a two stage process. Stage 1
draws from a pool of company tokens, where a given company has no more than 10%
of the pool. Stage 2 does a draw for each company selected in stage 1 from the
pool of volunteers from that company. The math works out to be about
33%/33%/33% of a given company having 0, 1 or 2 members of the Nomcom.
I did consider the "select only 1 nomcom member from a company" approach
(suggested in another message on this thread), but all that does is make it
statistically certain (>95%)for any company with about 28% of the nomcom pool
to have a member on the nomcom. I'd really like to remove that certainty.
The approach above is documented as an alternate process in the appendix of the
document - like I said, its going to be somewhat controversial to find a
workable process.
Reading on?
Item's 2, 3 and 4 are fixes for events (failures of process) that have
happened since the publication of 3777.
With respect to 5 - the text in 3777 is that the selection process should be
fair - which is defined to mean: "
A method is fair if
each eligible volunteer is equally likely to be selected."
That definition is already broken in that we cap the number of nomcom
members from any given company at 2 - which means that anyone in a large
company already has a lesser chance of selection then that represented by
his portion of the volunteer pool.
I think we benefit from diversity of opinion, and even more from diversity
of experience. I'm concerned that the Nomcom has been at times rather over
populated with large company representatives with a related narrowing of the
experience pool.
I?d argue that 2 out of 10 is not necessarily a big problem. But are you
concerned about that, or are you concerned there might be cases where closely
associated entities can circumvent the limit of 2, or are you concerned that
the nomcom volunteers to a too large extent consists of commercial vendors?
Mostly I think the latter. As a matter of pragmatism, the folks we select for
the various IESG/IAB/IAOC positions are mostly going to be those with good
support from their companies. That's still going to trend towards selecting
people from large companies. Even if we reduce the influence of large
companies on the selection process, that's not going to change for things like
the IESG, but at least we remove one leg of trends that tend to oligarchical
organization behavior.
There are a lot of ways to muck with the process if you have the "power" of
being on the nomcom concentrated in a few large organizations. While I'm
definitely unaware of any horse trading (you select my guy for the Lust Area
director and I'll vote for your guy for the Glutton Area director) [I almost
used real areas, but realized that could be taken badly....], I'd rather
minimize the opportunities for external attacks on our process by reducing the
attack surface.
There might be ways to tackle some of these issues, but the solutions are
different depending on which problem you want to address.
Yup. Have fun reading.
By the way, the document adds a number of items meant to constrain the process
so it completes. The words "reasonable time" are used way too often IMHO, and
there are no good rules for what happens if one of the actors fails to act.
Mike
Jari