Subject: Process change review and approval by fresh eyes

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Aug 2005 09:53:20 +0300 (EEST)

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 <[email-masked]>
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf