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

Bob Hinden <> Sat, 29 June 2019 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E2CE120400; Fri, 28 Jun 2019 21:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 6SFUUSva26_x; Fri, 28 Jun 2019 21:15:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91AD31200EF; Fri, 28 Jun 2019 21:15:32 -0700 (PDT)
Received: by with SMTP id r7so3944184pfl.3; Fri, 28 Jun 2019 21:15:32 -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=UzE/fDXc5dQXyfBlhHdb6LAhvfcg+nNf+4HQxZNaB68=; b=apUru7L6nhxuib/jxMkr1UMBhZQ1+BNfdLYjH52Yoj8aPkmw9iUVWClGXwrtsugsgT vFETeF9Pgpf2UaTBU6H1DD4VGkta8+EWXqYP41VjIEUMdxv0BO6vUA755E2T//9wafsU WaMNpqfG2lPZPyapayPTfIWN2IwAF33iPYQmjwxWw23hA3sKCQ/Mh3vDcMESnfJ1CsMJ mfgyOmZPxqzVDKGuGz4Zqexhuf0q+Yz4eT7f/OuNvzeWEfyQWzaX2yQvv47+llo6ler3 FKSgLUFpC15Be5V6LqxNGsSFAj97bFFrRo5wnioPMJcZ/CWw31NYAs+IJgZ3pFxIICJG asDw==
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=UzE/fDXc5dQXyfBlhHdb6LAhvfcg+nNf+4HQxZNaB68=; b=cUjQvVcbRW+S8GOgA0eZy13oCdsmHtN6SaUSZcRN+sbF2tlCyWooF4SKcuz9Sc69Ip uhOq0Co0utw4ZsLRaffJP5L+pijShp0MfcoxiGs421RSDXxSKM/pKgow9WErznS+E/EH wvLRuD3eF0jm1hUrP7mOdfbgYG0oHNhM3l6iPBuvK5aQPMwB7mGKZ+Nm1Y162X3cC1T/ nNLffBP1sREdgL788X0t/7YUmRS1ZCGjUWl2W+d6+m4rAOgBjnSPgRaaKZl6TdS0bzs+ YwBvbZe4dcTYpgdoyAYU587L6oYul57jeob+3U1gHVGMPGzs70gRwewRBJ1ueOgwlJG1 0Vng==
X-Gm-Message-State: APjAAAUcRU4Za5casC/scqwR2d31m9DhpEOxGrL0PvhuU0/aTwSESwJv dfWjdRnG+9rbspq7xHQsK0k=
X-Google-Smtp-Source: APXvYqxYlM9CDmGZ+K5S++B9JIHnVaqWLBgfRyHamesp/ZKhgXHbc7Gmojdr9etDSD1vwR5TWOYTpQ==
X-Received: by 2002:a63:dc50:: with SMTP id f16mr12733948pgj.447.1561781731959; Fri, 28 Jun 2019 21:15:31 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:6d48:546d:ac90:9e80? ([2601:647:5a00:ef0b:6d48:546d:ac90:9e80]) by with ESMTPSA id e10sm3918933pfi.173.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 21:15:31 -0700 (PDT)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_0C3D85B1-E07A-4D09-874D-A4284EB38AD2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 28 Jun 2019 21:15:30 -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: Sat, 29 Jun 2019 04:15:36 -0000


Regarding you first point:

> On Jun 28, 2019, at 2:37 PM, Barry Leiba <> wrote:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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?

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.


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