002. Why IETF rules won't work, either

[Jon Bosak <bosak@boethius.eng.sun.com>]

A thought that would naturally occur to one after reading what I've
just said about the impracticality of using something as massive as
Robert's in a multilingual environment is the possibility of using the
IETF process instead.  But I think that there are several things wrong
with this.

1. I've always had a problem with the way that the IETF
   governing bodies (IAB and IESG) are selected; they remind me
   of the Illuminati.  I don't see a genuinely democratic process
   here.  But I suppose we could just substitute the OASIS board
   and/or membership where approval is called for by the IESG, so
   maybe this is not a fundamental problem.

2. What seems to me to be a much more basic problem is stated
   right in rfc2026:

      These procedures are explicitly aimed at recognizing and
      adopting generally-accepted practices.  Thus, a candidate
      specification must be implemented and tested for correct
      operation and interoperability by multiple independent
      parties and utilized in increasingly demanding
      environments, before it can be adopted as an Internet
      Standard.

   The IETF process seems to be designed for things that have
   already been written; it's not so good at how we get to first
   reading in a committee setting.  I submit that a process
   designed to capture and approve already running technologies
   is not optimally designed for the strange and ugly process
   that we know from previous experience in joint DTD
   construction efforts.

3. One of the objectives of the process outline I proposed was
   to have a sphere of activity structured appropriately for
   decisions by groups of individuals and a sphere of activity
   structured appropriately for decisions by a group of
   organizations.  The IETF process seems to have been designed
   primarily for the former.  Under "5.  BEST CURRENT PRACTICE
   (BCP) RFCs" it says:

      While it is recognized that entities such as the IAB and
      IESG are composed of individuals who may participate, as
      individuals, in the technical work of the IETF, it is also
      recognized that the entities themselves have an existence
      as leaders in the community.  As leaders in the Internet
      technical community, these entities should have an outlet
      to propose ideas to stimulate work in a particular area, to
      raise the community's sensitivity to a certain issue, to
      make a statement of architectural principle, or to
      communicate their thoughts on other matters.  The BCP
      subseries creates a smoothly structured way for these
      management entities to insert proposals into the
      consensus-building machinery of the IETF while gauging the
      community's view of that issue.

   Despite the characterization of this mechanism as "smoothly
   structured," it looks to me like a rather badly designed
   afterthought.  Indeed, "5.1 BCP Review Process" concedes that

      Unlike standards-track documents, the mechanisms described
      in BCPs are not well suited to the phased roll-in nature of
      the three stage standards track and instead generally only
      make sense for full and immediate instantiation.

4. This is anectodal but direct: my limited experience with
   attempts to draft language within IETF committees has been
   uniformly negative.  I just don't think that the process is
   well designed to resolve real differences of opinion in a fair
   and orderly way.  It's designed to formalize agreement among
   small groups of technical experts who already largely agree on
   an approach that's already running.  It does not seem to me to
   be well suited to groups of industrial competitors with
   limited technical experience and real axes to grind.

   For all of its faults, Robert's really does know how to
   organize a mob into a deliberative assembly (see sections 52
   and 53 in the current edition, or 69 and 70 in the 1915
   edition).  The organizational model is one designed to start
   with a fractious gang of 1890s San Francisco dockworkers and
   turn them into a functioning civil society.  I don't think
   that this is entirely inappropriate to some of the groups that
   our process will be called upon to organize.

What we need to do, I think, is to start with basic parliamentary
procedure (and I mean really basic, not the endless explanatory prose
of the current Robert's) and grab whatever pieces of technical
committee procedure from the IETF or any other bottom-up model we can
find that look suitable for the construction of technical
specifications from scratch in a group of competitors who are working
by voluntary association.

Jon