idnits 2.17.1 draft-ietf-proto-wgchair-discuss-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 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 274), 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 2 instances of too long lines in the document, the longest one being 5 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 == Line 42 has weird spacing: '...focused on...' -- 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 247, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IDTRACKER' -- Possible downref: Normative reference to a draft: ref. 'MANKIN' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Meyer 3 draft-ietf-proto-wgchair-discuss-pilot-02.txt 4 Category Informational 5 Expires: October 2004 April 2004 7 Pilot: Working Group Chair Followup of DISCUSS Comments 8 10 Status of this Document 12 This document is an Internet-Draft and is subject to all provisions 13 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/1id-abstracts.html 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 WG. 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 As of this writing, many efforts aimed at streamlining various IETF 41 processes are underway. One such effort is the Process and Tools, or 42 PROTO Team. The PROTO Team is an IESG-driven activity focused on 43 improving the work flow of approval of documents, and the tools that 44 support this work flow. This document describes a pilot process 45 designed by the PROTO Team to streamline document flow by allowing 46 working group chairs to coordinate the resolution IESG DISCUSS 47 comments. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Pilot Description. . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Shepherding . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Shepherding Working Group Chair (SWGC). . . . . . . . . . . 4 56 3.3. Pilot Internet Draft (PID). . . . . . . . . . . . . . . . . 5 57 3.4. Responsible AD. . . . . . . . . . . . . . . . . . . . . . . 5 58 3.5. DISCUSSing AD . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Participants . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Pilot Process -- Details . . . . . . . . . . . . . . . . . . . 6 62 7. Pilot Termination and Evaluation . . . . . . . . . . . . . . . 7 63 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 8 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 11 71 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 11 72 15. Intellectual Property . . . . . . . . . . . . . . . . . . . . 11 73 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 As part of the ongoing effort to streamline various IETF processes, 78 the PROTO team [PROTO] has designed a set of pilot projects to test 79 possible changes to current document flow processing. This document 80 describes a pilot project designed to allow working group chairs to 81 follow up on IESG DISCUSS [IDTRACKER] comments, and thereby offload 82 that function from shepherding Area Director (AD) and improve process 83 efficiency. Finally, [KLENSIN] describes the rationale for 84 supporting piloting of process changes. 86 2. Pilot Description 88 This pilot is designed to allow a working group chair to follow up on 89 and resolve the DISCUSS comments for a given internet draft, and by 90 doing so increase the efficiency of the IETF document process flow. 91 The next section defines the terminology used throughout the 92 document, and remainder of the document describes the details of the 93 pilot. 95 3. Definitions 97 3.1. Shepherding 99 [MANKIN] defines the basic concept of document shepherding as 101 "...a single person (an AD currently) to take responsibility 102 for a document from the time the WG Chair(s) requests the IESG 103 to publish it to the time that it is given final edits by the 104 RFC Editor. The motivation is for the shepherd to provide 105 needed coordination." 107 3.2. Shepherding Working Group Chair (SWGC) 109 The Shepherding Working Group Chair, or SWGC, is a working group 110 chair that has been selected by the appropriate AD(s) to participate 111 in the pilot described in this document. Note that the Working Group 112 Secretary (if such exists) may also serve as the SWGC. 114 3.3. Pilot Internet Draft (PID) 116 The Pilot Internet Draft, or PID, is an Internet draft which a 117 shepherding working group chair takes through the post-working group 118 last call stages of the approval and publication process. The 119 approval of the responsible Area Director is necessary to make an 120 Internet draft part of the pilot. 122 3.4. Responsible AD 124 The responsible AD is the Area Director who is responsible for the 125 draft. 127 3.5. DISCUSSing AD 129 The DISCUSSing AD is the Area Director who has raised the DISCUSS 130 comments (as documented in the ID Tracker). 132 4. Participants 134 TBD 136 5. Duration 138 TBD 140 6. Pilot Process -- Details 142 In this section we detail the steps that a SWGC will take in 143 resolving the DISCUSS items against a given PID. The steps are given 144 below, in the order that they are to be executed. 146 (i). Immediately after the weekly IESG conference call, the 147 SWGC queries the ID tracker [IDTRACKER] to collect any 148 DISCUSS comments raised against the PID. In order to 149 accomplish this, the SWGC's email address must be added 150 to the "State Change Notice To:" field in the ID tracker. 151 This will result in an email to the SWGC when the 152 document is moved from the "IESG Evaluation" state to 153 the "IESG Evaluation/New ID Needed state", which occurs 154 after the IESG teleconference. This notification indicates 155 to the the SWGC that, for most past, the all of the 156 DISCUSS comments have been registered. 158 Note that there may be exceptional cases when DISCUSS 159 comments are registered after the IESG teleconference. 160 In these cases, the DISCUSSing AD should notify the SWGC 161 that new comments have been entered. 163 (ii). The SWGC analyzes comments from the tracker, and 164 initializes contact with any AD's who have placed 165 comments (blocking or non-blocking) on a draft, 166 notifying them that the SWGC is the current document 167 shepherd and seeking any additional clarification 168 necessary to understand the comment. Note that the 169 responsible AD must copied on this correspondence. 171 +------+ Comments +--------+ Comments +-------+ 172 | (i) |-------------> | (ii) | -------------> | (iii) | 173 +------+ Collected +--------+ Understood +-------+ 174 /|\ | 175 | | Comments not fully understood 176 | | (Further AD/SWGC Discussion 177 | | Required) 178 +----+ 180 (iii). The SWGC then coordinates DISCUSS comments, and builds a 181 a consistent interpretation the comments. This step may 182 required iteration with step (ii). above. That is: 184 +------+ Consistent +-------+ 185 | (ii) |----------------> | (iii) | 186 +------+ Interpretation +-------+ 187 /|\ | 188 | | Further AD/SWGC Discussion 189 | | Required 190 +--------------------------+ 192 (vi). The SWGC communicates the resolution-so-far to the 193 responsible AD and the DISCUSSing AD(s). 195 (vii). DISCUSSing AD removes DISCUSS comment, or tells the WG 196 why the comment is not resolved. 198 If the DISCUSS comment in question was not resolved to 199 the satisfaction of the DISCUSSing and responsible ADs, 200 two possibilities exist: 202 (a). The process returns to step (iii), or 204 (b). The working group can appeal in accordance with the 205 procedures described in RFC 2418 [RFC2418]. 207 Otherwise, the process continues with step (viii). 209 (viii). The responsible AD moves document to APPROVED state, or 210 sends it back to the IESG for re-review (if the changes 211 are deemed significant). 213 7. Pilot Termination and Evaluation 215 TBD 217 8. Contributors 219 TBD 221 9. Acknowledgments 223 Harald Alvestrand, Brian Carpenter, Aaron Falk and Pekka Savola made 224 many insightful comments on early versions of this document. 226 10. Security Considerations 228 This document specifies neither a protocol nor an operational 229 practice, and as such, it creates no new security considerations. 231 11. IANA Considerations 233 This document creates a no new requirements on IANA namespaces 234 [RFC2434]. 236 12. References 238 12.1. Normative References 240 [IDTRACKER] https://datatracker.ietf.org 242 [MANKIN] Mankin, A., "A Not So Wild Sheep Chase - 243 Definition of Shepherding", 244 draft-ietf-proto-shepherding-00.txt. Work in 245 Progress. 247 [RFC2026] Bradner, S., "The Internet Standards Process -- 248 Revision 3", BCP 9, RFC 2026, October, 1996. 250 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 251 Procedures", BCP 25, RFC 2418, September 1998. 253 12.2. Informative References 255 [KLENSIN] Klensin, J. and S. Dawkins, "A model for IETF 256 Process Experiments", draft-klensin-process-july14-02.txt. 257 Work in progress. 259 [PROTO] http://psg.com/~mrw/PROTO-Team 261 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 262 Writing an IANA Considerations Section in RFCs", 263 RFC 2434/BCP 26, October 1998. 265 13. Author's Address 267 D. Meyer 268 Email: dmm@1-4-5.net 270 14. Full Copyright Statement 272 Copyright (C) The Internet Society (2004). This document is subject 273 to the rights, licenses and restrictions contained in BCP 78 and 274 except as set forth therein, the authors retain all their rights. 276 This document and translations of it may be copied and furnished to 277 others, and derivative works that comment on or otherwise explain it 278 or assist in its implementation may be prepared, copied, published 279 and distributed, in whole or in part, without restriction of any 280 kind, provided that the above copyright notice and this paragraph are 281 included on all such copies and derivative works. However, this 282 document itself may not be modified in any way, such as by removing 283 the copyright notice or references to the Internet Society or other 284 Internet organizations, except as needed for the purpose of 285 developing Internet standards in which case the procedures for 286 copyrights defined in the Internet Standards process must be 287 followed, or as required to translate it into languages other than 288 English. 290 The limited permissions granted above are perpetual and will not be 291 revoked by the Internet Society or its successors or assigns. 293 This document and the information contained herein is provided on an 294 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 295 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 296 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 297 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 298 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 15. Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at ietf- 322 ipr@ietf.org. 324 16. Acknowledgement 326 Funding for the RFC Editor function is currently provided by the 327 Internet Society.