Subject: Clarification of my comment on giving up on process issues

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Mar 2006 13:43:27 -0500

Hi.

I gave a presentation at genarea today and commented that I strongly
felt like giving up on any participation in process change efforts as
a lost cause.

I want to explain what is frustrating me and to explain what is not frustrating me.

Several people said that I need to get more review of my draft.
That's reasonable and I'll work on that.  I admit significant
frustration that concerns about lack of review were not raised during
last call.  However that's par for the course; last call comments
including recommendations for more review come in up to the point that
a document is approved and we're all used to that.

Also, if people believed that the basic approach I'm
taking--delegating power to the IESG--was wrong, that would be fine.
People disagree with each other all the time.

What I am frustrated by is that it looks like we're headed for the
same sort of deadlock that we've had with all the process proposals.

I suspect that I can get my draft published and that it will not be
too difficult to do so.

However I don't think we're building the sort of community consensus
behind RFC 3933 as an approach to breaking process reform deadlock
that it will actually be useful to us.  What happens when John submits
his nomcom proposal as an RFC 3933 experiment?  Would there be any
plausable way he  could move forward on that proposal using RFC 3933?  

If the answer is that RFC 3933 is not the solution, then what is?  We
did not have consensus behind pesci at IETF 64.We've not had consensus
behind what process priorities were appropriate in other cases.

So, I'm close to concluding that we don't have mechanisms for getting
consensus on larger process changes and that perhaps the right
approach is to just move on with our existing processes.  They mostly
work after all.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Mar 2006 13:05:17 -0500

--On Wednesday, 22 March, 2006 13:43 -0500 Sam Hartman
<[email-masked]> wrote:

>...
> However I don't think we're building the sort of community
> consensus behind RFC 3933 as an approach to breaking process
> reform deadlock that it will actually be useful to us.  What
> happens when John submits his nomcom proposal as an RFC 3933
> experiment?  Would there be any plausable way he  could move
> forward on that proposal using RFC 3933?  

Not that I can find, which, if you are referring to the Nomcom
proposal I think you are, is why I haven't done it. For those
who don't remember, it suggested using a different model for
first-time appointments to the IESG or IAB than for renewals and
building an assumption into the renewal model that two terms
were normally good but that more than that probably indicated a
problem in progress or likely to occur down the line --
draft-klensin-nomcom-term-00.txt (expired) for the curious.    

draft-klensin-recall-rev-00.txt is another example of the same
thing.  There have been an informal in-the-hall discussion or
two, but no focused discussion that could be used to move the
proposal forward.  Unlike the nomcom one, it could presumably be
implemented as a process experiment although, extrapolating from
the number of recall efforts we've had, the experiment would
need to run a rather long time.  But, especially without clear
community support, the IESG would need to be mildly crazy to
adopt it as a process experiment -- it would just seem too
self-serving.

But, more generally, what those types of proposal need,
independent of the process-change model we use, is enough
community discussion to permit making a determination that
people care and that there is sufficient consensus to move
forward.

What concerns me most of all these days is that, if one can get
a process proposal onto the agenda of some WG, or can introduce
it via a meeting convened by some senior member of "the
Leadership", then it draws a handful of process-weenies and
generates comments (perhaps many comments) _from them_.  The
broader community shows little signs of caring, which leaves us
with three alternatives:

	(i) Do nothing, on the ground that, if enough people
	don't care, nothing is severely enough broken.
	
	(ii) Go ahead and made the change, partially on the
	theory that, if it turns out to be significantly worse,
	_that_ will bring the community out to comment.
	
	(iii) Continue thrashing.  Thrashing differs from (i) in
	that (i) doesn't use up community cycles and raise the
	frustration level.  Thrashing does both.

In that light, 3933 was intended to make (ii) less painful and
risky.  But it is not useful for changes we don't know how to
back out.  And, even for those we can back out, the question of
whether we should try an experiment to fix a problem that almost
no one seems to care about is a challenging one.

>...
> So, I'm close to concluding that we don't have mechanisms for
> getting consensus on larger process changes and that perhaps
> the right approach is to just move on with our existing
> processes.  They mostly work after all.

This, of course, is a variation on (i) above.  It is certainly
more efficient than (iii) and, if we can't even move forward
smoothly with 3933 experiments where there seems to be some
interest, may be better than (ii).    But it is, IMO, a fairly
sad state of affairs.

> My argument is that proliferation of competing process change
> proposals may well be an appropriate mechanism for RFC 3933
> experiments--even when these are significant process
> experiments.  I think recruiting the stakeholders will provide
> enough of a gate.
> 
> But this is only true if the community buys into the approach .

Agree completely.

     john