Subject: Re: NomCom eligibility & IETF 107

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Apr 2020 16:19:43 -0400

Barry Leiba <[email-masked]> wrote:
    > THIS NOMCOM CYCLE ONLY and SETTING NO PRECEDENT, I would replace the
    > first two paragraphs this way:

...

    > The question I will ask is this: Is there anyone who *can't live with
    > that outcome*?

I can live with this.

{I think that the impact is very small, and might even be zero.
I intend to try to determine the numbers exactly.
Having the Bluesheets entered from last week would help some scenarios.}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2020 10:03:05 -0400

The IESG has listened to the discussion and has reconsidered.  We have
posted an Internet draft:
https://datatracker.ietf.org/doc/draft-iesg-nomcom-eligibility-2020/

Murray will be the shepherding AD, and will request a four-week last
call later today, to end on 30 April, the deadline we had set for
comments.  The following week (7 May) will have an IESG telechat, and
we would expect to have the document on that telechat agenda for
approval.

The substantive bit in the document is as I described in the message below.

Barry, for the IESG

On Tue, Mar 31, 2020 at 3:37 PM Barry Leiba <[email-masked]> wrote:
>
> While we are sorting this out, and whether we publish an Internet
> draft or not, I would like to know this:
>
> As I (Barry, not the IESG as a whole) currently read the rough
> consensus, considering what people have said the reasons you all have
> given, and the discussion of those reasons, I see things falling
> toward option 1.  Specifically, looking at RFC 8713, Section 4.14, FOR
>    Members of the IETF community must have attended at least three of
>    the last five in-person IETF meetings in order to volunteer.
>
>    The five meetings are the five most recent in-person meetings that
>    ended prior to the date on which the solicitation for NomCom
>    volunteers was submitted for distribution to the IETF community.
>    For the 2020-2021 Nominating Committee those five meetings are
>    IETFs 102, 103, 104, 105, and 106.
>
> That question is not asking what you *prefer*; I've read all of those,
> and I am still collecting that input further.  But for the purpose of
> this question, does anyone think that outcome is so bad that you can't
> accept it?  If you can live with it, there's no need to respond.  Just
> let me know if you can't.
>
> Barry
>

---

From: Joel Halpern <[email-masked]>
Date: Thu, 2 Apr 2020 10:08:27 -0400

Thank you Barry.  This works for me.
Yours,
Joel

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Apr 2020 14:21:37 +0000

Thank you.  It is rarely easy for experienced people to change their mind, more so when it's a group.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Apr 2020 14:23:46 +0000

I like the document, it gives a nice rationale for what happened, things to consider, and comes to a conclusion.

I support it.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 2 Apr 2020 09:41:08 -0500

On Wed, Apr 1, 2020 at 3:20 PM Michael Richardson <[email-masked]>
wrote:

> ....

I agree. Why not include IETF 107?

Regards,
Behcet

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Apr 2020 10:56:24 -0400

> The substantive bit in the document is as I described in the message below.

Thanks, Barry.  This looks good, and I support adoption of this document 
as BCP.

Keith

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2020 10:25:53 -0500

> The substantive bit in the document is as I described in the message below.

+1.  Thanks for submitting an I-D.

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 02 Apr 2020 11:22:37 -0500

> https://datatracker.ietf.org/doc/draft-iesg-nomcom-eligibility-2020/

Looks good. I am fine with the document.

Strictly editorial comment: In section 2, last paragraph, I suggest 
changing the CREF to, "Note: The previous two sentences will be replaced 
before publication with, 'This document contains the outcome of that 
discussion.'"

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2020 13:03:05 -0400

Ack; sensible suggestion.  Thanks.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2020 13:04:37 -0400

> Ack; sensible suggestion.  Thanks.

Actually, I won't bother making that CREF change now, but will just
*do* that change when the doc is approved.

Barry

---

From: Bob Hinden <[email-masked]>
Date: Thu, 2 Apr 2020 10:07:06 -0700

Barry,

I read the draft and I support it.

One nit:  Should it say that it updates BCP10?

Bob

