Subject: Moving the process document forward

From: Melinda Shore <[email-masked]>
Date: Tue, 2 Sep 2003 12:09:08 -0400

Unfortunately, we left Vienna in probably greater confusion about
how to move forward than we were before we arrived.  We need to
spend some more time discussing what we want to say about changing
the structure and practices of the IETF.  There have been several
proposals to date but none has been attracted anything resembling
consensus.  The soon-to-be-posted revision of the process document
says this:

5.2 Changing the Structure and Practices of the IETF, contains the 
following appeal:
    Given the lack of concensus, this document asks the IETF community 
to submit
    and discuss further alternative process (and solution) proposals that
    might attract better concensus.

and so we're soliciting contributions.

Melinda & Avri

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 02 Sep 2003 13:33:51 -0700

Melinda,

slightly confused:
are you asking for input on how we should structure the process for 
achieving at a set of changes, or on what the changes should be?

These issues are related, but not the same....

                Harald

--On 2. september 2003 12:09 -0400 Melinda Shore <[email-masked]> wrote:

> following appeal:     Given the lack of concensus, this document asks the
> IETF community to submit     and discuss further alternative process (and
> solution) proposals that     might attract better concensus.
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 2 Sep 2003 16:43:39 -0400

On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand 
> achieving at a set of changes, or on what the changes should be?

The latter is, strictly speaking, out of scope.  But
we do need input on the question of how to tackle the
restructuring (if it's agreed that it's necessary) question,
whether it's details on how to construct a blue-ribbon panel
or to recommend kicking the whole thing over to the IESG.

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Sep 2003 14:01:06 -0700

Melinda,

MS> we do need input on the question of how to tackle the
MS> restructuring (if it's agreed that it's necessary) question,
MS> whether it's details on how to construct a blue-ribbon panel
MS> or to recommend kicking the whole thing over to the IESG.

The situation is a bit worse than that.

Other than general references to "restructuring" we do not have anything
concretely specifying what that means, nevermind whether we have
consensus to pursue it.

We could probably get community consensus that the world needs peace.
But the consensus would have little practical use, in terms of
predicting that community's embracing of any particular peace proposal,
or even of giving guidance for how to pursue peace.

When people explain what they mean by the term restructuring, in terms
that have some concrete relationship to the operation of the IETF and
some understanding of the intended, concrete outcomes, *then* it might
be worth considering how to pursue it.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 02 Sep 2003 14:52:07 -0700

I think the WG has the following chartered work item:

> As a second work item, the group will also produce a proposal for a
> process to develop solutions to the problems identified by this working
> group.

