Subject: [Pesci-discuss] Finding and nurturing the bright sparks of genius

From: Elwyn Davies <[email-masked]>
Date: Wed, 26 Oct 2005 12:09:27 +0100

The best work in the IETF (IMH and personal O) comes from recognition of 
a problem blended with the kernel of an idea for a solution.
Within those solutions, progress is made by individuals or small design 
teams coming up with ideas that advance the work.

The original ideas hardly ever stem from the larger consensus.  The 
virtue of the wg and the larger IETF, at their best, is to recognize the 
better mousetrap for what it is, to support it and  to converge round it.

The IAB and the IESG are supposed to be architecturally, technically and 
managerially aware of the problem space in which we are working.  They 
need to make the IETF and the wider world aware of this week's problems 
and promote the solutions we offer, but except as individuals they are 
unlikely to come up with the sparks of inventive genius that start us on 
the path to solutions.

What they should be doing is looking in the right places for those 
sparks of genius and then nuturing and fanning the flames into a real 
better mousetrap solution which can achieve technical excellence, market 
effectiveness and IETF consensus.  The IESG has to *steer* these small 
sparks into enormous bonfires that will burn up the problems (got a bit 
carried away with the metaphor there).

[Aside: Maybe there is a principle in there that we didn't write down?]

To my mind this applies just as much to our process as to the technical 
work.

The discussion over the last couple of weeks has spent far too much time 
worrying whether what PESCI is doing is subverting the IETF aethos, 
rather than seeing it as a way to find out if there are any sparks of 
genius out there to be nurtured. 

The discussion to date has neither spent a lot of time reviewing the 
principles proposed (with one or two honorable exceptions) nor have we 
seen any solutions proposed.

If we agree that there is some sort of  problem, it seems to me that 
almost any means is legitimate as a way to find the kernel of a 
solution.  If the current draft does revisit the ground covered by 
'problem' maybe it will trigger the Eureka moment in somebody for some 
part of a perceived problem and they (and maybe some of their 
colleagues) can come up with a strawman that we can discuss.  Until we 
have a strawman, the discussion is likely to remain unfocussed and 
procedural rather than solutional as it has done for the last couple of 
years

So: any or all of you, read what the draft says, please.   Then: do you 
believe there is a problem?  If so do you have a bright idea? Then come 
and propose it.  Only then are we likely to make progress and it will be 
up to the community and the IESG to nurture and guide it (not 
necessarily work it).  Only if this proposal is imposed without 
achieving community (rough) consensus is the IETF ethos subverted.

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 26 Oct 2005 13:49:31 +0200

At 13:09 26/10/2005, Elwyn Davies wrote:
>The best work in the IETF (IMH and personal O) comes from 
>recognition of a problem blended with the kernel of an idea for a solution.
>Within those solutions, progress is made by individuals or small 
>design teams coming up with ideas that advance the work.
>
>virtue of the wg and the larger IETF, at their best, is to recognize 
>the better mousetrap for what it is, to support it and  to converge round it.
>
>The IAB and the IESG are supposed to be architecturally, technically 
>and managerially aware of the problem space in which we are 
>working.  They need to make the IETF and the wider world aware of 
>this week's problems and promote the solutions we offer, but except 
>as individuals they are unlikely to come up with the sparks of 
>inventive genius that start us on the path to solutions.
>
>sparks of genius and then nuturing and fanning the flames into a 
>real better mousetrap solution which can achieve technical 
>excellence, market effectiveness and IETF consensus.  The IESG has 
>to *steer* these small sparks into enormous bonfires that will burn 
>up the problems (got a bit carried away with the metaphor there).
>

Granularity, subsidiarity, "concertation" (French meaning and now 
Eurospeak: to independently act in a concerted way), multilateralism.
This is the essence of a distributed network. IETF is facing the 
necessary transition from a decentralised (still somewhat 
centralised) system to its natural distributed stability. This MUST 
go together with IAB thinking on the Internet architecture.

This architecture/meta-architecture is no small thing. It is what I 
call transitionning from "mono-Internet" to "multi-Internet".

>To my mind this applies just as much to our process as to the technical work.
>
>The discussion over the last couple of weeks has spent far too much 
>time worrying whether what PESCI is doing is subverting the IETF 
>aethos, rather than seeing it as a way to find out if there are any 
>sparks of genius out there to be nurtured.
>principles proposed (with one or two honorable exceptions) nor have 
>we seen any solutions proposed.

I proposed one: to apply to meta-architectural layer the RFC 1958 
architectural principle together with an IAB model of the network.

>'problem' maybe it will trigger the Eureka moment in somebody for 
>some part of a perceived problem and they (and maybe some of their 
>colleagues) can come up with a strawman that we can discuss.  Until 
>we have a strawman, the discussion is likely to remain unfocussed 
>and procedural rather than solutional as it has done for the last 
>couple of years
>
>So: any or all of you, read what the draft says, please.

The first problem is to save a lof of time. When one quotes a Draft 
one does as for every other document: one gives its current URL.
Stupid input? I think it would save a lot of time and multiply 
reading by an order of magnitude ...

>  Then: do you believe there is a problem?  If so do you have a 
> bright idea? Then come and propose it.  Only then are we likely to 
> make progress and it will be up to the community and the IESG to 
> nurture and guide it (not necessarily work it).  Only if this 
> proposal is imposed without achieving community (rough) consensus 
> is the IETF ethos subverted.

All the best.
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 26 Oct 2005 05:52:05 -0700

Elwyn,

one further thought.....

--On 26. oktober 2005 12:09 +0100 Elwyn Davies <[email-masked]> 
wrote:

> almost any means is legitimate as a way to find the kernel of a solution.
> If the current draft does revisit the ground covered by 'problem' maybe
> it will trigger the Eureka moment in somebody for some part of a
> perceived problem and they (and maybe some of their colleagues) can come
> up with a strawman that we can discuss.  Until we have a strawman, the
> discussion is likely to remain unfocussed and procedural rather than
> solutional as it has done for the last couple of years

we have, in the years since Yokohama, as Dave's fond of marking time, had 
literally dozens of strawmen for how the process should be changed - 
including mandatory deadlines on WGs, constitutional limits on WGs per 
area, term limits on ADs, RFCs in HTML, I-Ds in XML, creating public IESG 
ballots, taking document review away from the IESG, splitting up the IESG 
into functional units, instituting early review, instituting late review, 
instituting cross-area review, changing IESG voting rules, appointing WG 
secretaries, public document tracking, making WG chairs shepherd 
documents... just to name a few.

Some of these have been adopted, most have not. And of the set not adopted, 
one common thread for many is that we do not know *how to make that change*.

The "just do it" department has usually come up against the principle 
described in the PESCI document as

>    G5.  Avoid changes that would require unrealistic resources or
>         behaviours.

PESCI itself is a short-term event. Its legitimacy is not even interesting 
to me - it needs none, if its output is right.

My most burning question is whether section 6 of the PESCI document is a 
realistic and acceptable way forward to get the process of getting 
important changes done running - or whether the proposal needs further 
elaboration or change in order to answer that question at all.
And to have any information about that, someone needs to comment on *that*.

So far, I don't think many have.

                      Harald

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Oct 2005 16:53:09 +0300

> My most burning question is whether section 6 of the PESCI document is 
> a realistic and acceptable way forward to get the process of getting 
> important changes done running

As requested.

>    What the PESCI design team propose should be done next:
>
>    We believe that an early proposal is needed for a new process for
>    developing changes to the IETF processes especially in the area of
>    developing standards documentation and other specifications.
>
>    This proposed new process
>    o  would be used by all individuals, design teams, and working groups
>       who wish to propose changes or additions to IETF processes,
>    o  should involve consultation with the IESG, the IAB, the IAOC, the
>       Working Group chairs, and IETF participants generally, but
>    o  must avoid requiring the IESG to develop the new processes or
>       micromanage this process of development and approval.
>    The new proposals, both for the change process and any resulting
>    changed processes, should be implemented as a matter of urgency and
>    should be handled expeditiously by the existing approvals and
>    publishing process.

This says very little in terms of concrete things, except that
the process needs an "early proposal", is used by everyone,
involves consultation with existing bodies,  is "urgent"
and "requires no micromanagement".

> 6.1.  Change Process Proposal
>
>    We propose that the design team model is the most effective way of
>    engineering process changes.  Within the context of the existing IETF
>    process, this could be arranged by constituting a set of design teams
>    with appropriate oversight and the charter of carrying out process
>    change.  The design teams would operate within these charters: the
>    overseers would invite design team members to participate, but
>    alternative teams could offer solutions if they feel they have better
>    solutions.
>
>    The teams should function with an open discussion list, in the same
>    way that the PESCI committee has done.  The result of the committee
>    should be tested against the IETF consensus in the normal fashion; we
>    believe that if there is clear IETF consensus that the proposal makes
>    sense, the IESG (and the ISOC Board of Trustees) will respect that
>    consensus and approve of it.

This is mostly OK. I just wonder where the efficiency compared
to a WG approach comes from (we all agree it hasn't worked well).
Even in a WG, its somewhat private groups that develop documents.
The difference between the above and the WG process appears
to be mainly that instead of a WG and IETF approval steps, we will have
just one, IETF approval step. I'm reasonably certain that we,
the IETF, still have sufficient possibility to affect the outcome,
which I think has been some people's concern. But I'm not sure
you will avoid some of the earlier problems that the WG processes
have had. We could still be in for a lengthy discussion at IETF
level. But maybe that's fine.

I definately want to keep my ability to comment on and
affect proposals. Maybe it helps that the discussion
will be in plenary/ietflist instead of some obscure and
ever-changing wg/mailinglist... most of the what we need
is a statement from the troops who actually do IETF
stuff, not from the few process fanatics or parts of
existing management... sometimes it feels that the
discussion (as well as mike time in plenaries) is
more or hijacked by a select few.

> 6.2.  Immediate Tasks for the Change Process
>
>    Assuming that the model suggested in Section 6.1 is adopted, the
>    following process change task appears to be the most urgent one, and
>    a team should start on this as soon as possible.
>
>    The most important single management role in the IETF at the moment
>    is that of the IESG, including the role of IETF Chair.  This should
>    therefore also receive the most scrutiny.  It's unreasonable to ask
>    people to grade their own performance, or to attempt to perform a
>    role at full speed while having to review how it could be done
>    otherwise.  Therefore, a review of the roles the IESG has should be
>    rooted outside the IESG - while asking current and former IESG
>    members for information and advice at every opportunity.
>
>    This should include:
>    o  Creating a list of the tasks that currently gate on the IESG
>    o  Identifying any additional related tasks that might be appropriate
>       to improve efficiency and effectiveness
>    o  Making proposals for discarding or restructuring the existing
>       tasks in combination with the new tasks
>    o  Making a proposal for grouping those tasks into separate task
>       groups that can be assigned to different bodies at need.
>    o  Developing a proposal for how the standards development work of
>       the IETF should be partitioned to provide optimum efficiency while
>       allowing the IETF to take on all appropriate work.
>    o  Developing a suggestion for an initial set of bodies for handling
>       those tasks in the new work partitioning scheme, including, if
>       appropriate, a restructuring of the IESG.
>    o  Describing the process by which the set of bodies gets modified.
>    o  Describing how members of the proposed bodies get selected,
>       replaced, and (if needed) r

I'm actually not at all certain that IESG restructuring
is priority 1. I think there's a good chance that
some of the non-basic AD tasks should be moved
to other bodies, including, for instance, process
changes. I would rather do a small change wrt IESG
role along with a few other changes elsewhere.

Anyway, I agree very much that IESG changes should
be performed by someone else than the IESG. It
puzzles me though, that the IESG would be selecting
the people to work on IESG role changes. Not sure
how to fix that, unless we have nomcom pick process
change masters, or have the IAB supervise pesci
instead.

The text isn't clear enough that all of the above bullet items
are intended to be about IESG's role. (Or are they?)

Item 5 appears to not belong under IESG restructuring, imho.
(I like item 5, but it seems that its more of an area etc issue.)

I'm a bit surprised that Section 5 worked hard on what items
should get a restructuring and then in Section 6 you decide
that just one of those does. I think we can afford upto a few
design teams at a time to look at other issues, too. I think
excellent bang-for-the-buck ratio could be reached from
rfc editor model changes. WG process is the other major
consumption of time at the moment, so improving that
would also be a priority (just that I don't know how). Trend
for openess should also continue.

So my suggestion would be to say that along with a
smaller scope of an iesg role change, 1-2-... other design teams
be created as well initially to look at the other problems, in
parallel.

--Jari

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 26 Oct 2005 06:08:07 -0700

I have been doing my day job at NANOG and have not even completely 
assimilated the PESCI draft and JohnK's recent note about PESCI, much less 
what has gone on since then, but

> [Aside: Maybe there is a principle in there that we didn't write down?]

Yeah, almost certainly, the list of 30-something principles is not complete, 
and not all the list elements are principles either.

Thre PESCI team has many people that I like AND respect on it, but whaever 
the current draft says, the IETF does NOT have 30-something principles.

The work that the PESCI team has done is good work, but we still don't know 
what the principles ARE - for my definition of "principle" - something that 
cannot change without the IETF not being the IETF, but turning into 
something else.

My suggestion, based on not a lot of sleep or thought, is that the BOF focus 
on getting community feedback on what the principles are, and the list of 
30-something is a reasonable starting point to winnow from.

I can say this on this list, on the IETF list, at the BOF, or at the 
plenary, but whatever else we need between Vancouver and Dallas for process 
evolution to move forward, we need to know those principles.

The alternative is that we evolve the IETF process in a way that the 
community will not follow, and that would be very unfortunate.

Thanks,

Spencer

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Oct 2005 10:31:51 +0100

Hi Spencer,

It does depend on what we mean by "principle".

> cannot change without the IETF not being the IETF, but turning into

We did recognise that there are two grades of principle (maybe loosely
categorised as "immutable" and "guiding").
Would it have helped (would it help in future work) to separate these out,
or would that simply introduce another area for debate?

My personal view is that a lot of previous attempts at process change have
foundered on discussions of the form
- "but if we make that change then we will no longer do xyz"
- "it doesn't matter if we no longer do xyz"
- "oh yes it does"
- "oh no it doesn't"

> 30-something is a reasonable starting point to winnow from.

Winnowing is fine by me.

We also found, as we put the draft together, that expressing principles
was hard. Repeatedly we found that what we wrote was a consequence of a
principle and not the actual principle. So feedback and discussion of the
list is most welcome.

> community will not follow, and that would be very unfortunate.

Thanks,
Adrian

---

From: Scott W Brim <[email-masked]>
Date: Thu, 27 Oct 2005 07:57:14 -0400

On Wed, Oct 26, 2005 06:08:07AM -0700, Spencer Dawkins allegedly
wrote:
> Thre PESCI team has many people that I like AND respect on it, but
> whaever the current draft says, the IETF does NOT have 30-something
> principles.

Good, we've got you thinking about it.  In order to discuss processes
for process change, we have to agree on core principles, and not take
short cuts on doing so. 

> My suggestion, based on not a lot of sleep or thought, is that the
> BOF focus on getting community feedback on what the principles are,
> and the list of 30-something is a reasonable starting point to
> winnow from.

I'd prefer doing *most* of this via mail (i.e. some can be done in the
BOF but just to get it moving).  It *should* be a long discussion, and
participants should think and feel deeply between comments.  

> plenary, but whatever else we need between Vancouver and Dallas for
> process evolution to move forward, we need to know those principles.

Yes.

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2005 16:47:28 +0200

Another point to consider is whether we did the right thing in
pushing the laundry list of raw principles off into an Appendix.
But we do need to be very clear about separating basic, unchanging
principles from the specific principles for change. Maybe the basics
should be spun off as a completely separate item of work?

    Brian

---

From: Scott W Brim <[email-masked]>
Date: Thu, 27 Oct 2005 10:58:23 -0400

> should be spun off as a completely separate item of work?

Yes.  We didn't have time.  I think we could take several months on
this.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2005 17:01:35 +0200

Jari Arkko wrote:
...
> existing management...

Violent agreement. We need input from the whole community
with deep IETF experience, such as WG chairs and prolific
contributors, but we're not likely to get all of them signing
up for a YAP WG (Yet Another Process WG).

> sometimes it feels that the

I think you mean a self-selected few, to be honest. There are
people who've stayed with the process discussion for many years,
and I think they are largely also prolific technical contributors.
The challenge is to get *more* such people engaged, if we are to
succeed in making changes.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2005 05:50:38 +0200

> should be spun off as a completely separate item of work?

I'm *somewhat* biased, but I think we captured a pretty basic set of 
principles in the IETF Mission Statement.
I'd like to get our principles sorted into 3 groups:

- Basic Principles that are in the mission statement. Remove and replace 
with pointer.
- Basic Principles that should have been in the mission statement. Refer to 
a mission statement upgrade. (I *hope* that's an empty list.....)
- Guiding Principles and Change Prinicples that follow from the prinicples 
in the mission statement. They belong here.

Does that make sense? At all?

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Oct 2005 11:20:45 -0700

> Some of these have been adopted, most have not. And of the set not 
> adopted, one common thread for many is that we do not know *how to make 
> that change*.

Dave is also fond of pointing out that the *real* common thread is a 
demonstrated community desire to spend more time criticizing and dismissing 
proposals than in making them work.

 From that perspective, the "we do not know how to make that change" 
argument is merely a convenient process hack that successfully distracts us 
from doing the hard work of making real changes.

An alternative to constantly turning every change suggestion into a process 
issue is encourage going about the direct work of making the change.  This 
involves rallying basic support and then focusing on improvement and 
adoption of the change. In such a context, the process oversight merely 
isone of ensuring that an effort doesn't do silly and/or destructive things.

Hence, "process" divides simply into sanity-checking and recruitment of 
community support.

(By the way, that's the way successful IETF process changes have been done 
in the past.)

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2005 18:40:27 +0100

Actually I realised yesterday (thanks to Sam's nagging - it's good to have
an AD to keep me honest) that we need to separate three types:

1) Basic, hopefully invariant, IETF principles
2) Principles for necessary process changes
3) Principles for a new process to change the process

Having reviewed the mission statement and a lot of other stuff prior
to the PESCI draft, I'm not 100% convinced that the mission statement
captures every single part of 1), but I think the problem here is
to capture 2) and 3) and separate 2) from 3). Our draft
is not clear enough about that yet.

     Brian

Harald Tveit Alvestrand wrote:
> - Basic Principles that should have been in the mission statement. Refer 
> to a mission statement upgrade. (I *hope* that's an empty list.....)
> - Guiding Principles and Change Prinicples that follow from the 
> prinicples in the mission statement. They belong here.
>