Guidance on Area Director Sponsoring of Documents

12 October 2026

1. Introduction

Per RFC8729, “[t]he IETF document stream includes IETF WG documents as well as ‘individual submissions’ sponsored by an IESG area director.” The publication of such an “individual submission” document requires the author(s) to find a sponsoring Area Director (AD) to take it through IETF Last Call and Internet Engineering Steering Group (IESG) review. This publication method is usually called the "AD Sponsored" method.

This statement is concerned with the IESG processing by the AD Sponsored publication method. It is divided into two parts: the publication process for individual submissions and guidance to the AD who is willing to sponsor such documents.

The procedures described in this statement do not change any underlying processes defined in RFC2026 and RFC8789, or the operation of the RFC Editor RFC8729 RFC9280.

2. Document Processing

2.1. Engagement with a Sponsoring AD

Individual submissions enter the AD sponsorship process through an agreement with an AD. Such agreements may be the result of the AD tracking the work earlier, discussions between the authors and the AD, discussions between a WG and the AD, or the recommendation of a “dispatch-style” WG.

If the author(s) cannot identify the most relevant AD or the area-specific dispatch process, they can contact the IESG. It is entirely at an AD's discretion to accept the processing of an individual submission.

2.2. Declining to Sponsor a Document

ADs can decline to sponsor a given document. It is recommended that ADs send a brief note to the IESG when they have turned down a sponsoring request, accompanied by an indication if this decision was due to an unsuitable topic for the AD or some other reason. This notification allows the other ADs to recognize if they are being asked about the document previously considered by a peer AD, searching for sponsoring among multiple ADs should not necessarily cause the second AD to automatically turn down the request. However, it is recommended that they query the ADs who have turned down sponsorship in the past and incorporate this information into their own decision.

An AD may abandon sponsorship of a given document after having agreed to sponsor it. This may occur, for example, if the AD discovers, after having agreed to sponsor the document, that the scope of work does not fall within the guidelines stated above. If an AD abandons sponsorship of a document, they must inform the IESG (as stated above), the document authors, and the public forums where the document is being discussed.

2.3 Reviews

Like any document in the IETF Stream, an AD-sponsored document requires rough consensus as a prerequisite to being published per RFC8789. While an AD may choose to gather community feedback and early reviews in their review process, all AD-sponsored documents will be sent to IETF Last Call to establish this rough consensus, followed by IESG Review.

IETF Last Call periods for AD-sponsored documents will be at least four weeks. RFC 2026 dictates this minimum review period when a proposed standards action comes from outside WGs. If the IESG believes that the community interest would be served by allowing more time for comment, it may decide on a longer IETF Last Call period or to explicitly lengthen a current Last Call period.

The exact nature of the review within the IETF is not specified, but it is anticipated that early reviews on relevant WGs (if any), directorate, area-specific, or “dispatch-style WG” mailing lists may occur. Individual reviewers and directorates can also be solicited. If insufficient review has occurred, the sponsoring AD should solicit these reviews explicitly. Similar to WG documents, the IETF Last Call list will be used for IETF Last Call discussions.

Individual submissions are treated in the same manner as WG documents in the IESG evaluation process. Therefore, existing Shepherd write-up templates, IESG Balloting Procedures for Documents, and appeal procedures apply to both WG documents and individual submissions.

3. Guidance for the Sponsoring AD

3.1. Choosing Documents to Sponsor

This section provides some guidelines to the AD when deciding whether to sponsor a document. Such guidelines are useful when authors contact an AD and suggest that their document be sponsored.

The decision to sponsor a document, or potentially later reverse this decision, involves AD discretion.

Benefit of the WG Process

ADs should consider the degree of effort that it would take for the community to review the document. Is it reasonable in size, complexity, and maturity, and is the anticipated degree of community discussion such that it can reasonably be managed by an AD without the structured facilitation of a WG? Can the document get adequate technical review without a WG? Is it likely that the document can reach consensus in IETF review without the consensus-building and iteration that occurs on a document adopted into a WG? Is the document at the boundary of multiple technical areas such that it is best served by having adequate cross-area reviews through a WG process?

Does the effort associated with the document warrant the creation or reopening of a WG? Clarifications and small updates of protocols in the AD's area are good candidates for AD sponsorship when no suitable WG exists, and the scale of the change does not warrant the creation of a WG.

Avoiding Conflict with Chartered Work

Documents sponsored by an AD are expected to be a rare occurrence and complement the chartered scope of existing WGs. An AD should not agree to sponsor a document which is already in scope of an active WG without first consulting that WG.

Fairness & Conflict of Interest

ADs should be fair in choosing the documents that they decide to sponsor. For instance, they should not give priority in accepting or processing documents on a company or authorship basis. The content of the document and its relevance to the Internet community should be the guiding factor.

Where an AD is one of the authors or contributors in a document, they cannot be the sponsoring AD.

Relevance

Is there a sufficiently strong motivation for publishing the document? Does it solve an important problem? Does it describe an issue that affects a significant number of users on the Internet? Does it create an interface or convention where widespread interoperability would be necessary?