idnits 2.17.1 draft-ietf-proto-wgchair-discuss-pilot-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 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 235), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 8 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 41 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 (February 2004) is 7368 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 211, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 218, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-klensin-process-july14-00 -- 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 (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Meyer 2 draft-ietf-proto-wgchair-discuss-pilot-00.txt 3 Category Informational 4 Expires: August 2004 February 2004 6 Pilot: Working Group Chair Followup of DISCUSS Comments 7 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of the Proto Team. Comments should be 31 addressed to the authors, or the mailing list at proto-team@ietf.org. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 As of this writing, many efforts aimed at streamlining various IETF 40 processes are underway. One such effort is the Process and Tools, or 41 PROTO Team. The PROTO Team is an IESG-driven activity focused on 42 improving the work flow of approval of documents, and the tools that 43 support this work flow. This document describes a pilot process 44 designed by the PROTO Team to streamline document flow by allowing 45 working group chairs to coordinate the resolution IESG DISCUSS 46 comments. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Pilot Description. . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Shepherding Working Group Chair (SWGC). . . . . . . . . . . 4 54 3.2. Pilot Internet Draft (PID). . . . . . . . . . . . . . . . . 4 55 4. Participants . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Pilot Process -- Details . . . . . . . . . . . . . . . . . . . 5 58 7. Pilot Termination and Evaluation . . . . . . . . . . . . . . . 7 59 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 12.1. Informative References . . . . . . . . . . . . . . . . . . 9 65 13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 10 66 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 10 67 15. Intellectual Property . . . . . . . . . . . . . . . . . . . . 10 68 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 As part of the currently ongoing effort to streamline various IETF 73 processes, the PROTO team [PROTO] has designed a set pilot projects 74 to test possible changes to current document flow processing. This 75 document describes a pilot project designed to allow working group 76 chairs to follow up on IESG DISCUSS [IDTRACKER] comments, and thereby 77 offload that function from shepherding Area Director (AD) and improve 78 process efficiency. Finally, see [KLENSIN] for one rationale 79 supporting piloting of process changes. 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. Pilot Description 87 This pilot is designed to allow a working group chair to follow up on 88 and resolve the DISCUSS comments for a given internet draft, and by 89 doing so increase the efficiency of the IETF document process flow. 90 The next section defines the terminology used throughout the 91 document, and remainder of the document describes the details of the 92 pilot. 94 3. Definitions 96 3.1. Shepherding Working Group Chair (SWGC) 98 The Shepherding Working Group Chair, or SWGC, is a working group 99 chair that has been selected by the appropriate AD(s) to participate 100 in the pilot described in this document. 102 3.2. Pilot Internet Draft (PID) 104 The Pilot Internet Draft, or PID, is an Internet draft which a 105 shepherding working group chair takes through the post-working group 106 last call stages of the approval and publication process. The 107 approval of the responsible Area Director is necessary to make an 108 Internet draft part of the pilot. 110 4. Participants 112 TBD 114 5. Duration 116 TBD 118 6. Pilot Process -- Details 120 In this section we detail the steps that a SWGC will take in 121 resolving the DISCUSS items against a given PID. The steps are given 122 below, in the order that they are to be executed. 124 (i). Immediately after the weekly IESG conference call, the 125 SWGC queries the ID tracker [IDTRACKER] to collect any 126 DISCUSS comments raised against the PID. 128 Note: The ID tracker is capable of sending email on 129 change of state. For the duration of the pilot, it 130 would be desirable for the tracker to send email to 131 the SWGC when the PID changes state to the AD 132 Followup, Revised ID Need, or Do Not Publish 133 states. If this is not possible, the SWGC will have 134 to query the tracker to determine if there are 135 DISCUSS comments. 137 (ii). The SWGC analyzes comments from the tracker, and 138 initializes contact with any AD's who have placed 139 comments (blocking or non-blocking) on a draft, notifying 140 them that the SWGC is the current document shepherd and 141 seeking any additional clarification necessary to 142 understand the comment. 144 +------+ Comments +--------+ Comments +-------+ 145 | (i) |-------------> | (ii) | -------------> | (iii) | 146 +------+ Collected +--------+ Understood +-------+ 147 /|\ | 148 | | Comments not fully understood 149 | | (Further AD/SWGC Discussion Required) 150 +----+ 152 (iii). The SWGC then coordinates DISCUSS comments, and builds a 153 a consistent interpretation the comments. This step may 154 required iteration with step (ii). above. That is: 156 +------+ Consistent +-------+ 157 | (ii) |----------------> | (iii) | 158 +------+ Interpretation +-------+ 159 /|\ | 160 | | Further AD/SWGC Discussion 161 | | Required 162 +--------------------------+ 164 (iv). The DISCUSS comments are then communicated to the working 165 group. 167 (v). After the author(s) resolve the issues provided by the 168 chair (the distilled DISCUSS issues), the SWGC reviews 169 the updated document to ensure that (in her/his option) 170 the DISCUSS issues have been resolved. 172 (vi). Finally, the SWGC prepares a summary of the resolution 173 including new document text and notifies the responsible 174 AD that the PID is ready to be reconsidered by the IESG. 176 7. Pilot Termination and Evaluation 178 TBD 180 8. Contributors 182 TBD 184 9. Acknowledgments 186 Aaron Falk made many insightful comments on early versions of this 187 document. 189 10. Security Considerations 191 This document specifies neither a protocol nor an operational 192 practice, and as such, it creates no new security considerations. 194 11. IANA Considerations 196 This document creates a no new requirements on IANA namespaces 197 [RFC2434]. 199 12. References 201 12.1. Informative References 203 [IDTRACKER] https://datatracker.ietf.org 205 [KLENSIN] Klensin, J. and S. Dawkins, "A model for IETF 206 Process Experiments", draft-klensin-process-july14-00.txt. 207 Work in progress. 209 [PROTO] http://psg.com/~mrw/PROTO-Team 211 [RFC2119] Bradner, S., "Key words for use in RFCs to 212 Indicate Requirement Levels", RFC 2119, March, 213 1997. 215 [RFC2026] Bradner, S., "The Internet Standards Process -- 216 Revision 3", RFC 2026/BCP 9, October, 1996. 218 [RFC2028] Hovey, R. and S. Bradner, "The Organizations 219 Involved in the IETF Standards Process", RFC 220 2028/BCP 11, October, 1996. 222 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 223 Writing an IANA Considerations Section in RFCs", 224 RFC 2434/BCP 26, October 1998. 226 13. Author's Address 228 D. Meyer 229 Email: dmm@1-4-5.net 231 14. Full Copyright Statement 233 Copyright (C) The Internet Society (2004). This document is subject 234 to the rights, licenses and restrictions contained in BCP 78 and 235 except as set forth therein, the authors retain all their rights. 237 This document and translations of it may be copied and furnished to 238 others, and derivative works that comment on or otherwise explain it 239 or assist in its implementation may be prepared, copied, published 240 and distributed, in whole or in part, without restriction of any 241 kind, provided that the above copyright notice and this paragraph are 242 included on all such copies and derivative works. However, this 243 document itself may not be modified in any way, such as by removing 244 the copyright notice or references to the Internet Society or other 245 Internet organizations, except as needed for the purpose of 246 developing Internet standards in which case the procedures for 247 copyrights defined in the Internet Standards process must be 248 followed, or as required to translate it into languages other than 249 English. 251 The limited permissions granted above are perpetual and will not be 252 revoked by the Internet Society or its successors or assigns. 254 This document and the information contained herein is provided on an 255 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 256 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 257 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 258 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 259 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 261 15. Intellectual Property 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use of 275 such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository at 277 http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at ietf- 283 ipr@ietf.org. 285 16. Acknowledgement 287 Funding for the RFC Editor function is currently provided by the 288 Internet Society.