Difference between revisions of "RFC5742"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) H. AlvestrandRequest for Comments: 5742 GoogleBCP: 92 ...") |
|||
Line 1: | Line 1: | ||
+ | Internet Engineering Task Force (IETF) H. Alvestrand | ||
+ | Request for Comments: 5742 Google | ||
+ | BCP: 92 R. Housley | ||
+ | Obsoletes: 3932 Vigil Security | ||
+ | Updates: 2026, 3710 December 2009 | ||
+ | Category: Best Current Practice | ||
+ | ISSN: 2070-1721 | ||
+ | IESG Procedures for | ||
+ | Handling of Independent and IRTF Stream Submissions | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Abstract | Abstract | ||
Line 14: | Line 16: | ||
Submission and IRTF streams. | Submission and IRTF streams. | ||
− | This document updates procedures described in | + | This document updates procedures described in RFC 2026 and RFC 3710. |
Status of This Memo | Status of This Memo | ||
Line 24: | Line 26: | ||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | ||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | ||
− | BCPs is available in Section 2 of | + | BCPs is available in Section 2 of RFC 5741. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
Line 35: | Line 37: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
− | This document is subject to | + | This document is subject to BCP 78 and the IETF Trust's Legal |
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | ||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | ||
Line 44: | Line 46: | ||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | ||
described in the BSD License. | described in the BSD License. | ||
− | |||
− | |||
− | |||
− | |||
== Introduction and History == | == Introduction and History == | ||
− | + | RFC 4844 [N1] defines four RFC streams. When a document is submitted | |
for publication, the review that it receives depends on the stream in | for publication, the review that it receives depends on the stream in | ||
− | which it will be published. The four streams defined in | + | which it will be published. The four streams defined in RFC 4844 |
are: | are: | ||
Line 80: | Line 78: | ||
and the IRTF stream, respectively [N1]. | and the IRTF stream, respectively [N1]. | ||
− | Following the approval of | + | Following the approval of RFC 2026 [N2] and prior to the publication |
− | of | + | of RFC 3932 [I1], the IESG reviewed all Independent Submission stream |
documents before publication. This review was often a full-scale | documents before publication. This review was often a full-scale | ||
review of technical content, with the Area Directors (ADs) attempting | review of technical content, with the Area Directors (ADs) attempting | ||
Line 95: | Line 93: | ||
Soliciting technical review is deemed to be the responsibility of the | Soliciting technical review is deemed to be the responsibility of the | ||
RFC Editor. If an individual AD chooses to review the technical | RFC Editor. If an individual AD chooses to review the technical | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
content of the document and finds issues, that AD will communicate | content of the document and finds issues, that AD will communicate | ||
Line 136: | Line 128: | ||
=== Changes since RFC 3932 === | === Changes since RFC 3932 === | ||
− | + | RFC 3932 provided procedures for the review of Independent Submission | |
stream submissions. With the definition of procedures by the IRSG | stream submissions. With the definition of procedures by the IRSG | ||
for the IRTF stream, it has become clear that similar procedures | for the IRTF stream, it has become clear that similar procedures | ||
Line 150: | Line 142: | ||
Submission or IRTF stream document to explain the specific | Submission or IRTF stream document to explain the specific | ||
relationship, if any, to IETF work. In case there is a dispute about | relationship, if any, to IETF work. In case there is a dispute about | ||
− | |||
− | |||
− | |||
− | |||
the content of the IESG note, this document provides a dispute | the content of the IESG note, this document provides a dispute | ||
Line 161: | Line 149: | ||
The review of Independent Submissions by the IESG was prescribed by | The review of Independent Submissions by the IESG was prescribed by | ||
− | + | RFC 2026 [N2], Section 4.2.3. The procedure described in this | |
document is compatible with that description. | document is compatible with that description. | ||
Line 167: | Line 155: | ||
Research Groups also include review by the IESG [I2]. | Research Groups also include review by the IESG [I2]. | ||
− | The IESG Charter ( | + | The IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review |
process that was employed in Spring 2003 (even though the RFC was not | process that was employed in Spring 2003 (even though the RFC was not | ||
− | published until 2004); with the publication of | + | published until 2004); with the publication of RFC 3932 [I1], the |
− | procedure described in | + | procedure described in RFC 3710 was no longer relevant to documents |
submitted via the RFC Editor. The publication of this document | submitted via the RFC Editor. The publication of this document | ||
− | further updates Section 5.2.2 of | + | further updates Section 5.2.2 of RFC 3710, now covering both the IRTF |
and the Independent Submission streams. | and the Independent Submission streams. | ||
Line 178: | Line 166: | ||
The RFC Editor reviews Independent Submission stream submissions for | The RFC Editor reviews Independent Submission stream submissions for | ||
− | suitability for publication as RFCs. As described in | + | suitability for publication as RFCs. As described in RFC 4846 [I3], |
the RFC Editor asks the IESG to review the documents for conflicts | the RFC Editor asks the IESG to review the documents for conflicts | ||
with the IETF standards process or work done in the IETF community. | with the IETF standards process or work done in the IETF community. | ||
Line 200: | Line 188: | ||
the IETF work done in WG <X> and recommends not publishing the | the IETF work done in WG <X> and recommends not publishing the | ||
document at this time. | document at this time. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
4. The IESG has concluded that this document violates IETF procedures | 4. The IESG has concluded that this document violates IETF procedures | ||
Line 229: | Line 210: | ||
a document attempts to take actions (such as registering a new URI | a document attempts to take actions (such as registering a new URI | ||
scheme) that require IETF Review, Standards Action, or IESG Approval | scheme) that require IETF Review, Standards Action, or IESG Approval | ||
− | (as these terms are defined in | + | (as these terms are defined in RFC 5226 [I6]), and for the case where |
there is a proposed change or extension to an IETF protocol that was | there is a proposed change or extension to an IETF protocol that was | ||
not anticipated by the original authors and that may be detrimental | not anticipated by the original authors and that may be detrimental | ||
Line 256: | Line 237: | ||
considerations of possible harm to the Internet. If the IESG does | considerations of possible harm to the Internet. If the IESG does | ||
not find any conflict between an IRTF submission and IETF work, then | not find any conflict between an IRTF submission and IETF work, then | ||
− | |||
− | |||
− | |||
− | |||
the IRSG is responsible for judging the technical merits for that | the IRSG is responsible for judging the technical merits for that | ||
Line 307: | Line 284: | ||
inclusion of the IESG note, direct the withdrawal of the IESG note, | inclusion of the IESG note, direct the withdrawal of the IESG note, | ||
or leave the final decision to the RFC Editor. Unlike the IAB | or leave the final decision to the RFC Editor. Unlike the IAB | ||
− | reviews specified in | + | reviews specified in RFC 4846 [I3], if the IAB directs the inclusion |
− | |||
− | |||
− | |||
− | |||
− | |||
or withdrawal the IESG note, the IAB decision is binding, not | or withdrawal the IESG note, the IAB decision is binding, not | ||
Line 335: | Line 307: | ||
is X". | is X". | ||
− | Example: Photuris ( | + | Example: Photuris (RFC 2522), which was published after |
− | IKE ( | + | IKE (RFC 2409). |
Note: In general, the IESG has no problem with rejected | Note: In general, the IESG has no problem with rejected | ||
Line 359: | Line 331: | ||
appropriate for publication in the RFC Series. That is a matter for | appropriate for publication in the RFC Series. That is a matter for | ||
discussion in the Internet community. | discussion in the Internet community. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== IAB Statement == | == IAB Statement == | ||
In its capacity as the body that approves the general policy followed | In its capacity as the body that approves the general policy followed | ||
− | by the RFC Editor (see | + | by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this |
proposal and supports it as an operational change that is in line | proposal and supports it as an operational change that is in line | ||
with the respective roles of the IESG, IRTF, and RFC Editor. The IAB | with the respective roles of the IESG, IRTF, and RFC Editor. The IAB | ||
Line 386: | Line 351: | ||
== Acknowledgements == | == Acknowledgements == | ||
− | + | RFC 3932 was a product of the IESG in October 2004, and it was | |
reviewed in the IETF, by the RFC Editor, and by the IAB. Special | reviewed in the IETF, by the RFC Editor, and by the IAB. Special | ||
− | thanks for the development of | + | thanks for the development of RFC 3932 go to (in alphabetical order) |
Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot | Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot | ||
Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all other IETF | Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all other IETF | ||
community participants who provided valuable feedback. | community participants who provided valuable feedback. | ||
− | This update to | + | This update to RFC 3932 was the product of the IESG in July and |
August of 2008, and it was reviewed in the IETF, by the RFC Editor, | August of 2008, and it was reviewed in the IETF, by the RFC Editor, | ||
by the IRSG, and by the IAB. Special thanks for the development of | by the IRSG, and by the IAB. Special thanks for the development of | ||
Line 404: | Line 369: | ||
=== Normative Reference === | === Normative Reference === | ||
− | [N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC | + | [N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC |
− | [N2] Bradner, S., "The Internet Standards Process -- Revision 3", | + | Series and RFC Editor", RFC 4844, July 2007. |
− | + | ||
+ | [N2] Bradner, S., "The Internet Standards Process -- Revision 3", | ||
+ | BCP 9, RFC 2026, October 1996. | ||
+ | [N3] Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, | ||
+ | and Boilerplates", RFC 5741, December 2009. | ||
+ | |||
+ | === Informative References === | ||
+ | [I1] Alvestrand, H., "The IESG and RFC Editor Documents: | ||
+ | Procedures", BCP 92, RFC 3932, October 2004. | ||
+ | [I2] Falk, A., "Definition of an Internet Research Task Force (IRTF) | ||
+ | Document Stream", RFC 5743, December 2009. | ||
+ | [I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions | ||
+ | to the RFC Editor", RFC 4846, July 2007. | ||
+ | [I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of | ||
+ | the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May | ||
+ | 2000. | ||
+ | [I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. | ||
− | + | [I6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |
+ | Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Authors' Address | Authors' Address | ||
− | Harald | + | |
− | Russell | + | Harald Alvestrand |
+ | EMail: [email protected] | ||
+ | |||
+ | Russell Housley | ||
+ | EMail: [email protected] |
Revision as of 00:12, 28 September 2020
Internet Engineering Task Force (IETF) H. Alvestrand Request for Comments: 5742 Google BCP: 92 R. Housley Obsoletes: 3932 Vigil Security Updates: 2026, 3710 December 2009 Category: Best Current Practice ISSN: 2070-1721
IESG Procedures for Handling of Independent and IRTF Stream Submissions
Abstract
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
This document updates procedures described in RFC 2026 and RFC 3710.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc- editor.org/info/rfc5742.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
Contents
Introduction and History
RFC 4844 [N1] defines four RFC streams. When a document is submitted for publication, the review that it receives depends on the stream in which it will be published. The four streams defined in RFC 4844 are:
- The IETF stream - The IAB stream - The IRTF stream - The Independent Submission stream
The IETF is responsible for maintaining the Internet Standards Process, which includes the requirements for developing, reviewing and approving Standards Track and BCP RFCs. These RFCs, and any other IETF-generated Informational or Experimental documents, are reviewed by appropriate IETF bodies [N2] and published as part of the IETF stream.
Documents published in streams other than the IETF stream might not receive any review by the IETF for such things as security, congestion control, or inappropriate interaction with deployed protocols. Generally, there is no attempt for IETF consensus or IESG approval. Therefore, the IETF disclaims, for any of the non-IETF stream documents, any knowledge of the fitness of those RFCs for any purpose.
IESG processing described in this document is concerned only with the last two categories, which comprise the Independent Submission stream and the IRTF stream, respectively [N1].
Following the approval of RFC 2026 [N2] and prior to the publication of RFC 3932 [I1], the IESG reviewed all Independent Submission stream documents before publication. This review was often a full-scale review of technical content, with the Area Directors (ADs) attempting to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups (WGs), and so on. This was a considerable drain on the resources of the IESG, and because this was not the highest priority task of the IESG members, it often resulted in significant delays.
In March 2004, the IESG decided to make a major change in this review model, with the IESG taking responsibility only for checking for conflicts between the work of the IETF and the documents submitted. Soliciting technical review is deemed to be the responsibility of the RFC Editor. If an individual AD chooses to review the technical
content of the document and finds issues, that AD will communicate these issues to the RFC Editor, and they will be treated the same way as comments on the documents from other sources.
Prior to 2006, documents from the IRTF were treated as either IAB submissions or Independent Submissions via the RFC Editor. However, the Internet Research Steering Group (IRSG) has established a review process for the publication of RFCs from the IRTF stream [I2]. Once these procedures are fully adopted, the IESG will be responsible only for checking for conflicts between the work of the IETF and the documents submitted, but results of the check will be reported to the IRTF. These results may be copied to the RFC Editor as a courtesy.
This document describes only the review process done by the IESG when the RFC Editor or the IRTF requests that review. The RFC Editor will request the review of Independent Submission stream documents, and the IRTF will request review of IRTF stream documents. There are many other interactions between document editors and the IESG, for instance, an AD may suggest that an author submit a document as input for work within the IETF rather than to the RFC Editor as part of the Independent Submission stream, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor as part of Independent Submission stream, but these interactions are not described in this memo.
For the convenience of the reader, this document includes description of some actions taken by the RFC Editor, the IAB, and the IRSG. The inclusion of these actions is not normative. Rather, these actions are included to describe the overall process surrounding the normative IESG procedures described in this document. No RFC Editor, IAB, or IRSG procedures are set by this document.
Changes since RFC 3932
RFC 3932 provided procedures for the review of Independent Submission stream submissions. With the definition of procedures by the IRSG for the IRTF stream, it has become clear that similar procedures apply to the review by the IESG of IRTF stream documents.
The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents.
The IESG may request the inclusion of an IESG note in an Independent Submission or IRTF stream document to explain the specific relationship, if any, to IETF work. In case there is a dispute about
the content of the IESG note, this document provides a dispute resolution process.
Background Material
The review of Independent Submissions by the IESG was prescribed by RFC 2026 [N2], Section 4.2.3. The procedure described in this document is compatible with that description.
The procedures developed by the IRTF for documents created by the Research Groups also include review by the IESG [I2].
The IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review process that was employed in Spring 2003 (even though the RFC was not published until 2004); with the publication of RFC 3932 [I1], the procedure described in RFC 3710 was no longer relevant to documents submitted via the RFC Editor. The publication of this document further updates Section 5.2.2 of RFC 3710, now covering both the IRTF and the Independent Submission streams.
Detailed Description of IESG Review
The RFC Editor reviews Independent Submission stream submissions for suitability for publication as RFCs. As described in RFC 4846 [I3], the RFC Editor asks the IESG to review the documents for conflicts with the IETF standards process or work done in the IETF community.
Similarly, documents intended for publication as part of the IRTF stream are sent to the IESG for review for conflicts with the IETF standards process or work done in the IETF community [I2].
The IESG review of these Independent Submission and IRTF stream documents results in one of the following five types of conclusion, any of which may be accompanied by a request to include an IESG note if the document is published.
1. The IESG has concluded that there is no conflict between this
document and IETF work.
2. The IESG has concluded that this work is related to IETF work done
in WG <X>, but this relationship does not prevent publishing.
3. The IESG has concluded that publication could potentially disrupt
the IETF work done in WG <X> and recommends not publishing the document at this time.
4. The IESG has concluded that this document violates IETF procedures
for <Y> and should therefore not be published without IETF review and IESG approval.
5. The IESG has concluded that this document extends an IETF protocol
in a way that requires IETF review and should therefore not be published without IETF review and IESG approval.
The RFC headers and boilerplate [N3] is intended to describe the relationship of the document to the IETF standards process. In exceptional cases, when the relationship of the document to the IETF standards process might be unclear, the IESG may request the inclusion of an IESG note to clarify the relationship of the document to the IETF standards process. Such a note is likely to include pointers to related IETF RFCs. The dispute resolution process in Section 4 is provided to handle situations in which the IRSG or RFC Editor is concerned with the content of the requested IESG note.
The last two responses are included respectively, for the case where a document attempts to take actions (such as registering a new URI scheme) that require IETF Review, Standards Action, or IESG Approval (as these terms are defined in RFC 5226 [I6]), and for the case where there is a proposed change or extension to an IETF protocol that was not anticipated by the original authors and that may be detrimental to the normal usage of the protocol, but where the protocol documents do not explicitly say that this type of extension requires IETF review.
If a document requires IETF review, the IESG will offer the author the opportunity to ask for publication as an AD-sponsored individual document, which is subject to full IETF review, including possible assignment to a WG or rejection. Redirection to the full IESG review path is not a guarantee that the IESG will accept the work item, or even that the IESG will give it any particular priority; it is a guarantee that the IESG will consider the document.
The IESG will normally complete review within four weeks of notification by the RFC Editor or IRTF. In the case of a possible conflict, the IESG may contact a WG or a WG Chair for an outside opinion of whether publishing the document is harmful to the work of that WG and, in the case of a possible conflict with an IANA registration procedure, the IANA expert for that registry.
If the IESG does not find any conflict between an Independent Submission and IETF work, then the RFC Editor is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet. If the IESG does not find any conflict between an IRTF submission and IETF work, then
the IRSG is responsible for judging the technical merits for that submission, including considerations of possible harm to the Internet.
The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of Independent Submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions.
Dispute Resolution
Experience has shown that the IESG and the RFC Editor have worked well together regarding publication recommendations and IESG notes. Where questions have arisen, they have been quickly resolved when all parties become aware of the concerns. However, should a dispute ever arise, a third party can assist with resolution. Therefore, this dispute procedure has an informal dialogue phase followed by an arbitration phase if the matter remains unresolved.
If the IESG requests the inclusion of an IESG note and the IRSG or the RFC Editor intends to publish the document without the requested IESG note, then they must provide a clear and concise description of the concerns to the IESG before proceeding. A proposal for alternate IESG note text from the IRSG or the RFC Editor is highly encouraged.
If the IESG does not want the document to be published without the requested IESG note, then the IESG must initiate an informal dialogue. The dialogue should not take more than six weeks. This period of time allows the IESG to conduct an IETF Last Call concerning the content of the requested IESG note (and not on the document as a whole) to determine community consensus if desired. At the end of the dialogue, the IESG can reaffirm the original IESG note, provide an alternate IESG note, or withdraw the note altogether. If an IESG note is requested, the IRSG or the RFC Editor must state whether they intend to include it.
If dialogue fails to resolve IRSG or RFC Editor concerns with the content of a requested IESG note and they intend to publish the document as an RFC without the requested IESG note, then the IESG can formally ask the IAB to provide arbitration. The IAB is not obligated to perform arbitration and may decline the request. If the IAB declines, the RFC Editor decides whether the IESG note is included. If the IAB accepts, the IAB review will occur according to procedures of the IAB's own choosing. The IAB can direct the inclusion of the IESG note, direct the withdrawal of the IESG note, or leave the final decision to the RFC Editor. Unlike the IAB reviews specified in RFC 4846 [I3], if the IAB directs the inclusion
or withdrawal the IESG note, the IAB decision is binding, not advisory.
Examples of Cases Where Publication Is Harmful
This section gives a couple of examples where delaying or preventing publication of a document might be appropriate due to conflict with IETF work. It forms part of the background material, not a part of the procedure.
Rejected Alternative Bypass:
As a WG is working on a solution to a problem, a participant decides to ask for Independent Submission stream publication of a solution that the WG has rejected. Publication of the document will give the publishing party an RFC number before the WG is finished. It seems better to have the WG product published first, and have the non-adopted document published later, with a clear disclaimer note saying that "the IETF technology for this function is X".
Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).
Note: In general, the IESG has no problem with rejected alternatives being made available to the community; such publications can be a valuable contribution to the technical literature. However, it is necessary to avoid confusion with the alternatives adopted by the WG.
Inappropriate Reuse of "free" Bits:
In 2003, a proposal for an experimental RFC was published that wanted to reuse the high bits of the "fragment offset" part of the IP header for another purpose. No IANA consideration says how these bits can be repurposed, but the standard defines a specific meaning for them. The IESG concluded that implementations of this experiment risked causing hard-to-debug interoperability problems and recommended not publishing the document in the RFC series. The RFC Editor accepted the recommendation.
The RFC series is one of many available publication channels; this document takes no position on the question of which documents are appropriate for publication in the RFC Series. That is a matter for discussion in the Internet community.
IAB Statement
In its capacity as the body that approves the general policy followed by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this proposal and supports it as an operational change that is in line with the respective roles of the IESG, IRTF, and RFC Editor. The IAB continues to monitor discussions within the IETF about potential adjustments to the IETF document publication processes and recognizes that the process described in this document, as well as other general IETF publication processes, may need to be adjusted to align with any changes that result from such discussions.
Security Considerations
The process change described in this memo has no direct bearing on the security of the Internet.
Acknowledgements
RFC 3932 was a product of the IESG in October 2004, and it was reviewed in the IETF, by the RFC Editor, and by the IAB. Special thanks for the development of RFC 3932 go to (in alphabetical order) Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all other IETF community participants who provided valuable feedback.
This update to RFC 3932 was the product of the IESG in July and August of 2008, and it was reviewed in the IETF, by the RFC Editor, by the IRSG, and by the IAB. Special thanks for the development of this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Olaf Kolkman, and Andy Malis.
References
Normative Reference
[N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[N2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[N3] Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers,
and Boilerplates", RFC 5741, December 2009.
Informative References
[I1] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[I2] Falk, A., "Definition of an Internet Research Task Force (IRTF)
Document Stream", RFC 5743, December 2009.
[I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions
to the RFC Editor", RFC 4846, July 2007.
[I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[I6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Authors' Address
Harald Alvestrand EMail: [email protected]
Russell Housley EMail: [email protected]