Subject: [Pesci-discuss] For whom it may concern..

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Nov 2005 02:55:11 +0200 (EET)

Dear (parts ofo the) IESG and IAB,

Thanks for overwhelming the PESCI BOF with your concerns.

Wouldn't you rather be part of the solution, or continue being part of 
the problem?

Unless you've noticed, the IETF leadership (that would be you) has not 
exactly been active or successful in solving this problem.  I realize 
John Klensin already stated this at a plenary a year or two ago. 
Maybe you should look at the mirror, and step back a bit when the 
community tries to solve the problem?

Thank you.

_______________________________________________
Pesci-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pesci-discuss

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 09 Nov 2005 20:12:05 -0500

Pekka,

An alternative perception is that you *saw* the IAB/IESG
contributing to the discussion of the solution, trying to help
lead it towards something that will work.

As opposed ot sitting in a smokey back room making the comments
among ourselves, for example.

Leslie.

Pekka Savola wrote:
> John Klensin already stated this at a plenary a year or two ago. Maybe 
> you should look at the mirror, and step back a bit when the community 
> tries to solve the problem?
> 
> Thank you.
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Nov 2005 08:28:46 +0200 (EET)

> lead it towards something that will work.

There obviously were many assumptions floating around, so I'll explain 
mine.

The IESG has had .. less than stellar track record of responding to 
the bottleneck problems.  As a matter of fact, I do not recall a 
single improvement which would have had _significant_ on throughput. 
While the transparency of the work has improved over the years, this 
has obviously not had significant impact on the amount of work getting 
done.

So, I see only two options which do not have to be mutually exclusive:

  1) we institute a new process change process which allows 
distributing the responsibility for getting the necessary changes 
proposed, discussed and implemented (this is actually similar to how 
the IAOC effort took off some responsibility from the IESG and IAB), 
or

  2) we continue to hope that the current or future leadership will 
drive through the required changes (in addition to keeping up with 
"day-to-day" business).

Call me a skeptic, but 2) has not been so successful so far, despite 
sporadic attempts (remember for example MPOWR and ICAR which were 
results of an IESG retreat on the topic -- not too different than the 
one Brian was mentioning).  It just doesn't seem to be possible to 
devote sufficient energy to do these things, while keeping the "daily 
business" running.

Hence, my main criticism of the current leadership is not that they 
have not been able to make these changes: rather, it is that they have 
not been able to realize that most likely they will never be able to 
make these changes themselves, and are not able to realize that they 
must "step out of the way" as soon as possible.

But instead of putting energy to improving the process change process 
and ensuring that it's "something that will work" as you say, it 
seemed to be better to shoot it down based on (what seemed to be) FUD 
reasons.

(FWIW, there already seemed to be at least some consensus for this 
approach at Paris meeting, which is probably why Brian acted as he 
should: http://www3.ietf.org/proceedings/05aug/plenaryw.html)

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 10 Nov 2005 13:54:47 +0100

At 07:28 10/11/2005, Pekka Savola wrote:
>  It just doesn't seem to be possible to devote sufficient energy to 
> do these things, while keeping the "daily business" running.

As a user implied IETF outsider (meaning having a direct 
understanding but being mentally unbound), I think this is not 
possible. You cannot mentally carry well a job one way and think it 
should be done better otherwise. You can advise, not organise.

This should be nr 1 rule of any change process. Until a change is 
enforced, the previous practice must be 100% enforced. Otherwise 
transitions become confusion.
jfc

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Nov 2005 07:25:48 -0800

Hi, Leslie,

> among ourselves, for example.

Yeah, and I'm pleased by that part... Thank you.

Another helpful thing that happened was Ted saying that, at some level, we 
are all on the same side, wanting the IETF to work better. This isn't news, 
but it's good to say it out loud from time to time.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Nov 2005 07:42:27 -0800

>  1) we institute a new process change process which allows distributing 
> the responsibility for getting the necessary changes proposed, discussed 
> and implemented (this is actually similar to how the IAOC effort took off 
> some responsibility from the IESG and IAB), or
>
>  2) we continue to hope that the current or future leadership will drive 
> through the required changes (in addition to keeping up with "day-to-day" 
> business).

Agree that these are two options, and not mutually exclusive.

One addition to 2), though.

When we have actually DONE something, it's usually been good. I'm thinking 
about the I-D Tracker, and the semi-related PROTO work, which has had more 
impact on the IETF than all the noodling about process change we've done 
since Yokohama.

I can't speak for anyone except myself, but  - I DO have cycles to try to 
help, and accept Leslie's point from PESCI, that random proposals don't 
help. I may not be the only one.

We talked about issuing a "call for proposals" yesterday. Please don't. 
You'll get more random proposals.

What would help me, and maybe others, try to help is a "call for proposals 
in a specific problem space".

Figuring out a way to tap cycles in the larger community is important. That 
was why Gen-ART was a good idea - the cycles to do more reviews were "out 
there", they just weren't being tapped effectively.

If you get a proposal that solves a specific problem/"pain point", that 
matters, we already have enough BCPs to actually DO something as a process 
experiment. Not saying that we don't need process evolution, just saying 
that we don't have to do process evolution before anything can get better.

Thanks,

Spencer

> sporadic attempts (remember for example MPOWR and ICAR which were results 
> of an IESG retreat on the topic -- not too different than the one Brian 
> was mentioning).  It just doesn't seem to be possible to devote sufficient 
> energy to do these things, while keeping the "daily business" running.
>
> Hence, my main criticism of the current leadership is not that they have 
> not been able to make these changes: rather, it is that they have not been 
> able to realize that most likely they will never be able to make these 
> changes themselves, and are not able to realize that they must "step out 
> of the way" as soon as possible.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Nov 2005 17:58:36 +0200 (EET)

On Thu, 10 Nov 2005, Spencer Dawkins wrote:
> experiment. Not saying that we don't need process evolution, just saying that 
> we don't have to do process evolution before anything can get better.

We already have a lot of those.  John Klensin's review team; Harald's 
two-level.  Alex Zinin's early review.  Maybe others I forgot.

It's not the lack of specific proposals on a specific problem space, 
it's the lack of follow-through.

Based on what I've seen,
  - it's not realistic to assume that the IESG will drive forward such 
a proposal, and
  - it's not realistic to assume the author of such a proposal would 
drive it through all by him/herself.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Margaret Wasserman" <[email-masked]>
Date: Thu, 10 Nov 2005 08:31:16 -0800

> drive it through all by him/herself.

This can be said of virtually all proposals in the IETF (including technical
ones).  Without a critical mass of people who are willing to work on a given
proposal, the proposal won't go forward.  

I don't see why process proposals should be an exception to this...

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Nov 2005 12:36:45 -0500

I believe that process proposals need to be an exception to this.
As far as I can tell, the community will never reach rough consensus on any 
of the major process changes.
(It was hard enough to get rough consensus on minor changes.)
As I said at the meeting, while such an absence can be used as an excuse 
for not making any major changes, that would seem to be an inappropriate 
response.

Yours,
Joel M. Halpern

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 10 Nov 2005 10:19:53 -0800

Pekka,

I take exception to one of your remarks:

--On 10. november 2005 08:28 +0200 Pekka Savola <[email-masked]> wrote:

> The IESG has had .. less than stellar track record of responding to the
> bottleneck problems.  As a matter of fact, I do not recall a single
> improvement which would have had _significant_ on throughput. While the
> transparency of the work has improved over the years, this has obviously
> not had significant impact on the amount of work getting done.

I believe that it has.

In terms of approved RFCs, the situation of 2005 is that the IESG moves 
approximately double the number of documents that it did in 2002.
In terms of people who complain about their documents being "stuck" in the 
IESG, I don't have the numbers (the stats are a noisy signal), but my 
impression from the complaints people addressed at me through my 4 years as 
IETF chair say that the difference is enormous.

You may dismiss that "mere" factor of two as an insignificant change in 
throughput. I won't - I have too much respect for the cost that the people 
who managed to do it paid to achieve it.

(NOTE: I *agree* that we *need* significant change. The improvements we 
have managed to get have come at a high cost to the people who made them - 
in many ways. We need to make our leadership jobs livable, not just 
survivable. But we should respect the reality.)

                          Harald

---

From: "Margaret Wasserman" <[email-masked]>
Date: Thu, 10 Nov 2005 10:57:06 -0800

Hi Joel,

Joel Halpern wrote:
> As far as I can tell, the community will never reach rough consensus on
> any of the major process changes.

I think that the community can (and does) reach consensus on major changes
when they are really needed.

Last year, we reached community consensus to reorganize the entire
administrative and financial structure of the IETF and to create a new IETF
leadership body.  IMO, this happened because the community was convinced
that change was necessary, and there was sufficient pressure to fix the
problem(s) that we were able to forge a consensus.

