Re: [wg-d] WG Principles

["Mark C. Langston" <skritch@home.com>]

Although Kent seems to be either ignoring or filtering me, here's my
feedback on these:


On 4 August 1999, Kent Crispin <kent@songbird.com> wrote:

>Spent some leisure time on a plane today.  Here's a rough cut at adapting 
>IETF  WG processes to the DNSO.
>
>[This material is shamelessly hacked from RFC2418.  If we decide to 
>use any of this, the matter of the ISOC copyright will have to be 
>addressed.] 
>
>1. Introduction
>
>The General Assembly (GA) of the DNSO is a large, open community of
>individuals concerned with the Internet and the technology used on
>it.  The primary activities of the GA are performed by committees
>known as working groups (WGs).  Working groups tend to have a narrow
>focus and a lifetime bounded by the completion of a specific set of
>tasks, although there are exceptions. 
>
>The GA working groups are managed by the Names Council (NC) of the
>DNSO.  The NC is elected from the DNSO constituencies, as described
>in the ICANN bylaws. 

"managed" might not be the right term here.


>
>[Description of the NC]
>
>The NC approves DNSO Policy Recommendations, and forwards them to the
>ICANN board for action. 

The origin of the Policy Recommendations, i.e., the WGs, should be
explicit.


>
>A small DNSO Secretariat provides staff and administrative support
>for the operation of the DNSO. 
>
>There is no formal membership in the DNSO.  Participation is open to
>all.  This participation may be by on-line contribution, attendance
>at face-to-face sessions, or both.  Anyone from the Internet
>community who has the time and interest is urged to participate in GA
>meetings and any of its on-line working group discussions. 
>Participation is by individual contributors, rather than by formal
>representatives of organizations. 
>

Except in WGs, as outlined in ICANN bylaws, namely:  WGs must consist
of one elected representative from each constituency.

>This document defines procedures and guidelines for the formation and
>operation of working groups in the DNSO.  It defines the relations of
>working groups to other bodies within the DNSO.  The duties of
>working group Chairs and the NC with respect to the operation of the
>working group are also defined.  When used in this document the key
>words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
>interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
>of these key words to help make the intent of standards track
>documents as clear as possible.  The same key words are used in this
>document to help smooth WG operation and reduce the chance for
>confusion about the processes. 
>
>
>2. Working group formation
>
>DNSO working groups are the primary mechanism for development of DNSO
>policies recommendations.  A working group may be established at the
>initiative of the Names Council, or it may be initiated by an
>individual or group of individuals.  Anyone interested in creating an
>DNSO working group MUST obtain the advice and consent of the Names
>Council and MUST proceed through the formal steps detailed in this
>section. 

Doesn't this give ultimate control over the creation of WGs to the NC?
Since the DNSO must approve WG recommendations anyway, I don't see why
this is necessary.

>
>Working groups are typically created to address a specific problem or
>to produce one or more specific deliverables.  Working groups are
>generally expected to be short-lived in nature.  Upon completion of
>its goals and achievement of its objectives, the working group is
>terminated.  A working group may also be terminated for other reasons
>(see section 4).  Alternatively, with the concurrence of the NC, the
>WG Chair, and the WG participants, the objectives or assignment of
>the working group may be extended by modifying the working group's
>charter through a rechartering process (see section 5). 
>
>2.1. Criteria for formation
>
>When determining whether it is appropriate to create a working group,
>the Names Council will consider several issues:
>
>    - Are the issues that the working group plans to address clear and
>      relevant to the Internet community?
>
>    - Are the goals specific and reasonably achievable, and achievable
>      within a reasonable time frame?
>

These so far are subjective.  One could easily argue that these are
common-sensical and always followed.  One could also point to WG-C
as a counterexample to this argument.


>    - What are the risks and urgency of the work, to determine the level
>      of effort required?
>
>    - Do the working group's activities overlap with those of another
>      working group?  If so, it may still be appropriate to create the
>      working group, but this question must be considered carefully by
>      the NC as subdividing efforts often dilutes the
>      available expertise.
>
>    - Is there sufficient interest within the DNSO in the working
>      group's topic with enough people willing to expend the effort to
>      produce the desired result?

Shouldn't the DNSO, via the GA, be the determiner of this?

>      Working groups require considerable effort, including management
>      of the working group process, editing of working group documents,
>      and contributing to the document text.  IETF experience suggests
>      that these roles typically cannot all be handled by one person; a
>      minimum of four or five active participants in the management
>      positions are typically required in addition to a minimum of one
>      or two dozen people that will attend the working group meetings
>      and contribute on the mailing list.  NOTE: The interest must be
>      broad enough that a working group would not be seen as merely the
>      activity of a single interested organization.
>
>    - Is there enough expertise within the DNSO in the working group's
>      topic, and are those people interested in contributing in the
>      working group?
>
>    - Does a base of interested consumers (end-users) appear to exist
>      for the planned work?  Consumer interest can be measured by
>      participation of end-users within the DNSO process, as well as by
>      less direct means.

