doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc3710.txt b/doc/rfc/rfc3710.txt
new file mode 100644
index 0000000..a0c0453
--- /dev/null
+++ b/doc/rfc/rfc3710.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      H. Alvestrand
+Request for Comments: 3710                                 Cisco Systems
+Category: Informational                                    February 2004
+
+
+                            An IESG charter
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This memo provides a charter for the Internet Engineering Steering
+   Group (IESG), a management function of the Internet Engineering Task
+   Force (IETF).  It is meant to document the charter of the IESG as it
+   is presently understood.
+
+1.  Introduction
+
+1.1.  The Role of the IESG
+
+   The Internet Engineering Steering Group (IESG) is the group
+   responsible for the direct operation of the IETF and for ensuring the
+   quality of work produced by the IETF.
+
+   The IESG charters and terminates working groups, selects their
+   chairs, monitors their progress and coordinates efforts between them.
+   The IESG performs technical review and approval of working group
+   documents and candidates for the IETF standards track, and reviews
+   other candidates for publication in the RFC series.  It also
+   administers IETF logistics, including operation of the Internet-Draft
+   document series and the IETF meeting event.
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                   Informational                      [Page 1]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+1.2.  Historic Note
+
+   The role of the IESG in the IETF management structure has been
+   largely constant since 1993, after the significant changes introduced
+   by the "POISED" process, and documented in RFC 1602 [5].  (The
+   previous process was documented in RFC 1310 [4]; RFC 1602 has later
+   been updated by RFC 1871 [7] and obsoleted by RFC 2026 [1].)
+
+   Some of the functions were also defined in RFC 1603 [6], Working
+   Group Guidelines, which was later obsoleted by RFC 2418 [2].
+
+   As the community has grown, and the IESG has gathered experience, the
+   ways in which the IESG has approached its tasks have varied
+   considerably, but the tasks have remained relatively constant.
+
+   This document describes the tasks assigned to the IESG.  It does not
+   attempt to describe in detail the procedures the IESG uses to
+   accomplish these tasks; that is done elsewhere - consult the IESG's
+   Web pages on the IETF Website for more information [9].
+
+   At this time (spring 2003), the structure of the IETF is undergoing
+   reevaluation, and the result is likely to include changes to the
+   IESG's role.  Therefore, this document was written as a
+   "documentation of existing practice" rather than as IETF consensus on
+   what the IESG should do.
+
+   This document is published as an Informational RFC, detailing the
+   current operations of the IESG.  It does not claim to represent
+   consensus of the IETF that this is the right set of instructions to
+   the IESG.
+
+2.  The Composition of the IESG
+
+   The IESG has the following members:
+
+   o  The IETF Chair, who also functions as the General Area Director
+      when this area is active
+
+   o  The Area Directors (ADs) for the IETF Areas
+
+   o  The Internet Architecture Board (IAB) Chair and the IETF Executive
+      Director, as ex-officio members of the IESG.
+
+   The IETF Chair and the Area Directors are selected by the IETF NomCom
+   according to the procedures of BCP 10 [3] (Nomcom procedures).
+
+   The IETF Executive Director is the person charged with running the
+   IETF Secretariat.
+
+
+
+Alvestrand                   Informational                      [Page 2]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+   The IESG also has liaisons, who are members of the IESG mailing list
+   and may attend all IESG meetings.  The Liaison positions exist to
+   facilitate the work of the IETF by expediting communication with
+   other entities involved in the IETF process; which positions to have
+   are decided by the IESG.
+
+   The liaisons are selected as appropriate by the bodies they
+   represent.  At the time of this writing, the liaisons present
+   represent the following bodies:
+
+      The RFC Editor
+
+      The IANA
+
+      The IAB
+
+   In addition, members of the IETF Secretariat are subscribed to the
+   mailing list and present in the IESG meetings as needed in order to
+   serve as a support function.
+
+   IESG decisions are made by the IETF Chair and the Area Directors.
+   All IESG members can participate in the IESG's discussions.
+
+3.  Procedural Issues
+
+   While the IESG is generally free to set its own procedures, some
+   parts of its procedures are properly part of its charter.  These are
+   given here.
+
+3.1.  Decision Making
+
+   The IESG attempts to reach all decisions unanimously.  If unanimity
+   cannot be achieved, the chair may conduct informal polls to determine
+   consensus.  There is no general rule on how the IESG takes votes; if
+   this had ever been needed, it is likely that the same rule as for the
+   IAB would be used (decisions may be taken if at least two thirds of
+   the members concur and there are no more than two dissents).
+
+   For the purpose of judging consensus, only the IETF Chair and the
+   Area Directors are counted.
+
+   The IESG may decide that other procedures for reaching a decision are
+   appropriate under specific conditions.  Such other procedures may
+   include:
+
+   o  Assertions of IETF consensus, such as when evaluating a standards
+      action.  Here, in addition to the technical quality of the
+      specification, the IESG has to evaluate the community opinion
+
+
+
+Alvestrand                   Informational                      [Page 3]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+      about the specification's subject matter; this has to happen with
+      due notice and opportunity for community feedback.
+
+   o  IESG actions in areas where the IESG has the authority to take
+      action.  This does not need special rules.
+
+   o  AD actions taken with the advice and consent of the IESG; the IESG
+      is expected to be kept informed, and gives comment, but the
+      authority to act is delegated to the AD.
+
+   o  AD action; cases where an AD can take independent action without
+      needing to consult the IESG first.
+
+   The IESG may reach decisions by face to face meeting,
+   teleconferencing, Internet communication, or any combination of the
+   above.
+
+3.2.  Openness and Confidentiality
+
+   The IESG publishes a record of decisions from its meetings on the
+   Internet, and conducts an open meeting at every IETF meeting.  It
+   publishes more detailed documentation of decisions as RFCs, Internet
+   Drafts or messages to the IETF-announce mailing list, with copies
+   kept on the IETF website when appropriate.
+
+   The IESG also has private group discussions, using any means of its
+   choice, including email.  Records of those discussions are not
+   required to be made public.  This is believed to be vital in
+   permitting a frank exchange of viewpoints and worries, allowing
+   people to speak out freely on topics known to be controversial, and
+   permitting people to change their minds based on presented arguments.
+   Decisions and their justification are a matter of public record.
+
+   However, discussion of personnel matters and possibly legal and
+   financial matters may sometimes be required to be kept confidential,
+   and the chair may, with the consent of the full members, exclude
+   liaison and ex officio members whose presence is seen as
+   inappropriate for the particular discussion.
+
+   The chair may also exclude members and liaisons who have a serious
+   conflict of interest on an issue (although this has never been
+   enacted).  Members can also choose to recuse themselves from
+   discussion of an issue, or refrain from participating in a particular
+   ballot, if they feel it is appropriate.
+
+
+
+
+
+
+
+Alvestrand                   Informational                      [Page 4]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+4.  The IESG Role in Working Group Management
+
+   The IESG is in charge of managing the working group process.  While
+   the process of managing a working group is assigned to the working
+   group chairs, the IESG is in charge of those processes that are
+   beyond the scope of the working group chair's role.  Most of these
+   functions are delegated by the IESG to a single Area Director - the
+   "responsible Area Director" for the group.
+
+4.1.  Working Group Creation
+
+   The formation of working groups is described in  BCP 25 [2], section
+   2; this document does not repeat the text there, but gives additional
+   details of IESG actions.
+
+   A Working Group (WG) may be requested by members of the IETF
+   community, who address the request to an AD that the requesters feel
+   is the appropriate AD for the task, or the formation can be initiated
+   by an AD.  The IESG may assign the prospective working group to
+   another AD and/or Area if the IESG thinks that is best.
+
+   The AD is responsible for ensuring that a working group being
+   chartered fulfills the criteria for WG formation given in BCP 25.
+   The charter is the result of a negotiation between the AD and the
+   community of interest, with review and advice from the rest of the
+   IESG and the IAB.
+
+   The AD, with the advice of the IESG, is also responsible for
+   selecting chairs for the working group which the AD thinks will be up
+   to the task.
+
+   All charters for proposed working groups are announced to the
+   community at large when the IESG thinks the charter is ready for
+   review, but prior to the IESGs final decision on chartering the WG.
+   The final decision to charter a WG is an IESG decision.
+
+   The Birds of a Feather (BOF) procedure described in BCP 25 [2],
+   section 2.4 also requires approval from the relevant AD (the one who
+   got the request or the AD that the IESG thinks is the right AD to
+   manage the task).  A BOF is not required to start a working group,
+   and a BOF may be held without the purpose of creating a working
+   group.  BOFs are also often discussed with the IESG and IAB.
+
+
+
+
+
+
+
+
+
+Alvestrand                   Informational                      [Page 5]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+4.2.  Working Group Management
+
+   The role of the Area Director in WG management is described in BCP 25
+   [2], section 6.7.
+
+   The role of managing a WG is divided between the WG Chair(s) and the
+   AD.
+
+   A WG chair has to manage the working group "from the inside", dealing
+   with individuals, drafts, proposals, meetings and email lists, and
+   has full power and responsibility to do that.
+
+   An AD manages a WG "from the outside", dealing with charters, chairs,
+   cross-WG and cross-area relationships and so on.
+
+   The AD is responsible for making sure the working groups stay focused
+   on the charter tasks, make forward progress, are coordinated with the
+   rest of the area, and are coordinated with the rest of the IETF.  The
+   ADs help each other with maintaining cross-area coordination.
+
+   In a well functioning working group, main responsibility for these
+   things rests with the chairs; the AD will normally be able to
+   concentrate on supporting the working group chairs' work.
+
+   When a WG finds that it is essential that work gets done which is not
+   on its charter, the AD, consulting with the rest of the IESG as
+   required, is responsible for figuring out whether to add it to their
+   charter, add it to another group's charter, task someone outside the
+   WG to work on it, or initiate creation of another WG.
+
+   Substantive changes to the body of a WG's charter require the same
+   type of process as chartering - see BCP 25 [2], section 5.
+
+   The Area Director is also responsible for picking and, when
+   necessary, replacing working group chairs.  This is done in
+   consultation with the IESG, but the decision is made by the
+   responsible AD.
+
+4.3.  Working Group Termination
+
+   Terminating a WG is a decision of the responsible AD.
+
+   A working group may be shut down when its work is complete, or when
+   the AD concludes that letting the working group continue its work no
+   longer contributes to the IETF's progress.
+
+   The decision to terminate a working group is announced, giving the
+   reason for termination.
+
+
+
+Alvestrand                   Informational                      [Page 6]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+5.  The IESG Role in Document Review
+
+   The IESG is expected to ensure that the documents are of a sufficient
+   quality for release as RFCs, that they describe their subject matter
+   well, and that there are no outstanding engineering issues that
+   should be addressed before publication.  The degree of review will
+   vary with the intended status and perceived importance of the
+   documents.
+
+   When there are problems or solutions that occur frequently, the IESG
+   may publish documents describing the problems and how to avoid them,
+   such as "IANA considerations" (BCP 26 [8]), or publish web pages with
+   commonly used guidelines.
+
+   Rules - stuff that the community is expected to follow - are decided
+   by IETF consensus processing and commonly published as BCP RFCs.
+
+   Guidance to the community that is of a more ephemeral and less
+   normative nature is decided by the IESG and published on the IESG's
+   Web pages.
+
+5.1.  Working Group Documents
+
+   This role is described in BCP 25 [2], section 7.5 and 8, and BCP 9
+   [1], section 6.  The IESG role is one of review and approval.
+
+5.2.  Non-Working Group Documents
+
+5.2.1.  Standards-Track Documents
+
+   This role, which applies to Proposed, Draft, Standard and BCP
+   processing, is described in BCP 9 [1], section 6.  Such documents are
+   submitted to the IESG, and are then assigned to a relevant AD.  The
+   IESG is responsible for determining:
+
+   o  Whether or not the specification is appropriate for the standards
+      track
+
+   o  Whether or not the specification needs review by one or more
+      existing WGs
+
+   o  Whether or not the quality of the specification is adequate
+
+   The IESG will either approve or disapprove of the publication of the
+   document on the standards track; no document can be published on the
+   standards track without IESG approval.
+
+
+
+
+
+Alvestrand                   Informational                      [Page 7]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+   The IESG may decide that a document submitted for standards-track
+   publication should instead be published as Experimental or
+   Informational, or that a document submitted for Proposed standard
+   should be published as a BCP, or vice versa.
+
+5.2.2.  Informational and Experimental Documents
+
+   These documents are normally submitted to the RFC Editor in
+   accordance with the procedures of BCP 9 [1], section 4.2.3 and BCP 25
+   [2], section 8.  The IESG is asked to review all documents submitted
+   in this fashion for conflicts with the IETF standards process or work
+   done in the IETF community; this is a modification of the BCP 9 [1]
+   procedure, and documented in BCP 25 [2], section 8.
+
+   The IESG may recommend that the document be published as-is, that it
+   be reviewed by a working group, that the document be published with
+   an IESG note indicating issues such as conflict with the IETF
+   standards process, or may recommend that the document not be
+   published.
+
+   If the document is referred to a WG, the WG can recommend that the
+   document be adopted as a WG document, that it be published (possibly
+   with comments), or that the IESG recommend to the RFC Editor that it
+   not be published.  The responsible AD for the WG is responsible for
+   getting a response from the WG in a timely manner.
+
+   An AD, in consultation with the author, may choose to put an
+   individual's document directly before the IESG, without waiting for
+   the document to be submitted through the RFC Editor.  This document
+   will then be processed in the same fashion as an Informational or
+   Experimental document from a working group.
+
+5.3.  IESG Review Procedures
+
+   The IESG review procedures are defined by the IESG.
+
+   The IESG is responsible for conducting the process in a timely manner
+   with appropriate communication.
+
+   For all documents, the IESG assigns a specific AD the responsibility
+   of shepherding the document; that AD will normally review the
+   document, and possibly ask for revisions to it to address obvious
+   problems, before asking the entire IESG to consider it for
+   publication.
+
+   The IESG has web pages as part of the IETF web (www.ietf.org);
+   current details of procedures, as well as the means of finding the
+   responsible AD for any document, are published there.
+
+
+
+Alvestrand                   Informational                      [Page 8]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+6.  The IESG Role in Area Management
+
+   The IETF divides its work into a number of areas, each comprised of
+   working groups that relate to that area's focus (BCP 25 [2], section
+   1).  The area structure is defined by the IESG, and the IESG can add
+   areas, redefine areas, merge areas, change the number of ADs assigned
+   to an area, or close down areas.
+
+   Changes to the area structure affect the IETF in many ways; decisions
+   to change the area structure are taken in consultation with the
+   community.
+
+   When changing the area structure, the IESG can decide which members
+   are responsible for new and changed areas, including making one
+   sitting AD responsible for multiple areas, but the IESG can only add
+   new members through the nomcom process.
+
+   The primary task of area management is handled by one or two Area
+   Directors per area.  An AD may be advised by one or more
+   directorates, which are created, selected, chaired and if necessary
+   disbanded by the AD (BCP 25 [2], section 1).  Directorates may be
+   specific to an area, specific to a technology, or chartered in some
+   other fashion.
+
+   The ADs for an area are jointly responsible for making sure the WGs
+   in the area are well coordinated, that there is coverage for the
+   technologies needed in the area, and that the challenges most
+   important to the Internet in that area are indeed being worked on.
+
+   The IESG decides which areas working groups belong to.
+
+7.  Other IESG Roles
+
+7.1.  Staff Supervision
+
+   The IETF Chair has primary responsibility for supervising the work of
+   the IETF Secretariat, with the advice and consent of the IESG, the
+   IAB Chair and the ISOC president.
+
+   The supervision of the Internet Assigned Numbers Authority (IANA) and
+   RFC-Editor functions is handled by the IAB.
+
+
+
+
+
+
+
+
+
+
+Alvestrand                   Informational                      [Page 9]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+7.2.  Process Management
+
+   The IESG is responsible for making sure the IETF process is
+   functional in all aspects.  This includes taking responsibility for
+   initiating consideration of updates to the process when required, as
+   well as addressing obvious miscarriages of process, even when they do
+   not fall into the categories described above.
+
+7.3.  External Relations
+
+   The responsibility for handling external relations rests with the
+   IAB, as described in the IAB Charter (RFC 2850 [10]).  However, when
+   technical cooperation is required, it is essential that the work be
+   coordinated with the relevant ADs.  This often means that ADs will
+   function in a liaison role with other organizations, but the IAB may
+   decide that the same function may also be done by others when it
+   decides that this is more appropriate.
+
+7.4.  Appeals Actions
+
+   The formal appeals procedure is described in BCP 9 [1], section 6.5.
+
+   Most decisions by a working group chair can be appealed to the AD,
+   and decisions by an individual AD can be appealed to the IESG.
+
+   Decisions of the IESG can be appealed to the IAB; for this reason,
+   the IAB chair and the liaison from the IAB recuse themselves from
+   discussion of appeals to the IESG.
+
+8.  Security Considerations
+
+   The security of the Internet depends on standards giving proper
+   thought to security.  Apart from that, there seems to be no
+   considerations of security relevant to this memo.
+
+9.  Acknowledgements
+
+   This work has been supported, aided and abetted by the whole IESG at
+   the time of this writing, and has benefited from many other comments.
+
+   Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret
+   Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz,
+   Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and
+   all others who provided comments on various versions of this
+   document!
+
+
+
+
+
+
+Alvestrand                   Informational                     [Page 10]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [2]  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
+        25, RFC 2418, September 1998.
+
+   [3]  Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
+        Process: Operation of the Nominating and Recall Committees", BCP
+        10, RFC 2727, February 2000.
+
+10.2.  Informative References
+
+   [4]  Chapin, L., "The Internet Standards Process", RFC 1310, March
+        1992.
+
+   [5]  Huitema, C. and P. Gross, "The Internet Standards Process --
+        Revision 2", RFC 1602, March 1994.
+
+   [6]  Huizer, E. and D. Crocker, "IETF Working Group Guidelines and
+        Procedures", RFC 1603, March 1994.
+
+   [7]  Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2,
+        RFC 1871, November 1995.
+
+   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [9]  http://www.ietf.org
+
+   [10] Carpenter, B., Ed., "Charter of the Internet Architecture Board
+        (IAB)", BCP 39, RFC 2850, May 2000.
+
+11.  Author's Address
+
+   Harald Tveit Alvestrand
+   Cisco Systems
+   5245 Arboretum Dr
+   Los Altos, CA
+   USA
+
+   EMail: harald@alvestrand.no
+
+
+
+
+
+
+Alvestrand                   Informational                     [Page 11]
+
+RFC 3710                    An IESG Charter                February 2004
+
+
+12.  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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Alvestrand                   Informational                     [Page 12]
+