GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3932

Network Working Group H. Alvestrand Request for Comments: 3932 October 2004 BCP: 92 Updates: 3710, 2026 Category: Best Current Practice

           The IESG and RFC Editor Documents: Procedures

Status of this Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document describes the IESG's procedures for handling documents
 submitted for RFC publication via the RFC Editor, subsequent to the
 changes proposed by the IESG at the Seoul IETF, March 2004.
 This document updates procedures described in RFC 2026 and RFC 3710.

1. Introduction and History

 There are a number of different methods by which an RFC is published,
 some of which include review in the Internet Engineering Task Force
 (IETF), and some of which include approval by the Internet
 Engineering Steering Group (IESG):
 o  IETF Working Group (WG) to Standards Track: Includes WG consensus,
    review in the IETF, IETF Last Call, and IESG approval
 o  IETF WG to Experimental/Informational: Includes WG consensus,
    review in the IETF, and IESG approval
 o  Area Director (AD) sponsored to Standards Track: Includes review
    in the IETF, IETF Last Call, and IESG approval
 o  AD Sponsored Individual to Experimental/Informational: Includes
    some form of review in the IETF and IESG approval
 o  Documents for which special rules exist

Alvestrand Best Current Practice [Page 1] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

 o  RFC Editor documents to Experimental/Informational
 This memo is only concerned with the IESG processing of the last
 category.
 Special rules apply to some documents, including documents from the
 Internet Architecture Board (IAB), April 1st RFCs, and republication
 of documents from other standards development organizations.  The
 IESG and the RFC Editor keep a running dialogue, in consultation with
 the IAB, on these other documents and their classification, but they
 are outside the scope of this memo.
 For the last few years, the IESG has reviewed all RFC Editor
 documents (documents submitted by individuals to the RFC Editor for
 RFC publication) before publication.  In 2003, this review was often
 a full-scale review of technical content, with the ADs attempting to
 clear points with the authors, stimulate revisions of the documents,
 encourage the authors to contact appropriate working groups and so
 on.  This was a considerable drain on the resources of the IESG, and
 since this is 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.  The new review model will have the IESG take 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 IESG member
 chooses to review the technical content of the document and finds
 issues, that member will communicate these issues to the RFC Editor,
 and they will be treated the same way as comments on the documents
 from other sources.
 Note: This document describes only the review process done by the
 IESG when the RFC Editor requests that review.  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, or the IESG may
 suggest that a document submitted to the IETF is better suited for
 submission to the RFC Editor but these interactions are not described
 in this memo.

2. Background Material

 The review of independent submissions by the IESG was prescribed by
 RFC 2026 [1] section 4.2.3.  The procedure described in this document
 is compatible with that description.

Alvestrand Best Current Practice [Page 2] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

 RFC 3710 [4] section 5.2.2 describes the spring 2003 review process
 (even though the RFC was published in 2004); with the publication of
 this document, the procedure described in RFC 3710 is no longer
 relevant to documents submitted via the RFC Editor.

3. Detailed Description of IESG Review

 The RFC Editor reviews submissions for suitability for publications
 as RFC.  Once the RFC Editor thinks a document may be suited for RFC
 publication, the RFC Editor asks the IESG to review the documents for
 conflicts with the IETF standards process or work done in the IETF
 community.
 The review is initiated by a note from the RFC Editor specifying the
 document name, the RFC Editor's belief about the document's present
 suitability for publication, and (if possible) the list of people who
 have reviewed the document for the RFC Editor.
 The IESG may return five different responses, any of which may be
 accompanied by an IESG note to be put on the document if the RFC
 Editor wishes to publish.
 1. The IESG has not found any conflict between this document and IETF
    work.
 2. The IESG thinks that this work is related to IETF work done in WG
    <X>, but this does not prevent publishing.
 3. The IESG thinks that publication is harmful to the IETF work done
    in WG <X> and recommends not publishing the document at this time.
 4. The IESG thinks that this document violates IETF procedures for
    <X> and should therefore not be published without IETF review and
    IESG approval.
 5. The IESG thinks 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 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 consensus or IESG approval (as these terms
 are defined in RFC 2434 [2]), and for the case where an IETF protocol
 is proposed to be changed or extended in an unanticipated way that
 may be harmful to the normal usage of the protocol, but where the
 protocol documents do not explicitly say that this type of extension
 requires IETF review.