I don't see the point of this.  WG's do not create product; they 
recommend policy.


>
>    - Does the DNSO have a reasonable role to play in the determination
>      of the policy?  
>
>    - Are all known intellectual property rights relevant to the
>      proposed working group's efforts issues understood?
>

Is the NC to retain the services of one or more TM/IP lawyers?  I 
don't see how anyone can be held to this.


>    - Is the proposed work plan an open effort?
>

"Open" needs to be defined.

>    - Is there a good understanding of any existing work that is
>      relevant to the topics that the proposed working group is to
>      pursue?  This includes work within the DNSO and elsewhere.
>

Understanding by whom?  The NC, the DNSO, the GA?

>    - Do the working group's goals overlap with known work in another
>      standards or policy body, and if so is adequate liaison in place?
>

Current or past standards or policy bodies?  WG-C is an example where
the work overlaps past bodies.

>Considering the above criteria, the Names Council, using its best
>judgement, will decide whether to pursue the formation of the group
>through the chartering process.

Again, the NC shouldn't necessarily be the final arbiter in the creation
of all WGs, as I mention above.  
 
>
>2.2. Charter
>
>The formation of a working group requires a charter which is
>negotiated between a prospective working group Chair and the Names
>Council, possibly with advice from other bodies of the DNSO and
>ICANN.  A charter is a contract between a working group and the DNSO
>to perform a set of tasks.  A charter:
>

This requirement I don't like, because I still believe the WG should
be allowed to elect its own Chair or chairs.  The organizers of the WG
(be it the GA, an individual, or the NC) should determine the Charter.

However, proceeding with an eye to charter formation:

>   1. Lists relevant administrative information for the working group;
>
>
>   2. Specifies the direction or objectives of the working group and
>      describes the approach that will be taken to achieve the goals;
>      and
>
>   3. Enumerates a set of milestones together with time frames for their
>      completion.
>

These are good.

>When the prospective Chair(s), the NC and the DNSO Secretariat are
>satisfied with the charter form and content, it becomes the basis for
>forming a working group.  Note that the NC MAY require holding an
>exploratory Birds of a Feather (BOF) meeting, as described below, to
>gage the level of support for a working group before approving the
>charter. 

Again, the NC should not be sole arbiter in the WG formation process.



>
>Charters may be renegotiated periodically to reflect the current
>status, organization or goals of the working group (see section 5). 
>Hence, a charter is a contract between the DNSO and the working group
>which is committing to meet explicit milestones and delivering
>specific "products". 
>
>Specifically, each charter consists of the following sections:
>
>   Working group name
>
>      A working group name should be reasonably descriptive or
>      identifiable. Additionally, the group shall define an acronym
>      (maximum 8 printable ASCII characters) to reference the group in
>      the DNSO directories, mailing lists, and general documents.
>
>   Chair(s)
>
>      The working group may have one or more Chairs to perform the
>      administrative functions of the group. The email address(es) of
>      the Chair(s) shall be included.  Generally, a working group is
>      limited to two chairs.
>
>   Names Council Liason
>
>      A NC member who acts as the primary NC contact for the
>      working group.

I like this idea, and have supported it in the past.
Could we agree that this would negate the need for the NC to appoint
chairs?

>
>   Mailing list
>
>      An DNSO working group MUST have a general Internet mailing list.
>      Most of the work of an DNSO working group will be conducted on the
>      mailing list. The working group charter MUST include:
>
>      1. The address to which a participant sends a subscription request
>         and the procedures to follow when subscribing,
>
>      2. The address to which a participant sends submissions and
>         special procedures, if any, and
>
>      3. The location of the mailing list archive. A message archive
>         MUST be maintained in a public place which can be accessed via
>         FTP or via the web.
>
>         As a service to the community, the DNSO Secretariat operates a
>         mailing list archive for working group mailing lists. In order
>         to take advantage of this service, working group mailing lists
>         MUST include the address "wg_acronym-archive@lists.DNSO.org"
>         (where "wg_acronym" is the working group acronym) in the
>         mailing list in order that a copy of all mailing list messages
>         be recorded in the Secretariat's archive.  Those archives are
>         located at ftp://ftp.DNSO.org/DNSO-mail-archive.  For
>         robustness, WGs SHOULD maintain an additional archive separate
>         from that maintained by the Secretariat.
>
>   Description of working group
>
>      The focus and intent of the group shall be set forth briefly. By
>      reading this section alone, an individual should be able to decide
>      whether this group is relevant to their own work. The first
>      paragraph must give a brief summary of the problem area, basis,
>      goal(s) and approach(es) planned for the working group.  This
>      paragraph can be used as an overview of the working group's
>      effort.
>
>   Goals and milestones
>
>      The working group charter MUST establish a timetable for specific
>      work items.  While this may be renegotiated over time, the list of
>      milestones and dates facilitates the Area Director's tracking of

