idnits 2.17.1 draft-iab-advcomm-01.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 93 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 204 has weird spacing: '... labels and o...' == Line 398 has weird spacing: '... of the relat...' == Line 759 has weird spacing: '...mission and t...' -- 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 (December 23, 2003) is 7429 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) -- Looks like a reference, but probably isn't: 'Cotton' on line 1562 -- Looks like a reference, but probably isn't: 'IANA' on line 1562 -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group AdvComm 2 Internet-Draft IETF 3 Expires: June 22, 2004 December 23, 2003 5 The IETF in the Large: Administration and Execution 6 draft-iab-advcomm-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on June 22, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB 38 Advisory Committee (AdvComm), with a mandate to review the existing 39 IETF administratuve structure and relationships (RFC-Editor, IETF 40 Secretariat, IANA) and to propose changes to the IETF management 41 process or structure to improve the overall functioning of the IETF. 42 The AdvComm mandate did not include the standards process itself. 44 This memo documents the AdvComm's findings and proposals. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 49 1.1 Overview of the AdvComm work process and output . . . . . . 4 50 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.3 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1 Current IETF support structure . . . . . . . . . . . . . . . 5 54 2.1.1 What the term IETF includes in this document . . . . . . . . 5 55 2.1.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1.3 Support . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.2 Observed stress points . . . . . . . . . . . . . . . . . . . 9 58 2.2.1 Stress points observed by IETF leadership . . . . . . . . . 9 59 2.2.2 Stress points observed by organizations supporting the IETF 10 60 2.3 A final observation . . . . . . . . . . . . . . . . . . . . 11 61 3. Stand Facing the Future: Requirements for a successful 62 IETF administration . . . . . . . . . . . . . . . . . . . . 11 63 3.1 Resource Management . . . . . . . . . . . . . . . . . . . . 11 64 3.1.1 Uniform Budgetary Responsibility . . . . . . . . . . . . . . 11 65 3.1.2 Revenue source equivalence . . . . . . . . . . . . . . . . . 11 66 3.1.3 Clarity in relationship with supporting organizations . . . 12 67 3.1.4 Flexibility in service provisioning . . . . . . . . . . . . 12 68 3.1.5 Administrative efficiency . . . . . . . . . . . . . . . . . 12 69 3.2 Stewardship . . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.2.1 Accountability for change . . . . . . . . . . . . . . . . . 12 71 3.2.2 Persistence and accessibility of records . . . . . . . . . . 13 72 3.3 Working environment . . . . . . . . . . . . . . . . . . . . 13 73 3.3.1 Service automation . . . . . . . . . . . . . . . . . . . . . 13 74 3.3.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4. Advisory Committee Advice . . . . . . . . . . . . . . . . . 14 76 4.1 Proposed: (single) formalized IETF organizational entity . 14 77 4.1.1 Comments on the necessity of this formalization . . . . . . 15 78 4.2 Possible structures . . . . . . . . . . . . . . . . . . . . 15 79 4.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2.2 ISOC Subsidiary . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2.3 Completely autonomous organizational entity . . . . . . . . 17 82 4.3 Who can decide . . . . . . . . . . . . . . . . . . . . . . . 17 83 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 86 A. IAB Advisory Committee Charter . . . . . . . . . . . . . . . 18 87 B. Input from the current IETF and IAB Chairs . . . . . . . . . 19 88 C. Consultation with ISI: RFC-Editor . . . . . . . . . . . . . 21 89 D. Consultation with Foretec/CNRI: Secretariat and Meeting 90 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 E. Consultation with ICANN: IANA protocol parameter assignment 34 93 Full Copyright Statement . . . . . . . . . . . . . . . . . . 40 95 1. Introduction 97 In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB 98 Advisory Committee (AdvComm), with a mandate to review the existing 99 IETF administratuve structure and relationships (RFC-Editor, IETF 100 Secretariat, IANA) and to propose changes to the IETF management 101 process or structure to improve the overall functioning of the IETF. 102 This purpose was defined in the IAB Advisory Committee (AdvComm) 103 charter, copied in Appendix A. The AdvComm mandate did not include 104 the standards process itself. 106 The tangible output of this committee is a set of observations and 107 recommendations for the IETF's executive structure - how the IETF 108 might be organizationally (re)structured so that it can effectively 109 and efficiently carry out its administrative activities. As a 110 necessary preamble to that, a description of the current issues and 111 future requirements is presented. The output does not represent any 112 decision-making or implementation -- see Section 1.3 for a discussion 113 of follow-on steps. 115 1.1 Overview of the AdvComm work process and output 117 The AdvComm was formed in September 2003, and carried out its work 118 over the course of the following 2 months, prior to the IETF58 in 119 November of 2003. 121 The AdvComm's membership included many of the individuals who are, or 122 have been, volunteered to manage the IETF's inter-organization 123 administrative relationships in recent years. The first phase of the 124 committee's work, therefore, included sharing and discussing the body 125 of tacit knowledge about those relationships. This included the 126 input from the current IETF and IAB Chairs in Appendix B, and yielded 127 the IETF organizational structure information in Section 2.1. 129 The committee also sought input from the other end of the key 130 existing administrative relationships (RFC-Editor, Secretariat, and 131 IANA). The output of those efforts is included in Appendix C, 132 Appendix D, and Appendix E, and these were also used as the basis for 133 the observations in Section 2. 135 From these inputs, the committee drew together a list of requirements 136 for successful future IETF administration, documented in Section 3. 138 Finally, the committee put together some advice for how the IETF 139 might consider reorganizing its administrative structure to meet 140 those requirements moving forward -- Section 4. 142 1.2 Scope 144 The AdvComm endeavored to stay focused on the IETF executive 145 structure -- the collection of organizations that work together to 146 bring the IETF's work to reality. However, by virtue of the very 147 fact that those relationships exist to get the work done, it was 148 important to bear in mind the work being done in the IETF PROBLEM 149 working group and IESG proposals for change, even as the committee 150 endeavored not to infringe on the scope of those efforts. The 151 objective is that these observations and proposals should be relevant 152 for today's IETF and any near-term evolutions that are deemed 153 appropriate. 155 1.3 Next Steps 157 This documents the state of the AdvComm's thinking at the end of a 158 two month process, and brings the currently-chartered work of the 159 AdvComm to a close. 161 Next steps include review of this material by the community, and 162 specific proposals for action that will be put forward by the IAB and 163 IETF Chairs. 165 2. Observations 167 2.1 Current IETF support structure 169 2.1.1 What the term IETF includes in this document 171 RFC 3233 ([1]) provides a definition of the IETF, in terms of its 172 work and its participation. 174 This document discusses the collection of organizations that work 175 together to support the effort described in RFC3233. In this 176 document, the term "IETF" explicitly includes the IESG, WGs, IAB, 177 IRTF, and RGs. This inclusive sense accords with considerable common 178 usage of the term "IETF". Formally, the IAB and IRTF are chartered 179 independently of the IETF. However, rather than coming up with a new 180 term to encompass "the IETF and all its friends", the common usage is 181 followed here. 183 2.1.2 Functions 185 The work of the IETF is supported by a specific set of functions. It 186 is useful to distinguish between the functions and the organizations 187 which provide those services, as outlined in the table below. In 188 some cases a single organization provides multiple services, but the 189 functions are logically distinct. 191 Function Known as Organization 192 (within the IETF) 193 --------- ---------------- ------------ 194 IESG Support Secretariat Foretec/CNRI 195 IAB Support ISOC/Secretariat ISOC, Foretec/CNRI 196 WG Support Secretariat Foretec/CNRI 197 Community Support Secretariat Foretec/CNRI 198 IETF Meetings Secretariat Foretec/CNRI 199 RFC Publication RFC-Editor USC/ISI 200 Standards Status Record RFC-Editor USC/ISI 201 Parameter Reg. IANA ICANN 202 Legal, insurance, etc (largely invisible) Provided by ISOC 204 Table 1. IETF functions, labels and organizations 206 In more detail, the functions can be broken down as follows: 208 IESG Support 210 Telechats 211 Communications 212 IETF document tracking 213 Working document management (mailing list, website, repository) 215 IAB support 217 Telechats 218 Communications 219 Working document management (mailing list, website, repository) 221 WG support 223 Charters 224 Milestone tracking 225 Workspace (website, mailing list) 226 Working document archive (mailing list archives, document 227 repository) 229 Community Support 231 Website 232 IETF mailing list 233 Announcements 234 I-D repository 236 RFC Publication 237 Website 238 RFC editorial 239 Document publication 240 RFC repository management 241 Official standards status record 243 IETF Meetings 245 Planning 246 Meeting Proceedings 248 Protocol parameter registration 250 Creation of registries 251 Assignment of protocol parameters 252 Management of accessible registry repository 254 Legal, insurance, etc 256 Legal support 257 Liability insurance for IAB, IESG, WG chairs, etc 258 Miscellaneous 260 2.1.3 Support 262 A presentation of the scope and depth of support that created the 263 IETF and has allowed it to continue to contribute would require a 264 discussion of history that is rich, vibrant, and completely beyond 265 the scope of this document. However, a very brief introduction to 266 some of the current pillars is needed to understand where the IETF is 267 today. 269 ISOC: Since 1992, ISOC has been the organizational home of the 270 IETF. This activity is part of its more general mission of 271 serving as the international organization for global coordination 272 and cooperation on the Internet, promoting and maintaining a broad 273 spectrum of activities focused on the Internet's development, 274 availability, and associated technologies. 276 Foretec/CNRI: The Corporation for National Research Initiatives 277 (CNRI) was founded in 1986, and since 1987, CNRI has served the 278 community by providing IETF Secretariat services. Until the early 279 1990s, CNRI provided legal assistance to the IETF and the IETF 280 Secretariat. After ISOC was founded, ISOC assumed overall legal 281 responsibility for the substantive workings of the IETF including 282 the efforts of the IETF chair, the IESG, the IAB, the area 283 directors and the working group chairs. CNRI assumed operational 284 responsibility for the substantive workings of the IETF 285 Secretariat. In 1998, in order to decrease overhead costs on the 286 activities, the Secretariat was reorganized placing Secretariat 287 employees including the IETF Executive Director in a CNRI for- 288 profit subsidiary (Foretec Seminars, Inc.). Foretec was founded 289 in 1997, in anticipation of the Secretariat becoming self- 290 supporting. CNRI and its subsidiary have continued to improve the 291 operation of the Secretariat, as appropriate, and maintain a 292 trained staff. 294 USC/ISI: The role of the RFC-Editor, and USC/ISI, is detailed in 295 RFC2555. The RFC document series is a set of technical and 296 organizational notes about the Internet (originally the ARPANET), 297 beginning in 1969. For 30 years, the RFC-Editor was Jon Postel, a 298 research scientist and manager in the Networking Division of the 299 USC Information Sciences Institute (ISI), with the function 300 gradually evolving into a team headed by him. The RFC-Editor 301 activity is currently organized as a project within ISI, using the 302 ISI infrastructure, and supported by a contract with ISOC. The 303 RFC-Editor is the publisher of RFCs and is responsible for the 304 final editorial review of the documents, as well as the 305 maintenance of the online repository and index of those documents. 307 ICANN: The Internet Corporation for Assigned Names and Numbers 308 (ICANN) is the non-profit corporation that was formed in 1998 to 309 assume responsibility for the IP address space allocation, 310 protocol parameter assignment, domain name system management, and 311 root server system management functions previously performed under 312 U.S. Government contract by IANA (at ISI) and other entities. 314 The support picture (who does what) can be described as follows: 316 Secretariat at Foretec/CNRI 318 IESG Support 319 IAB Support (working document management) 320 WG Support 321 Community Support 322 IETF meetings 324 RFC Editor at USC/ISI 326 [Supported by ISOC, based on a contract between USC/ISI and 327 ISOC] 329 RFC publication Maintenance of standards status record 331 IANA/ICANN 333 [Relationship defined by Memorandum of Understanding: RFC2860] 335 Protocol parameter registry 337 ISOC 339 IAB Support (Telechats) 340 Funds RFC-Editor 341 Misc IAB/IESG expenses 342 Provides insurance for IAB, IESG, WG chairs, etc 344 The available resources to support these activities are: 346 Meeting fees -- through Foretec 347 ISOC members' contributions for standards 348 ICANN for IANA 349 Volunteers/their employers (where applicable): 351 IETF participants 352 WG chairs 353 Document editors 354 IETF NomCom 355 IESG 356 IAB 357 IAB ExecDir 359 2.2 Observed stress points 361 The AdvComm noted several properties of the current IETF 362 organizational environment that cause stress in the system. These 363 have been noted both from the point of view of the IETF leadership as 364 well as that of organizations supporting the IETF. 366 2.2.1 Stress points observed by IETF leadership 368 The current IETF funding and operational structure is dependent on 369 IETF meeting attendance. Therefore, the most obvious stressor that 370 has emerged within the last two years is the decline in that 371 attendance. This trend, which has continued unabated, has resulted 372 in a decline in IETF revenue (detailed in the IETF chair presentation 373 at IETF 56 [2]), even as the requirements of the IETF operation are 374 remaining constant or increasing. 376 The result has been a budget deficit for operations which began in 377 2002, and is forecasted to continue until at least 2004, even after a 378 substantial increase in meeting fees. The continuing deficits have 379 depleted working capital, making the IETF less robust against 380 potential future budgetary disappointments. 382 The financial stress is real, but the IETF leadership has noted 383 several other stressors that are impediments to finding and 384 implementing solutions to the fiscal issues. Some obvious solutions 385 are not implementable in the current IETF structure. 387 The rest of the stressors listed in this section should be understood 388 as issues for which relief is necessary, particularly in the light of 389 needing to properly address and implement solutions to the financial 390 stress. 392 The current documentation of IETF processes and structure is, in 393 places, vague about the distribution of responsibility for management 394 and oversight of the IETF administrative relationships. This makes 395 it opaque to the IETF community, and sometimes leaves the leadership 396 in a poor position to manage effectively. 398 Additionally, the informality of the relationships with some of the 399 organizations that are carrying out key IETF functions compounds the 400 problem of determining who has responsibility, and how IETF community 401 consensus and desires are reflected in the activity. 403 As a separate issue, important IETF institutional memory is recorded 404 nowhere other than peoples' minds in many cases -- which requires 405 significant transmission of oral history for IETF leadership 406 transition to be effective. 408 Apart from the institutional memory, other important IETF 409 institutional records are spread across various organizations, and 410 searching for the set of relevant documentation (especially when this 411 is necessary long after the recording) can be challenging. 413 Another stressor relates to the need to scale support processes in 414 terms of reducing latency for mechanical processes. That is, a 415 decrease in the amount of manual labor required for the simpler tasks 416 between the organizations, would make more resources available to 417 focus on the special cases. Lack of automation in the basic request 418 services has been known to cause undue delay or failure in processing 419 simple, routine tasks. However, automation also requires resources 420 and significant management in order to make sure it fulfills the 421 community's requirements. 423 2.2.2 Stress points observed by organizations supporting the IETF 425 Supporting organizations report difficulties in determining 426 authoritative channels for directions -- either too many inputs, or 427 no clear authority for resolution of change requests. 429 In the absence of written agreements, supporting organizations may 430 not be clear from whom to take direction. Even where agreements 431 exist, the authority to provide direction may not be clear. The 432 genesis of both problems is that the IETF relies on external bodies 433 for support, but does not have sufficiently clear external 434 relationships to allow it to provide input as to its requirements or 435 direction on what services it desires. 437 2.3 A final observation 439 This section attempts to capture a snapshot of the current state of 440 the IETF organization, without undue fixation on the causes for 441 arriving at the current state. However, the it seems clear from the 442 observations that the current state does not provide an adequate 443 structure from which to reach into the future: some changes are 444 needed within the IETF administrative and executive structure. 446 3. Stand Facing the Future: Requirements for a successful IETF 447 administration 449 This section follows the set of observations with a set of 450 requirements for a properly-functioning IETF administrative 451 structure. These requirements are offered as the AdvComm's 452 description of what the IETF needs, without addressing immediately 453 the degree to which they are available with the current environment. 454 That is, these are "requirements", not "requirements for change". 456 3.1 Resource Management 458 3.1.1 Uniform Budgetary Responsibility 460 The IETF has operated in times of financial wealth and times of 461 economic cutbacks in the industry. It is reasonable to expect that 462 the future holds similarly variable trends. Therefore, it is 463 important that the IETF organization has the ability to make the 464 decisions to match its needs at a given point in time, i.e., 465 budgetary autonomy. At this particular moment, there are hard 466 choices to make, and the AdvComm believes that it is the IETF 467 leadership, with the advice and consent of the IETF community, that 468 needs to make them. 470 3.1.2 Revenue source equivalence 472 The IETF is currently supported by money from multiple sources, 473 including meeting fees, donations from interested corporate and non- 474 corporate entities, and donations in kind of equipment or manpower. 475 The IETF needs to be able to consider all sources of income, and all 476 expenses involved in running the IETF, as pieces of one budget, to be 477 free to adjust all items on the occasions when the income from the 478 different sources varies, and to allocate funds as reasonably 479 required. 481 The usual caveats apply: that donations not threaten the 482 independence of the IETF, and that donations are easier when they are 483 tax deductible. 485 3.1.3 Clarity in relationship with supporting organizations 487 While the IETF needs to be able to manage its revenue streams against 488 its expense expectations, it also needs to respect the needs of 489 supporting organizations to manage their own affairs. That is, the 490 text above does not suggest that the IETF should micromanage the 491 financial affairs of supporting organizations. 493 However, the very clear requirement is for clarity in the 494 distribution of rights, responsibilities, and accountability in those 495 relationships. The usual mechanism for documenting such clarity is 496 in contract form. Thus, the IETF needs to have clear contractual 497 relationships with the organizations supporting basic services, 498 including meeting organization, secretarial services, IT services, 499 etc. 501 3.1.4 Flexibility in service provisioning 503 The IETF needs to be able to raise money for, and fund the 504 development of, additional services as appropriate. This includes 505 the development of tools for participants, repository management, 506 etc. 508 3.1.5 Administrative efficiency 510 The IETF's needs should be met with the minimum of overhead. This 511 implies that there needs to be the possibility of combining work 512 efforts where appropriate, and generally avoiding duplication of 513 effort. 515 3.2 Stewardship 517 The requirements described below focus primarily on the needs of the 518 IETF administration on a day-to-day basis. However, responsible 519 management includes stewardship for future IETF work. 521 3.2.1 Accountability for change 523 The IETF needs to be responsible for changing its administrative 524 structure to meet the community's evolving needs. As such, the 525 administration needs to remain uniquely accountable to the IETF 526 community. 528 This also means that the distribution of responsibilities must be 529 clear to the IETF community, in order to permit it to comment on 530 current actions or future plans, and also to allow it to take action 531 when its needs are not being adequately addressed. 533 An implication of this is that responsibility for financial 534 management within the IETF needs to sit with individuals who are 535 accountable within the IETF organizational structure. 537 3.2.2 Persistence and accessibility of records 539 Much of the work of the IETF is focused on reaching decisions and 540 declaring closure. However, responsibility does not stop with the 541 declaration of completion. There are any number of reasons that 542 history must be adequately documented so that future work can review 543 substantive records, and not rely on oral history. 545 Therefore, the IETF needs to maintain and support the archiving of 546 all of its working documents in a way that continues to be 547 accessible, for all current and future IETF workers. 549 3.3 Working environment 551 Part of the job of administering the IETF is identifying and ensuring 552 the continued support of the tools and working environment necessary 553 to support the ongoing activity. 555 3.3.1 Service automation 557 Wherever human judgment is not required in order to complete an 558 action, services should be automated to provide the most friction- 559 free path and minimal delay in completing the action. 561 More processes could be accomplished without requiring human judgment 562 -- wherever possible, these should be identified, clarified, and 563 automated. 565 Note that this is not intended to imply ALL processes should be 566 automated! Rather, by reducing the friction incurred in steps that 567 are truly mechanical, more time and energy will be available to 568 properly treat those that require individual judgment. 570 3.3.2 Tools 572 Whether housed in an IETF-supported location or offered by individual 573 contribution, the PROBLEM WG has identified the need for more tool 574 support for working groups and specification development. The IETF 575 needs to be able to identify, develop and support an adequately rich, 576 consistent set of tools for getting the standards work done. 578 4. Advisory Committee Advice 580 The Advisory Committee discussed the material and observations, 581 described in this document, at great length. To the AdvComm, it 582 appeared clear that some level of IETF administration organizational 583 change is needed to address the stressors and meet all of the 584 requirements outlined in Section 3. 586 4.1 Proposed: (single) formalized IETF organizational entity 588 In order to ensure an IETF structure that is capable of meeting the 589 requirements outlined above, the AdvComm recommends that the IETF be 590 more formally organized. This would allow the IETF to take full 591 responsibility for, and management of, the resources required to 592 accomplish its work (as described in Section 3.1), provide and 593 maintain the necessary work environment for current work (as 594 described in Section 3.3), and provide appropriate stewardship of the 595 institutional information required for all aspects of current and 596 future work of the organization (as described in Section 3.2). 598 Some proposed models for establishing such a formalized effort are 599 described in the following sections. Some of the key expectations, 600 irrespective of the final implementation of formalism, are: 602 o the administration of the IETF would remain accountable to the 603 IETF leadership and community; the goal would be to ensure that 604 lines of responsibility and accountability were clearer; 606 o this formalized IETF would be responsible for managing financial 607 resources (revenue and expenses) directly; 609 o this formalized IETF would be directly signatory to agreements 610 with other organizations, and would therefore be able to negotiate 611 and administer any appropriate contracts; 613 o however implemented, this would require a small staff complement 614 (e.g., one full-time person) responsible to no other organization 615 than the one chartered with the IETF's mission; 617 o nevertheless, it remains a non-goal to create an organizational 618 entity that exists simply for the purpose of continuing to exist. 619 This should be executed with the minimum formality needed in order 620 to address the identified requirements. 622 4.1.1 Comments on the necessity of this formalization 624 An important question is: what does this proposed formalization 625 provide that cannot be provided by the status quo? The AdvComm 626 believes that an appropriately implemented formalization of the IETF 627 would permit the unification of the resource management, decision 628 making and stewardship that is imperative to providing clarity and 629 ensuring a viable future for the IETF. The AdvComm further believes 630 that this is simply not possible to implement within the existing 631 distributed and informal arrangement of responsibilities. 633 Naturally, the act of forming such an organization does not 634 immediately satisfy the requirements outlined in Section 3. It is 635 not a silver bullet. Changing the formal structure will not, for 636 example, change the financial status of the IETF. However, the 637 AdvComm believes it would provide the necessary basis from which the 638 required decisions could be made and acted upon. 640 In short, the AdvComm believes that we first have to place the 641 responsibility for defining the IETF's administrative environment 642 with specific people who are accountable to the IETF community. Then 643 these people can take the detailed decisions that will change the 644 IETF's administrative environment to fulfill its requirements. 646 4.2 Possible structures 648 Section 4.1 was deliberately vague on the nature of the formal 649 organizational entity that might provide the proper environment, 650 focusing instead on the key components of any implementation of such 651 a formalization, and how the formalization activity would address the 652 requirements laid out in Section 3. 654 Having thus determined that formalization of the IETF is seen as a 655 necessary step, the basic framework for 3 potential implementations 656 of it are described below. Note that these are not complete 657 proposals, nor is enough detail available to recommend a particular 658 path. The IETF leadership might select one to explore in greater 659 detail, to formulate an action proposal with sufficient detail to 660 make a decision to act. 662 4.2.1 ISOC 664 The IETF is organized as an activity of the Internet Society. One 665 potential path for increased formalism of the IETF's administration 666 would be to further define that relationship. This model anticipates 667 dedication of ISOC personnel to form the "small staff complement", 668 and would make ISOC responsible for all of the IETF's financial 669 resources and expenses. 671 This approach should be relatively straightforward to implement, 672 given ISOC's existing legal relationship with the IETF activity, and 673 its status as signatory for IETF-related contracts (e.g., RFC- 674 Editor). 676 This proposal is consistent with the goal of minimizing the amount of 677 formalization needed to meet the requirements of the IETF. 679 However, the general mission of ISOC is broader than the 680 standardization activity of the IETF, and the ISOC Board of Trustees 681 must stay focused on apportioning resources to meet that broader 682 mission. Would this approach allow the clear lines of responsibility 683 that are called for in Section 3? 685 4.2.2 ISOC Subsidiary 687 A modification of the proposal of housing the IETF central body 688 within ISOC is to create a legal not-for-profit subsidiary of ISOC, 689 with a mandate that is specifically focused on the IETF's mission. 690 This subsidiary would become the legal entity responsible for 691 managing the IETF's resources and expenses, and would become 692 signatory to any other legal instruments on the IETF's behalf. 694 As a distinct legal entity in its own right, the subsidiary would be 695 independently responsible for achieving its mission. That level of 696 independence addresses the concern raised against the notion of 697 further formalizing the IETF within ISOC directly -- that the IETF 698 mission might be disrupted by the organization's need to tend to 699 other aspects of ISOC's broader mission. The role of the IETF 700 community, and the ISOC parent, in defining and supporting that 701 mission would be spelled out in the creation of the legal body. 703 The IETF might additionally consider what the most appropriate 704 governance model would be for this approach. If it is desirable to 705 remove some of the administrative burden from the IESG and IAB, such 706 a subsidiary might have its own Board of Trustees, composed of 707 members appointed by IETF and ISOC. Such a Board would be 708 responsible for reviewing activities and ensuring that the 709 organization's efforts were adequately in line with its mission, its 710 finances were in order, and so on. The subsidiary would report to 711 its Board of Trustees. Other governance models are certainly 712 possible, and a Board of Trustees is not a requirement for this 713 approach. 715 At the same time, as a subsidiary organization, the expectation is 716 that the relationship with ISOC would remain a close one: the 717 subsidiary would benefit from ISOC's existing infrastructure and 718 support (a conservative approach to adding formalism and structural 719 overhead to the IETF activity), while the relationship would continue 720 to provide a channel for the IETF to support ISOC in achieving that 721 broader mission, with continued contribution of technical expertise 722 and support of activities. 724 This approach would require more work to create than simply housing 725 the work at ISOC. The subsidiary would have to be created and 726 rights/responsibilities adjusted between it and ISOC in order to 727 ensure that both have the necessary resources and frameworks to carry 728 out their missions. 730 4.2.3 Completely autonomous organizational entity 732 To complete the picture, a third option has to be considered. 733 Instead of creating a subsidiary of ISOC as a separate legal entity, 734 an entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be 735 created for the sole purpose of managing IETF administrative 736 activities. 738 This would offer the IETF complete autonomy with all the attendant 739 rights and responsibilities. In particular, an independent IETF 740 would at a minimum, need to operate much like a startup for the first 741 few years of its existence, with all the related financing and growth 742 issues, and survival risks. Given all the organizational change 743 taking place within the IETF during the same period, the AdvComm 744 believes that the financial and political risks of such an approach 745 should not be under-estimated. 747 For example, it would be necessary for the IETF to obtain initial 748 working capital sufficient to handle the commitments for the first 749 few meetings. While it would be conceivable to raise working capital 750 from advance meeting fees, such a financing plan would not leave much 751 margin for error; were one or more of the initial meetings to run in 752 the red, the survival of a fledgling IETF could be in jeopardy. 753 Given the economic environment, it probably should not be assumed 754 that working capital could be raised purely from corporate donations, 755 especially during an initial period in which staff required to 756 solicit and manage donations would not be available. 758 Additionally, the impact that such a move would have on ISOC's 759 ability to carry out its mission and the IETF's standing with 760 governmental organizations needs to be considered. 762 4.3 Who can decide 764 The AdvComm believes that the IETF leadership, acting with the advice 765 and consent of the IETF community and ISOC, have the ability and the 766 responsibility to act on the recommendation to formalize the IETF. 768 5. Security Considerations 770 This document does not describe any technical protocols and has no 771 implications for network security. 773 6. Acknowledgements 775 The AdvComm sincerely appreciates the time, effort and care of the 776 RFC-Editor, IANA, Secretariat and Secretariat organizations, in 777 providing input, responding to the AdvComm's questions, and 778 reviewing/correcting the consultation text shown here in the 779 appendixes. 781 References 783 [1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC 784 3233, February 2002. 786 [2] Alvestrand, H., "IETF Chair plenary presentation, 787 http://www.ietf.org/proceedings/ 03mar/slides/plenary- 788 3/index.html", March 2003. 790 Author's Address 792 Advisory Committee 793 IETF 795 EMail: advcomm@ietf.org 797 Appendix A. IAB Advisory Committee Charter 799 Date: Tue, 02 Sep 2003 16:34:58 -0400 800 From: Leslie Daigle 801 Subject: Formation of IAB Advisory Committee 802 To: IETF-Announce: ; 804 I would like to announce the formation of an IAB advisory 805 committee, as described below. 807 Thanks, 808 Leslie, 809 for the IAB. 811 ================= 813 IAB Advisory Committee on IETF Administration Relationships 814 The purpose of the committee is to review the existing 815 IETF administration relationships (RFC-Editor, IETF Secretariat, 816 etc) and propose IETF management process or structural changes 817 that would improve the overall functioning of the 818 IETF. Any such proposal will be subject to review and 819 acceptance by the IAB and IETF plenary. Note that the scope of the 820 advisory committee does NOT include proposed changes to the standards 821 development processes (e.g., WG organization, IESG management of 822 documents or working groups, etc). 824 The committee is chaired by the IAB Chair, Leslie Daigle, and 825 consists of: 827 o Bernard Aboba 828 o Harald Alvestrand (IETF Chair) 829 o Lynn St.Amour (ISOC President) 830 o Fred Baker (Chair, ISOC Board of Trustees) 831 o Brian Carpenter 832 o Steve Crocker 833 o Leslie Daigle (IAB Chair, chair of the committee) 834 o Russ Housley 835 o John Klensin 837 Additional input is welcome. The committee will also make a particular 838 effort to seek out further input as needed. 839 -- 841 Appendix B. Input from the current IETF and IAB Chairs 843 Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle 844 (IAB Chair). 846 Looking at the administrative overview of the IETF activity, there 847 are a number of things that work well: 849 o support organizations are committed to the work of the IETF; 851 o the volunteers of the IETF WGs can (mostly) concentrate on their 852 engineering work, not economics; 854 o money has (so far) been sufficient to cover the costs. 856 However, there are also a number of challenges: 858 o lack of persistent records of the whole organization's efforts -- 859 of working documents, meeting materials, communications. Also, 860 * lack of organization of records -- even when data is stored, it 861 can be hard or impossible to access when no longer current 862 (e.g., it may reside on some former WG chair's hard drive) 864 * history records are kept spottily (lists of wg chairs and old 865 versions of charters, to mention some); 867 o few safeguards against the "hit by a bus" problem -- much 868 information about relationships is not documented, and must be 869 transferred as oral tradition. This means that significant 870 overlap is needed when personnel changes; 872 o IETF leadership responsibilities are not clearly identified -- 873 typically handled by IETF and IAB Chairs, with some advice and 874 consent from IESG and IAB, but that makes it possible to challenge 875 every change decision; 877 o contracts do not clearly identify responsibility for executive 878 direction. Some contractual relationships are not documented, or 879 are not visible to the IETF leadership; 881 o variable, and often unclear, documentation of responsibilities 882 between IETF leadership and other organizations. This makes it 883 hard to determine how and where to discuss and effect improvements 884 for the IETF that affect one or more support organization's 885 activity; 887 o unclear budgeting responsibilities -- the IETF leadership has to 888 make decisions that will impact the revenues and costs of the 889 supporting organizations, but the supporting organizations wear 890 the direct effects of revenue and cost control. Information about 891 the financial impact of decisions are not available to IETF 892 leadership; 894 o partitioned finances -- it's not possible for the IETF to make 895 changes that would affect the balance of revenue and costs across 896 the revenue sources/expense commitments. E.g., raising meeting 897 fees wouldn't pay for more RFC-Editor resources; more support from 898 ISOC doesn't address any needs for IETF working group support 899 functions; 901 o the lack of clarity and the partitioning make it very hard for the 902 IETF leadership, and the community as a whole, to determine points 903 of accountability and implement changes for a healthy future. 905 Appendix C. Consultation with ISI: RFC-Editor 907 Responses to Questions from IAB Advisory Committee 908 for the RFC Editor 909 October 6, 2003 911 * 912 * (1) Your description of the function you are performing. Is 913 * that function, and its relationship to the IETF, adequately 914 * described in RFC 2223bis, or is additional description 915 * required? If the latter, what would you suggest? 917 ANSWER: 919 A comprehensive summary of current RFC Editor functions is attached 920 below. Note that this list has no direct relation to RFC2223bis, which 921 contains instructions to RFC authors. 923 * 924 * (2) What staff is being used to perform these functions and 925 * what are their particular skills for doing so (either 926 * individually or in the aggregate)? 927 * 929 ANSWER: 931 For 30 years, the RFC Editor was Jon Postel, a research scientist and 932 manager in the Networking Division of the USC Information Sciences 933 Institute (ISI). It is currently organized as a project within ISI, 934 using the ISI infrastructure. The following ISI staff members comprise 935 the RFC Editor project: 937 Joyce Reynolds 100% 938 Bob Braden 10% 939 Aaron Falk 10% 940 Sandy Ginoza 100% 941 Project Assistant 100% 942 Graduate Research Asst. 50% 944 Braden and Reynolds jointly manage the RFC Editor project, with 945 oversight of personnel and budgets. 947 Joyce Reynolds has been contributing her editorial and management 948 skills to the Internet since 1979. She performed the IANA functions 949 under Jon Postel's direction from 1983 until Postel's death in October 950 1998. She continued to perform the IANA protocol parameter tasks on 951 loan from ISI to ICANN, from 1998 to 2001. She was IANA liaison to the 952 IESG from 1998 to 2001, transitioning the role to Michelle Cotton in 953 the 2001. 955 Reynolds performed the RFC Editor functions under Jon Postel's 956 direction from 1987 until 1998. Reynolds has been a member of the IETF 957 since 1988, and she served as User Services Area Director on the IESG 958 for 10 years. Reynolds now serves a liaison to the IAB and IESG. She 959 handles the final proofing and quality control on RFCs prior to 960 publication. 962 Bob Braden has made many contributions to the Internet protocol 963 technology and community. He helped design TCP/IP during the original 964 research period beginning in 1978, and he has devoted his professional 965 career since 1978 to the Internet. He served for 13 years on the 966 original IAB and as its Executive Director for about 5 years. Since 967 1998 Braden has been co-leader of the RFC Editor project. He is the 968 principal reviewer of individual submissions. He also works on 969 technical issues related to the RFC Editor project. 971 Aaron Falk is a significant player in the IETF as a Working Group 972 chair, in the areas of transport protocols and satellite technology. 973 On the RFC Editor team, he assists with policy questions and handles 974 technical development, overseeing the work of the grad student 975 programmer. 977 Sandy Ginoza is the principal technical editor. She is generally 978 responsible for managing the RFC Editor queue and much of the 979 day-to-day interface with the IESG and authors. Ginoza sends and 980 receives a LOT of email, and she plays a central role in the 981 operation. 983 Two part-time Project Assistants, Mieke Van de Kamp and Alison de la 984 Cruz, do editing, mark-up, and initial proofing of individual RFCs. 985 Our goal is to have three pairs of eyes read every RFC word-for-word, 986 and in most instances we are able to do so. 988 A half-time USC Graduate Research Assistant provides programming 989 support by developing, extending, and maintaining RFC Editor scripts 990 and tools. 992 * (3) What criteria do you use to determine whether you are being 993 * successful, and how successful? Using those criteria, how 994 * successful are you and what could be done, especially from the 995 * IETF side, to improve that evaluation? 997 ANSWER: 999 We can begin with a historical perspective on this question. When Jon 1000 Postel unexpectedly passed away 5 years ago, Reynolds and Braden took 1001 on the challenge of carrying on Postel's RFC Editor function. The 1002 publication stream continued, with a modest increase in quantity and, 1003 we believe, no loss of quality. Furthermore, the transition was 1004 largely invisible to the IETF. In addition, the new RFC Editor project 1005 has significantly defined and clarified the publication process, 1006 improved the web site, added tools to improve productivity and quality, 1007 and adapted the procedures to changing realities. We are proud of 1008 these achievements. 1010 The three primary axes for measuring RFC Editor success are (1) 1011 quantity, (2) quality, and (3) accessibility. 1013 1. Quantity 1015 Roughly, quantitative success means the ability to keep up with 1016 the submission rate. Since the submission rate tends to be 1017 bursty, to avoid long delays we need an average capacity 1018 somewhat in excess of the average. 1020 RFC publication is necessarily a heavily labor-intensive process. 1022 Our goal is generally to complete the publication process in 1023 less than 4 weeks, exclusive of external factors beyond our 1024 control -- normative dependence upon other documents, delays by 1025 authors or the IESG, IANA delays, etc. 1027 2. Quality 1029 Publication quality is harder to measure, but "we know it when 1030 we see it." Considering quality as the absence of faults, by 1031 noting faults we can observe lack of quality. 1033 One measure of faults is the number of errata that appear after 1034 publication. In addition, there may be faults apparent to a 1035 reader, such as a meaningless title, confusing organization, 1036 useless Abstract, inadequate introduction, confusing 1037 formatting, bad sentences, or bad grammar. There are of course 1038 limits to our ability to repair bad writing; ultimately, 1039 quality depends upon the authors as well as the editing 1040 process. 1042 The only way to maintain quality is to continually monitor our 1043 work internally, to track external complaints, and to adjust 1044 our practice to correct frequent faults. Specific faults have 1045 sometimes led us to create new tools for checking 1046 consistency, to avoid clerical errors. Sometimes they have led 1047 to new user guidelines (e.g., on abbreviations or on Abstract 1048 sections.) 1050 3. Accessibility 1052 An important part of the RFC Editor function is to provide a 1053 database for locating relevant RFCs. This is actually a very 1054 hard problem, because there is often a complex semantic web 1055 among RFCs on a particular topic. We have made great 1056 improvements in our search engine and web site, but there is 1057 undoubtedly a need for more progress in this area. The 1058 challenge is to provide better guideposts to users without 1059 creating a significant additional manpower requirement. 1061 We make heavy use of our own search and access tools, and this 1062 gives us feedback on their success and sometimes suggests 1063 improvements. 1065 Finally, we offer some specific suggestions to answer the question, 1066 "What can the IETF do to improve the RFC Editor's evaluation" (i.e., our 1067 service to the community)? 1069 1. Give us better documents to publish. Many are well written and 1070 organized, but some are bad and a few are very bad and need a great 1071 deal of work to create acceptable publications. Better input 1072 documents will improve both our quantity and our quality. 1074 The IESG has been making a large effort to improve the quality of 1075 Internet Drafts before they become RFCs, and we are very grateful 1076 for this. 1078 One issue of particular concern is the increasing number of RFCs 1079 authored by non-English speakers. These can consume much extra 1080 editorial effort. We don't know any solution to this problem, but 1081 we know that the IESG is aware of it and working with provide 1082 editorial assistance when necessary within working groups. 1084 2. Prepare a series of RFCs containing "road maps" that describe the 1085 semantic web of RFCs in a particular area. Although these would 1086 rapidly become out-dated in detail, they would still provide very 1087 important guides to RFC readers. 1089 The RFC Editor is as self-critical as any organization could be, but we 1090 believe there is no objective basis for claiming that we are not doing 1091 a good job for the Internet. We continually strive to do a better job. 1093 * 1094 * (4) How would you characterize the quality of your relationship 1095 * with the IETF and its leadership? Is there mutual trust and a 1096 * sense of working together on issues, or do you and your 1097 * colleagues sometimes see the relationship as adversarial? 1098 * 1100 ANSWER: 1102 The RFC Editor shares with much of the rest of the Internet community a 1103 deep desire to advance the technology and practice of the Internet. We 1104 consider ourselves partners with the IETF, the IESG, and the IAB in 1105 this endeavor. 1107 Although the major goals coincide, the IESG and the RFC Editor quite 1108 properly have somewhat different priorities. The RFC Editor's role, 1109 historically and currently, is to create and maintain the RFC document 1110 series as a high-quality and vital channel for technical communication, 1111 while the IESG is concerned with managing the Internet engineering and 1112 standards process. This difference sometimes leads to honest 1113 disagreements, but we have generally worked out mutually-satisfactory 1114 solutions to these conflicts. 1116 The word "adversarial" seems completely inappropriate, and we are 1117 struggling to understand what could have led to its appearance here. 1119 * (5) Are there specific known problems you would like us to look 1120 * at and understand? If so, please describe them. 1122 ANSWER: 1124 (A) The length of time for IESG review and recommendations on individual 1125 submissions has sometimes become excessive. We understand the load 1126 of IESG members, but we would like to ask their help in keeping 1127 response to a few months. 1129 The RFC Editor has been attempting to raise the bar on accepting 1130 individual submissions, to avoid wasting valuable IESG time as well 1131 as to maintain (or improve) the quality of the RFC series. 1133 (B) We would like understanding and support of the RFC Editor's statutory 1134 and historic responsibility to publish significant technical documents 1135 about networking that originate outside the IETF standards process. 1136 This publication has several important purposes. 1138 One is to bring out new technical ideas for consideration and 1139 discussion. We believe that the future success of the Internet 1140 demands an infusion of new ideas (or old ideas revitalized), 1141 and that the publication of such ideas as RFCs is important. 1143 Another purpose is to build a shared literature of mature 1144 technical discussion, to help avoid the periodic 1145 re-discussions that take place on our mailing lists. 1147 Finally, the RFC series provides a historic repository for 1148 important ideas. We have come across a number of examples of 1149 important suggestions and partial technology developments that 1150 have been lost, or hard to locate, because they were not 1151 published as RFCs. The community spends too much of our time 1152 re-inventing many, many wheels. 1154 Our ultimate goal is to publish more high-quality submissions, so 1155 we can raise the bar for publication. 1157 Independent submission publications represent only a minor 1158 fraction of the RFC production. For example, so far in calendar 1159 2003 we have published 178 RFCs, including 14 independent submissions. 1160 If all the drafts that we think deserve to be preserved as RFCs were 1161 to be published, this fraction would grow, but we would not expect 1162 it to grow beyond 25% of the total number of published RFCs. 1164 (C) We would like to work with the IAB/IESG in re-examining the issue 1165 of normative references. We believe that the current definition of 1166 normative is ambiguous and unclear, and that as a result some 1167 publications may be unnecessarily held up for normative references 1168 where these are unnecessary. 1170 (D) We would like to cooperate in an investigation of the issues in 1171 extending the character set beyond US-ASCII,.e.g., to UTF-8. A 1172 major issue is whether there is a set of preparation, display, and 1173 searching tools for both the RFC Editor and the RFC consumers. 1174 These tools need to be ubiquitously available and mature enough. 1176 The RFC Editor is looking for input on how we can best continue to 1177 serve the community. We are grateful for the suggestions we have 1178 received, and we have adopted as many of them as feasible; the 1179 result has been quite a long list of incremental improvements in 1180 our service over the past 5 years. 1182 * 1183 * (6) How do you see the costs of your function evolving? If 1184 * things become more costly over time, what are the main 1185 * determiners of cost (e.g., general inflation, general IETF 1186 * growth, increase in the number of particular functions you are 1187 * carried out to perform,...). Are you doing some things that 1188 * IETF (IESG or otherwise) request that you do not consider 1189 * cost-effective and, if so, what are they? 1190 * 1191 * 1193 ANSWER: 1195 The major cost factor is the number of documents submitted and 1196 published. This has grown relatively slowly over time. It appears to 1197 us that the IETF process has (perhaps fortunately) been the bottleneck 1198 that has kept the rate of RFC production from growing exponentially. 1199 We do not expect that to change dramatically. 1201 In more detail, the cost factors are: 1203 (a) Inflation (on salaries) 1205 This shows a small and predictable annual increase. 1207 (b) The number of RFCs published. 1209 This is the primary cost factor. The bulk of the 1210 editorial and coordinating functions are directly 1211 attributable to specific documents. At present, 1212 we estimate that this cost category represents 1213 70% of our personnel time, and 63% of our cost. 1215 (c) Tasks not directly related to specific RFCs. 1217 This includes many functions: management (budget and 1218 personnel as well as policy and procedure development), 1219 IETF liaison, reviews of independent submissions, 1220 development and maintenance of web pages, scripts, and 1221 tools, the RFC Online project, maintaining the Errata 1222 web page, etc. These are currently estimated to 1223 require 30% of our personnel time, and 37% of our 1224 cost. 1226 Minor extensions of function can be absorbed with little extra cost 1227 (but at a leisurely pace). We are not proposing any major functional 1228 extensions at this time; such extensions would have to be costed 1229 separately (were money available for them.) 1231 Disk storage and web services are provided by ISI's support organization 1232 and are treated as overhead. Most of the desktop machines used by the 1233 project were originally bought under research contracts, although the 1234 RFC Editor budget includes a very small item for equipment upgrades. 1236 APPENDIX -- FUNCTIONS OF RFC EDITOR 1238 OVERVIEW 1240 The RFC Editor edits and publishes the archival series of RFC 1241 (originally "Request for Comment") documents. The RFCs form an archival 1242 series of memos about computer communication and packet switching 1243 networks that records the technical history of the ARPAnet and the 1244 Internet, beginning in 1969. The RFC Editor is funded by the Internet 1245 Society and operates under the general direction of the IAB (Internet 1246 Architecture Board). 1248 The RFC Editor publishes RFCs and a master index of the RFC series 1249 electronically on the Internet, via all common access protocols 1250 (currently, the Web, email, rsync, and FTP). It announces the existence 1251 of each new RFC via electronic mail to one or more mailing lists. The 1252 RFC Editor maintains a comprehensive web site with a variety of tools 1253 and lists to locate and access RFCs. This website also contains 1254 general information about RFC editorial policies, publication queue 1255 status, errata, and any other information that will make the RFC series 1256 more accessible and more useful. 1258 During the RFC editing process, the RFC Editor strives for quality, 1259 clarity, and consistency of style and format. Editorial guidelines and 1260 procedures to achieve these ends are established by the RFC Editor in 1261 consultation with the IAB and IESG (Internet Engineering Steering 1262 Group). The RFC Editor periodically publishes a revision of these its 1263 guidelines to authors. 1265 The RFC Editor coordinates closely with the IESG to carry out the 1266 Internet standards process as documented in the latest revision of "The 1267 Internet Standards Process" and later amendments. The RFC Editor also 1268 coordinates closely with the Internet Assigned Numbers Authority 1269 (IANA), to ensure that the parameters used in new and revised protocol 1270 descriptions are properly registered. 1272 SPECIFIC TASKS 1274 I. Editing and publishing RFCs 1276 (1) Publication process. 1278 The RFC Editor edits and publishes RFCs in accordance with RFC 1279 2026 (or replacement documents) and RFC 2223bis. This includes 1280 the following tasks: 1282 (a) Performing the final editing of the documents to maintain 1283 consistency of style, editorial standards, and clarity. 1285 At minimum, the RFC Editor: 1287 (i) Copy-edits the documents, including the correction of 1288 spelling and grammar, and some checking for 1289 inconsistent notation. Ambiguous sentences are 1290 resolved with the authors. 1292 (ii) Enforces the formatting rules of Section 3 of RFC 1293 2223bis 1295 (iii) Ensures that sections follow guidelines and rules 1296 of Section 4 of RFC 2223bis 1298 (iv) Verifies the consistency of references and 1299 citations, and verifies contents of references to RFCs 1300 and I-Ds. 1302 (v) Verifies that all normative dependencies have been 1303 satisfied. 1305 (vi) Verifies that guidelines from Section 2 of RFC 2223bis 1306 are followed, with respect to: URLs, titles, 1307 abbreviations, IANA Considerations, author 1308 lists, and Requirement-Level words. 1310 (vii) Typesets the documents in the standard RFC style. 1312 (viii) Verifies the correctness of published MIBs and 1313 ABNF fragments, using compilers. 1315 (b) Providing authors with a review period of no less than 48 1316 hours to approve the document. 1318 (c) Publishing new RFCs online by installing them in the official 1319 RFC archive, which is accessible via HTTP, FTP, and SMTP. 1320 The RFC Editor also provides compressed aggregate files of 1321 subsets of the complete RFC series, accessible via HTTP and 1322 FTP. PDF facsimiles are also maintained for all .txt RFCs. 1324 (d) Publicly announcing the availability of new RFCs via a 1325 mailing list. 1327 (e) Coordinating with the IANA for assignment of protocol 1328 parameter values for RFCs in the submission queue. 1330 (f) Coordinating closely with the IESG to ensure that the rules 1331 of RFC 2026 (or replacement) are followed. RFC Editor 1332 personnel attend IETF meetings. A designated RFC Editor 1333 person serves as liaison to the IAB and IESG. 1335 (2) Individual Submission Publication 1337 The RFC Editor publishes technically competent and useful 1338 documents that arise outside the IETF process, in accordance 1339 with RFC 2026. The RFC Editor makes the final determination on 1340 the publishability of such documents, with review by the IESG 1341 and input from knowledgeable persons. 1343 The RFC Editor reviews all such documents for acceptable 1344 editorial quality and for content, and works with the authors 1345 when necessary to raise the quality to an acceptable level. 1347 (3) Online RFC meta-information 1349 The RFC editor publishes the following status information via 1350 the Web and FTP. 1352 (a) A list of all RFCs currently published, including complete 1353 bibliographic information and document status. This list 1354 is published both in human and machine-readable (XML) 1355 forms. 1357 (b) A document consisting of summaries of RFCs in each range of 100. 1359 (c) A list of errors found in published RFCs. 1361 (d) An "RFC Editor Queue" specifying the stage of every document 1362 in the process of editing, review, and publication. 1364 (e) An RFC Editor web site containing 1365 (i) A search engine for RFCs. 1366 (ii) Information on the RFC publication process. 1367 (iii) Links to the above published items. 1369 (4) Public Queries 1371 Responding to, and when appropriate, redirecting, a wide range of 1372 email queries received in the RFC Editor mailbox. 1374 II. Improved Process and Infrastructure 1376 When resources allow, the RFC Editor makes improvements to its 1377 processes and to the RFC repository infrastructure. This includes 1378 improvements and extensions to the set of scripts used by the RFC 1379 Editor: (i) to maintain its databases and web pages, and (ii) to 1380 increase the efficiency and quality of the editing process. 1382 Changes in procedure are often suggested by IETF members as well as 1383 by the IESG. Here are some examples of changes that are either in 1384 process or have been suggested for possible action in the future. 1386 (1) Publication process 1388 (a) Accepting documents in XML encoding when there 1389 is an accompanying tool that will produce nroff markup. 1391 (b) Studying the feasibility of editing the XML form of 1392 submitted documents, prior to producing the final nroff 1393 and .txt versions. 1395 (c) Adopting additional tools for verifying formal 1396 specification languages used in RFCs in addition to 1397 MIBs, PIBs, and ABNF. 1399 (2) Database Accessibility and Quality 1401 (d) Improving the usefulness of the Errata information 1402 (i) Distinguish mere typographic errors from 1403 errors of substance 1404 (ii) Link errata to RFC index on web page. 1406 (e) Providing Web-based "enhanced" views of RFCs, including: 1408 (i) Links to other related RFCs and references. 1409 (ii) Links to and from online errata pages. 1411 (3) Maintaining an online repository of the corrected values 1412 of MIBs that have been published in 1413 RFCs. 1415 (4) Completing the RFC Online project, to bring online those 1416 early RFCs that are available only in paper form. 1418 Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting 1419 Planning 1421 Secretariat Responses to Questions from 1422 IAB Advisory Committee 1423 November 7, 2003 1425 * (1) Your description of the function you are performing. 1426 * Is that function, and its relationship to the IETF, adequately 1427 * understood for working purposes, or is additional description 1428 * required? If the latter, what would you suggest? 1430 The Secretariat work is divided into four parts: Meeting Planning, 1431 WG support, IESG support, and IETF Community support. 1433 IETF meeting planning includes: identifying venues; negotiating 1434 contracts; working closely with the WG chairs and the IESG to 1435 schedule events and avoid conflicts; preparing the agendas 1436 for the WG sessions; arranging for F&B and AV; handling 1437 registration; seeking and signing up hosts; providing Internet 1438 access, a terminal room, and a wireless network when a host is not 1439 available; providing on-site support; and preparing the proceedings. 1440 Meeting planning also may include organizing the IESG retreat. 1442 WG support includes: maintaining and updating charters, milestones, 1443 and other information for the 140+ WGs; tracking changes in chairs; 1444 hosting and archiving the discussion mailing lists; and processing 1445 requests to publish IDs as RFCs. 1447 IESG support includes: providing all support required for IESG 1448 teleconferences, which take place every two weeks and cover as many 1449 as 20+ documents each (i.e., processing "Last Calls", preparing the 1450 agenda and package, moderating the teleconference, preparing the 1451 minutes, sending out approval announcements, and updating the 1452 information in the ID Tracker); tracking the movement of I-Ds to RFCs; 1453 interfacing with the RFC Editor; performing administrative functions 1454 associated with WG creation, rechartering, and closing; maintaining 1455 the internal IESG Web pages; sending miscellaneous message to the 1456 IETF announcement list on behalf of the IESG, and posting them to the 1457 Web site, where applicable (e.g., appeals to the IESG and IESG 1458 responses to appeals); providing support to the NomCom, as needed 1459 (i.e., sending announcements, hosting/updating the Web site, 1460 arranging for conference calls); and developing Web-based tools to 1461 support IESG decision-making. 1463 IETF Community support includes: running the IETF meetings; hosting 1464 the IETF Web site, and keeping the web site it up to date; hosting the 1465 IETF announcement and discussion lists; responding to enquiries sent 1466 to the IETF Secretariat, the Executive Director, the meeting Registrar, 1467 the Webmaster, and the trouble-ticket systems; processing Intellectual 1468 Property Rights Notices; processing Liaison Statements; and posting 1469 I-Ds. 1471 * (2) What staff is being used to perform these functions and 1472 * what are their particular skills for doing so (either 1473 * individually or in the aggregate)? 1475 -- Three people perform administrative functions. 1476 -- Four-and-a-half people perform technical support. 1477 -- One-and-a-half people do development. 1478 -- Three people do maintenance. 1480 * (3) What criteria do you use to determine whether you are being 1481 * successful, and how successful? Using those criteria, how 1482 * successful are you and what could be done, especially from the 1483 * IETF side, to improve that evaluation? 1485 The continued efficient operation and evolution of the Internet is one 1486 important goal and challenge facing the IETF, and also the IETF 1487 Secretariat. Working together to assist the IETF in performing this 1488 important function has been a motivating factor in CNRI's support for 1489 almost 15 years. The criteria followed by CNRI, and (more recently) 1490 its subsidiary Foretec, in their efforts on behalf of the entire 1491 Internet community is to provide a consistent and dependable mechanism 1492 that enables those persons interested in the many and varied issues 1493 that are raised within the IETF to perform their important work in the 1494 Internet standards process unburdened by the routine administrative 1495 tasks associated with such endeavors. While I think this has been a 1496 successful activity over many years, there is always room for 1497 improvement; and a continuing dialogue between CNRI, ISOC, and the IETF 1498 leadership is useful for this purpose. High on my list of suggestions 1499 would be finding a way to increase the funds available to meet the 1500 increasing demands placed on the Secretariat. We can no longer depend 1501 only on attendance fees at meetings for this purpose. 1503 * (4) How would you characterize the quality of your relationship 1504 * with the IETF and its leadership? Is there mutual trust and a 1505 * sense of working together on issues, or do you and your 1506 * colleagues sometimes see the relationship as adversarial? 1508 While the Foretec management may have issues arising from day to day 1509 workflow demands on limited resources, CNRI values the trusted 1510 relationship we have had with the IETF community. The issue is 1511 cooperating in the development of new funding sources, and learning to 1512 live within the available resources. There is also an issue about 1513 effective lines of authority for the purpose of carrying out certain 1514 aspects of the overall standards process. There are many demands and 1515 pressures on the IESG and hence on the Secretariat. These workflow 1516 demands need to be addressed in a more systematic way for the benefit 1517 of all. 1519 * (5) Are there specific known problems you would like us to look 1520 * at and understand? If so, please describe them. 1522 Workload is high. Given the budgetary constraints that the Secretariat 1523 is under, there are no resources to take on additional work. The 1524 staff supporting all areas are working overtime just to keep up with 1525 the current workload. 1527 The Secretariat does not believe that the IETF Community appreciates 1528 the scope of the tasks. The Secretariat is automating more tasks, 1529 hopefully reducing the overall workload. There is a long queue of 1530 requests for new features in the tools that the Secretariat has built. 1531 There is not money to hire more developers. The IETF Executive Director 1532 is documenting processes. This has naturally caused discussion about 1533 whether the processes are what everyone wants the processes to be. 1534 While expected, it also increases workload. 1536 * (6) How do you see the costs of your function evolving? If 1537 * things become more costly over time, what are the main 1538 * determiners of cost (e.g., general inflation, general IETF 1539 * growth, increase in the number of particular functions you are 1540 * carried out to perform,...). Are you doing some things that 1541 * IETF (IESG or otherwise) request that you do not consider 1542 * cost-effective and, if so, what are they? 1544 The total budget for IETF-related activities at Foretec last year was 1545 about $2.5M. The vast bulk was covered by IETF meeting fees, but the 1546 shortfall was covered by contributions from CNRI and Foretec. 1548 CNRI has been asked by its Board to find a solution to the problem. 1550 Appendix E. Consultation with ICANN: IANA protocol parameter assignment 1551 Responses to Questions from IAB Advisory Committee 1552 for the IANA Protocol Parameter Assignment Function 1554 November 7, 2003 1556 * (1) Your description of the function you are performing. Is that 1557 * function, and its relationship to the IETF, adequately described in 1558 * RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA considerations), 1559 * or is additional description required? If the latter, what would 1560 * you suggest? 1562 Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as 1563 an MOU describing the functions that the IANA provides to the IETF. 1564 That office consists of, effective soon, a manager, three technical 1565 clerical staff (four full-time equivalents) plus half a dozen people 1566 on a consulting basis, performing functions for the IETF and the RIRs. 1567 The portion of that effort supporting IETF parameter assignment is 1568 roughly a full-time-equivalent plus software support and normal 1569 management/employment overheads. Fundamentally, the IETF parameter 1570 assignment function consists of accepting requests for protocol 1571 numbers for extensible protocols (such as IP Protocol, PPP PID, TCP/UDP 1572 Port, and the like), validating them according to business rules, 1573 identifying the appropriate registry, and in some cases portion of a 1574 registry, assigning the number, and documenting the result. 1576 RFC 2434 has served the IANA staff well as a guide, but is now in need 1577 of updating. Specific concerns with the document relate to the meaning 1578 of terms and the specificity of the information provided to the IANA in 1579 internet drafts. 1581 One issue relates to the meaning of the term "IETF consensus". When a 1582 document has passed through a defined consensus process, such as a 1583 working group, this is straightforward. When requests come to IANA that 1584 have not done so, IANA needs specific guidance on IETF expectations. 1585 This generally comes in the form of AD direction or consulting advice. 1586 An improved process would help, though; business rules that inform the 1587 IANA when a new registry is appropriate, and what rules should be 1588 applied in assignment of values in any given registry, for example, 1589 would help. 1591 Parameter assignment being an essentially clerical function, specific 1592 guidance to the clerical staff is absolutely mandatory, and often 1593 lacking or unclear. In IANA's dreams, every internet draft would 1594 contain an IANA Considerations section, even if all it said was 1595 "IANA need not concern itself with this draft". In the absence of such 1596 a statement, the IESG's IANA Liaison is forced to read the entire 1597 document at least twice: once when the IESG is first handed the 1598 document, to ensure that any instructions to IANA are clear, and again 1599 when the IESG hands the document on, to ensure that it can perform the 1600 requests the draft makes. This is clearly time-consuming and prone to 1601 error. 1603 IANA is now receiving a certain level of instruction in internet drafts, 1604 which is good. However, even the present level of advice is frequently 1605 lacking in clarity. For example, a PPP NCP definition might well 1606 require the assignment of two PIDs, one for the data exchange and one 1607 for the NCP itself. These two numbers come from four very separate 1608 ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and C001..FFFF. The choice 1609 of range is important, especially on low speed lines using 1610 byte-oriented asynchronous transmission, as the data assignment has a 1611 trade-off implied for the relative frequency of messages using the 1612 specified protocol, and the control function PIDs are partitioned as 1613 well. In such a case, IANA needs to know not that "two PIDs are 1614 required", but that "two PPP PIDs are required, the data PID named 1615 from the range 0001..00FF, and the 1616 control PID named from 1617 the range 8001..BFFF". 1619 Descriptions of registries to be designed need to be equally clear. If 1620 the specification says in its IANA Considerations section that "a 1621 registry named 'Fubar Code Points' should be built; the initial values 1622 in a table and IANA may assign additional values in any 1623 remaining value between the last initial code point and 65535", that 1624 is exactly what will happen. If there are additional expectations, 1625 such as "the working group's assigned number advisor will be asked" 1626 or "all assignments must be made in an RFC of informational or 1627 standard status", they won't necessarily be met - unless the IANA 1628 Considerations section specifies as much. What you put in the IANA 1629 Considerations section is what will be followed. It should be made 1630 clear so that the implementors get what they requested. Also, clear 1631 IANA Considerations sections also help the community, not only IANA. 1632 It makes (1) the authors think about all aspects of the creation of a 1633 registry and instructions on how to maintain but also (2) the public 1634 knows and understands the new registry instructions and how they can 1635 get assignments/registrations in that registry. 1637 Something that would materially help the IANA in its evaluation of 1638 internet drafts is a comment tracking system on the IETF side. The 1639 IANA's use of such a system is apparent: any comments it makes on the 1640 draft would appear in the system, where the IESG may readily retrieve 1641 them, and the IANA can find its comments when the draft later comes 1642 there. To be truly helpful, it should also include at least any last 1643 call IETF commentary and AD commentary, including agreed changes to 1644 the document. This would permit IANA to review those notes as well, 1645 which may in turn elicit further IANA commentary ("if you make that 1646 change, you should also specify <> in the IANA Considerations section") 1647 or may guide IANA's implementation. 1649 Normative references apply to IANA considerations as well as to other 1650 parts of the specification. Recently, the IESG started passing 1651 documents along prior to other documents normative for them, allowing 1652 them to sit in later queues to synchronize with their normative 1653 documents. In the special case where the normative document defines a 1654 registry and the draft under discussion assigns a value from that 1655 registry, this case needs to be handled in queue and in process like 1656 any other normative reference. 1658 * (2) What staff is being used to perform these functions and what 1659 * are their particular skills for doing so (either individually or 1660 * in the aggregate)? 1662 The staff assigned to this function, on 4 November 2003, includes 1663 Michelle Cotton and an assistant. They are essentially intelligent 1664 clerical staff familiar with computer back office applications, but 1665 otherwise with no special technical training. For technical questions, 1666 they depend heavily on advisors within IANA or assigned by the IETF. 1668 It should be kept in mind that it is not the IANA's job to understand 1669 how every protocol works that is being defined in a new registry. The 1670 IANA needs to know how to create and maintain the registry 1671 administratively. 1673 * (3) What criteria do you use to determine whether you are being 1674 * successful, and how successful? Using those criteria, how 1675 * successful are you and what could be done, especially from the IETF 1676 * side, to improve that evaluation? 1678 The basic measure of success is the number of assignments made. 1680 Michelle's sense is that IANA is now moderately successful, however 1681 further improvement can be made internally and externally. 1683 Paul is defining web-based automation which should help various 1684 aspects of IANA's work, including in part the IETF IANA function. 1685 Michelle believes that this automation will materially help her 1686 timeliness. But for that to be carried out properly, clear business 1687 guidelines must be given IANA for each of the existing registries, 1688 guidelines whose application can be readily automated. This is likely 1689 an IETF effort, or at least requires serious IETF input. 1691 * (4) How would you characterize the quality of your relationship with 1692 * the IETF and its leadership? Is there mutual trust and a sense of 1693 * working together on issues, or do you and your colleagues sometimes 1694 * see the relationship as adversarial? 1696 At this point, Michelle feels that IETF/IAB leadership is friendly and 1697 generally constructive. She is very cognizant of AD workload, and as 1698 such tries to focus questions and find other people to ask them of. As 1699 such, she perceives the communication level and volume to be on the 1700 light side of "about right". 1702 Again, amplified clarity of IESG/WG policy would reduce her question 1703 load, and there may be utility for an IAB liaison from the IANA such as 1704 IANA has with the IESG. That is really a question for the IAB; if it 1705 has questions for IANA, the chair should feel free to invite her 1706 comment or invite a liaison. 1708 * (5) Are there specific known problems you would like us to look at 1709 * and understand? If so, please describe them. 1711 This note has made a point concerning clarity of instructions, clarity 1712 of policy, and clarity of registries. There is ongoing work at IANA to 1713 clean up registry files inherited when IANA was split out from the RFC 1714 Editor's office; in dealing with the business considerations questions 1715 already raised, it may be helpful for a tiger team from the IETF to 1716 review their registries with them and make suggestions. 1718 There is an ongoing problem with receiving announcements concerning at 1719 least some internet drafts. Michelle plans to follow up with the 1720 Secretariat on this, but in short it appears that the IANA liaison is 1721 not copied on at least some list that internet draft actions are 1722 announced on. This seems to pertain to individual submissions that the 1723 IESG advises the RFC Editor that it "has no problem" publishing. 1725 * (6) How do you see the costs of your function evolving? If things 1726 * become more costly over time, what are the main determiners of cost 1727 * (e.g., general inflation, general IETF growth, increase in the number 1728 * of >particular functions you are carried out to perform,...). Are you 1729 * doing some things that IETF (IESG or otherwise) request that you do 1730 * not consider cost-effective and, if so, what are they? 1731 As detailed, the function described in RFC 2860 represents approximately 1732 a person-equivalent, plus facilities, software support, and standard 1733 business loading. This has been the approximate load level for at 1734 least the past five years, and is projected to remain about the same 1735 for the near future. The cost-effectiveness issues revolve around 1736 human-in-the-loop effort involved in reading drafts, investigating 1737 inquiries, and such that have been detailed here. The sense is that an 1738 effective comment management system plus the work flow systems ICANN 1739 is planning to implement should result in a net near term improvement 1740 in efficiency and timeliness; projected IETF growth should then 1741 consume that improvement over time. 1743 Full Copyright Statement 1745 Copyright (C) The Internet Society (2003). All Rights Reserved. 1747 This document and translations of it may be copied and furnished to 1748 others, and derivative works that comment on or otherwise explain it 1749 or assist in its implementation may be prepared, copied, published 1750 and distributed, in whole or in part, without restriction of any 1751 kind, provided that the above copyright notice and this paragraph are 1752 included on all such copies and derivative works. However, this 1753 document itself may not be modified in any way, such as by removing 1754 the copyright notice or references to the Internet Society or other 1755 Internet organizations, except as needed for the purpose of 1756 developing Internet standards in which case the procedures for 1757 copyrights defined in the Internet Standards process must be 1758 followed, or as required to translate it into languages other than 1759 English. 1761 The limited permissions granted above are perpetual and will not be 1762 revoked by the Internet Society or its successors or assigns. 1764 This document and the information contained herein is provided on an 1765 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1766 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1767 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1768 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1769 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1771 Acknowledgement 1773 Funding for the RFC Editor function is currently provided by the 1774 Internet Society.