diff options
Diffstat (limited to 'doc/rfc/rfc3716.txt')
| -rw-r--r-- | doc/rfc/rfc3716.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc3716.txt b/doc/rfc/rfc3716.txt new file mode 100644 index 0000000..0c64916 --- /dev/null +++ b/doc/rfc/rfc3716.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group IAB Advisory Committee +Request for Comments: 3716 IETF +Category: Informational March 2004 + + + The IETF in the Large: Administration and Execution + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB + Advisory Committee (AdvComm), with a mandate to review the existing + IETF administrative structure and relationships (RFC Editor, IETF + Secretariat, IANA) and to propose changes to the IETF management + process or structure to improve the overall functioning of the IETF. + The AdvComm mandate did not include the standards process itself. + + This memo documents the AdvComm's findings and proposals. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Overview of the AdvComm Work Process and Output. . . . 3 + 1.2. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Next Steps . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Current IETF Support Structure . . . . . . . . . . . . 4 + 2.1.1. What the Term IETF Includes in this Document . 4 + 2.1.2. Functions. . . . . . . . . . . . . . . . . . . 4 + 2.1.3. Support. . . . . . . . . . . . . . . . . . . . 6 + 2.2. Observed Stress Points . . . . . . . . . . . . . . . . 8 + 2.2.1. Stress Points Observed by IETF Leadership. . . 8 + 2.2.2. Stress Points Observed by Organizations + Supporting the IETF. . . . . . . . . . . . . . 10 + 2.3. A final Observation. . . . . . . . . . . . . . . . . . 10 + 3. Stand Facing the Future: Requirements for a Successful + IETF Administration. . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Resource Management. . . . . . . . . . . . . . . . . . 10 + 3.1.1. Uniform Budgetary Responsibility . . . . . . . 10 + + + +IAB Advisory Committee Informational [Page 1] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + 3.1.2. Revenue Source Equivalence . . . . . . . . . . 11 + 3.1.3. Clarity in Relationship with Supporting + Organizations. . . . . . . . . . . . . . . . . 11 + 3.1.4. Flexibility in Service Provisioning. . . . . . 11 + 3.1.5. Administrative Efficiency. . . . . . . . . . . 11 + 3.2. Stewardship. . . . . . . . . . . . . . . . . . . . . . 12 + 3.2.1. Accountability for Change. . . . . . . . . . . 12 + 3.2.2. Persistence and Accessibility of Records . . . 12 + 3.3. Working Environment. . . . . . . . . . . . . . . . . . 12 + 3.3.1. Service Automation . . . . . . . . . . . . . . 12 + 3.3.2. Tools. . . . . . . . . . . . . . . . . . . . . 13 + 4. Advisory Committee Advice . . . . . . . . . . . . . . . . . 13 + 4.1. Proposed: (Single) Formalized IETF Organizational + Entity . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1.1. Comments on the Necessity of this + Formalization. . . . . . . . . . . . . . . . . 14 + 4.2. Possible Structures. . . . . . . . . . . . . . . . . . 14 + 4.2.1. ISOC . . . . . . . . . . . . . . . . . . . . . 15 + 4.2.2. ISOC Subsidiary. . . . . . . . . . . . . . . . 15 + 4.2.3. Completely Autonomous Organizational Entity. . 16 + 4.3. Who Can Decide . . . . . . . . . . . . . . . . . . . . 17 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . 17 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Informative References . . . . . . . . . . . . . . . . . . . 18 + A. IAB Advisory Committee Charter . . . . . . . . . . . . . . . 19 + B. Input from the current IETF and IAB Chairs . . . . . . . . . 20 + C. Consultation with ISI: RFC Editor . . . . . . . . . . . . . 21 + D. Consultation with Foretec/CNRI: Secretariat and Meeting + Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + E. Consultation with ICANN: IANA Protocol Parameter + Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 35 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 39 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 40 + +1. Introduction + + In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB + Advisory Committee (AdvComm), with a mandate to review the existing + IETF administrative structure and relationships (RFC Editor, IETF + Secretariat, IANA) and to propose changes to the IETF management + process or structure to improve the overall functioning of the IETF. + This purpose was defined in the IAB Advisory Committee (AdvComm) + charter, copied in Appendix A. The AdvComm mandate did not include + the standards process itself. + + + + + + + +IAB Advisory Committee Informational [Page 2] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + The tangible output of this committee is a set of observations and + recommendations for the IETF's executive structure - how the IETF + might be organizationally (re)structured so that it can effectively + and efficiently carry out its administrative activities. As a + necessary preamble to that, a description of the current issues and + future requirements is presented. The output does not represent any + decision-making or implementation -- see Section 1.3 for a discussion + of follow-on steps. + +1.1. Overview of the AdvComm Work Process and Output + + The AdvComm was formed in September 2003, and carried out its work + over the course of the following 2 months, prior to the IETF58 in + November of 2003. + + The AdvComm's membership included many of the individuals who are, or + have been, volunteered to manage the IETF's inter-organization + administrative relationships in recent years. The first phase of the + committee's work, therefore, included sharing and discussing the body + of tacit knowledge about those relationships. This included the + input from the current IETF and IAB Chairs in Appendix B, and yielded + the IETF organizational structure information in Section 2.1. + + The committee also sought input from the other end of the key + existing administrative relationships (RFC Editor, Secretariat, and + IANA). The output of those efforts is included in Appendix C, + Appendix D, and Appendix E, and these were also used as the basis for + the observations in Section 2. + + From these inputs, the committee drew together a list of requirements + for successful future IETF administration, documented in Section 3. + + Finally, the committee put together some advice for how the IETF + might consider reorganizing its administrative structure to meet + those requirements moving forward -- Section 4. + +1.2. Scope + + The AdvComm endeavored to stay focused on the IETF executive + structure -- the collection of organizations that work together to + bring the IETF's work to reality. However, by virtue of the very + fact that those relationships exist to get the work done, it was + important to bear in mind the work being done in the IETF PROBLEM + working group and IESG proposals for change, even as the committee + endeavored not to infringe on the scope of those efforts. The + objective is that these observations and proposals should be relevant + for today's IETF and any near-term evolutions that are deemed + appropriate. + + + +IAB Advisory Committee Informational [Page 3] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +1.3. Next Steps + + This documents the state of the AdvComm's thinking at the end of a + two month process, and brings the currently-chartered work of the + AdvComm to a close. + + Next steps include review of this material by the community, and + specific proposals for action that will be put forward by the IAB and + IETF Chairs. + +2. Observations + +2.1. Current IETF Support Structure + +2.1.1. What the Term IETF Includes in this Document + + RFC 3233 ([1]) provides a definition of the IETF, in terms of its + work and its participation. + + This document discusses the collection of organizations that work + together to support the effort described in RFC 3233. In this + document, the term "IETF" explicitly includes the IESG, WGs, IAB, + IRTF, and RGs. This inclusive sense accords with considerable common + usage of the term "IETF". Formally, the IAB and IRTF are chartered + independently of the IETF. However, rather than coming up with a new + term to encompass "the IETF and all its friends", the common usage is + followed here. + +2.1.2. Functions + + The work of the IETF is supported by a specific set of functions. It + is useful to distinguish between the functions and the organizations + which provide those services, as outlined in the table below. In + some cases a single organization provides multiple services, but the + functions are logically distinct. + + + + + + + + + + + + + + + + +IAB Advisory Committee Informational [Page 4] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + Function Known as Organization + (within the IETF) + --------- ---------------- ------------ + IESG Support Secretariat Foretec/CNRI + IAB Support ISOC/Secretariat ISOC, Foretec/CNRI + WG Support Secretariat Foretec/CNRI + Community Support Secretariat Foretec/CNRI + IETF Meetings Secretariat Foretec/CNRI + RFC Publication RFC Editor USC/ISI + Standards Status Record RFC Editor USC/ISI + Parameter Reg. IANA ICANN + Legal, insurance, etc. (largely invisible) Provided by ISOC + + Table 1. IETF functions, labels and organizations + + In more detail, the functions can be broken down as follows: + + IESG Support + + Telechats + Communications + IETF document tracking + Working document management (mailing list, website, repository) + + IAB support + + Telechats + Communications + Working document management (mailing list, website, repository) + + WG support + + Charters + Milestone tracking + Workspace (website, mailing list) + Working document archive (mailing list archives, document + repository) + + Community Support + + Website + IETF mailing list + Announcements + I-D repository + + + + + + + +IAB Advisory Committee Informational [Page 5] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + RFC Publication + + Website + RFC editorial + Document publication + RFC repository management + Official standards status record + + IETF Meetings + + Planning + Meeting Proceedings + + Protocol parameter registration + + Creation of registries + Assignment of protocol parameters + Management of accessible registry repository + + Legal, insurance, etc. + + Legal support + Liability insurance for IAB, IESG, WG chairs, etc. + Miscellaneous + +2.1.3. Support + + A presentation of the scope and depth of support that created the + IETF and has allowed it to continue to contribute would require a + discussion of history that is rich, vibrant, and completely beyond + the scope of this document. However, a very brief introduction to + some of the current pillars is needed to understand where the IETF is + today. + + ISOC: Since 1992, ISOC has been the organizational home of the + IETF. This activity is part of its more general mission of + serving as the international organization for global coordination + and cooperation on the Internet, promoting and maintaining a broad + spectrum of activities focused on the Internet's development, + availability, and associated technologies. + + Foretec/CNRI: The Corporation for National Research Initiatives + (CNRI) was founded in 1986, and since 1987, CNRI has served the + community by providing IETF Secretariat services. Until the early + 1990s, CNRI provided legal assistance to the IETF and the IETF + Secretariat. After ISOC was founded, ISOC assumed overall legal + responsibility for the substantive workings of the IETF including + the efforts of the IETF chair, the IESG, the IAB, the area + + + +IAB Advisory Committee Informational [Page 6] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + directors and the working group chairs. CNRI assumed operational + responsibility for the substantive workings of the IETF + Secretariat. In 1998, in order to decrease overhead costs on the + activities, the Secretariat was reorganized placing Secretariat + employees including the IETF Executive Director in a CNRI for- + profit subsidiary (Foretec Seminars, Inc.). Foretec was founded + in 1997, in anticipation of the Secretariat becoming self- + supporting. CNRI and its subsidiary have continued to improve the + operation of the Secretariat, as appropriate, and maintain a + trained staff. + + USC/ISI: The role of the RFC Editor, and USC/ISI, is detailed in + RFC 2555. The RFC document series is a set of technical and + organizational notes about the Internet (originally the ARPANET), + beginning in 1969. For 30 years, the RFC Editor was Jon Postel, a + research scientist and manager in the Networking Division of the + USC Information Sciences Institute (ISI), with the function + gradually evolving into a team headed by him. The RFC Editor + activity is currently organized as a project within ISI, using the + ISI infrastructure, and supported by a contract with ISOC. The + RFC Editor is the publisher of RFCs and is responsible for the + final editorial review of the documents, as well as the + maintenance of the online repository and index of those documents. + + ICANN: The Internet Corporation for Assigned Names and Numbers + (ICANN) is the non-profit corporation that was formed in 1998 to + assume responsibility for the IP address space allocation, + protocol parameter assignment, domain name system management, and + root server system management functions previously performed under + U.S. Government contract by IANA (at ISI) and other entities. + + The support picture (who does what) can be described as follows: + + Secretariat at Foretec/CNRI + + IESG Support + IAB Support (working document management) + WG Support + Community Support + IETF meetings + + RFC Editor at USC/ISI + + [Supported by ISOC, based on a contract between USC/ISI and ISOC] + + RFC publication Maintenance of standards status record + + + + + +IAB Advisory Committee Informational [Page 7] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + IANA/ICANN + + [Relationship defined by Memorandum of Understanding: RFC 2860] + + Protocol parameter registry + + ISOC + + IAB Support (Telechats) + Funds RFC Editor + Misc IAB/IESG expenses + Provides insurance for IAB, IESG, WG chairs, etc. + + The available resources to support these activities are: + + Meeting fees -- through Foretec + ISOC members' contributions for standards + ICANN for IANA + Volunteers/their employers (where applicable): + + IETF participants + WG chairs + Document editors + IETF NomCom + IESG + IAB + IAB ExecDir + +2.2. Observed Stress Points + + The AdvComm noted several properties of the current IETF + organizational environment that cause stress in the system. These + have been noted both from the point of view of the IETF leadership as + well as that of organizations supporting the IETF. + +2.2.1. Stress Points Observed by IETF Leadership + + The current IETF funding and operational structure is dependent on + IETF meeting attendance. Therefore, the most obvious stressor that + has emerged within the last two years is the decline in that + attendance. This trend, which has continued unabated, has resulted + in a decline in IETF revenue (detailed in the IETF chair presentation + at IETF 56 [2]), even as the requirements of the IETF operation are + remaining constant or increasing. + + + + + + + +IAB Advisory Committee Informational [Page 8] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + The result has been a budget deficit for operations which began in + 2002, and is forecasted to continue until at least 2004, even after a + substantial increase in meeting fees. The continuing deficits have + depleted working capital, making the IETF less robust against + potential future budgetary disappointments. + + The financial stress is real, but the IETF leadership has noted + several other stressors that are impediments to finding and + implementing solutions to the fiscal issues. Some obvious solutions + are not implementable in the current IETF structure. + + The rest of the stressors listed in this section should be understood + as issues for which relief is necessary, particularly in the light of + needing to properly address and implement solutions to the financial + stress. + + The current documentation of IETF processes and structure is, in + places, vague about the distribution of responsibility for management + and oversight of the IETF administrative relationships. This makes + it opaque to the IETF community, and sometimes leaves the leadership + in a poor position to manage effectively. + + Additionally, the informality of the relationships with some of the + organizations that are carrying out key IETF functions compounds the + problem of determining who has responsibility, and how IETF community + consensus and desires are reflected in the activity. + + As a separate issue, important IETF institutional memory is recorded + nowhere other than peoples' minds in many cases -- which requires + significant transmission of oral history for IETF leadership + transition to be effective. + + Apart from the institutional memory, other important IETF + institutional records are spread across various organizations, and + searching for the set of relevant documentation (especially when this + is necessary long after the recording) can be challenging. + + Another stressor relates to the need to scale support processes in + terms of reducing latency for mechanical processes. That is, a + decrease in the amount of manual labor required for the simpler tasks + between the organizations, would make more resources available to + focus on the special cases. Lack of automation in the basic request + services has been known to cause undue delay or failure in processing + simple, routine tasks. However, automation also requires resources + and significant management in order to make sure it fulfills the + community's requirements. + + + + + +IAB Advisory Committee Informational [Page 9] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +2.2.2. Stress Points Observed by Organizations Supporting the IETF + + Supporting organizations report difficulties in determining + authoritative channels for directions -- either too many inputs, or + no clear authority for resolution of change requests. + + In the absence of written agreements, supporting organizations may + not be clear from whom to take direction. Even where agreements + exist, the authority to provide direction may not be clear. The + genesis of both problems is that the IETF relies on external bodies + for support, but does not have sufficiently clear external + relationships to allow it to provide input as to its requirements or + direction on what services it desires. + +2.3. A Final Observation + + This section attempts to capture a snapshot of the current state of + the IETF organization, without undue fixation on the causes for + arriving at the current state. However, it seems clear from the + observations that the current state does not provide an adequate + structure from which to reach into the future: some changes are + needed within the IETF administrative and executive structure. + +3. Stand Facing the Future: Requirements for a Successful IETF + Administration + + This section follows the set of observations with a set of + requirements for a properly-functioning IETF administrative + structure. These requirements are offered as the AdvComm's + description of what the IETF needs, without addressing immediately + the degree to which they are available with the current environment. + That is, these are "requirements", not "requirements for change". + +3.1. Resource Management + +3.1.1. Uniform Budgetary Responsibility + + The IETF has operated in times of financial wealth and times of + economic cutbacks in the industry. It is reasonable to expect that + the future holds similarly variable trends. Therefore, it is + important that the IETF organization has the ability to make the + decisions to match its needs at a given point in time, i.e., + budgetary autonomy. At this particular moment, there are hard + choices to make, and the AdvComm believes that it is the IETF + leadership, with the advice and consent of the IETF community, that + needs to make them. + + + + + +IAB Advisory Committee Informational [Page 10] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +3.1.2. Revenue Source Equivalence + + The IETF is currently supported by money from multiple sources, + including meeting fees, donations from interested corporate and non- + corporate entities, and donations in kind of equipment or manpower. + The IETF needs to be able to consider all sources of income, and all + expenses involved in running the IETF, as pieces of one budget, to be + free to adjust all items on the occasions when the income from the + different sources varies, and to allocate funds as reasonably + required. + + The usual caveats apply: that donations not threaten the + independence of the IETF, and that donations are easier when they are + tax deductible. + +3.1.3. Clarity in Relationship with Supporting Organizations + + While the IETF needs to be able to manage its revenue streams against + its expense expectations, it also needs to respect the needs of + supporting organizations to manage their own affairs. That is, the + text above does not suggest that the IETF should micro-manage the + financial affairs of supporting organizations. + + However, the very clear requirement is for clarity in the + distribution of rights, responsibilities, and accountability in those + relationships. The usual mechanism for documenting such clarity is + in contract form. Thus, the IETF needs to have clear contractual + relationships with the organizations supporting basic services, + including meeting organization, secretarial services, IT services, + etc. + +3.1.4. Flexibility in Service Provisioning + + The IETF needs to be able to raise money for, and fund the + development of, additional services as appropriate. This includes + the development of tools for participants, repository management, + etc. + +3.1.5. Administrative Efficiency + + The IETF's needs should be met with the minimum of overhead. This + implies that there needs to be the possibility of combining work + efforts where appropriate, and generally avoiding duplication of + effort. + + + + + + + +IAB Advisory Committee Informational [Page 11] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +3.2. Stewardship + + The requirements described below focus primarily on the needs of the + IETF administration on a day-to-day basis. However, responsible + management includes stewardship for future IETF work. + +3.2.1. Accountability for Change + + The IETF needs to be responsible for changing its administrative + structure to meet the community's evolving needs. As such, the + administration needs to remain uniquely accountable to the IETF + community. + + This also means that the distribution of responsibilities must be + clear to the IETF community, in order to permit it to comment on + current actions or future plans, and also to allow it to take action + when its needs are not being adequately addressed. + + An implication of this is that responsibility for financial + management within the IETF needs to sit with individuals who are + accountable within the IETF organizational structure. + +3.2.2. Persistence and Accessibility of Records + + Much of the work of the IETF is focused on reaching decisions and + declaring closure. However, responsibility does not stop with the + declaration of completion. There are any number of reasons that + history must be adequately documented so that future work can review + substantive records, and not rely on oral history. + + Therefore, the IETF needs to maintain and support the archiving of + all of its working documents in a way that continues to be + accessible, for all current and future IETF workers. + +3.3. Working Environment + + Part of the job of administering the IETF is identifying and ensuring + the continued support of the tools and working environment necessary + to support the ongoing activity. + +3.3.1. Service Automation + + Wherever human judgment is not required in order to complete an + action, services should be automated to provide the most friction- + free path and minimal delay in completing the action. + + + + + + +IAB Advisory Committee Informational [Page 12] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + More processes could be accomplished without requiring human + judgment. Wherever possible, these processes should be identified, + clarified, and automated. + + Note that this is not intended to imply ALL processes should be + automated! Rather, by reducing the friction incurred in steps that + are truly mechanical, more time and energy will be available to + properly treat those that require individual judgment. + +3.3.2. Tools + + Whether housed in an IETF-supported location or offered by individual + contribution, the PROBLEM WG has identified the need for more tool + support for working groups and specification development. The IETF + needs to be able to identify, develop and support an adequately rich, + consistent set of tools for getting the standards work done. + +4. Advisory Committee Advice + + The Advisory Committee discussed the material and observations, + described in this document, at great length. To the AdvComm, it + appeared clear that some level of IETF administration organizational + change is needed to address the stressors and meet all of the + requirements outlined in Section 3. + +4.1. Proposed: (Single) Formalized IETF Organizational Entity + + In order to ensure an IETF structure that is capable of meeting the + requirements outlined above, the AdvComm recommends that the IETF be + more formally organized. This would allow the IETF to take full + responsibility for, and management of, the resources required to + accomplish its work (as described in Section 3.1), provide and + maintain the necessary work environment for current work (as + described in Section 3.3), and provide appropriate stewardship of the + institutional information required for all aspects of current and + future work of the organization (as described in Section 3.2). + + Some proposed models for establishing such a formalized effort are + described in the following sections. Some of the key expectations, + irrespective of the final implementation of formalism, are: + + o the administration of the IETF would remain accountable to the + IETF leadership and community; the goal would be to ensure that + lines of responsibility and accountability were clearer; + + o this formalized IETF would be responsible for managing financial + resources (revenue and expenses) directly; + + + + +IAB Advisory Committee Informational [Page 13] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + o this formalized IETF would be directly signatory to agreements + with other organizations, and would therefore be able to negotiate + and administer any appropriate contracts; + + o however implemented, this would require a small staff complement + (e.g., one full-time person) responsible to no other organization + than the one chartered with the IETF's mission; + + o nevertheless, it remains a non-goal to create an organizational + entity that exists simply for the purpose of continuing to exist. + This should be executed with the minimum formality needed in order + to address the identified requirements. + +4.1.1. Comments on the Necessity of this Formalization + + An important question is: what does this proposed formalization + provide that cannot be provided by the status quo? The AdvComm + believes that an appropriately implemented formalization of the IETF + would permit the unification of the resource management, decision + making and stewardship that is imperative to providing clarity and + ensuring a viable future for the IETF. The AdvComm further believes + that this is simply not possible to implement within the existing + distributed and informal arrangement of responsibilities. + + Naturally, the act of forming such an organization does not + immediately satisfy the requirements outlined in Section 3. It is + not a silver bullet. Changing the formal structure will not, for + example, change the financial status of the IETF. However, the + AdvComm believes it would provide the necessary basis from which the + required decisions could be made and acted upon. + + In short, the AdvComm believes that we first have to place the + responsibility for defining the IETF's administrative environment + with specific people who are accountable to the IETF community. Then + these people can take the detailed decisions that will change the + IETF's administrative environment to fulfill its requirements. + +4.2. Possible Structures + + Section 4.1 was deliberately vague on the nature of the formal + organizational entity that might provide the proper environment, + focusing instead on the key components of any implementation of such + a formalization, and how the formalization activity would address the + requirements laid out in Section 3. + + + + + + + +IAB Advisory Committee Informational [Page 14] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + Having thus determined that formalization of the IETF is seen as a + necessary step, the basic framework for 3 potential implementations + of it are described below. Note that these are not complete + proposals, nor is enough detail available to recommend a particular + path. The IETF leadership might select one to explore in greater + detail, to formulate an action proposal with sufficient detail to + make a decision to act. + +4.2.1. ISOC + + The IETF is organized as an activity of the Internet Society. One + potential path for increased formalism of the IETF's administration + would be to further define that relationship. This model anticipates + dedication of ISOC personnel to form the "small staff complement", + and would make ISOC responsible for all of the IETF's financial + resources and expenses. + + This approach should be relatively straightforward to implement, + given ISOC's existing legal relationship with the IETF activity, and + its status as signatory for IETF-related contracts (e.g., RFC + Editor). + + This proposal is consistent with the goal of minimizing the amount of + formalization needed to meet the requirements of the IETF. + + However, the general mission of ISOC is broader than the + standardization activity of the IETF, and the ISOC Board of Trustees + must stay focused on apportioning resources to meet that broader + mission. Would this approach allow the clear lines of responsibility + that are called for in Section 3? + +4.2.2. ISOC Subsidiary + + A modification of the proposal of housing the IETF central body + within ISOC is to create a legal not-for-profit subsidiary of ISOC, + with a mandate that is specifically focused on the IETF's mission. + This subsidiary would become the legal entity responsible for + managing the IETF's resources and expenses, and would become + signatory to any other legal instruments on the IETF's behalf. + + As a distinct legal entity in its own right, the subsidiary would be + independently responsible for achieving its mission. That level of + independence addresses the concern raised against the notion of + further formalizing the IETF within ISOC directly -- that the IETF + mission might be disrupted by the organization's need to tend to + other aspects of ISOC's broader mission. The role of the IETF + community, and the ISOC parent, in defining and supporting that + mission would be spelled out in the creation of the legal body. + + + +IAB Advisory Committee Informational [Page 15] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + The IETF might additionally consider what the most appropriate + governance model would be for this approach. If it is desirable to + remove some of the administrative burden from the IESG and IAB, such + a subsidiary might have its own Board of Trustees, composed of + members appointed by IETF and ISOC. Such a Board would be + responsible for reviewing activities and ensuring that the + organization's efforts were adequately in line with its mission, its + finances were in order, and so on. The subsidiary would report to + its Board of Trustees. Other governance models are certainly + possible, and a Board of Trustees is not a requirement for this + approach. + + At the same time, as a subsidiary organization, the expectation is + that the relationship with ISOC would remain a close one: the + subsidiary would benefit from ISOC's existing infrastructure and + support (a conservative approach to adding formalism and structural + overhead to the IETF activity), while the relationship would continue + to provide a channel for the IETF to support ISOC in achieving that + broader mission, with continued contribution of technical expertise + and support of activities. + + This approach would require more work to create than simply housing + the work at ISOC. The subsidiary would have to be created and + rights/responsibilities adjusted between it and ISOC in order to + ensure that both have the necessary resources and frameworks to carry + out their missions. + +4.2.3. Completely Autonomous Organizational Entity + + To complete the picture, a third option has to be considered. Instead + of creating a subsidiary of ISOC as a separate legal entity, an + entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be + created for the sole purpose of managing IETF administrative + activities. + + This would offer the IETF complete autonomy with all the attendant + rights and responsibilities. In particular, an independent IETF + would at a minimum, need to operate much like a startup for the first + few years of its existence, with all the related financing and growth + issues, and survival risks. Given all the organizational change + taking place within the IETF during the same period, the AdvComm + believes that the financial and political risks of such an approach + should not be under-estimated. + + For example, it would be necessary for the IETF to obtain initial + working capital sufficient to handle the commitments for the first + few meetings. While it would be conceivable to raise working capital + from advance meeting fees, such a financing plan would not leave much + + + +IAB Advisory Committee Informational [Page 16] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + margin for error; were one or more of the initial meetings to run in + the red, the survival of a fledgling IETF could be in jeopardy. Given + the economic environment, it probably should not be assumed that + working capital could be raised purely from corporate donations, + especially during an initial period in which staff required to + solicit and manage donations would not be available. + + Additionally, the impact that such a move would have on ISOC's + ability to carry out its mission and the IETF's standing with + governmental organizations needs to be considered. + +4.3. Who Can Decide + + The AdvComm believes that the IETF leadership, acting with the advice + and consent of the IETF community and ISOC, have the ability and the + responsibility to act on the recommendation to formalize the IETF. + +5. Security Considerations + + This document does not describe any technical protocols and has no + implications for network security. + +6. Acknowledgements + + The AdvComm sincerely appreciates the time, effort and care of the + RFC Editor, IANA, Secretariat and Secretariat organizations in + providing input, responding to the AdvComm's questions, and + reviewing/correcting the consultation text shown here in the + appendixes. + + The members of the IAB Advisory Committee that prepared this report + were: + + o Bernard Aboba + o Harald Alvestrand (IETF Chair) + o Lynn St.Amour (ISOC President) + o Fred Baker (Chair, ISOC Board of Trustees) + o Brian Carpenter + o Steve Crocker + o Leslie Daigle (IAB Chair, chair of the committee) + o Russ Housley + o John Klensin + + + + + + + + + +IAB Advisory Committee Informational [Page 17] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +7. Informative References + + [1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC + 3233, February 2002. + + [2] Alvestrand, H., "IETF Chair plenary presentation, http:// + www.ietf.org/proceedings/03mar/slides/plenary-3/index.html", + March 2003. + + [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC + 2223, October 1997. + + [4] Reynolds, J. and B. Braden, Eds., "Instructions to Request for + Comments (RFC) Authors", Work in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +IAB Advisory Committee Informational [Page 18] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +Appendix A. IAB Advisory Committee Charter + + Date: Tue, 02 Sep 2003 16:34:58 -0400 + From: Leslie Daigle + Subject: Formation of IAB Advisory Committee + To: IETF-Announce: ; + + I would like to announce the formation of an IAB advisory + committee, as described below. + + Thanks, + Leslie, + for the IAB. + + ================= + + IAB Advisory Committee on IETF Administration Relationships + + The purpose of the committee is to review the existing + IETF administration relationships (RFC Editor, IETF Secretariat, + etc.) and propose IETF management process or structural changes + that would improve the overall functioning of the + IETF. Any such proposal will be subject to review and + acceptance by the IAB and IETF plenary. Note that the scope of the + advisory committee does NOT include proposed changes to the standards + development processes (e.g., WG organization, IESG management of + documents or working groups, etc.). + + The committee is chaired by the IAB Chair, Leslie Daigle, and + consists of: + + o Bernard Aboba + o Harald Alvestrand (IETF Chair) + o Lynn St.Amour (ISOC President) + o Fred Baker (Chair, ISOC Board of Trustees) + o Brian Carpenter + o Steve Crocker + o Leslie Daigle (IAB Chair, chair of the committee) + o Russ Housley + o John Klensin + + Additional input is welcome. The committee will also make a + particular effort to seek out further input as needed. -- + + + + + + + + +IAB Advisory Committee Informational [Page 19] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +Appendix B. Input from the Current IETF and IAB Chairs + + Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle + (IAB Chair). + + Looking at the administrative overview of the IETF activity, there + are a number of things that work well: + + o support organizations are committed to the work of the IETF; + + o the volunteers of the IETF WGs can (mostly) concentrate on their + engineering work, not economics; + + o money has (so far) been sufficient to cover the costs. + + However, there are also a number of challenges: + + o lack of persistent records of the whole organization's efforts -- + of working documents, meeting materials, communications. Also, + + * lack of organization of records -- even when data is stored, it + can be hard or impossible to access when no longer current + (e.g., it may reside on some former WG chair's hard drive) + + * history records are kept spottily (lists of wg chairs and old + versions of charters, to mention some); + + o few safeguards against the "hit by a bus" problem -- much + information about relationships is not documented, and must be + transferred as oral tradition. This means that significant + overlap is needed when personnel changes; + + o IETF leadership responsibilities are not clearly identified -- + typically handled by IETF and IAB Chairs, with some advice and + consent from IESG and IAB, but that makes it possible to challenge + every change decision; + + o contracts do not clearly identify responsibility for executive + direction. Some contractual relationships are not documented, or + are not visible to the IETF leadership; + + o variable, and often unclear, documentation of responsibilities + between IETF leadership and other organizations. This makes it + hard to determine how and where to discuss and effect improvements + for the IETF that affect one or more support organization's + activity; + + + + + +IAB Advisory Committee Informational [Page 20] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + o unclear budgeting responsibilities -- the IETF leadership has to + make decisions that will impact the revenues and costs of the + supporting organizations, but the supporting organizations wear + the direct effects of revenue and cost control. Information about + the financial impact of decisions are not available to IETF + leadership; + + o partitioned finances -- it's not possible for the IETF to make + changes that would affect the balance of revenue and costs across + the revenue sources/expense commitments. For example, raising + meeting fees wouldn't pay for more RFC Editor resources; more + support from ISOC doesn't address any needs for IETF working group + support functions; + + o the lack of clarity and the partitioning make it very hard for the + IETF leadership, and the community as a whole, to determine points + of accountability and implement changes for a healthy future. + +Appendix C. Consultation with ISI: RFC Editor + + Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a + work in progress to update RFC 2223 [3]. + + Responses to Questions from IAB Advisory Committee + for the RFC Editor + + October 6, 2003 + + * + * (1) Your description of the function you are performing. Is + * that function, and its relationship to the IETF, adequately + * described in RFC 2223bis, or is additional description + * required? If the latter, what would you suggest? + + ANSWER: + + A comprehensive summary of current RFC Editor functions is attached + below. Note that this list has no direct relation to RFC 2223bis, + which contains instructions to RFC authors. + + * + * (2) What staff is being used to perform these functions and + * what are their particular skills for doing so (either + * individually or in the aggregate)? + * + + + + + + +IAB Advisory Committee Informational [Page 21] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + ANSWER: + + For 30 years, the RFC Editor was Jon Postel, a research scientist and + manager in the Networking Division of the USC Information Sciences + Institute (ISI). It is currently organized as a project within ISI, + using the ISI infrastructure. The following ISI staff members + comprise the RFC Editor project: + + Joyce Reynolds 100% + Bob Braden 10% + Aaron Falk 10% + Sandy Ginoza 100% + Project Assistant 100% + Graduate Research Asst. 50% + + Braden and Reynolds jointly manage the RFC Editor project, with + oversight of personnel and budgets. + + Joyce Reynolds has been contributing her editorial and management + skills to the Internet since 1979. She performed the IANA functions + under Jon Postel's direction from 1983 until Postel's death in + October 1998. She continued to perform the IANA protocol parameter + tasks on loan from ISI to ICANN, from 1998 to 2001. She was IANA + liaison to the IESG from 1998 to 2001, transitioning the role to + Michelle Cotton in the 2001. + + Reynolds performed the RFC Editor functions under Jon Postel's + direction from 1987 until 1998. Reynolds has been a member of the + IETF since 1988, and she served as User Services Area Director on the + IESG for 10 years. Reynolds now serves a liaison to the IAB and + IESG. She handles the final proofing and quality control on RFCs + prior to publication. + + Bob Braden has made many contributions to the Internet protocol + technology and community. He helped design TCP/IP during the + original research period beginning in 1978, and he has devoted his + professional career since 1978 to the Internet. He served for 13 + years on the original IAB and as its Executive Director for about 5 + years. Since 1998 Braden has been co-leader of the RFC Editor + project. He is the principal reviewer of individual submissions. He + also works on technical issues related to the RFC Editor project. + + Aaron Falk is a significant player in the IETF as a Working Group + chair, in the areas of transport protocols and satellite technology. + On the RFC Editor team, he assists with policy questions and handles + technical development, overseeing the work of the grad student + programmer. + + + + +IAB Advisory Committee Informational [Page 22] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + Sandy Ginoza is the principal technical editor. She is generally + responsible for managing the RFC Editor queue and much of the day- + to-day interface with the IESG and authors. Ginoza sends and + receives a LOT of email, and she plays a central role in the + operation. + + Two part-time Project Assistants, Mieke Van de Kamp and Alison De La + Cruz, do editing, mark-up, and initial proofing of individual RFCs. + Our goal is to have three pairs of eyes read every RFC word-for-word, + and in most instances we are able to do so. + + A half-time USC Graduate Research Assistant provides programming + support by developing, extending, and maintaining RFC Editor scripts + and tools. + + * (3) What criteria do you use to determine whether you are being + * successful, and how successful? Using those criteria, how + * successful are you and what could be done, especially from the + * IETF side, to improve that evaluation? + + ANSWER: + + We can begin with a historical perspective on this question. When + Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden + took on the challenge of carrying on Postel's RFC Editor function. + The publication stream continued, with a modest increase in quantity + and, we believe, no loss of quality. Furthermore, the transition was + largely invisible to the IETF. In addition, the new RFC Editor + project has significantly defined and clarified the publication + process, improved the web site, added tools to improve productivity + and quality, and adapted the procedures to changing realities. We + are proud of these achievements. + + The three primary axes for measuring RFC Editor success are (1) + quantity, (2) quality, and (3) accessibility. + + 1. Quantity + + Roughly, quantitative success means the ability to keep up with + the submission rate. Since the submission rate tends to be + bursty, to avoid long delays we need an average capacity somewhat + in excess of the average. + + RFC publication is necessarily a heavily labor-intensive process. + + + + + + + +IAB Advisory Committee Informational [Page 23] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + Our goal is generally to complete the publication process in less + than 4 weeks, exclusive of external factors beyond our control -- + normative dependence upon other documents, delays by authors or + the IESG, IANA delays, etc. + + 2. Quality + + Publication quality is harder to measure, but "we know it when we + see it." Considering quality as the absence of faults, by noting + faults we can observe lack of quality. + + One measure of faults is the number of errata that appear after + publication. In addition, there may be faults apparent to a + reader, such as a meaningless title, confusing organization, + useless Abstract, inadequate introduction, confusing formatting, + bad sentences, or bad grammar. There are of course limits to our + ability to repair bad writing; ultimately, quality depends upon + the authors as well as the editing process. + + The only way to maintain quality is to continually monitor our + work internally, to track external complaints, and to adjust our + practice to correct frequent faults. Specific faults have + sometimes led us to create new tools for checking consistency, to + avoid clerical errors. Sometimes they have led to new user + guidelines (e.g., on abbreviations or on Abstract sections.) + + 3. Accessibility + + An important part of the RFC Editor function is to provide a + database for locating relevant RFCs. This is actually a very hard + problem, because there is often a complex semantic web among RFCs + on a particular topic. We have made great improvements in our + search engine and web site, but there is undoubtedly a need for + more progress in this area. The challenge is to provide better + guideposts to users without creating a significant additional + manpower requirement. + + We make heavy use of our own search and access tools, and this + gives us feedback on their success and sometimes suggests + improvements. + + Finally, we offer some specific suggestions to answer the question, + "What can the IETF do to improve the RFC Editor's evaluation" (i.e., + our service to the community)? + + + + + + + +IAB Advisory Committee Informational [Page 24] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + 1. Give us better documents to publish. Many are well written and + organized, but some are bad and a few are very bad and need a + great deal of work to create acceptable publications. Better + input documents will improve both our quantity and our quality. + + The IESG has been making a large effort to improve the quality of + Internet Drafts before they become RFCs, and we are very grateful + for this. + + One issue of particular concern is the increasing number of RFCs + authored by non-English speakers. These can consume much extra + editorial effort. We don't know any solution to this problem, but + we know that the IESG is aware of it and working with them to + provide editorial assistance when necessary within working groups. + + 2. Prepare a series of RFCs containing "road maps" that describe the + semantic web of RFCs in a particular area. Although these would + rapidly become out-dated in detail, they would still provide very + important guides to RFC readers. + + The RFC Editor is as self-critical as any organization could be, but + we believe there is no objective basis for claiming that we are not + doing a good job for the Internet. We continually strive to do a + better job. + + * + * (4) How would you characterize the quality of your relationship + * with the IETF and its leadership? Is there mutual trust and a + * sense of working together on issues, or do you and your + * colleagues sometimes see the relationship as adversarial? + * + + ANSWER: + + The RFC Editor shares with much of the rest of the Internet community + a deep desire to advance the technology and practice of the Internet. + We consider ourselves partners with the IETF, the IESG, and the IAB + in this endeavor. + + Although the major goals coincide, the IESG and the RFC Editor quite + properly have somewhat different priorities. The RFC Editor's role, + historically and currently, is to create and maintain the RFC + document series as a high-quality and vital channel for technical + communication, while the IESG is concerned with managing the Internet + engineering and standards process. This difference sometimes leads + to honest disagreements, but we have generally worked out mutually- + satisfactory solutions to these conflicts. + + + + +IAB Advisory Committee Informational [Page 25] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + The word "adversarial" seems completely inappropriate, and we are + struggling to understand what could have led to its appearance here. + + * (5) Are there specific known problems you would like us to look + * at and understand? If so, please describe them. + + ANSWER: + + (A) The length of time for IESG review and recommendations on + individual submissions has sometimes become excessive. We + understand the load of IESG members, but we would like to ask + their help in keeping response to a few months. + + The RFC Editor has been attempting to raise the bar on accepting + individual submissions, to avoid wasting valuable IESG time as + well as to maintain (or improve) the quality of the RFC series. + + (B) We would like understanding and support of the RFC Editor's + statutory and historic responsibility to publish significant + technical documents about networking that originate outside the + IETF standards process. This publication has several important + purposes. + + One is to bring out new technical ideas for consideration and + discussion. We believe that the future success of the Internet + demands an infusion of new ideas (or old ideas revitalized), and + that the publication of such ideas as RFCs is important. + + Another purpose is to build a shared literature of mature + technical discussion, to help avoid the periodic re-discussions + that take place on our mailing lists. + + Finally, the RFC series provides a historic repository for + important ideas. We have come across a number of examples of + important suggestions and partial technology developments that + have been lost, or hard to locate, because they were not + published as RFCs. The community spends too much of our time + re-inventing many, many wheels. + + Our ultimate goal is to publish more high-quality submissions, so + we can raise the bar for publication. + + Independent submission publications represent only a minor + fraction of the RFC production. For example, so far in calendar + 2003 we have published 178 RFCs, including 14 independent + submissions. If all the drafts that we think deserve to be + + + + + +IAB Advisory Committee Informational [Page 26] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + preserved as RFCs were to be published, this fraction would grow, + but we would not expect it to grow beyond 25% of the total number + of published RFCs. + + (C) We would like to work with the IAB/IESG in re-examining the issue + of normative references. We believe that the current definition + of normative is ambiguous and unclear, and that as a result some + publications may be unnecessarily held up for normative + references where these are unnecessary. + + (D) We would like to cooperate in an investigation of the issues in + extending the character set beyond US-ASCII, .e.g., to UTF-8. A + major issue is whether there is a set of preparation, display, + and searching tools for both the RFC Editor and the RFC + consumers. These tools need to be ubiquitously available and + mature enough. + + The RFC Editor is looking for input on how we can best continue to + serve the community. We are grateful for the suggestions we have + received, and we have adopted as many of them as feasible; the result + has been quite a long list of incremental improvements in our service + over the past 5 years. + + * + * (6) How do you see the costs of your function evolving? If + * things become more costly over time, what are the main + * determiners of cost (e.g., general inflation, general IETF + * growth, increase in the number of particular functions you are + * carried out to perform,...). Are you doing some things that + * IETF (IESG or otherwise) request that you do not consider + * cost-effective and, if so, what are they? + * + * + + ANSWER: + + The major cost factor is the number of documents submitted and + published. This has grown relatively slowly over time. It appears + to us that the IETF process has (perhaps fortunately) been the + bottleneck that has kept the rate of RFC production from growing + exponentially. We do not expect that to change dramatically. + + In more detail, the cost factors are: + + (a) Inflation (on salaries) + + This shows a small and predictable annual increase. + + + + +IAB Advisory Committee Informational [Page 27] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + (b) The number of RFCs published. + + This is the primary cost factor. The bulk of the editorial + and coordinating functions are directly attributable to + specific documents. At present, we estimate that this cost + category represents 70% of our personnel time, and 63% of our + cost. + + (c) Tasks not directly related to specific RFCs. + + This includes many functions: management (budget and personnel + as well as policy and procedure development), IETF liaison, + reviews of independent submissions, development and + maintenance of web pages, scripts, and tools, the RFC Online + project, maintaining the Errata web page, etc. These are + currently estimated to require 30% of our personnel time, and + 37% of our cost. + + Minor extensions of function can be absorbed with little extra cost + (but at a leisurely pace). We are not proposing any major functional + extensions at this time; such extensions would have to be costed + separately (were money available for them.) + + Disk storage and web services are provided by ISI's support + organization and are treated as overhead. Most of the desktop + machines used by the project were originally bought under research + contracts, although the RFC Editor budget includes a very small item + for equipment upgrades. + +APPENDIX -- FUNCTIONS OF RFC EDITOR + + OVERVIEW + + The RFC Editor edits and publishes the archival series of RFC + (originally "Request for Comment") documents. The RFCs form an + archival series of memos about computer communication and packet + switching networks that records the technical history of the ARPAnet + and the Internet, beginning in 1969. The RFC Editor is funded by the + Internet Society and operates under the general direction of the IAB + (Internet Architecture Board). + + The RFC Editor publishes RFCs and a master index of the RFC series + electronically on the Internet, via all common access protocols + (currently, the Web, email, rsync, and FTP). It announces the + existence of each new RFC via electronic mail to one or more mailing + lists. The RFC Editor maintains a comprehensive web site with a + variety of tools and lists to locate and access RFCs. This website + + + + +IAB Advisory Committee Informational [Page 28] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + also contains general information about RFC editorial policies, + publication queue status, errata, and any other information that will + make the RFC series more accessible and more useful. + + During the RFC editing process, the RFC Editor strives for quality, + clarity, and consistency of style and format. Editorial guidelines + and procedures to achieve these ends are established by the RFC + Editor in consultation with the IAB and IESG (Internet Engineering + Steering Group). The RFC Editor periodically publishes a revision of + these its guidelines to authors. + + The RFC Editor coordinates closely with the IESG to carry out the + Internet standards process as documented in the latest revision of + "The Internet Standards Process" and later amendments. The RFC + Editor also coordinates closely with the Internet Assigned Numbers + Authority (IANA), to ensure that the parameters used in new and + revised protocol descriptions are properly registered. + + SPECIFIC TASKS + + I. Editing and publishing RFCs + + (1) Publication process. The RFC Editor edits and publishes RFCs in + accordance with RFC 2026 (or replacement documents) and RFC + 2223bis. This includes the following tasks: + + (a) Performing the final editing of the documents to maintain + consistency of style, editorial standards, and clarity. + + At minimum, the RFC Editor: + + (i) Copy-edits the documents, including the correction of + spelling and grammar, and some checking for + inconsistent notation. Ambiguous sentences are + resolved with the authors. + + (ii) Enforces the formatting rules of Section 3 of RFC + 2223bis + + (iii) Ensures that sections follow guidelines and rules of + Section 4 of RFC 2223bis. + + (iv) Verifies the consistency of references and citations, + and verifies contents of references to RFCs and I-Ds. + + (v) Verifies that all normative dependencies have been + satisfied. + + + + +IAB Advisory Committee Informational [Page 29] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + (vi) Verifies that guidelines from Section 2 of RFC 2223bis + are followed, with respect to: URLs, titles, + abbreviations, IANA Considerations, author lists, and + Requirement-Level words. + + (vii) Typesets the documents in the standard RFC style. + + (viii) Verifies the correctness of published MIBs and ABNF + fragments, using compilers. + + (b) Providing authors with a review period of no less than 48 + hours to approve the document. + + (c) Publishing new RFCs online by installing them in the official + RFC archive, which is accessible via HTTP, FTP, and SMTP. The + RFC Editor also provides compressed aggregate files of subsets + of the complete RFC series, accessible via HTTP and FTP. PDF + facsimiles are also maintained for all .txt RFCs. + + (d) Publicly announcing the availability of new RFCs via a mailing + list. + + (e) Coordinating with the IANA for assignment of protocol + parameter values for RFCs in the submission queue. + + (f) Coordinating closely with the IESG to ensure that the rules of + RFC 2026 (or replacement) are followed. RFC Editor personnel + attend IETF meetings. A designated RFC Editor person serves + as liaison to the IAB and IESG. + + (2) Individual Submission Publication + + The RFC Editor publishes technically competent and useful + documents that arise outside the IETF process, in accordance with + RFC 2026. The RFC Editor makes the final determination on the + publishability of such documents, with review by the IESG and + input from knowledgeable persons. + + The RFC Editor reviews all such documents for acceptable editorial + quality and for content, and works with the authors when necessary + to raise the quality to an acceptable level. + + (3) Online RFC meta-information + + The RFC editor publishes the following status information via the + Web and FTP. + + + + + +IAB Advisory Committee Informational [Page 30] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + (a) A list of all RFCs currently published, including complete + bibliographic information and document status. This list is + published both in human and machine-readable (XML) forms. + + (b) A document consisting of summaries of RFCs in each range of + 100. + + (c) A list of errors found in published RFCs. + + (d) An "RFC Editor Queue" specifying the stage of every document + in the process of editing, review, and publication. + + (e) An RFC Editor web site containing + + (i) A search engine for RFCs. + (ii) Information on the RFC publication process. + (iii) Links to the above published items. + + (4) Public Queries + + Responding to, and when appropriate, redirecting, a wide range of + email queries received in the RFC Editor mailbox. + + II. Improved Process and Infrastructure + + When resources allow, the RFC Editor makes improvements to its + processes and to the RFC repository infrastructure. This includes + improvements and extensions to the set of scripts used by the RFC + Editor: (i) to maintain its databases and web pages, and (ii) to + increase the efficiency and quality of the editing process. + + Changes in procedure are often suggested by IETF members as well as + by the IESG. Here are some examples of changes that are either in + process or have been suggested for possible action in the future. + + (1) Publication process + + (a) Accepting documents in XML encoding when there is an + accompanying tool that will produce nroff markup. + + (b) Studying the feasibility of editing the XML form of + submitted documents, prior to producing the final nroff + and .txt versions. + + (c) Adopting additional tools for verifying formal + specification languages used in RFCs in addition to MIBs, + PIBs, and ABNF. + + + + +IAB Advisory Committee Informational [Page 31] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + (2) Database Accessibility and Quality + + (d) Improving the usefulness of the Errata information + + (i) Distinguish mere typographic errors from errors of + substance + (ii) Link errata to RFC index on web page. + + (e) Providing Web-based "enhanced" views of RFCs, including: + + (i) Links to other related RFCs and references. + (ii) Links to and from online errata pages. + + (3) Maintaining an online repository of the corrected values of + MIBs that have been published in RFCs. + + (4) Completing the RFC Online project, to bring online those early + RFCs that are available only in paper form. + +Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting + Planning + + Secretariat Responses to Questions from + IAB Advisory Committee + + November 7, 2003 + + * (1) Your description of the function you are performing. Is that + * function, and its relationship to the IETF, adequately + * understood for working purposes, or is additional description + * required? If the latter, what would you suggest? + + The Secretariat work is divided into four parts: Meeting Planning, WG + support, IESG support, and IETF Community support. + + IETF meeting planning includes: identifying venues; negotiating + contracts; working closely with the WG chairs and the IESG to + schedule events and avoid conflicts; preparing the agendas for the WG + sessions; arranging for F&B and AV; handling registration; seeking + and signing up hosts; providing Internet access, a terminal room, and + a wireless network when a host is not available; providing on-site + support; and preparing the proceedings. Meeting planning also may + include organizing the IESG retreat. + + WG support includes: maintaining and updating charters, milestones, + and other information for the 140+ WGs; tracking changes in chairs; + hosting and archiving the discussion mailing lists; and processing + requests to publish IDs as RFCs. + + + +IAB Advisory Committee Informational [Page 32] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + IESG support includes: providing all support required for IESG + teleconferences, which take place every two weeks and cover as many + as 20+ documents each (i.e., processing "Last Calls", preparing the + agenda and package, moderating the teleconference, preparing the + minutes, sending out approval announcements, and updating the + information in the ID Tracker); tracking the movement of I-Ds to + RFCs; interfacing with the RFC Editor; performing administrative + functions associated with WG creation, rechartering, and closing; + maintaining the internal IESG Web pages; sending miscellaneous + message to the IETF announcement list on behalf of the IESG, and + posting them to the Web site, where applicable (e.g., appeals to the + IESG and IESG responses to appeals); providing support to the NomCom, + as needed (i.e., sending announcements, hosting/updating the Web + site, arranging for conference calls); and developing Web-based tools + to support IESG decision-making. + + IETF Community support includes: running the IETF meetings; hosting + the IETF Web site, and keeping the web site it up to date; hosting + the IETF announcement and discussion lists; responding to enquiries + sent to the IETF Secretariat, the Executive Director, the meeting + Registrar, the Webmaster, and the trouble-ticket systems; processing + Intellectual Property Rights Notices; processing Liaison Statements; + and posting I-Ds. + + * (2) What staff is being used to perform these functions and + * what are their particular skills for doing so (either + * individually or in the aggregate)? + + -- Three people perform administrative functions. + -- Four-and-a-half people perform technical support. + -- One-and-a-half people do development. + -- Three people do maintenance. + + * (3) What criteria do you use to determine whether you are being + * successful, and how successful? Using those criteria, how + * successful are you and what could be done, especially from the + * IETF side, to improve that evaluation? + + The continued efficient operation and evolution of the Internet is + one important goal and challenge facing the IETF, and also the IETF + Secretariat. Working together to assist the IETF in performing this + important function has been a motivating factor in CNRI's support for + almost 15 years. The criteria followed by CNRI, and (more recently) + its subsidiary Foretec, in their efforts on behalf of the entire + Internet community is to provide a consistent and dependable + mechanism that enables those persons interested in the many and + varied issues that are raised within the IETF to perform their + important work in the Internet standards process unburdened by the + + + +IAB Advisory Committee Informational [Page 33] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + routine administrative tasks associated with such endeavors. While I + think this has been a successful activity over many years, there is + always room for improvement; and a continuing dialogue between CNRI, + ISOC, and the IETF leadership is useful for this purpose. High on my + list of suggestions would be finding a way to increase the funds + available to meet the increasing demands placed on the Secretariat. + We can no longer depend only on attendance fees at meetings for this + purpose. + + * (4) How would you characterize the quality of your relationship + * with the IETF and its leadership? Is there mutual trust and a + * sense of working together on issues, or do you and your + * colleagues sometimes see the relationship as adversarial? + + While the Foretec management may have issues arising from day to day + workflow demands on limited resources, CNRI values the trusted + relationship we have had with the IETF community. The issue is + cooperating in the development of new funding sources, and learning + to live within the available resources. There is also an issue about + effective lines of authority for the purpose of carrying out certain + aspects of the overall standards process. There are many demands and + pressures on the IESG and hence on the Secretariat. These workflow + demands need to be addressed in a more systematic way for the benefit + of all. + + * (5) Are there specific known problems you would like us to look + * at and understand? If so, please describe them. + + Workload is high. Given the budgetary constraints that the + Secretariat is under, there are no resources to take on additional + work. The staff supporting all areas are working overtime just to + keep up with the current workload. + + The Secretariat does not believe that the IETF Community appreciates + the scope of the tasks. The Secretariat is automating more tasks, + hopefully reducing the overall workload. There is a long queue of + requests for new features in the tools that the Secretariat has + built. There is not money to hire more developers. The IETF + Executive Director is documenting processes. This has naturally + caused discussion about whether the processes are what everyone wants + the processes to be. While expected, it also increases workload. + + * (6) How do you see the costs of your function evolving? If + * things become more costly over time, what are the main + * determiners of cost (e.g., general inflation, general IETF + * growth, increase in the number of particular functions you are + + + + + +IAB Advisory Committee Informational [Page 34] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + * carried out to perform,...). Are you doing some things that + * IETF (IESG or otherwise) request that you do not consider + * cost-effective and, if so, what are they? + + The total budget for IETF-related activities at Foretec last year was + about $2.5M. The vast bulk was covered by IETF meeting fees, but the + shortfall was covered by contributions from CNRI and Foretec. + + CNRI has been asked by its Board to find a solution to the problem. + +Appendix E. Consultation with ICANN: IANA protocol + Parameter Assignment + + Responses to Questions from IAB Advisory Committee + for the IANA Protocol Parameter Assignment Function + + November 7, 2003 + + * (1) Your description of the function you are performing. Is that + * function, and its relationship to the IETF, adequately described in + * RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA + * considerations), or is additional description required? If the + * latter, what would you suggest? + + Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as + an MOU describing the functions that the IANA provides to the IETF. + That office consists of, effective soon, a manager, three technical + clerical staff (four full-time equivalents) plus half a dozen people + on a consulting basis, performing functions for the IETF and the + RIRs. The portion of that effort supporting IETF parameter + assignment is roughly a full-time-equivalent plus software support + and normal management/employment overheads. Fundamentally, the IETF + parameter assignment function consists of accepting requests for + protocol numbers for extensible protocols (such as IP Protocol, PPP + PID, TCP/UDP Port, and the like), validating them according to + business rules, identifying the appropriate registry, and in some + cases portion of a registry, assigning the number, and documenting + the result. + + RFC 2434 has served the IANA staff well as a guide, but is now in + need of updating. Specific concerns with the document relate to the + meaning of terms and the specificity of the information provided to + the IANA in internet drafts. + + One issue relates to the meaning of the term "IETF consensus". When + a document has passed through a defined consensus process, such as a + working group, this is straightforward. When requests come to IANA + + + + +IAB Advisory Committee Informational [Page 35] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + that have not done so, IANA needs specific guidance on IETF + expectations. This generally comes in the form of AD direction or + consulting advice. An improved process would help, though; business + rules that inform the IANA when a new registry is appropriate, and + what rules should be applied in assignment of values in any given + registry, for example, would help. + + Parameter assignment being an essentially clerical function, specific + guidance to the clerical staff is absolutely mandatory, and often + lacking or unclear. In IANA's dreams, every internet draft would + contain an IANA Considerations section, even if all it said was "IANA + need not concern itself with this draft". In the absence of such a + statement, the IESG's IANA Liaison is forced to read the entire + document at least twice: once when the IESG is first handed the + document, to ensure that any instructions to IANA are clear, and + again when the IESG hands the document on, to ensure that it can + perform the requests the draft makes. This is clearly time-consuming + and prone to error. + + IANA is now receiving a certain level of instruction in internet + drafts, which is good. However, even the present level of advice is + frequently lacking in clarity. For example, a PPP NCP definition + might well require the assignment of two PIDs, one for the data + exchange and one for the NCP itself. These two numbers come from + four very separate ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and + C001..FFFF. The choice of range is important, especially on low + speed lines using byte-oriented asynchronous transmission, as the + data assignment has a trade-off implied for the relative frequency of + messages using the specified protocol, and the control function PIDs + are partitioned as well. In such a case, IANA needs to know not that + "two PIDs are required", but that "two PPP PIDs are required, the + data PID named <d-name$gt; defined in section <> from the range + 0001..00FF, and the control PID named <c-name$gt; defined in section + <> from the range 8001..BFFF". + + Descriptions of registries to be designed need to be equally clear. + If the specification says in its IANA Considerations section that "a + registry named 'Fubar Code Points' should be built; the initial + values in a table <name> and IANA may assign additional values in any + remaining value between the last initial code point and 65535", that + is exactly what will happen. If there are additional expectations, + such as "the working group's assigned number advisor will be asked" + or "all assignments must be made in an RFC of informational or + standard status", they won't necessarily be met - unless the IANA + Considerations section specifies as much. What you put in the IANA + Considerations section is what will be followed. It should be made + clear so that the implementors get what they requested. Also, clear + IANA Considerations sections also help the community, not only IANA. + + + +IAB Advisory Committee Informational [Page 36] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + It makes (1) the authors think about all aspects of the creation of a + registry and instructions on how to maintain but also (2) the public + knows and understands the new registry instructions and how they can + get assignments/registrations in that registry. + + Something that would materially help the IANA in its evaluation of + internet drafts is a comment tracking system on the IETF side. The + IANA's use of such a system is apparent: any comments it makes on the + draft would appear in the system, where the IESG may readily retrieve + them, and the IANA can find its comments when the draft later comes + there. To be truly helpful, it should also include at least any last + call IETF commentary and AD commentary, including agreed changes to + the document. This would permit IANA to review those notes as well, + which may in turn elicit further IANA commentary ("if you make that + change, you should also specify <> in the IANA Considerations + section") or may guide IANA's implementation. + + Normative references apply to IANA considerations as well as to other + parts of the specification. Recently, the IESG started passing + documents along prior to other documents normative for them, allowing + them to sit in later queues to synchronize with their normative + documents. In the special case where the normative document defines + a registry and the draft under discussion assigns a value from that + registry, this case needs to be handled in queue and in process like + any other normative reference. + + * (2) What staff is being used to perform these functions and what + * are their particular skills for doing so (either individually or + * in the aggregate)? + + The staff assigned to this function, on 4 November 2003, includes + Michelle Cotton and an assistant. They are essentially intelligent + clerical staff familiar with computer back office applications, but + otherwise with no special technical training. For technical + questions, they depend heavily on advisors within IANA or assigned by + the IETF. + + It should be kept in mind that it is not the IANA's job to understand + how every protocol works that is being defined in a new registry. + The IANA needs to know how to create and maintain the registry + administratively. + + * (3) What criteria do you use to determine whether you are being + * successful, and how successful? Using those criteria, how + * successful are you and what could be done, especially from the IETF + * side, to improve that evaluation? + + The basic measure of success is the number of assignments made. + + + +IAB Advisory Committee Informational [Page 37] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + Michelle's sense is that IANA is now moderately successful, however + further improvement can be made internally and externally. + + Paul is defining web-based automation which should help various + aspects of IANA's work, including in part the IETF IANA function. + Michelle believes that this automation will materially help her + timeliness. But for that to be carried out properly, clear business + guidelines must be given IANA for each of the existing registries, + guidelines whose application can be readily automated. This is + likely an IETF effort, or at least requires serious IETF input. + + * (4) How would you characterize the quality of your relationship + * with the IETF and its leadership? Is there mutual trust and a + * sense of working together on issues, or do you and your + * colleagues sometimes see the relationship as adversarial? + + At this point, Michelle feels that IETF/IAB leadership is friendly + and generally constructive. She is very cognizant of AD workload, + and as such tries to focus questions and find other people to ask + them of. As such, she perceives the communication level and volume + to be on the light side of "about right". + + Again, amplified clarity of IESG/WG policy would reduce her question + load, and there may be utility for an IAB liaison from the IANA such + as IANA has with the IESG. That is really a question for the IAB; if + it has questions for IANA, the chair should feel free to invite her + comment or invite a liaison. + + * (5) Are there specific known problems you would like us to look at + * and understand? If so, please describe them. + + This note has made a point concerning clarity of instructions, + clarity of policy, and clarity of registries. There is ongoing work + at IANA to clean up registry files inherited when IANA was split out + from the RFC Editor's office; in dealing with the business + considerations questions already raised, it may be helpful for a + tiger team from the IETF to review their registries with them and + make suggestions. + + There is an ongoing problem with receiving announcements concerning + at least some internet drafts. Michelle plans to follow up with the + Secretariat on this, but in short it appears that the IANA liaison is + not copied on at least some list that internet draft actions are + announced on. This seems to pertain to individual submissions that + the IESG advises the RFC Editor that it "has no problem" publishing. + + + + + + +IAB Advisory Committee Informational [Page 38] + +RFC 3716 The IETF: Administration and Execution March 2004 + + + * (6) How do you see the costs of your function evolving? If things + * become more costly over time, what are the main determiners of + * cost (e.g., general inflation, general IETF growth, increase in the + * number of particular functions you are carried out to + * perform,...). Are you doing some things that IETF (IESG or + * otherwise) request that you do not consider cost-effective and, + * if so, what are they? + + As detailed, the function described in RFC 2860 represents + approximately a person-equivalent, plus facilities, software support, + and standard business loading. This has been the approximate load + level for at least the past five years, and is projected to remain + about the same for the near future. The cost-effectiveness issues + revolve around human-in-the-loop effort involved in reading drafts, + investigating inquiries, and such that have been detailed here. The + sense is that an effective comment management system plus the work + flow systems ICANN is planning to implement should result in a net + near term improvement in efficiency and timeliness; projected IETF + growth should then consume that improvement over time. + +Author's Address + + IAB Advisory Committee + IETF + + EMail: iab@iab.org + + + + + + + + + + + + + + + + + + + + + + + + + +IAB Advisory Committee Informational [Page 39] + +RFC 3716 The IETF: Administration and Execution March 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +IAB Advisory Committee Informational [Page 40] + |