Re: 002. Why IETF rules won't work, either

[Terry Allen <tallen@sonic.net>]

Jon wrote:
| 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.

I'm offline right now, but there is a defined process; there are
nominations; and there's an election.  What's not genuinely democratic
about that?

Separately, and probably off topic here, we do need to clarify just
how voting for the OASIS board works (see my earlier confusion about
what's up on the site).

| 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.

The para you quote is about progressing things to IS level.  There
are very few ISs compared with Standards Track RFCs.  You get things
started with a BOF, which requires a minimal documentary basis, 
then construct goals and scenarios (if you're real organized), draft
specs (Internet Drafts) - and you don't have to have an implementation
to write an I-D.

If you do have a well advanced spec (IOTP is an example) you have
a job of education to do when you first bring it to the IETF, but
you can get through the process in good time (IOTP is now an RFC,
after about a year; considering how big it is, that's not bad at
all).

| 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.

I think this is a sidelight; as for our goals, so far all I've
seen is participation by individuals, as in the IETF.

| 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.

No, but I've given up efforts to correct misimpressions of the
IETF process based on the few SGML-related experiences best known
in this community.

|    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.

But look, in the IETF people can join in and participate in WGs
without having had to be appointed by name.  Instead of having to
figure out who's in good standing (a task I dread so much as committee
chair I may refuse it), the chair declares consensus.  It's the IETF
process, not at all Robert's, that fits what we've been doing and
are comfortable with.

I think we can probably use both, if the chair has the authority
to declare consensus and the committee never has to vote (and
therefore never needs a quorum).  IETF or Robert's, we really
need to avoid requiring physical meetings to do work.

regards, Terry