Subject: RE: Doing the Right Things?

From: <[email-masked]>
Date: Mon, 2 Jun 2003 11:03:32 +0300

Hi Keith,

> 1. We need to define the discipline of Internet Protocol Engineering.
> 
> By that, I mean we need to enumerate a series of steps that should
> normally be followed, more or less in order, when developing or modifying a
> protocol for use on the Internet.  It doesn't have to be a long or 
> complicated set of steps, and it doesn't have to be rigid.  The main thing
> is to establish that (for instance) you really do need to understand your
> threat model and choose a security technology *before* you design your
> protocol - or (for instance) the time to identify other parties that
> your protocol might effect and work out compromises about how to minimize
> adverse impact is *before* you do detailed protocol design or tweaking.
> And maybe it would include 'prototyping' as one of the steps to occur
> before standardizing.  (though this doesn't mean that the prototype has
> to implement all features of the standard)

I agree with you on this.  This almost seems like a roadmap.  I think in
the past, charters have served this function, in an informal way, but
I think having a loose, but more formal roadmap (for lack of a better
term) for the work we undertake in the IETF would be a good thing.

> 2. We need to change the methods by which working groups 
> conduct discussions.
> 
> a. Mailing list discussions are often so chaotic and unstructured that
> it's impossible to keep track of what is going on, the volume can be
> overwhelming, it's hard to get a "sense of the room" about where the
> group stands with respect to an issue, and people get so frustrated that they
> resort to personal attacks (or they take the bait when offered...)
> 
> Some groups have imposed some structure on their mailing list discussions,
> with varying degrees of success in raising the signal-to-noise ratio, 
> improving efficiency, and maintaining opennness and high technical quality.
> one thing that might be useful is to survey various groups and see what
> they've done, and get an assessment of how well it worked.
> 
> Maybe we need a "rules of order" for mailing list discussions.  We might also
> consider using other tools - e.g. having meetings via instant messaging, "web
> voting", etc.
> 
> Different working groups might need slightly different mechanisms depending
> on size, diversity of interests, and the variety of levels of 
> expertise.

Agreed.  Also, I think it is the WG chairs' job to be list moderators as well.
That means interveaning before the attacks get personal; summarizing the
discussions; etc.  When the mailing list becomes free-form & unstructured,
I doubt much can come from it.
 
> b. It's been repeatedly observed for several years that face-to-face meeting
> time isn't used effectively - it's often taken up almost entirely by
> presentations of material that could have been read in advance, leaving very
> little time for activities that really do need face-to-face interaction -
> like resolving tricky technical disagreements.  Persistent instructions from
> various ADs to WGs have had little effect.
> 
> Powerpoint-style presentations (not that it really matters which tool is used)
> tend to lull people into passivity, if not sleep.  Video projectors can be
> great for high quality drawings, or very occasionally, animations to
> illustrate how something works - but using them to put up words (with fancy
> backgrounds) that are just repeated by the speaker is to make a really
> ineffective use of high-bandwidth meeting time.
> 
> We need to understand why we are stuck in these ineffective modes, identify 
> changes that could get us out of this mode, and implement them for all
> working groups.  Even the way the room is arranged can make a difference in
> the effectiveness of a discussion, but right now it's impossible to get the
> room set up in anything other than theatre style seating which puts people
> to sleep.  Having lots of people in the room who aren't participating or even
> listening also has an undesirable effect.
> 
> Maybe we need to ban laptops in the rooms.  Maybe we need to have separate
> orientation sessions for newcomers to the WG so that they don't use the
> normal meeting time getting up to speed.  Maybe we need to require 
> participants to pass a basic competency test before entering the meeting room.
> Maybe we need to get rid of video projectors and put up whiteboards.

How about better time management; better meeting management, etc? Stronger
leadership is needed & perhaps a stronger requirement for getting a WG
slot at an IETF meeting is needed.  The transport area is fairly strict
about IETF meeting time, by the way.

One real-life problem that I have in my working group is that we are coming
to the point where we need to start some protocol work.  I know there will
be a land-grab, where many people try to bring forward proposals.  In past
IETFs, I've noticed having 5 presentations on the same topic (but different
individual drafts) tend to be mind-numbing.  I've been toying with the idea
of having a group discussing (almost a roundtable) where the different
parties interested in the protocol work get together and have a common
discussion time at the IETF up front - highlighting similarities & differences
between the proposals & general open issues.

> I suggest that the WG identify what kinds of things need to take place in
> face-to-face meetings; that these things be given priority on meeting
> agendas, that ADs check the agendas to ensure that the WG is planning
> to use meeting time appropriately.  Also we should not assume that
> face-to-face meetings have to be narrowly focused on the WG; face-to-face
> meetings can also be good times to resolve differences with other WGs or other
> interests that aren't represented by WGs.

I definately agree.   

John

---

From: "Jeanette Hofmann" <[email-masked]>
Date: Mon, 02 Jun 2003 14:27:14 +0200

> I doubt much can come from it.

Do you think that all working groups should appoint a moderator? 
> > We need to understand why we are stuck in these ineffective modes,

Judging from the improvements you and Keith suggest, the answer seems to 
be simple: making effective use of face-to-face meeting time means more 
preparatory work. 

Jeanette 

 identify

---

From: Keith Moore <[email-masked]>
Date: Mon, 2 Jun 2003 11:09:52 -0400

> > normally be followed, more or less in order, when developing or
> > modifying a protocol for use on the Internet.  It doesn't have to be
> > a long or complicated set of steps, and it doesn't have to be rigid.
> >  The main thing
> > is to establish that (for instance) you really do need to understand
> > your threat model and choose a security technology *before* you
> > design your protocol - or (for instance) the time to identify other
> > parties that your protocol might effect and work out compromises
> > about how to minimize adverse impact is *before* you do detailed
> > protocol design or tweaking. And maybe it would include
> > 'prototyping' as one of the steps to occur before standardizing. 
> > (though this doesn't mean that the prototype has to implement all
> > features of the standard)
> 
> I agree with you on this.  This almost seems like a roadmap.  I think
> in the past, charters have served this function, in an informal way,
> but I think having a loose, but more formal roadmap (for lack of a
> better term) for the work we undertake in the IETF would be a good
> thing.

note also that this 'roadmap' is independent of working group processes
- that is, it doesn't matter whether the engineering is being done
by a working group or a group of individuals or a single person -
these are steps you need to follow regardless.  so while the roadmap
might end up imposing some guidelines or constraints for WG operation,
it shoudn't be thought of strictly in terms of WG operation.