Subject: RE: Response requested: Proposal regarding milestones

From: [email-masked]
Date: Fri, 20 Dec 2002 07:01:06 +0200

Marshall,

>     - a design team, usually <= 5 people
>     - contributors, usually <= 20 people
>     - the masses, usually < the earth's population
>     
> although there's some talk about design teams in various documents,
> there's still something of an adhoc feeling about them, and 
> contributors don't have any mention at all.

I think a problem in the current process is that the role of design
teams is unclear.  In some cases, they are extremely useful and help
move the work forward.  In other cases, they destroy transparency
and can are detrimental to the WG process.  I think something to
discuss on the Problem Statement list is this.
     
> now, i'll claim that all three of these tiers provide are 
> necessary to a successful outcome.
>     
>     - design teams provide focus and consistency
>     - contributors provide breadth
>     - masses provide buy-in
>     
> (this is a little rough, i'll come up with crisper sound-bites later.)
> quick question: can we agree on the taxonomy?

I'd suggest that design teams do the heavy lifting, but I don't
oppose your taxonomy.

> if so, then sticking with fred's "management by objective" (or, more
> plainly, "it's the charter, stupid!"), does it make sense to 
> make design teams and contributors an explict part of the chartering progress?

As long as design teams are open & transparent and not formalized into
the WG.  Design teams sometimes smell of wg cliques - who secretely control
the WG / IETF process (no, wait, it is the directorates who fly into IETF
meetings in black helicopters who control the IETF process ...)
More seriously, from IETF outsiders (those who come to meetings and do
some work - but who are part of the audience more often than not, it
seems that this lack of transparancy is one of the larger issues
with current IETF processes.  

> if so, can we also agree that, from time to time, charters get updated
> as our understanding begins to converge with reality?

Most definatley.

> at this point, my claim is that we need to focus on two things:
>     
>     - what are the membership requirements for design teams and
>       contributors?
>     
>     - how does formalizing the design team and contributor concepts
>       impact the way the wg process works?
>     
> again, i like the direction you're going in (even if i'm not on board
> with all the details), but i'd like to see if we agree on the
> architectural aspects before we do the actual engineering.

I think those two things are important to discuss.  I'd still add a
third:

	- how to ensure transparency.

John

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 20 Dec 2002 07:06:10 -0500

>with current IETF processes.

Now that you mention it, I do remember feeling that way...

For the first few years that I was involved in IETF activities, I
was conscientious about reading WG mailing lists, I attended meetings,
but I still had no idea where/when/how many of the decisions were
being made.

Sometimes I'd object to something in a document, only to be told
something like "we discussed both choices and decided to go
with this one".  I never could figure out who "we" was, and I
didn't know what forum was being used for either the discussion
or the decision...  Perhaps there were design teams of which I
was entirely unaware.

Formalizing design teams as part of the charter and/or being more
open about the teams and their work within the WG can have some
benefits.  But, it also may formalize a more closed IETF where
only a few people are involved in the early decision making process.
Once something has been decided by a design team, there can be some
intertia against changing it, even if it has never been discussed by
the whole group.

Also, a fairly complex WG (like IPv6) couldn't be served by a
single design team.  In fact we currently have two semi-official
ones in progress (MIBs and Node Requirements), and we have some
unofficial ones (the flow label authors, the scoped addressing
authors, etc.).  We also have one official editor (Bob Hinden)
and several unofficial ones (editors of various documents
currently under consideration).  So how would an effort like this
map onto the design team/contributors/masses model proposed by
Marshall?

Margaret

---

From: Marshall Rose <[email-masked]>
Date: Fri, 20 Dec 2002 10:03:01 -0800

> or the decision...  Perhaps there were design teams of which I

obviously, at this point you should ask "can you give me a pointer to the
who/what/when/where so i can educate myself as to why that decision got made?"

i'm sympathetic to folks who want to make forward-progress and are reluctant to
reopen old decisions; but, there's also a responsibility to help people
understand how things got to where they are.

> intertia against changing it, even if it has never been discussed by

true, and this is why i'd like either this group (or another one) to get some
kind of concensus as to what makes design teams "special" -- there are a bunch
of things being balanced here, and i want to see if we can increase
getting-things-done without decreasing openness.

> map onto the design team/contributors/masses model proposed by

since you asked, i'll respond:

first, let's agree that the more you understand about a problem upfront,
the easier it is to put together a credible charter. let's also agree
that as time goes on, a successful wg should have a better understanding
of the problem, and that negotiating a change to the charter to reflect
that is a reasonable thing.

with that in mind, you first have to ask yourself whether it makes sense
to have "a fairly complex wg" or two or three less complex wgs. if the
latter, i think the question is already answered.

if the former, then i think the charter needs to discuss phases of the
wg's lifetime, which may overlap. (certainly work can start on a foo mib
before foo is fully defined, but you probably can't start work until
foo's definition is converging.)

