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

Barry Leiba <> Sun, 30 June 2019 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C20891201CC; Sun, 30 Jun 2019 14:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d8-tt5XX4AHO; Sun, 30 Jun 2019 14:33:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EC0F12009C; Sun, 30 Jun 2019 14:33:22 -0700 (PDT)
Received: by with SMTP id j6so24224024ioa.5; Sun, 30 Jun 2019 14:33:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=m8zQA3Ll0ih/A4+Ot0ao41nrY59PGPkYJbzjX5U5iT0=; b=M2S5QX+ohPPR++7Cn5rM2tZewM60Ppt4STZYtoXoi9ixKMg3r4I7Oorz1NLhOgzrCI dZ4rujfKlQa0BDTobx1cUKbUA3MBRU/ctgD/kmgLE4RXkfu3UlY098Lz2aUePhpgaeYO 2sQYZPRglfVWlBA6pGRL+i4X8FnachafhuA8hHC9SaB7HnyAoX8aI065jdDEwwtOEBv9 /QkhwX59rtA70CSkm2/vzVmzh7U6abCJKgFc41DfOY5uujhmkTF2x/mBNH4gwzxp5nZV TbJ8WTQY/LQunjAYwLPJSJyAETZX0mHLaY1dk4R8nw3I4MbTxYaQxYoG4OvO7PLshmLK cgYw==
X-Gm-Message-State: APjAAAU101ygsCCOVpM8UZPL7261r5HLEAOxKJSHnsGExoehFkcaor6c KvjgmXDRAJhhv2LS55SloozdCY60cmejY3APvfA=
X-Google-Smtp-Source: APXvYqyA3b09MyUaBcVu4CeWRDeRwW4VqihVoBLNflkt5NyOw6I9K6RyRWHpWocf8OMnwExsEKkpxPse+yHGEFFGmIg=
X-Received: by 2002:a5d:88c6:: with SMTP id i6mr23372410iol.107.1561930401343; Sun, 30 Jun 2019 14:33:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Sun, 30 Jun 2019 17:33:08 -0400
Message-ID: <>
To: Bob Hinden <>
Cc: Alissa Cooper <>, IESG <>, Jon Peterson <>, IASA 2 WG <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sun, 30 Jun 2019 21:33:24 -0000

> I am reading this differently, it says "The resignation may remain confidential”.  This allows
> the candidate to be confirmed but not announced.   I read the IAB exception to allow all
> of the steps to be taken and then make the announcement when it is all completed.

One more pass on this before I give up, because I continue to think
that not correcting a true process error is a really bad choice, and I
don't see any other true process errors in the document.

> I note this text is original to RFC7437, so unless we have heard from a NomCom that this
> has causing a significant NomCom problem, I continue to think that we shouldn’t change
> it as part of the IASA 2.0 work.

The IESG doesn't generally just accept faulty documents on the grounds
that the fault wasn't caught the last time the document was updated,
so it's OK to leave the fault in this version.  I'm OK with the other
things, which are perhaps not as clear as they might be, but are not
actually wrong.  So I'm trying to sort out whether this is actually
*wrong*, or whether I simply am missing something.

Maybe what I really don't understand is the exception that allows the
replacement process to be done before the vacancy is announced.  3.8
says, "The process [...] of filling the seat vacated by the confirmed
candidate may begin as soon as the vacancy is publicly announced."
The reason for that is to allow the community to put their names in
for consideration for the newly vacated position.

Is the exception trying to say that it's OK to fill a vacated IAB
position without soliciting new nominations, on the grounds that the
original call for IAB nominations should cover that, as the
nominations for the IAB are general enough?  In other words, it is
that we expect that anyone interested in an IAB position would have
already put their names in, and suddenly knowing that Joe Slobotnik's
IAB position is also open would not make a difference?


> >> Regarding you first point:
> >>
> >>>>> — Section 3.8 —
> >>>>>
> >>>>> However, the following exception is permitted in the case where the
> >>>>> candidate for an open position is currently a sitting member of the
> >>>>> IAB.  It is consistent with these rules for the announcements of a
> >>>>> resignation of a sitting member of the IAB and of the confirmed
> >>>>> candidate for the mid-term vacancy created by that sitting member on
> >>>>> the IAB to all occur at the same time as long as the actual sequence
> >>>>> of events that occurred did so in the following order:
> >>>>>
> >>>>> 1.  The NomCom completes the advice and consent process for the open
> >>>>>     position being filled by the candidate currently sitting on the
> >>>>>     IAB.
> >>>>>
> >>>>> 2.  The newly confirmed candidate resigns from their current position
> >>>>>     on the IAB.
> >>>>>
> >>>>> 3.  The IAB Chair (or the Managing Director, IETF Secretariat, if no
> >>>>>     Chair has been named or the vacancy was created via the departure
> >>>>>     of the IAB Chair) informs the NomCom of the mid-term vacancy.
> >>>>>
> >>>>> 4.  The NomCom acts on the request to fill the mid-term vacancy.
> >>>>>
> >>>>> Either I don’t understand what this is saying or I don’t understand how it’s
> >>>>> possible.  Paraphrasing, the first paragraph says that it’s OK for the
> >>>>> announcement of the sitting IAB member’s resignation to happen at the same time
> >>>>> as the announcement of that member’s confirmed replacement.  That means that at
> >>>>> the time of the resignation, the NomCom already had to have selected the
> >>>>> replacement, given that selection to the confirming body, and had it confirmed.
> >>>>> Which means that step 4 had to have happened before step 2, or at least before
> >>>>> step 3, no?
> >>
> >> I think what these steps are saying that the steps need to be done in this order.  For
> >> example, even though the NomCom might think there will be an opening on the IAB
> >> because they just appointed a sitting IAB member to, for example, an IESG position,
> >> they can’t fill that open position until the person resigned from the IAB and after they
> >> have heard from the IAB Chair that there is a mid-term vacancy.  Then the NomCom
> >> can act to fill the vacancy.
> >
> > I get that.  And, so, in that case, how can "the announcements of a
> > resignation of a sitting member of the IAB and of the confirmed
> > candidate for the mid-term vacancy created by that sitting member on
> > the IAB to all occur at the same time", given that earlier in Section
> > 3.8 it says this:
> >
> >   The resignation should be effective as of when the term of the new
> >   position begins.  The resignation may remain confidential to the
> >   IESG, IAB, IETF Trust, IETF LLC Board, and NomCom until the confirmed
> >   candidate is announced for the new position.  The process, according
> >   to rules set out elsewhere in this document, of filling the seat
> >   vacated by the confirmed candidate may begin as soon as the vacancy
> >   is publicly announced.
> > That seems to say that the NomCom can't begin the selection process
> > for the replacement until the vacancy is publicly announced.  So I'm
> > trying to understand exactly what "exception" is being explained in
> > the text I originally quoted, and I don't see how the four-step
> > ordered process changes the effect of the text immediately above this.
> > That's what I'm trying to understand.