Date: Tue, 31 Mar 2020 13:56:19 -0400
From: Alissa Cooper <alissa@xxxxxxxxxx>
Message-ID: <0C31D020-46FA-424E-8FFD-64BBE8F952E9@xxxxxxxxxx>
First, you can all ignore my opinion if you like, I haven't been part of
the IETF process for many years, and don't usually even read any of the
(voluminous) IETF related e-mail I still get sent. But I noticed all of
this tonight (I have only read a very few of the most recent messages, and
have no idea what proposals have been made).
Second, assuming it isn't already in the nomcomm process doc (I thought
it was, but perhaps not) the first thing that should be done, right now,
is to last call a 2 line (plus 27 pages, or whatever it is up to these days,
of boilerplate) BCP RFC-to-be (I-D initially) which simply says:
In case a new nomcom is not seated, for any reason, the previous
nomcom shall continue to serve.
That gets over any "Danger Will Robinson" type nonsense about "we absolutely
have to reach consensus or the whole process falls apart".
The previous nomcom might not be thrilled at this - but it is unlikely
(even this year) to ever be put into practice, but the process needs this
one vulnerability covered (assuming it isn't already).
Beyond that:
| I think what you suggest is a recipe for either delegitimizing the IETF
| or causing it to enter a state of dysfunction. It assumes there will be
| consensus at the end of four weeks.
Anything that is to make forward process has to assume rough consensus
for a change exists. If we ever get to the state where the IESG starts
saying (for any reason) "we have no consensus on what to do, but we believe
we must do something, so we have decided to do ..." then all is truly lost.
Personally, I'd like that to happen - I believe that the current IESG
process (and workload) is all broken, and needs a revolution to fix it,
and that kind of thing could provoke exactly the needed revolution.
That would be very similar to the IAB's Kobe decision (mid 90's) which
resulted in the revolution which installed (approximately) the current
process. The same would happen to the IESG I believe (and a good thing
that would be - it would return the IESG back to the job of managing the
IETF's work, and get it out of the standards (including BCP) approval
business).
Overall, I believe that the process Pete set out (along with the BCP I
suggested above) is the best way for all of you to make progress for
this year.
kre
