[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4858

Proto Team                                                       A. Falk
Internet-Draft                                                       ISI
Expires: September 16, 2005                                 H. Levkowetz
                                                                Ericsson
                                                                D. Meyer
                                              Cisco/University of Oregon
                                                          March 15, 2005


      The PROTO Process: Working Group Chair Document Shepherding
              draft-ietf-proto-wgchair-doc-shepherding-05

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 September 16, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The methodologies described in this document have been designed to
   improve and facilitate IETF document flow processing.  A set of
   processes and procedures, known as the PROTO process, are specified



Falk, et al.           Expires September 16, 2005               [Page 1]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   in which a working group chair serves as the primary document
   shepherd for a document which has been submitted to the IESG for
   publication.  Note that this role has traditionally been filled by
   the AD responsible for the working group.

   The shepherd's responsibilities include:

   1.  Providing the write-up accompanying a document that is forwarded
       to the IESG for publication.  Note that this write-up had
       traditionally been provided by the "Shepherding Area Director".
       Under the processes and procedures described here, the working
       group chair provides this write-up.

   2.  Following up on AD Evaluation comments to the authors and working
       group, and

   3.  Following up on all IESG comments ("DISCUSSes") related to the
       shepherded draft.

































Falk, et al.           Expires September 16, 2005               [Page 2]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Process Description  . . . . . . . . . . . . . . . . . . . . .  5
     3.1   WG Chair Write-Up for Publication Request  . . . . . . . .  5
     3.2   AD Review Shepherding  . . . . . . . . . . . . . . . . . .  8
     3.3   IESG Discuss Shepherding . . . . . . . . . . . . . . . . .  9
   4.  When Not to Use PROTO  . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   A.  Working documents  . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14



































Falk, et al.           Expires September 16, 2005               [Page 3]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


1.  Introduction

   Early in 2004, the IESG undertook several experiments aimed at
   evaluating whether any of the proposed changes to the IETF document
   flow process would yield qualitative improvements in document
   throughput and quality.  One such experiment, referred to as PROTO
   [PROTO], is a set of methodologies designed to involve the working
   group chairs more directly in their documents' approval life cycle.
   In particular, the PROTO team focused on that part of the document's
   life cycle which occurs after the working group and document editor
   would have traditionally forwarded the document to the IESG for
   publication.

   The methodologies developed and piloted by the PROTO team (hereafter
   referred to as the "PROTO process" or simply "PROTO") focus on the
   working group chair as the primary document shepherd.  In this
   context, the shepherd's responsibilities include:

   1.  Providing the write-up accompanying a document that has been
       forwarded to the IESG for publication.  This write-up had
       traditionally been provided by the "Shepherding Area Director".
       Under PROTO, the Working Group Chair provides this write-up.

   2.  Following up on AD Evaluation comments to the authors and working
       group, and

   3.  Following up on all IESG comments ("DISCUSSes") related to the
       shepherded draft.

   By the end of 2004, the IESG had evaluated the utility of the PROTO
   methodologies based on data obtained though several pilot projects
   which had run throughout the year, and subsequently decided to adopt
   the PROTO process.

   The primary objective of the PROTO process is to improve document
   throughput and quality by enabling a partnership between the
   Responsible Area Director and the Shepherding Working Group Chair
   (note that the Working Group Chair, in consultation with the
   Responsible Area Director, may designate the Working Group Secretary,
   if one exists, to be the shepherd for a particular document).  In
   particular, this partnership has the explicit goal of empowering the
   Shepherding WG Chair while at the same time offloading a specific
   part of the follow-up work which had traditionally been
   responsibility of the Responsible Area Director.  As such, PROTO has
   been scoped to include both the follow-up after the Responsible Area
   Director has read through and evaluated a document submitted to the
   IESG for publication, as well as follow-up on all IESG comments on a
   document (i.e., DISCUSSes).  Finally, it is important to note that



Falk, et al.           Expires September 16, 2005               [Page 4]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   PROTO does not cover follow-up for drafts which do not originate in a
   working group.

   The remainder of this document is organised as follows: Section 3
   outlines the overall PROTO process.  Section 3.1 describes the
   write-up which accompanies the publication request, Section 3.2
   describes the AD Review shepherding process, and Section 3.3
   describes IESG Discuss Shepherding.  Finally, Section 4 describes
   those cases in which the PROTO process should not be used.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Process Description

   The PROTO process involves Area Directors of selected areas, and some
   or all of the chairs for which the Area Director is Area Advisor.

   The PROTO process is divided into three tasks:

   o  Doing a WG Chair Write-Up for a document (Section 3.1),

   o  Following up on AD review comments (Section 3.2), and

   o  Following up on IESG DISCUSS comments (Section 3.3)


3.1  WG Chair Write-Up for Publication Request

   When a draft is ready to be submitted for publication, it is the task
   of the Shepherding WG Chair to do a document write-up for the draft.

   There are two parts to this task.  First, the Shepherding WG Chair
   answers questions 1.a to 1.h below to give the Responsible Area
   Director insight into the working group process as applied to this
   draft.  Note that while these questions may appear redundant in some
   cases, they are written to elicit information that the AD must be
   aware of (to this end, pointers to relevant entries in the WG archive
   will be helpful).  The goal here is to inform the AD about any issues
   that may have come up in IETF meetings, on the mailing list, or in
   private communication that they should be aware of prior to IESG
   evaluation of the shepherded draft.  Any significant issues mentioned
   in the questionnaire will probably lead to a follow-up discussion
   with the AD.



Falk, et al.           Expires September 16, 2005               [Page 5]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   The second part of the task is to prepare the "Protocol Write-Up"
   which is used both for the ballot write-up for the IESG telechat and
   for the the IETF-wide protocol announcement.  Item number 1.i
   describes the elements of the write-up.  Please see other protocol
   announcements in the IETF Announce archive for examples of such
   write-ups.

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

   1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

   1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)






