Hi, Dave,
While it is vastly more convenient, for the IESG, to have it take
initiative and
decide on its own to make a more strict rule and issue it in a document
that
does not go through public vetting, it isn't the way things are supposed
to be
done in the IETF.
Just to ring one of the changes here...
I'm actually OK with the process that Dave is not OK with, because I'm
assuming that "public vetting" can also be retroactive - as long as the IESG
announces rules publicly, I trust the community to point out problematic
rules with great enthusiasm, and trust that the IESG will not go into
"because we said so" mode when someone does point out that a new rule is
problematic.
If my trust is misplaced, we have bigger problems than process changes, I
think.
If the IESG is now responsible for inventing IETF policy, that ought to be
acknowledged and documented explicitly.
One of the many contortions we went through on process change was trying to
distinguish between policy and procedure. Our "current"(?) process BCPs
don't make this distinction well.
I'm totally good with the IESG inventing IETF *procedures*, and that's what
I think most of the ID checklist is. I would not be good with the IESG
inventing IETF *policy* without community involvement, but that's not what I
think is on the block.
Unannounced rules ("double SECRET probation") would be a problem, but I
don't see anyone arguing in favor of undocumented late-surprise barriers.
Thanks,
Spencer
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf