Subject: Re: Straw process outline for dealing with structural and practic

From: Scott Bradner <[email-masked]>
Date: Fri, 18 Jul 2003 11:18:53 -0400 (EDT)

I think this proposal combines many of the suggestions from Harald's 
slide that did not get consensus - I do not think it is a good idea
to do anything so formal at this time 

lets solicit ideas (as IDs) over the next 60 (or 30) days then discuss
them for a fixed time (e.g. 30 days) and see where we are at that point

I fully expect that a consensus would have been reached on some
of the problem solutions - we could then focus on the others

I was one who answered Harald's 'do we have to do something in 3 years'
question with a 'yes' but I see no reason to try and reform a 17 year old
organization in a few months - unseemly haste at best - lets take the time
to do it correctly (that does not mean we should do nothing for the next
year)

Scott

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Fri, 18 Jul 2003 22:09:17 +0200

On 18 Jul 2003 at 11:18, Scott Bradner wrote:

> slide 

Really? I am not aware that anybody proposed such a model yesterday as 
described in Elwyn's mail. 

that did not get consensus - I do not think it is a good idea
> to do anything so formal at this time 

Our proposal emerged as a response to the problem working group meeting. 
While there was support for the issue document and the short term 
improvements of the process document, we seemed to get stuck in a dead 
end with regard to those problems that affect the IETF's structure. People 
clearly didn't like the idea to delegate those structural issues to a working 
group. Or so we thought. That is why we tried to develop a different model, 
which would be, perhaps, less cumbersome and also integrate more people 
than a wg. Equipped with clear deadlines, our model would lead to quicker 
results. Results that reflect only those issues, which attract contributions from 
the IETF. 
With this plan, we thought, we avoid frustration about the fact that not much 
has changed since Yokohama. 

Now, some people say they want to see some visible changes soon while 
others caution about moving too fast. Hmmm, is there a non frustrating path 
out of this? 

> them for a fixed time (e.g. 30 days) and see where we are at that point.

Actually, Scott, this is not entirely different from what our model proposes. Is 
it the Synthesis and Answer Panel, that you find too formal?

Jeanette

---

From: Scott Bradner <[email-masked]>
Date: Fri, 18 Jul 2003 16:37:12 -0400 (EDT)

>  Is it the Synthesis and Answer Panel, that you find too formal?

I find it premature

Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 18 Jul 2003 17:47:40 -0400

>described in Elwyn's mail.

My slides included:

Blue ribbon panel/design team?
  - Chosen in some representative fashion
  - Solicits proposals and input from the community
  - Develops a recommendation to reform our management model
  - Recommendation is reviewed and ratified by the community

Although this is nowhere near as detailed, it is similar.

>than a wg.

This makes sense as a follow-on from the Problem WG.  However, at
the plenary, people offered much stronger support for the idea
that the IESG should propose a solution to these problems than they
did for any of the other options...

>others caution about moving too fast. Hmmm, is there a non frustrating path

We have consensus to start the near-term efforts, and there is
also non-formal work underway (as Harald discussed in the
plenary) to fix some immediate issues.  So, maybe that will
satisfy folks who want action now?

>it the Synthesis and Answer Panel, that you find too formal?

I believe that Scott doesn't want to determine how we will
make a decision until we know what change options are on the
table.

Margaret

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2003 03:13:18 -0400

--On Friday, 18 July, 2003 17:47 -0400 Margaret Wasserman 
<[email-masked]> wrote:

>> Really? I am not aware that anybody proposed such a model
>> yesterday as described in Elwyn's mail.
>
> My slides included:
>

It is also a WG, or maybe a design team plus 
restricted-membership WG, by another name and with a slightly 
different organizational model.  See my earlier note.

>> Our proposal emerged as a response to the problem working
>> group meeting. While there was support for the issue document
>> and the short term improvements of the process document, we
>> seemed to get stuck in a dead end with regard to those
>> problems that affect the IETF's structure. People clearly
>> didn't like the idea to delegate those structural issues to a
>> working group. Or so we thought. That is why we tried to
>> develop a different model, which would be, perhaps, less
>> cumbersome and also integrate more people than a wg.
>
> This makes sense as a follow-on from the Problem WG.  However,
> at the plenary, people offered much stronger support for the
> idea that the IESG should propose a solution to these problems
> than they did for any of the other options...

I think it is interesting, and _very_ important, to try to 
understand why the impression of the sentiment of the Problem WG 
and the response from the Plenary were so different.  I hope it 
is possible to do that analysis without getting (again) trapped 
in the philosophical question of how much authority the plenary 
has. My hypothesis...

(1) Regardless of the _authority_ of the plenary, significantly 
more IETF participants were sitting there, raising hands, and 
generally expressing opinions than have been participating 
actively and observably in the Problem WG.  Unless there is 
evidence that the plenary was somehow "packed" --and I saw 
none-- we (and, more importantly, the AD and the IESG) are 
obligated to pay very careful attention to the size of that 
group and its opinions as probably more reflective of a broader 
IETF community than the WG reflects.

(2) A disconnect between a group of active, apparently-informed, 
IETF participants of that size and a WG about either problem 
analysis or solution approaches suggests that the WG is out of 
touch with the community.

(3) Given especially the behavior of this WG and its mailing 
list, the most likely explanation of "out of touch" is that most 
of the IETF has found the WG, its mailing list traffic flow, and 
some of its tone, either unpleasant or overwhelming or 
unimportant enough that they have moved on to other things. 
This has created a statistical bias between the composition and 
opinions of the self-selected WG and that of the community.   In 
other words, the WG has become an island, having discussions and 
reaching conclusions that are out of touch with the IETF 
universe.

Now, what to do about this:

(i) It seems to me that the WG membership may need to do less 
"talking" (and especially repeating of issues and positions) and 
more outreach and listening to the broader community.

(ii) In part because that sort of outreach and listening is hard 
and we have no real structure for doing so, we should all be 
aware of the limitations of this WG, and any like it, for 
determining IETF consensus about policy, changes, and methods. 
We may, nonetheless, be an effective body for identifying 
"problems" and "issues" ... just not an effective body for 
estimating the importance of those issues to the community.

(iii) We should note, and add explicitly to the Problem list, 
something like:

	Sometimes, because of its composition, a
	well-intentioned WG will reach conclusions different
	from those of a reasonably-well-informed IETF Community.
	This is especially likely when the subject matter of the
	WG, or its style of working (discussed elsewhere) drives
	a significant fraction of "the rest of" the IETF away or
	otherwise prevents their active and effective
	participation.  Because their primary responsibilities
	lie with the WG itself, it is often impossible for WG
	leadership to either detect that this is occurring or to
	control it: the quest, especially on the WG level, for a
	mythical "silent majority" is more likely to lead to
	madness or demagoguery than to better understanding and
	alignment with the community.   It is therefore an
	important IESG responsibility, relying on Last Calls and
	other input --sometimes including plenary input-- to
	understand when such disconnects have occurred and to
	correct them.  But this type of IESG action almost
	inevitably leads to cries of outrage from the WG
	(because it had consensus internally) and frustration
	about "late surprises".   None of this should be
	considered a real process problem, and we should be more
	concerned if the IESG fails to do its job by searching
	for, identifying, and correcting for such disconnects.
	But, especially to the extent that it is inevitable in
	some cases, the community must learn to understand the
	problem and to be supportive of IESG action to detect
	and control it (and should insist that the IESG do so).

regardsm
john