Applications Area

The area is managed by its area directors, Peter Saint-Andre <stpeter@stpeter.im> and Alexey Melnikov <alexey.melnikov@isode.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
IETF.

The basic rules for operating the IETF are written down in RFC 2026.

Table Of Contents

• How to start a working group
• Changing a charter
• Terminating a working group
• Requesting a WG meeting at the IETF
• Requesting a BOF at the IETF
• Holding an Interim Working Group meeting
• Publishing RFCs
  • Standards from a WG
  • Standards without a WG
  • Informational or Experimental from a WG
  • Informational or Experimental without a WG
• Intellectual Property

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:

• Propose the idea to interested people. Often, mailing lists of existing working groups, the discuss@apps.ietf.org mailing list, and other public fora are good for getting things aired.
• Establish
  a mailing list for discussion of the idea. In order to have consistent
  IPR policies for different mailing lists, IESG prefers that mailing
  lists are hosted on ietf.org site. Use https://datatracker.ietf.org/list/request/ to request a mailing list creation. One of the Area Directors can confirm such requests.
• Convince
  the Area Directors that it is a good idea. The ADs may request that a
  BOF be held at an IETF meeting, before the working group is formed, to
  gauge interest and to refine charter goals. (See Requesting a BOF)
• Write a Charter for the working group. This should contain:
  • The name and acronym for the WG
  • One or more proposed chairpersons
  • The name of the mailing list and the URL of its archive
  • The purpose of the WG: What it will produce, and why
  • The
    goals and milestones: When it will produce what it expects to produce.
    Proposed editors for any documents to be produced should be shown if
    possible.

  All but the first 2 items are necessary.
  If any of these are missing from the charter, it will be rejected
  summarily; GET IT RIGHT! But don't worry about the acronym and chairs
  too much.

• Mail the charter to Apps ADs, and formally request that the charter be reviewed. If you don't explicitly make such a request, we'll assume that the charter is still being bashed. Make sure you get a confirmation from the ADs! If you don't get a confirmation within a few days, resend your request.
  The area directors then either give feedback or forward it to the IESG
  and IAB; expect at least 2 weeks (probably more) to pass before final
  approval is given.

  NOTES:

  1. If
     you want to charter a group in time to meet at an IETF meeting, you
     typically need the "final" charter at least six weeks before the
     meeting.
  2. While the people who wish to form a
     working-group typically draft the charter, the IAB and IESG may want to
     make substantial changes. It is better to enlist the cooperation of at
     least one of the Area Directors in drafting the initial charter.
  3. Working
     group chairs should have actively participated in at least one other
     IETF working group, so that they are familiar with IETF procedures. (As
     a side note: currently Apps ADs prefer to assign one experienced IETF
     chair and one new person. This helps to grow the pool of experienced
     chairs in the Area.)
  4. Final approval of chairs and editors
     may be negotiated between the area directors and the proposers and is
     subject to IESG and IAB review.
  5. Except in exceptional
     circumstances, WGs will not be approved with one person acting as both
     chair and editor of a critical document, nor will WGs be approved when
     different positions are expected to emerge and the proposed chair is
     strongly identified with one of the positions.
• When
  the IESG has approved the WG, it will be announced on the ietf-announce
  list. This is the official "creation date" of the WG. If the IESG
  rejects the charter, the ADs are responsible for telling the proposers
  why it was rejected.
• Note that the IETF applications area has limited resources and cannot accept every request to charter a working group.

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.
• The
  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!
• The
  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.
• The
  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
  group.

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 ietf-action@ietf.org.) Alternatively, you can use the old way, i.e. you send a message to the Area Directors, with a copy to agenda@ietf.org, 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
• A
  (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
  itself, convincing.
• 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.
• An
  agenda must be send to agenda@ietf.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.
• If
  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.
• A
  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 minutes@ietf.org, and the working group mailing list, within two weeks of the meeting.

Publishing RFCs

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:

1. The WG achieves consensus that an Internet-Draft is ready to be published as a standard.
2. 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 iesg-secretary@ietf.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
   this point.
3. The ADs review the document, or have it reviewed, and either accepts it or asks the WG to make revisions to it.
4. If
   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
   review.
5. If there are no significant objections raised in the Last Call period, the ADs ask the IESG to vote on the document.
6. 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.
• The
  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
do so.)

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.
• Although
  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
THING.

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
• The
  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.
• It
  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!

Intellectual Property

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.
• The
  WG is expected to prefer non-encumbered technology whenever such
  technology exists and is not significantly worse than the encumbered
  alternative.
• 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, <sob@harvard.edu>; also
send CC to the IETF Chair (Russ Housley <housley@vigilsec.com>)
and the IESG secretary <iesg-secretary@ietf.org>.

Examples that can be inspected are RFCs 1988, 1822, and 1790.