Network Working Group Internet Engineering Steering Group
INTERNET-DRAFT Erik Huizer
SURFnet bv
December 1992
IETF Working Group Guidelines and Procedures
Status of this Memo,
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
When finalized the draft document will be submitted to the RFC editor
as an informational document. Distribution of this memo is unlimited.
Please send comments to the author.
Abstract
The Internet Engineering Task Force (IETF) has the primary
responsibility for the development and review of potential Internet
Standards from all sources. The IETF is organized into Working Groups
(WG). This document describes the guidelines and procedures for
formation and operation of an IETF Working Group. It describes the
formal relationship between a WG and the Internet Engineering and
Steering Group (IESG). The basic duties of a WG chair and an IESG Area
Director are defined.
The expiration date of this internet draft is 15th July 1993.
Contents
Introduction
Acknowledgements
WG formation
Charter
Review of charter
Announcement
Birds of a Feather sessions (BOFs)
WG meetings
WG policies and procedures
Document procedures
Internet-Drafts
RFCs
Progression of documents
Review of documents
Termination of a WG
WG chair duties
AD duties
Security Considerations
Authors address
References
Appendix: Sample Working Group charter
Introduction
-----------
This document defines guidelines and procedures for Internet
Engineering Task Force Working Groups.
The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and
procedures defined by Internet Standards, commonly known as "the TCP/IP
protocol suite". The Internet Standards Process is defined in RFC
1310bis [1].
The primary responsibility for the development and review of potential
Internet Standards from all sources is delegated by the Internet
Society [2] to the Internet Engineering Task Force (IETF). The goals,
structures and procedures of the IETF can be found in it's charter [3].
The Internet Engineering Task Force is chaired by the IETF Chair and
managed by its Internet Engineering Steering Group (IESG). The IETF is
a large open community of network designers, operators, vendors, and
researchers concerned with the Internet and the Internet protocol
suite. It is organized around a set of technical areas, each managed by
one or two technical Area Directors (AD). In addition to the IETF
Chairman, the Area Directors make up the IESG membership. Each Area
Director has primary responsibility for one area of Internet
engineering activity, and hence for a subset of the IETF Working
Groups. At present there are eight areas, though this number may change
over time:
1) Applications
2) User Services
3) Internet Services
4) Routing
5) Network Management
6) Operational requirements
7) Security
8) Transport and Services
Each Area has an Area Directorate to support the Area Directors a.o.
with the review of documents produced in the area. The Area Directorate
is formed by the Area Director(s) from senior members of Working Groups
(WG) within the area.
The work of the IETF is performed by subcommittees 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.
Any member of the Internet community with the time and interest is
urged to attend IETF meetings and to participate actively in one or
more IETF Working Groups. Participation is by individual technical
contributors, rather than 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 reader is encouraged to read the IETF Charter [3] and the RFC on
the Internet Standards process [1]. Familiarity with these documents is
essential for an understanding of the procedures and guidelines
described in this document.
Acknowledgements
This document is largely due to the copy-and-paste function of a
wordprocessor.Several passages have been taken from the documents cited
in the reference section. Three people deserve special mention, as
especially large chunks of their documents have been integrated into
this one: Vint Cerf [8] from whom I borrowed the description of the
IETF. Greg Vaudreuil and Steve Coya [9] provided several paragraphs and
detailed feedback. All the errors you'll find are probably mine.
Working Group formation
----------------------
IETF Working Groups (WGs) are the primary mechanism for the development
of IETF protocols, standards, and recommendations. A Working Group may
be established under the direction of an Area Director (AD), or its
creation may be initiated by an individual, or group of individuals.
Anyone interested in creating an IETF Working Group must consult with
the appropriate IETF Area Director under whose direction the Working
Group would fall, to confirm that creating a Working Group is
appropriate.
A Working Group is typically created to address a specific problem or
produce a specific deliverable (document, RFC, 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 Area Director and
the Working Group chair and membership, the objectives or assignment of
the Working Group may be extended by enhancing or adding to the Working
Group's statement of objectives
When determining if creating a Working Group is appropriate, the Area
Director will consider several issues:
o Are the issues that the Working Group plans to address important?
o Does the work that the WG intends to undertake fit in with the
Architecture as understood by the IESG/IAB.
o Does the Working Group's activities overlap with those of another
Working Group? If so, it may still be appropriate to create another
Working Group, but this question must be considered carefully by the
Area Director as subdividing efforts often dilutes the available
technical expertise.
o Are there several people clearly interested in the Working Group's
topic and willing to expend the effort to produce a result (such as
an RFC)? Working Groups require considerable manpower: a chairman is
needed to run meetings, an editor to edit authors' submissions, and
authors to actually write text. IETF experience suggests that these
roles typically cannot all be handled by one person, four or five
active members are typically required. If the necessary manpower is
lacking, the person interested in creating the Working Group might
consider actually writing the RFC alone and submitting it for
review, rather than attempting to create a Working Group.
Considering the above criterion, the Area Director will decide whether
to pursue the formation of the group through the chartering process.
Charter
The formation of a Working Group requires an approved statement of
direction or objectives along with establishing the administrative
aspects of the Working Group which involves identifying the WG Chair or
co-Chairs, the WG secretary (which can also be the WG chair), and the
creation of a mailing list. This information is included in the Working
Group Charter.
The content of the charter document is negotiated between a prospective
Working Group chair and the relevant Area Director. The work statement
must explain the general purpose of the group, define its technical
scope, enumerate a set of goals and milestones together with time
frames for their completion, and document various administrative
points. When both the prospective Working Group chair and the Area
Director are satisfied with the charter text, it becomes the basis for
forming a Working Group. The charter document may be similarly
renegotiated or modified at any time during the course of the Working
Group's effort to reflect the changing goals of the group.
Each charter consists of five sections. These sections include
information about the Working Group (the name, the chairmen,
objectives, goals and milestones, and the mailing lists. The goals and
milestones are part of the IETF tracking system, and are designed to
allow a degree of project management and support. They may change
periodically to reflect the current status or organization of the
Working Group.
1. Working Group Name:
A Working Group name should be reasonable descriptive or
identifiable. Additionally, the group needs to define an 8 character
ASCII acronym to reference the group in the IETF directories,
mailing lists, and general documents.
2. Working Group Chair(s):
The Working Group may have one or two chair(s) to perform the
administrative functions of the group. It is strongly suggested that
these individuals have Internet mail addresses.
3. Working Group Description:
In one to two paragraphs, the focus and intent of the group should
be set forth. By reading this section alone, an individual should be
able to decide whether this group is relevant to their work.
Recognizing the importance of security and network management in the
Internet Architecture, this description of the work of the group
must specifically address the impact in terms of security and
management.
4. Goals and Milestones:
The Working Group should, after the first meeting, be able to
establish a timetable for work. While this may change over time, the
list of milestones and dates facilitate the Area Director's tracking
of Working Group progress and status, and it is indispensable to
potential participants to be able to identify the critical moments
for input. Milestones should consist of deliverables that can be
qualified as such, e.g. 'Internet-draft finished' is fine, but
'discuss via E-mail' is not. This milestone list is expected to be
updated periodically. Updated milestones should be submitted along
with meeting minutes to the IETF Secretariat
(iesg-secretary@cnri.reston.va.us).
5. Mailing Lists:
Most of the work of an IETF Working Group is conducted on Internet
Mail exploder lists. It is required that an IETF Working Group have
a general discussion list. An individual needs to be designated as
the list service postmaster, usually through the list-request alias
mechanism. A message archive should be maintained in a public place
which can be accessed via FTP. The IETF-archive@cnri.reston.va.us
should be included on the mailing list.
Note: It is strongly suggested that the mailing list be on an connected
IP host, to facilitate use of the SMTP expansion command (EXPN) and to
allow access via FTP to the mail archives. If this is not possible, the
message archive and membership of the list must be made available to
those who make such a request by sending a message to the list-request
alias. The list maintainer or archiver need not be the Working Group
chairman or secretary, but may be a member of the Working Group itself.
An example of a WG charter can be found in appendix A.
Charter Review
Once the Area Director has approved the Working Group charter, the
charter is submitted to the Internet Engineering and Steering Group and
Internet Architecture Board for review and approval.
The IESG will primarily consider if :
- the WG has no overlap with WGs in other areas;
- there is sufficient expertise in the IETF to review the results of
the WG;
The Internet Architecture Board (IAB) will review the charter of the
proposed WG to see whether the proposed work is relevant to the overall
architecture of the Internet Protocol Suite.
The approved charter is submitted to the IESG secretary (currently at
CNRI) who records and enters the information into the IETF tracking
database and returns the charter in form formatted by the database.
Using this reformatted charter, the Working Group is announced by the
IESG Secretary to the IETF mailing list.
Birds of a Feather (BOF)
For an individual, or small group of individuals, it is often not clear
if the issue(s) at hand merit the formation of a WG. To alleviate this
problem the IETF offers the possibility of a Birds of a Feather (BOF)
session.
A BOF is a session at an IETF where a brainstorm type of discussion is
held on a subject proposed by the chair(s) of the BOF. Any individual
(or group of individuals) can request permission to hold a BOF on a
certain subject. The request has to 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.
Usually the outcome of a BOF will be one of the following:
- There was enough interest in the subject to warrant the formation of
a WG;
- The discussion came to a fruitful conclusion, the results will be
written down and published as a RFC. There is no need to establish
a WG;
- 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 as a rule it is not allowed to have multiple BOF sessions on
the same subject at IETF meetings.
Working Group Meetings
---------------------
The Working Group is expected to meet periodically to discuss and
review task status and progress, and to direct future activities. It is
expected, but not required that every Working Group meet at the
trimester IETF plenary sessions. Additionally, interim meetings are
encouraged by telephone conference, video teleconference, or by actual
face to face meetings. Meetings should be publicized as widely as
possible, by announcing their time and location on the Working Group
mailing list etc. When a meeting is held outside of an IETF session,
the WG meeting should be announced to the IETF mailing list too.
All Working Group sessions (also the ones held outside of the IETF
sessions) should be reported by making minutes available. These minutes
should include the agenda for the meeting, an account of the discussion
including any decisions made, and a list of attendees. The Working
Group chair is responsible for insuring that meeting minutes are
written and distributed, though the actual task may be performed by the
Working Group secretary or someone designated by the Working Group
chair. The minutes submitted in ASCII text for publication in the IETF
Proceedings, and for posting in the IETF Directories.
If a WG wants to meet at an IETF meeting, it has to apply for a
timeslot. In order to be efficient with allocation of sparse time-
slots, and in order to coordinate as well as possible WGs that require
more or less the same subset of experts (such that these experts do not
waste time due to gaps between meetings), the WG chair needs to apply
for a meeting at an IETF to the secretariat, as soon as the first
announcement of that IETF meeting is made by the IETF secretariat to
the wg-chairs list.
The application for a WG meeting at an IETF meeting needs to be made to
the IETF secretariat, and it needs to contain:
- the amount of time requested;
- the rough outline of the agenda that is expected to be covered;
- the estimated number of people that will attend the WG meeting.
The secretariat will form a draft agenda and distribute it among the
wg-chairs for approval.
Alternatively some Area Directors may want to coordinate WG meetings in
their area and request that timeslots be coordinated through them.
After receiving all requests for timeslots by WGs in the area, the Area
Director(s) form a draft agenda for their area, which will be send to
the WG chairs of the area. After approval it will be send to the IETF
secretariat. The secretariat allots the timeslots on basis of the
agenda made by the Area Director(s). If the proposed 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.
WG policies and procedures
-------------------------
All Working Group actions should be public, and wide participation
encouraged. Announcements of meeting dates and time must be sent to the
Working Group mailing list and to mdavies@cnri.reston.va.us a
reasonable time before the meeting.
All Working Groups are autonomous, and each may have their own policies
and procedures with respect to meeting participation, reaching closure,
etc. Generally, acceptance or agreement is achieved via Working Group
consensus, though some Working Groups may decide that a simple
majority, significant majority (two thirds) or unanimous agreement is
required. A number of procedural questions and issues have risen over
time, and it is the function of the Working Group chair to manage this
process, keeping in mind that the overall purpose of the group is to
make progress towards realizing the Working Group's goals and
objectives.
There are no 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. Some of these "topics" are
listed here. Note that the choice of options is typically determined by
the Working Group members and the chairman.
1. The chair is encouraged to publish a draft agenda well in advance of
the actual meeting. The agenda needs to contain at least:
- items for discussion;
- estimated time necessary per item;
- clear indication of what documents the participants will need to
read before the meeting in order to be well prepared. The
documents should be publicly available (preferably as Internet-
drafts, see next section) and the "where and how to get them"
should be indicated.
2. All relevant documents for a meeting (including the final agenda)
should be published and available at least two weeks before the
meeting starts.
3. It is strongly suggested that the WG chair creates an anonymous FTP
directory specially for the upcoming meeting. All relevant documents
(including the final agenda and the minutes of the last meeting)
should be placed in this directory. This has the advantage that all
participants can just ftp all files in this directory and thus make
sure they have all relevant documents.
4. After a period of open meetings, the Working Group chair may hold
executive (closed) meetings of the Working Group consisting of the
authors of a particular document and any serious reviewers. This is
often necessary to make forward progress preparing a final document.
All work conducted in executive session must be made available for
review by all Working Group members.
5. It is acceptable to have restricted participation (not attendance!)
at IETF Working Group meetings for the purpose of achieving
progress. The Working Group chairman usually has the authority to
refuse to grant the floor to any unprepared individual.
6. Many Working Group participants hold that mailing list discussion is
the place to resolve issues and make decisions, while others
maintain that such should be accomplished only at IETF meetings.
Resolution and acceptance within the Working Group is resolved by
the Working Group.
7. Consensus can be determined by balloting, humming, or any other
means the WG will agree on (by consensus of course).
8. Repeated discussions on the same issues over E-mail can be avoided
if the chair makes sure that after a discussion has come to a
conclusion, the main arguments in the discussion (and the outcome)
are summarized and archived. It is also good practice to note
important decisions/consensus reached by E-mail in the minutes of
the next 'live' meeting.
Document procedures
-------------------
Internet Drafts
The IETF provides the Internet Drafts directories are provided to the
Working Groups as a resource to post and disseminate early copies of
any and all documents of the Working Group. This common repository is
available to all interested persons to facilitate wide review and
comment. It is encouraged that draft documents be posted as soon as
they become reasonably stable.
It is stressed here that Internet Drafts are drafts and have no
official status whatsoever.
Request For Comments (RFC)
The work of an IETF Working Group usually results in the publication of
one or more Request For Comments Documents (RFCs) [4]. This series of
documents are the journal of record for the internet community. A
document can be written by an individual in the Working Group or by the
group as a whole with a designated editor. The designated author need
not be the group chair(s).
Note: The reader is reminded that all Internet Standards are published
as RFCs, but NOT all RFCs specify standards!
For a description on the various subseries of RFCs the reader is
referred to [1,5,6,7].
Submission of documents
When a WG decides that a working document is ready for progression to
RFC, the following has to be done:
- The relevant document as approved by the WG has to be in the
Internet-Drafts directory;
- The relevant document has to be formatted according to RFC-rules
(see RFC-1111 [4]).
- The WG chair sends an E-mail, containing the reference to the
document, and the request that it be progressed as an
(Informational, experimental, prototype or proposed STD) RFC to the
Area Director(s), with a cc: to the IESG Secretary.
The Area Director(s) will acknowledge receipt of the E-mail. From then
onwards the progressing of the document is the responsibility of the
IESG.
Review of documents
In case the submission is intended for Informational only no review is
necessary. However if the WG or the RFC editor thinks that a review is
appropriate the AD can be asked to provide a review. In case of
submission as an Experimental, Prototype or Standards RFC, the document
will always be reviewed by the IESG. The review can either be done by
the AD and other IESG members or by independent (i.e. not having been
part of the WG in question) reviewers from the Area Directorate.
Before making a final decision on a document, the IESG 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.
The review will lead to one of three possible conclusions:
1- The document is accepted as is; This fact will be announced by the
IESG to the IETF mailing list and to the RFC Editor. Publication is
then further handled between the RFC editor and the author(s).
2- One or more changes regarding content are suggested to the
author(s)/WG. Once the author(s)/WG has made these changes or has
argued to the satisfaction of the reviewers why the change(s) is/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 good
argumentation from the reviewers. The whole process is structured
such that this situation is not likely to arise for documents coming
from a Working Group. After all the intents of the document would
already have been described in the WG charter, and this has already
been reviewed at the outstart of the WG.
If any individual or group of individuals feels that the review
treatment has been unfair, there is the possibility to make a
procedural complaint. The mechanism for procedural complaints is
described in the Charter of the IETF [3].
Termination of a WG
-------------------
Working Groups are typically chartered to accomplish a specific task.
After that task is complete, the group will be disbanded. If after a
meeting a few times, it becomes evident that the 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.
In those situations where the Working Group chairperson and the Area
Director disagree about the steps required to refocus the group or the
need to disband the group, the IESG will make a determination with
input from the Area Director and the Working Group chair(s). Major
changes will need a review from the IAB.
WG chair duties
--------------
The Working Group chair(s) have wide discretion in the conduct of
business. The WG chair has to make sure that the WG operates in a
reasonably efficient and effective way towards reaching the goals and
results described in the WG charter. This very general description
encompasses at the very least the following detailed tasks:
- Moderate the WG distribution list;
The chair makes sure that the discussions on this list are relevant
and that they converge. The chair makes sure that discussions on the
list are summarized and the outcome is well documented (to avoid
repeats).
- Organize, prepare and chair face-to-face meetings;
The chair plans and announces the meeting well in advance (see
section on WG meetings for exact procedures). The chair makes sure
that relevant documents and the final agenda are ready at least 2
weeks in advance of the meeting. The Chair makes sure minutes are
taken, and that an attendance list is circulated. It is strongly
suggested that the WG chair creates an anonymous FTP directory
specially for the upcoming meeting. All relevant documents should be
placed in this directory.
- Communicate results of meeting;
The chair makes sure that minutes of the meeting are taken. After
screening the minutes the final version will be send to the Area
Director(s) and the IETF secretariat, in time for publication in the
IETF proceedings. The WG chair provides the Area Directors with a
very short report (preferably via E-mail) on the meeting directly
after the meeting took place. These reports will be used for the
Area Report as presented in the proceedings of each IETF meeting.
- Distribute the work;
Of course each WG will contain a lot of participants that may not be
able to (or want to) do any work at all. Most of the time the work
is done by a few experts. It is the tasks of the chair to motivate
enough experts to allow for a fair distribution of the workload.
- Progress documents.
The chair will make sure that authors of WG documents incorporate
changes as discussed by the WG. Once a document is approved by the
WG the chair reports to the Area Director(s) and the IESG secretary.
The chair indicates (per E-mail) which document has been approved,
and asks the IESG to review it for publication as an RFC (specify
experimental, proposed STD etc.). The Area Director will acknowledge
the receipt of the E-mail, and from then on the action is on the
IESG. See the section on review of documents for possible further
involvement of the chair in document progressing.
Area Director duties
-------------------
The Area Directors are responsible for a coherent, coordinated and
architecturally consistent output from the Working Groups in their area
as a contribution to the overall results of the IETF. This very general
description encompasses at the very least the following detailed tasks
related to the Working Groups:
- Coordination of WGs;
The Area Director(s) coordinate the work done by the various WGs
within (and sometimes even outside) the relevant Area. The
Director(s) try to coordinate meetings in such a way that experts
can attend the relevant meetings with a minimum of overlap and gaps
between meetings. (See section on WG meetings for details)
- Reporting;
The Area Director(s) report on the progress in the Area to the IETF.
- Reviewing;
The Area Directors appoint independent reviewers for document
reviewing. The Area Director(s) track 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 Directors track and manage the progress of the various WGs
with the aid of a regular status report generated by the IESG
secretary. The Area Directors forward this regular status reports on
documents and milestones made by the IESG Secretary to the WG
chairs. This in turn helps the chairs to manage their WGs.
- Area Directorate;
The Area Director chairs the Area Directorate. He is responsible for
regular meetings of the directorate.
Security Considerations
----------------------
Security issues are not addressed in this memo.
References
----------
[1] RFC1310bis
[2] Charter Internet Society
[3] New charter IETF
[4] RFC 1111 Request for Comments on Request for Comments, J. Postel,
August 1990.
[5] RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March 1990
[6] RFC 1311 Introduction to the Standards Notes, ed. J. Postel,
March 1992.
[7] RFC 1360 IAB Official Protocol Standards, ed. J. Postel, Sept.
1992.
[8] RFC 1160, The Internet Activities Board, V.Cerf, may 1990
(This should be OBE by [3] by the time this gets published)
[9] Guidelines to Working Group Chair(s), S. Coya, IESG distribution
only.
Authors address
---------------
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
The expiration date of this Internet draft is 15th July 1993
Appendix: Sample Working Group charter
------------------------------------
MIME-MHS Interworking (mimemhs)
Charter
Chair(s):
Steve Thompson <sjt@gateway.ssw.com>
OSI Integration Area Director(s)
Erik Huizer <huizer@surfnet.nl>
Dave Piscitello <dave@sabre.bellcore.com>
Mailing lists:
General Discussion:mime-mhs@surfnet.nl
To Subscribe: mime-mhs-request@surfnet.nl
Archive:
Description of Working Group:
MIME, (Multipurpose Internet Mail Extensions) currently an Internet
Draft, is expected to become an Internet Proposed Standard. MIME
redefines the format of message bodies to allow multi-part textual and
non-textual message bodies to be represented and exchanged without loss
of information. With the introduction of MIME as a Proposed Standard
it is now possible to define mappings between RFC-822 content-types and
X.400 body parts. The MIME-MHS Interworking Working Group is chartered
to develop these mappings, providing an emphasis on both interworking
between Internet and MHS mail environments and also on tunneling
through these environments. These mappings will be made in the context
of an RFC-1148bis environment.
Goals and Milestones:
Jan 92 Post an Internet Draft describing MIME-MHS Interworking.
Jan 92 Post an Internet Draft describing the ``core'' set of
Registered conversions for bodyparts.
Jul 92 Submit a completed document to the IESG describing MIME-MHS
Interworking as a Proposed Standard.
Jul 92 Submit the ``core'' bodyparts document to the IESG as a
Proposed Standard.