An overview of where the IETF change process is currently at
James Kempf
kempf at docomolabs-usa.com
Wed Oct 1 09:18:01 CEST 2003
Avri,
You've fairly clearly articulated how you want to see community participants
chosen, but you've suggested nothing about how I* participants might be
chosen. Pursuing the analogy with NomCom, do you feel that the I*
participants should be chosen and should view their roles as similar to the
I* NomCom representatives? Or do you feel that they should be more active
participants?
jak
----- Original Message -----
From: "Avri Doria" <avri at acm.org>
To: <problem-statement at alvestrand.no>
Sent: Tuesday, September 30, 2003 11:16 PM
Subject: Re: An overview of where the IETF change process is currently at
>
> 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