Subject: RE: An overview of where the IETF change process is currently at

From: "Elwyn Davies" <[email-masked]>
Date: Wed, 1 Oct 2003 21:53:53 +0100

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:[email-masked]] 
> Sent: 01 October 2003 17:20
> To: [email-masked]
> 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" <[email-masked]>
> To: "Elwyn Davies" <[email-masked]>; "Avri Doria"
> <[email-masked]>; <[email-masked]>
> 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" <[email-masked]>
> > To: "'James Kempf'" <[email-masked]>; "Avri Doria"
> <[email-masked]>;
> > <[email-masked]>
> > 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:[email-masked]]
> > > Sent: 01 October 2003 16:18
> > > To: Avri Doria; [email-masked]
> > > 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" <[email-masked]>
> > > To: <[email-masked]>
> > > 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.
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 06 Oct 2003 16:44:45 -0700

Hello folks,

I have some comments on the draft.  I'll break it down into
three different e-mail messages, because otherwise I am
afraid that many points might be lost.

I believe that the document structure causes the
document to lose effectiveness.  It can be improved by
some pretty basic reorganization:

- The "Changes" sections should be moved into an
   appendix (or multiple appendices)

- The "Acknowledgement" section (currently 1.4) should
   be moved to be the last section before the normative
   references.

- In Section (2), the first part of the section should
   itemize the list of root causes, e.g.:
   = Unclear Mission
   = Poor Use of Effective Engineering Practice
   = Standards Process Abuse
   = Workload exceeds available staffing levels
   = Unsuitable Management Structure
   = Poor WG dynamics
   = Inadequate Staff Preparation

This text should be placed before section 2.1.

I know that the IETF participants are "Staff", because
I have two IETF t-shirts that say so.  Also I would
strongly encourage _short_ formulations for the "root
causes", because long rambling formulations just don't
get the point across anywhere near as well.

A statement is made that the "Unclear Mission" root
cause is the "fundamental" cause.  I don't believe it.
I think it's much more a case of arbitrary procedures
applied selectively according to circumstance and
personal preference.  When I discuss with people at
the IETF, I may often hear a point of view that I don't
agree with.  But I rarely would characterize it as not
having a clue about mission.  Without formulating a
proposed "mission statement" to try to prove my
point, I would at least like to strongly suggest that the
characterization in section 2., preceding section 2.1,
is wrong.  If I had to pick out a more fundamental
root cause, it would be "Unsuitable Management
Structure", at least from the current formulation for
the set of root causes.

Thus, I would suggest demoting section 2.2 to be placed
_much_ later in section 2.

More in another e-mail coming shortly.

Regards,
Charlie P.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 07 Oct 2003 09:48:11 +0200

--On 6. oktober 2003 16:44 -0700 Charlie Perkins <[email-masked]> 
wrote:

> personal preference.

Charlie,

I don't believe that the document as currently written raises the "unclear 
mission" point above the other points, one of which is the "management" 
issue. It just happens to come first in the list.

I think there are two issues with percieved arbitrariness:

- If we allow ourselves to assume that leaders have been genuinely acting 
in bad faith, I think we will jeopardize our ability to correctly diagnose 
and correct the real problems we have.
- If we do not understand the processes that led to the decisions that are 
being labelled "arbitrary" being taken by competent people acting in good 
faith, we are doomed to repeat them.

                        Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Oct 2003 15:42:05 +0200

Charlie has spent a lot of time on this draft. But (and I suspect I am
repeating myself) I believe we are way beyond the point of diminishing
returns with this document. I believe, although I have my own quibbles,
that we should stop investing effort in polishing it. It is a document
of *no* long-term value; its value lies in triggering remedial action,
and that is where all our effort should now go.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Oct 2003 16:46:30 +0300

> This text should be placed before section 2.1.

Agreed. Note that we should probably publish this document
as soon as possible, and get to the next step (see the thread
about needless continuous refinement). But the above modifications are
very easy and they should be done to get the point across
better.

--Jari

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 07 Oct 2003 08:07:00 -0700

Hello Brian,

If there are situations listed that aren't solvable problems,
then the document shouldn't contain them because the
solutionists will be wasting their time.

If there are problems that aren't listed, then I should think
they need to be listed if they are serious, but as you point
out a decision has eventually to made about whether the
serious problems have all been identified.

The editorial suggestions are typically easy to incorporate.
I don't think my editorial suggestions, or even substantive
comments, would materially delay the progress of this
document.  At least, I don't expect to be making any attempt
to delay the document.  I wish that I had been able to make
these comments much earlier, but better late than never.
Or, what in the heck is the purpose of Last Call??!

Regards,
Charlie P.

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Tue, 07 Oct 2003 21:07:35 +0200

On 7 Oct 2003 at 15:42, Brian E Carpenter wrote:

> of *no* long-term value;

While I agree with you that polishing efforts don't increase the usefulness of 
the draft, I would hope that it does have some long-term value. After all it is 
the first document in many years that lists in a systematic way operational 
and structural problems of the IETF. As some have remarked during the 
process of putting this draft together, a relevant number of problems  was 
already known in 1992 around the Kobe events. The IETF has not much 
organizational memory, at least not in a written, systematic way. Likewise, the 
IETF's understanding of its own change seems rather anecdotical. In order to 
foster learning processes, drafts such as Elwyn's problem-issue statement 
should be ascribed a long-term value. 

I also don't mind a few repetitions and redundancies in the draft. They make 
the whole text more understandable for outsiders and newcomers, who might 
struggle with some of the problems discussed in the document. 

Jeanette 

 its value lies in triggering remedial action,