When you surface after joining the IESG long enough to think about "steering", instead of just reviewing docs for telechats
Use the Datatracker to:
When a draft has an open ballot each AD can cast a vote, and the options available are:
YES
NO OBJECTION
DISCUSS
ABSTAIN
RECUSE
NO POSITION
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.
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
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.
Non-working-group mailing lists are used for various sorts of discussions, including:
The list of non-working-group mailing lists is here:
https://datatracker.ietf.org/list/nonwg
The list of Affiliate Groups is here:
https://www.ietf.org/about/groups/affiliate/
For instructions for creating a new nonwg list, see https://www.ietf.org/how/lists/nonwglist-guidelines/
These links are to wiki pages describing IESG working relationships with:
More groups with special relationships to the IESG:
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.
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".
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 [http://tools.ietf.org/html/rfc5742#section-3 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.