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
On Tue, Apr 7, 2020 at 5:25 PM John C Klensin <john-ietf@xxxxxxx> wrote:
>
> 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
> <iesg-secretary@xxxxxxxx> wrote:
>
> >
> > 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 last-call@xxxxxxxx mailing lists
> > by 2020-04-30. Exceptionally, comments may be sent to
> > iesg@xxxxxxxx instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
