INTERNET-DRAFT                                     A. Mankin
Category                                       Informational
Expires: August 2004                           February 2004

         A Not So Wild Sheep Chase - Definition of Shepherding

Status of this Document

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a product of the Proto Team .  Comments should be
   addressed to the authors, or the mailing list at

Copyright Notice

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

Mankin, A.                                                      [Page 1]

INTERNET-DRAFT            Expires: August 2004             February 2004


   This draft looks at IETF document shepherding.  Currently this is
   done largely by the Area Directors, though good working group chairs
   will recognize tasks they already perform here.

Mankin, A.                                                      [Page 2]

INTERNET-DRAFT            Expires: August 2004             February 2004

                           Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2. Shepherding As Currently Practiced by ADs. . . . . . . . . . .   4
   3. Job Requirements of Shepherding. . . . . . . . . . . . . . . .   4
   4. Shepherding's Relation to Approval . . . . . . . . . . . . . .   5
   5. Who Shepherds What?. . . . . . . . . . . . . . . . . . . . . .   6
   6. Steps of Shepherding Working Group Documents . . . . . . . . .   7
    6.1. Publication Requested . . . . . . . . . . . . . . . . . . .   7
    6.2. AD Evaluation . . . . . . . . . . . . . . . . . . . . . . .   7
    6.3. Expert Review . . . . . . . . . . . . . . . . . . . . . . .   8
    6.4. IESG Evaluation . . . . . . . . . . . . . . . . . . . . . .   8
    6.5. RFC Editor Queue. . . . . . . . . . . . . . . . . . . . . .   9
   7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .   9
   9. Security Considerations. . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. References. . . . . . . . . . . . . . . . . . . . . . . . . .  11
    11.1. Informative References . . . . . . . . . . . . . . . . . .  11
   12. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  12
   13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  12
   14. Intellectual Property . . . . . . . . . . . . . . . . . . . .  12
   15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  13

Mankin, A.                                                      [Page 3]

INTERNET-DRAFT            Expires: August 2004             February 2004

1.  Introduction

   This draft looks at IETF document shepherding.  Currently this is
   done largely by the Area Directors, though good working group chairs
   will recognize tasks they already perform here.

   The draft attempts to define current AD shepherding in some
   specificity, but in a  manner so that the definition can be turned
   into a guide for WG Chair shepherding, once WG Chairs have good
   support and facilities for shepherding efforts.  To this end, the AD
   work is separated into its components of shepherding, IESG review,
   and approval steps.

   The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC 2119].

2.  Shepherding As Currently Practiced by ADs

   The basic concept of document shepherding is for a a single person
   (an AD currently) to take responsibility for a document from the time
   the WG Chair(s) requests the IESG to publish it to the time that it
   is given final edits by the RFC Editor. The motivation is for the
   shepherd to provide needed coordination. It is easy to lose important
   information or cause delays without the shepherd's coordination.

   Here is one example of shepherding preventing the loss of information
   about a recent standards track document: at the time of RFC Editor
   final edits, the reviews by all the authors resulted in removal of
   wording that had been placed in the document through the IESG review
   process.  The new wording had been discussed with the Working Group,
   but not all the authors had noticed.  The shepherd had to step in.
   There was a human glitch that would have annulled the technical
   review process otherwise.

3.  Job Requirements of Shepherding

    1. Coordinating the resolution of comments from the the broader
       community after the WG. These include:

       - Remaining major WG issues

Mankin, A.                                          Section 3.  [Page 4]

