This proposal sounds interesting but couldn't it run into conflicts
when there are competition in running code? Who's running code do
you fast track? How does it apply in the protocol updates area, i.e.
BIS work?
This proposal and thread, similar to the recent others, all seem to be
looking for endorsing methods for lack of a better term, "rubber
stamping" and fast tracking work items, in particular when there are
WG related barriers holding back the WG work item(s) production progress.
I personally do not have an issue with expediting work when the proper
protocol engineering is done and the adequate engineering reviews are
done, in fact, I depend on the IETF/IESG engineering do this work. I
depend on the long time wisdom and engineering judgment of the IETF
leaders and reviewers to watch over sensitive engineering issues,
including conflict of interest related matters.
In the end, we are talking about trusting the process. If IETF
participants, especially those who don't attend meetings and long
participated remotely or via mailing list, lose faith in the WG
process, these process change proposals may expedite IETF work, but
they may also handicap the potential of a proposed standard, change
and industry following.
--
HLS
Stephen Farrell wrote:
Hi all,
I've just posted an idea [1] for a small process improvement.
If it doesn't seem crazy I'll try pursue it with the IESG as
an RFC 3933 process experiment. If its universally hated then
that's fine, it can die.
The IESG have seen (more-or-less) this already but it hasn't
be discussed, so this is just a proposal from me and has no
"official" status whatsoever.
Any comments, suggestions or better ideas are very welcome.
Feel free to send me comments off list for now, or on this
list I guess. If there's loads of email (always possible,
this being a process thing;-) we can move to some other list.
Regards,
Stephen.
[1] http://tools.ietf.org/id/draft-farrell-ft
--
HLS