[proto-team] Re: Revision of shepherding draft for the deadline

	I've read it over a few times and I like it. Others?

	Dave

On Sun, Mar 05, 2006 at 09:48:02PM -0500, Allison Mankin wrote:
> Hi, Dave,
> 
> Thanks for lending me the XML.  I made a number of friendly changes to it,
> based
> on discussions PROTO has had, and a few that I've had with Brian (as our
> AD).
> 
> They're easy to see with an rfcdiff of the -05 and -06 texts.
> 
> I've attached -06 txt and -06 xml for you.  I'm sending it to you to review
> and
> submit.  Let me know if you have any problems.  Or if you need anything from
> me - I'll be free at midnight when the Academy Awards are over :)
> 
> The changes are:
> 
>   - Mention shepherding of post-approval (IANA and RFC editor) actions
> 
>   - Questionnaire:
> 
>        Identify who is the shepherd
>        More about normative references; add bit about RFC 3967 (downref)
> process
> 
>   -  Discuss Shepherding
> 
>       Add a bit about handling directorates and pre-telechat emailed AD
> comments
>       Add use of the tracker comment email system
>       Mention recourse to the Discuss criteria and add reference
> 
> 
> Allison

> 
> 
> 
> 
> Proto Team                                                       A. Falk
> Internet-Draft                                                       ISI
> Expires: September 6, 2006                                  H. Levkowetz
>                                                                 Ericsson
>                                                                 D. Meyer
>                                               Cisco/University of Oregon
>                                                            March 5, 2006
> 
> 
>       The PROTO Process: Working Group Chair Document Shepherding
>               draft-ietf-proto-wgchair-doc-shepherding-06
> 
> Status of this Memo
> 
>    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 becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
> 
>    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 6, 2006.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2006).
> 
> Abstract
> 
>    The methodologies described in this document have been designed to
>    improve and facilitate IETF document flow processing.  A set of
>    procedures, known as the PROTO process (because it was created by the
>    PROcess and TOols or PROTO team), are specified in which a working
>    group chair serves as the primary document shepherd for a document
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 1]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    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.
> 
>    4.  Following up on IANA and RFC Editor questions in the post-
>        approval shepherding of the document.
> 
>    5.  In summary, continuing to care for the document in its post-WG
>        lifetime, as he or she has done as a Chair, continuing to watch
>        over quality, transparency, WG concerns, and timeliness.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 2]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
> 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  . . . . . . . . . . . . . . . . . . . . 12
>    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
>    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
>    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
>    8.  Informative References . . . . . . . . . . . . . . . . . . . . 13
>    Appendix A.  Working documents . . . . . . . . . . . . . . . . . . 14
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
>    Intellectual Property and Copyright Statements . . . . . . . . . . 16
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 3]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
> 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", primarily)
>        related to the shepherded draft.
> 
>    4.  Following up on queries and requests by help from IANA and the
>        RFC Editor related to the shepherded draft in moving it to
>        publication.
> 
>    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
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 4]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    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
>    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 is divided into the following 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)
> 
>    o  Supporting the document in the post-approval period (for the IANA
>       actions, the RFC Editor publication steps) is not described in the
>       general sense here.
> 
> 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
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 5]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    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.
> 
>    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?  Which chair is the WG
>         Chair Shepherd for this document?
> 
>    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, internationalization,
>         XML, 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.  (It should be
>         separate email because this questionnaire will be entered into
>         the tracker).
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 6]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    1.g) Have the chairs verified that the document checks out against
>         all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
>         Boilerplate checks are not enough; this check needs to be
>         thorough.
> 
>    1.h) Has the document split its references into normative and
>         informative?  Are there normative references to IDs, where the
>         IDs are not also ready for advancement or are otherwise in an
>         unclear state?  The RFC Editor will not publish an RFC with
>         normative references to IDs (will delay the publication until
>         all such IDs are also ready for RFC publicatioin).  If the
>         normative references are behind, what is the strategy for their
>         completion?  On a related matter, are there normative references
>         that are downward references, as described in BCP 97, RFC 3967
>         RFC 3967 [RFC3967]?  Listing these supports the Area Director in
>         the Last Call downref procedure specified in RFC 3967.
> 
>    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 "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?
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 7]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>              +    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 AD 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 questionnaire
>    indicates which chair will be the WG Chair Shepherd.  This
>    information should be entered into the ID Tracker (where it goes is
>    in flux).  In addition to making life easier for the ADs, this is
>    important for the IETF Chair's Gen-ART [GEN-ART] Directorate and
>    other directorates, so they can know where to address reviews in
>    addition to the Responsible Area Director.
> 
> 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.
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 8]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    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.
>         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 or she 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 kept well informed.
>    If this process fails to clarify or resolve the DISCUSS, the
> 
> 
> 
> Falk, et al.            Expires September 6, 2006               [Page 9]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    Shepherding WG Chair MAY further involve the Responsible Area
>    Director in the resolution process.
> 
>    3.a) Leading up to the fortnightly IESG conference call, the
>         Shepherding WG Chair may see email about the document from
>         directorate reviewers on behalf one or more ADs, and also
>         emailed copies of tracker DISCUSSes and COMMENTs.  The ADs are
>         now able to automatically send the comments to both the IESG and
>         the addresses placed in the "State Change Notice To" field,
>         which automatically includes all WG Chairs.  The WG Chair
>         shepherd SHOULD immediately begin to work on resolving DISCUSS
>         items with the AD, keeping the Responsible Area Director copied
>         so that he or she is able support the the activity during the
>         conference call.  When dealing with directorate reviews, the WG
>         Chair shepherd MUST involve the Area Director to whom the
>         directorate reports and be sure that AD considers the review
>         comments need resolving.
> 
>    3.b) Immediately after the IESG conference call, the Shepherding WG
>         Chair queries the ID tracker [IDTRACKER] to collect remaining
>         DISCUSS comments raised against the ID.  In order to ensure
>         this, in addition to the Responsible Area Director and the
>         Shepherding Working Group Chair having discussion, which should
>         happen (!), the Shepherding Working Group Chair's will receive
>         State Change Notice email due to the "State Change Notice To:"
>         field in the ID tracker.  Following the conference call, 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" or "IESG Evaluation: AD
>         Followup"), the Shepherd will receive mail.  This notification
>         indicates to the the Shepherding WG Chair that DISCUSS comments
>         have been registered.  AD Followup signifies the Responsible
>         Area Director's hope that resolution may be possible through a
>         discussion till the other Area Director understands more, or
>         (more usually) through some Notes to the RFC Editor.
> 
>    3.c)
> 
>         Note that there may be very exceptional cases when DISCUSS
>         comments are registered after the IESG teleconference.  In these
>         cases, the DISCUSSing AD must notify the Shepherding WG Chair
>         that new comments have been entered.  The email notification
>         facility is very convenient for this purpose, and also for the
>         cases where the DISCUSS comments are updated after they are
>         partially resolved.
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 10]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    3.d) 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 correspondence for resolving comments, because the
>         Responsible Area Director has a form of - um - responsibility.
>         This should not place the Responsible AD in the critical path
>         but should keep the Responsible AD ready to help if needed.
> 
>         +------+  Comments     +--------+  Comments      +-------+
>         | (3.a)| ------------> |  (3.b) | -------------> | (3.c) |
>         +------+  Collected    +--------+  Understood    +-------+
>                                 /|\   |
>                                  |    | Comments not fully understood
>                                  |    | (Further AD/Shepherding WG
>                                  |    |  Chair Discussion Required)
>                                  |    |
>                                  +----+
> 
>    3.e) 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.f) The DISCUSS comments are then communicated to the working group.
> 
>    3.g) 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.  It is very
>         important to resolve the comments in a timely way, while the
>         discussion is current for everyone.
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 11]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    3.h) The Shepherding WG Chair communicates the resolution-so-far to
>         the Responsible AD and the DISCUSSing AD(s).
> 
>    3.i) 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].  The Shepherding WG Chair should also review the
>              IESG's Discuss Criteria guidelines [I-D.iesg-discuss-
>              criteria] and discuss with the Responsible Area Director
>              whether there might be considerations against the
>              unresolved Discuss by the rest of the IESG due to these
>              guidelines.
> 
>         Otherwise, the process continues with step (3.h).
> 
>    3.j) The Responsible Area Director moves document to APPROVED state,
>         or if the changes are deemed significant, there may be a new WG
>         last call.  In that case, the document may go to the full IESG
>         for a re-check.
> 
> 
> 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
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 12]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    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.
> 
>    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 the
>    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.
> 
>    [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.
> 
>    [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
>               Documents may Refer Normatively to Documents at a Lower
>               Level", BCP 97, RFC 3967, December 2004.
> 
>    [I-D.iesg-discuss-criteria]
>               Peterson, J., "DISCUSS Criteria in IESG Review",
>               draft-iesg-discuss-criteria-02 (work in progress),
>               February 2006.
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 13]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
>    [IDTRACKER]
>               "The IETF Draft Tracker", Web
>               Application: https://datatracker.ie= tf.org/, 2002.
> 
>    [PROTO]    "The IESG Process and Tools (PROTO) Team", Web
>               Page: http://psg.com/~mrw/PROTO-Tea= m, 2004.
> 
>    [GEN-ART]  "The General Area Review Team (GEN-ART)", Web
>               Page: http://www.alvestrand.no/ietf= /gen/
>               review-guidelines.html, 2005.
> 
> 
> 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
>    we= b site:
> 
>    http://ietf.levkowetz.com/drafts/proto/wgchair-doc-shepherding/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 14]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Falk, et al.            Expires September 6, 2006              [Page 15]
> 
> Internet-Draft  Working Group Chair Document Shepherding      March 2006
> 
> 
> 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 (2006).  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 6, 2006              [Page 16]
> 
>