Hi,
Using my newtrk post as a springboard for a more generic issue:
As Harald said on the plenary, it seems more or less required to
create a mechanism where certain process changes could be approved and
reviewed without conflicting seriously with the "technical day-to-day
job" (as Bert said) and a conflict of interest.
That is, such decisions shouldn't need to be done by the IESG. IAB
might be an easy choice, in the absence of anything else readily
available..
I don't think we even need a formal process change to do so: just an
agreement from the IESG that they would not "step in the way" after
the said body says it's done with a proposal (we even have a mechanism
for this though it's not procedurally suited to modify BCPs: IAB
Informational RFCs).
Note that I believe that if there would be a significant community
agreement on any change, the IESG would not stand on the way no matter
its members' personal beliefs. (Though getting that consensus might be
easier if there was another, less loaded body evaluating and helping
one to drive the efforts.)
---------- Forwarded message ----------
Date: Thu, 4 Aug 2005 09:42:24 +0300 (EEST)
From: Pekka Savola <pekkas(_at_)netcore(_dot_)fi>
To: newtrk(_at_)lists(_dot_)uoregon(_dot_)edu
Subject: On the priorities of process change
(This might have been appropriate to the IETF list but decided to go for a
smaller scope this time.)
Bert and Sam's comments on the plenary made me think of the process change
priorities a bit.
I'm symphatetic to the belief that we must not work on too many things in
parallel; if we do, there is a danger that the community is not able to give
sufficient concentration to the process improvement effort.
In that light, I've gotten the feeling that either:
a) we must get to a resolution on SRD/ISD Very Soon Now (so that we can move
on to focus on other things), or
b) it might be best to abandon (or put on a back burner) the SRD/ISD
approaches, because AFAICS, in the grand scheme of things, I don't think they
actually provide significant improvement on timeliness or quality.
(But rather, the approaches "just" improve the external representation of our
work and make us more compliant with RFC2026. Maybe the decision to charter the
WG was a bad one, years ago, or maybe it was an attempt to collect "low-hanging
fruit" without realizing that we didn't know where the fruit was and low or
high it was.)
It seems that we should be better focusing on the more pressing problems (which
are out of scope of this WG):
- improving the IESG management/leadership capabilities to better lead,
steer, help, review, etc. [Harald's twolevel, John's standard review
panel, etc. proposals]
- improving the document workflow (up to 'Publication Requested').
I doubt this requires process changes, rather than cultural changes or
tools improvements. However, I doubt this could get proper attention
prior to the IESG's load on the day-to-day techincal job is decreased.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf