idnits 2.17.1 draft-davies-pesci-initial-considerations-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. ** 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 issues found here. 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 (October 23, 2006) is 6366 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 13 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 Intended status: Informational October 23, 2006 5 Expires: April 26, 2007 7 Moving Forwards with IETF Process Evolution 8 draft-davies-pesci-initial-considerations-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document provides a summary of previously identified problems 42 with the Internet Engineering Task Force (IETF) process for 43 developing standards and other specifications; and then identifies a 44 set of goals to aim at, and guidelines that should be followed during 45 any activity seeking to revise and update this process. It does not 46 propose specific changes to the process, which should be the subject 47 of future documents. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Guidelines and Goals . . . . . . . . . . . . . . . . . . . 3 53 1.2. Principles, Policy, Process and Procedure . . . . . . . . 3 54 1.3. About This Document . . . . . . . . . . . . . . . . . . . 5 55 2. Background reading . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Short problem analysis . . . . . . . . . . . . . . . . . . . . 6 57 4. Goals and Guidelines for IETF Process Change Activities . . . 7 58 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. Guidelines for Process Change Activities . . . . . . . . . 8 60 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 65 Appendix A. PESCI Announcement . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 15 69 1. Introduction 71 This document provides a summary of previously identified problems 72 with the Internet Engineering Task Force (IETF) process for 73 developing standards and other specifications (referred to as the 74 IETF standards development process in this document); and then 75 identifies a set of goals to aim at, and guidelines that should be 76 followed during any activity seeking to revise and update this 77 process. It also provides a reading list of the diverse material 78 that currently defines and discusses the various parts of this 79 process. It does not propose specific changes to the process, which 80 should be the subject of future documents. It has been produced by a 81 design team (the PESCI design team) selected by the IETF Chair and is 82 submitted to the IETF community for discussion. 84 The IETF almost continually debates its own process and this is in 85 many ways a healthy sign of its openness. However, the debate is 86 often inconclusive. The goals and guidelines set out in this 87 document represent an application of the IETF's Principles on 88 specification development and decision making appropriate to making 89 changes to the IETF standards development process. 91 1.1. Guidelines and Goals 93 The IETF has previously come to the conclusion that the IETF 94 standards development process suffers from a number of problems as 95 summarized in Section 3. In defining an activity to improve the IETF 96 standards development process, the activity needs to have a clear 97 goal or goals in ameliorating some part of these problems. Besides 98 the basic goal of process improvement, the activity should also aim 99 at a number of general goals applicable to the way in which the 100 improvement is defined and implemented. Because it is an IETF 101 activity, the activity itself and its results should follow the 102 general principles and policies which underlie the operation of the 103 IETF. Although the IETF has a Mission Statement [RFC3935], the 104 principles on which the IETF operates are mostly part of the 105 unwritten lore of the organization, and the PESCI design team created 106 a set of principles out of their collective experience of the way in 107 which the IETF operates. This set has been used to inform the 108 creation of a set of goals and guidelines applicable to any activity 109 which seeks to improve the IETF standards development process: 110 Section 4, which documents this set of goals and guidelines, provides 111 the results of this work. 113 1.2. Principles, Policy, Process and Procedure 115 Before going on to discuss process problems and guidelines for change 116 activities we should be clear about what we mean by "process", and 117 some of the other "P" words which will be used in the document. 119 Principles A set of statements that sets out how the IETF will 120 approach its work and carry out its mission. 121 Collectively they set the organization's ethos. These 122 include such things as requiring that development of 123 documents and organizational matters are as far as 124 possible open with "rough consensus and running code" as 125 an operating principle. When the PESCI design team 126 started work no such set of statements existed, and the 127 team created a set based on their collective 128 understanding of how the IETF functions. These 129 statements are not incorporated in this document but may 130 be published separately, possibly as part of a revision 131 of the Tao of the Internet. 133 Policy An agreement on what the IETF sets out to accomplish. At 134 the highest level this is incorporated in the IETF 135 Mission Statement[RFC3935]. This is refined in the 136 "constitutions" (usually known as "charters" in the IETF) 137 for the various component bodies which provide the 138 organisation of the IETF (listed in Section 2), but these 139 documents are not confined to policy matters. Overall 140 IETF policy and the constitutions of the bodies are 141 adopted by establishing strong IETF consensus. 143 Process Descriptions of the methods and mechanisms by which the 144 IETF works. These must be visible to all the IETF 145 participants; core pieces of the existing process are 146 contained in the IESG charter and the IAB charter 147 together with the definition of the IETF Standards Track 148 in [RFC2026]. Additions or modifications to IETF 149 processes are verified by establishing an IETF (rough) 150 consensus, but normally, the specification of the process 151 should be developed under the aegis of the body or bodies 152 that will oversee the operation of the process. 154 The process category covers area descriptions, large 155 proportions of the material in RFC2026 and the mechanisms 156 used to handle Intellectual Property Rights (IPR) 157 disclosures [RFC3979], as well as (for instance) the IAB 158 document on liaisons [RFC4053]. 160 Procedures The "nuts and bolts" of the execution of the process. 161 The I-D tracker, the tools team work, the liaison 162 statements document - even the IPR trust agreement - 163 belong in this category. 165 Procedures are normally developed by the people doing the 166 work, and documented and published as these bodies feel 167 it appropriate. 169 1.3. About This Document 171 This document was produced by the PESCI design team selected by the 172 IETF Chair and is published here as a record of discussion. PESCI 173 stands for Process Evolution Committee of the IETF and is in the 174 IETF's naming tradition as a successor of the earlier POISSON working 175 group. The membership of the design team is listed in the 176 Acknowledgements and the original announcement of PESCI is given as 177 an Appendix. PESCI had no special status in the IETF process; it was 178 simply the group of people who produced this document under the 179 leadership of the IETF Chair. 181 2. Background reading 183 The primary objective of the IETF process is to support the IETF 184 Mission Statement, [RFC3935]. Readers should be familiar with that 185 document. 187 The early phase of the current round of process discussions led to a 188 problem statement [RFC3774]. A general overview of current and draft 189 process documents can be found in [I-D.carpenter-procdoc-roadmap]. 190 At the time of writing, two process related working groups exist: 191 newtrk (New IETF Standards Track Discussion) and ipr (Intellectual 192 Property Rights). Their charters, mailing lists, etc., may be found 193 via http://www.ietf.org/html.charters/wg-dir.html#General%20Area. 195 The organisations involved in the IETF standards process are 196 discussed in [RFC2028]. Information about the constitutions, 197 purposes, and policy of the main IETF bodies involved in these 198 processes can be found in: 199 o The Internet Architecture Board(IAB) Charter[RFC2850] 200 o The Internet Engineering Steering Group (IESG) Charter[RFC3710] 201 o The Nominating and Recall Committee (NOMCOM)[RFC3777] 202 o Request For Comments (RFC) Editor: See the RFC Editor web pages 203 including RFC Editor Purpose description 204 (http://www.rfc-editor.org/DOCUMENTS/purpose.html) and some 205 procedures in [RFC3932] 206 o The memorandum of understanding under which the Internet Assigned 207 Numbers Authority (IANA)) operates is in [RFC2860]; the processes 208 and procedures as they affect IETF relationships to IANA are 209 currently under discussion and will be the subject of the 210 "techspec" BOF in November 2005 (see Section 3). 212 o The mission of the Internet Research Task Force (IRTF) is 213 described on its web page (http://www.irtf.org/), and the policies 214 and procedures for the IRTF are in [RFC2014] 215 o Liaisons with external bodies are conducted through the IAB (see 216 [RFC4052] and [RFC4053]) 218 In the last two years or so, a major effort has been made to update 219 the IETF's administrative structure, creating the IAOC, the IETF 220 Administrative Support Activity (IASA), and appointing the IETF 221 Administrative Director (IAD) (see [RFC4071] for details of these 222 bodies). This should not be confused with process change, although 223 its goal is to improve support for the process. Additionally, the 224 former and present IETF Chairs, and the IESG have taken steps to 225 improve procedures and their transparency. The Tools team and the 226 Education team are busy, many improvements have been made in details 227 of IESG document processing and shepherding, and the IESG has made a 228 number of efforts to improve the transparency of its discussions. 229 Such efforts are valuable, but orthogonal to process change as such. 230 However, they are part of the response to the problem statement 231 [RFC3774]. 233 3. Short problem analysis 235 The PESCI team reviewed earlier [RFC3774] and recent discussion of 236 IETF process problems. This generated the following list of problems 237 that seem to affect the development of standards and other 238 specifications (following the remit of the design team described in 239 Section 1) and that appear to be potentially soluble. 241 1. Timeliness of IETF output 242 2. Lack of clarity about authority and delegation 243 3. Variable quality of output from WGs 244 * At least 30% of drafts attract IESG "DISCUSS" comments even 245 after IETF Last Call. 246 * Unsolved issue of adequate cross-area review earlier in the 247 process. 248 4. IESG overload, which leads to subsidiary problems 249 * bottleneck effect 250 * too little steering 251 * perception issues and them/us mentality 252 * burnout 253 * potential lack of candidates 254 5. Lack of a "career path" for IESG members - "dropped in, 255 overworked and chopped off" 256 * there is no form of apprenticeship for Area Directors (ADs) 257 * ADs are trained "on the job" leading to lower effectiveness 258 early in their terms 259 * lack of any sort of formal recognition or role for "emeritus" 260 ADs 261 * potential to lose both experience and capability of ex-ADs 262 6. Binary nature of appeal/recall process 263 * there is a disincentive to "go nuclear" leading to festering 264 problems 265 * appeals are very time consuming for IESG (and maybe also for 266 IAB) 267 * the IESG judge and jury problem for process issues 268 7. Difficulties which the IETF has in dealing with complex problems 269 (architectural issues are hard to handle in the current IESG/ 270 area/working group structure) 271 8. Failures to follow through on the standards advancement process, 272 generally poor maintenance of standards and slow progress of 273 standards 274 Newtrk issues are in scope for the process change but we should 275 allow Newtrk to work - there maybe some opportunities to provide 276 input to newtrk through the principles we propose here. 277 9. Authority and decision mechanisms for parameter assignments 278 (IANA considerations). 279 10. Lack of a coherent set of documents defining the IETF processes. 281 Issues that are to be considered under the "techspec" banner are out 282 of scope for PESCI. The scope of techspec includes resolving 283 concerns regarding lack of visibility into RFC Editor state, copy- 284 editing, and excessive author changes in AUTH48. There was a 285 techspec BOF at IETF 64 in Vancouver. (see discussion list archive at 286 http://www1.ietf.org/mail-archive/web/techspec/current/). 288 IPR issues have their own WG (ipr) and have been thoroughly reviewed. 290 4. Goals and Guidelines for IETF Process Change Activities 292 This section lists specific goals and guidelines for any activity 293 seeking to change the IETF standards development process. An effort 294 has been made to write these very briefly and in self-explanatory 295 words. Many existing documents, including [RFC3774] and those cited 296 in [I-D.carpenter-procdoc-roadmap], have been consulted, as well as 297 recent mailing list discussions and private communications. An 298 intermediate output was a set of IETF Principles that is not 299 reproduced here but may be published separately. 301 4.1. Goals 303 Any activity which seeks to change the IETF standards development 304 process needs to have a well-defined aim of ameliorating some part of 305 the problems set out in Section 3 or identified subsequently. The 306 activity should also aim to satisfy a number of goals identified here 307 that should allow the changes to provide maximum improvement with 308 minimum disruption. 310 When designing new processes, it should be borne in mind that process 311 changes that require major structural changes within the IETF may 312 have wide-scale impact on the operation of the IETF: evolutionary 313 change may be more effective than revolutionary change. 314 G1. Ameliorate a well-defined part of the process problem space. 315 G2. Preserve those parts of the process that work reasonably well 316 today, unless they block other necessary changes. 317 G3. Make changes that seem certain to improve those parts of the 318 process that work less well. 319 G4. Avoid changes that would require unrealistic resources or 320 behaviours. 321 G5. Protect the continuity of ongoing IETF work. 322 G6. As far as possible, minimize simultaneous changes that may 323 interfere with each other. 324 G7. Avoid "thrashing" by repeated changes in the same area. 325 G8. Try to explicitly estimate the impact of changes before making 326 them, and try to measure whether the expectations were met after 327 making the change. 328 G9. Acknowledge that some refinement of the initial proposals may be 329 needed after trials. To this end try to work expeditiously to 330 provide a nearly right solution that delivers most of the gains 331 rather than refining the solutions endlessly before any 332 implementation (in line with the IETF's usual way of developing 333 standards). 335 4.2. Guidelines for Process Change Activities 337 Any activity for developing, approving and implementing changes to 338 IETF standards development process needs to operate in line with the 339 general principles of the IETF. This section presents a number of 340 guidelines developed from these principles that should apply to any 341 such activity. They deal with how any proposed changes to the IETF 342 processes for developing standards and other specifications should be 343 developed and authorized by the IETF community. These guidelines 344 appear to be broadly in line with our current process for development 345 activities, and similar principles should be true of any future 346 process. 348 P1. Changes to the IETF process must themselves be agreed by an open 349 process approved by the IETF community. 350 P2. The process for developing and agreeing these changed processes 351 must itself be the subject of IETF rough consensus. 352 P3. The development process must incorporate taking advice from 353 * the IESG, the IAB, the IAOC, and the Working Group chairs 354 * legal advisors 355 P4. When the proposed changes have been fully documented, "buy-in" 356 or more formal assent to the changed processes needs to be 357 obtained as follows: 358 * Any negative comments from the Working Group chairs must be 359 seriously considered. 360 * Formal consent must be obtained from the IESG, the IAB, and 361 the IAOC. 362 * Acceptance must be obtained from the ISOC board. 363 P5. The development and authorisation of the changed processes must 364 ensure that the IESG is not required itself to develop the new 365 processes. 367 5. Next Steps 369 The remit of the PESCI design team did not extend to determining what 370 IETF standards development process activities should be undertaken. 371 However the team encourages members of the community to produce 372 proposals for such activities in line with the above goals and 373 guidelines. 375 6. Security Considerations 377 This document has no direct impact on the security of the Internet. 378 However, a smooth and efficient IETF process is necessary to deal 379 rapidly with emerging security threats. Also, a badly designed 380 process may be subject to social denial of service attacks that could 381 damage both the IETF and indirectly the Internet itself. We should 382 also note that the change process (and the evaluation of potential 383 change) is itself vulnerable to social DoS. 385 7. IANA Considerations 387 This document does not require action by the IANA. However, IANA 388 activities do form part of the IETF process and process changes may 389 affect IANA. 391 8. Acknowledgements 393 The members of the PESCI team at the time this document was written 394 were: 396 Harald Alvestrand 397 Scott Brim 398 Brian Carpenter 399 Elwyn Davies 400 Adrian Farrel 401 Michael Richardson 403 This document was produced using the xml2rfc tool[RFC2629] and edited 404 with the xxe editor plug-in. 406 9. Informative References 408 [I-D.carpenter-procdoc-roadmap] 409 Carpenter, B., "The IETF Process: an Informal Guide", 410 draft-carpenter-procdoc-roadmap-05 (work in progress), 411 August 2006. 413 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 414 and Procedures", BCP 8, RFC 2014, October 1996. 416 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 417 3", BCP 9, RFC 2026, October 1996. 419 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 420 the IETF Standards Process", BCP 11, RFC 2028, 421 October 1996. 423 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 424 June 1999. 426 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 427 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 428 May 2000. 430 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 431 Understanding Concerning the Technical Work of the 432 Internet Assigned Numbers Authority", RFC 2860, June 2000. 434 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, 435 February 2004. 437 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 439 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 440 Recall Process: Operation of the Nominating and Recall 441 Committees", BCP 10, RFC 3777, June 2004. 443 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 444 Procedures", BCP 92, RFC 3932, October 2004. 446 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 447 BCP 95, RFC 3935, October 2004. 449 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 450 Technology", BCP 79, RFC 3979, March 2005. 452 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 453 for Management of IETF Liaison Relationships", BCP 102, 454 RFC 4052, April 2005. 456 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 457 Handling Liaison Statements to and from the IETF", 458 BCP 103, RFC 4053, April 2005. 460 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 461 Administrative Support Activity (IASA)", BCP 101, 462 RFC 4071, April 2005. 464 Appendix A. PESCI Announcement 466 To: IETF Announcement list 467 From: IETF Chair 468 Date: Fri, 16 Sep 2005 11:21:18 -0400 469 Subject: IETF Process Evolution 471 There has been quite a bit of community discussion of IETF process 472 change in recent months. Obviously, process changes must obtain 473 rough consensus in the IETF and follow the procedures in place 474 (principally RFC 2026 today). However, past experience has shown 475 that general discussion of IETF process change on the main IETF list, 476 or in a normal working group, rapidly tends towards divergent 477 opinions with consensus being extremely hard and slow to establish. 478 On the other hand, we have experience that discussion of simply 479 formulated principles and of consistent process proposals can be 480 constructive and convergent. 482 This note describes a method of starting the next phase of IETF 483 process change, possibly including updating the change process 484 itself. 486 As IETF Chair, I intend to lead a short term design team, to be known 487 as PESCI (Process Evolution Study Committee of the IETF). 489 I will request PESCI to 490 - review recent discussions on IETF process changes 491 - identify a concise set of goals and principles for process change 492 - publish these for comment and seek IETF debate and rough consensus 494 The target is to have a draft of goals and principles by IETF64. 496 The next steps will depend on the agreed goals and principles after 497 this debate. It is very likely that we will need a process that will 498 generate a consistent set of proposals and a sequence for 499 implementing them, with target dates. It is also likely that the 500 first proposal will be a new process for process change. And it's a 501 given that open discussion and rough consensus, in accordance with 502 IETF principles, will be required. 504 A non-binding proposal for the next steps is appended to this 505 message. 507 Given the short time until the next IETF, the team will have to start 508 very soon and work quite intensively. If you would like to volunteer 509 for the PESCI team or nominate someone to serve on it, please send me 510 email immediately. I want to create the team within a week. 512 Brian Carpenter 513 IETF Chair 515 N.B. The open discussion list will be pesci-discuss@ietf.org, but it 516 hasn't yet been created at the time of sending this message. 518 ----- 520 Possible next steps after the PESCI goals and principles are agreed: 522 - decide whether to renew the PESCI design team (assumed below) or 523 use an alternative discussion forum 524 - consider various process change proposals from any source 525 - reach a team consensus on a consistent set of proposals and a 526 sequence for implementing them, with target dates. All proposals 527 must embed the principle of rough IETF consensus and must provide an 528 appeal mechanism. 529 - one of the proposals, likely the first, may be a proposal for a new 530 process for process change 531 - post the proposals as Internet-Drafts intended for publication as 532 BCPs 533 - seek IETF-wide rough consensus on these drafts 534 - legal considerations, IASA financial considerations, and 535 considerations of practicality raised by current or past Area 536 Directors, WG Chairs and the like will be given special 537 consideration. If IETF consensus appears to be for a proposal which 538 is legally, financially or practically unacceptable, PESCI will need 539 to convince the community to change its mind. 541 To enable this, as relevant, the ADs, IAB members, and IAOC members 542 including the IAD will be asked to provide personal input 543 specifically on the feasibility of implementing the proposed process 544 changes as they affect their specific roles. 546 - forward proposals for approval as BCPs* and acceptance by the ISOC 547 Board. Until such time as the new process for process change has 548 been approved, the proposals will be submitted directly to the 549 General Area Director and the approval body will be the IESG. 550 However, the IESG members' principal chance to comment on and 551 influence the proposals is prior to their forwarding for approval. 553 *An alternative would be to use the mechanism described in RFC 3933, 554 if consensus was weak. In particular, this can be used to experiment 555 with the practicality of ideas. 557 Additional conditions for PESCI's work 559 - a subsidiary goal is to end up with a clearly defined and 560 interlocked set of process documents, rather than a patchwork of 561 updates to existing documents 563 - PESCI will provide an open mailing list where discussion with the 564 community will be encouraged. It will issue regular (monthly?) 565 progress reports and generally operate as transparently as possible. 566 Discussion in IETF plenary sessions is also expected. 568 - nothing in this proposal prevents ongoing operational improvements 569 within the current process. 571 Author's Address 573 Elwyn Davies (editor) 574 Folly Consulting 575 Soham, 576 UK 578 Phone: +44 7889 488 335 579 Fax: 580 Email: elwynd@dial.pipex.com 581 URI: 583 Full Copyright Statement 585 Copyright (C) The Internet Society (2006). 587 This document is subject to the rights, licenses and restrictions 588 contained in BCP 78, and except as set forth therein, the authors 589 retain all their rights. 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 595 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 596 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Intellectual Property 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Acknowledgment 625 Funding for the RFC Editor function is provided by the IETF 626 Administrative Support Activity (IASA).