[tcpm] TCPM

[Mark Allman <[e-mail]>]

Folks-

I have mostly been lurking lately, but I have read a few of these
process-y notes recently and have shortened my life with far too many
inane TCPM threads over the years.  It is clear some people are
frustrated.  However, I do not agree that this frustration should be
pointed at the chairs or ADs (I wore one of those hats for some of the
ongoing work, so I am not unbiased, but...).  It seems to me there is
frustration from a bunch of angles here---and that people are not
considering the full scope.  It seems to me there is frustration:

  - ...that some people are viewed as being overly pedantic.  I
    believe this is true.

  - ...that some people place too much emphasis on 'running code'
    and not enough on technical principles.  I believe this is
    true. 

  - ...that some people place too much emphasis on technical
    principles and not enough on 'running code'.  I believe this is
    true.

  - ...that a not insignificant portion of the documents brought to
    the working group and adopted by the working group are poorly
    written (regardless of the technical merit).  I believe this is
    true.

  - ...that discussion is sometimes circular with the same comments
    being made over-and-over.  I believe this is true.

  - ...that technical comments are not responded to with technical
    counter-arguments.  I believe this is true.

  - ...that sometimes WG decisions are not as clearly stated as they
    could be.  I believe this is true.

  - ...that TCP is overly hard to change.  I believe this is true.

  - ...that TCP should not be changed unless the Internet would melt
    otherwise.  I believe this is true.

I believe all of these things can be frustrating.  I can very much
sympathize with frustration from all sides.

(Note: I take my share of the blame for each of these.)      

I have a series of suggestions that I think would perhaps provide a
better and more timely set of work in this WG.  The first set is for
the members and the second set is for the chairs:

(M.1) Try to rate limit yourself.  Send one message / day (say) on each
      draft.  If the point you want to make doesn't seem big enough
      to blow your one message on then just forget it.  Or, send it
      off-list.

(M.2) Label your comments explicitly as "nit" or "small annoyance"
      or "major technical bone of contention" or some such.  I.e., clue
      the reader in to how serious you think a document failure is.
      And, then, stick to your classification.  There is no use having a
      knock-down, drag-out fight over a universally agreed small issue.

(M.3) Try to not be so damned pedantic.  We all have pet-peeves and
      things we consider "wrong", but in the grand scheme of things
      don't matter one whit.  I cannot stress this enough: if you are
      arguing about a two word phrase you are **off the effin' rails**.
      The pedanticness causes myriad problems: from just being overall a
      no-op on the document to making people tune threads out to making
      people tune out the entire WG to making people less likely to
      enter a discussion because of the cost:benefit being tilted far
      too much towards "cost".  Messages sent to the list have an impact
      on the overall environment and the WG's ability to do business.
      This impact can be greater than whatever particular point you are
      trying to convey.

(M.4) When a technical point is made, try to answer it with a
      technical point.  There is often an impedance mis-match on
      this list that leads to loops.  E.g., "technical principle [X]
      suggests we should not do [Y]" followed by "but [Y] is done in
      OSes A, B and C".  These two statements are just talking past
      each other and so both points remain unaddressed.  Running
      code is a useful data point and can be suggestive of how
      something will work.  But, all running code (and in particular
      any number of tweaks to TCP) is not a good idea.  We have a
      long RFC on problems with TCP implementations [RFC2525].

      Remember: Just because something is used doesn't make it a
      good idea.

      Remember: Having something implemented and running offers a
      valid data point that is not for nothing.

I.e., play nicer.  

But, since I don't really expect you to do so I have some
suggestions for the chairs:

(C.1) Drum up some document editors.  One of the issues is that the
      pens are in the hands of pedantic partisans.  This does not
      help the WG get its work done because one of the strong
      principals in the discussion also holds the ability to write
      the final words.  This means that they can prevent some words
      from being penned and also that it clouds their thinking about
      the words they do write (that they may not agree with).  

      For each controversial document (which should be determinable
      from the pre-adoption discussion) find someone who (a) is not
      hardened on one side or the other and (b) knows how to
      actually write quality documents to do the bulk of the
      writing.  That doesn't mean the technical originators don't
      get their authorship.  It adds someone to the process who can
      more easily word a compromise and assert that while it didn't
      make everyone perfectly happy that in the absence of much WG
      disagreement the particular language is staying.

      Note: I am not suggesting someone come in to take over the
      technical development of the document.  I am suggesting
      someone come in who can put together *the document* that the
      **WG** develops without having a particularly hardened opinion
      of the technology.
      
      (This more applies to the extensions and not the
      maintenance---the latter being much less controversial in
      general.) 

(C.2) The decision about accepting work items and using a particular
      document as the starting point are often conflated.  These are
      separate decisions and obviously there has been confusion on this
      point in some cases.  The questions should be posed independently.
      "Should we take on a work item to developed a TCP extension to do
      [foo]?" and given that the answer is "yes" then we can ask "should
      we use [draft-bar] as the basis or work up something new?".  In
      conjunction with naming an independent editor this should make the
      process much more clear.

(C.3) Put big decisions in explicit emails---not at the end of long
      threads.  I.e., use a subject like "TCPM DECISION: draft-foobar"
      and then in that email you can write "passwd WGLC", "decided to
      target status Proposed Standard", "named Bob Smith as document
      editor", etc.  This will help people who might have lost interest
      in a long and winding pedantic thread understand what happened.
      It will also explicitly call attention to a decision point (which
      of course can be challenged).

(C.4) In the WG status (which is a fabulous tool and David and Wes
      should be thanked for starting it) particular decisions can be
      referenced.  E.g., "Target: PS (per email: http//....)".

(C.5) When there is a particular point of disagreement it could be
      framed in a new thread and posed to the group by the chairs.
      "Alice & Bob have reached an impasse.  We're looking for input as
      to whether we should go with [foo] or [bar]." (with sketches of
      the approaches).  This may get more voices in the process than
      figuring out this impasse at the end of a long and messy thread. 

In sum, the WG is what we make it.  I believe there are some fairly
easy things we can each do.  But, at this point I think possibly the
most important thing we could do would be to put the pens in the
hands of people who are a bit outside the fray.

FWIW.

allman