| 订阅 | 在线投稿
分享
 
 
 

RFC1603 - IETF Working Group Guidelines and Procedures

来源:互联网网民  宽屏版  评论
2008-05-31 18:56:25

Network Working Group E. Huizer

Request for Comments: 1603 SURFnet bv

Category: Informational D. Crocker

Silicon Graphics, Inc.

March 1994

IETF Working Group

Guidelines and Procedures

Status of this Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Abstract

The Internet Engineering Task Force (IETF) has responsibility for

developing and reviewing specifications intended as Internet

Standards. IETF activities are organized into working groups (WGs).

This document describes the guidelines and procedures for formation

and operation of IETF working groups. It describes the formal

relationship between IETF participants WG and the Internet

Engineering Steering Group (IESG). The basic duties of IETF

participants, including WG Chair and IESG Area Directors are defined.

Table of Contents

1. INTRODUCTION.............................................. 2

1.1. IETF approach to standardization........................ 3

1.2. Acknowledgments......................................... 4

2. WORKING GROUP (WG) FORMATION.............................. 5

2.1. Criteria for formation.................................. 5

2.2. Charter................................................. 6

2.3. Charter review & approval............................... 9

2.4. Birds of a feather (BOF)................................ 9

3. WORKING GROUP OPERATION................................... 11

3.1. Session planning........................................ 11

3.2. Session venue........................................... 12

3.3. Session management...................................... 14

3.4. Contention and appeals overview......................... 15

4. WORKING GROUP TERMINATION................................. 16

5. STAFF ROLES............................................... 17

5.1. WG Chair................................................ 17

5.2. WG Editor/Secretary..................................... 19

5.3. WG Facilitator.......................................... 19

5.4. Design teams............................................ 19

5.5. Area Consultant......................................... 19

5.6. Area Director........................................... 20

5.7. Area Directorate........................................ 21

6. WORKING GROUP DOCUMENTS................................... 21

6.1. Session documents....................................... 21

6.2. IETF meeting document archive........................... 21

6.3. Internet-Drafts (I-D)................................... 23

6.4. Request For Comments (RFC).............................. 24

6.5. Submission of documents................................. 24

6.6. Review of documents..................................... 25

7. SECURITY CONSIDERATIONS................................... 26

8. REFERENCES................................................ 26

9. AUTHORS' ADDRESSES........................................ 27

APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28

1. INTRODUCTION

This document defines guidelines and procedures for Internet

Engineering Task Force working groups. The Internet is a loosely-

organized international collaboration of autonomous, interconnected

networks; it supports host-to-host communication through voluntary

adherence to open protocols and procedures defined by Internet

Standards, a collection of which are commonly known as "the TCP/IP

protocol suite". The Internet Standards Process is defined in [1].

Development and review of potential Internet Standards from all

sources is conducted by the Internet Engineering Task Force (IETF).

The IETF is a large, open community of network designers, operators,

vendors, users, and researchers concerned with the Internet and the

technology used on it. The IETF is managed by its Internet

Engineering Steering Group (IESG) whose membership includes an IETF

Chair, responsible for oversight of general IETF operations, and Area

Directors, each of whom is responsible for a set of IETF activities

and working groups. The IETF Executive Director and IESG Secretary

are ex-officio participants, as are the IAB Chair and a designated

Internet Architecture Board (IAB) member. At present there are 10

areas, though the number and purview of areas changes over time:

User Services (USV)

Applications (APP)

Service Applications (SAP)

Transport Services (TSV)

Internet (INT)

Routing (RTG)

Network Management (MGT)

Operational Requirements (OPS)

Security (SEC)

Standards & Processes (STD)

Most areas have an advisory group or directorate. The specific name

and the details of the role for each group differs from area to area,

but the primary intent is that the group assist the Area Director,

e.g., with the review of specifications produced in the area. An

advisory group is formed by an Area Director (AD) and comprises

eXPerienced members of the IETF and technical community represented

by the area. A small IETF Secretariat provides staff and

administrative support for the operation of the IETF.

The primary activities of the IETF are performed by committees known

as working groups. There are currently more than 60 of these.

Working groups tend to have a narrow focus and a lifetime bounded by

completion of a specific task, although there are exceptions.

There is no formal membership in the IETF. 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

IETF meetings and any of its on-line working group discussions.

Participation is by individual technical contributors, rather than by

formal representatives of organizations.

This document defines procedures and guidelines for formation and

operation of working groups in the IETF. It defines the relations of

working groups to other bodies within the IETF. The duties of working

group Chairs and Area Directors with respect to the operation of the

working group are also defined. The document uses: "shall", "will",

"must" and "is required" where it describes steps in the process that

are essential, and uses: "suggested", "should" and "may" are where

guidelines are described that are not essential, but are strongly

recommended to help smooth WG operation.

1.1. IETF approach to standardization

The reader is encouraged to study The Internet Standards Process [1].

Familiarity with this document is essential for a complete

understanding of the philosophy, procedures and guidelines described

in this document.

The goals of the process are summarized in [1]:

"In general, an Internet Standard is a specification that is

stable and well-understood, is technically competent, has

multiple, independent, and interoperable implementations

with operational experience, enjoys significant public

support, and is recognizably useful in some or all parts of

the Internet.

...

"In outline, the process of creating an Internet Standard is

straightforward: a specification undergoes a period of

development and several iterations of review by the Internet

community and perhaps revision based upon experience, is

adopted as a Standard by the appropriate body (see below),

and is published.

"In practice, the process is somewhat more complicated, due

to (1) the number and type of possible sources for

specifications; (2) the need to prepare and revise a

specification in a manner that preserves the interests of

all of the affected parties; (3) the importance of

establishing widespread community agreement on its technical

content; and (4) the difficulty of evaluating the utility of

a particular specification for the Internet community.

...

"These procedures are explicitly aimed at developing and

adopting generally-accepted practices. Thus, a candidate

for Internet standardization is 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 standardization process has been marked by informality. As

the community of participation has grown it has become necessary to

document procedures, while continuing to avoid unnecessary

bureaucracy. This goals of this balancing act are summarized in [1]

as:

"The procedures that are described here provide a great deal

of flexibility to adapt to the wide variety of circumstances

that occur in the Internet standardization process.

Experience has shown this flexibility to be vital in

achieving the following goals for Internet standardization:

* high quality,

* prior implementation and testing,

* openness and fairness, and

* timeliness."

1.2. Acknowledgments

Much of this document is due to the copy-and-paste function of a Word

processor. Several passages have been taken from the documents cited

in the reference section. The POISED WG provided discussion and

comments. Three people deserve special mention, as especially large

chunks of their documents have been integrated into this one: Vint

Cerf [7] from whom we borrowed the description of the IETF; and Greg

Vaudreuil and Steve Coya who provided several paragraphs. Also, John

Stewart and Steve Crocker did a truly stellar job of proof-reading.

However, all the errors you'll find are probably ours.

2. WORKING GROUP (WG) FORMATION

IETF working groups (WGs) are the primary mechanism for development

of IETF specifications and guidelines, many of which are intended as

standards or recommendations. A working group may be established at

the initiative of an Area Director (AD) or it may be initiated by an

individual or group of individuals. Anyone interested in creating an

IETF working group must oBTain the advice and consent of the

appropriate IETF Area Director under whose direction the working

group would fall and must proceed through the formal steps detailed

in this section.

A working group is typically created to address a specific problem or

produce a deliverable (a guideline, standards specification, etc.)

and is expected to be short-lived in nature. Upon completion of its

goals and achievement of its objectives, the working group as a unit

is terminated. Alternatively at the discretion of the IESG, Area

Director, the WG Chair and the WG participants, the objectives or

assignment of the working group may be extended by enhancing or

modifying the working group's charter.

2.1. Criteria for formation

When determining whether it is appropriate to create a working group,

the Area Director and the IESG will consider several issues:

- Are the issues that the working group plans to address clear