We don't have Area Directors.

>      working group progress and status, and it is indispensable to
>      potential participants identifying the critical moments for input.
>      Milestones shall consist of deliverables that can be qualified as
>      showing specific achievement; e.g., "Draft Policy finished" is
>      fine, but "discuss via email" is not. It is helpful to specify
>      milestones for every 3-6 months, so that progress can be gauged
>      easily.  This milestone list is expected to be updated
>      periodically (see section 5).
>

Perhaps earlier in the document you should give an example of the
typical lifespan of a WG.  3-6 month WGs are far longer than current
ICANN behavior would indicate.


>      An example of a WG charter is included as Appendix A.
>
>2.3. Charter review & approval
>
>Proposed working groups often comprise competent participants who are
>not familiar with the history of Internet architecture or DNSO
>processes.  This can, unfortunately, lead to good working group
>consensus about a bad policy.  To facilitate working group efforts,
>the NC may assign a Consultant from among the ranks of senior DNSO
>participants.  (Consultants are described in section 6.) At the
>discretion of the NC, approval of a new WG may be withheld in the
>absence of sufficient consultant resources. 
>

I don't like this.  It gives even more power over WGs to the NC, and
it also allows the NC to "stuff" a WG.

>Once the NC has granted preliminary approval for the working group
>charter, the charter is submitted for review by the General Assembly. 
>The proposed charter will be posted to the DNSO-announce mailing list
>as a public notice that the formation of the working group is being
>considered.  At the same time the proposed charter is also posted to
>the "new-work" mailing list.  This mailing list has been created to
>let qualified representatives from other organizations know

What "other organizations" and "qualified representatives" in whose
opinion?


>about pending DNSO working groups.  After a review period lasting at
>least a week the NC MAY approve the charter as-is, it MAY request
>that changes be made in the charter, or MAY decline to approve
>chartering of the working group
>

How is the GA opinion considered with respect to this process?

>If the NC approves the formation of the working group it remands the
>approved charter to the DNSO Secretariat who records and enters the
>information into the DNSO tracking database.  The working group is
>announced to the DNSO-announce by the DNSO Secretariat. 
>

Should it not also be announced to the GA list?

>2.4. Birds of a Feather (BOF)
>
>Often it is not clear whether an issue merits the formation of a
>working group.  To facilitate exploration of the issues the DNSO
>offers the possibility of a Birds of a Feather (BOF) session, as well
>as the early formation of an email list for preliminary discussion. 
>In addition, a BOF may serve as a forum for a single presentation or
>discussion, without any intent to form a working group. 
>
>A BOF is a session at a physical DNSO meeting which permits "market
>research" and technical "brainstorming".  Any individual may request
>permission to hold a BOF on a subject.  The request MUST be filed
>with the NC who must approve a BOF before it can be scheduled.  The
>person who requests the BOF may be asked to serve as Chair of the
>BOF. 

NO.  If the BOF is to be part of the formal WG process, it must not
be restricted to physical meetings.  Period.  It's exlusionary.


>
>The Chair of the BOF is also responsible for providing a report on
>the outcome of the BOF.  If the Area Director approves, the BOF is

We have no Area Directors.


>then scheduled by submitting a request to agenda@DNSO.org with copies
>to the NC.  A BOF description and agenda are required before a BOF
>can be scheduled. 
>
>Available time for BOFs is limited, and BOFs are held at the
>discretion of the NC.  The NC may require additional assurances
>before authorizing a BOF.  For example,
>

Why must BOFs be approved by the NC?  most other professional 
organizations I'm familiar with allow BOFs to self-organize.


>- The NC MAY require the establishment of an open email list prior to
>authorizing a BOF.  This permits initial exchanges and sharing of
>framework, vocabulary and approaches, in order to make the time spent
>in the BOF more productive. 
>
>- The NC MAY require that a BOF be held, prior to establishing a
>working group (see section 2.2). 
>

Again, no.  It's exlusionary as long as it requires physical
participation.

>- The NC MAY require that there be a draft of the WG charter prior to
>holding a BOF. 
>
>- The NC MAY require that a BOF not be held until an Internet-Draft
>describing the proposed technology has been published so it can be
>used as a basis for discussion in the BOF. 
>

Again, why must the NC have final say over the existence of a BOF?

[snip rest of BOF talk, as I think this is not useful at all in 
current form]

