RFC 3716

IETF in the Large: Administration and Execution

📅 published March 2004, from ietf

Status of this Memo ✨

okay so first things first, the Status of this Memo 💅. This memo is informational 🎀. It's giving "here's some info for the Internet community," NOT a standard. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 🌈, so share it with everyone bestie.

Copyright Notice 💜

Abstract 🦋

Let's set the scene 🎬. In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), and their mandate was to look at the current IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and propose changes to the IETF management process or structure so the whole IETF runs better. The AdvComm mandate did NOT include the standards process itself 🙅‍♀️.

This memo documents what the AdvComm found and what it proposed 📝✨.

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
          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 🎀

Okay so the IETF Chair and the IAB Chair formed this IAB Advisory Committee (AdvComm) back in the fall of 2003 🍂. Its whole job was reviewing the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA), then proposing changes to the IETF management process or structure to make the overall functioning of the IETF better 💖. The purpose is written down in the AdvComm charter, which you can read in Appendix A. And again, the AdvComm mandate did NOT include the standards process itself 🙅‍♀️.

The big output here is a set of observations and recommendations for the IETF's executive structure 👑. Basically, how could the IETF be organized (or reorganized) so it can handle its administrative stuff effectively and efficiently? Before getting to that, the document lays out the current issues and future requirements as a necessary preamble ✨. Also, this output is NOT a decision or an implementation. Check Section 1.3 for what happens next 🦋.

1.1. Overview of the AdvComm Work Process and Output 🌸

The AdvComm was formed in September 2003 and worked for about 2 months after that, wrapping up before IETF58 in November of 2003 ⏰.

A lot of the AdvComm members are people who have volunteered to manage the IETF's inter-organization administrative relationships in recent years 🫶. So the first phase was basically sharing and talking through all that tacit knowledge about those relationships 🧠. That included input from the current IETF and IAB Chairs (Appendix B), and it's where the IETF organizational structure information in Section 2.1 came from 📚.

The committee also went to the other end of those key relationships (RFC Editor, Secretariat, and IANA) to get their side 🙌. That output lives in Appendix C, Appendix D, and Appendix E, and it was also used as the basis for the observations in Section 2 👀.

From all of those inputs, the committee made a list of requirements for successful future IETF administration, which you'll find in Section 3 📋.

Finally, the committee came up with some advice on how the IETF might reorganize its administrative structure to meet those requirements going forward. That's Section 4 💅.

1.2. Scope 🧚

The AdvComm tried really hard to stay focused on the IETF executive structure, which is the collection of organizations that work together to make the IETF's work happen 🛠️. BUT, because those relationships exist to get the work done, it mattered to keep the work of the IETF PROBLEM working group and the IESG's proposals for change in mind 👀. The committee also tried NOT to step on the toes of those efforts 🙈. The goal is that these observations and proposals stay relevant for today's IETF and any near-term evolutions that are deemed appropriate 💜.

1.3. Next Steps 🍓

This document captures where the AdvComm's thinking landed at the end of a two-month process, and it wraps up the AdvComm's currently chartered work 🎀.

What's next? Community review of this material 👥, plus specific proposals for action that the IAB and IETF Chairs will put forward 📣. Stay tuned, bestie ✨.

2. Observations 🌸

2.1. Current IETF Support Structure 🌈

2.1.1. What the Term IETF Includes in this Document 🦋

Okay, so RFC 3233 ([1]) is where the IETF gets defined, in terms of its work and its participation 📖.

This document talks about the group of organizations that work together to support the effort described in RFC 3233 🫶. And here, the term "IETF" explicitly includes the IESG, WGs, IAB, IRTF, and RGs 💅. That's a pretty inclusive way of using the word, but it matches how people commonly use "IETF" anyway 🙌. Formally, the IAB and IRTF are chartered independently of the IETF, but instead of inventing a brand new term for "the IETF and all its friends," the document just goes with common usage 💜✨.

2.1.3. Support 💖

Okay bestie, the full history of who has held the IETF up is an epic 🎀 It's rich, it's vibrant, and it is completely out of scope for this doc 😭 But we need a quick peek at the current pillars so we know where the IETF is today 🦋

ISOC 🌸 Since 1992, ISOC has been the organizational home of the IETF. This is part of its bigger mission 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 took on overall legal responsibility for the substantive workings of the IETF, including the efforts of the IETF chair, the IESG, the IAB, the area directors and the working group chairs. CNRI took on operational responsibility for the substantive workings of the IETF Secretariat. In 1998, 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) looks like this 👑

   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

   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.

