|
Guidance on Area Director Sponsoring of Documents Guidance on Area Director Sponsoring of DocumentsDate: Mar 2007
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 1.
Introduction
1. Introduction"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" method. 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 languageIn 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.).
3. SubmissionIndividual 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 ballot information). 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 whole. Messages sent to [email protected] 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 RulesAD 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 period. 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 SponsorThis 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 submissions. 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 applied:
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 tracker. 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 shopping." 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.
6. DiscussionAD 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 submissions. 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:
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 ProceduresThe "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 protected] are not considered. 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.
8. References
Appendix A. AcknowledgementsThis statement has been prepared as a result of discussions in the IESG. The members of the IESG at the time this was written were:
In addition, the editor would like to thank Leslie Daigle, John Klensin, and Pekka Savola for input.
Appendix B. Secretariat Response to SubmissionsIndividual submission requests sent to [email protected] prompt the secretariat to send a response suggesting an alternative submission process. Example response note is shown below.
Appendix C. PROTO Write-UpA 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 isolation. 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.
The write-up is entered into the ID Tracker in the "Comment" field. |
||||||||||||
|
|||||||||||||
