Guidance on Area Director Sponsoring of Documents
This statement discusses the process related to "individual submissions", publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This statement covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate.
Table of Contents
2. Requirements language
4. Processing Rules
5. Choosing Documents to Sponsor
7. Summary of Changes to Existing Procedures
Appendix A. Acknowledgements
Appendix B. Secretariat Response to Submissions
Appendix C. PROTO Write-Up
"Individual submissions" are documents intended to become RFCs
through the IETF, without being submitted by a Working Group
(WG). The publication of these documents requires the authors to
find sponsoring Area Director (AD) to take it through IETF and
Internet Engineering Steering Group (IESG) review. Accordingly,
this publication method is sometimes called the "AD Sponsored"
The statement is concerned with the IESG processing by the AD
Sponsored method. This statement also provides guidance for choosing
between individual submissions and independent submissions through
the RFC Editor.
This statement describes procedures and working methods. It does not
change any underlying rules such as those in RFC 2026 [RFC2026] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) or the operation of the RFC Editor as defined in [I‑D.iab‑rfc‑editor] (Daigle, L., “The RFC Series and RFC Editor,” March 2007.). The statement also does not change
the procedures related to independent submissions or other RFC
streams [I‑D.iab‑rfc‑editor] (Daigle, L., “The RFC Series and RFC Editor,” March 2007.) [I‑D.klensin‑rfc‑independent] (Klensin, J., “Independent Submissions to the RFC Editor,” December 2006.).
2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
Individual submissions enter the process through an agreement with
an AD. Such agreements are usually the result of the AD tracking the
work earlier, or discussions between the authors and the AD. And
sometimes the AD agrees with a WG that a particular document should be
progressed as an individual submission.
Similar to the process for WG submissions, the authors may find a
willing external Shepherd [I‑D.ietf‑proto‑wgchair‑doc‑shepherding] (Levkowetz, H., “Document Shepherding from Working Group Last Call to Publication,” February 2007.). The task of the
Shepherd is to manage the discussions relating to the document's
process through the system. The Shepherd will also provide a write-up
similar to Document Shepherd Write-ups for WG documents. Appendix C (PROTO Write-Up) explains how to interpret the normal write-up
template for individual submissions. If no Shepherd can be identified,
the tasks of the Shepherd fall on the AD. In that case the authors
should, however, provide the write up so that the AD has the necessary
background information about the proposal. When the AD has the
write-up he or she can insert the document into the data tracker and
set its parameters correctly (e.g., the area, intended status and
If for some reason the authors cannot identify the most relevant
Area Director, they should contact to the General Area Director first.
This replaces the previous practice of writing to the IESG as a
Messages sent to firstname.lastname@example.org prompt the secretariat to
send a response that suggests the authors should follow the
appropriate submission procedure for their desired method, such as
finding an AD to sponsor an individual submission. The response can
also suggest that the authors should also consider the normal IETF
publication path through an existing working group, or consider
proposing a BoF at a future IETF meeting. An example statement is shown in Appendix B (Secretariat Response to Submissions).
Finally, authors who consider making either an individual
submission through the IETF or an independent submission via the RFC
Editor should be aware that some documents either have to be from the
IETF or would benefit from being from the IETF. For instance, the
document may request an IANA allocation from a space that has a
Standards Action IANA rule (see RFC
2434 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) [RFC2434]). Such actions can not come from independent
submissions. For a discussion of when a document can not be processed
as an independent submission, see RFC
3932 (Alvestrand, H., “The IESG and RFC Editor Documents: Procedures,” October 2004.) [RFC3932].
One possibility for such documents is to process them as AD
Sponsored submissions. Other alternatives include finding or
creating a suitable WG to process the document or abandoning the
document altogether. The authors are responsible for the decision
to proceed with a particular approach among the set of allowed
options. The authors are also responsible for the effort of
proposing a Birds-of-a-Feather (BoF) session, convincing the IESG
or one of the ADs that the document needs to be sponsored, etc.
4. Processing Rules
AD Sponsored documents to Standards Track require review in the
IETF, IETF Last Call, and IESG approval. AD Sponsored documents to
Experimental/Informational require some form of review in the IETF and
IESG approval. While RFC 2026 does not require the latter type of
documents to go through an IETF Last Call, this statement suggests that
it is always performed. It is needed to ensure adequate review
and transparency in a situation where the pending publication
of the document may not be known by any Working Group or the IETF community at large.
As RFC 2026 states, when a proposed standards action comes from
outside Working Groups, the IETF Last Call period is at least four
weeks. If the IESG believes that the community interest would be
served by allowing more time for comment, it may decide on a longer
Last-Call period or to explicitly lengthen a current Last-Call
The exact nature of the review within the IETF is not specified,
but it is expected that documents be posted for review in the
relevant WG mailing lists. Often no relevant mailing list exists,
in which case area-specific or IETF main discussion list can be
used. Individual reviewers, review teams, and review boards for
specific topics can also be used. If no sufficient review has been
obtained, the AD should solicit it explicitly.
Note that discussing topics outside the charter of a WG can cause
loss of focus in a WG, if a WG list is chosen for discussion. This
should be considered when seeking review and when deciding to adopt
documents for sponsoring. On the other hand, work closely related to a
WG but strictly outside its charter should always be brought to the
WG's attention during review.
Sponsored submissions are treated in the same manner with other
submissions in the actual IESG evaluation process. Existing discuss,
appeal, recusing, etc. rules apply also to sponsored submissions.
5. Choosing Documents to Sponsor
This section provides some guidelines for the use of the AD
Sponsoring method. Such guidelines are useful when authors contact
the AD and suggest that their document be sponsored. The rules are
also useful in controlling the load on the IESG, and to ensure
fairness. AD Sponsored documents are the only way to publish
Standards Track documents outside WGs. IETF documents may also have
a higher priority at the RFC Editor processing queue than independent
When considering the choice between a sponsored document and an RFC
Editor submission, the RFC 3932 rules play a role [RFC3932] (Alvestrand, H., “The IESG and RFC Editor Documents: Procedures,” October 2004.). Some documents require IETF review, as they extend
IETF protocols and they may not go through the RFC Editor's
independent submissions track. See response 5 (extension requires IETF
review) of RFC 3932. Sometimes such documents are suitable candidates
for being sponsored, however. It would be useful to add, say, IANA
rules or IPv6 considerations to an old specification that did not have
them and for which no WG can be found. Such additions to standards
track RFCs need to be on the standards track themselves, preventing
the use of independent submissions.
In general, the decision to sponsor a document involves AD
discretion. It is necessary for the AD to be willing to spend
effort on the document. The following considerations should be
- Document Track
Documents that need to be on the Standards Track can only
be published via WGs or the AD Sponsored method.
Documents that fall under this class should either be handled by
the IETF in some manner or be dropped. This ultimate decision
depends on, among other things, on the value of the document's
contribution and whether it fits within the mission of the
The AD should also consider whether the normal IETF WG/BoF
process should be employed instead. Some situations where
this is impractical have been noted in Section 6 (Discussion).
- IANA Rules
Documents that request "IETF Consensus" or "Standards Action"
IANA allocations also need to be WG submissions or AD Sponsored documents.
On the other, documents intended to satisfy "Specification
required" could be processed as independent submissions.
- Benefit from IETF Review
All AD sponsored documents go through IETF Last Call,
and also receive additional review from the sponsoring
AD, the IESG, and may also be reviewed by solicited
experts and WGs.
Does the document need such IETF-wide review, or is RFC Editor's
Independent Submission Review (ISR) sufficient? For instance,
the AD can decide that while a particular document could be an
independent submission, the added review would be useful and
would benefit the community.
As an example, the AD may expect that a particular protocol will
be widely deployed, and that providing additional IETF review
makes the protocol more likely to be useful for the community
and less likely to cause problems.
- Availability of Reviewer Resources
Are there persons that can help with the review of the document
during, for instance, the IETF Last Call? Is there a risk that
such persons become distracted from their chartered work at the
IETF because of the extra reviews being requested?
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 company or personal
criteria; 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 significant contributors in
a document, he or she can not be the sponsoring AD.
The above process issues need to be considered together with the
relevance the document has for the Internet community. Does it
solve an important problem? Does it describe an issue that
affects a significant number of users in the Internet? Does it
create an interface or convention where widespread
interoperability would be necessary?
For instance, a document that describes a serious vulnerability
or an architectural issue in protocols in the AD's area is a
good candidate for being sponsored. Clarifications and small
updates of protocols in the AD's area are also good candidates
when no suitable working working group exists, and the scale of
the change does not warrant the creation of one.
A document specifying a particular vendor's proprietary protocol
is typically more suitable as an independent submission than being sponsored by an AD. A document specifying an alternate
approach to an existing Standards Track solution is typically not a likely candidate either. But this is a judgment call. For instance, if there is general agreement in a WG for publishing a
"road not followed" document for the record, but the WG itself
considers it out of scope, AD sponsoring might be appropriate.
As with relevance, the quality of the document and the expected
outcome of the IETF review process affect the decision. In
general, the AD should only sponsor documents that he or
she believes in; the decision to sponsor should only be taken
after at least as detailed review as the AD performs for regular
As with BoFs, it is possible that the IETF community is divided
or unable to agree on a proposal, even if the proposal itself is
of high quality and relevant. The AD should consider the
likelihood of achieving consensus in IETF review, if relevant
for the type of document in question.
Sometimes the IETF, IESG, and the WG has more information about
the history of the document than the RFC Editor. This is the case with the "road not followed" documents mentioned above as
well as with other documents recently seriously considered in the IETF. If the publication of these documents is appropriate,
they are likely more suitable as individual submissions than as independent submissions.
ADs can always decline to sponsor a given document. The decision to
either sponsor or not to sponsor should be made in a timely manner,
however. It is expected that ADs can make this decision in the same
timeframe as they perform AD reviews from Working Groups. To
facilitate tracking of progress and draft history, the ADs should
enter the draft in question to the tracker as soon as the publication
request is made as well as record the eventual decision in the
It may still take a while to find the right AD, if the contacted AD
suggests that the document fits better in another AD's area of expertise. Or the author may realize that a more suitable AD
exists. Legitimate search for the right AD should not be confused with authors going through several ADs trying to find one that will sponsor
their document. For BOF requests, this practice has been termed "AD
To identify cases of AD shopping, 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 was due to unsuitable
topic for the AD or some other reason. This allows the other ADs to
recognize that they are being asked for the same document again. This
should not necessarily cause the second AD to automatically turn down
the request. However, it is recommended that he or she query the ADs
that have turned down sponsorship in the past and incorporate this
information into their own decision.
AD Sponsored submissions represent a significant workload to the
IESG. Reasons for the popularity of these submissions include the
interest of the ADs to progress work in their fields, the difference
in time-to-RFC-publication IETF documents enjoy over independent
submissions, the ability to avoid the IESG notes that independent
submissions get, and the wider review IETF documents get.
Improvements in the efficiency of the RFC Editor processing are
likely to increase the popularity of the independent submissions, which
represent a smaller load for the IESG. Similarly, ongoing work [I‑D.klensin‑rfc‑independent] (Klensin, J., “Independent Submissions to the RFC Editor,” December 2006.) may change the tone of the IESG
notes. However, the speed of the independent submissions channel
depends to a large extent on its review stage, and it has generally
been easier to find reviewers for IETF documents.
In any case, the IESG can handle some amount of sponsored
documents. The system is self-regulating in the sense that if the
IESG becomes too busy, the ADs are less likely to adopt sponsored
documents; there is no requirement for them to sponsor any
The interesting question is why there was no WG to deal with the
issue in the proposal, if it is so important and useful. One
reason for this can be that our BoF process tends works better for
large efforts than small. The process also favors focused efforts
which may make it hard to report issues that cross multiple WGs or
areas. Running a BoF and creating a WG takes time and requires a
significant number of persons to be involved in the effort. Some of
the situations where this can be problematic include:
- Corrections and small updates of existing RFCs when the WG that created the original RFCs no longer exists.
- Draft Standard revisions of Proposed Standard RFCs when the WG no longer exists.
- IANA considerations updates for old protocol specifications to bring them up to today's requirements. Many old protocol specifications had no IANA considerations, for instance.
- Architectural issues that cross multiple WGs or areas, but are not being handled currently by the IAB.
- Registration of values and formats in frameworks, such as media type registrations.
Some areas employ area-specific WGs that can be used to process
some of these. For instance, TSVWG in the Transport area produces documents as a real WG, resulting in less need for AD
sponsoring. Other areas such as Internet and Security have area-specific discussion forums that do not act like WGs. The Routing
area employs both models with their RTGAREA group for discussion and RTGWG for WG-like operation for "catchall" documents. In the
Operations and Management Area the MIB Doctors team discusses
procedural and technical issues, reviews documents, and sometimes
issues documents related to the MIB quality review process.
7. Summary of Changes to Existing Procedures
The "talk to the appropriate AD" and "submit via RFC
Editor" approaches are promoted over submitting documents via the
secretariat. This allows the ADs to discuss the appropriate
submission method with the authors, and does not require the
secretariat to think about policy issues such as whether a document
is worthwhile for being sponsored.
Submissions sent to email@example.com are not
New text is adopted for the secretariat's response to submissions.
It should also be noted that Section 4.2.3 of RFC 2026 states
"Unless they are the result of IETF Working Group action, documents
intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor." This has not been
operational practice for some time, however. A number of
Informational and Experimental documents have been submitted as AD
Sponsored documents. The rationale behind this is the wider review
that can be achieved, but this is one area where current procedures
have deviated from RFC 2026. However, RFC 2026 is not technically
violated, since in these cases the IESG serves as the submitter to
the RFC Editor in place of the author.
||Daigle, L., “The RFC Series and RFC Editor,” draft-iab-rfc-editor-04 (work in progress), March 2007.
||Levkowetz, H., “Document Shepherding from Working Group Last Call to Publication,” draft-ietf-proto-wgchair-doc-shepherding-09 (work in progress), February 2007.
||Klensin, J., “Independent Submissions to the RFC Editor,” draft-klensin-rfc-independent-05 (work in progress), December 2006.
||Bradner, S., “The Internet Standards Process -- Revision 3,” BCP 9, RFC 2026, October 1996.
||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
||Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).
||Alvestrand, H., “The IESG and RFC Editor Documents: Procedures,” BCP 92, RFC 3932, October 2004.
||Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,” BCP 97, RFC 3967, December 2004.
Appendix A. Acknowledgements
This statement has been prepared as a result of discussions
in the IESG. The members of the IESG at the time this
was written were:
- Bill Fenner
- Brian Carpenter
- Cullen Jennings
- Dan Romascanu
- David Kessens
- Jari Arkko
- Jon Peterson
- Lars Eggert
- Lisa Dusseault
- Magnus Westerlund
- Mark Townsley
- Ross Callon
- Russ Housley
- Sam Hartman
- Ted Hardie
In addition, the editor would like to thank Leslie Daigle, John
Klensin, and Pekka Savola for input.
Appendix B. Secretariat Response to Submissions
Individual submission requests sent to firstname.lastname@example.org
prompt the secretariat to send a response suggesting an
alternative submission process. Example response note
is shown below.
"We cannot process your request. Please make an independent
submission through the RFC Editor, or find an IETF Area Director
to sponsor your draft as an individual submission to the
IETF. Also, please consider the normal IETF publication path
through an existing working group, or consider proposing a BoF at
a future IETF meeting.
Please see RFC 3932 for guidance on which documents may be
suitable as independent submission through the RFC Editor. If you
choose this option, please send your publication request to
If you wish to seek Area Director sponsorship for an
individual submission, the best solution is to contact the
most relevant Area Director directly, with an explanation of
why the draft is appropriate for IETF publication. The Area
Director is also the best source of advice about whether an
existing WG, or a BoF, may be applicable. The Area Directors
and WGs are listed at:
If for some reason you cannot identify the most relevant Area
Director, please talk to the General Area Director first.
The IETF Secretariat"
Appendix C. PROTO Write-Up
A write-up should accompany any request for sponsoring. This
write-up should follow the the Document Shepherd Write-up template given
in Section 3.1 of [I‑D.ietf‑proto‑wgchair‑doc‑shepherding] (Levkowetz, H., “Document Shepherding from Working Group Last Call to Publication,” February 2007.). However, as there
is no working group, questions that relate to the the working group
need to be interpreted in the context of the interested community
instead. It is assumed that an interested community exists in all
cases, and that individual submissions are not prepared in complete
In addition, under item 1.k the authors should indicate if the
document been considered in any existing or past WG, and if yes,
describe why the work was not adopted as a work item there.
The initial template of the edited write-up is included below for
ease of copying pasting the questions elsewhere. But changes are
expected over time. Any future changes to [I‑D.ietf‑proto‑wgchair‑doc‑shepherding] (Levkowetz, H., “Document Shepherding from Working Group Last Call to Publication,” February 2007.) need to be applied,
for instance. The latest version of this template is available from
the IESG section of the IETF web site.
- Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
- Has the document had adequate review both from key
members of the interested community and others? Does the
Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
- Does the Document Shepherd have any specific
concerns or issues with this document that the Responsible
Area Director and/or the IESG should be aware of? For
example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community
has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns
- How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of
a few individuals, with others being silent, or does the
interested community as a whole understand and agree with
- Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
- Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
- Has the document split its references into
normative and informative? Are there normative references
to documents that are not ready for advancement or are
otherwise in an unclear state? If such normative references
exist, what is the strategy for their completion? Are there
normative references that are downward references, as
described in [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,” December 2004.)? If so, list these
downward references to support the Area Director in the Last
Call procedure for them [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,” December 2004.).
- Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[RFC5226]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?
- Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
- The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
- Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
- Working Group Summary
Was there anything in the discussion in the interested
community that is worth noting? For example, was there
controversy about particular points or were there
decisions where the consensus was particularly rough?
Was the document considered in any WG, and if so, why
was it not adopted as a work item there?
- Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?
The write-up is entered into the ID Tracker in the "Comment"