And the available resources to support all of this come from:

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 noticed several properties of the current IETF organizational environment that cause stress in the system. These were noted both from the point of view of the IETF leadership and from that of the organizations supporting the IETF.

2.2.1. Stress Points Observed by IETF Leadership 📉

The current IETF funding and operational structure depends on IETF meeting attendance. So the most obvious stressor to pop up in the last two years is the decline in that attendance 💀 This trend has continued unabated, and it has led to a drop in IETF revenue (detailed in the IETF chair presentation at IETF 56 [2]), even as the requirements of the IETF operation remain constant or increase.

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 also noted several other stressors that get in the way of finding and implementing solutions to the fiscal issues. Some obvious solutions are not implementable in the current IETF structure.

The rest of the stressors in this section should be understood as issues where relief is necessary, especially given the need to properly address and implement solutions to the financial stress.

The current documentation of IETF processes and structure is, in places, vague about how responsibility for management and oversight of the IETF administrative relationships is distributed. This makes it opaque to the IETF community, and sometimes leaves the leadership in a poor position to manage effectively 🙈

Also, the informality of the relationships with some of the organizations carrying out key IETF functions makes it even harder to tell 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 people's minds in many cases 🧠 That means IETF leadership transitions only work well with a lot of oral history being passed along.

Apart from institutional memory, other important IETF institutional records are spread across various organizations, and searching for the relevant documentation (especially long after it was recorded) can be challenging 🔍

Another stressor is the need to scale support processes by reducing latency for mechanical processes. In other words, cutting the amount of manual labor needed for the simpler tasks between the organizations would free up more resources to focus on the special cases ⭐ Lack of automation in basic request services has been known to cause undue delay or failure when processing simple, routine tasks. But automation also takes resources and significant management to make sure it fulfills the community's requirements 🤓

2.2.2. Stress Points Observed by Organizations Supporting the IETF 🫶

Supporting organizations report difficulty in figuring out authoritative channels for direction 🌀 There are either too many inputs, or no clear authority for resolving change requests.

Without written agreements, supporting organizations may not be clear about who to take direction from. Even where agreements exist, the authority to provide direction may not be clear. The root of both problems is that the IETF relies on external bodies for support, but does not have sufficiently clear external relationships to let it provide input on its requirements or on the direction of the services it wants 💅

2.3. A Final Observation 🔮

This section tries to capture a snapshot of the current state of the IETF organization, without undue fixation on the causes of arriving at that state. Still, it seems clear from these observations that the current state does not provide an adequate structure 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 observations with a set of requirements for a properly functioning IETF administrative structure. The AdvComm offers these as its description of what the IETF needs, without immediately addressing how much of it is available in the current environment. In other words, these are "requirements", not "requirements for change" 🎯

3.1. Resource Management 💰

3.1.1. Uniform Budgetary Responsibility 🧾

The IETF has operated through times of financial wealth and times of economic cutbacks in the industry, so it's reasonable to expect that the future holds similarly variable trends. That makes it important that the IETF organization can make the decisions needed 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 it is the IETF leadership, with the advice and consent of the IETF community, that needs to make them 👑

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. It also needs to be free to adjust all items when income from the different sources varies, and to allocate funds as reasonably required 🌈

The usual caveats apply: donations should not threaten the independence of the IETF, and donations are easier when they are tax deductible 🎀

3.1.3. Clarity in Relationship with Supporting Organizations 🤝

The IETF needs to manage its revenue streams against its expense expectations, but it also needs to respect the needs of supporting organizations to manage their own affairs. The text above does not suggest that the IETF should micro-manage the financial affairs of supporting organizations 🙅‍♀️

The very clear requirement, though, is for clarity in the distribution of rights, responsibilities, and accountability in those relationships. The usual way to document that clarity is in contract form. So the IETF needs 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. That 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 🦋

3.2. Stewardship 🌸

The requirements described below focus mainly on the needs of the IETF administration on a day-to-day basis. Responsible management, though, also includes stewardship for future IETF work 🔮

3.2.1. Accountability for Change ✨

okay so the IETF has to be responsible for changing its own admin structure so it keeps up with what the community actually needs 💅 which means the admin side has to stay uniquely accountable to the IETF community. no cap, that's the whole point.

this also means the distribution of responsibilities must be clear to the IETF community 🫶 so people can weigh in on what's happening now or what's planned, and also step up when their needs aren't being handled. main character energy for the community, not the admins 👑

