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

Barry Leiba <barryleiba@computer.org> Fri, 28 June 2019 21:38 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 715E912028B; Fri, 28 Jun 2019 14:38:11 -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 AYy-yWC6LxEK; Fri, 28 Jun 2019 14:38:09 -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 B47EF120110; Fri, 28 Jun 2019 14:38:09 -0700 (PDT)
Received: by mail-io1-f45.google.com with SMTP id u19so7019518ior.9; Fri, 28 Jun 2019 14:38:09 -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=/JaqsGBr9br8H7aSrQjGWkTjuVVGyw/f3YzT3atHObM=; b=GOGUVYVW+xugVv3oCeTbm+G6ka0GQeKL/j4ZNZ5X7W9quhKTO3TrWa4eLJkDURJ940 meO72CDtpW696BuKE3V8sa5mflufbaV1W+vTHM3WpX6qys/NW8eO2jN+1ufRijJBHIB1 x3NKPbV3l78MlbtwY6ZCg9Q823cYyOL7/d3c4rQ2K+uMSDOGgGQLjFeERCQnoTuWKeyA 0WQDEMSkqH4OkuQbInXBK09Ajz1EHPuDeMAWlux180a86EpJdp9SCjRgIrsXfRCBHDhy SA+X5i8VOaf6A/RSQjpLExBMkk2tpIZ3zNS0c+cOcXTx5/yoWyDXF5HIVvNwK+lnBoB2 r18w==
X-Gm-Message-State: APjAAAU5uZliHKDaIrFT5t3EFq22zzGzX7pebLvWS2lIYUyGnRikzwmY HTP5u8YR9cXUJFgFcih7JG6bYT7hj12wG9PYZlI=
X-Google-Smtp-Source: APXvYqwfc5G1waRuxsoGSF/TGNNdnT178zgNP3bKKpRN2BpG6CTtX1wxTkrgFYkEIs+lQBTXDOQMZzBjcjgfukau7N0=
X-Received: by 2002:a6b:b497:: with SMTP id d145mr13325494iof.17.1561757888694; Fri, 28 Jun 2019 14:38:08 -0700 (PDT)
MIME-Version: 1.0
References: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com> <1C131171-0ABE-4DB1-BEB7-03E765B1E6C6@cooperw.in>
In-Reply-To: <1C131171-0ABE-4DB1-BEB7-03E765B1E6C6@cooperw.in>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 28 Jun 2019 17:37:56 -0400
Message-ID: <CALaySJKHut1EL_eKQ5rhSXFeF6_+EizwcHdhxhieRy3D3dzQwg@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Cc: 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/EUiF4COoPan-3E6pm8GU8ylQOow>
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: Fri, 28 Jun 2019 21:38:11 -0000

> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for the work on this!
> >
> > I have three points I'd like to discuss, all of which should be easy:
> >
> > — 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?
> >
> > — Section 4.6 —
> >
> >   Any such appointment must be temporary and does not absolve the Chair
> >   of any or all responsibility for ensuring the NomCom completes its
> >   assigned duties in a timely fashion.
> >
> > Then where does it say how to permanently replace a NomCom Chair who really
> > does have to leave permanently (say, death or incapacity, unexpected family
> > issues, or even just is no longer willing to do it)?
> >
> > — Section 4.10 —
> >
> >   The prior year's Chair may select a designee from a pool composed of
> >   the voting volunteers of the prior year's committee and all prior
> >   Chairs if the Chair is unavailable.  If the prior year's Chair is
> >   unavailable or is unable or unwilling to make such a designation in a
> >   timely fashion, the Chair of the current year's committee may select
> >   a designee in consultation with the Internet Society President.
> >
> > Why is it that the prior year’s Chair can pick someone else on her own, but the
> > current Chair has to consult with the ISOC President to do the same thing?
>
> Bob has added the following text to the -08 version of the document:
>
> "This revision addresses only the changes required for IASA 2.0; should the community
> agree on other changes, they will be addressed in future documents.”
>
> The authors and the WG have been strict about only applying changes necessary for
> IASA 2.0, so while clarifying the points you raise above may be useful for a future update,
> they are not in scope for this one.

OK, that covers the second and third points, and I'll move them down
to comments so they're recorded for later.

But on the first point it's either sufficiently unclear that I don't
understand it, or it's broken.  I *would* like to discuss that and
make sure that if it's truly unclear (and not just fuzzy brain on my
part) or broken we fix it.  It would be a bad idea to publish an
update such as this with a rule that isn't usable (as opposed to one
that we think should be changed later).

Barry