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

Bob Hinden <bob.hinden@gmail.com> Sun, 30 June 2019 17:13 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6612015D; Sun, 30 Jun 2019 10:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBIEfoCPbGdz; Sun, 30 Jun 2019 10:13:24 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC11D120113; Sun, 30 Jun 2019 10:13:23 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id p11so11229618wre.7; Sun, 30 Jun 2019 10:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id j132sm9388943wmj.21.2019.06.30.10.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 10:13:21 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <4710C519-37CC-4586-83E7-02776889370F@gmail.com>
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: <CALaySJK+=W6FwMcHJ-nuyZFmvukMN_GUh6qDAWvwHnizyZqy9A@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, Jon Peterson <jon.peterson@team.neustar>, IASA 2 WG <iasa20@ietf.org>, draft-ietf-iasa2-rfc7437bis@ietf.org, iasa2-chairs@ietf.org
To: Barry Leiba <barryleiba@computer.org>
References: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com> <1C131171-0ABE-4DB1-BEB7-03E765B1E6C6@cooperw.in> <CALaySJKHut1EL_eKQ5rhSXFeF6_+EizwcHdhxhieRy3D3dzQwg@mail.gmail.com> <F15F78D3-2257-4F1B-B832-D9C7CC47E512@gmail.com> <CALaySJK+=W6FwMcHJ-nuyZFmvukMN_GUh6qDAWvwHnizyZqy9A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/MRknXXTUmfkA_PEztcNI8BLbIwU>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)
X-BeenThere: iasa20@ietf.org
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?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jun 2019 17:13:26 -0000

Barry,

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

Bob



> 
> Barry