Falk, et al.           Expires September 16, 2005               [Page 6]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

   1.k) Note:

        *    The relevant information for the technical summary can
             frequently be found in the abstract and/or introduction of
             the document.  If not, this may be an indication that there
             are deficiencies in the abstract or introduction.

        *    For the Working Group Summary: Was there anything in WG
             process that is worth noting? For example, was there
             controversy about particular points, decisions where
             consensus was particularly rough, etc.

        *    For the protocol quality, useful information includes:

             +    Are there existing implementations of the protocol?

             +    Have a significant number of vendors indicated they
                  plan to implement the specification?

             +    Are there any reviewers that merit special mention as
                  having done a thorough review (i.e., that resulted in
                  important changes or a conclusion that the document
                  had no substantive issues)?

   The questionnaire and write-up is sent to the ADs and
   iesg-secretary@ietf.org with a request to publish the document.  The
   questionnaire and write-up, minus any discussion of possible appeals,
   is also sent to the working group mailing list.  The publication
   request SHOULD also indicate which chair will be shepherding the
   document (this will be entered into the ID Tracker [IDTRACKER]).  In
   addition to making life easier for the ADs, this lets the IETF chair
   know where to send Gen-ART [GEN-ART] reviews.






Falk, et al.           Expires September 16, 2005               [Page 7]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


3.2  AD Review Shepherding

   The steps for working group chair shepherding of AD reviews are as
   follows:

   2.a) If there is more than one chair, the chairs decide on which one
        should be responsible for ensuring that the needed fixes are
        done when the AD returns comments.  This MUST be done before the
        publication request is sent, so that the information can be
        included in the request, as mentioned above.  This MUST be an
        explicit agreement among the working group chairs.

   2.b) The AD reads, evaluates and comments on the draft (as is the
        case when not using PROTO).

   2.c) Depending on the magnitude of the issues found, the AD returns
        the full review to the chairs, and requests that either:

        *    Further editorial work must be done on the document before
             it can be published, or,

        *    ID Nits must be fixed before the document before it can be
             published, or

        *    A revised draft is is required to resolve issues that have
             been found in subsequent IESG review.

        As covered below, the comments will be posted to the working
        group mailing list.  The comments will normally also be posted
        by the AD in the ID Tracker [IDTRACKER].  Working groups that
        use issue tracking should also record the issues (and eventually
        their resolution) in the issue tracker.

   2.d) The Shepherding WG Chair reads through the AD Evaluation
        comments, making very certain that all comments are understood,
        so that it is possible to follow up on them with the authors and
        working group.  If there is some uncertainty as to what is
        requested, this must be resolved with the Area Director.

   2.e) The Shepherding WG Chair sends the comments to the author(s) and
        to the working group mailing list, in order to have a permanent
        record of the comments.  It is recommended that the chair
        solicit from the author(s) an estimate on when the fixes will be
        done, that is, when the revised draft can be expected.

   2.f) When incorporating the fixes in the new version of the draft, it
        is strongly RECOMMENDED that the editor keep a list showing how
        each issue was addressed and showing what the revised text is.



