An overview of where the IETF change process is currently at

[Elwyn Davies]

I think Spencer has the correct story.

To my mind, we really don't want preeconceived ideas in the form of an
'official I* position' in advance.
It will be helpful if the SAP has people who have some idea what will be
acceptable to the I* and who will indeed add the 'insiders' view to the pot.
It will also help if the I* believes that anything that comes out has been
handled by somebody who 'seem reasonable'.  It also doesn't stop the I*
discussing solutions in parallel.

Regards,
Elwyn

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer at mcsr-labs.org] 
> Sent: 01 October 2003 17:20
> To: problem-statement at alvestrand.no
> Subject: Re: An overview of where the IETF change process is 
> currently at
> 
> 
> Dear James,
> 
> I hear what you're saying here.
> 
> I'm not one of the proposal authors, but I was at the sushi bar when
> they put the proposal together. So, speaking only for myself...
> 
> I think the message in the proposal under discussion is "we're looking
> for help from 'inside', and reserving seats to try to make that
> possible".
> 
> Avri/Elwyn/Jeanette - am I misspeaking here? Are we looking for an
> "official I* position", going in, or just some I* participants who
> seem (to the I*) reasonable?
> 
> Spencer
> 
> ----- Original Message ----- 
> From: "James Kempf" <kempf at docomolabs-usa.com>
> To: "Elwyn Davies" <elwynd at nortelnetworks.com>; "Avri Doria"
> <avri at acm.org>; <problem-statement at alvestrand.no>
> Sent: Wednesday, October 01, 2003 10:48 AM
> 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.
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/problem-statement/attachments/20031001/11f4f352/attachment-0001.htm