Draft minutes from Nomcom Meeting

[Avri Doria <avri@acm.org>]

Nomcom, Wednesday 9-11:30
Minutes taken by Melinda Shore

Agenda:
Agenda review
Review of changes to 2727bis
Review of proposals for closing open issues
Discussion of when 2727bis becomes normative

[Trying to close down wg]

no changes to agenda
-----------
Jim Galvin reviewed changes in 2727bis-08.

Issue 11 (and 23): should clarifying text indicate that the
Confirmed candidates, chosen by the standard process (as
opposed to midterm appointments) be expected to serve at
least two years.  mid-term appointments may serve less than
two years

Issue 8: when a new area is created one AD may serve for a
longer term (to offset terms).  Change specifies maximum
period of 3 years.  In the past nomcom can't choose term
length - they're told by the requesting body (IESG or IAB)
[Scott Bradner and Mike St Johns].  Disputed by Avri and
Jim.  2727bis has said for a long time that nomcom can set
duration.  Marshall asked about how firm this is - how do
the checks and balances work?  Scott B. said that the IESG
has decided in the past - the issue here is lack of clarity
in the document.  Mike said that when two slots are open of
different length, the nomcom chooses which candidate fills
which slot, but the requesting body is responsible for
requesting the durations in the first place.  Jim asked if
the authority to adjust the term length rests only with the
requesting body, and Scott said "yes."  Harald said it's a
distinction without a difference and that reasonable people
will do the right thing without specific guidance - that the
document does not need clarification.  Scott said that he's
not asking for a change.

Issue 25: explicitly declare that the ISOC board of trustees
may provide a liaison

Issue 9: clarify what is meant by "approved by all members."

Issue 7: allows for the possibility that the NOMCOM may
replace a member no longer participating

Issue 5: adds that the nomcom talk to wg chairs

Issue 4: adds that the recall signers should be verified for
eligibility

Bunch of editorial changes

------------

Proposals for closing open issues

1. Release of qualification statements

objection was description of desirable qualifications was to
be disseminated.  Issue was "when."  should be during
announcement or during solicitation?  Mike St John wants to
withhold communication until done (as validation) - doesn't
want public discussion during process, thinks it will create
appealable problems.  Jim Galvin asked if it would be okay
to make editorial changes.  Also, what is meaning of
information?  Is it normative, and how is it used by nomcom?
Scott said that the information should be put out early, and
that it's important for the community to know what the IESG
and IAB suggested as criteria.  Harald also disagrees with
Mike, asked if it would be correct to say that the
description is from the IESG and IAB, identifying the
source?  Lucy Lynch said it's chicken/egg problem, that if
the information is mandatory it should be exposed early and
that if it's advisory there's more wiggle room.  Mike:
"expertise" may be a better term than "qualifications."
Avri asked if "expertise" would obviate Mike's objections.
Mike said he doesn't feel that strongly and would be willing
to be overridden.  If there's no benefit from exposing the
information, why do it?  Scott argued again for early
release of the information, said community may not agree
with the IESG about qualification and that dialog should be
possible.  Joel pointed out that the text already says that
the qualifications are "desirable", not mandatory.  Jim said
that the context is allowing people to choose whether they'd
like to serve on nomcom or be considered for open I*
positions.  Mike said the community should be asked for
input for qualifications.

Agreed to suggested change

2. nomcom causes midterm vacancies

nomcom may propose moving a serving I* from one position to
another.  issue is whether mid-term procedures should be
used to replace mover.  Mike asked to be aware of dependency
on rule saying that no-one may serve on both IESG and IAB
simultaneously.  IESG and IAB chairs do the requesting of
the Executive Director, who's responsible for asking the
nomcom to select the replacement.  Harald and Scott think
it's more specific than necessary, ask that the stuff about
chair requests be dropped.  Jim asked if the issue is that
the text in -08 is about making sure that mid-term vacancy
rules are applied to the letter, Mike pointed to Ted Hardie
experience - he may have been able to serve on both, but
voluntarily stepped down.  Nomcom cannot by itself choose to
fill a slot that it's creating.  Also distinguishes between
IAB, where open position need not be announced, and IESG,
where open position must be announced.  Text in -08 applies
only to openings created by the nomcom on the IAB.

Agreed tosuggested change

3. liaison initiation of problem resolution process

When the liaison goes to their respective bodies, do they
reveal information that's confidential to nomcom.  Proposal
is to have liaisons discuss among themselves and the chair
rather than going back to their bodies.

Agreed to suggested change

10. nomcom member recall

replaces "quorum" with "2/3".  Doesn't explicitly exclude
the chair, should.  Mikes says should exclude person under
consideration for recall.  Quorum is defined elsewhere in
the text as 75%.

Agreed to suggested change

17, must or should for completion of nomcom process

Old text says the confirmatin process must be completed at
least one month prior to first IETF.  Suggested to change
the must to should proposal is to leave as is.  Scott says
that must implies existence of recourse and there is none.
Joel said job is "do it."  Mike said problem with text is
that it's binding on process, not people, and suggested
changing to musts on people.  Scott suggested changing to
"due dates" rather than musts.

Will be taken back to the list ("is due by").

24.  Term changeover timing for IAB

What does overlap mean for IAB, where there are no specific
slots?  When does IAB seat start, when does it end?  The
delta is the addition of IESG for existing text, addition of
IAB sentence at end.  How does this apply to midterm
vacancies?  Jim said handled elsewhere - that's why it says
"sitting members."  Mike suggests specifying that the
proposed text is for sitting candidates, adding clause for
midterm replacements.  Scott suggested that midterm
appointments become effective as soon as possible after
confirmation.

Change is agreed to, with editorial clarifications.

---------------

When does 27272bis become normative?

Proposal: once published.  Current nomcom is free to use
current BCP or new one for current process, but use new
process for new midterm vacancies.  Scott said that it
should wait for publication, suggested that it become
effective when IESG approves it or when ISOC board accepts
it.  Joel says the question of when it becomes effective is
out of the hands of the working group.  Mike said the
problem is that the nomcom may not conflict the old stuff,
must document any changes to procedure.  Jim said it might
be useful for IESG to make general statement about process
documents.  Mike thinks the document should include a
statement about when it becomes normative.  Scott said that
it would be harmful, but that it would be better for the
IEsG to make a statement.

Is the second bullet acceptable (current nomcom is free to
use current or bis for any current process where there is no
conflict)?  Yes

Should it only be sent as a recommendation to IETF chair, or
should it go in the document?  Goes as a recommendation to
chair.

Mike asked if the recommendation is binding.  Joel said he
hopes the IESG will make a statement about this when then
document is announced.

Does the room agree that the IESG should make a statement?
yes

Scott clarified that we're not sending it to the IETF chair,
but the area director for the general area.

-----------

The intention is to close down the group but keep the list
active once the document is approved by the IESG and
accepted by the ISOC board.  Scott said that according to
recent history, the wg would not go poof until the document
popped out of the RFC editor's queue.