An overview of where the IETF change process is currently at

[Avri Doria]

On måndag, sep 29, 2003, at 00:46 Asia/Seoul, Melinda Shore wrote:

> Avri and I need to talk some more
> about how to break the logjam but one thing that concerns me a
> great deal is how we're going to be able to come to consensus
> when there's strong opposition to pretty much every option that's
> been put forward.  One thing we have discussed is that it may
> be useful to identify the characteristics that the process itself
> needs to have.

As one of the proponents of one of the process proposals, I figured I 
should take a first attempt at giving the reasoning I used while 
participating in the creation of that proposal.  Some of the discussion 
about that proposal have concerned it being over-engineered.  While I 
cannot argue against that impression specifically, I do think that the 
details of that proposal came from a concept of what was required in 
such a process.  I believe one deficiency in that proposal is that we 
did not include an analysis of the requirements for the process.

Note: this note is purely personal opinion and _not_ a WG co-chair 
opinion.  It also does not necessarily reflect the opinions of my two 
co-authors who may have had different motivations.  The proposal was a 
compromise of our different points of view.   This is mine.

- transparency: (rapidly becoming an overused term) I think that any 
process to respond to the issues in the problem statement especially in 
the response could result in recommendations for structural change 
should be done in a way that allows for intense community scrutiny.

- public participation: I think that the community should not only be 
allowed to watch the process, but should have the maximum possible 
ability to contribute to that process.

- public accountability:   Those who presume to take the communities 
opinions and mold them into a proposal should be accountable to that 
community.  The IETF should know who is making recommendations and who 
is making decsions.  And the future roles of those individuals within 
the IETF should take the way they perform these tasks into account.

- rapid movement toward resolution:  I think that many in the IETF 
community are running out of patience.  Now that the problem 
description is nearly complete, resolution should be rapid.  This does 
not mean it should be rushed, but there should be a reasonable schedule 
that is adhered to strictly.

- significant and balanced representation for those who currently have 
the I* responsibility:  I think it is important that those people who 
have been chosen as the IETF's governing team should have a voice in 
any recommendation.  Not only does the IESG, and possibly the ISOC, 
need to approve the decisions,  the IESG and the IAB would be 
responsible for carrying out any of the recommended changes that were 
approved.  Further, I think it would a serious problem if the I* was 
caught by surprise by any of the recommendations.

- majority representation for the community at large:  I think it is 
critical that the community at large have serious representation in the 
process of making the recommendation.  Thus I think that non officials 
of the IETF community should be the majority of the group.

- a fair selection procedure for choosing those from the community at 
large needs to be chosen

- non prejudicial method for choosing a chair: given the number of 
different interests involved in making the recommendation, it seemed 
reasonable that the participants in the process itself pick the person 
they wanted to coordinate the functioning of the team.  and if they are 
not happy with that chair, they should be able to reassign it.

- use of processes already understood:  Instead of inventing new ways 
of doing things, I felt that it would be best to borrow from techniques 
already in use in the IETF.  Therefore the proposal uses variants of 
familiar methods, albeit it different combinations:
-- the entire team makes a recommendation to the ADs similar to the way 
directorates do
-- the chair is chosen in the same way as the chair of the IAB
-- the community representatives are chosen in a method similar to the 
nomcom process.
-- recommendations come in from the community and are distilled by a 
smaller group similar to the way a design team functions.  These 
recommendations are reviewed by the IETF community at large before 
being sent on to the IESG.  Again similar to a working group, although 
a very large one.

- The final decision belongs to the IESG as the appointed 
representatives of the community at large.

The proposal was made in the spirit of trying to move the WG chartered 
work along to completion.  My assumption was that the quickest way to 
resolve the issue was to have a proposal that could be discussed and 
modified.  And while it is true that the IESG is empowered to decide on 
a process before this group reaches consensus, I felt that there was a 
possibility that they might not (for any number of possible reasons), 
or that if they did they might use some variant of this proposal or of 
other proposals that might be discussed in the WG.

I hope that a discussion of how people think the process should be run 
can help us move away from the deadlock we are currently experiencing.

thanks
a.