Skip to content

Latest commit

 

History

History
195 lines (139 loc) · 9.4 KB

newADinfo.md

File metadata and controls

195 lines (139 loc) · 9.4 KB
title description published date tags editor dateCreated
New AD Info
true
2022-10-03 13:58:37 UTC
iesg
markdown
2022-09-28 14:08:25 UTC

New Area Director Information

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 Mailing Lists.

Basic AD Responsibilities:

Document Sponsoring and Telechat Information:

  • PublishPath
  • [AD Review Checklist]
  • [Document Onto Agenda]
  • [Chartering Working Groups]
  • [Reviewing Documents and Registrations (MIME Media Types, URI/URN, MIB)]
  • [Collection of issues frequently found by ART Area ADs]
  • Guidelines for Issues Found during TSVDIR Reviews
  • [Front Page Authors]
  • [Discuss Resolving]
  • [Working with the RFC Editor on Independent Submissions]
  • [Obsoleting RFCs belonging to other Streams]
  • Information about [informal telechats]
  • [Processing Errata]

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

  • RFC 3774 is a snapshot of what the community thought the IETF needed to fix in 2004. It is still relevant, and that is not a good sign ...

Other Intros

Driving Lessons for the Datatracker

Use the Datatracker to:

  • Initiate Last Calls
  • Create document ballots, build meeting agendas and clear returning items
  • Lets ADs fill in ballots (BallotDetails)
  • Initiates approval announcement messages (ApprovalDetails)
  • Sends email to a list when the document changes state (TrackerNotifications)
  • [wiki: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:

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.

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 - Status Change Documents (was: Moving documents to Historic)
  • IntellectualProperty - Sometimes patents cause process concerns
  • TrustAppointments - according to draft-ietf-iasa2-trust-update

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
  • Affiliate Groups is for non-IETF related hobbies or activities (sailing, scuba diving, running, or HAM radio operators to name a few)

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/

Working with Other Groups

These links are to wiki pages describing IESG working relationships with:

  • ... [IesgIab IAB]
  • ... [IesgIsoc ISOC]
  • ... [IanaInteractions IANA]
  • ... [IesgIasa IASA]

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
  • DirectoratesTeams
  • IesgNominating - positions we nominate

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.

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