and relevant for the Internet community?

- Are the goals specific and reasonably achievable, and

achievable within the time frame specified by the

milestones?

- What are the risks and urgency of the work, to determine the

level of attention 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 Area Directors as subdividing

efforts often dilutes the available technical expertise.

- Is there sufficient interest and expertise in the working

group's topic with at least several people willing to expend

the effort to produce the desired result (e.g., a protocol

specification)? Working groups require considerable effort,

including management of the working group process, editing

of working group documents, and contribution to the document

text. IETF experience suggests that these roles typically

cannot all be handled by one person; four or five active

participants are typically required.

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

process, as well as by less direct means.

Considering the above criteria, the Area Director 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

primarily negotiated between a prospective working group Chair and

the relevant Area Director, although final approval is made by the

IESG and all charters are reviewed by the Internet Architecture Board

(IAB). A charter is a contract between a working group and the IETF

to perform a set of tasks. A charter:

1. Lists relevant administrative ASPects of 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, the Area Director and the IESG Secretary

are satisfied with the charter form and content, it becomes the basis

for forming a working group. The AD may require an initial draft of a

charter to be available prior to holding an exploratory Birds of a

Feather (BOF) meeting, as described below.

Charters may be renegotiated periodically to reflect the current

status, organization or goals of the working group. Hence, a charter

is a contract between the IETF and the working group which is

committing to meet explicit milestones and delivering concrete

"products".

Specifically, each charter consists of 6 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 IETF directories, mailing lists, and

general documents.

Chair(s)

The working group may have one or two Chair(s) to perform

the administrative functions of the group. The email

address(es) of the Chair(s) shall be included.

Area and Area Director(s)

The name of the IETF area with which the working group is

affiliated and the name and electronic mail address of the

associated Area Director.

Mailing list

It is required that an IETF working group have a general

Internet mailing list. Most of the work of an IETF working

group will be conducted that.

The charter shall include:

The address to which a participant sends a

subscription request and the procedures to follow when

subscribing,

The address to which a participant sends submissions

and special procedures, if any, and

The location of the mailing list archive, if any.

A message archive should be maintained in a public place

which can be Accessed via FTP. The ability to retrieve from

the archive via electronic mail requests also is

recommended. Additionally, the address:

ietf-archive@cnri.reston.va.us

shall be included on the mailing list.

NOTE: It is strongly suggested that the mailing list be on

a host directly connected to the IP Internet to facilitate

use of the SMTP expansion command (EXPN) and to allow mail

archive access via FTP, gopher and the like in keeping with

the general IETF rule for openness. If this is not possible,

the message archive and membership of the list must be made

available to those who request it by sending a message to

the list-request alias.

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 will

frequently be used as an overview of the working group's effort.

The terms "they", "them" and "their" are used in this document as

third-person singular pronouns.

To facilitate evaluation of the intended work and to provide

on-going guidance to the working group, the charter shall

describe the problem being solved and shall discuss

objectives and expected impact with respect to:

- Architecture

- Operations

- Security

- Network management

- Transition (where applicable)

Goals and milestones

The working group charter must establish a timetable for

work. While this may be re-negotiated 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., "Internet-Draft 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. Updated milestones are re-negotiated

with the Area Director and the IESG, as needed, and then are

submitted to the IESG Secretary:

IESG-secretary@cnri.reston.va.us

An example of a WG charter is in Appendix A.

2.3. Charter review & approval

Working groups often comprise technically competent participants who

are not familiar with the history of Internet architecture or IETF

processes. This can, unfortunately, lead to good working group

consensus about a bad design. To facilitate working group efforts,

an Area Director may assign an Area Consultant from among the ranks

of senior IETF participants. (Area Consultants are described in the

section of Staff Roles.) At the discretion of the AD, approval of a

new WG may be withheld in the absence of sufficient Consultant

resources.

Once the Area Director (and the Area Directorate, as the AD deems

appropriate) has approved the working group charter, the charter is

submitted for review by the IAB and approval by the Internet

Engineering Steering Group using the criteria described previously.

The Internet Architecture Board (IAB) will review the charter of the

proposed WG to determine the relationship of the proposed work to the

overall architecture of the Internet Protocol Suite.

The approved charter is submitted to the IESG Secretary who records

and enters the information into the IETF tracking database and

returns the charter in a form formatted by the database. The working

group is announced to the IETF mailing list by the IESG Secretary.

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 IETF

offers the possibility of a Birds of a Feather (BOF) session, as well

as the early formation of an email list for preliminary discussion.

Alternatively, 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 an IETF 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

relevant Area Director. The person who requests the BOF is usually

appointed as Chair of the BOF. The Chair of the BOF is also

responsible for providing a report on the outcome of the BOF.

The AD may require the conduct of email discussion, 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 AD may require that a BOF be held,

prior to establishing a working group, and the AD may require that

there be a draft of the WG charter prior to holding a BOF.

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;

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

There is an increasing demand for BOF sessions at IETF meetings.

Therefore the following rules apply for BOFs:

- All BOFs must have the approval of the appropriate Area

Director. The Secretariat will NOT schedule or allocate time

slots without the explicit approval of the Area Director.

- The purpose of a BOF is to conduct a single, brief

discussion or to ascertain interest and establish goals for

a working group. All BOF organizers are required to submit a

brief written report of what transpired during the BOF

session together with a roster of attendees to the IESG

Secretary for inclusion in the Proceedings.

- A BOF may be held only once (ONE slot at one IETF Plenary

meeting).

- Under unusual circumstances an Area Director may, at their

discretion, allow a BOF to meet for a second time. Typically

(though not a requirement) this is to develop a charter to

be submitted to the IESG.

- BOFs are not permitted to meet three times.

- A BOF may be held for single-event discussion, or may pursue

creation of normal IETF working groups for on-going

interactions and discussions. When the request for a BOF

comes from a formally-constituted group, rather than from an

individual, the rules governing the handling of the request

are the same as for all other BOFs and working groups.

- When necessary, WGs will be given priority for meeting space

over BOFs.

3. WORKING GROUP OPERATION

The IETF has basic requirements for open and fair participation and

for thorough consideration of technical 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".

A number of procedural questions and issues will arise over time, and

it is the function of the Working Group Chair 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 have evolved

over time that have proven successful. These are listed here, with

actual choices typically determined by the working group participants

and the Chair.

3.1. Session planning

For coordinated, structured WG interactions, the Chair must publish a

draft agenda well in advance of the actual session. The agenda needs

to 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 shall include sending a copy to the working group mailing

list and to the IETF-Announce list. Notices for the IETF-Announce

list should be sent to:

ietf-announce-post@cnri.reston.va.us

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

common, but not required, that a working group will meet at the

trimester IETF Plenary events. Additionally, interim sessions may be

scheduled for telephone conference, video teleconference, or for

face-to-face (physical) sessions.

