idnits 2.17.1 draft-davies-structural-rev-process-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** 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 (September 03, 2003) is 7541 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 section? '4' on line 278 looks like a reference -- Missing reference section? '1' on line 267 looks like a reference -- Missing reference section? '2' on line 271 looks like a reference -- Missing reference section? '3' on line 275 looks like a reference -- Missing reference section? '10' on line 299 looks like a reference -- Missing reference section? '11' on line 304 looks like a reference -- Missing reference section? '9' on line 296 looks like a reference -- Missing reference section? '5' on line 284 looks like a reference -- Missing reference section? '8' on line 293 looks like a reference -- Missing reference section? '6' on line 287 looks like a reference -- Missing reference section? '7' on line 290 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Problem Statement E. Davies 3 Internet-Draft Nortel Networks 4 Expires: March 3, 2004 A. Doria 5 ETRI 6 J. Hofmann 7 Wissenschaftszentrum Berlin 8 September 03, 2003 10 IETF Structural Problems Improvement Process 11 draft-davies-structural-rev-process-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 3, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document suggests a possible process to address the 44 structural problems identified in the IETF Problem Statement as 45 requested in Version 02 of the IETF Problem Resolution draft. 47 The process proposes that the IESG delegate responsibility for 48 coordinating, moderating and synthesising proposals for solutions 49 to parts of the structural problems to a Synthsis and Action Panel 50 (SAP) selected through a variant of the nomcom selection process. 51 The SAP should, if possible, deliver an integrated set of 52 proposals for changes derived from community input, both 53 unsolicited and, if necessary, solicited. The SAP would act as a 54 moderator between authors of alternative propoasals in attempting 55 to achieve a proposal on which the community could agree. The 56 agreed plan be would be delivered to the IESG for final approval 57 and action. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. A Proposal for Changing the Structure and Practices of the 64 IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1 Constitution and Selection of the SAP . . . . . . . . . . . . 4 66 2.2 Initial List of Issues to be Considered . . . . . . . . . . . 5 67 2.3 Open Solicitation of Contributions to the Solution . . . . . . 5 68 2.4 Achieving an Integrated Solution . . . . . . . . . . . . . . . 6 69 2.5 Acceptance of the Integrated Solution . . . . . . . . . . . . 6 70 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 Normative References . . . . . . . . . . . . . . . . . . . . . 6 73 Informative References . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 75 Intellectual Property and Copyright Statements . . . . . . . . 9 77 1. Introduction 79 Version 02 of the Problem Resolution draft[4] solicited proposals 80 from the community for processes to resolve the more structural 81 problems identified in the Problem Issues draft[1]. This document 82 offers one possible process. 84 The process proposed requests the IESG to delegate responsibility 85 for identifying the changes that need to be made to rectify all or 86 most of the existing structural problems identified in [1] to a 87 Synthesis and Action Panel (SAP). The SAP would coordinate and 88 moderate between authors of community proposals for change in 89 order to synthesise an integrated plan of action leading to a 90 reinvigorated IETF. 92 1.1 Acknowledgements 94 The development of this proposal was assisted by Dave Crocker, and 95 Spencer Dawkins. 97 2. A Proposal for Changing the Structure and Practices of the IETF 99 A significant number of the issues that were identified in the 100 IETF Problem Statement appear to require alterations to the 101 structure of the IETF and/or the core practices which effectively 102 characterize the IETF. 104 The process documented in this section is designed to overcome the 105 objections that lead to the rejection of the working group process 106 which was proposed in earlier versions of the Problem Resolution 107 draft[4]. It is intended to produce, in a well-defined period of 108 time, 110 o a proposal for such structural changes to the IETF as the 111 community finds necessary to allow the various issues to be 112 resolved, together with 114 o a migration plan which will allow the IETF to transform itself 115 as painlessly as possible. 117 In outline the plan requires: 119 o Selection of a Synthesis and Action Panel (SAP) which will 120 moderate the process and own the final proposal for change 121 under the general oversight of the IESG. 123 o Generation of a list of issues that appear to require 124 attention, initially in this document, but subject to additions 125 by agreement of the SAP. 127 o Solicitation of contributions from individuals or groups of 128 IETF stakeholders which will address solutions to any part of 129 the problem space as described in the Problem Issues draft[1]. 131 o Moderation between contributors and synthesis of the resulting 132 contributions by the SAP in order to create a proposal which 133 appears to result in an organization which will, so far as is 134 possible, no longer suffer from the issues identified, and a 135 minimally disruptive changeover process. 137 o Acceptance of the proposal initially by as large a part of the 138 IETF community as possible through open discussion by email and 139 at plenary session(s), and finally by the existing IESG at the 140 time of completion. 142 The plan will be subject to a tight timetable, enforced by the SAP 143 with the backing of the IAB, IESG and ISOC that is intended to 144 deliver an accepted proposal at the second IETF meeting after the 145 inception of the SAP. 147 The following sections expand on the plan outline and give details 148 of the way in which the work should be carried out. 150 2.1 Constitution and Selection of the SAP 152 The SAP will comprise a number of members that is sufficiently low 153 so that the group is able to take decisions rapidly and 154 effectively. The members of the SAP (SAPs) will be selected to 155 represent the interests of as wide a range of the stakeholders in 156 the IETF as is possible. To this end one group of the SAPs will be 157 nominated by the existing management structures of the IETF (IESG, 158 IAB and ISOC) whilst the remainder will be selected through a 159 re-use of the latest nomcom selection process. 161 There will be eleven members of the SAP as follows: 163 o Two members of the current IESG nominated by the IESG. 165 o Two members of the current IAB nominated by the IAB. 167 o One member of the current ISOC Board nominated by the ISOC 168 Board. 170 o Six members selected by the same process as is used to select 171 the nomcom as described in RFC 2727[2] and RFC2777[3] but using 172 an extended eligibility period as is currently being suggested 173 by the nomcom working group in the revisions to RFC 2727[10] 174 and RFC 2777[11] (i.e. attendance at least 3 out of the 175 preceding 5 IETF meetings). 177 The SAP will elect its chair from amongst its members in the same 178 way as the IAB does at present. 180 We believe that is important that the full range of stakeholder 181 interests should be represented. To this end, we encourage people 182 from all parts of the community to put their names forward, so 183 that subject to the luck of the draw, there will be a true 184 diversity of views in the SAP. 186 2.2 Initial List of Issues to be Considered 188 The following issues taken from the problem statement document and 189 the analysis in [4]: 191 o The Mission Problem (Section 4.1 of [4], [9]), 193 o the Complex Problems problem (Section 4.3 of [4], [5], [8]), 195 o the Standards Hierarchy problem (Section 4.4 of [4], [6]), 197 o the Management Scaling problem (Section 4.6 of [4], [8], [5], 198 [2]), and 200 o The longer-term portions of the Engagement Problem (Section 4.5 201 of [4], [7]) 203 (Additional references on each item indicate associated documents 204 that may need to be updated as a result of this process). 206 The SAP will discuss this list and may add further issues if it is 207 deemed necessary. 209 2.3 Open Solicitation of Contributions to the Solution 211 The IESG will issue an invitation for proposals and actively 212 encourage people to contribute to the change process. Proposals 213 are solicited for both single items and comprehensive problems. 214 Individuals and groups are invited to participate. In addition the 215 SAP will approach people individually or as groups as tghey see 216 fit and ask for suggestions to address structural problems not 217 adequately covered by any other contributions. THE SAP will 218 publish all contributions in order to ensure transparency and to 219 allow people to get involved at each stage of the process. 221 2.4 Achieving an Integrated Solution 223 The SAP's chief task will be to generate an integrated proposal, 224 which includes solutions to all items of the issue list (if 225 possible) and a transition or migration plan. This task requires 226 moderating the communication between all contributors, 227 ascertaining consensus among contributors and producing a 228 synthesis of the various proposals. 230 2.5 Acceptance of the Integrated Solution 232 The SAP will publish the proposed integrated solution as widely as 233 possible. Since the IETF lacks an all-embracing forum which is 234 guaranteed to place the result in front of all all stakeholders, 235 various mailing lists and plenary meetings will be used for final 236 community input and to confirm the overall acceptance of the 237 proposed solutions. 239 After final modifications based on community feedback, the SAP 240 will send the proposed solutions to the IESG for implementation. 242 3. Conclusion 244 The IETF has problems, and we need to work to solve those 245 problems, both via focused immediate improvements and via an 246 integrated effort to build an IETF organizational structure and 247 develop processes that can better handle our current size and 248 complexity. 250 The proposed solicitation process and the Sythesis and Answer 251 Panel aims at including input of as many IETF members as possible 252 to the solution of the more structural problems of the IETF. At 253 the same time, the proposed solution process allows for faster 254 results than a regular working group. 256 4. Security Considerations 258 This document contains suggestions for processes that the IETF 259 could use to resolve process-related and organizational problems 260 with the IETF. Although the structure and quality of the IETF's 261 processes may have an affect on the quality of the IETF's 262 security- related work, there are no specific security-related 263 issues raised in this document. 265 Normative References 267 [1] Davies, E., Ed., "IETF Problem Statement", 268 draft-ietf-problem-issue-statement-02 (work in progress), Jun 269 2003. 271 [2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 272 Process: Operation of the Nominating and Recall Committees", 273 RFC 2727, Feb 2000. 275 [3] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", 276 RFC 2777, February 2000. 278 [4] Davies, E., Ed. and J. Hofmann, Ed., "IETF Problem Resolution 279 Processes", draft-ietf-problem-process-02 (work in progress), 280 August 2003. 282 Informative References 284 [5] Alvestrand, H., "An IESG charter", draft-iesg-charter-03 285 (work in progress), Apr 2003. 287 [6] Bradner, S., "The Internet Standards Process -- Revision 3", 288 RFC 2026, Oct 1996. 290 [7] Bradner, S., "IETF Working Group Guidelines and Procedures", 291 BCP 25, RFC 2418, September 1998. 293 [8] Carpenter, B., "Charter of the Internet Architecture Board 294 (IAB)", RFC 2850, May 2000. 296 [9] Harris, S., "The Tao of IETF - A Novice's Guide to the 297 Internet Engineering Task Force", RFC 3160, August 2001. 299 [10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and 300 Recall Process: Operation of the Nominating and Recall 301 Committees", draft-ietf-nomcom-rfc2727bis-07 (work in 302 progress), August 2003. 304 [11] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", 305 draft-eastlake-rfc2777bis-selection-02 (work in progress), 306 June 2003. 308 Authors' Addresses 310 Elwyn B. Davies 311 Nortel Networks 312 Harlow Laboratories 313 London Road 314 Harlow, Essex CM17 9NA 315 UK 317 Phone: +44 1279 405 498 318 EMail: elwynd@nortelnetworks.com 320 Avri Doria 321 ETRI 322 161 Gajeong-dong 323 Yuseong-gu 324 Daejeon 305-350 325 Korea 327 Phone: +82 16 9608 5024 328 EMail: avri@acm.org 330 Jeanette Hofmann 331 Wissenschaftszentrum Berlin 332 Reichpietschufer 50 333 Berlin 10785 334 Germany 336 Phone: +49 30 25491 288 337 EMail: jeanette@wz-berlin.de 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 intellectual property or other rights that might be claimed to 343 pertain to the implementation or use of the technology described 344 in this document or the extent to which any license under such 345 rights might or might not be available; neither does it represent 346 that it has made any effort to identify any such rights. 347 Information on the IETF's procedures with respect to rights in 348 standards-track and standards-related documentation can be found 349 in BCP-11. Copies of claims of rights made available for 350 publication and any assurances of licenses to be made available, 351 or the result of an attempt made to obtain a general license or 352 permission for the use of such proprietary rights by implementors 353 or users of this specification can be obtained from the IETF 354 Secretariat. 356 The IETF invites any interested party to bring to its attention 357 any copyrights, patents or patent applications, or other 358 proprietary rights which may cover technology that may be required 359 to practice this standard. Please address the information to the 360 IETF Executive Director. 362 Full Copyright Statement 364 Copyright (C) The Internet Society (2003). All Rights Reserved. 366 This document and translations of it may be copied and furnished 367 to others, and derivative works that comment on or otherwise 368 explain it or assist in its implementation may be prepared, 369 copied, published and distributed, in whole or in part, without 370 restriction of any kind, provided that the above copyright notice 371 and this paragraph are included on all such copies and derivative 372 works. However, this document itself may not be modified in any 373 way, such as by removing the copyright notice or references to the 374 Internet Society or other Internet organizations, except as needed 375 for the purpose of developing Internet standards in which case the 376 procedures for copyrights defined in the Internet Standards 377 process must be followed, or as required to translate it into 378 languages other than English. 380 The limited permissions granted above are perpetual and will not 381 be revoked by the Internet Society or its successors or assignees. 383 This document and the information contained herein is provided on 384 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 385 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 386 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Acknowledgement 392 Funding for the RFC Editor function is currently provided by the 393 Internet Society.