[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          G. Huston
Internet-Draft                                                   Telstra
Expires: April 25, 2003                                          M. Rose
                                            Dover Beach Consulting, Inc.
                                                        October 25, 2002


                A Proposal to Improve IETF Productivity
                        draft-huston-ietf-pact-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 25, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The IETF standards process must exhibit four qualities
   (Predictability, Accountability, Competency, and Timeliness), which
   we term "the IETF Pact".  Growth in the IETF's size and diversity
   challenges its ability to make progress in producing useful
   specifications.  This proposal puts forward procedural changes that
   will improve the IETF PACT, without altering the IETF's philosophy or
   structure, and without requiring changes to the formal IETF standards
   process (cf., RFC 2026 [1]).





Huston & Rose            Expires April 25, 2003                 [Page 1]


Internet-Draft               The IETF Pact                  October 2002


Table of Contents

   1.    The Problem  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The IETF "PACT"  . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Working Group Operation  . . . . . . . . . . . . . . . . . .  5
   3.1   The "Utility Focus" model for WGs  . . . . . . . . . . . . .  5
   3.2   The "Short-term" model for WGs . . . . . . . . . . . . . . .  5
   4.    IETF Operation . . . . . . . . . . . . . . . . . . . . . . .  6
   4.1   The "Area Focus" model for the IESG  . . . . . . . . . . . .  6
   4.1.1 Bounded Discussion . . . . . . . . . . . . . . . . . . . . .  6
   4.1.2 Proportional Voting  . . . . . . . . . . . . . . . . . . . .  7
   4.1.3 Vote Explanations  . . . . . . . . . . . . . . . . . . . . .  7
   4.1.4 Status Reporting . . . . . . . . . . . . . . . . . . . . . .  8
   4.2   The "Bounded Outcome" model for the IETF . . . . . . . . . .  8
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  9
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
   A.    Summary of Proposed Rules  . . . . . . . . . . . . . . . . . 12
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13































Huston & Rose            Expires April 25, 2003                 [Page 2]


Internet-Draft               The IETF Pact                  October 2002


1. The Problem

   Growth in the IETF's size and diversity challenge its ability to make
   progress in producing useful specifications.  For example, Working
   Group (WG) efforts often take far too long, and the result of those
   efforts is sometimes not very useful to the Internet community.
   These difficulties are sometimes exacerbated by IESG procedures that
   introduce further delay and ambiguity to the process.

   This memo proposes seven procedural changes that will improve the
   Predictability, Accountability, Competency and Timeliness of the IETF
   ("the IETF Pact"), without altering the IETF's philosophy or
   structure, and without requiring changes to the formal IETF standards
   process (cf., RFC 2026 [1]).





































Huston & Rose            Expires April 25, 2003                 [Page 3]


Internet-Draft               The IETF Pact                  October 2002


2. The IETF "PACT"

   The IETF standards process must exhibit four qualities:

   Predictability: IETF efforts must not waste time and energy.

      For example, if the responsible AD has any issue with a Working
      Group (WG) document, these should be known to the WG long before
      the document is submitted to the IESG.  IESG procedures for
      documents must be clear and consistent, and the status and
      progress of documents through the procedures must be visible to
      all.  At any point, it must be clear what the next step is for a
      document and when that step will be taken.

   Accountability: Those holding IETF management positions necessarily
      wield considerable power and the IETF community needs to be able
      to know who has wielded it and when.

   Competency: The process must encourage the production of technically
      competent output; otherwise, we are left with a fair, expeditious,
      but useless process.

   Timeliness: Timeliness relates to relevance and quality and, as such,
      the IETF's work is sensitive to real-world needs.

      If the IETF process takes too long, the results will be irrelevant
      and other, less engineered solutions will emerge.  Ultimately
      then, the Internet community will be less dependent on the IETF's
      work.  Finally, longer WG processes often lead to work with less
      focus and clarity, and the resulting technical specifications are
      often confusing and laden with questionable features.  This makes
      them more difficult to implement correctly and, again, less likely
      to have real-world utility.

   We now present a set of proposed changes to the way the IETF manages
   its working groups.  Each change is presented in two parts:

   o  a philosophy or rational for a change in the IETF's behavior; and,

   o  a corresponding rule to be employed by the IESG.

   Finally, Appendix A summarizes the proposed rules.

   In considering these proposals, please keep in mind that the changes
   being presented do not change the way in which areas are managed
   according to RFC 2026 [1]; rather these are changes to the IESG
   management model, which the standards process purposefully leaves to
   the discretion of the IESG.



Huston & Rose            Expires April 25, 2003                 [Page 4]


Internet-Draft               The IETF Pact                  October 2002


3. Working Group Operation

   An IETF working group is for engineering, rather than research or
   general discussion.  Hence a WG must understand what problem it is
   solving, who will use the solution and how it will be used, and the
   WG must make near-term progress towards that solution.

3.1 The "Utility Focus" model for WGs

   An IETF working group charter is characterized as a contract between
   the WG and the IETF.  As the IETF has grown larger and more diverse,
   and as the problems tackled by WGs have grown more ambitious,
   charters have sometimes become too vague to provide adequate guidance
   about the goals and scope of the WG.

   Accordingly, a WG charter must explicitly state:

   o  what problems are to be solved or what specific benefits are
      intended from the work to be done;

   o  who the intended beneficiaries are (also describing some examples
      of the use and effect that will accrue from using the capabilities
      provided by the WG's output); and,

   o  where areas of difficulty are likely to be encountered.


3.2 The "Short-term" model for WGs

   If an effort requires more than 1.5 years to produce something that
   is ready for IETF last call, then it is not yet ready for the IETF.
   The effort must do its pre-standards work elsewhere and then come to
   the IETF when a solution is ready to be standardized.

   Accordingly, a WG gets no more than 18 months to have their first
   Internet-Draft (I-D) approved by the IESG; similarly, a WG gets no
   more than 12 months to have each succeeding document approved by the
   IESG.













Huston & Rose            Expires April 25, 2003                 [Page 5]


Internet-Draft               The IETF Pact                  October 2002


4. IETF Operation

   The IESG must juggle two extremely difficult tasks:

   o  technical oversight; and,

   o  process management.

   It is essential to retain and support both of these tasks, while also
   balancing the need to make timely progress.

   After a document is given to the IESG for approval it can be
   difficult to ascertain the document's status and how it got there.
   The procedures that the IESG uses for voting are not well known, and
   the reasoning behind the IESG's votes are not published.  Further,
   some of the procedures may result in a document being delayed, even
   if there is a strong consensus in the IESG for it to go forward.  As
   a result, WG chairs and document editors often find themselves in
   "limbo", where they don't know what to do to move documents through
   the IETF system.

   Two complimentary changes can remedy the problem:

   o  a greater emphasis on area focus; and,

   o  a narrower emphasis on what gets evaluated during IETF last call.


4.1 The "Area Focus" model for the IESG

   Each area comprises considerable specialization.  Although it is
   essential to have coordination and collaboration among the areas, it
   is equally important that the WGs in an area be allowed to focus on
   their own activities and have their consensus results published.

   Our philosophy is that whenever the IESG makes any decisions, all ADs
   get a voice, but no one AD gets a veto.  In realizing this, several
   factors must be balanced.

4.1.1 Bounded Discussion

   It is essential that no AD be able to exercise a "pocket veto".
   Hence there needs to be a way, within the IESG, to override blockages
   by individual ADs.

   Accordingly, once a document is submitted to the IESG for approval, a
   formal request for further discussion may delay IESG voting on the
   document until no later than the next IESG meeting.  (In other words,



Huston & Rose            Expires April 25, 2003                 [Page 6]


Internet-Draft               The IETF Pact                  October 2002


   there may be at most one request for discussion for the document and
   any AD may request it.)

4.1.2 Proportional Voting

   Responsible ADs are presumed to be expert in the work under review,
   both in terms of the technology and their WGs' history.  In order to
   facilitate the efficiency of their work, they must have a
   disproportionate say in progressing a document.

   Accordingly, all IESG votes require a minimum of 55% of those voting
   "yes" to pass; further, the votes of the responsible ADs are weighted
   to 45% of all votes, with the remaining ADs combining to 55% of all
   votes.

   The voting proportions give extra weight to the votes of the
   Responsible ADs, but permit the remainder of the IESG to override
   them.

   For example, let's assume that there are 13 ADs voting and that 2 ADs
   are responsible for an area:

        if the two responsible ADs            then passage requires
       =============================    ================================
       both vote yes                    at least 2 other ADs to vote yes
       both vote no                     all other ADs to vote yes
       split (one yes, the other no)    at least 7 other ADs to vote yes


   For example, if both routing ADs vote "yes", then it takes most of
   the other ADs voting "no" to defeat an action in the routing area.

   Naturally, the usual checks-and-balances apply, e.g., if an IESG
   member disapproves of an IESG action, they (like any other IETF
   member) are free to appeal to the IAB.

4.1.3 Vote Explanations

   In order to give WGs a constructive path towards resolving AD
   concerns, a WG must know precisely what those concerns are.
   Requiring publication of IESG rationale for rejecting a document
   helps ensure IESG accountability when a rejection occurs.

   Accordingly, if an IESG vote rejects a WG document, then the IESG
   must publish an explanation prior to the next IESG meeting.  If no
   report is published in that timeframe, then the document is
   automatically approved.




Huston & Rose            Expires April 25, 2003                 [Page 7]


Internet-Draft               The IETF Pact                  October 2002


4.1.4 Status Reporting

   WG documents do not materialize out of the ether -- WGs are granted
   charters by the IESG, and work under the guidance of an AD when
   producing their documents.  As such, the IESG's decision process
   should presume a timely, favorable outcome for WG output.

   Accordingly, the IESG must publish regular reports identifying those
   actions they have not yet addressed and explaining why.  At a
   minimum, the IESG must publish these reports no later than one month
   prior to each face-to-face IETF meeting.

4.2 The "Bounded Outcome" model for the IETF

   A document is developed as a sequence of design decisions, as a WG
   makes progress.  Hence the resulting document typically is produced
   from a substantial number of group consensus assessments.  This
   should create a very strong presumption of community approval for the
   document.

   Any document can be criticized for its choices.  An IETF effort is
   designed to resolve engineering choices for one issue and then move
   to a new issue.  It is not reasonable to permit arbitrary criticisms
   to be raised late in the process, derailing the incremental effort of
   a WG.

   It is always reasonable to raise fundamental engineering problems,
   but it is essential to distinguish these from matters of engineering
   aesthetics.  In particular, the IETF Last Call and IESG review
   periods are not intended for second-guessing a WG's design choices --
   the purpose of an IETF Last Call and IESG review is to focus on the
   overall viability of the document.

   Accordingly, When evaluating a document, the IESG should heed
   comments that identify fundamental engineering problems and should
   ignore comments that suggest better ways of solving the same problem.















Huston & Rose            Expires April 25, 2003                 [Page 8]


Internet-Draft               The IETF Pact                  October 2002


5. IANA Considerations

   This memo does not create any new issues for the IANA.
















































Huston & Rose            Expires April 25, 2003                 [Page 9]


Internet-Draft               The IETF Pact                  October 2002


6. Security Considerations

   To the extent that the proposed changes produce documents that are
   more timely and simpler, those documents, in theory, should contain
   fewer security holes.














































Huston & Rose            Expires April 25, 2003                [Page 10]


Internet-Draft               The IETF Pact                  October 2002


References

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


Authors' Addresses

   G. Huston
   Telstra
   5/490 Northbourne Avenue
   Dickson, ACT  2602
   AU

   EMail: gih@telstra.net


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268
   US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us


























Huston & Rose            Expires April 25, 2003                [Page 11]


Internet-Draft               The IETF Pact                  October 2002


Appendix A. Summary of Proposed Rules

   Rule 1: A WG charter must explicitly state:

      *  what problems are to be solved or what specific benefits are
         intended from the work to be done;

      *  who the intended beneficiaries are (also describing some
         examples of the use and effect that will accrue from using the
         capabilities provided by the WG's output); and,

      *  where areas of difficulty are likely to be encountered.

   Rule 2: A WG gets no more than 18 months to have their first I-D
      approved by the IESG; similarly, a WG gets no more than 12 months
      to have each succeeding document approved by the IESG.

   Rule 3: Once a document is submitted to the IESG for approval, a
      formal request for further discussion may delay IESG voting on the
      document until no later than the next IESG meeting.

   Rule 4: All IESG votes require a minimum of 55% of those voting "yes"
      to pass; further, the votes of the responsible ADs are weighted to
      45% of all votes, with the remaining ADs combining to 55% of all
      votes.

   Rule 5: If an IESG vote rejects a WG document, then the IESG must
      publish an explanation prior to the next IESG meeting.  If no
      report is published in that timeframe, then the document is
      automatically approved.

   Rule 6: The IESG must publish regular reports identifying those
      actions they have not yet addressed and explaining why.  At a
      minimum, the IESG must publish these reports no later than one
      month prior to each face-to-face IETF meeting.

   Rule 7: When evaluating a document, the IESG should heed comments
      that identify fundamental engineering problems and should ignore
      comments that suggest better ways of solving the same problem.












Huston & Rose            Expires April 25, 2003                [Page 12]


Internet-Draft               The IETF Pact                  October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Huston & Rose            Expires April 25, 2003                [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/