Alvestrand Best Current Practice [Page 3] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

 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 IESG 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 have review done within 4 weeks from the RFC
 Editor's notification.  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 the WG and, in the
 case of a possible conflict with an IANA registration procedure, the
 IANA expert for that registry.
 Note that if the IESG has not found any conflict between a submission
 and IETF work, then judging its technical merits, including
 considerations of possible harm to the Internet, will become the
 responsibility of the RFC Editor.  The IESG assumes that the RFC
 Editor, in agreement with the IAB, will manage mechanisms for
 additional technical review.

4. Standard IESG Note

 One of the following IESG notes will be sent to the RFC Editor for
 all documents, with a request for placement either in or immediately
 following the "Status of this Memo" section of the finished RFC,
 unless the IESG decides otherwise:
 1. For documents that specify a protocol or other technology, and
    that have been considered in the IETF at one time:
    The content of this RFC was at one time considered by the IETF,
    and therefore it may resemble a current IETF work in progress or a
    published IETF work.  This RFC is not a candidate for any level of
    Internet Standard.  The IETF disclaims any knowledge of the
    fitness of this RFC for any purpose and in particular notes that
    the decision to publish is not based on IETF review for such
    things as security, congestion control, or inappropriate
    interaction with deployed protocols.  The RFC Editor has chosen to
    publish this document at its discretion.  Readers of this RFC
    should exercise caution in evaluating its value for implementation
    and deployment.  See RFC 3932 for more information.

Alvestrand Best Current Practice [Page 4] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

 2. For documents that specify a protocol or similar technology and
    are independent of the IETF process:
    This RFC is not a candidate for any level of Internet Standard.
    The IETF disclaims any knowledge of the fitness of this RFC for
    any purpose and in particular notes that the decision to publish
    is not based on IETF review for such things as security,
    congestion control, or inappropriate interaction with deployed
    protocols.  The RFC Editor has chosen to publish this document at
    its discretion.  Readers of this document should exercise caution
    in evaluating its value for implementation and deployment.  See
    RFC 3932 for more information.
 3. For documents that do not specify a protocol or similar
    technology:
    This RFC is not a candidate for any level of Internet Standard.
    The IETF disclaims any knowledge of the fitness of this RFC for
    any purpose and notes that the decision to publish is not based on
    IETF review apart from IESG review for conflict with IETF work.
    The RFC Editor has chosen to publish this document at its
    discretion.  See RFC 3932 for more information.

5. 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: A WG is working on a solution to a
 problem, and a participant decides to ask for publication of a
 solution that the WG has rejected.  Publication of the document will
 give the publishing party an RFC number to refer to 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).
 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

Alvestrand Best Current Practice [Page 5] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

 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.
 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 the working group
 did adopt.
 The RFC series is one of many available publication channels; this
 document takes no position on the question of which documents the RFC
 series is appropriate for.  That is a matter for discussion in the
 IETF community.

6. IAB Statement

 In its capacity as the body that approves the general policy followed
 by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this
 proposal and supports it as an operational change that is in line
 with the respective roles of the IESG and RFC Editor.  The IAB
 continues to monitor the range of organized discussions within the
 IETF about potential adjustments to the IETF document publication
 processes (e.g., NEWTRK working group) and recognizes that the
 process described in this document, as well as other general IETF
 publication processes, may need to be adjusted in the light of the
 outcome of those discussions.

7. Security Considerations

 The process change described in this memo has no direct bearing on
 the security of the Internet.

8. Acknowledgements

 This document is a product of the IESG, and all its members deserve
 thanks for their contributions.
 This document has been reviewed in the IETF and by the RFC Editor and
 the IAB; the IAB produced the text of section 6.  Special thanks go
 to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt
 Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and all other
 IETF community members who provided valuable feedback on the
 document.

Alvestrand Best Current Practice [Page 6] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

9. References

9.1. Normative Reference

 [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

9.2. Informative References

 [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 [3]  Internet Architecture Board and B. Carpenter, Ed., "Charter of
      the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May
      2000.
 [4]  Alvestrand, H., "An IESG charter", RFC 3710, February 2004.

Author's Address

 Harald Alvestrand
 EMail: harald@alvestrand.no

Alvestrand Best Current Practice [Page 7] RFC 3932 IESG and RFC Editor Documents: Procedures October 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 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 IETF's procedures with respect to rights in IETF 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Alvestrand Best Current Practice [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3932.txt · Last modified: 2004/10/06 18:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki