Subject: Re: [Last-Call] Last Call: <draft-iesg-nomcom-eligibility-2020-00.txt> (Eligibility for the 2020-2021 Nominating Committee) to Best Current Practice

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Apr 2020 19:09:37 +0100

Hi,

Thanks to Barry for putting this together and to the IESG for pushing it
forwards. I support publication as an RFC. Two small comments: one of
substance, one a trivial edit.

Cheers,
Adrian

==

I may have missed it in the discussion, but...

If we have to form a recall committee in the period before we have worked
out a long-term solution, I presume the same rules will apply. I think it
would be wise to fill this hole now because if we need it (which we won't)
then we'll need to sort it out in a real hurry.

I think we can do this with simple edits such as the following. OTOH, if
this was already discussed and discarded, then just say so and we can move
on.

Abstract
OLD
   This document only affects the seating of the
   2020-2021 NomCom, and does not set a precedent for the future.
NEW
   This document only affects the seating of the
   2020-2021 NomCom and the formation of any recall 
   Committee before the end of IETF 108, and does not set a
   precedent for the future.
END

Section 1
OLD
   The 2020-2021 Nominating Committee (NomCom) needs to be formed
   between IETF 107 and IETF 108, and the issue of eligibility of who
   can serve on that NomCom needs clarification: a one-time
   interpretation of the eligibility rules is required for this
   particular exceptional situation, given the tight timeframe for
   seating this year's NomCom.
NEW
   The 2020-2021 Nominating Committee (NomCom) needs to be formed
   between IETF 107 and IETF 108, and the issue of eligibility of who
   can serve on that NomCom needs clarification. Similarly, there is the
   possibility that a Recall Committee will need to be formed before IETF
108.
   A one-time interpretation of the eligibility rules is required for this
   particular exceptional situation.
END

Section 3
OLD
   This update is an emergency interpretation of the intent of BCP 10
   for this current exceptional situation only, and applies only to the
   2020-2021 NomCom, which is expected to be seated prior to IETF 108.
   It will explicitly not apply to any future NomCom and does not set
   precedent: another update to BCP 10 will be necessary to address
   future eligibility, as there will be time for proper community work
   on such an update.
NEW
   This update is an emergency interpretation of the intent of BCP 10
   for this current exceptional situation only, and applies only to the
   2020-2021 NomCom, which is expected to be seated prior to IETF 108,
   And to the creation of any Recall Committee that may need to be
   Seated before IETF 108.  It will explicitly not apply to any future 
   NomCom or Recall Committee and does not set precedent: another
   update to BCP 10 will be necessary to address future eligibility, as
   there will be time for proper community work on such an update.
END

---

Minor edit
Section 3
s/another update/an update/

--

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of The IESG
Sent: 02 April 2020 18:25
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Subject: Last Call: <draft-iesg-nomcom-eligibility-2020-00.txt> (Eligibility
for the 2020-2021 Nominating Committee) to Best Current Practice

The IESG has received a request from an individual submitter to consider the
following document: - 'Eligibility for the 2020-2021 Nominating Committee'
  <draft-iesg-nomcom-eligibility-2020-00.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-04-30. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract

   The 2020-2021 Nominating Committee (NomCom) needs to be formed
   between IETF 107 and IETF 108, and the issue of eligibility of who
   can serve on that NomCom needs clarification.  This document provides
   a one-time interpretation of the eligibility rules that is required
   for the exceptional situation of the cancellation of the in-person
   IETF 107 meeting.  This document only affects the seating of the
   2020-2021 NomCom, and does not set a precedent for the future.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-iesg-nomcom-eligibility-2020/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-iesg-nomcom-eligibility-2020/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2020 14:31:19 -0400

Hi, Adrian, and thanks for the response.

> then we'll need to sort it out in a real hurry.

Given that the recall process in BCP 10 explicitly refers to the
NomCom eligibility and process, I think that what's important is to be
clear that the scope of this document does include anything that's

NEW
   This document only affects the seating of the
   2020-2021 NomCom and any rules that relate to the
   NomCom process before IETF 108, and does not set a
   precedent for the future.
END

NEW
   The 2020-2021 Nominating Committee (NomCom) needs to be formed
   between IETF 107 and IETF 108, and the issue of eligibility of who
   can serve on that NomCom needs clarification: a one-time
   interpretation of the eligibility rules is required for this
   particular exceptional situation.  That interpretation will apply
   to the seating of that NomCom and to any rules that relate
   to the NomCom process before IETF 108.
END

NEW
   and to any rules that relate to the NomCom process before IETF 108.

-- 
Barry

---

From: Michael StJohns <[email-masked]>
Date: Thu, 2 Apr 2020 15:27:06 -0400

>     future eligibility, as there will be time for proper community work

Looking at the above - perhaps this is better done as a combination of 
permanent and temporary changes to BCP 10?

One permanent item maybe - or at least something that lets us deal with 
various possibilities temporarily:

"For the purposes of calculating terms and dates of the Nomcom and 
positions selected by the Nomcom, including the formation of any recall 
committee or Nomcom requirement to select mid-term replacements 'end of 
First meeting' shall be taken to mean the earliest of the last day of 
the first in-person IETF meeting of the year or of a virtual meeting 
designated by the IESG to replace the in-person meeting, or March 31st. 
Likewise for the Second meeting except that the date shall be no earlier 
than the end date of the first meeting and no later than July 30th.  
Likewise for the Third meeting except that the end date shall be no 
earlier than the date of the second meeting and no later than the 7th of 
December.  The beginning of such meeting shall be understood to be 6 
days prior to the designated end date of that meeting."

I'm not opposed to leaving the document as is - but it would be nice to 
have some idea of what the various dates mean without having to write 
another temporary amendment.

Mike

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Apr 2020 20:55:39 +0100

Hi Barry,

> tied to that process.  

Thanks. I really appreciate what you're trying to do here.

> So how about this instead?:
>
>> Abstract
>> OLD

I have a pedant's concern that the "recall process" is not the "NomCom process".

In your preamble you said "NomCom eligibility and process" and I feel that captures it better, so in the spirit of negotiation, how about...
   This document only affects the seating of the
   2020-2021 NomCom and any rules that relate to 
   NomCom eligibility or process before IETF 108, and
   does not set a precedent for the future.

>   to the NomCom process before IETF 108.

Similarly:
...and to any rules that relate to NomCom eligibility before IETF 108.

>   future eligibility, as there will be time for proper community work

And again:
s/relate to the NomCom process/relate to NomCom eligibility/

Cheers,
Adrian

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Apr 2020 15:13:33 -0500

> permanent and temporary changes to BCP 10? 

This is exactly the kind of scope creep that I (and others) had been 
worried about when the proposal was made to document the one-time 
exception process as an RFC instead of using the day-pass precedent of 
using an IESG statement. There is discussion underway on 
[email-masked] about more persistent changes, and your 
proposal would be useful input to that conversation. But given the 
timeframes that are absolutely critical in which we get consensus on 
this document, I think it is imperative that we focus on a one-time, 
non-precedent-setting decision that can be used by the NomCom chair to 
successfully run the rapidly-approaching process.

Alissa laid out some very valid concerns in her message at 
<https://mailarchive.ietf.org/arch/msg/ietf/LpGQtfEgofbJ9cvkcdX19sTloHU>, 
and attempting to expand the scope of this document beyond the immediate 
decision in front of us steers us directly towards one of the worst-case 
outcomes that she described.

/a

---

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

Adrian, I accept your amendment; thank you.

Barry

---

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

On 03-Apr-20 09:13, Adam Roach wrote:
> worried about 

Agreed. Make this document strictly limited to this year's problem.
Long term amendments can be done on a more relaxed timescale. 

I support this draft plus the clarifying changes suggested by Adrian/Barry.

    Brian

> when the proposal was made to document the one-time

---

From: Melinda Shore <[email-masked]>
Date: Thu, 2 Apr 2020 14:32:26 -0800

This strikes me as the best of the available choices, and agree
that the document needs to be narrowly scoped to cover this year,
only.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 02 Apr 2020 20:25:59 -0500

> I support this draft plus the clarifying changes suggested by 

Yep. Since Mike has said that he is "not opposed to leaving the document 
as is", let's do that. Let's just commit to getting the bigger changes 
done before IETF 110.

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 Apr 2020 22:21:01 +0200

I don't agree that this draft states only for 2020-2021, this draft should
be for the future of this period and for any consequences. Why should we go
through the process again every time if some thing happens in future.

If we issue best practice it should be for a procedure not stating one time
rule, how can you be sure that doing it once means best practice.
Please amend it to state the situation of remote participation because of a
pandemic and if it happens in the future we can use this best practice
again to solve problems without wasting time for another IESG review and
IETF review.

AB

---

From: Joel Halpern <[email-masked]>
Date: Fri, 3 Apr 2020 16:33:08 -0400

AB, I do not think you want what you have written.  If we were to do 
what you said, then until we have a face-to-face meeting there will be 
no new nomcom-eligible individuals.

As a one-time solution to the immediate problem, the document as written 
works.  Let's do it so we can move forward.
As a long term solution, no, the document does not work.  Which is why 
there are other discussions as to how to resolve the problem longer 
term.  With an expectation that there will be a suitable document 
produced before we need it.  If the community can not come to sufficient 
agreement to do that in the next 9 months, we have a different problem.

Yours,
Joel

On 4/3/2020 4:21 PM, Abdussalam Baryun wrote:
> I don't agree that this draft states only for 2020-2021, this draft 
> should be for the future of this period and for any consequences. Why 
> should we go through the process again every time if some thing happens 
> in future.
> 
> If we issue best practice it should be for a procedure not stating one 
> time rule, how can you be sure that doing it once means best practice.
> Please amend it to state the situation of remote participation because 
> of a pandemic and if it happens in the future we can use this best 
> practice again to solve problems without wasting time for another IESG 
> review and IETF review.
> 
> AB
> 
> On Thu, Apr 2, 2020 at 7:26 PM The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     [email-masked] <mailto:[email-masked]> mailing lists by
>     2020-04-30. Exceptionally, comments may
>     be sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the beginning
>     [email-masked] <mailto:[email-masked]>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 Apr 2020 23:33:45 +0200

Hi Joel,
I hope you are well,

I think it is important to consider the last 5 meetings which include 107,
but the draft does not consider and ignores the pandemic. Usually important
participants don't  attend in person when they have problems in their live
or difficulties, but still we can count them missing, but in the pandemic
situation all organisations in the world now is already attending remotely.

> no new nomcom-eligible individuals.

why not eligible for counting 107 and other last if attended. I want to
count in the 107 meeting  as in person because all business in the world do
count remote meetings and they get paid for it.

> works.  Let's do it so we can move forward.

Yes it works but IMHO it is not fair, because we are in a pandemic, and
many people in the world are suffering including IETF participants.

> term.

ok if it does not work, then I think it is better to give chance to who
attended 107 and count it. I really hope we don't loose some of our
participants in this pandemic, so counting 107 is important for  ietf
future.

> With an expectation that there will be a suitable document

There is a problem with the world or in organisation's business, so it is
good to solve things faster than 9 months.

however, thanks for your reply and comments,

best wishes,
AB

---

From: Bob Hinden <[email-masked]>
Date: Sat, 4 Apr 2020 08:53:46 -0700

> On Apr 2, 2020, at 2:37 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree that this should be as limited as possible to deal with the current issue (with changes discussed by Adrian/Barry).

Bob

> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 4 Apr 2020 10:44:13 -0600

This looks good to me. (or at least look like the least bad). 

> On Apr 2, 2020, at 11:24 AM, The IESG <[email-masked]> wrote:
> 
> 
> be sent to [email-masked] instead. In either case, please retain the beginning

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 6 Apr 2020 15:20:21 +0200

Comment on this draft number 2:
+++++++++++++++++++++++++++

*My comments and suggestions to the draft depends on understanding
some concepts which I state in some points:-*

Firstly, the best practice needs to state human rights specially in
this pandemic

and needs to state fairness and to provide opportunity to participants without

affecting the feeling that IETF is a volunteering community and work to make

all efforts count in good faith.

Secondly, IETF has meeting's core values. The RFC8718 BCP226 states
importance of openness and fairness and protection for participants,

when it describes the meeting venues it insures that venues keep
participants safe and encourage them to

work in IETF. I recommend that this draft refers to BCP226 in terms
of: 1-why we meet? 2-facilitate who want to be involved

3-inclusiveness. The BCP226 mentions safety, health risk, and travel
difficulties, that show that a meeting venue showed provide.

Therefore, it is clear at 10-March there was no where to meet in the
world and there may be another cancelled venue of 108, so

IETF needs to facilitate its goals and participant efforts.

Thirdly, the draft should be a best practice document it is just an
RFC for such period of time, BCP is for long-periods/now-and-future.

Fourthly, we need to remember/remind All that any meeting of IETF has
goals and values which is known, so does the meeting of 107 achieve

the IETF meeting goals. IMHO yes, because from BCP226 we can
understand the main values and goals of meetings to facilitate work,

specially when we are in this pandemic from February 2020 and all
people in the physical world have difficulties in living normal
physical life.

Fifthly, the IETF is part of creating the Internet (virtual world),
which is with no doubt the best place for meetings in pandemics, and
which is for long time

the best choice of many organisations to conduct meetings officially
and consider it as a real physical meeting with recognising each
identity

of users in this virtual world of the Internet which is reliable and
secured in many protocols. How can IETF not recognise a virtual
meeting and accept it

as a physical meeting specially in physical-pandemic that covered the
world from February 2020 until now while writing this last-call-draft?

We in IETF should be marketing for Internet-virtual-meetings and that
others use Internet more frequently in official meetings. There is a
future threat that

another virtual-system for the world can be used best for official meetings.

Sixth, every participant's time or effort counts, and usually it is
known that time is money for the human, but time with effort has
values (not only one value).

The values are gained by both parties of such business/community. In
IETF of volunteering efforts which is mostly virtual, so we should
never think of the money

not paid by a participant by attending this 107 virtual meeting and
making it the purpose of excluding 107 from the last five IETF
meetings. The time in pandemics

usually has very very high value for any human and for any business.
IMHO a person calling me/my-business by phone to join our work in
pandemic has more value than

some one meeting f2f in normal life.

lastly, when we exclude a meeting it means excluding
efforts/participants from different parts of the world with different
culture and different pandemic results.

We don't forget that there may be one participant that wanted to have
a chance to be eligible by attending 107 because he made two attends
but now can be excluded.

We need to be inclusive not exclusive in terms of our IETF
participants to give them chances to join NomCom.

comments for > draft-iesg-nomcom-eligibility-2020-00> Abstract>

Abstract

AB> The in person IETF 107 meeting was cancelled yes, but the abstract
should say that the

meeting was held virtually. Or it should state that there was a
meeting 107, so the abstract

*needs clarification as was there a meeting or not. As it says first
that we should decide between*

*meeting 107 and 108, but then says cancelled 107, so now we are not
between 107 and 108!!!!!!*

*AB> mentioning in-person in abstract is showing that this word is
very important for meetings, but IMHO it is not*

*the main issue in defining any meeting. A meeting is a meeting if the
managers call it a meeting officially in documents.*

*So they called it a meeting 107, and now we are between time of two
official meetings 107 and 108.*

*AB> we should use as in reference *[CANCEL107] it was mentioned *as
using same words IESG used: *The IETF107 Vancouver in-person Meeting**

AB> Abstract> amend to>

Abstract

   for the exceptional situation of the cancellation of the

   IETF 107 Vancouver in-person meeting, and that IETF107 meeting was
conducted virtually.

AB comments for > draft-iesg-nomcom-eligibility-2020-00> Introduction>

The COVID-19 outbreak, which at the time of this writing has been
   declared a global pandemic [PANDEMIC
<https://tools.ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-PANDEMIC>],
has resulted in the
   cancellation of the in-person IETF 107 meeting [CANCEL107
<https://tools.ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-CANCEL107>],
resulting
   in its conversion to a limited-agenda virtual meeting, with remote
   participation only.

AB> we need to be fair of time and place, the pandemic was in different
times and places world,

and the cancellation was on 10-March. The draft should state the date
of the scheduled

IETF Vancouver meeting 21-27-March and the date of the cancellation of
10-March.

AB> In the introduction you consider forming between two meeting, so
you consider both as meetings.

Therefore, 107 is a meeting completed by this draft and it was
recognised to form the NomCom between

it and the coming 108 meeting.

*AB> draft also needs to inform where the meeting was scheduled and
cancelled, so cancelling the meeting in Vancouver, can mean*

*having the meeting in another way or place. It was cancelled when
pandemic reached the Vancouver city, but there was places*

*in the world that organisations already cancelled their in-person
meeting and made them virtual.*

*AB> The reference [CANCEL107] should change the name because it is
trying to say 107 is cancelled but no, the *

*message by IESG was saying in the reference content that we are doing
virtual meeting 107 replacing Vancouver in-person meeting.*

*AB> change reference name>*

*From [CANCEL107] to [Vancouver] or [Van107].*

draft-iesg-nomcom-eligibility-2020-00> background>

1.  Do not count IETF 107 at all, for the purpose of NomCom
       eligibility, as BCP 10 <https://tools.ietf.org/html/bcp10>
clearly refers to in-person meetings only.
       NomCom eligibility would, therefore, be based on attendance at
       IETFs 102 through 106.

AB> why we start with not counting or with excluding attendance of 107

AB> This point is not true, the BCP 10 does not refer clearly to
*in-person* this word was not used.

BCP 10 says meeting, and meeting means that IETF calls a meeting a
meeting. Any meeting in the world is

defined by who calls it a meeting, and what IETF documents call that
meeting, it was called 107, and

it was official and not cancelled.

AB> IMHO, if you based attendance on 102-106 then that is not the last
5 meetings only if you state in this RFC

that the 107 meeting will be repeated again at one coming date.

AB> this draft by this point will not follow BCP 10 because it
includes the last 6 meetings, because a participant that

attends only 102, 103, 104, will be eligible but still was absent in
three of the real last 5 meetings (105,106,107),

that is not following BCP 10 at all.

 draft-iesg-nomcom-eligibility-2020-00> background>

2. Do not have anyone lose eligibility because of IETF 107, but do count
someone as having attended 107, for the purpose of NomCom eligibility, if
that person attended the IETF 107 virtual meeting (signed the electronic
blue sheet). People could thus gain eligibility from IETF 107, but could
not lose eligibility from it, and eligibility would be based on attendance
at IETFs 102 through 107.

AB> this point is correct, and is best practice because counting 107
and without losing eleigibility from it.

This point considers human rights, when they are called by managers
for meeting and they attend for that call.

Also considering human rights for the pandemic to give chance for who
could not attend 107, so to check 102.

draft-iesg-nomcom-eligibility-2020-00> background>

3.  Count virtual attendance at IETF 107 and consider IETF 107 as one
       of the last five meetings, so that NomCom eligibility would be
       based on attendance at IETFs 103 through 107.

AB> this point does not consider reality of organisations
business/practices in the world now, and

does not consider pandemic and human rights. the 107 meeting is one of
the last five meetings no doubt.

AB> the draft does state about pandemic but where is human rights, the
meetings are not with equal efforts.

The 102 meeting should be mentioned Montreal meeting in the draft.
Adding one meeting 102 and excluding 107,

is not fair because usually participants are absent because of the
distance of meeting usually, so if majority say include 102 and

take out 107, does that follow the BCP 10.

AB>  The draft MUST mention the meeting city of 102 as Montreal, and
other in-person included meetings' cities should be in draft. I think
also

105 was in Montreal, so we have two Montreal in the meetings included
in point-1 which excludes 107, don't think that is fair.

AB> the draft's background or introduction SHOULD state that the IETF
meetings were called by the IETF and SHOULD state on which date the
decision was made that

this 107 meeting became virtually because of pandemic.

AB> amend point 3 to>

3.  Do not count IETF 102 in-person meeting, and only consider the
       last five meetings, so that NomCom eligibility would be
       based on attendance at IETFs 103 through 107.

draft-iesg-nomcom-eligibility-2020-00> background>

In judging rough consensus the IESG has considered the arguments and
   levels of support in favor of and against each option: largely,
   issues of fairness to newer participants, acceptance of more
   participants in the volunteer pool, and greatest adherence to the
   spirit of the rules defined in BCP 10, which is the community-
   consensus basis we are working from.

AB> add>

adherence to the spirit of the rules defined in BCP226.

draft-iesg-nomcom-eligibility-2020-00>section 3>

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.
      Because no IETF 107 in-person was held, for the 2020-2021
      Nominating Committee those five meetings are IETFs 102, 103, 104,
      105, and 106.

AB> Amend to> Reading>

      Members of the IETF community must have been absent at most two of
      the last five IETF meetings in order to volunteer.

      The five meetings are the five meetings called by IESG that
      ended prior to the date on which the solicitation for NomCom
      volunteers was submitted for distribution to the IETF community.
      Because there was no availability of any meeting venue for 107
meeting, it was held virtually.

      For the 2020-2021 Nominating Committee those five meetings are
IETFs 103, 104,
      105, 106 and 107.

draft-iesg-nomcom-eligibility-2020-00>section 3>

AB> amend>

This update is an emergency interpretation of the intent of BCP 10 and BCP226
   for this current exceptional situation only, and applies only to the
   2020-2021 NomCom, which is expected to be seated prior to IETF 108.

AB> in section 6, References> Add>

[RFC8718] BCP226 as normative reference.

AB> the above reference is important, because it shows the importance
of meeting availability and inclusiveness of participants and giving
chance

to include all participants equally. Also the reference shows health
risk and travel difficulties issues, so that this pandemic of corona
results on cities can affect

choosing meetings venues in the future, and or choosing virtual meeting as well.

Take care, and best wishes,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 6 Apr 2020 16:04:37 +0200

To the Author, and to IESG,

Please amend because this is influencing community to Choose 1 and not want
to amend the eligibility.

Comment number 3
++++++++++++++++++++++++++

AB> draft-iesg-nomcom-eligibility-2020-00>  background> Amend >

1.  Do not count IETF 107 at all, for the purpose of NomCom
       eligibility, as considering IETF meetings to be in-person meetings only.
       NomCom eligibility would, therefore, be based on attendance at
       IETFs 102 through 106.

AB> The above that mentions BCP 10, makes the reader understand that
this is the best choice, because this is the only point of the three
in background that states BCP 10. The three point context is saying
the discussion is centred around but still makes reference as arguing
without argues/reference in two other points. We should let IETF
participants read the draft and read the three options with out making
an influence on their choice, or make other choices look not right.

AB> I disagree that BCP 10 is clearly referring otherwise why we are
writing this draft if it was clear. However, it is clear that virtual
real-time meeting was done long time ago, so the issue is depends on
the meeting caller if you call 107 an IETF meeting then it is a
meeting no doubt. Also, if the author does not want to amend or the
community does n't want because of consensus, then please correct in
the introduction or amend the following:

AB>amend in abstract and introduction>

The 2020-2021 Nominating Committee (NomCom) needs to be formed
   between IETF 107 virtual meeting and IETF 108 Madrid meeting,

Also, need to mention Vancouver venue was cancelled and why it was. The
draft should explain that this is first time in the IETF that there was no
availability in all IETF meeting venues, and that many cities are working
virtually including the time we are discussing and writing this
last-call-draft.

Best Regards

AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Apr 2020 15:18:46 +0100

AB, greetings.

I think you make excellent points for how we engineer NomCom eligibility in the future with full consideration of remote participation.

However, this draft is to address a very specific need against a very tight timeline. 

The risk is that if we debate your points, as I’m sure you’d agree is the correct thing to do, we will not reach agreement and consensus in time to seat this particular NomCom. I hope you will also agree that if we cannot put a NomCom in place in time, then we will jeopardise all of the processes and operational procedures of the IETF, and none of us would want that.

So this draft is a compromise proposal. Many people have discussed different approaches and details, but they have agreed to compromise.

The question for you is which of your comments are you prepared to compromise on for this one NomCom. Once this is agreed, we can have the longer and more considered discussion of how to handled future NomCom eligibility.

Best,

Adrian

From: last-call <[email-masked]> On Behalf Of Abdussalam Baryun
Sent: 06 April 2020 14:20
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Last-Call] Last Call: <draft-iesg-nomcom-eligibility-2020-00.txt> (Eligibility for the 2020-2021 Nominating Committee) to Best Current Practice

 

My comments and suggestions to the draft depends on understanding some concepts which I state in some points:-

Firstly, the best practice needs to state human rights specially in this pandemic

and needs to state fairness and to provide 

opportunity to participants without
affecting the feeling that IETF is a volunteering community and work to make
all efforts count in good faith.
 
Secondly, IETF has meeting's core values. The RFC8718 BCP226 states importance of openness and fairness and protection for participants,
when it describes the meeting venues it insures that venues keep participants safe and encourage them to
work in IETF. I recommend that this draft refers to BCP226 in terms of: 1-why we meet? 2-facilitate who want to be involved
3-inclusiveness. The BCP226 mentions safety, health risk, and travel difficulties, that show that a meeting venue showed provide.
Therefore, it is clear at 10-March there was no where to meet in the world and there may be another cancelled venue of 108, so
IETF needs to facilitate its goals and participant efforts.
 
Thirdly, the draft should be a best practice document it is just an RFC for such period of time, BCP is for long-periods/now-and-future.
 
Fourthly, we need to remember/remind All that any meeting of IETF has goals and values which is known, so does the meeting of 107 achieve
the IETF meeting goals. IMHO yes, because from BCP226 we can understand the main values and goals of meetings to facilitate work,
specially when we are in this pandemic from February 2020 and all people in the physical world have difficulties in living normal physical life.
 
Fifthly, the IETF is part of creating the Internet (virtual world), which is with no doubt the best place for meetings in pandemics, and which is for long time
the best choice of many organisations to conduct meetings officially and consider it as a real physical meeting with recognising each identity
of users in this virtual world of the Internet which is reliable and secured in many protocols. How can IETF not recognise a virtual meeting and accept it
as a physical meeting specially in physical-pandemic that covered the world from February 2020 until now while writing this last-call-draft?
We in IETF should be marketing for Internet-virtual-meetings and that others use Internet more frequently in official meetings. There is a future threat that
another virtual-system for the world can be used best for official meetings. 
 
Sixth, every participant's time or effort counts, and usually it is known that time is money for the human, but time with effort has values (not only one value).
The values are gained by both parties of such business/community. In IETF of volunteering efforts which is mostly virtual, so we should never think of the money
not paid by a participant by attending this 107 virtual meeting and making it the purpose of excluding 107 from the last five IETF meetings. The time in pandemics
usually has very very high value for any human and for any business. IMHO a person calling me/my-business by phone to join our work in pandemic has more value than
some one meeting f2f in normal life.
 
lastly, when we exclude a meeting it means excluding efforts/participants from different parts of the world with different culture and different pandemic results.
We don't forget that there may be one participant that wanted to have a chance to be eligible by attending 107 because he made two attends but now can be excluded.
We need to be inclusive not exclusive in terms of our IETF participants to give them chances to join NomCom.

 

Abstract

AB> The in person IETF 107 meeting was cancelled yes, but the abstract should say that the 

meeting was held virtually. Or it should state that there was a meeting 107, so the abstract 

needs clarification as was there a meeting or not. As it says first that we should decide between
meeting 107 and 108, but then says cancelled 107, so now we are not between 107 and 108!!!!!!
 
AB> mentioning in-person in abstract is showing that this word is very important for meetings, but IMHO it is not
the main issue in defining any meeting. A meeting is a meeting if the managers call it a meeting officially in documents.
So they called it a meeting 107, and now we are between time of two official meetings 107 and 108.
 
AB> we should use as in reference [CANCEL107] it was mentioned as using same words IESG used: *The IETF107 Vancouver in-person Meeting*
 
AB> Abstract> amend to>
Abstract
 
   IETF 107 Vancouver in-person meeting, and that IETF107 meeting was conducted virtually.

The COVID-19 outbreak, which at the time of this writing has been
   declared a global pandemic [PANDEMIC <https://tools.ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-PANDEMIC> ], has resulted in the
   cancellation of the in-person IETF 107 meeting [CANCEL107 <https://tools..ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-CANCEL107> ], resulting
   in its conversion to a limited-agenda virtual meeting, with remote
   participation only.

AB> we need to be fair of time and place, the pandemic was in different times and places world,
and the cancellation was on 10-March.. The draft should state the date of the scheduled
IETF Vancouver meeting 21-27-March and the date of the cancellation of 10-March. 
 
AB> In the introduction you consider forming between two meeting, so you consider both as meetings.
Therefore, 107 is a meeting completed by this draft and it was recognised to form the NomCom between
it and the coming 108 meeting.
 
AB> draft also needs to inform where the meeting was scheduled and cancelled, so cancelling the meeting in Vancouver, can mean
having the meeting in another way or place. It was cancelled when pandemic reached the Vancouver city, but there was places
in the world that organisations already cancelled their in-person meeting and made them virtual.
 
AB> The reference [CANCEL107] should change the name because it is trying to say 107 is cancelled but no, the 
message by IESG was saying in the reference content that we are doing virtual meeting 107 replacing Vancouver in-person meeting.
 
AB> change reference name>
>From [CANCEL107] to [Vancouver] or [Van107].

1.  Do not count IETF 107 at all, for the purpose of NomCom
       eligibility, as BCP 10 <https://tools.ietf.org/html/bcp10>  clearly refers to in-person meetings only.
       NomCom eligibility would, therefore, be based on attendance at
       IETFs 102 through 106.

AB> This point is not true, the BCP 10 does not refer clearly to *in-person* this word was not used.
BCP 10 says meeting, and meeting means that IETF calls a meeting a meeting. Any meeting in the world is
defined by who calls it a meeting, and what IETF documents call that meeting, it was called 107, and 
it was official and not cancelled.
 
AB> IMHO, if you based attendance on 102-106 then that is not the last 5 meetings only if you state in this RFC
that the 107 meeting will be repeated again at one coming date.
 
AB> this draft by this point will not follow BCP 10 because it includes the last 6 meetings, because a participant that
attends only 102, 103, 104, will be eligible but still was absent in three of the real last 5 meetings (105,106,107),
that is not following BCP 10 at all.

   2.  Do not have anyone lose eligibility because of IETF 107, but do
       count someone as having attended 107, for the purpose of NomCom
       eligibility, if that person attended the IETF 107 virtual meeting
       (signed the electronic blue sheet).  People could thus gain
       eligibility from IETF 107, but could not lose eligibility from
       it, and eligibility would be based on attendance at IETFs 102
       through 107.
 
AB> this point is correct, and is best practice because counting 107 and without losing eleigibility from it.
This point considers human rights, when they are called by managers for meeting and they attend for that call.
Also considering human rights for the pandemic to give chance for who could not attend 107, so to check 102.

 
AB> this point does not consider reality of organisations business/practices in the world now, and
does not consider pandemic and human rights. the 107 meeting is one of the last five meetings no doubt.
 
AB> the draft does state about pandemic but where is human rights, the meetings are not with equal efforts.
The 102 meeting should be mentioned Montreal meeting in the draft. Adding one meeting 102 and excluding 107,
is not fair because usually participants are absent because of the distance of meeting usually, so if majority say include 102 and 
take out 107, does that follow the BCP 10. 
 
AB>  The draft MUST mention the meeting city of 102 as Montreal, and other in-person included meetings' cities should be in draft. I think also
105 was in Montreal, so we have two Montreal in the meetings included in point-1 which excludes 107, don't think that is fair.
 
AB> the draft's background or introduction SHOULD state that the IETF meetings were called by the IETF and SHOULD state on which date the decision was made that
this 107 meeting became virtually because of pandemic.
 
AB> amend point 3 to>

 

 

AB> Amend to> Reading>

      The five meetings are the five meetings called by IESG that
      ended prior to the date on which the solicitation for NomCom
      volunteers was submitted for distribution to the IETF community.
      Because there was no availability of any meeting venue for 107 meeting, it was held virtually.
      For the 2020-2021 Nominating Committee those five meetings are IETFs 103, 104,
      105, 106 and 107.

 
AB> amend>

 
 
AB> the above reference is important, because it shows the importance of meeting availability and inclusiveness of participants and giving chance
to include all participants equally. Also the reference shows health risk and travel difficulties issues, so that this pandemic of corona results on cities can affect
choosing meetings venues in the future, and or choosing virtual meeting as well.

On Thu, Apr 2, 2020 at 7:26 PM The IESG <[email-masked] <mailto:[email-masked]> > wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] <mailto:[email-masked]>  mailing lists by 2020-04-30. Exceptionally, comments may
be sent to [email-masked] <mailto:[email-masked]>  instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Apr 2020 11:03:08 -0400

EXEC SUM:  I can live with the proposed option 1

It appears in section 3 that option 1 has been chosen.
Maybe that could be more explicit?  I had to compare text.

Snark:
        I find the preference of option 1 to be very self-serving of the current
        group of people who are well funded, and blessed with good visa-karma to
        always be able to attend, and it is apparent to me, have essentially never
        been remote.

I believe that *option 3* (count virtual attendance) adheres to the rules
better, and provides better ongoing eligibility to counting towards 2021/2022.
I don't think that we can repeat *this* process if we cancel the in-person IETF108.

** Will eligibility-discuss be allowed to come up with a different way of
** counting IETF107 for the purpose of 2021/2022?
{I appreciate what the last paragraph of section 3 says, and it seems to
support the concept that 2021/2022 could count IETF107 differently.
In particular, this means that we probably need the datatracker to be
loaded with Bluesheet and Registration information.  So I think the answer is
** YES, but I would re-word that paragraph to say so}

I would like to know the difference in count between the three options.
To do that, we need bluesheet information loaded to the DT.

I suspect that it is in fact very small (at most five people, excluded by
option 1, but included by 3), and it is for that reason:

**
**      I can live with the proposed option 1
**

I found option 2, "do not lose eligibility" to be rather unclear.
I think that what it is saying is that elibility will be 3 out of 6, rather
than 3 out of 5, and perhaps it would better if it just said that.

As such, options 2 and 3 are actually:

2. Count virtual attendance by bluesheet at IETF 107 as attendance.

2A.      Change the formula to be 3 of 6, counting
         IETF102 through IETF107.

2B.      Leave the formula to be 3 of 5, counting IETF103 through IETF107.

Option 1 and 2A benefits people who would normally have been eligible, but
who couldn't be bothered to attend the (virtual) plenary or any of the BOFs.
That's the group of people who have *their* single WG, and they attend it
only, and they don't socialize outside that group, and don't pay attention to
IETF-wide issues.
(to be nicer: maybe their home Internet connectivity sucks, but they
regularly watch the youtube feed from a coffee shop or office, to which they
can not attend)
2A helps people who have attended two meetings, so are new, and independent
of pandemic would not have been able to travel anyway (for reasons of: visa,
funding, parenting)

I think that 2B best recognizes people who are connected to the IETF, who
attend the virtual plenary and BOF, even if they are new and/or forced to be
virtual.

(If you take the union of IETF107 attendance and IETF102 attendance, and
remove the common subset, then the remaining people are the list of people
who might be affected by the changes.  Some won't be eligible at all.
I would calculate that, but the IETF107 Attendee list is not available on the site)

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 6 Apr 2020 10:16:39 -0500

On 4/6/2020 9:18 AM, Adrian Farrel wrote:
> The risk is that if we debate your points, as I’m sure you’d agree is 
> the correct thing to do, we will not reach agreement and consensus in 
> time to seat this particular NomCom. I hope you will also agree that 
> if we cannot put a NomCom in place in time, then we will jeopardise 
> all of the processes and operational procedures of the IETF, and none 
> of us would want that.
>

I completely agree with Adrian's assessment here. I have thoughts about 
many of the detailed points that AB has raised, but am not bringing them 
forth because driving them to conclusion would likely take more time 
than we currently have.

/a

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Apr 2020 15:16:48 +0000

I disagree with you Abdussalam.  The draft states a view, it doesn’t force others (e.g., you) to agree with it.

I happen to agree with the draft.  Going by public comments, so do many others.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 6 Apr 2020 22:34:37 +0200

Hi Adrian and Adam,

Thanks for your reply and advise. My reply to your comments below,

On Mon, Apr 6, 2020 at 4:18 PM Adrian Farrel <[email-masked]> wrote:

> AB, greetings.
>
>
>
> I think you make excellent points for how we engineer NomCom eligibility
> in the future with full consideration of remote participation.
>
>
>

ok, so our last call comments to IESG will still be documented in IETF. In
future, some students may read it all, and make comments and analysis of
this as past. In my culture,
people in present always should think how future people/new-generation will
read past decisions and interactions.

> The risk is that if we debate your points, as I’m sure you’d agree is the
> correct thing to do, we will not reach agreement and consensus in time to
> seat this particular NomCom.
>

I never thought of this risk, because I always think if no consensus still
the IESG can make the draft official and issue their decision for this
specific tight timeline. The IESG has the authority
and power to solve any IETF problem if there was no consensus specially for
administrative RFCs. I usually send my last call comments to IESG request,
and I did not much make discussions
in IETF list because I think they already had their decision with
consensus, and we are now in IESG last call.

I hope you will also agree that if we cannot put a NomCom in place in time,
> then we will jeopardise all of the processes and operational procedures of
> the IETF, and none of us would want that.
>

I am not sure I understand. Do you mean that NomCom cannot be formed by
IESG decision only if there is consensus? Doesn't IESG have the authority
to make a special decision if there was no consensus?

 I think the spirit of consensus-rule is effective and helpful in my old
culture, they used by finding the right thing to do for community. When
there is consensus, then that means we will have many to use the decision
and obey the order, but on the other hand, if we don't have consensus that
will mean that there may be a problem in the proposed-decision or in the
community, so it is better to force a fair decision that makes amendments
that is close to logical best practice. That is why we need a high board to
direct communities, and in IETF, that is why we need IESG.

I think it is the power of IESG to review this last call draft, to form
NomCom, and to make draft fair and make it following all BCP spirits which
should include good faith. I like to trust the IESG they do their best but
still they can get in future critical analysis to their decisions or
interactions.

>
>
> So this draft is a compromise proposal. Many people have discussed
> different approaches and details, but they have agreed to compromise.
>

ok that they did compromise discussions, but the draft did not reflect that
interaction. I read it and gives less information of the real situation of
this pandemic and no availability of meeting venue. This pandemic is very
very special and this NomCom will be also very special and their work will
be very special if the pandemic does not stop before few months. May God
bless all,

>
>
> The question for you is which of your comments are you prepared to
> compromise on for this one NomCom. Once this is agreed, we can have the
> longer and more considered discussion of how to handled future NomCom
> eligibility.
>

Usually in IETF compromise can happen between participants that recognise
each other or reply to each other in discussions, there can be participants
that are ignored or excluded, or blocked by some groups in WGs or by groups
in IETF list. I have very few participants that reply or recognise me, so
how could I compromise with who does not recognise me. However, if you mean
me and you to compromise between our opinions, I will need to discuss with
you in a different subject/thread of not IESG-Last-Call, but we can discuss
as subject: the IETF compromised proposal.

On Mon, Apr 6, 2020 at 5:16 PM Adam Roach <[email-masked]> wrote:

> The risk is that if we debate your points, as I’m sure you’d agree is the
> correct thing to do, we will not reach agreement and consensus in time to
> seat this particular NomCom. I hope you will also agree that if we cannot
> put a NomCom in place in time, then we will jeopardise all of the processes
> and operational procedures of the IETF, and none of us would want that.
>
>
> forth because driving them to conclusion would likely take more time than
> we currently have.
>
IMHO  thinking of risks and time SHOULD not affect our comment to IESG, the
IESG now is asking for comments with this Last Call, why should we not give
our real views or full reviews and comments.
IMHO it is a problem to feel that we can not comment fully, because we
don't have time, which I think there is no need for long time, because the
time frame is structured and is until 30 April and fixed and a decision
will be made by IESG with consensus or without consensus.

Best Wishes,

AB

> *From:* last-call <[email-masked]> *On Behalf Of *Abdussalam
> Baryun
> *Sent:* 06 April 2020 14:20
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Last-Call] Last Call:
> <draft-iesg-nomcom-eligibility-2020-00.txt> (Eligibility for the 2020-2021
> Nominating Committee) to Best Current Practice
>
>
>
> *My comments and suggestions to the draft depends on understanding some concepts which I state in some points:-*
>
>
>
> Firstly, the best practice needs to state human rights specially in this
> pandemicand needs to state fairness and to provide
>
> should say that the meeting was held virtually. Or it should state that
> there was a meeting 107, so the abstract
>
> *needs clarification as was there a meeting or not. As it says first that we should decide between*
>
> *meeting 107 and 108, but then says cancelled 107, so now we are not between 107 and 108!!!!!!*
>
>
>
> *AB> mentioning in-person in abstract is showing that this word is very important for meetings, but IMHO it is not*
>
> *the main issue in defining any meeting. A meeting is a meeting if the managers call it a meeting officially in documents.*
>
> *So they called it a meeting 107, and now we are between time of two official meetings 107 and 108.*
>
>
>
> *AB> we should use as in reference *[CANCEL107] it was mentioned *as using same words IESG used: *The IETF107 Vancouver in-person Meeting**
>
>
>
> AB> Abstract> amend to>
>
> Abstract
>
>
>
> *AB comments for > draft-iesg-nomcom-eligibility-2020-00> Introduction>*
>
>
>
>    declared a global pandemic [PANDEMIC <https://tools.ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-PANDEMIC>], has resulted in the
>
>    cancellation of the in-person IETF 107 meeting [CANCEL107 <https://tools..ietf.org/html/draft-iesg-nomcom-eligibility-2020-00#ref-CANCEL107>], resulting
>
> *AB> draft also needs to inform where the meeting was scheduled and cancelled, so cancelling the meeting in Vancouver, can mean*
>
> *having the meeting in another way or place. It was cancelled when pandemic reached the Vancouver city, but there was places*
>
> *in the world that organisations already cancelled their in-person meeting and made them virtual.*
>
>
>
> *AB> The reference [CANCEL107] should change the name because it is trying to say 107 is cancelled but no, the *
>
> *message by IESG was saying in the reference content that we are doing virtual meeting 107 replacing Vancouver in-person meeting.*
>
>
>
> *draft-iesg-nomcom-eligibility-2020-00> background>*
>
>
>
> * draft-iesg-nomcom-eligibility-2020-00> background>*
>
>
>
> *draft-iesg-nomcom-eligibility-2020-00> background>*
>
>
>
> *draft-iesg-nomcom-eligibility-2020-00> background>*
>
>
>
>
>
> *draft-iesg-nomcom-eligibility-2020-00>section 3>*
>
>
>
>
>
>
>
> *draft-iesg-nomcom-eligibility-2020-00>section 3>*
>
>
>
>
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 07 Apr 2020 10:17:19 +1000

On Tue, Apr 7, 2020, at 06:34, Abdussalam Baryun wrote:
> IMHO thinking of risks and time SHOULD not affect our comment to IESG, the IESG now is asking for comments with this Last Call, why should we not give our real views or full reviews and comments.
> IMHO it is a problem to feel that we can not comment fully, because we don't have time, which I think there is no need for long time, because the time frame is structured and is until 30 April and fixed and a decision will be made by IESG with consensus or without consensus.

I'm going to pop on my programmer/product hat and see if I can make an analogy.

Sometimes you are working on a new feature, or a brand new release of a product. Sometimes you have an urgent bugfix or security fix.

When you're working on version 2 of the product, you look at the user stories and the architecture of the codebase and refactor as appropriate to provide the best product for the future.

When you're doing an urgent bugfix or security patch, you make the minimally invasive change possible. You try to keep the diff minimal so it's easy to reason about. You don't alter the whitespace to comply with the latest code style guide, you don't change APIs, and you most certainly don't try to shoehorn all the new features from version 2 into the security patch to version 1.

Back to the situation at hand. The IESG is trying to apply an urgent patch to the NomCom process to deal with an emergent issue. There are other known deficiencies in the process which are being worked on for version 2. This is not the effort to produce version 2 - this is the effort to apply an emergency patch version 1 so it keeps working in the short term - which is why there's pushback at trying to pull version 2 considerations into it (like Michael's "Snark" today about it favouring those who can attend physically. Yep - that's a designed in property of v1 - and it's not the task of this minimal patch to change that design).

Cheers,

Bron,

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Apr 2020 17:25:09 -0400

Hi.  
Sorry to have not responded more quickly.

First and most important, with the addition of the changes
suggested by Adrian and Barry, I agree with Cullen: this is
probably the least-bad solution (or tied for that distinction)
and I support it on that basis.  

I would prefer that the document be explicit about an issue
partially pointed out by others, i.e., that a future,
longer-term, proposal be able to change the status of IETF 107
wrt counting for NomComs after this one.   For example, in the
last paragraph of Section 3, we might change:

Old:
	precedent: another update to BCP 10 will be necessary to
	address future eligibility, as there will be time for
	proper community work on such an update.

New:
	precedent: another update to BCP 10 will be necessary to
	address future eligibility, as there will be time for
	proper community work on such an update.  That update
	may change how participation in IETF 107 is counted for
	the 2021-2022 NomCom and for any activities related to
	NomCom eligibility (other than seating the 2020-2021
	NomCom) after it becomes effective.

This would accomplish two things.   First, it makes it a little
bit more clear that that there is no constraint on the
longer-term effort figuring out a way to count some criterion
for attendance at IETF 107 and doing so.  Having that option
will be particularly important should IETF 108 be virtual (as
seems likely after yesterday's IESG announcement).  I think most
of the discussion has been consistent with the possibility of
counting IETF 107 somehow for NomComs after this one, so that is
just a clarification.  

The other is that there is a scenario, however unlikely, in
which Barry's formulation probably does not work.  As I read his
text, the certification of eligibility for signing Recall
Petitions and qualifications to volunteer for any Recall
Committee seated before the 2021-2022 NomCom is seated would
follow the eligibility rules for the 2020-2021 Nomcom.   If the
longer-term effort concludes (and concludes before or right
after IETF 108) that IETF 107 (and 108) should be counted
somehow, it is not clear to me that we want qualifications to
filed a petition in, say, August, to be evaluated against
eligibility to volunteer for the 2020-2021 NomCom under these
emergency rules.  RFC 8713 further complicates the situation
because it says "qualified to be voting members of a NomCom" (in
Section 7.1.1) and "The five meetings are the five most recent
meetings that ended prior to the date on which the solicitation
for NomCom volunteers was submitted for distribution to the IETF
community" (Section 4.14). without, AFAICT, specifying whether
the Secretariat is to count the five meetings prior to when the
petition was filed or the five meetings used to determine
eligibility for the either the most-recently-seated Nomcom or,
if the petition is filed between the third meeting of one year
and the end of the first meeting of the next, the next one.

I don't believe we either can or should try to discuss those
issues now, much less block this document waiting for them to be
resolved, but (especially given the second concern below) we
shouldn't have anything in this document that would appear to
preclude the longer-term effort from addressing them and having
its conclusions reflected immediately. 

I have two additional concerns, which are probably best noted as
issues for future consideration while we move forward with this
document:

(1)  With appreciation for Michael's analysis and comments and
other attempts to go through scenarios, I am a bit concerned
about fairness to one hypothetical class of people, those who
started coming to IETF meetings with IETF 105, attended 106,
expected to attend 107, and who have plunged themselves into the
IETF's work sufficiently that they intended to volunteer for the
NomCom.  I find it harder to be concerned about people who have
stopped attending meetings and intermittent attendees in part
because, until we make changes to how the NomCom operates
(already too late for the upcoming volunteer pool), I don't see
them as volunteering for the NomCom in significant numbers
whether they are eligible or not (nor have I seen anything since
these discussions started that would change that guess).  But,
while I am guessing that the pool of those very active relative
newcomers is small and the subset of them who would have
volunteered is smaller still, there is at least a hint of
unfairness that we should note, if only to add to the sense of
urgency about the longer-term work.

(2) I don't think we could have done better with the tools we
have and in the available time and I think we owe the IESG
thanks for navigating through this.  However, this document is
the result of a proposal from the IESG to deal with an issue
whose outcome will affect the membership of the 2021-2022 IESG
(including whether incumbents who are willing to serve again are
returned); community discussion whose conclusions were less than
obvious and crystal-clear; a document produced by the IESG
reflecting their analysis of community rough consensus and that,
coincidentally I'm sure, includes approximately the same
proposal for how to move forward that they proposed initially;
and the same IESG evaluating the results of this Last Call.
Again, given the available procedures and time pressure, I think
the IESG made the best of a bad situation and could not have
done much better.  But I think the situation strongly suggests
that, in addition to looking at the Nomcom and eligibility rules
for the future, we need to think about procedural mechanisms to
avoid putting the IESG in a position in which, in order to Do
the Right Thing, they are trapped into a situation in which they
need to act as Proposer, Document Author, Discussants,
Consensus-determiner, and Document approver [1], especially in
situations in which a reasonable person could conclude that they
were working with situations that might have a direct effect on
them.

thanks,
  john

[1] More complicated, IMO, than arresting officer, judge, jury,
and maybe executioner.

--On Thursday, April 2, 2020 10:24 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from an individual submitter
> to consider the following document: - 'Eligibility for the
> 2020-2021 Nominating Committee'
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists
> by 2020-04-30. Exceptionally, comments may be sent to
> [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Apr 2020 19:32:18 -0400

Hi, John, and thanks for the thoughtful note.  I agree with the sense
of everything you say, but the bottom line on all of it is that any
effort to do a proper BCP can -- of course -- update anything that
came before it, and always could.  I'm happy to say that explicitly
here, so I suggest that both of your points can be handled together
this way:

OLD
        precedent: another update to BCP 10 will be necessary to
        address future eligibility, as there will be time for
        proper community work on such an update.
NEW
        precedent: an update to BCP 10 will be necessary to
        address future eligibility, as there will be time for
        proper community work on such an update.  That update
        could change any part of the BCP 10 process, including
        anything specified in this document.
END

What do you think?

Barry

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Apr 2020 21:57:29 -0400

--On Tuesday, April 7, 2020 19:32 -0400 Barry Leiba
<[email-masked]> wrote:

> Hi, John, and thanks for the thoughtful note.  I agree with
> the sense of everything you say, but the bottom line on all of
> it is that any effort to do a proper BCP can -- of course --
> update anything that came before it, and always could.  I'm
> happy to say that explicitly here, so I suggest that both of
> your points can be handled together this way:
> 
> OLD
>         precedent: another update to BCP 10 will be necessary
> to         address future eligibility, as there will be time
> for         proper community work on such an update.
> NEW

Barry,

Thanks for the quick response.  The above works for me and
solves the main problem I was concerned about.

It does, however, reinforce the notion that this document is
"part of the BCP 10 process" and hence that it should be part of
BCP 10, however temporarily.

thanks again, 
   john

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2020 14:12:14 -0400

I am about to submit version -01 with the changes discussed so far.
Please continue last call discussion in this thread.

Barry