Doing the Right Things?

[Keith Moore]

>  Do people think that these are the right things to do?

I think we need to take on a few other things besides:

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)

The reason I say this is that several groups have demonstrated the inability
to define the problem they are working on, and several groups have reached the
Last Call stage while failing to meet some basic requirement (like
authentication) or failing to understand some important negative impact of
their protocols (like the effect of scoped addresses on applications).

By establishing a series of steps that should be undertaken in protocol
design, we should be able to gain confidence much earlier that a protocol
design has taken into account needs that can be anticipated, and in turn, this
should provide confidence that the protocol will ultimately be approved
without significant late changes.

This will be awkward and uncomfortable for people to do at first, but it's the
very basis of engineering.


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.

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.

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.

*****************************************************************************

Problems 1 and 2 are deeply embedded in IETF culture, but they are also
probably the things that most need to change, if we want to improve the
timeliness or quality of IETF's output.  And due to the amount of inertia, it
will be very hard to make small changes work.   The changes will need to
appear to be drastic to overcome that inertia - it will need to _feel
different_ than it does now (and probably different than it ever has) when
you're participating in an IETF WG - whether over the net or at a f2f meeting.

*****************************************************************************


3. We need to see if there are specific kinds of areas or activities that we
need to engage in, for which our WG processes don't work well.

WGs are the IETF version of Maslow's hammer.  Any time we have a problem we
want to form a working group to look at it.  But working groups (and the
assumptions about WG operation that go with them) are not always a 
good way to look at a problem.  Sometimes a different mode of conversation,
or different procedures, or different management structures, are 
appropriate.  

We need to understand the limitations of the WG process and determine whether
there should be exceptions to that process for activities that are not
chartered to develop technical protocol standards. 


4. We need to reorganize our document series.

(this is a problem that I don't think is touched on in the current draft)

Lots of people complain that RFCs are too often used to give things the
appearance of standardization even when they have not been approved for that. 
That is probably true, but it's not what I mean here.

The problem I see here is that we now have so many RFCs that it's too easy for
some important bit of information to get lost.  Sequential numbering was fine
when there were only a couple of thousand RFCs (and when you could ignore
the first several hundred), and many of us had the important RFC numbers 
memorized, but now there are just too many (or maybe I'm getting too old,
but I'm not the only one getting older..)  I see useful work getting unnoticed
because it's buried in some obscure RFC number.

Some SDOs have a numbering scheme that reflects categories, and I think we
might do well to consider such a scheme for IETF documents.  This probably
means abandoning the linear RFC numbering scheme entirely, though it doesn't
mean that we have to stop calling them RFCs.