All working group sessions (including those held outside of the IETF

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 IETF

Proceedings, and for posting in the IETF Directories and are to be

sent to:

minutes@cnri.reston.va.us

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. Also note that decisions reached during IETF meetings

are NOT final, but must be conveyed to the mailing list to verify WG

consensus.

IETF Meetings

If a WG needs a session at an IETF meeting, the Chair must apply for

time-slots as soon as the first announcement of that IETF meeting is

made by the IETF Secretariat to the WG-chairs list. Session time is

a scarce resource at IETF 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 IETF meeting shall be made to

the IETF Secretariat. Alternatively some Area Directors may want to

coordinate WG sessions in their area and request that time slots be

coordinated through them. After receiving all requests for time

slots by WGs in the area, the Area Director(s) form a draft session-

agenda for their area, which is then sent to the WG chairs of the

area. After approval it will be sent to the IETF Secretariat.

An application must contain:

- 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 must not be scheduled for the same time

slot(s); and

- Individuals whose attendance is desired.

The Secretariat allots time slots on the basis of the session-agenda

made by the Area Director(s). If the proposed session- agenda for an

area does not fit into the IETF meeting-agenda, the IETF Secretariat

will adjust it to fit, after consulting the Area Director(s) and the

relevant chairs. The Secretariat will then form a draft session-

agenda and distribute it among the Working Group Chairs for final

approval.

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 IETF

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.

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.

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 IETF meetings, due to the time and expense required to

attend.

3.3. Session management

Working groups make decisions through a "rough consensus" process.

IETF 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 balloting, humming, or any other means

on which the WG agrees (by rough consensus, of course).

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 direct a discussion 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 overview

In the course of group design processes, strife happens. Strife and

contention are particularly likely when working groups comprise many

constituencies. On the other hand differences in view are vital to

the success of the IETF and healthy debate is encouraged. Sometimes

debates degenerate into something akin to warfare. For these

circumstances, the IETF has an extensive review and appeals process.

Formal procedures for requesting review and conducting appeals are

documented in The Internet Standards Process [1]. A brief summary is

provided, here.

In fact the IETF approach to reviews and appeals is quite simple:

When an IETF participant feels that matters have not been conducted

properly, they should state their concern to a member of IETF

management. In other words, the process relies upon those who have

concerns raising them. If the result is not satisfactory, there are

several levels of appeal available, to ensure that review is possible

by a number of people uninvolved in the matter in question.

Reviews and appeals step through four levels, each in turn:

WG Chair

An appeal must begin with the management closest to the

operation of the working group, even if the concern applies

to their own handling of working group process.

Area

If discussion and review with the WG Chair do not produce a

satisfactory result, the complainant may bring their concern

to the cognizant Area Director.

IESG

If a concerned party is not satisfied with the results of

the area-level review, then they may bring the matter to the

IESG Chair and the Area Director for Standards & Processes.

The IESG Chair and the Standards & Processes AD will bring

the issue before the full IESG for an additional review and

will report the resolution back to the parties.

IAB

The IAB provides a final opportunity to appeal the results

of previous reviews. If a concerned party does not accept

the outcome of the IESG review, then they may take their

concern to the IAB, by contacting the IAB Chair.

Concerns entail either a disagreement with technical decisions by the

working group or with the process by which working group business has

been conducted. Technical disagreements may be about specific

details or about basic approach. When an issue pertains to

preference, it should be resolved within the working group. When a

matter pertains to the technical adequacy of a decision, review is

encouraged whenever the perceived deficiency is noted. For matters

having to do with preference, working group rough consensus will

dominate.

When a matter pertains to working group process, it is important that

those with a concern be clear about the manner in which the process

was not open or fair and that they be willing to discuss the issue

openly and directly. In turn, the IETF management will make every

effort to understand how the process was conducted, what deficiencies

were present (if any) and how the matter should be corrected. The

IETF functions on the good will and mutual respect of its

participants; continued success requires continued attention to

working group process.

4. WORKING GROUP TERMINATION

Working groups are typically chartered to accomplish a specific task.

After that task is complete, the group will be disbanded. However if

a WG produces a Proposed or Draft Standard, 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 work as it moves to Draft Standard and Standard status.)

If, at some point, it becomes evident that a working group is unable

to complete the work outlined in the charter, the group, in

consultation with its Area Director can either:

1. Recharter to refocus on a smaller task,

2. Choose new Chair(s), or

3. Disband.

If the working group disagrees with the Area Director's choice, it

may appeal to the IESG.

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

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

This encompasses at the very 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. 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 specification

Editor to one or two participants. Often, 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 are structured as true meetings,

conducted over the course of several days (to allow

participation across the Internet.) Participants are

expected to allocate time to the meeting, usually in the

range of 1-2 hours per day of the "meeting".

Organize, prepare and chair face-to-face & on-line formal sessions

The Chair should plan and announce sessions well in advance.

(See section on Session Planning for exact procedures.)

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 the section on Session Documents for detailed

procedures.

Immediately after a session, the WG Chair must immediately

provide the Area Director with a very short report

(approximately one paragraph, via email) on the session.

This is used in an Area Report as presented in the

Proceedings of each IETF meeting.

Distribute the work

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 will make sure that authors of WG documents

incorporate changes as discussed by the WG. See the section

on Session Documents for details procedures.

Document publication

The Chair and/or Secretary will work with the RFCEditor to

ensure document conformance with RFCpublication

requirements and to coordinate any editorial changes

suggested by the RFCEditor. A particular concern is that

all participants are working from the same version of a

document at the same time.

5.2. WG Editor/Secretary

Taking minutes and editing working group documents often is performed

by a specifically-designated participant or set of participants. In

this role, the Editor's job is to record WG decisions, rather than to

perform basic specification.

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

5.4. Design teams

The majority of the detailed specification effort within a working

group may be done by self-selecting sub-groups, called design teams,

with the (implicit or explicit) approval of the working group. The

team may hold closed sessions for conducting portions of the

specification effort. In some cases design teams are necessary to

make forward progress when preparing a document. All work conducted

by a design team must be available for review by all working group

participants and the design team must be responsive to the direction

of the working group's consensus.

5.5. Area Consultant

At the discretion of the AD, a Consultant may be assigned to a

working group. Consultants are senior participants in the IETF

community. They have technical background appropriate to the WG and

experience in Internet architecture and IETF process.

5.6. Area Director

Area Directors are responsible for ensuring that working groups in

their area produce coherent, coordinated, architecturally consistent

and timely output as a contribution to the overall results of the

IETF. This very general description encompasses at the very least

these detailed tasks related to working groups:

Area planning

The Area Director determines activities appropriate to the

area. This may include initiating working groups directly,

rather than waiting for proposals from IETF participants.

Coordination of WGs

The Area Director coordinates the work done by the various

WGs within (and sometimes even outside) the relevant area.

IETF Meeting Schedule

The Director tries to coordinate sessions in such a way that

experts can attend the relevant sessions with a minimum of

overlap and gaps between sessions. (See section on WG

sessions for details.)

Reporting

The Area Director reports to the IETF on progress in the

area.

Reviewing

The Area Director may appoint independent reviewers prior to

document approval. The Area Director tracks the progress of

documents from the area through the IESG review process, and

report back on this to the WG Chair(s).

Progress tracking

The Area Director tracks and manages the progress of the

various WGs with the aid of a regular status report on

documents and milestones that is generated by the IESG

Secretary. The Area Director forwards this report to the WG

chairs. This in turn helps the chairs to manage their WGs.

5.7. Area Directorate

An area directorate consists of senior members of the technical

community and are appointed by the Area Director who then tasks them

with technical oversight and review of specific area activities. An

Area Director chairs the directorate. At the request of the AD,

directorate members conduct specification reviews and may be assigned

as Area Consultants, to provide architectural assistance.

6. WORKING GROUP DOCUMENTS

6.1. Session documents

All relevant documents for a session (including the final agenda)

should be published and available at least two weeks before a session

starts.

It is strongly suggested that the WG Chair make sure that an

anonymous FTP directory be available for the upcoming session. All

relevant documents (including the final agenda and the minutes of the

last session) should be placed in this directory. This has the

advantage that all participants can FTP all files in this directory

and thus make sure they have all relevant documents. Also, it will be

helpful to provide electronic mail-based retrieval for those

documents.

6.2. IETF meeting document archive

In preparing for an IETF meeting it is helpful to have ready access

to all documents that are being reviewed. While documents usually are

placed in the internet-drafts Internet Repository or in the

respective working group archives or just published in some mail-

lists, there are just too many things to browse or read through.

Also, many documents are modified immediately before a meeting.

The InterNIC Directory and Database Services provides a current-

ietf-docs archive to enable people to get all documents that are

relevant for the up-coming IETF meeting. This document database will

be removed two weeks after the IETF meeting.

The completeness of this archive depends on the authors and working

group chairs submitting the documents. Each WG Chair is requested to

submit the agenda to this archive.