INTERNET-DRAFT            Expires: August 2004             February 2004

       - Remaining WG Chair issues (nit review, quality issues)

       - AD Evaluation comments

       - Expert Review (such as MIB Doctor review)

       - IETF Last Call comments

       - IESG blocking (Discuss) and non-blocking comments
         (including, within them, directorates' comments)

       Note that while the AD is the shepherd there is overlap of
       the shepherd and reviewer role in shepherding the AD Review
       comments, while if the WG Chair is shepherd, this overlap
       moves.  This is simply observed, rather than viewed as a
       negative, because all reviews are public.

    2. Throughout the document's period from the time that the WG
       requests publication until it is published as an RFC,
       recording notes about it in the i-d tracker and updating its

       Note that some of the state updates are performed by the IETF
       Secretariat, though the AD Shepherd has access to perform all
       updates.  Note also that the proto-team is investigating
       tracker changes to facilitate WG Chair shepherding.

    3. Sometime before standards track documents go on the IESG's
       agenda for review, preparing a writeup for them.

    4. Using active monitoring and reminding to minimize document's
       time in wait states (any of the resolutions in 1, processing
       in 5, 6, and 7).

    5. Participating in/reviewing the IANA processing of document.

    6. Participating in/reviewing the RFC Editor final edits of the

    7. Helping editors/chairs on miscellaneous issues such as
       submitting an IPR claim.

4.  Shepherding's Relation to Approval

   The AD mingles his or her role as a document shepherd with roles

Mankin, A.                                          Section 4.  [Page 5]

INTERNET-DRAFT            Expires: August 2004             February 2004

   having to do with document approval.  Separating the two kinds of
   roles out is necessary in order to have shepherding taken over by WG
   Chairs, but not always simple.  In the RFC Editor final edits above,
   there wasn't a procedural rule that would bring in AD approval of the
   change, so that was purely shepherding.

   A clear case of separation is when the WG Chair requests IETF Last
   Call for a document.  The Shepherd begins shepherding the document at
   this point (more on this below) and coordinates a gathering of
   information regarding the document (has the nit review been done, how
   much early review, AD reviews, and so on).  The AD decides whether
   the IETF Last Call may proceed or not - that is based on
   recommendation from the Shepherd (on a basis the AD and the Shepherd
   decide on).  If the AD is the Shepherd, the AD reviews his or her own
   information, of course.  The decision is approval, the gathered
   information is shepherding.

5.  Who Shepherds What?

   The concept of shepherding a document currently applies to Area
   Directors.  Documents have Shepherding Area Directors as follows:

     Working Group Documents - the "Area Advisor" for that Working
     Group will become the shepherd for the document.

     Individual submissions to an Area Director - that Area Director.

     Individual submissions for special cases (e.g. a document about
     liaison relations by an Area Director and an officer of another SDO) -
     the IETF Chair will appoint an Area Director to shepherd the document,
     or might shepherd it himself or herself as the General Area Director.

     Individual submissions from the RFC Editor - the IESG receives these
     and volunteers for shepherding them based on their topics.

     Submissions from the IAB - the IESG's liaison to the IAB shepherds
     these through their process.

Mankin, A.                                          Section 5.  [Page 6]

INTERNET-DRAFT            Expires: August 2004             February 2004

6.  Steps of Shepherding Working Group Documents

   This section gives some more detail to AD shepherding of WG
   documents.  Document shepherding is not precisely the same for non-WG
   documents, but these give a very good feel for the job.  This section
   refers to top-level states used in the i-d tracker.

   Typically, the Area Director is involved with working group documents
   because of having chartered the work for them and followed their
   progress.  Ideally there has been time to be involved in early review
   of the document, before the working group does its last call.  But
   what we define as shepherding the document does not begin until the
   document reaches the point of the request for publication by the
   Working Group Chair(s).  Each state is considered below.

6.1.  Publication Requested

   In the "Publication Requested" state, the WG Chair sends in the
   document to the IESG Secretary and the AD for the WG with a formal
   Publication Request.  This begins shepherding, but the decision about
   when the document goes to IETF Last Call (if it is standards track)
   is an approval-related step.  Similarly the decision about when the
   document is ready to go on the IESG agenda (if it is not standards
   track) is approval-related.

6.2.  AD Evaluation

   In this state, the AD is expected to send the document to the IESG
   with his or her own issues already resolved.  Handling of the AD
   issues, along with the other kinds of issues listed under the job
   description above, is a shepherding step.  Coordination and
   resolution of all the issues from comments here is distinct from the
   AD's job of approving the document to proceed to Last Call or IESG
   Evaluation from here.

Mankin, A.                                        Section 6.2.  [Page 7]

INTERNET-DRAFT            Expires: August 2004             February 2004

6.3.  Expert Review

   The "Expert Review" state can be used for a fairly wide category of
   reviews, though there are several tight usages such as the O&M policy
   of requiring MIB Doctor Review of all MIBs before IETF Last Call
   before IETF Last Call.  Coordination and resolution of all the MIB
   Doctor reviews is shepherding, and it is distinct from the AD's job
   of approving (in this case, in agreement with the O&M AD) that the
   document can proceed to Last Call.

6.4.  IESG Evaluation

   The "IESG Evaluation" state is when the IESG comment that are
   recorded in the I-D Tracker [IDTRACKER]. The shepherd makes sure that
   all the comments have been recorded and are understandable enough.
   The shepherd has a responsibility to ensure that the document Editor
   has received all the Discusses and then has responsibility to make
   sure they all get resolved.   This is, of course, done in a variety
   of ways, depending on the nature of the comments and who they come
   from.  The shepherd may need to coordinate among the several
   resolutions because of possible conflicts among them.  The shepherd
   also takes responsibility for ensuring that the WG is aware of
   Discuss changes.  When the changes are made, the shepherd has
   responsibility to make sure that the revision has just those changes
   and no others, or if the changes are RFC Editor notes, that they are
   correct (and later that they go into the final edit).

   The approval-related role here is for the AD to state to the
   Secretariat after all objections to the document have been removed
   that the Secretariat should announce the document as approved.  By
   doing so, the responsible AD simply says that he or she has vouched
   for his or her delegation to the shepherd in carrying out this
   completion of approval.

   NOTE:   The resolution of comments in any* stage after
           Publication Requested may require an i-d revision.  The
           shepherd always has responsibility to make sure that only
           the few changes in the comments are made in the revision,
           or that revisions are held off.

Mankin, A.                                        Section 6.4.  [Page 8]

INTERNET-DRAFT            Expires: August 2004             February 2004

6.5.  RFC Editor Queue

   As mentioned above, the shepherd job description includes
   participating in and reviewing IANA and RFC-Editor processing of the
   document.  IANA involvement for the shepherd occurs at any time from
   IETF Last Call onward.

7.  Contributors


8.  Acknowledgments


Mankin, A.                                          Section 8.  [Page 9]

INTERNET-DRAFT            Expires: August 2004             February 2004

9.  Security Considerations

   This document specifies neither a protocol nor an operational
   practice, and as such, it creates no new security considerations.

10.  IANA Considerations

   This document creates a no new requirements on IANA namespaces

Mankin, A.                                        Section 10.  [Page 10]

INTERNET-DRAFT            Expires: August 2004             February 2004

11.  References

11.1.  Informative References


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

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

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

   [RFC2434]       Narten, T., and H. Alvestrand, "Guidelines for
                   Writing an IANA Considerations Section in RFCs",
                   RFC 2434/BCP 26, October 1998.

Mankin, A.                                      Section 11.1.  [Page 11]

INTERNET-DRAFT            Expires: August 2004             February 2004

12.  Author's Address

   A. Mankin

13.  Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

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

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

   This document and the information contained herein is provided on an

14.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information

Mankin, A.                                        Section 14.  [Page 12]

INTERNET-DRAFT            Expires: August 2004             February 2004

   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

   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-

15.  Acknowledgement

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

Mankin, A.                                        Section 15.  [Page 13]