idnits 2.17.1 draft-ietf-proto-wgchair-doc-shepherding-07.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 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 767. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (June 23, 2006) is 6516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PROTO Team A. Falk 3 Internet-Draft ISI 4 Intended status: Informational H. Levkowetz 5 Expires: December 25, 2006 Ericsson 6 D. Meyer 7 Cisco/University of Oregon 8 L. Eggert 9 NEC 10 A. Mankin 11 June 23, 2006 13 Document Shepherding From Working Group Last Call to IESG Approval 14 draft-ietf-proto-wgchair-doc-shepherding-07 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 25, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document describes methodologies that have been designed to 48 improve and facilitate IETF document flow processing. It specifies a 49 set of procedures under which a working group chair or secretary 50 serves as the primary Document Shepherd for a document that has been 51 submitted to the IESG for publication. Before this, the shepherding 52 role has traditionally been filled by the Area Director responsible 53 for the working group. 55 A Document Shepherd's responsibilities include: 57 o Providing the Document Shepherd Write-Up accompanying a document 58 that is forwarded to the IESG when publication is requested. 60 o During AD Evaluation by the Responsible Area Director, managing 61 the discussion between the authors, the working group, and the 62 Responsible Area Director. 64 o During IESG evaluation, following up on all IESG feedback 65 ("DISCUSS" and "COMMENT" items) related to the shepherded 66 document. 68 o Following up on IANA and RFC Editor requests in the post-approval 69 shepherding of the document. 71 In summary, a Document Shepherd continues to care for a shepherded 72 document during its post-WG lifetime similar to the way he or she has 73 cared for it while responsible for the document in a working group. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 80 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 81 3.2. Document Shepherding during AD Evaluation . . . . . . . . 8 82 3.3. Document Shepherding during IESG Evaluation . . . . . . . 10 83 4. When Not to Use the Document Shepherding Process . . . . . . . 12 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 87 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 88 Appendix A. Working Documents . . . . . . . . . . . . . . . . . . 14 89 Appendix B. Example Document Announcement Write-Ups . . . . . . . 15 90 B.1. Example Document Announcement Write-Up for 91 draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 15 92 B.2. Example Document Announcement Write-Up for 93 draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 Intellectual Property and Copyright Statements . . . . . . . . . . 18 97 1. Introduction 99 Early in 2004, the IESG undertook several experiments aimed at 100 evaluating whether any of the proposed changes to the IETF document 101 flow process would yield qualitative improvements in document 102 throughput and quality. One such experiment, referred to as the 103 "PROTO process" or "PROTO" (because it was created by the "PROcess 104 and TOols" or PROTO [PROTO] team, is a set of methodologies designed 105 to involve working group chairs or secretaries more directly in their 106 documents' approval life cycle. In particular, the PROTO team 107 focused on improvements to the part of a document's life cycle that 108 occurs after the working group and document editor have forwarded it 109 to the IESG for publication. 111 By the end of 2004, the IESG had evaluated the utility of the PROTO 112 methodologies based on data obtained through several pilot projects 113 that had run throughout the year, and subsequently decided to adopt 114 the PROTO process for all documents and working groups. This 115 document describes this process. 117 The methodologies developed and piloted by the PROTO team focus on 118 the working group chair or secretary as the primary Document 119 Shepherd. The primary objective of this document shepherding process 120 is to improve document processing throughput and document quality by 121 enabling a partnership between the Responsible Area Director and the 122 Document Shepherd. In particular, this partnership has the explicit 123 goal of empowering the Document Shepherd while at the same time 124 offloading a specific part of the follow-up work that has 125 traditionally been responsibility of the Responsible Area Director. 127 Consequently, the document shepherding process includes follow-up 128 work during all document processing stages after Working Group Last 129 Call, i.e., during AD Evaluation of a document, during IESG 130 evaluation, and during post-approval processing by IANA and the RFC 131 Editor. In these stages, it is the responsibility of the Document 132 Shepherd to track and follow up on feedback received on a document 133 from all relevant parties. 135 The Document Shepherd is usually a chair of the working group that 136 has produced the document. In consultation with the Responsible Area 137 Director, the chairs may instead decide to appoint a working group 138 secretary as the responsible Document Shepherd. 140 The remainder of this document is organised as follows: Section 3 141 outlines the overall document shepherding process. Section 3.1 142 describes the Document Shepherd Write-Up that accompanies the 143 publication request of a document. Section 3.2 describes the AD 144 Evaluation shepherding process and Section 3.3 describes IESG DISCUSS 145 shepherding. Finally, Section 4 describes those cases in which the 146 document shepherding process should not be used. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in BCP 14, RFC 2119 153 [RFC2119]. 155 3. Process Description 157 The document shepherding process consists of the following tasks: 159 o Providing the Document Shepherd Write-Up accompanying a document 160 that is forwarded to the IESG when publication is requested, as 161 described in Section 3.1. 163 o During AD Evaluation of the document by the Responsible Area 164 Director, managing the discussion between the authors, the working 165 group and the Responsible Area Director, as described in 166 Section 3.2. 168 o During IESG evaluation, following up on all IESG feedback 169 ("DISCUSS" and "COMMENT" items) related to the shepherded 170 document, as described in Section 3.3. 172 o Following up on IANA and RFC Editor requests in the post-approval 173 shepherding of the document. 175 In summary, a Document Shepherd continues to care for a shepherded 176 document during its post-WG lifetime similar to how how he or she has 177 done while responsible for the document in a working group. 179 Before any document shepherding takes place, a single Document 180 Shepherd must be identified for a document. This is typically the 181 chair of the working group that has produced a document. If the 182 working group has more than one chair, the chairs decide on who 183 should act as Document Shepherd for a document. In consultation with 184 the Responsible Area Director, the chairs may also decide to appoint 185 a working group secretary as Document Shepherd. The Document 186 Shepherd SHOULD NOT be an author of the shepherded document. 188 It is important to note that the document shepherding process only 189 applies to documents that are the product of a working group. It 190 does not apply to documents that originate elsewhere. Additionally, 191 Section 4 discusses other instances in which the document shepherding 192 process does not apply. 194 3.1. Document Shepherd Write-Up 196 When a working group decides that a document is ready for submission 197 to the IESG for publication, it is the task of the Document Shepherd 198 to complete a "Document Shepherd Write-Up" for the document. 200 There are two parts to this task. First, the Document Shepherd 201 answers questions 1.a to 1.h below to give the Responsible Area 202 Director insight into the working group process that applied to this 203 document. Note that while these questions may appear redundant in 204 some cases, they are written to elicit information that the 205 Responsible Area Director must be aware of (to this end, pointers to 206 relevant entries in the WG archive will be helpful). The goal here 207 is to inform the Responsible Area Director about any issues that may 208 have come up in IETF meetings, on the mailing list, or in private 209 communication that they should be aware of prior to IESG evaluation 210 of the shepherded document. Any significant issues mentioned in the 211 questionnaire will probably lead to a follow-up discussion with the 212 Responsible Area Director. 214 The second part of the task is to prepare the "Document Announcement 215 Write-Up" that is input to both the ballot for the IESG telechat and 216 to the eventual IETF-wide announcement message. Item number (1.i) 217 describes the elements of the Document Announcement Write-Up. Some 218 examples of Document Announcement Write-Ups are included in 219 Appendix B, and there are many more examples with Subject lines such 220 as "Protocol Action" and "Document Action" in the IETF-announce 221 mailing list archive. 223 (1.a) Who is the Document Shepherd for this document? Has the 224 Document Shepherd personally reviewed this version of the 225 document and, in particular, does he or she believe this 226 version is ready for forwarding to the IESG for publication? 228 (1.b) Has the document had adequate review both from key WG members 229 and from key non-WG members? Does the Document Shepherd have 230 any concerns about the depth or breadth of the reviews that 231 have been performed? 233 (1.c) Does the Document Shepherd have concerns that the document 234 needs more review from a particular or broader perspective, 235 e.g., security, operational complexity, someone familiar with 236 AAA, internationalization or XML? 238 (1.d) Does the Document Shepherd have any specific concerns or 239 issues with this document that the Responsible Area Director 240 and/or the IESG should be aware of? For example, perhaps he 241 or she is uncomfortable with certain parts of the document, or 242 has concerns whether there really is a need for it. In any 243 event, if those issues have been discussed in the WG and the 244 WG has indicated that it still wishes to advance the document, 245 detail those concerns here. 247 (1.e) How solid is the WG consensus behind this document? Does it 248 represent the strong concurrence of a few individuals, with 249 others being silent, or does the WG as a whole understand and 250 agree with it? 252 (1.f) Has anyone threatened an appeal or otherwise indicated extreme 253 discontent? If so, please summarise the areas of conflict in 254 separate email messages to the Responsible Area Director. (It 255 should be in a separate email because this questionnaire will 256 be entered into the ID Tracker.) 258 (1.g) Has the Document Shepherd verified that the document satisfies 259 all ID nits? (See http://www.ietf.org/ID-Checklist.html and 260 http://tools.ietf.org/tools/idnits/). Boilerplate checks are 261 not enough; this check needs to be thorough. 263 (1.h) Has the document split its references into normative and 264 informative? Are there normative references to documents that 265 are not ready for advancement or are otherwise in an unclear 266 state? If such normative references exist, what is the 267 strategy for their completion? Are there normative references 268 that are downward references, as described in [RFC3967]? If 269 so, list these downward references to support the Area 270 Director in the Last Call procedure for them [RFC3967]. 272 (1.i) The IESG approval announcement includes a Document 273 Announcement Write-Up. Please provide such a Document 274 Announcement Write-Up. Recent examples can be found in the 275 "Action" announcements for approved documents. The approval 276 announcement contains the following sections: 278 Technical Summary 279 Relevant content can frequently be found in the abstract 280 and/or introduction of the document. If not, this may be 281 an indication that there are deficiencies in the abstract 282 or introduction. 284 Working Group Summary 285 Was there anything in WG process that is worth noting? For 286 example, was there controversy about particular points or 287 were there decisions where the consensus was particularly 288 rough? 290 Document Quality 291 Are there existing implementations of the protocol? Have a 292 significant number of vendors indicated their plan to 293 implement the specification? Are there any reviewers that 294 merit special mention as having done a thorough review, 295 e.g., one that resulted in important changes or a 296 conclusion that the document had no substantive issues? 298 The Document Shepherd MUST send the Document Shepherd Write-Up to the 299 Responsible Area Director and iesg-secretary@ietf.org together with 300 the request to publish the document. The Document Shepherd SHOULD 301 also send the entire Document Shepherd Write-up to the working group 302 mailing list. If there is information which may prove to be 303 sensitive, lead to possible appeals or is personal information that 304 the Document Shepherd feels should be written up, it should be sent 305 in direct email to the Responsible Area Director, because the 306 Document Shepherd Write-Up will be published openly in the tracker. 308 The Document Shepherd Write-Up is entered into the ID Tracker 309 [IDTRACKER] as a "Comment." The name and email address of the 310 Document Shepherd are entered into the ID Tracker, currently as a 311 "Brief Note" (this may change in the future). The email address of 312 the Document Shepherd MUST also be added to the "State or Version 313 Change Notice To" field. In addition to making life easier during 314 IESG Evaluation, this information is important for the IETF Chair's 315 Gen-ART [GEN-ART] Directorate and other directorates, so they can 316 know where to address reviews to, in addition to the Responsible Area 317 Director. 319 3.2. Document Shepherding during AD Evaluation 321 The steps for document shepherding during AD Evaluation are as 322 follows: 324 (2.a) The Responsible Area Director reads, evaluates and comments on 325 the document, as is the case when not using the document 326 shepherding process. If the Responsible Area Director 327 determines that the document is ready for IESG Evaluation, he 328 or she indicates this to the Document Shepherd and the 329 document shepherding process continues as described in 330 Section 3.3. 332 (2.b) If the Responsible Area Director has identified issues with a 333 document that must be addressed before IESG Evaluation can 334 commence, he or she sends a full evaluation to the Document 335 Shepherd and should also enter the review into the ID Tracker. 337 (2.c) The Document Shepherd reads the AD Evaluation comments, making 338 very certain that all comments are understood, so that it is 339 possible to follow up on them with the authors and working 340 group. If there is some uncertainty as to what is requested, 341 this must be resolved with the Responsible Area Director. 343 (2.d) The Document Shepherd sends the AD Evaluation comments to the 344 authors and to the working group mailing list, in order to 345 have a permanent record of the comments. It is RECOMMENDED 346 that the Document Shepherd solicit from the authors an 347 estimate on when the required changes will be complete and a 348 revised document can be expected. Working groups that use 349 issue tracking should also record the issues (and eventually 350 their resolution) in their issue tracker. 352 (2.e) During the production of a revised document that addresses the 353 AD Evaluation comments, it is strongly RECOMMENDED that the 354 authors keep a list showing how each comment was addressed and 355 what the revised text is. It is strongly RECOMMENDED that 356 this list be forwarded to the Responsible Area Director 357 together with the revised document. 359 (2.f) In the event that the authors or working group disagrees with 360 a comment raised by the Responsible Area Director or has 361 previously considered and dismissed the issue, the Document 362 Shepherd MUST resolve the issue with the Responsible Area 363 Director before a revised document can be submitted. 365 (2.g) The Document Shepherd iterates with the authors (and working 366 group, if required) until all outstanding issues have been 367 resolved and a revised document is available. At this point, 368 the Document Shepherd notifies the Responsible Area Director 369 and provides him or her with the revised document, the summary 370 of issues and the resulting text changes. 372 (2.h) The Responsible Area Director verifies that the issues he or 373 she found during AD Evaluation are resolved in the revised 374 version of the document by starting the process described in 375 this section at step (2.a). 377 3.3. Document Shepherding during IESG Evaluation 379 During IESG Evaluation of a document, ADs can bring forward two kinds 380 of remarks about a document: DISCUSS item and COMMENT items. A 381 DISCUSS blocks a document's approval process until it has been 382 resolved; a COMMENT does not. This section details the steps that a 383 Document Shepherd takes to resolve any DISCUSS and COMMENT items 384 brought forward against a shepherded document during IESG Evaluation. 386 Note that DISCUSS and COMMENT items are occasionally written in a 387 manner that makes their intent unclear. In these cases, the Document 388 Shepherd SHOULD start a discussion with the ADs who brought the items 389 up to clarify their intent, keeping the Responsible Area Director 390 informed. If this fails to clarify the intent, the Responsible Area 391 Director may need to work towards a clarification inside the IESG. 393 (3.a) Leading up to the IESG conference call, the Document Shepherd 394 may see emails about the document from directorate reviewers 395 on behalf one or more ADs and also emailed copies of DISCUSS 396 and COMMENT items entered into the ID Tracker. The Document 397 Shepherd SHOULD immediately begin to work on resolving DISCUSS 398 and COMMENT items with the ADs who have raised them, keeping 399 the Responsible Area Director copied on the email exchange, so 400 that he or she is able support the the activity during the 401 conference call. When dealing with directorate reviews, the 402 Document Shepherd MUST involve the ADs to whom these 403 directorates report to ensure that these ADs consider the 404 review comments that need resolving. 406 (3.b) Immediately following the conference call, when the document 407 changes state from the "IESG Evaluation" state to one of the 408 states requiring Document Shepherd action, e.g., "IESG 409 Evaluation: Revised ID Needed" or "IESG Evaluation: AD 410 Followup", the Document Shepherd will receive email. A state 411 of "AD Followup" typically signifies the Responsible Area 412 Director's hope that a resolution may be possible through a 413 continued discussion or (more usually) through a small set of 414 changes as "Notes to the RFC Editor." 416 Note that there may be very exceptional cases when DISCUSS 417 items are registered after an IESG conference call. In these 418 cases, the AD who has raised the DISCUSS MUST notify the 419 Document Shepherd about it. (The notification facility in the 420 ID Tracker is very convenient for this purpose and also for 421 the cases where the DISCUSS and COMMENT items are updated 422 after they are partially resolved.) 424 (3.c) The Document Shepherd then queries the ID Tracker to collect 425 the remaining DISCUSS and COMMENT items raised against the 426 document. The Document Shepherd analyses these items and 427 initialises contact with the ADs who have placed them. The 428 Responsible Area Director MUST be copied on all correspondence 429 related to active DISCUSS or COMMENT items. This does not 430 place the Responsible Area Director in the critical path 431 towards a resolution, but should keep him or her informed 432 about the state of the discussion. 434 +-------+ +-------+ +-------+ 435 | (3.b) | -----------> | (3.c) | ------------> | (3.d) | 436 +-------+ Comments +-------+ Comments +-------+ 437 collected /|\ | understood 438 | | 439 | | Comments not fully understood 440 | | (Further AD/Document Shepherd 441 | | discussion required) 442 +---+ 444 (3.d) The Document Shepherd then coordinates the resolution of 445 DISCUSS and COMMENT items and builds a a consistent 446 interpretation of the comments. This step is similar to much 447 of the process described in Section 3.2. 449 +-------+ +-------+ 450 | (3.c) | ---------------> | (3.d) | 451 +-------+ Consistent +-------+ 452 /|\ interpretation | 453 | | Further AD/Document Shepherd 454 | | discussion required 455 +--------------------------+ 457 (3.e) The Document Shepherd then communicates the DISCUSS and 458 COMMENT items to the document authors and the working group. 460 (3.f) After the authors resolve the DISCUSS and COMMENT items, the 461 Document Shepherd reviews the resulting revised document, 462 using his or her technical expertise to ensure that all raised 463 DISCUSS and COMMENT issues have been resolved. 465 Note that the Document Shepherd may also suggest resolutions 466 to DISCUSS and COMMENT items, enter them into an issue 467 tracker, or perform other steps to streamline the resolution 468 of the evaluation comments. It is very important to resolve 469 the comments in a timely way, while the discussion is current 470 for everyone involved. 472 (3.g) When the Document Shepherd is satisfied that the revised 473 document addresses the evaluation comments, he or she 474 communicates the resolution to the Responsible Area Director 475 and the ADs that had raised the DISCUSS and COMMENT items. 477 (3.h) Each AD that had raised a DISCUSS checks whether the 478 communicated resolution addresses their DISCUSS items. If it 479 does, the AD will clear the DISCUSS. It it does not, the AD 480 notifies the Document Shepherd and adds information to the ID 481 Tracker explaining why the DISCUSS was not resolved. The 482 Document Shepherd informs the working group accordingly. 483 (COMMENT items need not be checked and cleared, because they 484 do not block the document, but ADs are encouraged to do so.) 486 If a DISCUSS was not resolved to the satisfaction of the AD 487 that has raised it or the Responsible Area Director, two 488 possibilities exist: 490 (a) The process returns to step (3.d), or 492 (b) If no progress can be made on the resolution of the 493 DISCUSS with the AD who has raised it, despite 494 clarification and additional involvement of the 495 Responsible Area Director, the Document Shepherd and 496 working group might as a very last resort consider an 497 appeal in accordance with the procedures described in 498 [RFC2026] and referred to in [RFC2418]. The Document 499 Shepherd SHOULD also review the IESG's Discuss Criteria 500 guidelines [I-D.iesg-discuss-criteria] and discuss with 501 the Responsible Area Director whether there might be 502 considerations against the unresolved DISCUSS by the rest 503 of the IESG due to these guidelines. 505 Once the process above has cleared all DISCUSS items, document 506 shepherding continues with step (3.i). 508 (3.i) The Responsible Area Director moves document to the "Approved 509 - Announcement to be sent" state in the ID Tracker, or, if he 510 or she deems the changes to the revised document significant, 511 there may be a new WG last call. In the latter case, the 512 document may go through a full IESG Evaluation process again. 514 4. When Not to Use the Document Shepherding Process 516 As mentioned in Section 3, the Document Shepherd SHOULD NOT be an 517 author of the shepherded document. If this cannot be avoided by 518 making another working group chair or secretary the Document 519 Shepherd, the document shepherding process SHOULD NOT be used. There 520 are several other cases in which the document shepherding process 521 SHOULD NOT be used. These include: 523 1. Cases, where the Document Shepherd is the primary author or 524 editor of a large percentage of the documents produced by the 525 working group. 527 2. Cases, where the Responsible Area Director expects communication 528 difficulties with the Document Shepherd (either due to 529 experience, strong views stated by the Document Shepherd, or 530 other issues). 532 3. Cases, where the working group itself is either very old, losing 533 energy, or winding down, i.e., cases, where it would not be 534 productive to initiate new processes or procedures. 536 Finally, note that other cases exist in which using the document 537 shepherding process may not be productive. The final determination 538 as to whether to use the document shepherding process or not is left 539 to the Responsible Area Director. If the document shepherding 540 process is not used, the Responsible Area Director acts as Document 541 Shepherd, just as he or she did in the past. 543 5. Security Considerations 545 This document specifies a change to IETF document processing 546 procedures. As such, it neither raises nor considers protocol- 547 specific security issues. 549 6. IANA Considerations 551 This document creates no new requirements on IANA namespaces or other 552 IANA requirements. 554 7. Acknowledgments 556 This document is the product of PROTO team, which includes the 557 authors as well as Bill Fenner, Barbara Fuller, and Margaret 558 Wasserman. 560 The Document Shepherd Write-Up originated in an idea by John Klensin. 561 Thomas Narten and Margaret Wasserman implemented it for the entire 562 Internet Area, and their template was the basis of the version used 563 today. 565 Colin Perkins wrote the Document Announcement Write-Up for 566 draft-ietf-avt-rtp-midi-format included in Appendix B.1. David Black 567 wrote the Document Announcement Write-Up for 568 draft-ietf-imss-ip-over-fibre-channel included in Appendix B.2. 570 8. Informative References 572 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 573 3", BCP 9, RFC 2026, October 1996. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 579 Procedures", BCP 25, RFC 2418, September 1998. 581 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 582 Documents may Refer Normatively to Documents at a Lower 583 Level", BCP 97, RFC 3967, December 2004. 585 [I-D.iesg-discuss-criteria] 586 Peterson, J., "DISCUSS Criteria in IESG Review", 587 draft-iesg-discuss-criteria-02 (work in progress), 588 February 2006. 590 [IDTRACKER] 591 "The IETF Internet-Draft Tracker", Web 592 Application: https://datatracker.ietf.org/, 2002. 594 [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web 595 Page: http://psg.com/~mrw/PROTO-Team, 2004. 597 [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: 598 http://www.alvestrand.no/ietf/gen/review-guidelines.html, 599 2005. 601 Appendix A. Working Documents 603 (This section should be removed by the RFC editor before 604 publication.) 606 The current working documents for this document are available at this 607 web site: 609 http://tools.ietf.org/wg/proto/ 610 draft-ietf-proto-wgchair-doc-shepherding/ 612 Appendix B. Example Document Announcement Write-Ups 614 This appendix includes two examples of Document Announcement Write- 615 Ups. Many more examples with Subject lines such as "Protocol Action" 616 and "Document Action" can be found in the IETF-announce mailing list 617 archive. 619 B.1. Example Document Announcement Write-Up for 620 draft-ietf-avt-rtp-midi-format 622 Technical Summary 624 These documents define the RTP Payload format for MIDI (Musical 625 Instrument Digital Interface), and additional guidelines on 626 implementation specifically concerning the timing of reception and 627 transmission for best performance in different applications. MIDI 628 is a real-time media, which however is brittle to losses and 629 errors. Therefore the RTP payload format defines recovery 630 journals as a way of avoiding persistent audible errors, and 631 discusses congestion control handling for these journals. 633 The RTP payload for MIDI encodes the broad range of MIDI commands. 634 The format is suitable for interactive applications (such as 635 network musical performance) and content-delivery (such as file 636 streaming). 638 Working Group Summary 640 There is consensus in the WG to publish these documents. 642 Document Quality 644 This RTP Payload format has been implemented during the 645 development of the specification and successfully tested over an 646 IP network between two remote sites, thus showing that the 647 technical solution is successfully working. It has been reviewed 648 by the MIDI Manufacturers Association and their comments have been 649 addressed. Allison Mankin reviewed the document for the IESG, 650 including a careful review with the editor of the media types, in 651 parallel with ietf-types list review requested on 2006-01-08, 652 which raised no issues. 654 Magnus Westerlund and Colin Perkins jointly shepherded these 655 documents. 657 B.2. Example Document Announcement Write-Up for 658 draft-ietf-imss-ip-over-fibre-channel 660 Technical Summary 662 This document specifies the encapsulation of IPv6, IPv4 and ARP 663 packets over Fibre Channel. This document also specifies the 664 methods for forming IPv6 link-local addresses and statelessly 665 autoconfigured IPv6 addresses on Fibre Channel networks, and a 666 mechanism to perform IPv4 address resolution over Fibre Channel 667 networks. This document (when published as RFC) obsoletes RFC2625 668 and RFC3831. 670 Working Group Summary 672 This document has been reviewed by Fibre Channel experts in 673 Technical Committee T11 (Fibre Channel standards organization) in 674 addition to members of the IMSS WG. There is solid support for 675 this document both in the WG and from T11. 677 Document Quality 679 This document replaces and consolidates two separate RFCs on IPv4 680 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 681 3831). Most of its technical content is unchanged from those 682 RFCs. The technical changes that have been made are primarily 683 based on implementation experience. 685 The protocol has been reviewed for the IESG by David L. Black (WG 686 chair). 688 Also Bert Wijnen has reviewed this document for the IESG. 690 In addition, Brian Haberman has done a review for the INT Area as 691 requested by WG-chair (David Black) via Margaret Wasserman. 693 Authors' Addresses 695 Aaron Falk 697 Email: falk@isi.edu 698 Henrik Levkowetz 699 Torsgatan 71 700 Stockholm S-113 37 701 Sweden 703 Phone: +46 708 32 16 08 704 Email: henrik@levkowetz.com 706 David Meyer 707 1225 Kincaid St 708 Eugene, OR 97403 709 USA 711 Phone: +1 541 346 1747 712 Email: dmm@1-4-5.net 714 Lars Eggert 715 NEC Network Laboratories 716 Kurfuerstenanlage 36 717 Heidelberg 69115 718 Germany 720 Phone: +49 6221 4342 143 721 Fax: +49 6221 4342 155 722 Email: lars.eggert@netlab.nec.de 723 URI: http://www.netlab.nec.de/ 725 Allison Mankin 727 Email: mankin@psg.com 729 Full Copyright Statement 731 Copyright (C) The Internet Society (2006). 733 This document is subject to the rights, licenses and restrictions 734 contained in BCP 78, and except as set forth therein, the authors 735 retain all their rights. 737 This document and the information contained herein are provided on an 738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 741 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 742 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 745 Intellectual Property 747 The IETF takes no position regarding the validity or scope of any 748 Intellectual Property Rights or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; nor does it represent that it has 752 made any independent effort to identify any such rights. Information 753 on the procedures with respect to rights in RFC documents can be 754 found in BCP 78 and BCP 79. 756 Copies of IPR disclosures made to the IETF Secretariat and any 757 assurances of licenses to be made available, or the result of an 758 attempt made to obtain a general license or permission for the use of 759 such proprietary rights by implementers or users of this 760 specification can be obtained from the IETF on-line IPR repository at 761 http://www.ietf.org/ipr. 763 The IETF invites any interested party to bring to its attention any 764 copyrights, patents or patent applications, or other proprietary 765 rights that may cover technology that may be required to implement 766 this standard. Please address the information to the IETF at 767 ietf-ipr@ietf.org. 769 Acknowledgment 771 Funding for the RFC Editor function is provided by the IETF 772 Administrative Support Activity (IASA).