so, in that case, i think you define the phases and then designate
design team/contributors for each phase.

i'll tell you that, in general, i'm somewhat nervous about "fairly
complex wgs", because they tend to be multi-year efforts and i worry
that wgs that hang around for a long time tend to lose focus, so i would
hope things like this are the exceptions that prove the rule.

/mtr

---

From: "James Luciani" <[email-masked]>
Date: Fri, 20 Dec 2002 14:25:17 -0500

> > or the decision...  Perhaps there were design teams of which I

I had exactly this experience as well.  Also, I had asked to be part of
several of them over the last year or so and was ignored in several cases...
in fact, one AD was even kind enough to ask the chair to have me involved
and yet it did not happen.  I think design teams have occasionally done more
harm than good, because they were permitted to act as far too closed of a
system.  I have heard this sentiment from people time and time again; worse
yet, the complainers about this were often the workers for the group who
have subsequently felt disenfranchised and thus stopped participating.  If
design teams are to continue then they need to be substantially more open
than they have been in past.

> > single design team.  In fact we currently have two semi-official

Yeh, I do not think that design teams should be WG based as much as a well
defined and scoped "topic" base.  There is even potential to have design
teams across WGs.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 20 Dec 2002 11:37:01 -0800

The most problematic design teams I've come across is the one
often referred to as "the authors".  It seems "the editor"
forgets that "the authors" are providing input to the WG and
that this input has no more weight than input from others.

One of things that might help remind "the authors" that they
are given no more weight is not to list them at the top of
the WG I-D.

For this reason, I would like the IETF adopt a practice that
IETF documents list only the Editor in the header.

Kurt

---

From: Marshall Rose <[email-masked]>
Date: Fri, 20 Dec 2002 11:37:12 -0800

> defined and scoped "topic" base.  There is even potential to have design

that raises some serious alarms with me, but i guess it's a matter of
understanding the particular case. whenever possible, i prefer to use the
short-term highly-focused wg model, if for no other reason because wgs chartered
like this tend to finish... but, if the case can be made for a design team
spanning wgs, i don't see a fundamental reason why not...

mtr

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 20 Dec 2002 12:35:46 -0800

Marshall Rose wrote:
> ...
> i'll tell you that, in general, i'm somewhat nervous about 
> "fairly complex wgs", because they tend to be multi-year 
> efforts and i worry that wgs that hang around for a long time 
> tend to lose focus, so i would hope things like this are the 
> exceptions that prove the rule.

Do they really loose focus, or is it simply that once the fundamental
priority issues are completed, the remaining issues are independent and
just as easily accomplished by smaller or other existing groups? 

For example, we may decide initially that a temporary area is required
to establish a level of focus across a range of groups. Over time that
will evolve to a point where a complex WG is sufficient to maintain the
necessary focus on the critical architectural issues. Eventually though,
the technology becomes mature enough that the architecture is well
understood so WGs in other areas can reference it. At this point a
complex dedicated WG is no longer required, and starts to look defocused
as it deals with the independent edge cases. 

This is not wrong, we just need to recognize the evolutionary process as
part of the overall architecture you are attempting to define. If we
insist that all WGs are short term and narrowly focused, we can't take
on complex tasks because the resulting pieces will not fit together.

Tony

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Dec 2002 13:35:21 -0800

> than they have been in past.

The difficulty is that without design teams, i.e. a small, dedicated group of
individuals, the liklihood that one gets "design by committee" is higher. Small
group interaction has generally proven in the past to have a higher success rate
(though not guaranteed) to get good designs.

The only other way I've seen to avoid "design by committee" is to do
requirements and then run a bakeoff against the requirements for individuals or
teams to submit their proposals. This works in some cases, where the
requirements are clear, where good, mature proposals are forthcoming, but
doesn't work in others, with fuzzy requirements, or where the topic area is new
and there are no good, mature proposals.

Perhaps the solution is to make design teams more open.

            jak

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 Dec 2002 16:35:39 -0500

> spanning wgs, i don't see a fundamental reason why not...

One of the design teams that Margaret mentioned is a good example
of a "cross-WG" design team and that is the IPv6 MIB design team.
The Internet and OPS ADs specifically requested the team to deal with
the complex issue of updating existing MIBs to support both v4 and
v6.  Even though most of the documents are now IPv6 WG documents,
the team is composed of experts from both v6 and management.  I
tend to think it has worked fairly well.

So, if the DT has a clear goal, committed members, and support,
I can see them working well.

Brian

---

From: Marshall Rose <[email-masked]>
Date: Fri, 20 Dec 2002 14:15:53 -0800

> just as easily accomplished by smaller or other existing groups? 

sometimes it may be that case that a "fairly complex wg" may never even
get focus. but, if you have to do it that way, then you should do it
that way. however, we really need to think extra hard before doing
something that way...    

