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

From: "Allison Mankin" <[email-masked]>
Date: Sun, 5 Mar 2006 21:48:02 -0500

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/proto-team

---

From: David Meyer <[email-masked]>
Date: Mon, 6 Mar 2006 06:53:15 -0800

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

	Dave

> 
> 
> 
> 
> 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
>    [email-masked] 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: [email-masked]
> 
> 
>    Henrik Levkowetz
>    Torsgatan 71
>    Stockholm  S-113 37
>    SWEDEN
> 
>    Phone: +46 708 32 16 08
>    Email: [email-masked]
> 
> 
>    David Meyer
>    1225 Kincaid St
>    Eugene, OR  97403
>    USA
> 
>    Phone: +1.541.346.1747
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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
>    [email-masked].
> 
> 
> 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]
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 7 Mar 2006 10:00:21 +0100

Hi,

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

read it and agree, it's in good shape overall. I only have some minor  
comments:

(1) If RFC2119 language is applicable to a process document (and I'm  
not sure that it is), some parts of the document could use some  
RFC2119-ization. Example in Section 3.1: change "it is the task of  
the Shepherding WG Chair to do a document write-up" to "the  
Shepherding WG Chair MUST do a document write-up".

(2) The intro briefly notes that chairs can appoint secretaries as  
shepherds, but the process description in Section 3 never picks this  
up. A brief paragraph on what steps this involves may be good. We may  
also want to change terminology from "Shepherding WG Chair" to simply  
"Shepherd" or something similar for that reason.

Nits:

URL in Section 3.1 point 1.g should become a reference

typo in Section 3.1 point 1.h: s/publicatioin/publication/

same paragraph has some duplication: "as described in BCP 97, RFC  
3967 RFC 3967 [RFC3967]"

Section 3.1, last paragraph: not sure if IESG secretary email address  
should be hardcoded here - maybe just say "to the AD and the IESG  
secretary?"

Lars

PS: Aaron has used the PROTO process in DCCP in the past. We've  
dropped the ball a bit on this when Tom and me took over, but we're  
going to start to use PROTO again with draft-ietf-dccp-tfrc-voip-05,  
which has just passed WGLC.
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: David Meyer <[email-masked]>
Date: Tue, 7 Mar 2006 07:20:48 -0800

> Shepherding WG Chair MUST do a document write-up".

	Use of 2119 language in non-protocol specs continues to
	be controversial, since there's no real interoperation
	going on here. We've bashed this around in the context of
	OPS area documents for many years now. OTOH, from 2119, 
	
	  1. MUST   This word, or the terms "REQUIRED" or
	            "SHALL", mean that the definition is an
		    absolute requirement of the specification. 

	seems consistent with what you want to convey.

> "Shepherd" or something similar for that reason.

	Yep.

	Good comments. 

	Dave