and the implication is that responsibility for financial management in the IETF needs to sit with individuals who are accountable inside the IETF's organizational structure. ngl that's just basic common sense 🎀

3.2.2. Persistence and Accessibility of Records

bestie, a lot of IETF work is about reaching decisions and declaring something closed 🦋 but responsibility doesn't just vanish once a thing is "done." there are so many reasons history has to be properly documented, so future work can look at real records and not just rely on oral history 🙈

so the IETF needs to maintain and support archiving of all of its working documents in a way that stays accessible for all current and future IETF workers. it's giving legacy and I'm obsessed 🌸

3.3. Working Environment

part of administering the IETF is figuring out, and keeping up, the tools and working environment needed to support the ongoing activity 🧚

3.3.1. Service Automation

wherever human judgment isn't needed to finish an action, services should be automated so the path is the most friction-free it can be and the delay is minimal ✨ no more clicking through hoops for stuff a computer can just do 💀

more processes could get done without human judgment too! wherever possible, those processes should be identified, clarified, and automated 🍓

Note that this is not intended to imply ALL processes should be automated! 💖

the point is that by cutting friction in steps that are truly mechanical, there's more time and energy left to properly handle the stuff that actually needs individual judgment 🫶

3.3.2. Tools

whether a tool lives in an IETF-supported location or comes from individual contributions, the PROBLEM WG has spotted 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 so the standards work actually gets done 💜

4. Advisory Committee Advice ✨

the AdvComm talked through the material and observations in this document at great length 😭 and to them it was super clear that some level of organizational change in IETF administration is needed. it's the only way to address the stressors and meet all of the requirements outlined in Section 3 👑

4.1. Proposed: (Single) Formalized IETF Organizational Entity

so to make sure the IETF has a structure that can actually meet the requirements above, the AdvComm recommends that the IETF get more formally organized 🎀 this would let the IETF take full responsibility for, and management of, the resources needed to get its work done (as described in Section 3.1), provide and maintain the necessary work environment for current work (as described in Section 3.3), and provide proper stewardship of the institutional info needed for all aspects of current and future work of the organization (as described in Section 3.2) 💅

there are some proposed models for setting this up in the following sections. no matter how the final formalism looks, some key expectations are:

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;
this formalized IETF would be responsible for managing financial resources (revenue and expenses) directly;
this formalized IETF would be directly signatory to agreements with other organizations, and would therefore be able to negotiate and administer any appropriate contracts;
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;
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

okay so the big question is: what does this formalization give us that the status quo can't? 🤔 the AdvComm believes that an appropriately implemented formalization would let resource management, decision making and stewardship come together, and that's imperative for clarity and a viable future 🌈 they also believe this is simply not possible inside the existing distributed and informal arrangement of responsibilities 💀

obviously, forming an organization doesn't instantly check off the requirements in Section 3. it's not a silver bullet 🙃 changing the formal structure won't, for example, change the financial status of the IETF. still, the AdvComm believes it would give us the necessary basis for making and acting on the required decisions ✨

in short, we first have to put responsibility for defining the IETF's administrative environment in the hands of specific people who are accountable to the IETF community 🫶 then those people can make the detailed decisions that change the administrative environment so it fulfills its requirements 💖

4.2. Possible Structures

Section 4.1 was deliberately vague about what the formal organizational entity might look like 🦋 it focused on the key components of any version of formalization, and how that formalization would address the requirements in Section 3 instead.

so, having decided that formalization is a necessary step, the basic framework for 3 potential implementations is described below 🧚 these aren't complete proposals, and there isn't enough detail available to recommend a particular path. IETF leadership might pick one to explore in more depth, to write an action proposal detailed enough 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 more formalism would be to further define that relationship 🌸 this model anticipates dedicating 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 lines up with the goal of minimizing how much formalization is needed to meet the requirements 🎀

however, ISOC's general mission is broader than the IETF's standardization work, and the ISOC Board of Trustees must stay focused on apportioning resources to meet that broader mission 😭 so would this approach allow the clear lines of responsibility that Section 3 calls for? 🤔

4.2.2. ISOC Subsidiary

a tweak on housing the IETF central body inside ISOC is to create a legal not-for-profit subsidiary of ISOC, with a mandate 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 its own distinct legal entity, the subsidiary would be independently responsible for achieving its mission 🫶 that level of independence addresses the concern raised against formalizing the IETF directly within ISOC: that the IETF mission might get disrupted by ISOC needing to tend to other parts of its broader mission. the role of the IETF community, and the ISOC parent, in defining and supporting that mission would be spelled out when the legal body is created 🌈