>
>3.  Working Group Operation
>
>The DNSO has basic requirements for open and fair participation and
>for thorough consideration of  alternatives.  Within those
>constraints, working groups are autonomous and each determines most
>of the details of its own operation with respect to session
>participation, reaching closure, etc.  The core rule for operation is
>that acceptance or agreement is achieved via working group "rough
>consensus".  WG participants should specifically note the
>requirements for disclosure of conflicts of interest in [2]. 
>

No.  Rough consensus has been shown to be contentious, "fuzzy", and
vague.  Formal voting would be a much better approach, and is in
fact the method in use currently in DNSO WGs for all matters of 
concern and substance (e.g., elections).  

>A number of procedural questions and issues will arise over time, and
>it is the function of the Working Group Chair(s) to manage the group
>process, keeping in mind that the overall purpose of the group is to

This is too vague.  The Chair responsibilities need to be explicit.

>make progress towards reaching rough consensus in realizing the
>working group's goals and objectives. 
>
>There are few hard and fast rules on organizing or conducting working
>group activities, but a set of guidelines and practices has evolved
>over time that have proven successful.  These are listed here, with

They have been proven successful in a restricted environment for 
certain types of topics, with relatively small numbers of highly
technical participants working towards the same goal.

>actual choices typically determined by the working group participants
>and the Chair(s). 
>
>3.1. Session planning (mainly for physical meetings)
>
>For coordinated, structured WG interactions, the Chair(s) MUST
>publish a draft agenda well in advance of the actual session.  The
>agenda should contain at least:
>
>   - The items for discussion;
>
>   - The estimated time necessary per item; and
>
>   - A clear indication of what documents the participants will need to
>     read before the session in order to be well prepared.
>
>Publication of the working group agenda shall include sending a copy
>of the agenda to the working group mailing list and to
>agenda@DNSO.org. 
>
>All working group actions shall be taken in a public forum, and wide
>participation is encouraged.  A working group will conduct much of
>its business via electronic mail distribution lists but may meet
>periodically to discuss and review task status and progress, to
>resolve specific issues and to direct future activities.

No decisions can be made, nor consensus reached, if all interested
parties are not involved.  This allows once again for selective
exclusion.

>  DNSO
>Plenary meetings are the primary venue for these face-to-face working
>group sessions, and it is common (though not required) that active
>"interim" face-to-face meetings, telephone conferences, or video
>conferences may also be held.  Interim meetings are subject to the
>same rules for advance notification, reporting, open participation,
>and process, which apply to other working group meetings. 
>

If they are "open" (a term not defined yet in this document) then
they must include all who wish to participate in the process.  Physical
meetings with no facilities for remote participation are not, in this
sense, "open".


>All working group sessions (including those held outside of the DNSO
>meetings) shall be reported by making minutes available.  These
>minutes should include the agenda for the session, an account of the
>discussion including any decisions made, and a list of attendees. 
>The Working Group Chair is responsible for insuring that session
>minutes are written and distributed, though the actual task may be
>performed by someone designated by the Working Group Chair.  The
>minutes shall be submitted in printable ASCII text for publication in
>the DNSO Proceedings, and for posting in the DNSO Directories and are
>to be sent to: minutes@DNSO.org
>
>3.2. Session venue
>
>Each working group will determine the balance of email and face-to-
>face sessions that is appropriate for achieving its milestones. 
>Electronic mail permits the widest participation; face-to-face
>meetings often permit better focus and therefore can be more
>efficient for reaching a consensus among a core of the working group
>participants.  

I.e., they are exclusionary.

>In determining the balance, the WG must ensure that
>its process does not serve to exclude contribution by email-only
>participants.  

There are chairs of existing WGs who have been caught filtering out
all communications from certain WG participants.  

>Decisions reached during a face-to-face meeting about
>topics or issues which have not been discussed on the mailing list,
>or are significantly different from previously arrived mailing list
>consensus MUST be reviewed on the mailing list. 

They must not only be reviewed, but must be accepted or rejected by
the mailing list.  Decisions cannot be made behind closed doors 
(even when the closed door is just the elimination of certain 
participants by requiring f2f meetings.)

>
>DNSO Meetings
>
>If a WG needs a session at an DNSO meeting, the Chair must apply for
>time-slots as soon as the first announcement of that DNSO meeting is
>made by the DNSO Secretariat to the WG-chairs list.  Session time is
>a scarce resource at DNSO meetings, so placing requests early will
>facilitate schedule coordination for WGs requiring the same set of
>experts. 
>
>The application for a WG session at an DNSO meeting MUST be made to
>the DNSO Secretariat at the address agenda@DNSO.org.  If this is the
>case it will be noted in the DNSO meeting announcement.  A WG
>scheduling request MUST contain:
>
>   - The working group name and full title;
>
>   - The amount of time requested;
>
>   - The rough outline of the WG agenda that is expected to be covered;
>
>   - The estimated number of people that will attend the WG session;
>
>   - Related WGs that should not be scheduled for the same time slot(s);
>     and
>
>   - Optionally a request can be added for the WG session to be
>     transmitted over the Internet in audio and video.

