Minutes interim-2022-elegy-01: Tue 10:00
|Meeting Minutes||NomCom Eligibility Update (elegy) WG|
|Date and time||2022-09-27 14:00|
|Title||Minutes interim-2022-elegy-01: Tue 10:00|
Virtual Interim meeting 2022-09-27 1400 UTC.
Note Well and Agenda Bashing
WG management decisions (how will we work).
Belief that going forward that everything that was in 8989 is already
consensed, and that is the default.
That in order to change things we need active consensus to change this.
JH: reminds that we need to confirm this on the list.
RS: what, realistically is the real most publish date for this document?
BL: end of November, right after IETF115 meeting.
- Editorial Issues with Adopted Document
Martin shares github, and some PRs for editorial stuff were already done
and were committed.
- MD: todo to have an available data section. Don't have any data, and
do not have a strong conviction about what should be there. Please
send data if you have it, or have ideas about what should go there.
- RS: Robert has to generate the data, and to do so, need really well
defined questions for this. Have some implementation to finish
before the data can be produced. It will be mid-October before
anything can be provided. So, fits into November deadline.
- RS: But, first, would like to challenge if we really need any more
data? When we were doing the experiment, we need to prove it. But
maybe it is a distraction to get the data out?
- MD: if nobody responds to the question, then maybe we need results
of the experiment.
- MCR: is there data that we should be produced regularly that should
be specified in this document? Is this data that we need to produce
regularly, or can it be produced retroactively easily?
- RS: for the 2021 nomcom, we are getting some data with some
integrity checks already, so going forward, we can get better data.
- MCR: but do we need to specify reports?
- RS: the data that we need to get is just never going to be going
- MD: the Security Considerations has some hints about there might
need to be indicators.
- BL: this document is ending the experimenting, rather than starting
it. Not the point to argue to prolong the experiment.
MD: leave this open for awhile, have not got a clear direction yet.
MD: more substantive item is directorate eligibility proposal.
Originally proposed this when the number of remote people was going
to be curtailed? Do we really want people just doing directorate
reviews? Probably no.
RS: looked at membership of directorate, just being a member will be
noisy, so will need some aspect of doing actual reviews. That exact
threshold might be difficult to establish and get consensus on.
MD: another issue, not yet in github, is authorship of the document.
Could hand the pen away, could bring on co-author, or do nothing and
- BL a few people thought it would be good to have a co-author.
- JK more concerned that we discuss it. Just concerned that it not
happen by accident.
- BL we develop community consensus on this, and if someone disagrees
then they have an avenue to complain.
- JK we always say that, but it never quite works... but is okay.
- Core Content issue with Document
next steps: clean up acknowledgements, wait for additional comments...
- DE: would like to simplify things, do not think we need all three
- MD: as we are expanding to do the remote attendance, then the other
paths are far less important now.
- BL: we are looking for people who are familiar with the IETF, which
does not necessarily mean that they are going to meetings. Would not
like to remove other paths.
BL will post to the list the plan that he started with, that we need
proposals for change. The idea to finalize things for IETF115.
DE = Donald Eastlake
JK = John Klensin
JH = Joel Halpern
RS = Robert Sparks
BL = Barry Leiba
MCR= Michael Richardson
MD = Martin Duke