idnits 2.17.1 draft-ietf-proto-ad-comments-pilot-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 410), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (April 2004) is 7309 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) == Unused Reference: 'RFC2026' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 341, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Proto Team H. Levkowetz 3 Internet-Draft ipUnplugged 4 Expires: September 30, 2004 April 2004 6 Protocol Pilot: Workgroup Chair Followup of AD Evaluation Comments 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt . 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html . 32 This Internet-Draft will expire on September 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes a pilot implementation of a protocol change 41 within the IETF. The essence of the change is to have workgroup 42 chairs handle the feedback of AD (Area Director) Evaluation comments 43 on a draft to the authors (and workgroup if necessary) and make sure 44 that needed draft changes are made, and the AD notified when a new 45 draft which resolves the comments is available. 47 1. Introduction 49 As part of the currently ongoing effort to improve the work flow 50 (particularly speed of approval) of documents, the PROTO team 51 [PROTO] is defining pilot projects to test possible protocol changes. 52 This document describes such a pilot. 54 The purpose of the pilot described here is to test offloading 55 follow-up work which an Area Director (AD) traditionally has done 56 after he has read through and evaluated a document submitted to the 57 IESG for publication. It is hoped that offloading this onto the 58 chair (or one of the chairs) of the workgroup which submitted the 59 draft will increase the speed of follow-up and the transparency of 60 the process, and reduce the workload of the AD to boot. The pilot 61 does not include offloading of follow-up for drafts which do not 62 originate in a workgroup. 64 For a discussion of the reasoning underlying piloting of process 65 changes, see [JULY14]. 67 2. Pilot description 69 2.1 Participants 71 This pilot involves Area Directors of selected areas, and some or all 72 of the chairs for which the Area Director is Area Advisor. 74 2.2 Running time and pilot size 76 This pilot is to be run not less than 4 months, and not more than 8 77 months, unless early experience shows it to be clearly detrimental. 78 It is expected that it will be started shortly after the IETF 59 79 meeting, and completed in time for the results to be reported at the 80 IETF 60 meeting. The pilot should be run with no less than 2 and not 81 more than 6 ADs, and between 5 and 20 workgroups. 83 The running time should be chosen such that the participating ADs and 84 WG chairs have opportunity to get past the initial learning and 85 first-time execution barrier, and get some familiarity with the 86 process before the pilot is closed and evaluated. 88 2.3 Assumptions 90 The pilot assumes that the steps an Area Director currently (before 91 this pilot goes into effect) go through for an AD Evaluation are as 92 follows: 94 1. Read and evaluate the document, taking notes of issues found. It 95 is expected that each AD has his own style and method of 96 evaluating documents, but roughly the elements given in Section 97 3.3 of [SIRS] are probably present in the review. 99 2. Depending on the magnitude of the issues found (and other 100 considerations?), either 102 2.a) return the document to the chairs with the review, 103 requesting further workgroup work, and post the review to the 104 workgroup mailing list 106 2.b) send the full review to the authors, with copy to the 107 chairs, and ask for issues to be resolved; post a summary of the 108 review to the workgroup mailing list 110 2.c) send the full review to the authors, possibly with copy to 111 the chairs, and ask for nits to be fixed. 113 3. Follow-up, nudge and iterate until the authors (and workgroup if 114 required) has fixed the issues found, and submitted an updated 115 draft. At this point, the draft is ready for IETF last call if 116 it is a standards-track document (or BCP), or for placement on 117 telechat agenda otherwise. 119 2.4 Pilot Process Description 121 The pilot process is changed compared with the process described 122 above in that the responsibility for step 3 above is put squarely on 123 the Workgroup Chair, rather than on the Area Director. Step 2 should 124 preferably be modified so that the Area Director sends the AD 125 Evaluation review comments to the chair(s), who in turn forward them 126 to the authors and workgroup as appropriate. The steps are then as 127 follows: 129 1. If there is more than one chair, the chairs decide on which one 130 should be responsible for ensuring that the needed fixes are done 131 when the AD returns comments. This can for instance be done at 132 the time the publication request is sent. It is important that 133 this is an explicit agreement. 135 2. The AD reads, evaluates and writes comments pretty much as 136 before. However, note that since the communication between AD 137 and authors is not direct, the need for clear and 138 well-articulated review comments is somewhat larger. 140 3. Depending on the magnitude of the issues found (and other 141 considerations?), the AD returns the full review to the chairs, 142 and requests either: 144 3.a) that further workgroup work be undertaken to put the 145 document into shape to be published 147 3.b) that authors and workgroup are informed of the issues found 148 and resolve them in a revised draft 150 3.c) that the authors fix nits as needed. 152 As covered below, the comments will be posted to the workgroup 153 mailing list. The comments will normally also be posted by the 154 AD in the ID Tracker [IDTRACKER]. Working groups that use issue 155 tracking should also record the issues (and eventually their 156 resolution) in the issue tracker. 158 4. The chair responsible reads through the AD Evaluation comments, 159 making very certain that all comments are understood, so that it 160 is possible to follow up on them with the authors and workgroup. 161 If there is some uncertainty as to what is requested, this must 162 be resolved with the Area Director. 164 5. The responsible chair sends the comments to the author(s) and to 165 the workgroup mailing list, in order to have a permanent record 166 of the comments. It is recommended that the chair solicit from 167 the author(s) an estimate on when the fixes will be done - i.e., 168 when the submission of a revised draft can be expected. 170 6. When incorporating the fixes in the new version of the draft, it 171 is strongly recommended that the revising editor keep a summary 172 list showing how the issues were addressed issue by issue, and 173 showing what the revised text is. If such a list is forwarded to 174 the AD with the revised draft, it will make it possible for the 175 AD to verify the fixes very quickly. 177 7. The responsible chair follows-up, nudges and iterates until the 178 authors (and workgroup if required) has fixed the issues found, 179 and submitted an updated draft. At this point, the AD is 180 notified of the revised draft, and provided with the summary list 181 of issues and resulting text changes. 183 In the event that the working group disagrees with a comment 184 raised by the AD or has already considered the issue and 185 previously ruled it out, this must be discussed and resolved with 186 the AD before the new version of the draft is submitted. 188 8. The Area Director verifies that the issues he found during AD 189 Evaluation are resolved by the new version of the draft. 191 9. (Hopefully, that's it, but in the worst case this starts over at 192 1 again...) 194 2.5 Wrap-up 196 At the end of the pilot lifetime, it is expected that an evaluation 197 of the experienced benefits is made, using input solicited from the 198 participating Area Directors and Workgroup Chairs by means of an 199 email questionnaire, web-page form or something similar. The 200 questions are given below, in Section 2.5.2. A per-review 201 questionnaire is also provided in Section 2.5.1. 203 2.5.1 Questionnaire to be done after each individual AD Review 205 To be done by both WG Chair and AD. 207 R1. I'm submitting this questionnaire as 208 1. Area Director 209 2. Workgroup Chair 211 R2. Document name: 213 R3. WG Chair shepherding of the AD evaluation comments for this 214 draft speeded up the procedure: 215 1. Strongly disagree 216 2. Disagree 217 3. Undecided 218 4. Agree 219 5. Strongly agree 221 R4. WG Chair shepherding of the AD evaluation comments for this 222 draft resulted in the comments being resolved in a satisfactory 223 manner: 224 1. Strongly disagree 225 2. Disagree 226 3. Undecided 227 4. Agree 228 5. Strongly agree 230 R5. WG Chair shepherding of the AD evaluation comments for this 231 draft resulted in a more transparent process: 232 1. Strongly disagree 233 2. Disagree 234 3. Undecided 235 4. Agree 236 5. Strongly agree 238 R6. WG Chair shepherding of the AD evaluation comments for this 239 draft resulted in a more well-documented process: 240 1. Strongly disagree 241 2. Disagree 242 3. Undecided 243 4. Agree 244 5. Strongly agree 246 R7. The interaction with the document editors in resolving the 247 comments worked out well: 248 1. Strongly disagree 249 2. Disagree 250 3. Undecided 251 4. Agree 252 5. Strongly agree 254 R8. - Public Comments? 256 R9. - Comments to IESG and PROTO-Team only? 258 R10. WG Chair shepherding of the AD evaluation comments for this 259 draft worked out well, overall: 260 1. Strongly disagree 261 2. Disagree 262 3. Undecided 263 4. Agree 264 5. Strongly agree 266 R11. - Public Comments? 268 R12. - Comments to IESG and PROTO-Team only? 270 2.5.2 Questionnaire for the Pilot as a Whole 272 To be done by both WG Chair and AD. 274 X1. Document name: 276 X2. I clearly understood what was expected of me in this pilot. 277 1. Strongly disagree 278 2. Disagree 279 3. Undecided 280 4. Agree 281 5. Strongly agree 283 Comments? 285 X3. What is your evaluation of the benefit of the procedure you've 286 tried out in this pilot? 287 1. Definitely harmful 288 2. Somewhat harmful 289 3. Mixed feelings 290 4. Somewhat beneficial 291 5. Definitely beneficial 293 Comments? 295 X4. What is your evaluation of the added effort required for the 296 procedure you've tried out in this pilot? 297 1. Major increased effort 298 2. Somewhat increased 299 3. No change 300 4. Somewhat decreased effort 301 5. Major decreased effort 303 Comments? 305 X5. Considering all factors, this procedure should be made the 306 normal way of handling AD evaluation comments. 307 1. Strongly disagree 308 2. Disagree 309 3. Undecided 310 4. Agree 311 5. Strongly agree 313 Comments? 315 X6. What do you consider to be the major advantages of this 316 procedure change? 318 X7. What do you consider to be the major disadvantages of this 319 procedure change? 321 X8. How would you change the procedure to minimise the 322 disadvantages? 324 X9. Comments to the IESG and PROTO-Team only: 326 3. Security Considerations 328 This document specifies a pilot implementation of a change in IETF 329 procedures. It does not raise or consider any protocol-specific 330 security issues. When evaluating the result of the pilot, the IESG 331 should check if the changes has reduced the quality of security 332 review and consideration for protocols, and take this into 333 consideration when deciding whether the changes should be made 334 permanent. 336 4 Informative References 338 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 339 3", BCP 9, RFC 2026, October 1996. 341 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 342 the IETF Standards Process", BCP 11, RFC 2028, October 343 1996. 345 [JULY14] Klensin, J. and S. Dawkins, "A model for IETF Process 346 Experiments", draft-klensin-process-july14-02 (work in 347 progress), April 2004. 349 [SIRS] Carpenter, B. and D. Crocker, "Careful Additional Review 350 of Documents (CARD)by Senior IETF Reviewers (SIRS)", 351 draft-carpenter-solution-sirs-01 (work in progress), June 352 2003. 354 [IDTRACKER] 355 "The IETF Draft Tracker", Web Application: https:// 356 datatracker.ietf.org/. 358 [PROTO] "The IESG Process and Tools (PROTO) Team", Web Page: 359 http://psg.com/~mrw/PROTO-Team. 361 Author's Address 363 Henrik Levkowetz 364 ipUnplugged AB 365 Arenavagen 23 366 Stockholm S-121 28 367 SWEDEN 369 Phone: +46 708 32 16 08 370 EMail: henrik@levkowetz.com 372 Intellectual Property Statement 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org. 396 Disclaimer of Validity 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 401 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 402 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 403 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Copyright Statement 408 Copyright (C) The Internet Society (2004). This document is subject 409 to the rights, licenses and restrictions contained in BCP 78, and 410 except as set forth therein, the authors retain all their rights. 412 Acknowledgment 414 Funding for the RFC Editor function is currently provided by the 415 Internet Society.