Falk, et al.           Expires September 16, 2005               [Page 8]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


        It is strongly RECOMMENDED that this list be forwarded to the
        Responsible Area Director with the revised draft.

   2.g) The Shepherding WG Chair iterates with the authors (and working
        group if required) until the outstanding issues have been
        resolved and a revised draft has been submitted.  At this point,
        the AD is notified and provided with the summary list of issues
        and resulting text changes.

        In the event that the working group disagrees with a comment
        raised by the AD or has previously considered and dismissed the
        issue, the Shepherding WG Chair MUST resolve the issue with the
        AD before a revised draft can be submitted.

   2.h) The Area Director verifies that the issues he found during AD
        Evaluation are resolved by the new version of the draft.

   2.i) The shepherding process normally terminates at this point.
        However, in the event that no resolution can be found, the
        process goes to 1.  above (i.e., essentially restarts).


3.3  IESG Discuss Shepherding

   In this section we detail the steps that a Shepherding WG Chair will
   take in resolving the DISCUSS items against a given ID.  The steps
   are given below, in the order that they are to be executed.  Note
   that occasionally DISCUSSes are written in a manner that makes their
   primary intent unclear.  In these cases, the Shepherding WG Chair
   (and possibly the document editor)  and DISCUSSing AD SHOULD meet
   (either in person or electronically) to resolve the issue.  In
   addition, the Responsible Area Director SHOULD be notified of the
   meeting.  If this process fails to clarify or resolve the DISCUSS,
   the Shepherding WG Chair MAY further involve the Responsible Area
   Director in the resolution process.

   3.a) Immediately after the weekly IESG conference call, the
        Shepherding WG Chair queries the ID tracker [IDTRACKER] to
        collect any DISCUSS comments raised against the ID.  In order to
        accomplish this, the Shepherding WG Chair's email address is
        added to the "State Change Notice To:" field in the ID tracker.
        This will result in an email to the Shepherding WG Chair when
        the document changes state from the "IESG Evaluation" state to
        one of the states requiring Shepherd actions (i.e., "IESG
        Evaluation: Revised ID Needed", "IESG Evaluation: AD Followup").
        This notification indicates to the the Shepherding WG Chair that
        the DISCUSS comments have been registered.




Falk, et al.           Expires September 16, 2005               [Page 9]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


        Note that there may be exceptional cases when DISCUSS comments
        are registered after the IESG teleconference.  In these cases,
        the DISCUSSing AD should notify the Shepherding WG Chair that
        new comments have been entered.

   3.b) The Shepherding WG Chair analyses comments from the tracker, and
        initialises contact with any AD's who have placed comments
        (blocking or non-blocking) on the draft that is being
        shepherded.  In particular, the Shepherding WG Chair MUST notify
        the relevant ADs that the Shepherding WG Chair is the current
        document shepherd.  Note that the Responsible Area Director MUST
        be copied on this correspondence.

        +------+  Comments     +--------+  Comments      +-------+
        | (3.a)| ------------> |  (3.b) | -------------> | (3.c) |
        +------+  Collected    +--------+  Understood    +-------+
                                /|\   |
                                 |    | Comments not fully understood
                                 |    | (Further AD/Shepherding WG
                                 |    |  Chair Discussion Required)
                                 |    |
                                 +----+

   3.c) The Shepherding WG Chair then coordinates DISCUSS comments, and
        builds a a consistent interpretation of the comments.  This step
        may require iteration with step (2).  above.  That is:

        +------+   Consistent     +-------+
        | (3.b)| ---------------> | (3.c) |
        +------+ Interpretation   +-------+
          /|\                         |
           |                          | Further AD/Shepherding WG
           |                          | Chair discussion required
           +--------------------------+

   3.d) The DISCUSS comments are then communicated to the working group.

   3.e) After the author(s) resolve the issues provided by the
        Shepherding WG Chair (i.e., the summarised DISCUSS issues), the
        Shepherding WG Chair reviews the updated document to ensure that
        (in her/his option) the DISCUSS issues have been resolved.

        Note that the Shepherding WG Chair may also propose resolutions
        to these issues, file them in an issue tracker, or do other
        steps to streamline the resolution of the comments.






