idnits 2.17.1 draft-davies-pesci-next-steps-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 254. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 13, 2006) is 6526 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) == Outdated reference: A later version (-05) exists of draft-carpenter-procdoc-roadmap-04 == Outdated reference: A later version (-03) exists of draft-davies-pesci-initial-considerations-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Davies, Ed. 3 Internet-Draft Folly Consulting 4 Expires: December 15, 2006 June 13, 2006 6 Organizing IETF Process Change 7 draft-davies-pesci-next-steps-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 27 http://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 December 15, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document sets out a strawman proposal for how to organize the 41 revision and update of any part of the Internet Engineering Task 42 Force (IETF) processes including those for developing standards and 43 other specifications. It does not propose specific changes to any of 44 these processes, which should be the subject of future documents. 45 However, it does propose an initial target area for process change. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. About This Document . . . . . . . . . . . . . . . . . . . . 3 51 2. A Template for Process Change Organization . . . . . . . . . . 3 52 2.1. Change Process Proposal . . . . . . . . . . . . . . . . . . 4 53 3. Immediate Tasks for the Change Process . . . . . . . . . . . . 4 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 57 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Introduction 63 In a previous document [I-D.davies-pesci-initial-considerations] a 64 design team selected by the IETF Chair suggested some goals and 65 guidelines that should be followed in setting out to change any of 66 the processes used in the IETF. In the light of the design team's 67 experience, this document suggests a possible way of organizing such 68 process change work and also identifies a target area as the initial 69 focus for process change to address the problems that were summarized 70 in [I-D.davies-pesci-initial-considerations]. 72 [I-D.davies-pesci-initial-considerations] also contains a extensive 73 reading list of background material which documents many of the 74 processes which might be the subject of change through the process 75 suggested in this document. One problem that has been identified is 76 that this material has been built up piecemeal over the lifetime of 77 the IETF and it is neither entirely self-consistent nor easy to 78 navigate even for experienced IETF participants. An overview and 79 guide to the existing and draft material has been developed 80 [I-D.carpenter-procdoc-roadmap] as an interim measure. 82 1.1. About This Document 84 This document was produced by the PESCI design team selected by the 85 IETF Chair and is published here as a record of discussion. PESCI 86 stands for Process Evolution Committee of the IETF and is in the 87 IETF's naming tradition as a successor of the earlier POISSON working 88 group. The membership of the design team is listed in the 89 Acknowledgements. PESCI had no special status in the IETF process; 90 it was simply the group of people who produced this document under 91 the leadership of the IETF Chair. 93 Discussion of this draft is welcomed on the pesci-discuss@ietf.org 94 list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss). 96 2. A Template for Process Change Organization 98 The PESCI design team is proposing a process for developing changes 99 to the IETF processes especially in the area of developing standards 100 documentation and other specifications. It is intended that this 101 should be a template for any future change process that appears to be 102 required, but in the best traditions of the IETF the process should 103 itself be tested by experiment and modified if it is found wanting. 105 This proposed new process 106 o would be used by all individuals, design teams, and working groups 107 who wish to propose changes or additions to IETF processes, 108 o should involve consultation with the IESG, the IAB, the IAOC, the 109 Working Group chairs, and IETF participants generally, but 110 o must avoid requiring the IESG to develop the new processes or 111 micromanage this process of development and approval. 113 The new proposals, both for the change process and any resulting 114 changed processes, should be implemented as a matter of urgency and 115 should be handled expeditiously by the existing approvals and 116 publishing process. 118 2.1. Change Process Proposal 120 We propose that the design team model is the most effective way of 121 engineering process changes. The design team is a tried-and-tested 122 IETF methodology especially suitable for creating concrete solutions 123 applicable to constrained problems. Within the context of the 124 existing IETF process, the model would be applied by constituting a 125 set of design teams with appropriate oversight and the charter of 126 carrying out process change. The design teams would operate within 127 these charters: the overseers would invite design team members to 128 participate, but alternative teams could offer solutions if they feel 129 they have better solutions. 131 The teams should function with an open discussion list, in the same 132 way that the PESCI team has done. The output of each team should be 133 tested against the IETF consensus in the normal fashion; we believe 134 that if there is clear IETF consensus that the proposal makes sense, 135 the IESG (and the ISOC Board of Trustees) will respect that consensus 136 and approve of it. 138 3. Immediate Tasks for the Change Process 140 Assuming that the model suggested in Section 2.1 is adopted, the 141 following process change task appears to be the most urgent one, and 142 a team should start on this as soon as possible. 144 The most important single management role in the IETF at the moment 145 is that of the IESG, including the role of IETF Chair. This should 146 therefore also receive the most scrutiny. It's unreasonable to ask 147 people to grade their own performance, or to attempt to perform a 148 role at full speed while having to review how it could be done 149 otherwise. Therefore, a review of the roles the IESG has should be 150 rooted outside the IESG - while asking current and former IESG 151 members for information and advice at every opportunity. 153 This review should include: 155 o Creating a list of the tasks that currently gate on the IESG 156 o Identifying any additional related tasks that might be appropriate 157 to improve efficiency and effectiveness 158 o Making proposals for discarding or restructuring the existing 159 tasks in combination with the new tasks 160 o Making a proposal for grouping those tasks into separate task 161 groups that can be assigned to different bodies at need. 162 o Developing a proposal for how the standards development work of 163 the IETF should be partitioned to provide optimum efficiency while 164 allowing the IETF to take on all appropriate work. 165 o Developing a suggestion for an initial set of bodies for handling 166 those tasks in the new work partitioning scheme, including, if 167 appropriate, a restructuring of the IESG. 168 o Describing the process by which the set of bodies gets modified. 169 o Describing how members of the proposed bodies get selected, 170 replaced, and (if needed) removed. 171 o Proposing a structure for the documentation of the IETF process 172 that would result from their recommendations 174 4. Security Considerations 176 This document has no direct impact on the security of the Internet. 177 However, a smooth and efficient IETF process is necessary to deal 178 rapidly with emerging security threats. Also, a badly designed 179 process may be subject to social denial of service attacks that could 180 damage both the IETF and indirectly the Internet itself. We should 181 also note that the change process (and the evaluation of potential 182 change) is itself vulnerable to social DoS. 184 5. IANA Considerations 186 This document does not require action by the IANA. However, IANA 187 activities do form part of the IETF process and process changes may 188 affect IANA. 190 6. Acknowledgements 192 The members of the PESCI team at the time this document was written 193 were: 195 Harald Alvestrand 196 Scott Brim 197 Brian Carpenter 198 Elwyn Davies 199 Adrian Farrel 200 Michael Richardson 202 This document was produced using the xml2rfc tool [RFC2629] and 203 edited with the xxe editor plug-in. 205 7. Informative References 207 [I-D.carpenter-procdoc-roadmap] 208 Carpenter, B., "The IETF Process: a Roadmap", 209 draft-carpenter-procdoc-roadmap-04 (work in progress), 210 February 2006. 212 [I-D.davies-pesci-initial-considerations] 213 Davies, E., "Moving Forwards with IETF Process Evolution", 214 draft-davies-pesci-initial-considerations-01 (work in 215 progress), January 2006. 217 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 218 June 1999. 220 Author's Address 222 Elwyn Davies (editor) 223 Folly Consulting 224 Soham, 225 UK 227 Phone: +44 7889 488 335 228 Fax: 229 Email: elwynd@dial.pipex.com 230 URI: 232 Intellectual Property Statement 234 The IETF takes no position regarding the validity or scope of any 235 Intellectual Property Rights or other rights that might be claimed to 236 pertain to the implementation or use of the technology described in 237 this document or the extent to which any license under such rights 238 might or might not be available; nor does it represent that it has 239 made any independent effort to identify any such rights. Information 240 on the procedures with respect to rights in RFC documents can be 241 found in BCP 78 and BCP 79. 243 Copies of IPR disclosures made to the IETF Secretariat and any 244 assurances of licenses to be made available, or the result of an 245 attempt made to obtain a general license or permission for the use of 246 such proprietary rights by implementers or users of this 247 specification can be obtained from the IETF on-line IPR repository at 248 http://www.ietf.org/ipr. 250 The IETF invites any interested party to bring to its attention any 251 copyrights, patents or patent applications, or other proprietary 252 rights that may cover technology that may be required to implement 253 this standard. Please address the information to the IETF at 254 ietf-ipr@ietf.org. 256 Disclaimer of Validity 258 This document and the information contained herein are provided on an 259 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 260 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 261 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 262 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 263 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 264 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 266 Copyright Statement 268 Copyright (C) The Internet Society (2006). This document is subject 269 to the rights, licenses and restrictions contained in BCP 78, and 270 except as set forth therein, the authors retain all their rights. 272 Acknowledgment 274 Funding for the RFC Editor function is currently provided by the 275 Internet Society.