An overview of where the IETF change process is currently at
Elwyn Davies
elwynd at nortelnetworks.com
Wed Oct 1 17:30:18 CEST 2003
When the authors of the proposal thought about this, the idea was that the
I* members would be full and active participants in the process (rether than
observers as in NomCom), and that they were to be delegated by the I* from
amongst their number.
The relative sizes of the groups of participants was carefully chosen to
give full weight to the views of the I* members but without giving them a
dominant position, and without making the group too unwieldy (some people
think it is already too big). The document says nothing about whether the
I* would give any particular mandate to their representatives or allow them
free rein to exercise their best judgement.
Regards,
Elwyn
> -----Original Message-----
> From: James Kempf [mailto:kempf at docomolabs-usa.com]
> Sent: 01 October 2003 16:18
> To: Avri Doria; problem-statement at alvestrand.no
> Subject: Re: An overview of where the IETF change process is
> currently at
>
>
> 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.
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/problem-statement/attachments/20031001/db553581/attachment-0001.htm
More information about the Problem-statement
mailing list