Structure of the archive:

On ds.internic.net documents will be stored under the appropriate

working group name under the appropriate area name in the directory:

/pub/current-ietf-docs

Each area will also have a directory called bof where a document to

be discussed in a BOF meeting will be placed. At the area level a

directory called plenary will be created to hold documents or

presentation material related to a plenary session. Any filename

conflicts will be resolved by the InterNIC's administrator and the

submitter will be informed via electronic mail. Example:

/pub/current-ietf-docs/app/osids

/pub/current-ietf-docs/int/sip

Access via anonymous FTP:

Anonymous FTP to ds.internic.net and change directory to

/pub/current-ietf-docs/

and browse and get the document of interest.

Access via gopher:

Connect to gopher.internic.net and select the menu item:

4. InterNIC Directory and Database Services (AT&T)/

and then the menu item:

3. Documents to be reviewed at the *** IETF

One may use the public-access gopher client by:

telnet gopher.internic.net

Submission of documents via anonymous FTP:

FTP to ds.internic.net and login as anonymous. Change directory to:

/incoming/current-ietf-docs

Put the document using the following filename convention,

<area>.<wgname>.<filename>

e.g.:

plenary.mondayVGs.ps

app.osids.agenda

app.osids.internic-talk-VGs.ps

Note that the names of areas and working groups are their official

short-form acronyms,

Submission of documents via electronic mail:

Send mail to

admin@ds.internic.net

with the following subject line:

IETF - <area>.<wgname>.<filename>

e.g.:

IETF - app.osids.agenda

NOTE: Instead of sending a fresh copy of an already available

document, you may ask the InterNIC's administrators to create a link

to an existing internet-draft/RFC/ID

NOTE: If you do not remember your area or working group acronym get

the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous

FTP.

6.3. Internet-Drafts (I-D)

The Internet-Drafts directory is provided to working groups as a

resource for posting and disseminating early 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 Internet-Drafts are working documents and

have no official standards status whatsoever. They may, eventually,

turn into a standards-track document or they may sink from sight.

Internet-Drafts are submitted to:

internet-drafts@cnri.reston.va.us

The format of an Internet-Draft must be the same as for an RFC[2].

Further, an I-D must contain:

- Beginning, standard, boilerplate text which is provided by

the Secretariat;

- The I-D filename; and

- The expiration date for the I-D.

Complete specification of requirements for an Internet-Draft are

found in the file:

1id-guidelines.txt

in the internet-drafts directory at an Internet Repository site.

6.4. Request For Comments (RFC)

The work of an IETF working group usually results in publication of

one or more documents, as part of the Request For Comments (RFCs) [2]

series. This series is the archival publication record for the

Internet community. A document can be written by an individual in a

working group, by a group as a whole with a designated Editor, or by

others not involved with the IETF. The designated author need not be

the group Chair(s).

NOTE: The RFCseries is a publication mechanism only and publication

does not determine the IETF status of a document. Status is

determined through separate, explicit status labels assigned by the

IESG on behalf of the IETF. In other words, the reader is reminded

that all Internet Standards are published as RFCs, but NOT all RFCs

specify standards.

For a description on the various categories of RFCs the reader is

referred to [1, 4, 5, 6].

6.5. Submission of documents

When a WG decides that a document is ready for publication, the

following must be done:

- The version of the relevant document as approved by the WG

must be in the Internet-Drafts directory;

- The relevant document must be formatted according to RFC

rules [2].

- The WG Chair sends email to the relevant Area Director, with

a copy to the IESG Secretary. The mail should contain the

reference to the document, and the request that it be

progressed as an Informational, Experimental, Prototype or

standards-track (Proposed, Draft or Internet Standard) RFC.

The IESG Secretary will acknowledge receipt of the email. Unless

returned to the WG for further development, progressing of the

document is then the responsibility of the IESG. After IESG

approval, responsibility for final disposition is the joint

responsibility of the RFCEditor and the WG Chair and Editor.

6.6. Review of documents

Usually in case of a submission intended as an Informational or

Experimental RFCminimal review is necessary. However, if the WG or

the RFCEditor thinks that an extensive review is appropriate, the

Area Director may be asked to conduct one. This review may either be

done by the AD and other IESG participants or the IESG may ask for an

independent review (e.g., by someone not part of the WG in question)

from the Area Directorate or elsewhere.

A review will lead to one of three possible conclusions:

1. The document is accepted as is.

This fact will be announced by the IESG Secretary to the

IETF mailing list and to the RFCEditor. Publication is then

further handled between the RFCEditor and the author(s).

2. Changes regarding content are suggested to the author(s)/WG.

Suggestions must be clear and direct, so as to facilitate

working group and author correction of the specification.

Once the author(s)/WG have made these changes or have

explained to the satisfaction of the reviewers why the

changes are not necessary, the document will be accepted for

publication as under point 1, above.

3. The document is rejected.

This will need strong and thorough arguments from the

reviewers. The whole IETF and working group process is

structured such that this alternative is not likely to arise

for documents coming from a working group. After all, the

intentions of the document will already have been described

in the WG charter, and reviewed at the start of the WG.

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 procedural complaints is

described in the section on Contention and Appeal.

Before the IESG makes a final decision on a standards-track document,

the IESG Secretary will issue a "Last Call" to the IETF mailing list.

This Last Call will announce the intention of the IESG to consider

the document, and it will solicit final comments from the IETF 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 cannot serve as a more general, in-depth review.

7. SECURITY CONSIDERATIONS

Security issues are not discussed in this memo.

8. REFERENCES

[1] Internet Architecture Board and Internet Engineering Steering

Group, "The Internet Standards Process -- Revision 2", RFC1602,

IAB, IESG, March 1994.

[2] Postel, J., "Instructions to RFCAuthors", RFC1543,

USC/Information Sciences Institute, October 1993.