the IETF might also consider what the most appropriate governance model would be here 👑 if it's desirable to take some administrative burden off the IESG and IAB, the subsidiary might have its own Board of Trustees, made up of members appointed by IETF and ISOC. that Board would be responsible for reviewing activities and making sure 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, the expectation is that the relationship with ISOC stays 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 keeps giving the IETF a channel to support ISOC in its broader mission, with continued contribution of technical expertise and support of activities 🫶

this approach would take more work to create than simply housing the work at ISOC 😭 the subsidiary would have to be created, and rights and responsibilities adjusted between it and ISOC, so that both have the resources and frameworks they need to carry out their missions 🔥

4.2.3. Completely Autonomous Organizational Entity ✨

Okay, last option bestie, and it's a big one 💅. Instead of making ISOC a parent and creating a subsidiary as a separate legal entity, the IETF could become its own brand-new legal entity, either "IETF, Inc." or "IETF, LLC" 🦋. It would exist for the sole purpose of handling IETF administrative stuff.

This would give the IETF complete autonomy, with all the rights and responsibilities that come with it 👑. But ngl, an independent IETF would basically have to operate like a startup for its first few years 🚀, with all the financing, growth, and survival risks that come with that. The AdvComm thinks those financial and political risks should not be under-estimated, especially since the IETF is already going through a ton of organizational change during the same period 😭.

Here's the thing: the IETF would need initial working capital big enough to cover the commitments for the first few meetings 💸. Raising that from advance meeting fees is conceivable, but it wouldn't leave much margin for error. If one or more of those first meetings ran in the red, a fledgling IETF's survival could be in jeopardy 💀. And given the economic environment, it probably should not be assumed that working capital could come purely from corporate donations, especially early on when the staff needed to solicit and manage donations wouldn't be available yet 🥲.

Also, we need to think about how this move would affect ISOC's ability to carry out its mission, and how it would affect the IETF's standing with governmental organizations 🌍.

4.3. Who Can Decide 🗳️

The AdvComm believes that the IETF leadership, acting with the advice and consent of the IETF community and ISOC, has 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 🙌. They provided input, answered the AdvComm's questions, and reviewed and corrected the consultation text shown here in the appendixes 🎀.

The members of the IAB Advisory Committee who prepared this report were:

Bernard Aboba
Harald Alvestrand (IETF Chair)
Lynn St.Amour (ISOC President)
Fred Baker (Chair, ISOC Board of Trustees)
Brian Carpenter
Steve Crocker
Leslie Daigle (IAB Chair, chair of the committee)
Russ Housley
John Klensin

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.

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.  --

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 ✨:

support organizations are committed to the work of the IETF;
the volunteers of the IETF WGs can (mostly) concentrate on their engineering work, not economics;
money has (so far) been sufficient to cover the costs.

However, there are also a number of challenges 😬:

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);
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;
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;
contracts do not clearly identify responsibility for executive direction. Some contractual relationships are not documented, or are not visible to the IETF leadership;
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;
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 is not available to IETF leadership;
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;
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

Here's the IAB's first question for the RFC Editor 🧐: describe the function you're performing, and say whether that function and its relationship to the IETF is adequately described in RFC 2223bis, or whether more description is needed (and if so, what you'd 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 📋.

The second question asks what staff is being used to perform these functions, and what their particular skills are for doing so, either individually or in the aggregate 🧑‍💻.

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 make up 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. She 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 as 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 Internet protocol technology and the 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, and 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 🤓.

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 🖍️. The goal is to have three pairs of eyes read every RFC word-for-word, and in most instances they 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 🛠️.

The third question asks what criteria you use to determine whether you are being successful, and how successful you are. Using those criteria, how successful are you, and what could be done, especially from the IETF side, to improve that evaluation? 🎯

ANSWER:

okay so we can start with some history, bestie 🕰️ When Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden stepped up and took on the challenge of carrying on Postel's RFC Editor function 🫶 The publication stream kept going, with a modest increase in quantity and, we believe, no loss of quality ✨ The transition was also largely invisible to the IETF, which is so iconic. The new RFC Editor project has seriously defined and clarified the publication process, improved the web site, added tools to boost productivity and quality, and adapted the procedures to changing realities 💅 We are proud of all of this 🏆

