Network Working Group J. Arkko (Editor)
Internet-Draft Ericsson
Intended status: Informational October 16, 2006
Expires: April 19, 2007
Guidance on Area Director Sponsoring of Documents
draft-iesg-sponsoring-guidelines-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
There are a number of different methods by which an RFC can be
published in addition to the regular submissions from a working
group. This note discusses the publication of RFCs by finding a
sponsoring Area Director to take it through IETF and Internet
Engineering Steering Group (IESG) review. This note covers both the
the processing in the IESG as well as guidance on when such
sponsoring is appropriate.
Arkko (Editor) Expires April 19, 2007 [Page 1]
Internet-Draft AD Sponsoring Guidelines October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Submission . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 5
5. Choosing Documents to Sponsor . . . . . . . . . . . . . . . . 6
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Summary of Changes to Existing Procedures . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. PROTO Write-Up . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Arkko (Editor) Expires April 19, 2007 [Page 2]
Internet-Draft AD Sponsoring Guidelines October 2006
1. Introduction
There are a number of different methods by which an RFC is published
[RFC3932, I-D.iab-rfc-editor]:
o Output from the Working Groups (WGs) to Standards Track, Best
Current Practice (BCP), Experimental, or Informational.
o Area Director (AD) Sponsored documents to Standards Track,
Experimental, or Informational.
o RFC Editor documents to Experimental or Informational.
o Documents for which special rules exist.
Only some of these methods involve review in the IETF. This note is
concerned with the Internet Engineering Steering Group (IESG)
processing by the AD Sponsored method. This note also provides
guidance for choosing between sponsored and RFC Editor submissions.
This note describes procedures and working methods. It does not
change any underlying rules such as those in RFC 2026 [RFC2026] or
the operation of the RFC Editor as defined in [I-D.iab-rfc-editor].
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].
3. Submission
Individual submissions can enter the process either by sending a
request to the RFC Editor or through an agreement with an AD.
RFC Editor document submission
The authors contact the RFC Editor and request the publication as
an RFC. The requested result in this case is an RFC Editor
document.
However, some submissions 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 [RFC2434]). Such actions can not
come from RFC Editor submissions. For a discussion of when a
Arkko (Editor) Expires April 19, 2007 [Page 3]
Internet-Draft AD Sponsoring Guidelines October 2006
document can not be processed as an RFC Editor submission, see RFC
3932 [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.
Agreement with an AD
AD Sponsored submissions can also be initiated by the AD who is
willing to sponsor a document. Such submissions are usually the
result of the AD tracking the work earlier, or discussions between
the authors and the AD.
Document submissions to the RFC Editor are automatically entered to
the IESG processing for the RFC 3932 check.
AD sponsored document submissions require the sponsoring AD to enter
the draft in the tracker and set the parameters appropriately (e.g.,
state set to "AD Review", status set to "Proposed Standard", and the
area set correctly).
Once the AD has agreed to sponsor a document, the authors need to
provide a write-up similar to PROTO team write-ups from WGs. A
suggested write-up form can be found from Appendix B.
Previously, it was also possible to send a request to the secretariat
for a document to be sponsored. This is no longer possible.
Messages sent to iesg@ietf.org are NOT considered to be a submission
at all. Messages sent to iesg-secretary@ietf.org prompt the
secretariat to send the following response:
Arkko (Editor) Expires April 19, 2007 [Page 4]
Internet-Draft AD Sponsoring Guidelines October 2006
"We cannot process your request. You have two choices - direct
submission to the RFC Editor, or finding 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 for direct submission to the RFC Editor. If you
choose this option, please send your publication request to
<rfc-editor@rfc-editor.org>
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:
http://www.ietf.org/html.charters/wg-dir.html
If for some reason you cannot identify the most relevant Area
Director, please talk to the General Area Director first.
The IETF Secretariat"
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. Even the latter type of documents often go
through an IETF Last Call as a means to solicit the IETF review.
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
Arkko (Editor) Expires April 19, 2007 [Page 5]
Internet-Draft AD Sponsoring Guidelines October 2006
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.
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 RFC Editor
submissions.
When considering the choice between a sponsored document and an RFC
Editor submission, the RFC 3932 rules play a role [RFC3932]. If the
document generates a 3, 4 or 5 response based on RFC 3932 it is not
appropriate for an RFC Editor submission. 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 RFC Editor
submissions.
But a negative response from the RFC 3932 check may also indicate
that the document is inappropriate or harmful. If the document is
not changed, it should neither be sponsored by the ADs or published
via the RFC Editor.
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:
Document Track
Documents that need to be on the Standards Track can only be
published via WGs or the AD Sponsored method.
Arkko (Editor) Expires April 19, 2007 [Page 6]
Internet-Draft AD Sponsoring Guidelines October 2006
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.
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 5.
IANA Rules
Documents that request "IETF Consensus" or "Standards Action" IANA
allocations also need to use be WG submissions or AD Sponsored
documents.
Benefit from IETF Review
Does the document need IETF-wide review, or is Independent
Specification Review (ISR) sufficient? For instance, the AD can
decide that while a particular document could be submitted via the
RFC Editor, the added review at the IETF and IESG 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?
Fairness
ADs should be fair in choosing the documents that they decide to
sponsor. For instance, they should not sponsor documents only
from their own company or their friends; 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 of a document, he or she can not
be the sponsoring AD.
Arkko (Editor) Expires April 19, 2007 [Page 7]
Internet-Draft AD Sponsoring Guidelines October 2006
Relevance
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 not suitable for being sponsored. A document
specifying an alternate approach to an existing Standards Track
solution is typically not a likely candidate either.
Quality
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 have 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 WG
submissions.
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.
ADs can always decline to sponsor a given document.
It may take a while to find the right AD. Sometimes the contacted AD
may suggest 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
Arkko (Editor) Expires April 19, 2007 [Page 8]
Internet-Draft AD Sponsoring Guidelines October 2006
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 query the ADs
that have turned down sponsorship in the past and incorporate this
information into his decision.
6. Discussion
AD Sponsored submissions represent a significant workload to the
IESG. Reasons for this popularity include the interest of the ADs to
progress work in their fields, the difference in time-to-RFC-
publication IETF documents enjoy over RFC Editor submissions, the
ability to avoid the IESG notes that RFC Editor submissions get, and
the wider review IETF documents get.
However, improvements in the efficiency of the RFC Editor processing
are likely to increase the popularity of the RFC Editor submissions,
which represent a smaller load for the IESG. Similarly, ongoing work
[I-D.klensin-rfc-independent] may change the tone of the IESG notes.
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:
o Corrections and small updates of existing RFCs when the WG that
created the original RFCs no longer exists.
o Draft Standard revisions of Proposed Standard RFCs when the WG no
longer exists.
o 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.
o Architectural issues that cross multiple WGs or areas.
Arkko (Editor) Expires April 19, 2007 [Page 9]
Internet-Draft AD Sponsoring Guidelines October 2006
o 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.
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 iesg@ietf.org 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
practise 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.
8. Security Considerations
There are no security considerations beyond those normally involved
in the IETF processing of proposals for new RFCs.
9. IANA Considerations
There are no IANA considerations.
10. References
Arkko (Editor) Expires April 19, 2007 [Page 10]
Internet-Draft AD Sponsoring Guidelines October 2006
10.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[I-D.ietf-proto-wgchair-doc-shepherding]
Levkowetz, H., "Document Shepherding From Working Group
Last Call to IESG Approval",
draft-ietf-proto-wgchair-doc-shepherding-07 (work in
progress), June 2006.
10.2. Informative References
[RFC3967] 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.
[I-D.iab-rfc-editor]
Daigle, L., "The RFC Series and RFC Editor",
draft-iab-rfc-editor-01 (work in progress), July 2006.
[I-D.klensin-rfc-independent]
Klensin, J., "Independent Submissions to the RFC Editor",
draft-klensin-rfc-independent-02 (work in progress),
May 2006.
Appendix A. Acknowledgements
This note 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
Arkko (Editor) Expires April 19, 2007 [Page 11]
Internet-Draft AD Sponsoring Guidelines October 2006
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 for input.
Appendix B. PROTO Write-Up
The following write-up should accompany any request for sponsoring.
The write-up is a modified version of the WG chair proto write-up in
[I-D.ietf-proto-wgchair-doc-shepherding].
(1.a) Has the document had adequate review both from key community
members and technical experts? Does the submitting author have
any concerns about the depth or breadth of the reviews that have
been performed?
(1.b) Does the submitting author 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?
(1.c) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will be
entered into the ID Tracker.)
Arkko (Editor) Expires April 19, 2007 [Page 12]
Internet-Draft AD Sponsoring Guidelines October 2006
(1.d) Has the submitting author verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough.
(1.e) 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]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].
(1.f) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. 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 or
introduction.
Working Group Summary
Indicate the community and/or individuals that this submission
comes from. Was this proposal discussed in any public forum,
and was there anything in that discussion that is worth noting?
For example, was there controversy about particular points?
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?
The write-up is entered into the ID Tracker in the "Comment" field.
Arkko (Editor) Expires April 19, 2007 [Page 13]
Internet-Draft AD Sponsoring Guidelines October 2006
Author's Address
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@ericsson.com
Arkko (Editor) Expires April 19, 2007 [Page 14]
Internet-Draft AD Sponsoring Guidelines October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Arkko (Editor) Expires April 19, 2007 [Page 15]
