An overview of where the IETF change process is currently at
Avri Doria
avri at acm.org
Wed Oct 1 16:16:28 CEST 2003
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.
More information about the Problem-statement
mailing list