> on complex tasks because the resulting pieces will not fit together.

that really depends on how well you understand that problem and the
components of the solution.  for example, defining an smi, so that work
on snmp could be done separately from the various mibs (and most mibs
could be done independently from each other), was obviously a good
approach.
    
but again, i'm not insisting that all wgs be short-term and
narrowly-focused (though it would make me happier if they all turned out
that way); rather, i'm saying that we must take extra care, pay extra
attention, and be extra thoughtful when commissioning wgs of the "fairly
complex" variety!
    
/mtr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Dec 2002 17:13:25 -0600

On 12/20/02 at 12:35 PM -0800, Tony Hain wrote:

>we may decide initially that a temporary area is required
>necessary focus on the critical architectural issues.

Isn't that supposed to be an IRTF working group?
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 20 Dec 2002 15:33:39 -0800

> Isn't that supposed to be an IRTF working group?

Not necessarily. If all we are ever going to take on in the IETF are
small incremental changes, short-term narrow-focus groups are
appropriate. If we need to make significant changes like replacing the
predominate protocol at a given layer, that isn't going to happen
quickly, and no it is not research. What it means is that the breadth of
the problem space is not well understood by the majority of the
participants. Just figuring out what people need to have spelled out
takes time.

I agree with Marshall that we should seriously consider breaking down
the problem as far as we can up front, but some of the hard problems
require strong cross discussion and trade-off between the constituent
pieces. My concern is that if we end up restricting the scope of WGs to
the narrow, well-defined edge issues, we will force the IETF into
irrelevancy as the real significant challenges are taken elsewhere.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Dec 2002 02:16:20 +0200

> or the decision...  Perhaps there were design teams of which I

You may have run into a badly run design team, WG, or chairs.
Personally, I've had relatively good experiences of design
teams, though not all of them succeeded. But perhaps I've been
blind, having been a member in a number of such teams...

Anyway, we shouldn't forget that the output of individuals,
editors, and design teams is under the WG's consideration.
Generally we also expect design decisions to be justified.
If they are not, then its just plain wrong, whatever the source
of the documents are.

The more official position the design team has the more careful
it has to be in announcing its progress, decisions, and
justifications. The design teams that I have seen work well
have produced frequent output which has been debated on the
list.

Anyways, if someone wants to formalize the notion of a
design team we need to understand there are several different
types:

Individual submission team -- A group of like-minded folks
                               get together and produce documents.
                               These groups should be dealt with
                               like individuals are dealt with;
                               I see little possibilities for
                               additional formalism or control here.
                               This is our basic mode of operation
                               in IETF.

Specific task force DT -- Individuals with specific expertise are
                           brought in to solve a problem, sometimes
                           even from outside the WG. Usually works
                           for a very short duration only. These folks
                           may produce a short document, but more typically
                           just recommendations on how to solve a particular
                           problem, which architecture to use, evaluate
                           alternatives, etc.

Productivity booster DT -- The chairs organize a "design team"
                            to get the 10 key people that care
                            about an issue work more efficiently.
                            Weekly conference calls, expectation to
                            produce and review text on a weekly
                            basis is often involved. Typically,
                            the group of dt members is a superset of
                            document authors-editors. These groups
                            tend to be less focused than others,
                            so it is important to keep efficient
                            meetings and make sure decisions are
                            actually made, and communicated as
                            proposals to the WG.

Cross area DT -- Some complex functional area with several RFCs
                  needs coordination and planning for something
                  like security. The only time I was involved in
                  something like this it failed, because it ended
                  up as a fight between the DT and the individual
                  RFC authors on who gets to decide things... but
                  who knows, maybe this could still work in some
                  case.

RFC DT -- A team tasked with the production of an RFC. The work may
           start from zero, or involve some level of merging from
           (incomplete and perhaps overlapping) components already
           provided. It seems kind of hard to tell whether the folks
           working on X are a design team or a set of author-editors.
           I guess the deciding factor is whether the author-editors
           are there because they have always been working on this
           issue, or if the chairs needed to pick a team at some
           point.

In any case, most of the issues related to selected editors
or the WG participants in general apply also to design teams.
Accepting to take on the work load etc.

James commented that DTs sometimes produce design-by-committee
results. I would note that there's a lot of this also in the WG
level. Perhaps the only way to fight that is to have folks that
are willing to listen to others and not insist on getting their
own stuff in as an "option", and folks who care about the beauty
of the end result. And they shouldn't be too polite either, certain
roughness is needed sometimes to get rid of bad stuff.

Jari

---

From: "James V. Luciani" <[email-masked]>
Date: Sat, 21 Dec 2002 10:13:56 -0500

>and there are no good, mature proposals.

Folks managed before DTs were the rage in the IETF.  Now, the chair had to 
be a chair and not an organizer.   But if you sign up for the job you gots 
to pay the price.