It should not be optional.  Real-time participation by all interested
parties should be required.


>
>NOTE: While open discussion and contribution is essential to working
>group success, the Chair is responsible for ensuring forward
>progress.  When acceptable to the WG, the Chair may call for
>restricted participation (but not restricted attendance!) at DNSO

No.  Particularly not when the NC is appointing chairs.  We already
have a chair who has explicitly stated for the record that they think
individual contributions are worthless and should be ignored.


>working group sessions for the purpose of achieving progress.  The
>Working Group Chair then has the authority to refuse to grant the
>floor to any individual who is unprepared or otherwise covering
>inappropriate material, or who, in the opinion of the Chair is
>disrupting the WG process.  

Again, no.  This allows the NC too much power, and allows the NC to
shape policy in the face of, and to spite, WG input.  See WG-A for
an example of this.

>The Chair should consult with the Area
>Director(s) if the individual persists in disruptive behavior. 
>

We have no Area Directors.

>On-line
>
>It can be quite useful to conduct email exchanges in the same manner
>as a face-to-face session, with published schedule and agenda, as
>well as on-going summarization and consensus polling. 
>

This is the first time polling has been mentioned.  Once again, I
say we avoid the vague term "consensus" and require some form of
formal voting procedure.

>Many working group participants hold that mailing list discussion is
>the best place to consider and resolve issues and make decisions. 
>The choice of operational style is made by the working group itself. 

The choice of operational style MUST include all interested parties.
Allowing this provides the WG with means to exclude participants.

>It is important to note, however, that Internet email discussion is
>possible for a much wider base of interested persons than is
>attendance at DNSO meetings, due to the time and expense required to
>attend. 

Exactly.

>
>As with face-to-face sessions occasionally one or more individuals
>may engage in behavior on a mailing list which disrupts the WG's
>progress.

"disrupt" must be defined.

  In these cases the Chair should attempt to discourage the
>behavior by communication directly with the offending individual
>rather than on the open mailing list.  If the behavior persists then
>the Chair must involve the NC in the issue.  As a last resort and
>after explicit warnings, the NC, may request that the mailing list
>maintainer block the ability of the offending individual to post to
>the mailing list.  (If the mailing list software permits this type of
>operation.) Even if this is done, the individual must not be
>prevented from receiving messages posted to the list.  Other methods
>of mailing list control may be considered but must be approved by the
>NC. 

Again, we're placing more and more power into the hands of the NC.
The NC is a tool of, and not the lord over, the GA.  The NC should not
be allowed to have this kind of power over the voice of the GA, which
includes members who are not allowed representation on the NC, and thus
may be excluded by political maneuvering within these rules by the NC.

>
>3.3. Session management
>
>Working groups make decisions through a "rough consensus" process. 

No.  Formal voting.

>DNSO consensus does not require that all participants agree although
>this is, of course, preferred.  In general, the dominant view of the
>working group shall prevail.  (However, it must be noted that
>"dominance" is not to be determined on the basis of volume or
>persistence, but rather a more general sense of agreement.) Consensus
>can be determined by a show of hands, humming, or any other means on
>which the WG agrees (by rough consensus, of course).  Note that 51%
>of the working group does not qualify as "rough consensus" and 99% is
>better than rough.  It is up to the Chair to determine if rough
>consensus has been reached. 

When the WG consists of parties who stand to directly gain or lose
financially based on decisions made in the WG, as has been the case
so far in WGs A and C, such a method will not satisfy.  Formal 
voting should be used.  If for no other reason, those making 
decisions should be put in a position to be held accountable for 
their decisions, and not be allowed to hide behind the "fuzz"
of this vague term "consensus" which you non-define above.

>
>It can be particularly challenging to gauge the level of consensus on
>a mailing list.  There are two different cases where a working group
>may be trying to understand the level of consensus via a mailing list
>discussion.  But in both cases the volume of messages on a topic is
>not, by itself, a good indicator of consensus since one or two
>individuals may be generating much of the traffic. 

If it's so difficult, why not use a simple, proven method of
determining opinion:  formal voting procedures.


>
>In the case where a consensus which has been reached during a face-
>to-face meeting is being verified on a mailing list the people who
>were in the meeting and expressed agreement must be taken into
>account.  If there were 100 people in a meeting and only a few people
>on the mailing list disagree with the consensus of the meeting then
>the consensus should be seen as being verified.

Not if the f2f meeting was held knowing that the dissenters wouldn't
or couldn't attend.

>  Note that enough
>time should be given to the verification process for the mailing list
>readers to understand and consider any objections that may be raised
>on the list.  The normal two week last-call period should be
>sufficient for this. 
>

