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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 30 June 2019 23:10 UTC

Return-Path: <brian.e.carpenter@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 1106B1201D3; Sun, 30 Jun 2019 16:10:09 -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 1Y2pDbceRg50; Sun, 30 Jun 2019 16:10:06 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 7E8761201CD; Sun, 30 Jun 2019 16:10:06 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id i2so6295441plt.1; Sun, 30 Jun 2019 16:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FHomYf1PlcqUMW+R8uZg3gcrw7SWbyf7NgX31wUNKWg=; b=UYso+GovdSltiyJaoAtLZH2usrJf47G8HGwWXqhQof/lvpCVV8VCioH+kSjhBmiSAR 0FPv5Vfnvq+7xOSkK0MO4ZFkNH4H57T6nwo9sedQNMeponRU5BNcxrjY7pmkfh31rMmw Oy9NzpSyLctXXCNO3ASMCQc04C4HcLm2q7uup0PeU5E1jPIYCAuxZZ7+zzyN0nDdw48h XHq3v1KOxNl13STm8FnRc1olZ8ZSZu2QD5lw8YrGTI5u7lTA6vwa2WTYeshZuG9yQtXL hVEDYzlFbEn54i3oI6YUEKRPW2zU7aQja1epp+xKIaM99zHB+7/6mpI1CtDiC8X+4rw8 +9kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FHomYf1PlcqUMW+R8uZg3gcrw7SWbyf7NgX31wUNKWg=; b=pJ6GwAt7Bv1KHPWkGxwYL0PrYx0iqkVT9Ek+hAnVnXEH7JuOdkyUUUHd8LXgP5Y945 IITHseoTWnTUsZ3ygHjl/se1OYLZWp8KLm/pbXgpQRQtw59H8p7DczCDT3GZw2LP6A03 taRJg41FGPzXLrlm6eV15HXgUDNyEcuEdygkmLr5K+xyz28blaP+49eYJI9g4wyoVqqk HwM5ByAJ6rnsAyfCpMhrueusIS8Pmwfxb8iqAYLk6hU1Lv5pOKEyGsjwS6+2+tYHVJwI wcDvgkabQhVYB0VQlp0NouznIeIJCoYF++inSUZCkRoy2gYdsGcNAuFvNjPpxvhVrb04 Ex0g==
X-Gm-Message-State: APjAAAUbWNVLaRTCR+VH2DTqra/13KTEoesrBsbm0aMg250wqzF3ifKt e8LqueQYOswhBv9lN0IdPug=
X-Google-Smtp-Source: APXvYqxfZzCUILT0zb1ovcfOFec0vnFkCSQUZ9qm/ocv/8xMEM0RJyXGUVInMijE+UUmUI/2W0Tmmw==
X-Received: by 2002:a17:902:9a95:: with SMTP id w21mr24974367plp.126.1561936205973; Sun, 30 Jun 2019 16:10:05 -0700 (PDT)
Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id f11sm7429087pga.59.2019.06.30.16.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 16:10:04 -0700 (PDT)
To: Barry Leiba <barryleiba@computer.org>, Bob Hinden <bob.hinden@gmail.com>
Cc: IASA 2 WG <iasa20@ietf.org>, Alissa Cooper <alissa@cooperw.in>, iasa2-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-iasa2-rfc7437bis@ietf.org, Jon Peterson <jon.peterson@team.neustar>
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> <4710C519-37CC-4586-83E7-02776889370F@gmail.com> <CALaySJ+1q4jrFk9+g=kwk86Lc=GMpFniFWXoNYsidOL6F_uZag@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <cc578052-6be1-6a5a-f05f-2bf38d3210dc@gmail.com>
Date: Mon, 1 Jul 2019 11:10:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CALaySJ+1q4jrFk9+g=kwk86Lc=GMpFniFWXoNYsidOL6F_uZag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/kRvvlwxrg8n7hlFrp331SOMyNVg>
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 23:10:09 -0000

Barry,

> Maybe what I really don't understand is the exception that allows the
> replacement process to be done before the vacancy is announced. 

I don't believe that is the intention. I think the intention was to describe
exactly what happened in 2013:
https://mailarchive.ietf.org/arch/msg/ietf-announce/ogw1xIIrxXN-ExzUmordL1uXetk
https://mailarchive.ietf.org/arch/msg/ietf-announce/EwBi_PHbPs3a4CqJwYDjObb2VSc
i.e. an hour or so after an IAB member was announced as a new AD, NomCom
started the mid-term vacancy process. (I assume that in the intervening hour,
the IAB member resigned and the IAB duly informed NomCom of the vacancy.)

In other words "The process [...] of filling the seat" includes a call for
nominations, as it did in 2013. (The fact that it happened in May rather
than before the MArch IETF is beside the point, I think.)

I think that in this sentence:
"The resignation may remain confidential to the IAB,
 IAOC, IESG, and nominating committee until the confirmed candidate is
 announced for the new position."
the phrase "the new position" means (in the 2013 case) the Transport AD
position. Filling in the unknowns, the sentence reads:
"Spencer's resignation from the IAB may remain confidential to the IAB,
 IAOC, IESG, and nominating committee until Spencer is announced as
 the new Transport AD."

So yes, the wording could be improved to clarify what "the new position"
refers to. But (IMHO) that's an erratum, not a process bug.

Regards
   Brian

On 01-Jul-19 09:33, Barry Leiba wrote:
>>
>> 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.
> 
> One more pass on this before I give up, because I continue to think
> that not correcting a true process error is a really bad choice, and I
> don't see any other true process errors in the document.
> 
>> 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.
> 
> The IESG doesn't generally just accept faulty documents on the grounds
> that the fault wasn't caught the last time the document was updated,
> so it's OK to leave the fault in this version.  I'm OK with the other
> things, which are perhaps not as clear as they might be, but are not
> actually wrong.  So I'm trying to sort out whether this is actually
> *wrong*, or whether I simply am missing something.
> 
> So...
> Maybe what I really don't understand is the exception that allows the
> replacement process to be done before the vacancy is announced.  3.8
> says, "The process [...] of filling the seat vacated by the confirmed
> candidate may begin as soon as the vacancy is publicly announced."
> The reason for that is to allow the community to put their names in
> for consideration for the newly vacated position.
> 
> Is the exception trying to say that it's OK to fill a vacated IAB
> position without soliciting new nominations, on the grounds that the
> original call for IAB nominations should cover that, as the
> nominations for the IAB are general enough?  In other words, it is
> that we expect that anyone interested in an IAB position would have
> already put their names in, and suddenly knowing that Joe Slobotnik's
> IAB position is also open would not make a difference?
> 
> Barry
> 
>>>> 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.
>>
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>