Subject: engineering discipline WAS: stats from the text conferencing experiment

From: [email-masked]
Date: Tue, 26 Nov 2002 11:22:10 +0200

Hi Margaret & Randy,

> > Actually, I think that hourglass model doesn't work because
> > it is very hard for consensus-based organizations to exercise
> > discipline.  I'm still trying to figure out a way to make
> > engineering discipline seem as enticing as chasing every
> > new (good or bad) idea that comes along.
> > 
> > ...but, that's pretty off-topic. :-)
> 
> imiho, that should be highly on topic for the wgchairs list

I agree.  One suggestion is that endless email discussions be
brought to a conclusion and made into an Internet Draft.  For
example, the current Site Local / PI / GUPPI or whatever it is 
now discussion on the IPv6 mailing list has gotten out of hand,
IMO.  I would like to see folks submit drafts outlining the 
problem, impact & possible solutions (maybe not all in one
draft).  Putting it down in black & white in a draft tends
to help make the good & the bad more apparent.

Long email discussions (again IMO) do nothing to create consensus
nor do they do anything resembling discipline ...

John

---

From: [email-masked]
Date: Tue, 26 Nov 2002 14:55:11 +0200

Hi Margaret,

> I think that everyone knows and agrees that the IPv6 mailing list
> has a strong tendency to get out-of-hand.

By the way, I didn't mean to suggest that you or Bob were the cause of any
of the problems ....

> Practical suggestions
> for how to avoid this, without causing larger problems, are
> appreciated.

Well, one thing that just came to mind would be to get a
neutral document editor to discuss with different folks
(off of the list) and compile some of the ideas, maybe
into some sort of work scoping document.  Again, it could be
me, but I am having trouble sorting out what problem everyone
is trying to solve.  Most likely, several folks are trying to
solve different problems.

> However, I would not agree with the characterization
> that the pre-Atlanta site-local discussion and the current
> GUPI discussion are the same discussion.

Well, the are not the exact same discussion, but they are
playing in the same sandbox, but I could be wrong - I am
having a hard time keeping up.

> For the current topic, I happen to know that a number of drafts
> are underway, in fact Steve Bellovin has already posted one.  We
> also have a couple of drafts available from the multi6 group.

That I think is a good thing.

> I have serious doubts, though, that the emergence of these
> drafts will do anything to slow down the volume of mail on the
> IPv6 list.

What I meant to imply that putting designs, needs, problems
into a draft can help create a self-organizing mechanism.

> The type of discipline I was talking about, though, is not
> mailing list discipline, but engineering discipline.

Actually, I thought that the mailing list discipline is part
of the engineering discipline.  Using IPv6 as the example,
it seems that there is a great deal of speculation as opposed
to engineering going on.

> How can we convince a large group of people to:
>
>          - Minimize design complexity to keep implementation
>                  costs low and reliability high?
>          - Remove features that are not widely implemented
>                  or deployed, instead of arguing that they
>                  should be left in because they _might_ be
>                  useful?
>          - Understand the problem statement, and design the
>                  simplest solution that solves the problem?
>          - Do the work that needs to be done to finish the
>                  base protocol, instead of inventing optional
>                  features or running off and examining every
>                  "interesting problem" that comes along.
>                  [This most often manifests itself in a lack
>                  of interest in writing or reviewing MIBs.]
>
> We've tried, in the past, to force some discipline through
> charters.  However, the way the IETF is organized, there
> is no way for WG chairs to hold the line.

I think that we may need to also assign teams to work on specific
topics, and bring their results to the WG.  For some work topics,
this has been sucessful.  When there are too many cooks ... you
know the rest.

> People who want
> to do unchartered work can:  ask for a BOF, submit the
> work as individual drafts to the RFC editor, bring it
> to the IESG through a different AD, etc.

Also, it might be useful to organize more BOFs on specific
issues which are hard to make progress issues.  The 2nd
IPv6 meeting in Atlanta was nearly a BOF.  It might be
useful to split contentious work off until it is more mature
or at least stable.

> What would really work is if we could foster an environment
> where engineering discipline is one of our core values, and
> where it is "cool" to make decisions that simplify and
> focus our work, rather than our current status where it is
> cool to invent a whole new protocol and/or identify an
> "interesting" problem and pursue it.

I think structuring the work differently might be a possibility.
I think group dynamics tend to lead to some of the problems we
see.

I agree with you, though.  The problems you are seeing are
evident elsewhere.

John