wiki:WikiStart

  1. Quick Links
  2. Getting Started as an AD
  3. Processes for Uncommon Stuff
  4. Working with Other Groups
  5. Useful Mailing Lists or Addresses
  6. Miscellaneous

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
  • 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

IESG liaisons to other things

  • Deborah -- IAB
  • Adam -- NomCom
  • EKR -- Tools team
  • Suresh -- Edu team
  • Mirja, Alvaro, Warren -- Comms review

IESG mailing lists administrators

  • Terry Manderson
  • Suresh Krishnan
  • Secretariat

Meeting with Leaders of other Standards Bodies

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)
  • 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.
  • IetfValues - in-progress write-up of suggested IETF values
  • WgIprDiscussions - in-progress writeup on guidance to working groups about making informed decisions about IPR.
  • NumberOfAuthors - IESG Statement on the Number of Authors in an IETF Document (Alvaro and Terry)
  • UseOfUpdatesTag - IESG Statement on the use and meaning of the "Updates" and "Updated by" tags.

Tools

Rules

Thoughts

Getting Started as an AD

​An IESG Charter, RFC 3710 (2004)

First Steps

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

Basic AD Responsibilities:

Document Sponsoring and Telechat Information:

When you surface after joining the IESG long enough to think about "steering", instead of just reviewing docs for telechats

Other Intros

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:

The Ballot Process in General

When a draft has an open ballot each AD can cast a vote, and the options available are:

YES
NO OBJECTION
DISCUSS
ABSTAIN
RECUSE

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

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:

Liaison relationships

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.

Useful Mailing Lists or Addresses

<wg>-chairs@… - mail the chairs of <wg>

<area>-chairs@… - mail all the chairs of <area> ("<area>" is one of app, gen, int, ops, rai, rtg, sec, tsv)

<ad-name>-chairs@… - mail all the chairs of WGs for which <ad-name> is responsible (john-smith-chairs, for example)

<wg>-ads@… - 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>-ads@… - mail the ADs of <area> ("<area>" is one of app, gen, int, ops, rai, rtg, sec, tsv)

irtf-announce@… - IRTF announcement list, including progress reports for the different reserach groups. ​https://www1.ietf.org/mailman/listinfo/irtf-announce

tools-discuss@… - The mailing list for IETF Tools announcements and discussion. ​https://www1.ietf.org/mailman/listinfo/tools-discuss

Miscellaneous

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.

Wiki page for EnsuringAppropriateDiscussionOnIetfAtIetfList.

Dealing with some complicate IANA Registries: MediaTypes (a.k.a. MIME Types)

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.)
  • 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.)
Last modified 7 weeks ago Last modified on Jul 31, 2018, 9:30:54 AM

Attachments (2)

Download all attachments as: .zip