[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wg-d] WG Principles
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.
[Description of the NC]
The NC approves DNSO Policy Recommendations, and forwards them to the
ICANN board for action.
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.
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.
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?
- 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?
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.
- 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 proposed work plan an open effort?
- 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.
- Do the working group's goals overlap with known work in another
standards or policy body, and if so is adequate liaison in place?
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.
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:
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.
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.
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.
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
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).
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.
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
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
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.
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.
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
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,
- 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).
- 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.
In general, a BOF on a particular topic is held only once (ONE slot
at one DNSO Plenary meeting). Under unusual circumstances the NC
may, at their discretion, allow a BOF to meet for a second
time. BOFs are not permitted to meet three times. Note that all
other things being equal, WGs will be given priority for meeting
space over BOFs. Also, occasionally BOFs may be held for other
purposes than to discuss formation of a working group.
Usually the outcome of a BOF will be one of the following:
- There was enough interest and focus in the subject to warrant the
formation of a WG;
- While there was a reasonable level of interest expressed in the BOF
some other criteria for working group formation was not met (see
section 2.1).
- The discussion came to a fruitful conclusion, with results to be
written down and published, however there is no need to establish a
WG; or
- There was not enough interest in the subject to warrant the
formation of a WG.
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].
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
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
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. 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.
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. In determining the balance, the WG must ensure that
its process does not serve to exclude contribution by email-only
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.
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.
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
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. The Chair should consult with the Area
Director(s) if the individual persists in disruptive behavior.
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.
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.
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.
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. 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.
3.3. Session management
Working groups make decisions through a "rough consensus" process.
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.
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.
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. 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.
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. 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.
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.
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;
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;
Timing
The input pertains to a topic that the working group has not yet
opened for discussion; or
Scope
The input is outside of the scope of the working group charter.
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
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
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,
2. Choose new Chair(s), or
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
Working Group Consultant roles, and they serve at the discretion of
the NC.
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,
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. 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.
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.
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]
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 Secretariat
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.
8. Review of documents
The NC reviews all documents submitted by WGs.
Prior to the NC beginning their deliberations on policy
documents, DNSO Secretariat will issue a "Last-Call" to the DNSO
mailing list. This Last Call will announce the intention of
the NC to consider the document, and it will solicit final comments
from the DNSO within a period of two weeks. It is important to note
that a Last-Call is intended as a brief, final check with the
Internet community, to make sure that no important concerns have been
missed or misunderstood. The Last-Call should not serve as a more
general, in-depth review.
The NC review takes into account responses to the Last-Call and
will lead to one of these possible conclusions:
1. The document is accepted as is for the status requested.
This fact will be announced by the DNSO Secretariat to the DNSO
mailing list.
2. The document is accepted as-is but not for the status requested.
This fact will be announced by the DNSO Secretariat to the DNSO
mailing list.
3. Changes regarding content are suggested to the author(s)/WG.
Suggestions from the NC must be clear and direct, so as to
facilitate working group and author correction of the
specification. If the author(s)/WG can explain to the
satisfaction of the NC why the changes are not necessary, the
document will be accepted as under point 1, above.
If the changes are made the revised document may be resubmitted
for NC review.
4. Changes are suggested by the NC and a change in status is
recommended.
The process described above for 3 and 2 are followed in that
order.
5. The document is rejected.
Any document rejection will be accompanied by specific and
thorough arguments from the NC. Although the DNSO and working
group process is structured such that this alternative is not
likely to arise for documents coming from a working group, the
NC has the right and responsibility to reject documents that the
NC feels are fatally flawed in some way.
If any individual or group of individuals feels that the review
treatment has been unfair, there is the opportunity to make a
procedural complaint. The mechanism for this type of complaints is
described in [X].
10. Acknowledgments
11. References
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[2] Hovey, R., and S. Bradner, "The Organizations involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall Committees", BCP
10, RFC 2282, February 1998.
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, April 1995.
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997.
12. Editor's Address
Appendix: Sample Working Group Charter
Working Group Name:
New TLDS (ntlds)
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Names Council Liason(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:
To Subscribe:
Archive:
Description of Working Group:
Goals and Milestones:
--
Kent Crispin "Do good, and you'll be
kent@songbird.com lonesome." -- Mark Twain