The three primary axes for measuring RFC Editor success are (1) quantity, (2) quality, and (3) accessibility 🦋

1. Quantity 💌

Roughly, quantitative success means keeping up with the submission rate. The submission rate is bursty, so to avoid long delays we need an average capacity somewhat in excess of the average 📈

RFC publication is necessarily a heavily labor-intensive process 🛠️

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." Honestly, same. If you consider quality as the absence of faults, then by noting faults you can observe lack of quality 🔍

One measure of faults is the number of errata that appear after publication 🙈 There may also be faults a reader can spot, like a meaningless title, confusing organization, useless Abstract, inadequate introduction, confusing formatting, bad sentences, or bad grammar 💀 There are of course limits to how much we can repair bad writing. Ultimately, quality depends on the authors as well as the editing process 🫠

The only way to maintain quality is to keep monitoring our work internally, track external complaints, and adjust our practice to correct frequent faults 👑 Specific faults have sometimes led us to create new tools for checking consistency, to avoid clerical errors 🧚 Other times they've led to new user guidelines (e.g., on abbreviations or on Abstract sections.) 🍓

3. Accessibility 🌈

An important part of the RFC Editor function is providing 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 here 😭 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 how well they work 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)? 💜

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 become 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 so grateful for this 🫶

One issue of particular concern is the increasing number of RFCs authored by non-English speakers. These can consume a lot of extra editorial effort. We don't know any solution to this problem yet, but we know the IESG is aware of it and working with them to provide editorial assistance when necessary within working groups 🌷

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 be very important guides for 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 keep striving 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 🌼

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 for 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 and 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 the future success of the Internet demands an infusion of new ideas (or old ideas revitalized), and that publishing 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 are 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 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 preserved as RFCs were 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 the current definition of normative is ambiguous and unclear, and as a result some publications may be unnecessarily held up for normative references where these are not needed 🤔