You've yet to define last-call, and your cut-and-paste effort from
IETF procedure is showing.

>The other case is where the discussion has been held entirely over
>the mailing list.  The determination of the level of consensus may be
>harder to do in this case since most people subscribed to mailing
>lists do not actively participate in discussions on the list.  It is
>left to the discretion of the working group chair how to evaluate the
>level of consensus. 

Again, no, particularly not when the NC is appointing chairs.  Formal
voting procedures would work best here.

> The most common method used is for the working
>group chair to state what he or she believes to be the consensus view
>and.  at the same time, requests comments from the list about the
>stated conclusion. 


No.  We cannot, we must not, operate on a "silence=consensus" policy.
This allows the chair to push his favored view forward, and this
has already been evidenced in at least WG-C.

>
>The challenge to managing working group sessions is to balance the
>need for open and fair consideration of the issues against the need
>to make forward progress.  The working group, as a whole, has the
>final responsibility for striking this balance.  The Chair has the
>responsibility for overseeing the process but may delegate direct
>process management to a formally-designated Facilitator. 
>
>It is occasionally appropriate to revisit a topic, to re-evaluate
>alternatives or to improve the group's understanding of a relevant
>decision.  However, unnecessary repeated discussions on issues can be
>avoided if the Chair makes sure that the main arguments in the
>discussion (and the outcome) are summarized and archived after a
>discussion has come to conclusion.  It is also good practice to note
>important decisions/consensus reached by email in the minutes of the
>next 'live' session, and to summarize briefly the decision-making
>history in the final documents the WG produces. 
>

This again shows the cut-and-paste job from the IETF documents, and
assumes that a good deal of work will be done in f2f environments.
It will not.


>To facilitate making forward progress, a Working Group Chair may wish
>to decide to reject or defer the input from a member, based upon the
>following criteria:
>
>   Old
>   The input pertains to a topic that already has been resolved and is
>   redundant with information previously available;
>

In the Chair's opinion.  The chair is appointed by the NC.  This gives
the NC power over the decisions made in the WG.

>   Minor
>   The input is new and pertains to a topic that has already been
>   resolved, but it is felt to be of minor import to the existing
>   decision;

In the Chair's opinion.  The chair is appointed by the NC.  This gives
the NC power over the decisions made in the WG.


>
>   Timing
>   The input pertains to a topic that the working group has not yet
>   opened for discussion; or

In the Chair's opinion.  The chair is appointed by the NC.  This gives
the NC power over the decisions made in the WG.


>
>   Scope
>   The input is outside of the scope of the working group charter.

In the Chair's opinion.  The chair is appointed by the NC.  This gives
the NC power over the decisions made in the WG.


>
>3.4. Contention and appeals
>
>Disputes are possible at various stages during the DNSO process.  As
>much as possible the process is designed so that compromises can be
>made, and genuine consensus achieved; however, there are times when

You've yet to define consensus.  Formal voting procedures should be
used.

>even the most reasonable and knowledgeable people are unable to
>agree.  To achieve the goals of openness and fairness, such conflicts
>must be resolved by a process of open review and discussion. 
>
>Formal procedures for requesting a review of WG, Chair, or actions
>and conducting appeals are documented in XXX
>

XXX?

>
>4. Working Group Termination
>
>Working groups are typically chartered to accomplish a specific task
>or tasks.  After the tasks are complete, the group will be disbanded. 
>However, it may be the case that the WG will become dormant rather
>than disband (i.e., the WG will no longer conduct formal activities,
>but the mailing list will remain available to review the policy
>proposal as it moves through the ICANN processes.)
>
>If, at some point, it becomes evident that a working group is unable
>to complete the work outlined in the charter, or if the assumptions
>which that work was based have been modified in discussion or by
>experience, the NC, in consultation with the working group can
>either:
>
>   1. Recharter to refocus its tasks,
>

The WG should be able to recharter itself, or at least to redefine its
own goals.


>   2. Choose new Chair(s), or
>

The WG should also be able to do this without the NC's approval,
particularly when the NC is appointing WG chairs.

>   3. Disband.
>
>5. Rechartering a Working Group
>
>Updated milestones are renegotiated with the NC as needed, and then
>are submitted to the DNSO Secretariat: DNSO-secretary@DNSO.org.
>
>Rechartering (other than revising milestones) a working group follows
>the same procedures that the initial chartering does (see section 2). 
>The revised charter must be submitted to the NC for approval.  As
>with the initial chartering, the NC may approve new charter as-is, it
>may request that changes be made in the new charter (including having
>the Working Group continue to use the old charter), or it may decline
>to approve the rechartered working group.  In the latter case, the
>working group is disbanded. 
>
>6. Staff Roles
>
>Working groups require considerable care and feeding.  In addition to
>general participation, successful working groups benefit from the
>efforts of participants filling specific functional roles.  The NC
>must agree to the specific people performing the WG Chair, and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exactly.  However, many do not agree with the policy of having the
NC imposing a chair on the WG.


