Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)

John C Klensin <> Mon, 08 July 2019 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C94A1202F2; Mon, 8 Jul 2019 13:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WK5CVl--1mee; Mon, 8 Jul 2019 13:33:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF555120288; Mon, 8 Jul 2019 13:33:26 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1hkaKB-0008Cs-2l; Mon, 08 Jul 2019 16:33:23 -0400
Date: Mon, 08 Jul 2019 16:33:17 -0400
From: John C Klensin <>
To: Barry Leiba <>, Alissa Cooper <>
cc: IASA 2 WG <>, Bob Hinden <>,, IESG <>, Jon Peterson <>,
Message-ID: <2136D3A424B33DD39E443A27@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> < om> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 20:33:39 -0000

--On Monday, July 8, 2019 11:24 -0400 Barry Leiba
<> wrote:

>> The exception in the document seems consistent with the
>> following hypothetical situation:
>> The nomcom for year 2035-2036 has been seated. Alice has been
>> on the IAB for one year. She is also a nominee for an AD
>> position in the Foo area. There are also six open positions
>> on the IAB.
>> The nomcom does its deliberations and selects Alice to be the
>> next Foo AD. They also select six people to serve on the IAB.
>> They send the IESG slate to the IAB for confirmation and the
>> IAB, with Alice recused, confirms the slate. Alice resigns
>> from her position on the IAB. The IAB chair informs the
>> nomcom of the mid-term vacancy created by Alice resigning.
>> The nomcom selects a seventh candidate to serve on the IAB
>> (since they have a pool of nominees and filling the vacancy
>> is a responsibility of the 2035-2036 nomcom) and sends the
>> IAB slate to the ISOC BoT for confirmation. The announcements
>> of the confirmed slates and of Alice's resignation from the
>> IAB then happen simultaneously.
>> I think this is different from the 2013 situation because all
>> of the events are taking place during the established nomcom
>> timeline for getting people seated by the first IETF meeting
>> of the year, so the IAB candidate pool for 2036 is still
>> "active," so to speak.
> OK... then you're saying that in the case that the NomCom has
> not yet announce the IAB slate, the exception says that they
> can fill an extra IAB position without advertising that to the
> community, because there's already a bunch of people who put
> their names in for IAB positions and there's no reason to
> think that knowing that there's one more open position will
> matter.
> I get that, and, understanding it, I do agree that that was
> the intent of that text.
> May I suggest, then, the following edit to make it clear?:
>    However, the following exception is permitted in the case
> where the    candidate for an open position is currently a
> sitting member of the    IAB.
>    However, an exception is permitted in the case where the
>    candidate for an open position is currently a sitting
> member of the    IAB.  Because there is already a pool of
> candidates for a set of IAB    positions, the NomCom does not
> a need to inform the community    explicitly that one more
> position is becoming available, so par of the    process can
> overlap.
> Tweak as necessary, but does that work?  Alissa, Bob, others,
> what do you think?

Barry, because I believe that the existing text is as hard to
understand and possibly ambiguous as seem to do, this is a
substantive change.  Consider the following scenario, which I
consider plausible, and consider it in context with the recent
discussion about overrepresentation of organizations on the

Among the members of the IAB are persons A and B, both from
company X.  To make the example more clear, assume B is on the
"off" cycle and not up for re-selection.  Person C, who is also
from company X, does not self-nominate as a candidate because
she believes that A is likely to be, and B is certain to be, on
the nomcom after the process completes and  that more than two
people from that company would be a bad idea.  Now, if the
Nomcom moves person B to the IESG and the Nomcom simply fills
the IAB seat from those who are still on the list of candidates
they had earlier (i.e., after candidates who had already been
selected have been removed), then they can't consider C as a
possible candidate because C, having not volunteered under those
circumstances, is on the list.  If they issued a new call for
candidates, C would presumably volunteer and might turn out to
be the best candidate in the (new) candidate pool for the IAB.

I personally don't think that community would be well-served by
making that decision but, one way or the other, clarifying that
the text means that the nomcom is not required to issue a new
call for candidates is almost certainly substantive.