The area is managed by its area directors, Peter Saint-Andre <firstname.lastname@example.org> and Alexey Melnikov <email@example.com>.
They are ultimately responsible for all activity in the area, including
the setting of these rules, subject to the decisions of the IESG and
The basic rules for operating the IETF are written down in RFC 2026.
Table Of Contents
How to start a working group
A working group is started to do work that the IETF thinks should be done. Since you are the IETF, you decide!
The steps towards forming a working group are:
Changing a charter
Changing a charter requires that:
- The chair of the WG proposes the change to the WG, and achieves at least rough consensus on the charter.
chair sends the new charter to the Area Directors, with a CC to the
iesg-secretary, possibly with a CC to the WG, requesting that the
charter be updated. There will be no action taken by the ADs
until this mail is sent! The ADs read mailing lists, but it is the
responsibility of the chair to make an explicit request.
- The Area Directors approve the change, tell the IESG secretary to install the new charter, and inform the chair.
Terminating a working group
There are three reasons why a working group terminates:
- It has completed the items listed in the charter, and is satisfied with the result. GOOD!
group has reached consensus that the activity cannot or should not be
completed in this WG, and requests that it be disbanded. This, too, is
an E-mail from the Chair to the ADs, with a CC to the IESG-secretary.
ADs decide that the group is not going to complete its tasks in a
reasonable time or with reasonable quality, and decide to disband the
The third one is a drastic action, and not to be undertaken lightly,
but the following danger signs are things that the ADs will watch for:
- Charters with milestones more than 2 years past due
- The group not producing any new I-D within 6 months
- The group not meeting for 2 consecutive IETFs
- The group failing repeatedly to address problems that have been identified with their proposals
- The group mailing list being completely quiet for more than 2 months
- The group showing no signs of reaching convergence on important issues despite continuing debate.
None of these are by themselves things that clearly indicate that the
group should be disbanded, but if any of them apply to your group, it
should serve as a hint that you may get a call from the ADs soon.....
Requesting a WG meeting at the IETF
The ADs attempt to arrange an "area track" for each IETF meeting, so
that there is little or no overlap between groups in the Apps area.
In order to do this, it is important to watch the announcement lists,
and as soon as the announcement that the Secretariat is taking requests
for slots at the IETF, use the IETF Meeting Session Request Tool
to request a slot. (If you are a WG chair, you should have a
username/password for accessing it already. If you don't, send an email
to firstname.lastname@example.org.) Alternatively, you can use the old way, i.e. you send a message to the Area Directors, with a copy to email@example.com, telling us:
- That you need to meet
- How many people you expect
- How many meeting slots you want (more than one is difficult to get and might require AD approval)
- Whether you need MBONE coverage
- What groups you must (or would prefer to) avoid conflicts with
The cutoff date for all requests for slots is generally
about a month before the IETF, but the best locations and time slots
are often occupied much earlier, so get your name in early - preferably
within a week of the announcement!
See the IETF Meetings Page and follow the link to ``Next Meeting'' for WG scheduling request deadlines.
Requesting a BOF at the IETF
BOFs in the Apps area are requested the same way as WG slots are. In
particular, BOFs are lower priority than WGs; if a WG needs a space, a
BOF can get moved around.
Anyone can request a BOF, but a BOF cannot meet without the sponsorship
of its Area Director. (And going to multiple ADs for the BOF is not
necessarily a Good Thing; we DO talk about these things!)
What we need to schedule a BOF is:
- A name for the BOF
- A chairperson for the session
(convincing) description of the reasons why the BOF needs to meet. Mere
interest in the topic among people who might attend IETF is not, in
- Expected attendance
Again, the cut-off date for BOFs is usually a month before the IETF.
See the IETF Meetings Page and follow the link to ``Next Meeting'' for BOF scheduling request deadlines.
Holding an Interim Working Group Meeting
Most of the work done by a working group will be done on the mailing
list. Face to face meetings should, whenever possible, be held during
the IETF conferences.
Occasionally, working groups hold "interim" face-to-face meetings,
teleconferences and/or jabber meetings, between IETF meetings. Such
meetings must conform to the same rules as normal IETF working group
meetings. In particular:
- The time and location of the meeting must be approved in advance by the Area Directors.
- Meetings must be announced, well in advance, on both the working group mailing list and the IETF-Announce mailing list.
- All documents discussed at such meetings must be published as Internet-Drafts several days prior to the meeting.
agenda must be send to firstname.lastname@example.org, and circulated to the working
group mailing list, several days prior to the meeting. The agenda must
list any documents to be discussed at the meeting, which must be
published as internet-drafts.
- Attendance must be open to anyone who wishes to participate.
multiple face-to-face interim meetings are held by a working group,
locations of physical meetings should be chosen to reflect the
geographic diversity of the mailing list participants.
brief (one or two paragraph) summary of the meeting should be sent to
the Area Directors within a day or two following the meeting.
- Minutes must be recorded and sent to email@example.com, and the working group mailing list, within two weeks of the meeting.
Most results from working groups are published in the form of RFCs.
Before something becomes an RFC, it has to be submitted as an
Internet-Draft; see RFC 2418, section 7.2, for details on publishing I-Ds. The most important sentence in that chapter is:
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.
Please do not send copies of Internet-Drafts to the area directors unless we specifically ask you to do so.
Standards from a WG
The procedure for a WG publishing a standards-track document is:
- The WG achieves consensus that an Internet-Draft is ready to be published as a standard.
- The WG chair informs the ADs that the WG asks for it to be published (NOTE: The request must come from the WG chair, not
the document author!), in E-mail with CC to firstname.lastname@example.org.
The WG will not update the document after this point, unless there are
problems found later on, in which case the process must be restarted at
- The ADs review the document, or have it reviewed, and either accepts it or asks the WG to make revisions to it.
the ADs accept it, the AD tells the iesg-secretary to put out an IETF
Last Call (generally 2 weeks) on the document. Under some circumstances
and at AD discretion, the IETF Last Call may occur in parallel with AD
- If there are no significant objections raised in the Last Call period, the ADs ask the IESG to vote on the document.
- If the IESG accepts the document, it is published as a standards-track RFC.
Standards without a WG
The process for standards that are published without a WG is the same as for WG documents, with the following exceptions:
- The document author requests publication, instead of the WG chair.
- The IETF Last Call is (at a minimum) 4 weeks, not 2 weeks.
AD has the option of asking for a WG to be formed to consider the
problem, or of appointing an ad-hoc review committee, rather than
accepting the proposal.
Note that one possible action for the ADs is to ask the author to
submit the proposal for Experimental, so that it gets an RFC number,
and come back in 6 months or a year and ask for resubmission as a
Proposed Standard, because experience showed that it was useful.
(The procedure for submitting internet-drafts is given in the 1id-guidelines
document in the IETF shadow directories. Please do not send copies of
internet-drafts to the area directors unless we specifically ask you to
Informational or Experimental from a WG
The procedure is the same as for standards, but with the following modifications:
- The AD decides whether or not to make a Last Call on it.
Generally, Last Calls are only done when controversy is expected or
there appear to be questions which the WG has not resolved.
there is IESG review of these documents, the rules for approving such
documents are somewhat easier (no "DISCUSS" votes)
Informational or Experimental without a WG
There are 2 variety of this: one is similar to Standard Track
submission without a WG and an AD gets involved. Another one is direct
submission to RFC Editor (described below). THESE ARE NOT THE SAME
Anyone can have a document published as an RFC by E-mailing it to the
RFC editor and asking for it to be published, if he/she is able to
convince the RFC editor that it should be published.
However, one should consider:
- The RFC editor will ask the IESG if it wishes to comment on a document before deciding whether to publish the document or not
IESG has the option of inserting disclaimers into the "status of this
document" section, indicating, for instance, that this document is not considered for Standard, and that other, standards-track documents are better for the same purpose. IESG can also recommend not publishing the document, because a similar (competing) work is done in one of IETF WGs.
is considered polite to put out documents as Internet-Drafts for at
least a couple of weeks before publishing them, and asking for comments
on one or more mailing lists. This often helps improve the quality of
the documents too!
As all who have been with the IETF for a while know, IPR problems are a pain.
The most interesting discussions are found in RFC 2026 section 10; the basic tenets of which are:
- All IPR problems known to participants MUST be identified to the WG.
WG is expected to prefer non-encumbered technology whenever such
technology exists and is not significantly worse than the encumbered
- Where licensing is an issue, licensing MUST be
available on "reasonable and non-discriminatory terms". The first test
is whether 2 independent licenses have in fact been granted under such
terms between the Proposed and Draft status for the specification.
- Patents where the patent holder has filed a grant of rights to freely use the patent are not considered terribly encumbering.
For discussions of release of IPR, the correct address is the ISOC vice
president for standards, Scott Bradner, <email@example.com>; also
send CC to the IETF Chair (Russ Housley <firstname.lastname@example.org>)
and the IESG secretary <email@example.com>.
Examples that can be inspected are RFCs 1988, 1822, and 1790.