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.