IESG Quick Links and Semi-Complete Guide
Notice an omission or error? Please work with the IESG and edit this page.
Most-used Wiki pages
- OffDuty - when are you on vacation?
- InformalAgenda - the agenda for the next informal telechat; add items here
- UpcomingIetf - booking the IESG breakout room and showing arrival times
- RetreatInfo - information about the upcoming IESG retreat
- DownrefRegistry - which documents have been Last Called as Downrefs following RFC 3967 (BCP 97) procedure
- IesgOnlyEtiquette - when to use and not to use iesg-only mailing list
Meeting with Leaders of other Standards Bodies
- IEEE 802 Exec Com, IESG, and IAB Meeting - Milpitas, July 25, 2012
- IEEE 802 Exec Com, IESG, and IAB Meeting - Orlando, March 16, 2013
- Upcoming meeting - Newark, September 29, 2014
Some Things We're Currently Working On
- FoldingInUpdates - Advice on folding in updates when progressing a document from PS to IS (Barry and Brian)
- QuickWorkingGroups - Quickly chartering short-lived, tightly scoped working groups with short schedules (Barry and Pete)
- DesignatingAsHistoric - Draft of update to IESG Statement on Designating RFCs as Historic (Barry)
- MailingListArchiving - Proposed IESG Statement regarding mailing list archiving (Pete)
- NewCharteringProcess - How to charter a new working group (old documentation is out of date)
- CharterInternalReviewBlockCriteria - Proposed criteria for balloting 'Block' during IESG internal review of a WG charter proposed for external review.
- Draft2119BoilerplateSuggestions - Proposed boilerplate for use with RFC2119 that allows the use of RFC2119 keywords in normal text if they are not in all-uppercase.
- BadDiffExamples - Examples of massive fail when diffing documents for review.
- SpecialUseTopLevelDomainProcess - How to deal with requests for special use TLDs
- IesgReorgMessages - Proposed messages to the community on the IESG Re-organization
- Secretariat tools - see also IssueTracking and how to send a ticket.
- Prototype tools by the IETF Tools Team pages.
- Notes on tools in progress, WishLists for tools.
- Sites for IESG's OwnContent
Getting Started as an AD
- Work with the secretariat to verify that you are set up as an AD with the various tools. Your existing tools login is used for most things, most importantly the datatracker. You should also get a login/password pair from the secretariat for the ARO tools, and a separate pair from the RFC Editor for working with errata.
- Ask the current IESG members if that's the complete list of passwords - update the above bullet if it isn't.
- Join a bunch of MailingLists.
General AD Responsibilities:
- Summary of Desired Expertise for NomCom
- ManageWorkingGroup and picking chairs
- Handling When Two ADs in the Same Area Have the Same Affiliation
Document Sponsoring and Telechat Information:
- Reviewing Documents and Registrations (MIME Media Types, URI/URN, MIB)
- Collection of issues frequently found by Application Area ADs
- Guidelines for Issues Found during TSVDIR Reviews
- Working with the RFC Editor on Independent Submissions
- Information about informal telechats
- HowDoing: Tools to monitor AD and WG progress
- NewbieQuestions - other collected new-to-IESG questions
- IesgInternal - when we need to communicate in private and how
Driving Lessons for the I-D Tracker
What we call the "IESG Tracker" is actually the Area Director's window into the IETF-wide ID-Tracker. It was introduced in May 2002, and was a huge advance in our awareness of document status and progress.
Use the tracker to:
- Initiate Last Calls (LastCallDetails)
- Create document ballots, build meeting agendas and clear returning items (DocumentOntoAgenda)
- Lets ADs fill in ballots (BallotDetails)
- Initiates approval announcement messages (ApprovalDetails)
- Sends email to a list when the document changes state (TrackerNotifications)
- Defer a draft to the next telechat
The Ballot Process in General
When a draft has an open ballot each AD can cast a vote, and the options available are:
There's more detail about what these mean at
voting-procedures, SingleDiscussResolution and InfoExpProcedures for non-standards track and RFC Editor submissions.
You can also see the IESG Statement on the Discuss Criteria to be used (and not used) when placing a Discuss.
An AD can change his or her vote up to a late stage, i.e. during the telechat at which the document is finally approved. However, it's much better to cast your ballot early.
If an AD hasn't had time to review a draft but really feels the need to do so (i.e. is unwilling to state NO OBJECTION without further ado), it's possible to DEFER the draft to the next telechat - once only. Most ADs feel bad if they have to do this.
The Role of Document Shepherds
RFC 4858 defines the role of the Document Shepherd for documents from IETF working groups, and it also says:
The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd.
Experience has shown that a successful Document Shepherd need not be the working group chair or secretary. In fact, the IESG encourages the working group chair to select an active working group participant that has strong understanding of the document content, is familiar with the document history, and is familiar with the IETF standards process. The Document Shepherd of a working group document should not be an author or editor of the document.
Not all individual submissions have a Document Shepherd other than an author or editor of the document. When there is one, the Document Shepherd is selected by the Responsible Area Director in consultation with the document authors or editors.
The main duties of a Document Shepherd are:
- Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested.
- During AD Evaluation of the document by the responsible Area Director, managing the discussion between the editors, the working group and the responsible Area Director.
- During the IETF Last Call, if required for the document, managing the discussion between the reviewers, the editors, the working group and the Responsible Area Director.
- During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document.
- Following up on IANA and RFC Editor requests after IESG approval.
The Document Shepherd prepares a publication request write-up. The template for the write-up can be found here:
For working group documents: http://www.ietf.org/iesg/template/doc-writeup.html
For individual documents: http://www.ietf.org/iesg/template/individual-doc-writeup.html
DISCUSSes and How They Get Resolved
The DISCUSS ballot is the way for an AD to state an issue that prevents him or her from agreeing that a document is ready. A DISCUSS is not a binary vote - as its name suggests, it is a statement of what the AD has found wrong with a draft, preferably also a statement of how it could be fixed, and the trigger for a constructive discussion to resolve it as quickly as possible. Here is more information about DiscussResolving.
Processes for Uncommon Stuff
- NewWork - From Ideas to BOFs to Chartering
- HistoricStatus - Moving documents to Historic
- IntellectualProperty - Sometimes patents cause process concerns
Non-Working-Group Mailing Lists
Non-working-group mailing lists are used for various sorts of discussions, including:
- Directorates and review teams
- Review lists specified in IANA procedures
- Discussions with the intent to form a working group
- Discussions for a subtask of a working group
The list of non-working-group mailing lists is here: http://www.ietf.org/list/nonwg.html
Scroll to the bottom of that page for instructions for creating a new one.
Working with Other Groups
These links are to wiki pages describing IESG working relationships with:
More groups with special relationships to the IESG:
- IesgLaw - although most of the time legal issues can be handled by IASA
- SecretariatInteraction - working with the Secretariat
- IesgNomcom - IESG Interaction with NomCom
- IesgNominating - positions we nominate
The formal responsibility for handling liaisons and especially liaisons relations with external standard bodies are on IAB. However an AD will commonly be in the path for handling liaison statements and especially replies to received ones. The general process for handling liaisons are specified in RFC4053.
The IAB procedure for handling liaison responsibilities are documented in RFC4052. This includes creating formal relations and appoint liaison to bodies or liaison managers.
Working with the RFC Editor
IESG members need to work closely with the RFC Editor, and track interactions with the RFC Editor. The main tasks include:
- Ensuring that the RFC Editor notes in the approved documents are correct. Often the discuss-clearing involves changing or adding text, and the most expedient way of handling small updates is the use of RFC Editor notes. RFC Editor notes are entered in the document's "ballot text".
- Note that sometimes late reviews or other reasons cause changes to be useful even after approval. Editing RFC Editor notes is possible after approval, but should be avoided as a general case. If you ever find a need to do a change to the RFC Editor notes, send mail to the RFC Editor to inform that a change has happened. Alternatively, wait to AUTH48 for the changes.
- Ensuring that the changes suggested by authors in AUTH48 fall under editorial class, and authorizing other changes where needed. Sometimes significant changes are attempted at this stage for various reasons. The right response in such cases is typically taking the draft back to the working group and going through the WGLC, LC, and IESG approval again.
- Performing a conflict review (see Section 3 of RFC 5742) against documents in the Independent Stream and IRTF Stream. A separate note regarding the conflict review process can be found here: IesgRfceditorSubmissions.
Useful Mailing Lists or Addresses
<wg>-email@example.com - mail the chairs of <wg>
<area>-firstname.lastname@example.org - mail all the chairs of <area> ("<area>" is one of app, gen, int, ops, rai, rtg, sec, tsv)
<ad-name>-email@example.com - mail all the chairs of WGs for which <ad-name> is responsible (john-smith-chairs, for example)
<wg>-firstname.lastname@example.org - mail the ADs of <wg>; note that this is the same as <area>-ads for the area in which <wg> resides... it does not send mail only to the AD responsible for <wg>
<area>-email@example.com - mail the ADs of <area> ("<area>" is one of app, gen, int, ops, rai, rtg, sec, tsv)
firstname.lastname@example.org - IRTF announcement list, including progress reports for the different reserach groups. https://www1.ietf.org/mailman/listinfo/irtf-announce
email@example.com - The mailing list for IETF Tools announcements and discussion. https://www1.ietf.org/mailman/listinfo/tools-discuss
The IESG has a private Web site, which is mostly obsoleted by this Wiki.
The IETF Chair has a demanding ChairTimeline to plan IETF meetings.
C code in I-Ds should do bound checking. The exception is when the code is a fragment and it's clear that it's a fragment. In that case a prominent note in the module needs to say "this is a code fragment, when this fragment is implemented as part of [insert_protocol_name] implement bound checking".
Wiki page for LegacyErrataHandling.
Wiki page for DocumentLanguageEditing session in London.
Wiki page for SpeakingForIetf.
Wiki page for DealingWithPrivateFeedbackInIetfProcess.
Some abandoned or obsolete stuff that's nonetheless useful to save
- DraftShepherdWriteupWgAlternate - A new proposal for a radical change to the shepherd writeup, as discussed at IETF 84. This is a version that strips out all the yes/no sorts of things and instead asks for a paragraph or two of information in each of five categories. (This is now part of the normal shepherd writeup documentation.)
- DraftNoteWellSummary - A draft version of a very short Note Well summary. (This is now dead.)
- DraftBoilerplateChange - A draft of a change to the boilerplate for cases where we are publishing something (such as documentation of a vendor-specific mechanism) where the community has consensus to publish, but consensus on the content doesn't make sense. (The IAB has chosen not to approve this, but the text is still useful as an IESG note in such documents.)