An overview of where the IETF change process is currently at

[Spencer Dawkins]

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.
> > >
> > >
> > >
> >
> >
>