[3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to

the F.Y.I. Notes", RFC1150, Proteon, USC/Information Sciences

Institute, March 1990.

[4] Postel, J., Editor, "Introduction to the STD Notes", RFC1311,

USC/Information Sciences Institute, March 1992.

[5] Postel, J., Editor, "Internet Official Protocol Standards", STD

1, RFC1600, IAB, March 1994.

[6] Cerf, V., "The Internet Activities Board", RFC1160, NRI, May

1990.

9. AUTHORS' ADDRESSES

Erik Huizer

SURFnet bv

P.O. Box 19035

3501 DA Utrecht

The Netherlands

Phone: +31 30 310290

Fax: +31 30 340903

EMail: Erik.Huizer@SURFnet.nl

Dave Crocker

Silicon Graphics, Inc.

2011 N. Shoreline Blvd.

P.O. Box 7311

Mountain View, CA 94039

Phone: +1 415 390 1804

Fax: +1 415 962 8404

EMail: dcrocker@sgi.com

APPENDIX: SAMPLE WORKING GROUP CHARTER

Multiparty Multimedia Session Control (mmusic)

Charter

Chair(s):

Eve Schooler <schooler@isi.edu>

Abel Weinrib <abel@bellcore.com>

Transport Area Director(s)

Allison Mankin <mankin@cmf.nrl.navy.mil>

Mailing lists:

General Discussion:confctrl@isi.edu

To Subscribe: confctrl-request@isi.edu

Archive: venera.isi.edu:~/confctrl/confcrtl.mail

Description of Working Group:

The demand for Internet teleconferencing has arrived, yet an

infrastructure to support this demand is barely in place.

Multimedia session control, defined as the management and

coordination of multiple sessions and their multiple users in

multiple media (e.g., audio, video), is one component of the

infrastructure. The Multiparty Multimedia Session Control

Working Group is chartered to design and specify a protocol to

perform these functions.

The protocol will provide negotiation for session membership,

underlying communication topology and media configuration. In

particular, the protocol will support a user initiating a

multimedia multiparty session with other users ("calling" other

users) over the Internet by allowing a teleconferencing

application on one workstation to explicitly rendezvous with

teleconferencing applications running on remote workstations.

Defining a standard protocol will enable session-level

interoperability between different teleconferencing

implementations.

The focus of the working group is to design a session negotiation

protocol that is tailored to support tightly-controlled

conferences. The MBONE currently carries primarily loosely-

controlled sessions, i.e., sessions with little to no interaction

among members and with no arbitration facility, security, or

coordination of quality-of-service options for time-critical

media. Users may learn of available sessions using the "sd"

utility or other out of band mechanisms (e.g., email). However,

there is clearly also a need for tightly-controlled sessions that

provide mechanisms for directly contacting other users to

initiate a session and for negotiating conference parameters such

as membership, media encodings and encryption keys. In addition,

these sessions should support renegotiation during a session, for

example to add or delete members or change the media encoding.

It is possible that the protocol will, in the limiting case, also

support loosely-controlled sessions.

The main goal of the working group will be to specify the session

control protocol for use within teleconferencing software over

the Internet. The working group will focus on the aspects of the

session control problem that are well understood, while keeping

an eye on evolving research issues. Toward this end, the working

group has made an inventory of existing conferencing systems and

their session control protocols. The working group will document

the requirements of the existing prototypes as a basis for the

protocol development. The working group will iteratively refine

the protocol based on implementation and operational experience.

Furthermore, the working group will coordinate with other efforts

related to multimedia conferencing, such as directory services

for cataloguing users and conferences, the RTP and RTCP protocols

developed by the Audio/Video Transport Working Group, resource

reservation and management at the network level, and schemes for

multicast address allocation.

Goals and Milestones:

May 93 Hold an on-line working group meeting to discuss

the conference control framework, the relevant

terminology, a functional taxonomy and how

different conversational styles place

requirements on session protocols.

Jun 93 Submit the Conference Session Control Protocol to

the IESG for consideration as an Experimental

Protocol.

Aug 93 Post an Internet-Draft describing the Session

Control Requirements.

Nov 93 Post an Internet-Draft of the Session Control

Protocol.

Mar 94 Submit a revised Internet-Draft based on

implementation experience.

 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
  Network Working Group E. Huizer Request for Comments: 1603 SURFnet bv Category: Informational D. Crocker Silicon Graphics, Inc. March 1994 IETF Working Group Guidelines and Procedures Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. Table of Contents 1. INTRODUCTION.............................................. 2 1.1. IETF approach to standardization........................ 3 1.2. Acknowledgments......................................... 4 2. WORKING GROUP (WG) FORMATION.............................. 5 2.1. Criteria for formation.................................. 5 2.2. Charter................................................. 6 2.3. Charter review & approval............................... 9 2.4. Birds of a feather (BOF)................................ 9 3. WORKING GROUP OPERATION................................... 11 3.1. Session planning........................................ 11 3.2. Session venue........................................... 12 3.3. Session management...................................... 14 3.4. Contention and appeals overview......................... 15 4. WORKING GROUP TERMINATION................................. 16 5. STAFF ROLES............................................... 17 5.1. WG Chair................................................ 17 5.2. WG Editor/Secretary..................................... 19 5.3. WG Facilitator.......................................... 19 5.4. Design teams............................................ 19 5.5. Area Consultant......................................... 19 5.6. Area Director........................................... 20 5.7. Area Directorate........................................ 21 6. WORKING GROUP DOCUMENTS................................... 21 6.1. Session documents....................................... 21 6.2. IETF meeting document archive........................... 21 6.3. Internet-Drafts (I-D)................................... 23 6.4. Request For Comments (RFC).............................. 24 6.5. Submission of documents................................. 24 6.6. Review of documents..................................... 25 7. SECURITY CONSIDERATIONS................................... 26 8. REFERENCES................................................ 26 9. AUTHORS' ADDRESSES........................................ 27 APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28 1. INTRODUCTION This document defines guidelines and procedures for Internet Engineering Task Force working groups. The Internet is a loosely- organized international collaboration of autonomous, interconnected networks; it supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards, a collection of which are commonly known as "the TCP/IP protocol suite". The Internet Standards Process is defined in [1]. Development and review of potential Internet Standards from all sources is conducted by the Internet Engineering Task Force (IETF). The IETF is a large, open community of network designers, operators, vendors, users, and researchers concerned with the Internet and the technology used on it. The IETF is managed by its Internet Engineering Steering Group (IESG) whose membership includes an IETF Chair, responsible for oversight of general IETF operations, and Area Directors, each of whom is responsible for a set of IETF activities and working groups. The IETF Executive Director and IESG Secretary are ex-officio participants, as are the IAB Chair and a designated Internet Architecture Board (IAB) member. At present there are 10 areas, though the number and purview of areas changes over time: User Services (USV) Applications (APP) Service Applications (SAP) Transport Services (TSV) Internet (INT) Routing (RTG) Network Management (MGT) Operational Requirements (OPS) Security (SEC) Standards & Processes (STD) Most areas have an advisory group or directorate. The specific name and the details of the role for each group differs from area to area, but the primary intent is that the group assist the Area Director, e.g., with the review of specifications produced in the area. An advisory group is formed by an Area Director (AD) and comprises eXPerienced members of the IETF and technical community represented by the area. A small IETF Secretariat provides staff and administrative support for the operation of the IETF. The primary activities of the IETF are performed by committees known as working groups. There are currently more than 60 of these. Working groups tend to have a narrow focus and a lifetime bounded by completion of a specific task, although there are exceptions. There is no formal membership in the IETF. 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 IETF meetings and any of its on-line working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations. This document defines procedures and guidelines for formation and operation of working groups in the IETF. It defines the relations of working groups to other bodies within the IETF. The duties of working group Chairs and Area Directors with respect to the operation of the working group are also defined. The document uses: "shall", "will", "must" and "is required" where it describes steps in the process that are essential, and uses: "suggested", "should" and "may" are where guidelines are described that are not essential, but are strongly recommended to help smooth WG operation. 1.1. IETF approach to standardization The reader is encouraged to study The Internet Standards Process [1]. Familiarity with this document is essential for a complete understanding of the philosophy, procedures and guidelines described in this document. The goals of the process are summarized in [1]: "In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. ... "In outline, the process of creating an Internet Standard is straightforward: a specification undergoes a period of development and several iterations of review by the Internet community and perhaps revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published. "In practice, the process is somewhat more complicated, due to (1) the number and type of possible sources for specifications; (2) the need to prepare and revise a specification in a manner that preserves the interests of all of the affected parties; (3) the importance of establishing widespread community agreement on its technical content; and (4) the difficulty of evaluating the utility of a particular specification for the Internet community. ... "These procedures are explicitly aimed at developing and adopting generally-accepted practices. Thus, a candidate for Internet standardization is 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 standardization process has been marked by informality. As the community of participation has grown it has become necessary to document procedures, while continuing to avoid unnecessary bureaucracy. This goals of this balancing act are summarized in [1] as: "The procedures that are described here provide a great deal of flexibility to adapt to the wide variety of circumstances that occur in the Internet standardization process. Experience has shown this flexibility to be vital in achieving the following goals for Internet standardization: * high quality, * prior implementation and testing, * openness and fairness, and * timeliness." 1.2. Acknowledgments Much of this document is due to the copy-and-paste function of a Word processor. Several passages have been taken from the documents cited in the reference section. The POISED WG provided discussion and comments. Three people deserve special mention, as especially large chunks of their documents have been integrated into this one: Vint Cerf [7] from whom we borrowed the description of the IETF; and Greg Vaudreuil and Steve Coya who provided several paragraphs. Also, John Stewart and Steve Crocker did a truly stellar job of proof-reading. However, all the errors you'll find are probably ours. 2. WORKING GROUP (WG) FORMATION IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended as standards or recommendations. A working group may be established at the initiative of an Area Director (AD) or it may be initiated by an individual or group of individuals. Anyone interested in creating an IETF working group must oBTain the advice and consent of the appropriate IETF Area Director under whose direction the working group would fall and must proceed through the formal steps detailed in this section. A working group is typically created to address a specific problem or produce a deliverable (a guideline, standards specification, etc.) and is expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group as a unit is terminated. Alternatively at the discretion of the IESG, Area Director, the WG Chair and the WG participants, the objectives or assignment of the working group may be extended by enhancing or modifying the working group's charter. 2.1. Criteria for formation When determining whether it is appropriate to create a working group, the Area Director and the IESG will consider several issues: - Are the issues that the working group plans to address clear and relevant for the Internet community? - Are the goals specific and reasonably achievable, and achievable within the time frame specified by the milestones? - What are the risks and urgency of the work, to determine the level of attention 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 Area Directors as subdividing efforts often dilutes the available technical expertise. - Is there sufficient interest and expertise in the working group's topic with at least several people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Working groups require considerable effort, including management of the working group process, editing of working group documents, and contribution to the document text. IETF experience suggests that these roles typically cannot all be handled by one person; four or five active participants are typically required. - 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 IETF process, as well as by less direct means. Considering the above criteria, the Area Director 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 primarily negotiated between a prospective working group Chair and the relevant Area Director, although final approval is made by the IESG and all charters are reviewed by the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks. A charter: 1. Lists relevant administrative ASPects of 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, the Area Director and the IESG Secretary are satisfied with the charter form and content, it becomes the basis for forming a working group. The AD may require an initial draft of a charter to be available prior to holding an exploratory Birds of a Feather (BOF) meeting, as described below. Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group. Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering concrete "products". Specifically, each charter consists of 6 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 IETF directories, mailing lists, and general documents. Chair(s) The working group may have one or two Chair(s) to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Area and Area Director(s) The name of the IETF area with which the working group is affiliated and the name and electronic mail address of the associated Area Director. Mailing list It is required that an IETF working group have a general Internet mailing list. Most of the work of an IETF working group will be conducted that. The charter shall include: The address to which a participant sends a subscription request and the procedures to follow when subscribing, The address to which a participant sends submissions and special procedures, if any, and The location of the mailing list archive, if any. A message archive should be maintained in a public place which can be Accessed via FTP. The ability to retrieve from the archive via electronic mail requests also is recommended. Additionally, the address: ietf-archive@cnri.reston.va.us shall be included on the mailing list. NOTE: It is strongly suggested that the mailing list be on a host directly connected to the IP Internet to facilitate use of the SMTP expansion command (EXPN) and to allow mail archive access via FTP, gopher and the like in keeping with the general IETF rule for openness. If this is not possible, the message archive and membership of the list must be made available to those who request it by sending a message to the list-request alias. 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 will frequently be used as an overview of the working group's effort. The terms "they", "them" and "their" are used in this document as third-person singular pronouns. To facilitate evaluation of the intended work and to provide on-going guidance to the working group, the charter shall describe the problem being solved and shall discuss objectives and expected impact with respect to: - Architecture - Operations - Security - Network management - Transition (where applicable) Goals and milestones The working group charter must establish a timetable for work. While this may be re-negotiated 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., "Internet-Draft 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. Updated milestones are re-negotiated with the Area Director and the IESG, as needed, and then are submitted to the IESG Secretary: IESG-secretary@cnri.reston.va.us An example of a WG charter is in Appendix A. 2.3. Charter review & approval Working groups often comprise technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design. To facilitate working group efforts, an Area Director may assign an Area Consultant from among the ranks of senior IETF participants. (Area Consultants are described in the section of Staff Roles.) At the discretion of the AD, approval of a new WG may be withheld in the absence of sufficient Consultant resources. Once the Area Director (and the Area Directorate, as the AD deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the Internet Engineering Steering Group using the criteria described previously. The Internet Architecture Board (IAB) will review the charter of the proposed WG to determine the relationship of the proposed work to the overall architecture of the Internet Protocol Suite. The approved charter is submitted to the IESG Secretary who records and enters the information into the IETF tracking database and returns the charter in a form formatted by the database. The working group is announced to the IETF mailing list by the IESG Secretary. 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 IETF offers the possibility of a Birds of a Feather (BOF) session, as well as the early formation of an email list for preliminary discussion. Alternatively, 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 an IETF 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 relevant Area Director. The person who requests the BOF is usually appointed as Chair of the BOF. The Chair of the BOF is also responsible for providing a report on the outcome of the BOF. The AD may require the conduct of email discussion, 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 AD may require that a BOF be held, prior to establishing a working group, and the AD may require that there be a draft of the WG charter prior to holding a BOF. 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; - 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. There is an increasing demand for BOF sessions at IETF meetings. Therefore the following rules apply for BOFs: - All BOFs must have the approval of the appropriate Area Director. The Secretariat will NOT schedule or allocate time slots without the explicit approval of the Area Director. - The purpose of a BOF is to conduct a single, brief discussion or to ascertain interest and establish goals for a working group. All BOF organizers are required to submit a brief written report of what transpired during the BOF session together with a roster of attendees to the IESG Secretary for inclusion in the Proceedings. - A BOF may be held only once (ONE slot at one IETF Plenary meeting). - Under unusual circumstances an Area Director may, at their discretion, allow a BOF to meet for a second time. Typically (though not a requirement) this is to develop a charter to be submitted to the IESG. - BOFs are not permitted to meet three times. - A BOF may be held for single-event discussion, or may pursue creation of normal IETF working groups for on-going interactions and discussions. When the request for a BOF comes from a formally-constituted group, rather than from an individual, the rules governing the handling of the request are the same as for all other BOFs and working groups. - When necessary, WGs will be given priority for meeting space over BOFs. 3. WORKING GROUP OPERATION The IETF has basic requirements for open and fair participation and for thorough consideration of technical 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". A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair 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 have evolved over time that have proven successful. These are listed here, with actual choices typically determined by the working group participants and the Chair. 3.1. Session planning For coordinated, structured WG interactions, the Chair must publish a draft agenda well in advance of the actual session. The agenda needs to 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 shall include sending a copy to the working group mailing list and to the IETF-Announce list. Notices for the IETF-Announce list should be sent to: ietf-announce-post@cnri.reston.va.us 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. It is common, but not required, that a working group will meet at the trimester IETF Plenary events. Additionally, interim sessions may be scheduled for telephone conference, video teleconference, or for face-to-face (physical) sessions. All working group sessions (including those held outside of the IETF 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 IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@cnri.reston.va.us 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. Also note that decisions reached during IETF meetings are NOT final, but must be conveyed to the mailing list to verify WG consensus. IETF Meetings If a WG needs a session at an IETF meeting, the Chair must apply for time-slots as soon as the first announcement of that IETF meeting is made by the IETF Secretariat to the WG-chairs list. Session time is a scarce resource at IETF 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 IETF meeting shall be made to the IETF Secretariat. Alternatively some Area Directors may want to coordinate WG sessions in their area and request that time slots be coordinated through them. After receiving all requests for time slots by WGs in the area, the Area Director(s) form a draft session- agenda for their area, which is then sent to the WG chairs of the area. After approval it will be sent to the IETF Secretariat. An application must contain: - 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 must not be scheduled for the same time slot(s); and - Individuals whose attendance is desired. The Secretariat allots time slots on the basis of the session-agenda made by the Area Director(s). If the proposed session- agenda for an area does not fit into the IETF meeting-agenda, the IETF Secretariat will adjust it to fit, after consulting the Area Director(s) and the relevant chairs. The Secretariat will then form a draft session- agenda and distribute it among the Working Group Chairs for final approval. 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 IETF 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. 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. 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 IETF meetings, due to the time and expense required to attend. 3.3. Session management Working groups make decisions through a "rough consensus" process. IETF 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 balloting, humming, or any other means on which the WG agrees (by rough consensus, of course). 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 direct a discussion 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 overview In the course of group design processes, strife happens. Strife and contention are particularly likely when working groups comprise many constituencies. On the other hand differences in view are vital to the success of the IETF and healthy debate is encouraged. Sometimes debates degenerate into something akin to warfare. For these circumstances, the IETF has an extensive review and appeals process. Formal procedures for requesting review and conducting appeals are documented in The Internet Standards Process [1]. A brief summary is provided, here. In fact the IETF approach to reviews and appeals is quite simple: When an IETF participant feels that matters have not been conducted properly, they should state their concern to a member of IETF management. In other words, the process relies upon those who have concerns raising them. If the result is not satisfactory, there are several levels of appeal available, to ensure that review is possible by a number of people uninvolved in the matter in question. Reviews and appeals step through four levels, each in turn: WG Chair An appeal must begin with the management closest to the operation of the working group, even if the concern applies to their own handling of working group process. Area If discussion and review with the WG Chair do not produce a satisfactory result, the complainant may bring their concern to the cognizant Area Director. IESG If a concerned party is not satisfied with the results of the area-level review, then they may bring the matter to the IESG Chair and the Area Director for Standards & Processes. The IESG Chair and the Standards & Processes AD will bring the issue before the full IESG for an additional review and will report the resolution back to the parties. IAB The IAB provides a final opportunity to appeal the results of previous reviews. If a concerned party does not accept the outcome of the IESG review, then they may take their concern to the IAB, by contacting the IAB Chair. Concerns entail either a disagreement with technical decisions by the working group or with the process by which working group business has been conducted. Technical disagreements may be about specific details or about basic approach. When an issue pertains to preference, it should be resolved within the working group. When a matter pertains to the technical adequacy of a decision, review is encouraged whenever the perceived deficiency is noted. For matters having to do with preference, working group rough consensus will dominate. When a matter pertains to working group process, it is important that those with a concern be clear about the manner in which the process was not open or fair and that they be willing to discuss the issue openly and directly. In turn, the IETF management will make every effort to understand how the process was conducted, what deficiencies were present (if any) and how the matter should be corrected. The IETF functions on the good will and mutual respect of its participants; continued success requires continued attention to working group process. 4. WORKING GROUP TERMINATION Working groups are typically chartered to accomplish a specific task. After that task is complete, the group will be disbanded. However if a WG produces a Proposed or Draft Standard, 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 work as it moves to Draft Standard and Standard status.) If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, the group, in consultation with its Area Director can either: 1. Recharter to refocus on a smaller task, 2. Choose new Chair(s), or 3. Disband. If the working group disagrees with the Area Director's choice, it may appeal to the IESG. 5. 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. 5.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. This encompasses at the very 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. 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 specification Editor to one or two participants. Often, 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 are structured as true meetings, conducted over the course of several days (to allow participation across the Internet.) Participants are expected to allocate time to the meeting, usually in the range of 1-2 hours per day of the "meeting". Organize, prepare and chair face-to-face & on-line formal sessions The Chair should plan and announce sessions well in advance. (See section on Session Planning for exact procedures.) 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 the section on Session Documents for detailed procedures. Immediately after a session, the WG Chair must immediately provide the Area Director with a very short report (approximately one paragraph, via email) on the session. This is used in an Area Report as presented in the Proceedings of each IETF meeting. Distribute the work 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 will make sure that authors of WG documents incorporate changes as discussed by the WG. See the section on Session Documents for details procedures. Document publication The Chair and/or Secretary will work with the RFCEditor to ensure document conformance with RFCpublication requirements and to coordinate any editorial changes suggested by the RFCEditor. A particular concern is that all participants are working from the same version of a document at the same time. 5.2. WG Editor/Secretary Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Editor's job is to record WG decisions, rather than to perform basic specification. 5.3. 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. 5.4. Design teams The majority of the detailed specification effort within a working group may be done by self-selecting sub-groups, called design teams, with the (implicit or explicit) approval of the working group. The team may hold closed sessions for conducting portions of the specification effort. In some cases design teams are necessary to make forward progress when preparing a document. All work conducted by a design team must be available for review by all working group participants and the design team must be responsive to the direction of the working group's consensus. 5.5. Area Consultant At the discretion of the AD, a Consultant may be assigned to a working group. Consultants are senior participants in the IETF community. They have technical background appropriate to the WG and experience in Internet architecture and IETF process. 5.6. Area Director Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. This very general description encompasses at the very least these detailed tasks related to working groups: Area planning The Area Director determines activities appropriate to the area. This may include initiating working groups directly, rather than waiting for proposals from IETF participants. Coordination of WGs The Area Director coordinates the work done by the various WGs within (and sometimes even outside) the relevant area. IETF Meeting Schedule The Director tries to coordinate sessions in such a way that experts can attend the relevant sessions with a minimum of overlap and gaps between sessions. (See section on WG sessions for details.) Reporting The Area Director reports to the IETF on progress in the area. Reviewing The Area Director may appoint independent reviewers prior to document approval. The Area Director tracks the progress of documents from the area through the IESG review process, and report back on this to the WG Chair(s). Progress tracking The Area Director tracks and manages the progress of the various WGs with the aid of a regular status report on documents and milestones that is generated by the IESG Secretary. The Area Director forwards this report to the WG chairs. This in turn helps the chairs to manage their WGs. 5.7. Area Directorate An area directorate consists of senior members of the technical community and are appointed by the Area Director who then tasks them with technical oversight and review of specific area activities. An Area Director chairs the directorate. At the request of the AD, directorate members conduct specification reviews and may be assigned as Area Consultants, to provide architectural assistance. 6. WORKING GROUP DOCUMENTS 6.1. Session documents All relevant documents for a session (including the final agenda) should be published and available at least two weeks before a session starts. It is strongly suggested that the WG Chair make sure that an anonymous FTP directory be available for the upcoming session. All relevant documents (including the final agenda and the minutes of the last session) should be placed in this directory. This has the advantage that all participants can FTP all files in this directory and thus make sure they have all relevant documents. Also, it will be helpful to provide electronic mail-based retrieval for those documents. 6.2. IETF meeting document archive In preparing for an IETF meeting it is helpful to have ready access to all documents that are being reviewed. While documents usually are placed in the internet-drafts Internet Repository or in the respective working group archives or just published in some mail- lists, there are just too many things to browse or read through. Also, many documents are modified immediately before a meeting. The InterNIC Directory and Database Services provides a current- ietf-docs archive to enable people to get all documents that are relevant for the up-coming IETF meeting. This document database will be removed two weeks after the IETF meeting. The completeness of this archive depends on the authors and working group chairs submitting the documents. Each WG Chair is requested to submit the agenda to this archive. Structure of the archive: On ds.internic.net documents will be stored under the appropriate working group name under the appropriate area name in the directory: /pub/current-ietf-docs Each area will also have a directory called bof where a document to be discussed in a BOF meeting will be placed. At the area level a directory called plenary will be created to hold documents or presentation material related to a plenary session. Any filename conflicts will be resolved by the InterNIC's administrator and the submitter will be informed via electronic mail. Example: /pub/current-ietf-docs/app/osids /pub/current-ietf-docs/int/sip Access via anonymous FTP: Anonymous FTP to ds.internic.net and change directory to /pub/current-ietf-docs/ and browse and get the document of interest. Access via gopher: Connect to gopher.internic.net and select the menu item: 4. InterNIC Directory and Database Services (AT&T)/ and then the menu item: 3. Documents to be reviewed at the *** IETF One may use the public-access gopher client by: telnet gopher.internic.net Submission of documents via anonymous FTP: FTP to ds.internic.net and login as anonymous. Change directory to: /incoming/current-ietf-docs Put the document using the following filename convention, <area>.<wgname>.<filename> e.g.: plenary.mondayVGs.ps app.osids.agenda app.osids.internic-talk-VGs.ps Note that the names of areas and working groups are their official short-form acronyms, Submission of documents via electronic mail: Send mail to admin@ds.internic.net with the following subject line: IETF - <area>.<wgname>.<filename> e.g.: IETF - app.osids.agenda NOTE: Instead of sending a fresh copy of an already available document, you may ask the InterNIC's administrators to create a link to an existing internet-draft/RFC/ID NOTE: If you do not remember your area or working group acronym get the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous FTP. 6.3. Internet-Drafts (I-D) The Internet-Drafts directory is provided to working groups as a resource for posting and disseminating early 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 Internet-Drafts are working documents and have no official standards status whatsoever. They may, eventually, turn into a standards-track document or they may sink from sight. Internet-Drafts are submitted to: internet-drafts@cnri.reston.va.us The format of an Internet-Draft must be the same as for an RFC[2]. Further, an I-D must contain: - Beginning, standard, boilerplate text which is provided by the Secretariat; - The I-D filename; and - The expiration date for the I-D. Complete specification of requirements for an Internet-Draft are found in the file: 1id-guidelines.txt in the internet-drafts directory at an Internet Repository site. 6.4. Request For Comments (RFC) The work of an IETF working group usually results in publication of one or more documents, as part of the Request For Comments (RFCs) [2] series. This series is the archival publication record for the Internet community. A document can be written by an individual in a working group, by a group as a whole with a designated Editor, or by others not involved with the IETF. The designated author need not be the group Chair(s). NOTE: The RFCseries is a publication mechanism only and publication does not determine the IETF status of a document. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards. For a description on the various categories of RFCs the reader is referred to [1, 4, 5, 6]. 6.5. Submission of documents When a WG decides that a document is ready for publication, the following must be done: - The version of the relevant document as approved by the WG must be in the Internet-Drafts directory; - The relevant document must be formatted according to RFC rules [2]. - The WG Chair sends email to the relevant Area Director, with a copy to the IESG Secretary. The mail should contain the reference to the document, and the request that it be progressed as an Informational, Experimental, Prototype or standards-track (Proposed, Draft or Internet Standard) RFC. The IESG Secretary will acknowledge receipt of the email. Unless returned to the WG for further development, progressing of the document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFCEditor and the WG Chair and Editor. 6.6. Review of documents Usually in case of a submission intended as an Informational or Experimental RFCminimal review is necessary. However, if the WG or the RFCEditor thinks that an extensive review is appropriate, the Area Director may be asked to conduct one. This review may either be done by the AD and other IESG participants or the IESG may ask for an independent review (e.g., by someone not part of the WG in question) from the Area Directorate or elsewhere. A review will lead to one of three possible conclusions: 1. The document is accepted as is. This fact will be announced by the IESG Secretary to the IETF mailing list and to the RFCEditor. Publication is then further handled between the RFCEditor and the author(s). 2. Changes regarding content are suggested to the author(s)/WG. Suggestions must be clear and direct, so as to facilitate working group and author correction of the specification. Once the author(s)/WG have made these changes or have explained to the satisfaction of the reviewers why the changes are not necessary, the document will be accepted for publication as under point 1, above. 3. The document is rejected. This will need strong and thorough arguments from the reviewers. The whole IETF and working group process is structured such that this alternative is not likely to arise for documents coming from a working group. After all, the intentions of the document will already have been described in the WG charter, and reviewed at the start of the WG. 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 procedural complaints is described in the section on Contention and Appeal. Before the IESG makes a final decision on a standards-track document, the IESG Secretary will issue a "Last Call" to the IETF mailing list. This Last Call will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF 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 cannot serve as a more general, in-depth review. 7. SECURITY CONSIDERATIONS Security issues are not discussed in this memo. 8. REFERENCES [1] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC1602, IAB, IESG, March 1994. [2] Postel, J., "Instructions to RFCAuthors", RFC1543, USC/Information Sciences Institute, October 1993. [3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to the F.Y.I. Notes", RFC1150, Proteon, USC/Information Sciences Institute, March 1990. [4] Postel, J., Editor, "Introduction to the STD Notes", RFC1311, USC/Information Sciences Institute, March 1992. [5] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC1600, IAB, March 1994. [6] Cerf, V., "The Internet Activities Board", RFC1160, NRI, May 1990. 9. AUTHORS' ADDRESSES Erik Huizer SURFnet bv P.O. Box 19035 3501 DA Utrecht The Netherlands Phone: +31 30 310290 Fax: +31 30 340903 EMail: Erik.Huizer@SURFnet.nl Dave Crocker Silicon Graphics, Inc. 2011 N. Shoreline Blvd. P.O. Box 7311 Mountain View, CA 94039 Phone: +1 415 390 1804 Fax: +1 415 962 8404 EMail: dcrocker@sgi.com APPENDIX: SAMPLE WORKING GROUP CHARTER Multiparty Multimedia Session Control (mmusic) Charter Chair(s): Eve Schooler <schooler@isi.edu> Abel Weinrib <abel@bellcore.com> Transport Area Director(s) Allison Mankin <mankin@cmf.nrl.navy.mil> Mailing lists: General Discussion:confctrl@isi.edu To Subscribe: confctrl-request@isi.edu Archive: venera.isi.edu:~/confctrl/confcrtl.mail Description of Working Group: The demand for Internet teleconferencing has arrived, yet an infrastructure to support this demand is barely in place. Multimedia session control, defined as the management and coordination of multiple sessions and their multiple users in multiple media (e.g., audio, video), is one component of the infrastructure. The Multiparty Multimedia Session Control Working Group is chartered to design and specify a protocol to perform these functions. The protocol will provide negotiation for session membership, underlying communication topology and media configuration. In particular, the protocol will support a user initiating a multimedia multiparty session with other users ("calling" other users) over the Internet by allowing a teleconferencing application on one workstation to explicitly rendezvous with teleconferencing applications running on remote workstations. Defining a standard protocol will enable session-level interoperability between different teleconferencing implementations. The focus of the working group is to design a session negotiation protocol that is tailored to support tightly-controlled conferences. The MBONE currently carries primarily loosely- controlled sessions, i.e., sessions with little to no interaction among members and with no arbitration facility, security, or coordination of quality-of-service options for time-critical media. Users may learn of available sessions using the "sd" utility or other out of band mechanisms (e.g., email). However, there is clearly also a need for tightly-controlled sessions that provide mechanisms for directly contacting other users to initiate a session and for negotiating conference parameters such as membership, media encodings and encryption keys. In addition, these sessions should support renegotiation during a session, for example to add or delete members or change the media encoding. It is possible that the protocol will, in the limiting case, also support loosely-controlled sessions. The main goal of the working group will be to specify the session control protocol for use within teleconferencing software over the Internet. The working group will focus on the aspects of the session control problem that are well understood, while keeping an eye on evolving research issues. Toward this end, the working group has made an inventory of existing conferencing systems and their session control protocols. The working group will document the requirements of the existing prototypes as a basis for the protocol development. The working group will iteratively refine the protocol based on implementation and operational experience. Furthermore, the working group will coordinate with other efforts related to multimedia conferencing, such as directory services for cataloguing users and conferences, the RTP and RTCP protocols developed by the Audio/Video Transport Working Group, resource reservation and management at the network level, and schemes for multicast address allocation. Goals and Milestones: May 93 Hold an on-line working group meeting to discuss the conference control framework, the relevant terminology, a functional taxonomy and how different conversational styles place requirements on session protocols. Jun 93 Submit the Conference Session Control Protocol to the IESG for consideration as an Experimental Protocol. Aug 93 Post an Internet-Draft describing the Session Control Requirements. Nov 93 Post an Internet-Draft of the Session Control Protocol. Mar 94 Submit a revised Internet-Draft based on implementation experience.
󰈣󰈤
 
 
 
>>返回首页<<
 
 热帖排行
 
 
静静地坐在废墟上,四周的荒凉一望无际,忽然觉得,凄凉也很美
©2005- 王朝网络 版权所有