>Working Group Consultant roles, and they serve at the discretion of
>the NC. 

No, they serve at the discretion of the WG.  The NC should have no
say in who the WG wants to put in these positions.  If the NC were
knowledgable enough about the issues at hand, they wouldn't need the
WG.  The WG should be allowed to choose those it feels would best 
serve in these roles.

>
>6.1. WG Chair
>
>The Working Group Chair is concerned with making forward progress
>through a fair and open process, and has wide discretion in the
>conduct of WG business.  The Chair must ensure that a number of tasks
>are performed, either directly or by others assigned to the tasks. 
>
>The Chair has the responsibility and the authority to make decisions,
>on behalf of the working group, regarding all matters of working
>group process and staffing, in conformance with the rules of the
>DNSO.  The NC has the authority and the responsibility to assist in
>making those decisions at the request of the Chair or when
>circumstances warrant such an intervention. 
>
>The Chair's responsibility encompasses at least the following:
>
>   Ensure WG process and content management
>
>      The Chair has ultimate responsibility for ensuring that a working
>      group achieves forward progress and meets its milestones.  The
>      Chair is also responsible to ensure that the working group
>      operates in an open and fair manner.  For some working groups,

It has already been shown that at least one NC-appointed chair is 
not willing to do this, and has said as much, for the record.
The practice should not be allowed to continue.

>      this can be accomplished by having the Chair perform all
>      management-related activities.  In other working groups --
>      particularly those with large or divisive participation -- it is
>      helpful to allocate process and/or secretarial functions to other
>      participants.  Process management pertains strictly to the style
>      of working group interaction and not to its content. It ensures
>      fairness and detects redundancy.  The secretarial function
>      encompasses document editing.  It is quite common for a working
>      group to assign the task of Editor to one or two
>      participants.  Sometimes, they also are part of the design team,
>      described below.
>
>   Moderate the WG email list
>
>      The Chair should attempt to ensure that the discussions on this
>      list are relevant and that they converge to consensus agreements.
>      The Chair should make sure that discussions on the list are
>      summarized and that the outcome is well documented (to avoid
>      repetition).  The Chair also may choose to schedule organized on-
>      line "sessions" with agenda and deliverables.  These can be
>      structured as true meetings, conducted over the course of several
>      days (to allow participation across the Internet).
>
>      Organize, prepare and chair face-to-face and on-line formal
>      sessions.
>
>   Plan WG Sessions
>
>      The Chair must plan and announce all WG sessions well in advance
>      (see section 3.1).
>
>   Communicate results of sessions
>
>      The Chair and/or Secretary must ensure that minutes of a session
>      are taken and that an attendance list is circulated (see section
>      3.1).
>
>      Immediately after a session, the WG Chair MUST provide the NC
>      Director with a very short report (approximately one paragraph,
>      via email) on the session.
>
>   Distribute the workload
>
>      Of course, each WG will have participants who may not be able (or
>      want) to do any work at all. Most of the time the bulk of the work
>      is done by a few dedicated participants. It is the task of the
>      Chair to motivate enough experts to allow for a fair distribution
>      of the workload.
>
>   Document development
>
>      Working groups produce documents and documents need authors. The
>      Chair must make sure that authors of WG documents incorporate
>      changes as agreed to by the WG (see section 6.3).
>
>   Document publication
>
>      The Chair and/or Document Editor will work to
>      ensure document conformance with DNSO publication requirements
>      and to coordinate any editorial changes required.
>      A particular concern is that all participants are working
>      from the same version of a document at the same time.
>
>6.2. WG Secretary
>
>Taking minutes and editing working group documents often is performed
>by a specifically-designated participant or set of participants.  In
>this role, the Secretary's job is to record WG decisions. 
>
>6.3. Document Editor
>
>Most DNSO working groups focus their efforts on a document, or set of
>documents, that capture the results of the group's work.  A working
>group generally designates a person or persons to serve as the Editor
>for a particular document.  The Document Editor is responsible for
>ensuring that the contents of the document accurately reflect the
>decisions that have been made by the working group. 
>
>As a general practice, the Working Group Chair and Document Editor
>positions are filled by different individuals to help ensure that the
>resulting documents accurately reflect the consensus of the working
>group and that all processes are followed. 
>
>6.4. WG Facilitator
>
>When meetings tend to become distracted or divisive, it often is
>helpful to assign the task of "process management" to one
>participant.  Their job is to oversee the nature, rather than the
>content, of participant interactions.  That is, they attend to the
>style of the discussion and to the schedule of the agenda, rather
>than making direct technical contributions themselves. 
>
>6.5. Design teams
>
>It is often useful, and perhaps inevitable, for a sub-group of a
>working group to develop a proposal to solve a particular problem. 
>Such a sub-group is called a design team.  In order for a design team
>to remain small and agile, it is acceptable to have closed membership
>and private meetings.  

