Just as a follow-up here ...
I was John's co-author on RFC 3933 (http://tools.ietf.org/html/rfc3933).
When we were working on the draft, the problem I thought we were
solving, was that the IESG needs to update the IETF's BCP processes from
time to time, but (1) it was like 32 simultaneous root canals to
actually get community consensus to modify the IETF's process BCPs
including untried changes that might be improvements, so (2) the IESG
was using informal IESG statements developed with much less community
involvement than was expected for process BCP changes, in order to get
anything done at all.
I (and, I think, John as well) saw RFC 3933 process experiments as a
middle path between lightweight IESG decisions and full process BCP
revisions. That's what I thought Section 2 of RFC 3933 was trying to say.
I had assumed that if the IESG clearly had discretion to do something
under the current process BCPs, and thought it was the right thing to
do, they would just do it, rather than set up a process experiment.
For what that's worth.
Spencer
On 1/24/2013 12:34 PM, John C Klensin wrote:
--On Tuesday, January 22, 2013 16:31 -0500 Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't believe the
draft will materially help, and is at best a distraction from
dealing with meaningful problems.
The crux of the issue is that any attempt at "fast tracking" is
fundamentally about short-circuiting some aspect of our review
processes. We should only do that very carefully. In almost
all cases, individual judgement is needed as to when it is
appropriate to do that. ADs/WG chairs already have some
flexibility here. e.g., a WG can skip WG LC if they think its
...
Hi.
First of all, I am completely in agreement with Thomas and his
analysis. Anything that can reasonably and appropriately be
done by this sort of effort can be done by discretion without
adoption of a formal procedure and adoption of a formal
procedure creates additional and unnecessary risks.
As co-author of the process experiment model, I also object to
its use when it is not demonstrably necessary, for example to
give extra status and force IETF-wide use where the actions
suggested can be carried out as a matter of normal discretion
(see Section 5 of the document).