In some other cases, we don't have that pressure (yet), so we have not
reached consensus to make other specific major changes. 

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Nov 2005 00:59:56 +0200 (EET)

On Thu, 10 Nov 2005, Harald Tveit Alvestrand wrote:
> ...

Fair point, and I'm sorry for sounding unfair.  In my earlier message, 
I had actually listed successes which have no doubt had an impact in 
what you've said (genart, proto work, I-D tracker, tools, uptake on 
education, etc.). Maybe mistakenly I removed that (this) discussion in 
the sake of conciseness before posting.

But, "less is more".  [The IESG] doing more (if it's not around an 
order of magnitude more) may help in the short term, but not in the 
longer term.  Especially if the amount of work done is not static or 
decreasing over time.

(However, I believe the improvements made have resulted in tremendous 
increase in *transparency* and the ability to figure out what's going 
on; that certainly could have resulted in dramatic decrease of 
complaints.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Nov 2005 02:55:56 +0100

Spencer Dawkins wrote:
...

> When we have actually DONE something, it's usually been good. I'm 
> thinking about the I-D Tracker, and the semi-related PROTO work, which 
> has had more impact on the IETF than all the noodling about process 
> change we've done since Yokohama.

I think Pekka is indeed underestimating the impact of those
two improvements (and there is more we can do by adding new
features to the tracker to directly support the PROTO
mechanism). I can testify that the internal efficiency of the
IESG is much greater today than it was some years ago (when
I sat in on the IESG as IAB chair). But I think Ted Hardie put
his finger on something rather vital when he stated the need
for more parallelism. For a community that builds high performance
routers, this should be obvious. Regardless of formal process
change, we need to increase parallelism.

     Brian

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Nov 2005 08:39:46 -0500

> on; that certainly could have resulted in dramatic decrease of 

In my experience, transparency (as a side-effect) increases
efficiency. Do not underestimate the importance of it being clear
clear who has the token and what the token holder is expected to
do. Compared to the pre-tracker days, this has had a significant
impact. While I was an AD, it was not uncommon to see authors go
directly to Tracker after a telechat and start dealing with IESG
comments before I had been able to get around and send them mail
saying what had happened. In those cases, one (perhaps small)
bottleneck had been removed.

IMO, there is significant potential here to develop improved tools to
make this happen routinely. For example, if tracker was better about
sending mail on certain events (like after a telechat, including the
review comments). Or, if it was smart about sending reminders
(document has been in "revised version needed" for > N weeks), or "New
Version posted", check outstanding discuss comments (with followup
reminders when this doesn't happen), etc.

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Nov 2005 16:16:42 +0200 (EET)

On Mon, 14 Nov 2005, Thomas Narten wrote:
> For example, if tracker was better about

FWIW, I don't think this helps all that much for the cases when the 
IESG is the bottleneck; however, I'm assuming that:

  - each AD regularly monitors his/hers I-D tracker pile
  - each AD regularly checks out the exceptions [0] to figure out if
    he/she missed something

[0] http://rtg.ietf.org:8080/Test/tracker_exceptions

If these assumptions hold, sending mails won't help.

On the other hand, the notifications might be very helpful for cases 
where the ball is believed to be at the authors/WG's feet, and AD 
would need to find time to ping those folks (and now the system does 
that automatically).

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Nov 2005 09:33:01 -0500

>   - each AD regularly monitors his/hers I-D tracker pile

I think this happens less often than would be ideal. A week here a
week there, pretty soon we're talking about real time...

>   - each AD regularly checks out the exceptions [0] to figure out if

Ditto.  Indeed, if you believe offloading ADs is necessary, this is a
prime example of where it could be done.

> would need to find time to ping those folks (and now the system does 

The system does not do that automatically now. Or just barely.

The email notification facilities in tracker are rudimentary. They
only happen for a limited number of state changes. They do not send
followups after an initial note. Only the AD can enter the email
addresses of those that get pinged (and if an email address goes bad,
its not obvious that anyone notices). In practice, many documents
don't have correct email addresses, etc., etc.

This could be improved (and many people have suggested worthwhile
improvements), but requires improvements to tracker. And that work is
pretty much on hold until the secretariat transition to Neustar
completes...

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2005 16:50:54 +0100

> pretty much on hold until the secretariat transition to Neustar

This is all very much on the IESG radar screen and is why we are
planning an efficiency retreat, as I mentioned in plenary, and why
the PROTO team is looking at necessary tool updates, as Allison
mentioned in plenary.

All this is *procedural* improvement, and not process reform.
What we want to look at here is process reform.

     Brian