Since we know what the problems are (modulo objections to -issue-03, which 
I haven't seen much of), there should be at least some possibility of 
suggesting the required process for fixing them.

This may come in the form of (problem, suggested solution, 
how-to-get-there) descriptions, or it may come in the form of (problem, 
needed investigation, range of solutions) descriptions; I personally don't 
think all of our problems will be solved by a single fell-swoop solution - 
different problems may require different approaches, so there are probably 
multiple things that can be suggested, refined and adopted - but I think 
the proposals need to be anchored into "what problem are we trying to 
solve".

(Yes, I AM working on delivering what I think the IESG was charged with in 
Vienna - proposing at least some process to deal with at least some of the 
problems. It's not ready for publication yet.)

                                Harald

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Sep 2003 17:16:08 -0500

Dear Dave,

I have been confused before, but had assumed that "restructuring"
meant at least "fixing 2.6.2 in the current problem statement draft".

If it means more than this, that's fine. But I happen to believe that
2.6.2 is a real problem, and that structural changes are likely
required
to fix them.

("Workload of the IESG", if the draft isn't open in a window on your
desktop/palmtop/laptop/etc.)

Spencer

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Wed, 03 Sep 2003 00:39:11 +0200

> concretely specifying what that means, nevermind whether we have

In the problem resolution process draft we differentiate between near-term 
improvements and longer-term efforts aiming to adress structures of the 
IETF.  

In the structural problems improvement process draft we suggest a list of 
issues, which are discussed in more detail in Elwyn's problem issue draft:

o  The Mission Problem (Section 4.1),

      o  the Complex Problems problem (Section 4.3),

      o  the Standards Hierarchy problem (Section 4.4),

      o  the Management Scaling problem (Section 4.6), and

      o  The longer-term portions of the Engagement Problem (Section 4.5)

This list is not meant to be exhaustive. It is just the result of the discussion on 
this list. 

 jeanette

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Sep 2003 15:57:20 +0200

Reading draft-ietf-problem-process-02.txt and 
draft-davies-structural-rev-process-00.txt, I'm concerned that we
are falling into our own trap (i.e. over-engineering).

To me things are not so complicated. We have a list of problems
ready to publish. We have a measure of agreement that the current
leaders (IESG + IAB) ultimately have to show leadership in
implementing change to solve those problems, without fixing what
isn't broken. So we should basically send the list of problems to the
IESG and tell them to set up design teams to fix them. The
decomposition in draft-ietf-problem-process-02.txt is certainly
useful because it suggests a structure of design teams,
but I think this WG would be best advised to stop there.

   Brian

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Thu, 04 Sep 2003 23:59:37 +0200

On 4 Sep 2003 at 15:57, Brian E Carpenter wrote:

> IESG and tell them to set up design teams to fix them.

Your proposal touches upon several of the problems documented in the 
problem issue draft. To list the obvious ones: 

2.6.1 Span of authority: Overt authority in the IETF is concentrated in the 
small number of people sitting on the IESG...

2.6.2 Workload of the IESG: With the current structure of the IETF and IESG, 
it is clear that the workload imposed on each of the Area Directors (ADs) is 
well beyond the capabilities....

2.6.6 Concentration of Influence in Too Few Hands: ... the IETF appeared to 
have created an affinity group system which tended to re-select the same 
leaders from a limited pool of people...

2.6.7 Excessive Reliance on Personal Relationships: ...the IETF is built on a 
particular kind of one-to-one personal trust relationships. This is a  very 
powerful model but it does not scale well...

I wonder what we gain if we set up a resolution process which basically 
repeats or even exacerbates the problems the process is meant to solve.

jeanette

 The

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Sep 2003 14:01:04 +0200

in line...

Jeanette Hofmann wrote:
> problem issue draft. 

You're missing my point. The only authority that exists *today* is
today's leadership. Nobody else but them can change things. So it simply
*doesn't matter* that today's leadership is perceived by some people
as part of the problem. There is nobody else who actually can initiate change. 

> To list the obvious ones:
> 

That is very unfair to the current IESG and IAB and the attitude many
of them, and the IETF Chair, have taken to the work here. We are obviously
going to set up one or more design teams (whatever name you choose, it's
the same thing) and we can do it the easy way (have the IESG do it) or
erect a new, complicated, ad hoc mechanism to produce the same result more 
slowly.

I want to see these design teams next week, not next year!

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Sep 2003 09:25:08 -0500

Dear Brian,

I hope (or at least "think") we are tripping over a word or two.

> as part of the problem. There is nobody else who actually can
initiate change.

I was relatively with you down to the last two words. Do you mean

- initiate a proposal for change, or

- initiate change based on a proposal?

I think Jeanette is talking about the process for initiating a
proposal for change.

[deleted down to]

> I want to see these design teams next week, not next year!

That would be lovely...

Spencer

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Fri, 05 Sep 2003 16:40:23 +0200

On 5 Sep 2003 at 14:01, Brian E Carpenter wrote:

> You're missing my point.

Thank you. 

 The only authority that exists *today* is
> today's leadership. 

I didn't deny that. Neither does draft-davies-structural-rev-process-00.txt. 
According to our model, IESG and IAB nominate people for the SAP panel, 
the IESG would keep an oversight role and make final decisions. 

Nobody else but them can change things. So it simply
> of them, and the IETF Chair, have taken to the work here.

I was talking about structural problems not about individual people. I was 
merely quoting from a list of problems generated on this very list to explain 
why I don't share your view on what constitutes an easy and quick path 
forward. 

Jeanette 
 
 We are obviously

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Sep 2003 11:07:44 -0400

> problem issue draft. To list the obvious ones: 

Since there are problems with every part of the IETF organization 
(they're certainly not entirely in IESG and IAB) it is impossible to
have the problems addressed by a part of the organization that doesn't
have problems.

IESG and IAB are in the best position to set up design teams to make
suggestions as to how to solve these problems.   Since design teams have
no official status, other people can also form design teams (or act
as individuals) and write internet-drafts about how to solve these
problems if they want to do so; indeed, some suggestions have already
been presented in that form.

But the alternative to having IESG and IAB set up design teams is to
wait for other people to take the initiative, and this seems unlikely to
produce good results in a timely fashion.

No matter who makes the suggestions, any changes to the existing BCPs
that dictate how we do our work still have to be vetted through the IETF
consensus process.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Sep 2003 17:49:53 +0200

> I think Jeanette is talking about the process for initiating a

I think so to. And I'm pessimistic about that happening quickly
except by decisive IESG action. Sorry, but this WG suffers from
the same problems that it has identified.

   Brian

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

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

---

From: Avri Doria <[email-masked]>
Date: Sat, 6 Sep 2003 07:38:59 +0900

On lördag, sep 6, 2003, at 00:49 Asia/Seoul, Brian E Carpenter wrote:
> except by decisive IESG action.

speaking personally:

And if that happens, then perhaps a proposal from this group does 
become superfluous.  but until such time as they do, it is the WG role 
to try and suggest a process to them.

And draft-davies-structural-rev-process-02 itself says, this group can 
decide that it doesn't want to suggest any process other then asking 
the IESG to please fix things.  and if that turns out to be the rough 
consensus then fine it gets documented and we are done.

My concern is that if we wait for speedy decisive action and that 
action doesn't come then a year can pass with us being no further along 
then we are now.  the only alternative most of us have since we cannot 
affect the IESG in any direct manner is to continue working within the 
context of this WG within the context of its charter.

As i see the SAP proposal in draft-davies-structural-rev-process-00 it 
is a way to create a 'design team', making sure that it gets and 
considers opinions from all involved.

a.

---

From: Avri Doria <[email-masked]>
Date: Sat, 6 Sep 2003 09:51:38 +0900

I got one of the draft names wrong in this email.
Correction below.

a.

On lördag, sep 6, 2003, at 07:38 Asia/Seoul, Avri Doria wrote:

> decide that it

should be draft-ietf-problem-process-02.txt

> doesn't want to suggest any process other then asking the IESG to 
> please fix things.  and if that turns out to be the rough consensus 
> then fine it gets documented and we are done.
>
> action doesn't come then a year can pass with us being no further 
> along then we are now.  the only alternative most of us have since we 
> cannot affect the IESG in any direct manner is to continue working 
> within the context of this WG within the context of its charter.
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 6 Sep 2003 10:14:34 -0400

> then we are now.  

if this WG tries to get consensus on the way forward, it will take even
longer.

Keith

---

From: Avri Doria <[email-masked]>
Date: Sat, 6 Sep 2003 23:53:45 +0900

On lördag, sep 6, 2003, at 23:14 Asia/Seoul, Keith Moore wrote:

>> along
I don't see why that is necessarily so.  If people were to start 
talking about a process and to start making comments on what is wrong 
with the SAP idea or to start making other process suggestions we might 
get somewhere.

If, on the other hand, all we can talk about is why it would take a 
long time to get a process to consensus, then we may create a self 
fulfilling prophecy.

As it currently stands this group is close to being on its schedule, 
and I believe that if we focused on a process for moving forward we 
would get one with consensus.

Personally, I am into trying to find the process that can work and can 
represent the various interests of IETF participants.  It doesn't have 
to be a perfect process, just one that work work and one that would not 
leave the community out.  While I can't state for certain that the IESG 
couldn't do it, I personally think it would be very difficult for them 
to take in the breadth of opinion and synthesis it into something that 
will satisfy the community and get the job done. All this while doing 
their normal IESG work.

 From watching the solutions group, it is obvious there are folks with 
ideas and I am sure there are many that haven't been aired yet.  Now we 
need a way to find out which ideas are the ones that will serve to fix 
the problems that need fixing.  How do we take the many ideas people 
have for ways to fix things and come up with some practical workable 
solutions.  What we need is a process that will take the richness we 
have in the IETF community and bring it together into a workable 
solution.

a.

---

From: Keith Moore <[email-masked]>
Date: Sat, 6 Sep 2003 16:50:59 -0400

> >> along then we are now.
> I don't see why that is necessarily so. 

in general, it's harder to get agreeement among a large number of people with
widely varying levels of experience (in this case, that means experience leading
IETF or a very similar activity) than it is to get agreement among a smaller
number of people all of whom have some direct experience.  this is especially 
true when the consequences of being wrong are severe.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 7 Sep 2003 21:51:24 -0700

Brian,

BEC> You're missing my point. The only authority that exists *today* is
BEC> today's leadership. Nobody else but them can change things. So it simply
BEC> *doesn't matter* that today's leadership is perceived by some people
BEC> as part of the problem. There is nobody else who actually can initiate change.

I think you have correctly summarized a common point of view in the community.

What it misses is that the IESG is not really tasked with "initiating" very
much and, in fact, has very little history "initiating" much.

By design and by long practise, this is a community of self-starters. The job
of the IESG is to shepherd *community* initiatives.

i.e.,

     community  =  individuals from the community  =  us.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 7 Sep 2003 21:48:47 -0700

>> concretely specifying what that means, nevermind whether we have

HTA> I think the WG has the following chartered work item:

I'm confused by your response, since none of it seems to pertain to my note.

Let's be clear:

1. I did not say that anyone or thing in the Problem working group has been
done badly or outside of scope

2. The charter text you quote says nothing about "restructuring" being
required"

3. Neither the problems draft nor solutions draft says nothing about
restructuring being required.

So let me state my point again:

Some folks are tossing around the term "restructuring" as if a) it is accepted
that that will happen, and b) that there is some general understanding of what
the term means.

I claim that neither is true.

However the term tends to imply potentially massive change.  Yet there is
certainly no basis for claiming that we have community consensus in favor of
massive change.

If my assessment is incorrect, I would really appreciate hearing how.

SD> I have been confused before, but had assumed that "restructuring"
SD> meant at least "fixing 2.6.2 in the current problem statement draft".

I could make a guess about what the term means, too.  It might or might not be
the same as your guess.

My point is that the term "restructuring" is too serious and implies too much
change for us to be guessing.

JH> In the structural problems improvement process draft we suggest a list of
JH> issues, which are discussed in more detail in Elwyn's problem issue draft:

My original -- and continuing -- point is that "improvement" to a structure
does not necessarily mean "restructuring".

Too much is being taken for granted or is being said without enough precision.

d/

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 Sep 2003 23:15:53 -0400

--On Saturday, September 06, 2003 07:38 +0900 Avri Doria
<[email-masked]> wrote:

> My concern is that if we wait for speedy decisive action and
> that action doesn't come then a year can pass with us being no
> further along then we are now.  the only alternative most of
> us have since we cannot affect the IESG in any direct manner
> is to continue working within the context of this WG within
> the context of its charter.
> 
> As i see the SAP proposal in
> draft-davies-structural-rev-process-00 it is a way to create a
> 'design team', making sure that it gets and considers opinions
> from all involved.

But, unless I misunderstand parts of that document --which is
possible, of course, it isn't going anywhere unless the IESG
takes action, if only to start appointing people.  That brings
us back to Brian's position, and the questions I raised during
the Vienna plenary: either the IESG has to take responsibility
for moving things forward from this point, or we are stuck.
Now, "the IESG takes responsibility" could involve their
deciding to create some SAP action, or their deciding to create
some other design team mechanism, or their deciding to create
some follow-on WG(s) (my least favorite option), or their
deciding to actually do or propose something decisive (for
community review and/or as an experiment).  But, any way you
look at it, I think there are only three possibilities:

	* We continue to discuss issues and possible solutions
	for a very long time, probably until the proverbial hot
	place freezes over.
	
	* The IESG takes _some_ action.
	
	* We conclude that the IESG is sufficiently uninterested
	in effective change that the appropriate Minneapolis
	plenary action is to insist that all of them resign,
	effective as soon as the Nomcom can come up with
	replacements who are more receptive to change and
	evolution. 

Fortunately, my sense is that the odds that the latter is
necessary are very, very, low.  And that makes the second choice
the best one, I think clearly so.

    john

---

From: Avri Doria <[email-masked]>
Date: Mon, 8 Sep 2003 17:04:27 +0900

Hi John,

You are right at the end of the day, the IESG has to take some action 
(leaving open the possible view that to take no action is to take 
action)

I think there are two paths:

- they can figure it out a process on their own.
or
- the Problem WG can come up with a suggestion it reaches consensus on 
and after being reviewed by the IETF in LC it is sent to the IESG.

In the first case they can do anything they wish.  The community 
doesn't really get much of a say other then in the context of Nomcom.  
In the second case, one can hope they would go with the consensus 
reached by the WG etc.  I.e. the community does get to voice an opinion.

The IESG gave the community an opportunity to voice its opinion on the 
process to be taken; i.e. it created this WG with its charter.  If this 
WG  doesn't come up with one, I think it is tantamount to inviting the 
IESG to do as they please.

If this group can come to closure on a process (not the solutions to 
the issues, that is not our task) in short time, we can send that on.  
If we can't, we fail in meeting our charter and await  their pleasure.

a.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Sep 2003 11:29:43 +0200

>      community  =  individuals from the community  =  us.

Yes, but I think we have done that bit. Turning it into actual
actions is the next hurdle. That's where I have trouble seeing
any stuckee except the IESG.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 8 Sep 2003 07:53:07 -0400

> and after being reviewed by the IETF in LC it is sent to the IESG.

let's just say I hope they do the former, because if we wait for this WG to do
the latter then it will delay any useful change by probably a year.  IMHO.

of course, if the IESG waits for this WG to get consensus on whether it should
act now or later, it will take even longer.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Sep 2003 07:34:58 -0500

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
> change for us to be guessing.

OK, point taken (on the second time round). When I say "restructure",
I mean

o       offload some portion of the IESG review workload,
            per Problem Statement 2.6.2, with the smallest process
            and structural changes required to achieve this goal

Who means something else when they say "restructure"?

If we really mean "offload IESG review workload", saying so
would be an improvement.

> Too much is being taken for granted or is being said without enough
precision.

I agree, and hope we can agree on more precision..

Spencer

---

From: Melinda Shore <[email-masked]>
Date: Mon, 8 Sep 2003 15:49:50 -0400

> act now or later, it will take even longer.

Right now, there's no consensus anywhere on how to go about
tackling longer-term change.  There was no consensus within
the plenary in Vienna, it seemed clear to me at the time,
and right now there's no consensus within this working group
about how to proceed.

We have two proposals in front of us at the moment: 1) kick the
whole thing over to the IESG, and 2) form something that looks
like a design team using the mechanism described in the current
draft of the process document.  There have been some posts
objecting to the second proposal and I'd like to get a handle
on whether or not there's any support for it at all right now.

Melinda