Absolutely agree with Joel here.
My experience with participating in a NomCom is limited to just one time, but
that one experience
left some pretty deep scars. :-)
One of them was from the amount of time spent in trying to determine not just
what the job was for
each prospective candidate, but what the "job" was for the complete slate.
This is - IMO - the single biggest reason to prefer to "re-up" every AD if
they're all willing to take one
more for the team. Every person who isn't going to be on the next IESG
represents a lost perspective
that may or may not be part of the Area responsibility for that AD, but may
very well be critical for
the IESG as a whole.
In addition to trying to guess what the "talent-set" requirement is for a
complete slate, the NomCom
also has to try to figure out balance on a lot of different dimensions.
Company-mix, representation
by regions, extra skills and/or tools each AD might bring to the table, etc.
In fact, having worked through this, the single biggest dread a NomCom might
face is the potential
that the IAB may decide to exercise a line-item veto on nominated candidates -
either forcing the
NomCom to effectively start over, or giving the NomCom a clear indication that
their effort to come
up with a balanced slate was a complete waste of time.
So, in addition to not being able to re-define the basic task of each AD, a
NomCom cannot possibly
have the time to try, with the already heavy burden of other considerations
that need to be taken
into account and the tight time schedule defined for them.
The NomCom has a very hard job. We need to try to keep that in mind when we
decide to second
guess their decisions and how they made them.
--
Eric
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Joel M. Halpern
Sent: Thursday, March 07, 2013 4:57 PM
To: Andrew Sullivan
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Nomcom is responsible for IESG qualifications
I read 3777 as somewhere in between, with some important caveats.
As I understand the rules and practice of the game we are playing:
The IESG (and the IAB and IAOC) specify what they want to see (their job
requirements).
The nomcom collects those, and community input. Community input is explicitly
asked for both on candidates, positions, and general operational behaviors.
This includes community feedback on the job that needs to be done.
The nomcom selects candidates.
The nomcom tells the confirming body who the candidates are, what the nomcom
felt the requirements were and why, and how the candidate meets the
requirements.
the confirming body reaches its conclusion, and responds.
Do note that while the nomcom is free to interpret the job requirements, they
are NOT free to redefine the job. If asked for a Security AD, they can not
appoint an extra applications AD. Even i the community input strongly led them
to conclude that is what is needed.
One of the interesting things is that the nomcom does not in practice have a
way to tell the community exactly what it decided the job requirements are. I
say this because the explanation of how the requirements were interpreted is
often tied in with the available and selected candidates and their
qualifications, which must not be discussed with the community. And the
confirming body can not tell the community what it did with the nomcom
statements.
Yours, through my narrow lenses,
Joel
On 3/7/2013 4:28 PM, Andrew Sullivan wrote:
On Thu, Mar 07, 2013 at 01:02:09PM -0800, Dave Crocker wrote:
in the interpretation across different Nomcoms. Since this is a
strategic issue, it's too important to leave that ambiguous, IMO.
Why? It seems to me that merely having drawn attention to these bits
of RFC 3777 provides a hint to future nomcoms that they may not be so
bound as they think. Why isn't that enough? I suppose it may be too
late for this year, but this fact will surely be remembered by some
eligible volunteers next year, and they can use the apparent power
they already have to modify the stance the Nomcom takes. No?
The alternative seems, to me, to be yet another IETF meta-discussion.
These seem inevitably to be giant time-holes into which we throw our
most engaged participants, and in this case we'd be doing it where the
RFC and the existing practice don't align well. Why not just realign
to what the text says?
Best,
A