d
> On Apr 2, 2020, at 7:03 AM, Barry Leiba <[email-masked]> wrote:
>

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 02 Apr 2020 12:09:27 -0500

> *do* that change when the doc is approved.

Perfectly reasonable. Thanks.

pr

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2020 13:15:16 -0400

> I read the draft and I support it.

Thanks, Bob.

> One nit:  Should it say that it updates BCP10?

I think it should not, but should be its own BCP.

We need a broader effort to update BCP 10, but this is a one-time
exception.  Publishing it as a BCP is a process formality, but sets no
precedent and won't apply after this year's NomCom is seated.  I think
it would be wrong for it to formally update BCP 10.

Barry

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2020 18:10:53 -0000

In article <[email-masked]>,
>I think it should not, but should be its own BCP.

I'm enough of an optimist to hope that we don't need a defined process
for future global pandemics.  And even if we did, the chances that the
next pandemic would be sufficiently similar to use the same changes
are low.  Put it on the calendar for 2122.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 02 Apr 2020 15:12:03 -0500

On 2 Apr 2020, at 13:10, John Levine wrote:

> In article 
> <[email-masked]>,
> for future global pandemics.

I think the "broader effort to update BCP 10" Barry was referring to is 
the nascent effort to deal with NomCom eligibility in general, 
especially for remote participants, not a process for pandemics. :-)

That said, while I agree that this document needn't be marked as 
updating RFC 8713 (it's pretty ephemeral; no need to document something 
in the text of the RFC for this), I do think it's reasonable to make it 
part of BCP 10. This document will be part of the NomCom process. When 
the broader update to BCP 10 arrives and obsoletes this document, it 
will be removed from BCP 10 and replaced by the broader update. That's 
the normal way we deal with BCPs.

But all of this is a teeny tiny point. Let's get the document approved, 
and the IESG can figure out the correct process buttons to push when 
we're done.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Apr 2020 10:21:43 +1300

> it would be wrong for it to formally update BCP 10.

Fully agree. And the draft is fine by me.

     Brian

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2020 16:45:26 -0500

Regarding whether this updates or is part of BCP 10, the best reason to
do it is to make it possible to observe this via the various tools and
search engines.  Even long after this crisis is over, the fact that this
happened can prove useful a) to scholars, b) if a new crisis should come
up it will show how we handled it this time.  (b) is not the same as
setting precedent, though it could effectively set precedent in a way,
and not listing this as an update or part of BCP doesn't preclude
setting precedent.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Apr 2020 18:10:08 -0400

--On Thursday, April 2, 2020 13:15 -0400 Barry Leiba
<[email-masked]> wrote:

> We need a broader effort to update BCP 10, but this is a
> one-time exception.  Publishing it as a BCP is a process
> formality, but sets no precedent and won't apply after this
> year's NomCom is seated.  I think it would be wrong for it to
> formally update BCP 10.

Barry, 

lLet me try an alternate theory out on you.  First, however
temporarily, this is a clarifying update to RFC 8713.
Regardless of what decisions are made about BCP numbers, that
update should be noted in the draft to make the thread clear and
so, at least during the several months (or perhaps close to a
year if there is a recall effort) in which this procedure is
active and relevant, any effort to look up the topics covered by
8713 provides a clear path to this specification.  I think,
given that, treating it as part of BCP 10 follows, but I don't
think it makes a lot of difference as long as the "updates"
thread is clear.

I don't think the "updates" relationship can be avoided.  When
the first sentence in Section 3 of the I-D says:

	The following text modifies, for the 2020-2021 NomCom
	selection only, the first two paragraphs (quoted above)
	of Section 4.14 of BCP 10 [RFC8713]:

That is about as clear a candidate for "updating" (in this case
8713) as I've seen in some time.

I do recognize what I think is your concern about BCP 10, but it
seems to me that is easily handled: when the more permanent fix
(the "[an]other update to BCP 10 [that] will be necessary..."
comes along, it formally obsoletes this temporary document,
making clear that the emergency interpretation no longer applies
and specifying what does.  Move it to Historic too, if that
seems sensible.   And, if having a dead document as part of BCP
10 bothers people. remove it at that time.

Just a thought...
   john