Application Area procedures

The area is managed by its area directors, Chris Newman <chris.newman@sun.com> and Lisa Dusseault <lisa@osafoundation.org>. 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

• 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. If you do not have facilities to do this yourself the area directors may be able to suggest some alternatives.
• 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.

  If any of these are missing from the charter, it will be rejected summarily; GET IT RIGHT!

• Mail the charter to draft-charters@apps.ietf.org, with a CC to iesg-secretary@ietf.org, 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.
  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 1 year 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, 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)
• 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, or teleconferences, 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 1603, chapter 6.3, 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, there is no formal IESG "vote"

Informational or Experimental without a WG

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 may request a Last Call on the document to get wider review
• 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.
• 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 chapter 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 (Fred Baker <fred@cisco.com>) and the IESG secretary <iesg-secretary@ietf.org>

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