No, it is not.  And once again, the WGs in the DNSO are recommending
policy, not creating a specific technical entity.  Such a methodology
will not work in this context.

>Design teams may range from an informal chat
>between people in a hallway to a formal set of expert volunteers that
>the WG chair or NC appoints to attack a controversial problem.  The
>output of a design team is always subject to approval, rejection or
>modification by the WG as a whole. 
>

This also allows for exlusion and/or process capture by one organization,
constituency, or group of conspirators.

>6.6. Working Group Consultant
>
>At the discretion of the NC, a Consultant may be assigned to a
>working group.  Consultants have specific technical background
>appropriate to the WG and experience in Internet architecture and
>DNSO process. 

No, and I've already outlined my reasons against this earlier in the
document.

>
>6.7. NC Liason
>
>NC Liasons are responsible for ensuring that working groups in their
>charge produce coherent, coordinated, architecturally consistent and
>timely output as a contribution to the overall results of the DNSO. 
>
>7.  Working Group Documents
>
>7.1. Session documents
>
>All relevant documents to be discussed at a session should be
>published and available as DNSO-Drafts at least two weeks before a
>session starts.  Any document which does not meet this publication
>deadline can only be discussed in a working group session with the
>specific approval of the working group chair(s).  Since it is
>important that working group members have adequate time to review all
>documents, granting such an exception should only be done under
>unusual conditions.  The final session agenda should be posted to the
>working group mailing list at least two weeks before the session and
>sent at that time to agenda@DNSO.org for publication on the DNSO web
>site. 
>
>7.2. DNSO-Drafts
>
>The DNSO-Drafts directory is provided to working groups as a resource
>for posting and disseminating in-process copies of working group
>documents.  This repository is replicated at various locations around
>the Internet.  It is encouraged that draft documents be posted as
>soon as they become reasonably stable. 
>
>It is stressed here that DNSO-Drafts are working documents and have
>no official standards status whatsoever.  They may, eventually, turn
>into a policy recommendation or they may sink from sight. 
>DNSO-Drafts are submitted to: dnso-drafts@DNSO.org,
>
>The format of a DNSO-Draft is flexible, but a plain ascii text
>version must be available so that any WG member can view it. 
>
>   Further, all Drafts must contain:
>
>   - Beginning, standard, boilerplate text which is provided by the
>     Secretariat on their web site and in the ftp directory;
>   - The Draft filename; and
>   - The expiration date for the Draft.
>
>   Complete specification of requirements for a DNSO-Draft are
>   found in the file ....
>
>7.3. Policy Recommendation Documents
>
>The work of an DNSO working group often results in publication of one
>or more documents. [characteristics of such documents]
>

All WG policy recommendations should be signed off on by those in the
WG who are in agreement with it.  Otherwise, it allows for a 
situation like that now in WG-A.


>7.4. Working Group Last-Call
>
>When a WG decides that a document is ready for publication it may be
>submitted to the NC for consideration.  In most cases the
>determination that a WG feels that a document is ready for
>publication is done by the WG Chair issuing a working group Last-
>Call.  The decision to issue a working group Last-Call is at the
>discretion of the WG Chair working with the NC Liason.  A working
>group Last-Call serves the same purpose within a working group that a
>NC Last-Call does in the broader DNSO community. 
>
>7.5. Submission of documents
>
>Once that a WG has determined at least rough consensus exists within
>the WG for the advancement of a document the following must be done:
>
>   - The version of the relevant document exactly as agreed to by the WG
>     MUST be in the Drafts directory.
>
>   - The relevant document MUST be formatted according to section 7.3.
>
>   - The WG Chair MUST send email to the relevant NC Liason.  A copy
>     of the request MUST be also sent to the DNSO Secretariat.  The mail
>     MUST contain the reference to the document's filename, and the
>     action requested.  The copy of the message to the 	DNSO Secretaria
>t
>     is to ensure that the request gets recorded by the Secretariat so
>     that they can monitor the progress of the document through the
>     process.
>
>   Unless returned by the NC to the WG for further development,
>   progressing of the document is then the responsibility of the NC.
>

The document should be submitted to the GA for approval.  This process
is fine, except where you say NC, I would substitue GA.  The NC should
simply accept the will of the GA and pass the document to ICANN.

>8. Review of documents
>
>   The NC reviews all documents submitted by WGs.
>

The GA reviews all documents.

[snip rest]

-- 
Mark C. Langston	     			Let your voice be heard:
mark@bitshift.org				     http://www.idno.org
Systems Admin					    http://www.icann.org
San Jose, CA					     http://www.dnso.org