From: http://psg.com/~mrw/PROTO-Team/shepherding-draft.txt Title: A Not So Wild Sheep Chase: Definition of Shepherding Reference: IETF Network Working Group, Internet Draft 'draft-ietf-proto-shepherding-00.txt' Date: February 2004 See also: IESG Process and Tools (PROTO) Team http://psg.com/~mrw/PROTO-Team/ ============================================================================== INTERNET-DRAFT A. Mankin draft-ietf-proto-shepherding-00.txt 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- 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 document is a product of the Proto Team . Comments should be addressed to the authors, or the mailing list at proto-team@ietf.org. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Mankin, A. [Page 1] INTERNET-DRAFT Expires: August 2004 February 2004 Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 states. 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 document. 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 TBD 8. Acknowledgments TBD 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 [RFC2434]. Mankin, A. Section 10. [Page 10] INTERNET-DRAFT Expires: August 2004 February 2004 11. References 11.1. Informative References [IDTRACKER] https://datatracker.ietf.org [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [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 Email: mankin@psg.com 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 English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 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. 15. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mankin, A. Section 15. [Page 13]