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

Bob Hinden <> Sun, 30 June 2019 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BC6612015D; Sun, 30 Jun 2019 10:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aBIEfoCPbGdz; Sun, 30 Jun 2019 10:13:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC11D120113; Sun, 30 Jun 2019 10:13:23 -0700 (PDT)
Received: by with SMTP id p11so11229618wre.7; Sun, 30 Jun 2019 10:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=987SS4sN8yQ/S7W1l/TbaSTHwK6pxexzmek8I57AgxE=; b=QcEAghayxO05mFXWemcqdv/XflfYcqvSakUvIKYMPyGidxSO3G3KZbyEhnsgdX/AIg 7ydSaOp1M6e9Hr36hlzLunoalg9cN5/2ItLVz1G0mq5fdqMh6+mGGZw8LgsXjz9rzKVb TVnssVUbRWVOj4XtbbUT8xqvJaT+RNEGbWuz+o66xj7sh+aAaAZyk4iUJKeFwVQBqn44 cXao+o9ZQftyBouAN5b6pGLo1CzpvwHejDw+NOd3xJ4FJMinqCmS6FqRluHr0INOhQ/H R4j07LdwwRMBWAXoln0ZZHv3fRihZ+YUhjn7bSnnC8aK9kE8mT/PAJ1gMx/pAe9AdF3g 5LqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=987SS4sN8yQ/S7W1l/TbaSTHwK6pxexzmek8I57AgxE=; b=UB2hzgbIupBPwb58dhoECqJ84e3IAxZXYwlIb9DYfIE+QVdShoBN5xMCGMdXjblhAs wwZDwGoFgGbNutGbG7dSO07/8MHmT8PInl9CzfrmkxJne5gPinLGF2Wm3UXOwo3mgODn G2mwne2k+zNuXR8daIKztJQFadJrnVunOJ2Lr1+WMFFdyjq9V+a++Z0JA9QaYu8LNHvD YnxnFtpzGR2O2gwoNFm7/Q/5zsUFZUFL7AKe+G3nNQfk3uhX8i8Q11rmSZkmHZG1XbN2 egfzSFkxK7V0MPzSUSv1b6lDJ7fI//cA6CWcjW9T4LbP33+MwwMXaGJEBINYejI1nLDw oUXw==
X-Gm-Message-State: APjAAAWEKuxOPegbTucVEtIg+pOVJqJy06t5v6qSECS9dl74nSoQOrot 7UAC5AosTU14KwLFddBsOg0=
X-Google-Smtp-Source: APXvYqwAwFffm1436lFpOmMCCeU+hQKzMdAkKFlVNpY/IHL56oM8p9E+hb17PP93FvL1oiaw/BxyZQ==
X-Received: by 2002:a05:6000:146:: with SMTP id r6mr15879966wrx.237.1561914802153; Sun, 30 Jun 2019 10:13:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j132sm9388943wmj.21.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 10:13:21 -0700 (PDT)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_D2FB3FF5-267D-4628-9B2C-E8CCB494A129"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 30 Jun 2019 10:13:16 -0700
In-Reply-To: <>
Cc: Bob Hinden <>, Alissa Cooper <>, IESG <>, Jon Peterson <>, IASA 2 WG <>,,
To: Barry Leiba <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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 17:13:26 -0000


> On Jun 29, 2019, at 6:09 AM, Barry Leiba <> wrote:
>> 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.

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.

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.


> Barry