An overview of where the IETF change process is currently at

James Kempf kempf at docomolabs-usa.com
Wed Oct 1 10:18:45 CEST 2003


Elwyn,

The problem is that any I* participants won't be "representatives" in the
sense that I think you mean, that is, I don't think they will be empowered
by their colleagues to represent a joint I* opinion unless that opinion has
been discussed and concensus has been achieved. The I* just doesn't work
that way currently, it works like the rest of the IETF, where things are
discussed until concensus has been reached. Now, it's possible that the I*
could empower individuals to represent an I* opinion without that kind of
concensus discussion, but it would be a change from current practice.

I think a more realistic expectation, given current practice, would be that
the I* representatives would, in fact, work more like the NomCom liasons,
if, of course, the resolution process follows the path described in the
email Avri sent.

            jak




----- Original Message ----- 
From: "Elwyn Davies" <elwynd at nortelnetworks.com>
To: "'James Kempf'" <kempf at docomolabs-usa.com>; "Avri Doria" <avri at acm.org>;
<problem-statement at alvestrand.no>
Sent: Wednesday, October 01, 2003 9:09 AM
Subject: RE: An overview of where the IETF change process is currently at


> I think the important thing is for the whole I* to feel involved in the
> process without dominating it.
> One would expect any I* participants to have an I* perspective on the
> matters under consideration and to bring with them a feeling of the
attitude
> of the other members to what is going on.  Clearly mandating a particular
> attitude is contrary to normal IETF practice and would probably not go
down
> well with the normal free thinking attitude of most IETF members. However,
> the I* do endeavour to adhere to certain general principles and might
expect
> their representatives to uphold these views unless really good arguments
> were advanced to change them (as happens in technical matters today), if
> only because the IESG in particular has got to implement the results and
> getting an outright rejection of a proposed solution would probably
provoke
> a major crisis in the IETF.
>
> regards,
> Elwyn
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf at docomolabs-usa.com]
> > Sent: 01 October 2003 16:49
> > To: Davies, Elwyn [HAL02:0S00:EXCH]; Avri Doria;
> > problem-statement at alvestrand.no
> > Subject: Re: An overview of where the IETF change process is
> > currently at
> >
> >
> > Typically, the IAB doesn't make an official "IAB" statement
> > unless there is
> > concensus among its members, and I assume the IESG does the
> > same. So any
> > representatives from the IAB to the group would not be
> > empowered to speak
> > for the entire IAB. They would, as for any IETF participant,
> > be speaking as
> > individuals when giving an opinion in real time.
> >
> > Given that, I'm not sure how active an I* presence you are
> > likely to get in
> > the process unless all of the I* are involved, which just
> > isn't practical. I
> > think a more practical scenario is to view any I*
> > participants as somewhat
> > more active than the NomCom liasons, but not representing any
> > I* opinion in
> > real time. That is, they would have to go back to their
> > respective I* and
> > discuss any matter that might come up where an I* opinion
> > might be desirable
> > or necessary, then bring it back to the group. What I am
> > trying to say is
> > that any I* participant would not be empowered to represent
> > the I* as a
> > whole, at least, if the I* continue with present practice.
> > Present practice
> > could, of course, be changed, but requiring concensus is a very strong
> > custom and I think it would be difficult to change (in addition to any
> > changes having their own downsides).
> >
> > I hope any other I* (especially IESG) will speak up if they
> > feel I've missed
> > something here.
> >
> >             jak
> >
> > ----- Original Message ----- 
> > From: "Elwyn Davies" <elwynd at nortelnetworks.com>
> > To: "'James Kempf'" <kempf at docomolabs-usa.com>; "Avri Doria"
> > <avri at acm.org>;
> > <problem-statement at alvestrand.no>
> > Sent: Wednesday, October 01, 2003 8:30 AM
> > Subject: RE: An overview of where the IETF change process is
> > currently at
> >
> >
> > 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.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>



More information about the Problem-statement mailing list