idnits 2.17.1 draft-ietf-proto-shepherding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 322), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 84, but not defined == Unused Reference: 'RFC2119' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 305, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Mankin 3 draft-ietf-proto-shepherding-00.txt 4 Category Informational 5 Expires: August 2004 February 2004 7 A Not So Wild Sheep Chase - Definition of Shepherding 8 10 Status of this Document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the Proto Team . Comments should be 32 addressed to the authors, or the mailing list at proto-team@ietf.org. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This draft looks at IETF document shepherding. Currently this is 41 done largely by the Area Directors, though good working group chairs 42 will recognize tasks they already perform here. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Shepherding As Currently Practiced by ADs. . . . . . . . . . . 4 48 3. Job Requirements of Shepherding. . . . . . . . . . . . . . . . 4 49 4. Shepherding's Relation to Approval . . . . . . . . . . . . . . 5 50 5. Who Shepherds What?. . . . . . . . . . . . . . . . . . . . . . 6 51 6. Steps of Shepherding Working Group Documents . . . . . . . . . 7 52 6.1. Publication Requested . . . . . . . . . . . . . . . . . . . 7 53 6.2. AD Evaluation . . . . . . . . . . . . . . . . . . . . . . . 7 54 6.3. Expert Review . . . . . . . . . . . . . . . . . . . . . . . 8 55 6.4. IESG Evaluation . . . . . . . . . . . . . . . . . . . . . . 8 56 6.5. RFC Editor Queue. . . . . . . . . . . . . . . . . . . . . . 9 57 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 9 59 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 11.1. Informative References . . . . . . . . . . . . . . . . . . 11 63 12. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 12 64 13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 12 65 14. Intellectual Property . . . . . . . . . . . . . . . . . . . . 12 66 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 68 1. Introduction 70 This draft looks at IETF document shepherding. Currently this is 71 done largely by the Area Directors, though good working group chairs 72 will recognize tasks they already perform here. 74 The draft attempts to define current AD shepherding in some 75 specificity, but in a manner so that the definition can be turned 76 into a guide for WG Chair shepherding, once WG Chairs have good 77 support and facilities for shepherding efforts. To this end, the AD 78 work is separated into its components of shepherding, IESG review, 79 and approval steps. 81 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC 2119]. 85 2. Shepherding As Currently Practiced by ADs 87 The basic concept of document shepherding is for a a single person 88 (an AD currently) to take responsibility for a document from the time 89 the WG Chair(s) requests the IESG to publish it to the time that it 90 is given final edits by the RFC Editor. The motivation is for the 91 shepherd to provide needed coordination. It is easy to lose important 92 information or cause delays without the shepherd's coordination. 94 Here is one example of shepherding preventing the loss of information 95 about a recent standards track document: at the time of RFC Editor 96 final edits, the reviews by all the authors resulted in removal of 97 wording that had been placed in the document through the IESG review 98 process. The new wording had been discussed with the Working Group, 99 but not all the authors had noticed. The shepherd had to step in. 100 There was a human glitch that would have annulled the technical 101 review process otherwise. 103 3. Job Requirements of Shepherding 105 1. Coordinating the resolution of comments from the the broader 106 community after the WG. These include: 108 - Remaining major WG issues 109 - Remaining WG Chair issues (nit review, quality issues) 111 - AD Evaluation comments 113 - Expert Review (such as MIB Doctor review) 115 - IETF Last Call comments 117 - IESG blocking (Discuss) and non-blocking comments 118 (including, within them, directorates' comments) 120 Note that while the AD is the shepherd there is overlap of 121 the shepherd and reviewer role in shepherding the AD Review 122 comments, while if the WG Chair is shepherd, this overlap 123 moves. This is simply observed, rather than viewed as a 124 negative, because all reviews are public. 126 2. Throughout the document's period from the time that the WG 127 requests publication until it is published as an RFC, 128 recording notes about it in the i-d tracker and updating its 129 states. 131 Note that some of the state updates are performed by the IETF 132 Secretariat, though the AD Shepherd has access to perform all 133 updates. Note also that the proto-team is investigating 134 tracker changes to facilitate WG Chair shepherding. 136 3. Sometime before standards track documents go on the IESG's 137 agenda for review, preparing a writeup for them. 139 4. Using active monitoring and reminding to minimize document's 140 time in wait states (any of the resolutions in 1, processing 141 in 5, 6, and 7). 143 5. Participating in/reviewing the IANA processing of document. 145 6. Participating in/reviewing the RFC Editor final edits of the 146 document. 148 7. Helping editors/chairs on miscellaneous issues such as 149 submitting an IPR claim. 151 4. Shepherding's Relation to Approval 153 The AD mingles his or her role as a document shepherd with roles 154 having to do with document approval. Separating the two kinds of 155 roles out is necessary in order to have shepherding taken over by WG 156 Chairs, but not always simple. In the RFC Editor final edits above, 157 there wasn't a procedural rule that would bring in AD approval of the 158 change, so that was purely shepherding. 160 A clear case of separation is when the WG Chair requests IETF Last 161 Call for a document. The Shepherd begins shepherding the document at 162 this point (more on this below) and coordinates a gathering of 163 information regarding the document (has the nit review been done, how 164 much early review, AD reviews, and so on). The AD decides whether 165 the IETF Last Call may proceed or not - that is based on 166 recommendation from the Shepherd (on a basis the AD and the Shepherd 167 decide on). If the AD is the Shepherd, the AD reviews his or her own 168 information, of course. The decision is approval, the gathered 169 information is shepherding. 171 5. Who Shepherds What? 173 The concept of shepherding a document currently applies to Area 174 Directors. Documents have Shepherding Area Directors as follows: 176 Working Group Documents - the "Area Advisor" for that Working 177 Group will become the shepherd for the document. 179 Individual submissions to an Area Director - that Area Director. 181 Individual submissions for special cases (e.g. a document about 182 liaison relations by an Area Director and an officer of another SDO) - 183 the IETF Chair will appoint an Area Director to shepherd the document, 184 or might shepherd it himself or herself as the General Area Director. 186 Individual submissions from the RFC Editor - the IESG receives these 187 and volunteers for shepherding them based on their topics. 189 Submissions from the IAB - the IESG's liaison to the IAB shepherds 190 these through their process. 192 6. Steps of Shepherding Working Group Documents 194 This section gives some more detail to AD shepherding of WG 195 documents. Document shepherding is not precisely the same for non-WG 196 documents, but these give a very good feel for the job. This section 197 refers to top-level states used in the i-d tracker. 199 Typically, the Area Director is involved with working group documents 200 because of having chartered the work for them and followed their 201 progress. Ideally there has been time to be involved in early review 202 of the document, before the working group does its last call. But 203 what we define as shepherding the document does not begin until the 204 document reaches the point of the request for publication by the 205 Working Group Chair(s). Each state is considered below. 207 6.1. Publication Requested 209 In the "Publication Requested" state, the WG Chair sends in the 210 document to the IESG Secretary and the AD for the WG with a formal 211 Publication Request. This begins shepherding, but the decision about 212 when the document goes to IETF Last Call (if it is standards track) 213 is an approval-related step. Similarly the decision about when the 214 document is ready to go on the IESG agenda (if it is not standards 215 track) is approval-related. 217 6.2. AD Evaluation 219 In this state, the AD is expected to send the document to the IESG 220 with his or her own issues already resolved. Handling of the AD 221 issues, along with the other kinds of issues listed under the job 222 description above, is a shepherding step. Coordination and 223 resolution of all the issues from comments here is distinct from the 224 AD's job of approving the document to proceed to Last Call or IESG 225 Evaluation from here. 227 6.3. Expert Review 229 The "Expert Review" state can be used for a fairly wide category of 230 reviews, though there are several tight usages such as the O&M policy 231 of requiring MIB Doctor Review of all MIBs before IETF Last Call 232 before IETF Last Call. Coordination and resolution of all the MIB 233 Doctor reviews is shepherding, and it is distinct from the AD's job 234 of approving (in this case, in agreement with the O&M AD) that the 235 document can proceed to Last Call. 237 6.4. IESG Evaluation 239 The "IESG Evaluation" state is when the IESG comment that are 240 recorded in the I-D Tracker [IDTRACKER]. The shepherd makes sure that 241 all the comments have been recorded and are understandable enough. 242 The shepherd has a responsibility to ensure that the document Editor 243 has received all the Discusses and then has responsibility to make 244 sure they all get resolved. This is, of course, done in a variety 245 of ways, depending on the nature of the comments and who they come 246 from. The shepherd may need to coordinate among the several 247 resolutions because of possible conflicts among them. The shepherd 248 also takes responsibility for ensuring that the WG is aware of 249 Discuss changes. When the changes are made, the shepherd has 250 responsibility to make sure that the revision has just those changes 251 and no others, or if the changes are RFC Editor notes, that they are 252 correct (and later that they go into the final edit). 254 The approval-related role here is for the AD to state to the 255 Secretariat after all objections to the document have been removed 256 that the Secretariat should announce the document as approved. By 257 doing so, the responsible AD simply says that he or she has vouched 258 for his or her delegation to the shepherd in carrying out this 259 completion of approval. 261 NOTE: The resolution of comments in any* stage after 262 Publication Requested may require an i-d revision. The 263 shepherd always has responsibility to make sure that only 264 the few changes in the comments are made in the revision, 265 or that revisions are held off. 267 6.5. RFC Editor Queue 269 As mentioned above, the shepherd job description includes 270 participating in and reviewing IANA and RFC-Editor processing of the 271 document. IANA involvement for the shepherd occurs at any time from 272 IETF Last Call onward. 274 7. Contributors 276 TBD 278 8. Acknowledgments 280 TBD 282 9. Security Considerations 284 This document specifies neither a protocol nor an operational 285 practice, and as such, it creates no new security considerations. 287 10. IANA Considerations 289 This document creates a no new requirements on IANA namespaces 290 [RFC2434]. 292 11. References 294 11.1. Informative References 296 [IDTRACKER] https://datatracker.ietf.org 298 [RFC2119] Bradner, S., "Key words for use in RFCs to 299 Indicate Requirement Levels", RFC 2119, March, 300 1997. 302 [RFC2026] Bradner, S., "The Internet Standards Process -- 303 Revision 3", RFC 2026/BCP 9, October, 1996. 305 [RFC2028] Hovey, R. and S. Bradner, "The Organizations 306 Involved in the IETF Standards Process", RFC 307 2028/BCP 11, October, 1996. 309 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 310 Writing an IANA Considerations Section in RFCs", 311 RFC 2434/BCP 26, October 1998. 313 12. Author's Address 315 A. Mankin 316 Email: mankin@psg.com 318 13. Full Copyright Statement 320 Copyright (C) The Internet Society (2004). This document is subject 321 to the rights, licenses and restrictions contained in BCP 78 and 322 except as set forth therein, the authors retain all their rights. 324 This document and translations of it may be copied and furnished to 325 others, and derivative works that comment on or otherwise explain it 326 or assist in its implementation may be prepared, copied, published 327 and distributed, in whole or in part, without restriction of any 328 kind, provided that the above copyright notice and this paragraph are 329 included on all such copies and derivative works. However, this 330 document itself may not be modified in any way, such as by removing 331 the copyright notice or references to the Internet Society or other 332 Internet organizations, except as needed for the purpose of 333 developing Internet standards in which case the procedures for 334 copyrights defined in the Internet Standards process must be 335 followed, or as required to translate it into languages other than 336 English. 338 The limited permissions granted above are perpetual and will not be 339 revoked by the Internet Society or its successors or assigns. 341 This document and the information contained herein is provided on an 342 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 343 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 344 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 345 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 346 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 14. Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at ietf- 370 ipr@ietf.org. 372 15. Acknowledgement 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.