An overview of where the IETF change process is currently at

[Elwyn Davies]

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