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

Barry Leiba <barryleiba@computer.org> Sat, 29 June 2019 13:10 UTC

Return-Path: <barryleiba@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 6F2BF120096; Sat, 29 Jun 2019 06:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN43dv2Sp7fd; Sat, 29 Jun 2019 06:10:11 -0700 (PDT)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 C494E12008A; Sat, 29 Jun 2019 06:10:11 -0700 (PDT)
Received: by mail-io1-f45.google.com with SMTP id n5so18483480ioc.7; Sat, 29 Jun 2019 06:10:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GTzffMHGVSnP6s3e6ffkWsNZKPt+EA/NEu8UCuJBfhs=; b=q/rDJJ3gpt/q80ogBRbAPFIae6ENNxJZOaFJ5bxKNWbmZEFyoOEJBH6vMiiEWGHDtC QxcLrzDVyaMHS+eR03PweRdmVgQvjlXjNELtjaQdJq3zDKZglx0ZaYjx8Ki5nX+/Nxos ZFgOgt2mTukgfnga+kgNXFkht9Wo6BNd0WKkjDkZxtbOG3fKjxKUQUVxO+bAbzdpxfRy zAdvI9UYd/uMMnq18HxIdV7HHt1XUQ6mUr4LmbfcYQ8yYDxtrS3FSS8p5aGDsS+04Tx/ a2QVcjO1RtT2GdpKuJ+Fkv3at65XtEtS5wvmgPsxXralXwBbnQfdTXUoAXLzRcZBuBmD gvXQ==
X-Gm-Message-State: APjAAAWQP71oQTBlxHiVtb0MfvgZ8vzw1TYwoyv56SLug/ekUJMPQL23 0NrCV9Z9thEnAa6MK+j2cPKWWidPVKvTC6fgLFI=
X-Google-Smtp-Source: APXvYqwoikKFwdmWIS31NY0lLA2qGjDLWRFoLCBl/02UY71YtI3sJBwsORfJBINQAAExkjNEbLi2v2LznsP0smlpBTo=
X-Received: by 2002:a5d:9613:: with SMTP id w19mr8984785iol.140.1561813810740; Sat, 29 Jun 2019 06:10:10 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <F15F78D3-2257-4F1B-B832-D9C7CC47E512@gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Sat, 29 Jun 2019 09:09:53 -0400
Message-ID: <CALaySJK+=W6FwMcHJ-nuyZFmvukMN_GUh6qDAWvwHnizyZqy9A@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: 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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/QYIydI4JJNtU8G-dDK7DWT8i-Ys>
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: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <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: Sat, 29 Jun 2019 13:10:14 -0000

> 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.

Barry