(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 📅

(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 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 🦋

Okay bestie, so the RFC Editor is the one who edits and publishes the archival series of RFC (originally "Request for Comment") documents 📚. These RFCs are a memo series about computer communication and packet switching networks, and they basically record the technical history of the ARPAnet and the Internet, starting way back in 1969 🕰️. The RFC Editor is funded by the Internet Society and works 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, through all the common access protocols (right now that's the Web, email, rsync, and FTP) 🌐. Every new RFC gets announced by email to one or more mailing lists 📬. There's also a comprehensive website with a bunch of tools and lists to help you find and access RFCs 🔍. That site has general info about RFC editorial policies, publication queue status, errata, and anything else that makes the series more accessible and more useful 💖.

During the editing process, the RFC Editor strives for quality, clarity, and consistency of style and format ✨. The editorial guidelines and procedures that get that done are set by the RFC Editor in consultation with the IAB and IESG (Internet Engineering Steering Group) 🤝. The RFC Editor also periodically publishes a revision of 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 🎀. It also works closely with the Internet Assigned Numbers Authority (IANA) so 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.
  - (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.
- (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.
(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 🦋

Question (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?

Okay so the Secretariat work is split into four parts: Meeting Planning, WG support, IESG support, and IETF Community support 💅

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
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
processing requests to publish IDs as RFCs

IESG support is a whole thing 😭 It 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 messages 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)
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 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
posting I-Ds 🌈

Question (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)?

Here's the staffing breakdown 🍓

Three people perform administrative functions.
Four-and-a-half people perform technical support.
One-and-a-half people do development.
Three people do maintenance.

Question (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?

Okay, this one is kind of the heart of it 🫶 The continued efficient operation and evolution of the Internet is one important goal and challenge facing the IETF, and also the IETF Secretariat. Helping the IETF do this important job has been a motivating factor in CNRI's support for almost 15 years 🌸

The criteria CNRI followed, and (more recently) its subsidiary Foretec, for the entire Internet community is to provide a consistent and dependable mechanism. That mechanism lets people working on the many and varied issues raised within the IETF do their important work in the Internet standards process, without being weighed down by the routine administrative tasks that come with such endeavors 💜

The writer thinks this has been a successful activity over many years, but there is always room for improvement 👑 A continuing dialogue between CNRI, ISOC, and the IETF leadership is useful for that purpose. Top of the wishlist: finding a way to increase the funds available to meet the growing demands placed on the Secretariat. We can no longer depend only on attendance fees at meetings for this purpose 💀

Question (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?

Relationship check 🦋 Foretec management may have issues from day-to-day workflow demands on limited resources, but CNRI values the trusted relationship it has had with the IETF community 🥹 The challenge is cooperating on developing new funding sources, and learning to live within the available resources. There is also an issue about effective lines of authority for carrying out certain aspects of the overall standards process. There are many demands and pressures on the IESG and, by extension, on the Secretariat. These workflow demands need to be addressed in a more systematic way for the benefit of all ✨

Question (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 budget constraints 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 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 the Secretariat has built, and there is no money to hire more developers. The IETF Executive Director is documenting processes, which has naturally sparked discussion about whether the processes are what everyone wants them to be. That discussion was expected, but it also adds to the workload 🙈

Question (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?

Money talk 💰 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 🗓️

Question (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?

Okay so, per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as an MOU describing the functions that the IANA provides to the IETF 💖. Her office is about to consist of a manager, three technical clerical staff (four full-time equivalents), plus half a dozen people on a consulting basis, and they perform functions for the IETF and the RIRs. The slice of that effort that supports IETF parameter assignment is roughly one full-time-equivalent, plus software support and the normal management and employment overheads. 🧚

Fundamentally, the IETF parameter assignment function is giving me main character energy in the best way 💅. It accepts requests for protocol numbers for extensible protocols (such as IP Protocol, PPP PID, TCP/UDP Port, and the like), validates them according to business rules, identifies the appropriate registry (and, in some cases, the appropriate portion of a registry), assigns the number, and documents the result.

RFC 2434 has served the IANA staff well as a guide, but ngl it's now in need of updating 🫶. The specific concerns relate to the meaning of terms and to how specific the information is that the IANA gets in Internet-Drafts.

One issue is 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 that have not done so, IANA needs specific guidance on IETF expectations, and this generally comes in the form of AD direction or consulting advice. An improved process would help, though. Business rules that tell the IANA when a new registry is appropriate, and what rules should be applied in assigning values in any given registry, for example, would be so helpful 🎀.

Parameter assignment is an essentially clerical function, so specific guidance to the clerical staff is absolutely mandatory, and it's 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". Without that statement, the IESG's IANA Liaison is forced to read the entire document at least twice. The first read is when the IESG is first handed the document, to make sure any instructions to IANA are clear. The second is when the IESG hands the document on, to make sure 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, because the data assignment has a trade-off implied for the relative frequency of messages using the specified protocol. The control function PIDs are partitioned as well. So in a case like this, 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", then 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. Clear IANA Considerations sections also help the community, not only IANA 🦋.

That's because they (1) make the authors think about all aspects of the creation of a registry and the instructions on how to maintain it, and they (2) let the public know and understand the new registry instructions and how they can get assignments or 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 pretty clear: 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 let IANA review those notes as well, which may in turn prompt 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 before other documents normative for them, which lets them 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 🫧.

Question (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, as of 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 🌷.

Question (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 📈.

Michelle's sense is that IANA is now moderately successful, though 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 this automation will materially help her timeliness. But for that to be carried out properly, clear business guidelines must be given to IANA for each of the existing registries, and those guidelines must be ones whose application can be readily automated. This is likely an IETF effort, or at least requires serious IETF input 🤖.

Question (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, so she 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. There may also be utility in an IAB liaison from the IANA, like the one 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 💌.

Question (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 😭.

Question (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 one 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 it's projected to remain about the same for the near future 🌼.

The cost-effectiveness issues revolve around the human-in-the-loop effort involved in reading drafts, investigating inquiries, and such, which have been detailed here. The sense is that an effective comment management system, plus the workflow 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

Full Copyright Statement ✨

Okay bestie, copyright first 💅 The Internet Society owns the copyright for this one (2004), and it's subject to the rights, licenses and restrictions in BCP 78. Outside of what BCP 78 says, the authors keep 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 🦋

So the IETF is being totally neutral here 🫶 It doesn't take a side on whether any IPR (intellectual property rights) or other rights that might be claimed for the tech in this doc are valid, or how far they reach, or whether a license for them is even out there. It also isn't claiming it looked into any of that itself. If you want the rules on RFC rights, check BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances of licenses that are supposed to be available. You can also see what happens when someone tries to get a general license or permission to use proprietary rights for implementing or using this spec. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🌸

The IETF also really wants to hear from anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🙈✨

Acknowledgement 💖

Funding for the RFC Editor function is currently coming from the Internet Society. Thank you, Internet Society 🫶👑

📦 where this page comes from

ietf: rfc3716 2004-03
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms