* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Some basic principles:

  • Small focused efforts are best
  • Co-chairs are usually a Good Idea!
  • The AD and WG Chairs have a technical management role, not a technical role

It's an AD's job to choose, appoint, train, guide, manage and support WG Chairs. An AD will often know people active in the WG's technical area, but may not have experience of them in a managerial role. Thus, an AD needs to talk to others who have worked with potential WG Chairs to find out if they are likely to succeed. Some ADs have tried making open calls for nominations and volunteers, followed by an interview process. Not only does this help choose a good candidate, but also it gives the community a better view of how the choice was made.

Some WGs have more than one co-chair. It is considered a good practice that co-chairs of the same WG are not affiliated or their particpation is not sponsored by the same company. However this is not a mandatory requirement and situations may happen where individuals change affiliation or sponsorship. It is recommended that such cases are made known to the community and especially to the other WG participants. For this purpose ADs will recommend the chairs of the WGs to disclose their affiliation or participation sponsorship at nomination and in cases of changes of affiliation or sponsorship - especially when these are not obvious from their email addresses - by sending a message to the WG mail list.


  • Group created with narrow focus, clear objectives, and limited options
  • State what is out of scope as well as what is in scope
  • Any special requirements or conditions on the work to be produced
  • Published and measurable goals and milestones
  • Mailing list and WG Chairs' addresses
  • Email archive is mandatory
  • Additional Web Page if desired - but it can't replace official IETF material
  • Do they need a security advisor? Any other technical advisors?
  • Do they need a WG Secretary?

A charter is a contract between the AD and the WG, negotiated between AD and Chairs with the group's participation. The charter requires community discussion and IESG approval, except for very minor updates. The AD should continuously verify that the WG is making progress and staying within its charter.

As well as scoping the tasks of the WG, the charter may define any special requirements or conditions for the work to be produced by the WG. For example, if any specification produced by the WG will need to meet the implementation or operational requirements in section 4.1.1 of RFC 2026 (see also section 3 of RFC 4794), that requirement should be included in the charter.

Sometimes Working Groups change their charters. This can happen at a few different levels of seriousness.

  • If a few goal dates are changed, and the WG chair and AD are good with the changes, no extra review is typically done.
  • Changes in the substance of the goals need to be approved by the WG, then are run by the IESG. E.g. if a WG decides it can't meet some side-goal and decides to remove from the charter. To get a changed charter reviewed by the IESG, you're supposed to send email to the IESG Secretary asking for the new charter to be reviewed and approved. The IESG Secretary put this on the next telechat agenda and sends a message to the IESG list with the charter text you send. The IESG will decide whether IETF-wide review is needed.
  • A major change in direction needs broader community review, just as a new working group does. Not always obvious how to make this happen - it means sending a WG back into BOF mode.