Falk, et al.           Expires September 16, 2005              [Page 10]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   3.f) The Shepherding WG Chair communicates the resolution-so-far to
        the responsible AD and the DISCUSSing AD(s).

   3.g) DISCUSSing AD removes DISCUSS comment, or tells the Shepherding
        WG Chair and adds information to the ID tracker explaining why
        the comment is not resolved.  The Shepherding WG Chair informs
        the working group accordingly.

        If the DISCUSS comment in question was not resolved to the
        satisfaction of the DISCUSSing AD(s) and Responsible Area
        Director, two possibilities exist:

        (a)  The process returns to step (3.c), or

        (b)  If no progress can be made on the resolution of the DISCUSS
             with the DISCUSSING AD, despite clarification and
             additional involvement of the Responsible Area Director,
             the Shepherding WG Chair and the WG might at last resort
             consider an appeal in accordance with the procedures
             described in RFC 2026 [RFC2026] and referred to in RFC 2418
             [RFC2418].

        Otherwise, the process continues with step (3.h).

   3.h) The Responsible Area Director moves document to APPROVED state,
        or if the changes are deemed significant, there may be a new WG
        last call.  Finally, the document goes to the full IESG for
        re-review.


4.  When Not to Use PROTO

   As mentioned above, there are several cases in which the PROTO
   process SHOULD NOT be used.  These include

   1.  Those cases in which the WG chair primary document author or
       editor, or the WG chair is the primary author or editor of a
       large percentage of the documents produced by the working group,

   2.  Those cases in which the Responsible Area Director expects
       communication difficulties with the WG chair (either due to
       experience, strong views stated by the chair, or other issues),
       and

   3.  Those cases in which the working group itself is either very old,
       losing energy, or winding down.  i.e., those cases in which it
       would not be productive to initiate new processes or procedures.




Falk, et al.           Expires September 16, 2005              [Page 11]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


   Finally, note these guidelines are intended to help the Responsible
   Area Director determine when to use the PROTO process.  The final
   determination as to whether to use the PROTO process or not is left
   to the Responsible Area Director's discretion.

5.  Security Considerations

   This document specifies a change to IETF document flow procedures.
   As such, it neither raises nor considers protocol-specific security
   issues.

6.  Acknowledgments

   This document is the product of PROTO team, which includes authors as
   well as Allison Mankin, Bill Fenner, Barbara Fuller, and Margaret
   Wasserman.

7.  IANA Considerations

   This document creates no new requirements on IANA namespaces or other
   IANA requirements.

8.  Informative References

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

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [IDTRACKER]
              "The IETF Draft Tracker", Web
              Application: https://datatracker.ietf.org/, 2004.

   [PROTO]    "The IESG Process and Tools (PROTO) Team", Web
              Page: http://psg.com/~mrw/PROTO-Team, 2004.

   [GEN-ART]  "The General Area Review Team (GEN-ART)", Web
              Page: http://www.alvestrand.no/ietf/gen/review-guidelines.
              html, 2005.




Falk, et al.           Expires September 16, 2005              [Page 12]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


Authors' Addresses

   Aaron Falk

   Email: falk@isi.edu


   Henrik Levkowetz
   Torsgatan 71
   Stockholm  S-113 37
   SWEDEN

   Phone: +46 708 32 16 08
   Email: henrik@levkowetz.com


   David Meyer
   1225 Kincaid St
   Eugene, OR  97403
   USA

   Phone: +1.541.346.1747
   Email: dmm@1-4-5.net

Appendix A.  Working documents

   (This section should be removed by the RFC editor before publication)

   The current working documents for this draft are available at this
   web site:

   http://ietf.levkowetz.com/drafts/proto/wgchair-doc-shepherding/



















Falk, et al.           Expires September 16, 2005              [Page 13]

Internet-Draft    Working Group Chair Document Shepherding    March 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Falk, et al.           Expires September 16, 2005              [Page 14]


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