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