Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

NomCom 2017 Concluded

Desired expertise

These pages contain the current summaries of desired expertise for open positions, provided to the NomCom by the IESG, IAB, and IAOC. As the NomCom proceeds, per BCP 10, we receive input from the community on the qualifications required for the positions. The NomCom bases selections on all of this information. These pages may be updated periodically.

This is the summary of the required expertise for the position IESG Members:

Summary of desired expertise (2018)

GENERIC IESG MEMBER EXPERTISE

IESG members are the managers of the IETF standards process. They must understand the way the IETF works, recognise where the organisation needs to evolve, be good at working with other people, be able to inspire and encourage other people to work together as volunteers, and have sound technical judgment about IETF technology and its relationship to technology developed elsewhere.

Area Directors (ADs) select the Working Group (WG) Chairs, and then work with them to manage IETF WGs. So, IESG members should possess sufficient interpersonal and management skills to manage 15 to 30 part-time people. Most ADs are also responsible for the management of one or more directorates or review teams. The ability to identify good leaders and technical experts, and then recruit them for IETF work and leadership at all levels is important. Although it is not a prerequisite, experience as a WG Chair provides important understanding of that role, and it will help when working with WG Chairs to resolve problems and issues that may arise.

ADs are also expected to understand where there is a need to change either IETF processes or IETF's overall role as the Internet and the industry around it evolves.

All IESG members should have strong technical knowledge that crosses two or three IETF Areas. An ideal IESG member has made significant technical contributions in more than one IETF Area, preferably authoring documents and/or chairing WGs in more than one IETF Area. Breadth of technical ability and the facility to quickly grasp concepts outside of their strongest areas are more important than specific technical expertise. Experience from a broad range of backgrounds across the entire IESG is desirable.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, to guide and judge consensus, to know who the subject-matter experts are and to seek their advice, and to mentor other IETF participants to take the technical lead is at least as important, if not more important, than their own technical abilities.

An AD must be able to personally review every Internet-Draft that they sponsor. For other Internet-Drafts an AD needs simply to be satisfied that adequate review has taken place, though many ADs personally review these documents as well. Note that after the 2015 reorganisation of IETF areas and IESG procedures, assignments of ADs to specific working groups are more flexible than before, and can accommodate the expertise available in the IESG as a whole.

It is very helpful for an IESG member to have a good working knowledge of the IETF document process as well as WG creation and chartering process. This knowledge is most likely to be found in experienced WG Chairs, but may also be found in authors of multiple documents. It is very helpful for an IESG member to have experience attending multiple IETF meetings, creating WG session agendas, supervising WG sessions, and helping to arrange interim WG meetings.

IESG members must have strong oral and written communications skills. They must have a proven track record of leading and contributing to the consensus of diverse groups. They must be able to prioritize their work, and must reliably follow through and finish the important work items in a timely manner.

An IESG member should be able to guide WGs to follow their charters and nurture new talent to fulfill IETF leadership roles in the future.

Finally, across the IESG there should be at least some ADs that have expertise on specific Internet-scale issues and trends, such as privacy issues or the growth of open source style collaboration.

A FEW COMMENTS ON THE IESG ROLE

Though not part of our formal summary of desired expertise, the IESG wanted to make the NomCom aware of the time commitment that serving on the IESG entails. The basic IESG activities can consume a minimum of 15 hours during a typical non-meeting week. Some ADs have been able to combine significant other responsibilities with an AD role, while others put a larger proportion of their hours into AD responsibilities. A personal commitment is critical.

Ability to contribute more time is useful, but if the NomCom should pick a few ADs who can only do 15 hrs/week on a routine basis, the IESG can cope with that.

The time commitment varies by Area and by month, with the most intense periods immediately before and during IETF meetings. ADs during their first year tend to spend more time per week on AD work. Practices vary widely between IESG members, however. Most IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. While most ADs do not occupy formal liaison positions, they may need to interact with external groups such as other standards development organizations (SDOs), which may require travel. We have also found IESG member attendance at all IETF meetings to be imperative, typically arriving one or two days early. IESG members also attend one, and sometimes two, IESG retreats per year, as well as occasional workshops and interim meetings.

Because of the time and travel commitments, and awkwardly timed conference calls, IESG members have found that good personal motivation and family and sponsor support are important factors in making the role successful for them. These factors should be considered from a long-term perspective, i.e., covering at least the two-year term. (Although IESG members often serve two terms and sometimes more, finding motivation on third or subsequent terms has been reported to be more challenging.)

This is the summary of the required expertise for the position ART AD:

Applications and Real Time (ART)

The ART Area works on application layer and related protocols. It encompasses several areas of work:

"Infrastructure" protocols. These are underpinnings for other application-layer protocols. They sit above transport protocols, and should not themselves be considered "transport", but they are often or usually used by other application-layer protocols as a layer between applications and transport. Current work in this category includes evolution, maintenance, and extensions to HTTP, SIP, Audio/Video Transport, and RTSP, and codec development.

Real-time applications. These have previously been developed in the RAI Area, and are protocols that enable interactive human-to-human communication (see RFC 3550). Groups in this category are working on things such as real-time web communications, teleconferencing, emergency services communication, internet telephony, and instant messaging.

Traditional applications. These have previously been developed in the Applications Area, and are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, non-real-time web services, and support for constrained environments.

Application building blocks. These are designed to be used with a variety of more specific applications. They include internationalization, JSON and XML, media types, URNs, and URI schemes.

The ART Area often discusses whether something is properly the realm of the IETF or "belongs" to other SDOs. The ART Area often re-uses technology developed elsewhere. As a result, the set of ART ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP and Unicode Consortium.

ART ADs are expected to take a lead role, guiding the community in the making of critical decisions about the scope of the IETF's applications-layer protocol work. Because of the breadth of the ART Area, the ART ADs need to deal with a large set of application-layer protocols, including many with which a particular AD may not have direct experience. ART ADs need to be good at evaluating new approaches to new problems and assessing the expertise of the people who bring them to the IETF. They need to connect well with the community, and know whom to go to for technical advice.

The set of people active in the ART Area changes with the protocols under development at the time. Therefore it is important that the ART ADs be able to clearly explain how the IETF works and to help new participants and working groups operate well, within the IETF standards process. The ability to reach out to new technology communities is important, so that the ART Area stays relevant to the ongoing evolution of Internet applications.

Cross-area expertise with the Security and Transport Areas is also useful, as there are often dependencies between ART work and those areas, particularly with respect to authentication, confidentiality, privacy, network congestion issues, and newly evolving work in the Transport Area.

ART ADs should be prepared to spend 50-75% of their time on IESG-related activities.

This description has been careful to talk about the set of ART ADs as a collective, with a collective set of skills. No one AD will have all of them, and it would be best to look at a balanced skill set across the ART ADs. A generalist with good management skills and good working relationships within the community will be more successful than a narrow specialist. That said, the particular challenges of certain aspects of ART Area work mean that it's important that for each of the following there be at least one AD with a good understanding of it: internationalization; URI schemes; SIP, SDP and related services; RTP; real-time web communications; web services; and media types.

This is the summary of the required expertise for the position Internet AD:

Internet

The primary technical topics covered by the Internet Area include: the IP layer (both IPv4 and IPv6), implications of IPv6 address adoption, co-existence between the IP versions, DNS, DHCP, mobility, multihoming, multicast, host and router configuration, time protocols, and Internet of Things, along with various link-layer technologies.

The Internet Area is responsible for specifying how IP will run over new link layer protocols as they are defined. A significant number of the new link-layer protocols being defined now are in emerging technologies like IoT or constrained networking.

Between them, the Internet ADs are expected to have a solid understanding of these technologies, including issues related to IP addressing, name resolution, forwarding, tunneling, and fragmentation.

Since the Internet Area includes a broad range of technical topics, the Internet Area ADs typically divide the WGs that they manage based on workload and expertise. To assist the ADs, there is an active Internet Area directorate and an active IoT Directorate. However, with the large number of WGs, the Internet Area has historically required considerable time commitment and breadth of expertise from its ADs. As the role of the AD requires significant interaction with the Internet Area directorates, the Internet area workgroups, and other Areas, the ADs are expected to have awareness of contemporary management techniques in dealing with change and challenging technical and personnel situations.

The Internet Area traditionally intersects most frequently with all of the other Areas. Interaction with the Transport Area is related to work on address translation, IPv4-IPv6 co-existence, and multihoming mechanisms. Interaction with the Routing Area concentrates mainly on the relationship between the operation of the IP layer and routing functionality. Interaction with the Operations and Management Area is focused on operations required for IPv6 adoption, YANG development, and AAA interactions. Interaction with the Security Area is focused on topics such as IPsec usage, DNS security, and network access control. The touchpoints with the ART area are related to the IoT space where there are tight interactions between application-layer protocols such as CoAP and IPv6-over-constrained-link-layer adaptations in order to provide better efficiency. Cross-area expertise in any of these Areas is particularly useful.

The Internet Area is also often involved in the adaptation of a variety of technologies to IP, some of which may require interactions with many other organizations such as 5G, 3GPP, ETSI, the ITU, IEEE, BBF, and CableLabs. Expertise with liaison processes and an understanding of how Internet Area protocols are used in various networks (such as Broadband, wireless & cellular networks, low-power networks, and the "Internet of Things"), is desirable.

This is the summary of the required expertise for the position Management AD:

Operations and Management

The primary technical areas covered by the Operations and Management Area include: Network Management, AAA, DNS operations, IPv6 operations, and Routing operations.

Unlike most IETF areas, the Operations and Management Area is logically divided into two separate functions: Network Management and Operations. This year, the Network Management AD role is open, so specific expertise desired for the open position includes a strong understanding of Network Management and measurement, as well as the ability to step into Internet operations issues when necessary. To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, YANG doctors). Historically, specific expertise desired for this position includes a strong understanding of IPFIX, SNMP, SMI, and specifically YANG/NETCONF/RESTCONF as well as autonomic networking as they have become much more important within the IETF the last couple of years. Some knowledge of AAA, RADIUS, and Diameter would also be helpful. The "Internet of Things" is another area which is increasingly gaining attention. Knowledge (or at least an interest) regarding the operational aspects of consumer devices/sensors/etc is also a plus.

A strong architectural background is desirable since the evolution of the Internet management architecture is expected to be one of the principal subjects of interest and work for the Operations and Management Area in the coming years.

Another important role of the Management AD is to identify potential or actual management issues regarding IETF protocols and documents in all Areas, and to work with the other Areas to resolve those issues. This implies a strong understanding of how new and updated protocols should be managed, including aspects related to configuration, monitoring and alarms. It also implies a good understanding of the operational environment, a strong cross-area understanding of the Internet architecture, and a strong understanding of IETF protocols. Note that breadth of technical ability is more important than specific technical expertise.

In terms of future challenges, recent shifts to the increased use of encryption (for example, to counter Pervasive Monitoring) have serious implications for operation and management of networks. Consideration of the impact of this will be a substantial part of the role.

The Management portion of the Operations and Management Area intersects with all Areas, specifically in reviewing and assisting with documents related to management or AAA aspects, especially the shepherding and management of documents defining MIB and YANG modules and specifications that make use of RADIUS or Diameter. Thus, cross-area expertise in any Area would be useful. Security of network management is an important topic. The Operations and Management Area also interacts with the operations community, operator organizations like NANOG, RIPE, and other SDOs doing work in network management such as the IEEE 802.

This is the summary of the required expertise for the position Routing AD:

Routing

The Routing Area is responsible for facilitating the operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols, as well as developing new protocols, extensions, and bug fixes in a timely manner. Forwarding methods (such as destination-based unicast and multicast forwarding, MPLS, and pseudowire) as well as associated routing and signalling protocols (such as OSPF, IS-IS, BGP, RSVP-TE, LDP, PIM, RPL, TRILL, and VPNs at Layer 2, Layer 3), and newer architectures such as NVO3 and SFC are within the scope of the Routing Area. The interactions of routing systems with configuration and orchestration platforms (I2RS, routing-related YANG models) are handled in the routing area. The Routing Area also works on Generalized MPLS used in the control plane of optical networks as well as security and manageability aspects of the routing system. The Routing Area Working Groups cover a wide range of data plane technologies (Layer 1, Layer 2, Layer 3) and control protocols.

A Routing AD must have solid knowledge of the Internet routing system and its operations. A Routing AD must be proficient in at least one of the mainstream routing protocol or technology such as BGP, OSPF, IS-IS, MPLS, GMPLS, or multicast. A Routing AD should have some knowledge of routing services (pseudo-wire, L2VPN, L3VPN). Some familiarity with recent trends in routing (new routing management models, wireless) would be helpful. Implementation, deployment and operational experience as well as significant contributions to the WGs in the Routing Area are highly desirable. It is desired for a Routing AD to have experience in the operation, deployment and/or implementation of routing protocols in non-traditional environments such as mobile, ad hoc and sensor networks (and other IoT-related deployments), including an understanding of interactions with other network systems, including security and management.

Currently, the Routing Area is managed by three Area Directors who typically divide the WGs that they each manage based on workload and expertise. To assist the ADs, there is an active Routing Area directorate that provides technical reviews on demand. Given the broad range of technical topics that have relationship among them, the Routing ADs closely coordinate the overall direction of the area between them and by routinely engaging the WG Chairs. Besides IESG-level commitments, the Routing ADs meet periodically among themselves and organize training and other informal meetings with the WG Chairs.

The Routing Area intersects most frequently with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area concentrates mainly on IP forwarding and encapsulation. With the Operations and Management Area the focus is on development of YANG models and on consideration of management and operation of routing infrastructure. With the Security Area the focus is on routing protocol security. Cross-area expertise in any of those areas would be useful.

Work in the Routing Area often overlaps with work in other SDOs. In particular, there have been interactions with the ITU-T on MPLS-related topics, and with the IEEE. Knowledge of the workings of other SDOs would be beneficial.

This is the summary of the required expertise for the position Security AD:

Security

The Security Area primarily focuses on protocols that provide one or more security services -- integrity, authentication, confidentiality, and access control -- and on protocols operating on infrastructure that provides such security services. Many security mechanisms that are needed to provide these security services employ the use of cryptography. In addition to traditional security issues, the privacy and usability of IETF protocols has become an important consideration.

Specific expertise required for a Security AD includes a strong working knowledge of IETF security protocols and mechanisms that have been developed in the Security Area, other Areas of the IETF, and outside the IETF. It is also important for Security ADs to understand the practical aspects of securing Internet resources, such as techniques for denial- of-service mitigation or for securing Web applications. A good understanding of threat modeling and risk assessment as well as operational and industry practices is also beneficial.

Between the two Security ADs there will ideally be one who is knowledgeable about each of the following security protocols: PKIX, IPsec, TLS, SASL, GSS-API, EAP, CMS, and S/MIME. Ideally at least one AD should be knowledgeable about web security, threat and policy management, as well as system integrity (RFC4949).

The Security Area intersects with all other IETF Areas, and the Security ADs are expected to read and understand the security implications of documents produced by all IETF Areas. Security ADs become personally involved and coordinate the involvement of other security experts in the work of other Areas. Broad knowledge of IETF areas and technologies and the ability to assimilate new information quickly are imperative for a Security AD.

This is the summary of the required expertise for the position Transport AD:

Transport

There are a number of points that matter for the Transport Area Director position, in addition to the “Generic Expertise”.

The Transport Area Directors are more than managers, but the “soft skills” included under “Generic Expertise” for all IESG positions matters even more in the Transport and Services (TSV) area, because of the breadth of topics for which the area is responsible, and because the Transport Area Directors must manage and recruit volunteers to maintain the Transport Area Document Review Triage Team (“TSV triage team”), the Transport Area Review Team, and any active Transport Area directorates.

The Transport Area works on mechanisms related to end-to-end data transport, queuing, delay tolerant networking, as well as technologies for network storage, and signalling protocols. Many transport protocols support Internet applications and services that exchange potentially large volumes of traffic at potentially high bandwidths, therefore the IESG must maintain transport knowledge.

A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion, control loops and hysteresis, flow control, queuing and latency, transport connection and reliability issues, and interactions with the network layer, the application layer, and middleboxes. They are not expected to be experts on all or even most of these topics, but rather to work well with the Transport Area participants who are, and to have enough familiarity with the principles involved to exercise their own good judgment about what should be done and why.

Together, the Transport ADs are expected to understand how transport technologies (layer 4) interact with IP layer technologies and protocols (layer 3) technologies, and with the end-to-end aspects of various applications and application-layer protocols (layer 7).

A Transport AD should have good relationships with the topic experts in the Transport Area. Additionally, the Transport ADs should have good relationships with topic experts in other areas. The Transport Area intersects most frequently with the Security, ART, Operations and Management, Internet, and Routing areas, and Transport-related IRTF research groups, especially ICCRG and MAPRG. Cross-area experience in any of those Areas would be particularly useful.

Together, the Transport ADs are expected to effectively charter, manage and review current and new transport work, including congestion signaling and reporting, Quality of Service (QoS, including Differentiated Services and reservation signaling), and congestion control for unresponsive flows, NAT regularization and specification, storage protocols for the Internet, performance metrics for Internet paths, experimentation with congestion control schemes developed in the IRTF, unicast and multipath extensions to existing transport protocols, and congestion control algorithms for interactive real time media. Based on current discussions about ossification of transport protocols and stack evolution, basic knowledge about security and privacy, and higher layer protocols including web technologies as well as having an overall architectural view can be of value.

A Transport AD requires good soft skills, including the ability to maintain the directorates and relationships, and the ability to develop new working group chairs and encourage potential TSV Area Directors. The Transport ADs are expected to delegate tasks, such as document reviews and follow-up discussions to document reviews, errata processing, to the TSV triage team. This ensures parts of the document reviews required in IESG review are handled by the TSV Area Review team.

Together, the Transport ADs are expected to organize their workload, e.g., document review, email discussions as follow-up of document review, IESG emails, WG management, etc, in such a way that the average weekly workload is about 15 to 20 hours (50 % or less of a 40 hours full-time employment). This is in direct relationship to the Transport communities’ intention to open up the Transport AD position for more willing nominees (see [1] below for the discussions) by lowering the effective workload and reducing the required time commitment.

Because many Transport working groups have strong ties to the research community, some research background can be very helpful.

This is the summary of the required expertise for the position IAB Member:

The IAB Role

The IAB is chartered both as a committee of the IETF and as an advisory body of the Internet Society. The IAB acts as a source of advice and guidance concerning technical, architectural and procedural matters pertaining to the Internet and its enabling technologies; this includes both reviewing proposed new work and providing input to the IESG as well as providing perspective to the broader community on important issues. The IAB develops and documents architectural insight and guidance for the Internet. It provides architectural input into IETF technical activities as well as sponsoring and organizing work in the IRTF. The IAB also has several procedural roles to support the operation of the IETF including being the formal channel for liaisons with other organizations.

Architectural role

The IAB oversees various aspects of the architecture for the protocols and technical specifications as developed by the IETF, as well as overseeing activities in the IRTF. While the IAB does draw on specific expertise as required, it is expected that the sum of the expertise of IAB members encompasses a broad range of technologies under IETF and IRTF study, and also encompasses a broad range of perspectives on these specifications, from research and academic study through development, deployment and operational experience.

A major role of the IAB is to take a broad and long range perspective to offer input into the planning and coordination among different areas of Internet activities, including those of the IETF and IRTF. The IAB, both collectively and on an individual basis, is expected to pay attention to important long- term issues in the Internet, to make sure that these issues are brought to the attention of the groups that are in a position to address them, and to make sure that the right people within these groups are in contact with each other. To foster this community-building role, the IAB maintains open communications channels with other bodies engaged in Internet governance, including ICANN, the Regional Internet Registries, and ISOC, and provides technical and architectural input as appropriate. As needed, the IAB works with ISOC to provide advice and guidance to the Internet community on technical, architectural, procedural, and policy matters pertaining to the Internet and its enabling technologies. That advice and guidance are provided to the public, to the Board of Trustees and Officers of the Internet Society, and to the larger community as circumstances dictate.

Organizational role

The IAB has a number of roles within the organizational functioning of the IETF. While these roles require administrative rather than technical work, they form a large and important part of the IABs activities. All IAB members need to be prepared to participate (to varying degrees) in these activities.

The IAB serves as an appeal board for complaints of improper execution of the standards process, acting on appeals in respect of IESG standards decisions. In addition, the IAB appoints ISOC BoT members as well as a member of the IAOC, and hears appeals on matters related to the IAOC and IAD.

The IAB is responsible for the RFC Editor function, including appointing and overseeing the RFC Series Editor. The IAB provides direction for the administration of the IETF's protocol parameters registries (the IANA function). The IAB selects the chair of the Internet Research Task Force (IRTF) for a renewable two year term, and oversees the IRTF's activities.

The IAB has a role in the IETF Nominations Committee process: the IAB confirms the IETF Chair and the Area Directors (IESG).

The IAB is responsible for liaisons between the IETF and other organizations that undertake activities that overlap or intersect with the IETF's activities including other standards development organizations. The IAB appoints liaison managers to manage these relationships, and deals with liaison matters of an architectural or general procedural nature. The IAB becomes actively involved when these liaison relationships have difficulties, for example, in determining clear boundaries of responsibility. The IAB also appoints a member to the ICANN Nomcom and a liaison to the ICANN board to represent the IETF's interests within ICANN. IAB members fulfill the role of liaison "shepherds" to advise the liaison managers and to act as review point for assessing the efficacy of liaison activities and the liaison manager's duties.

IAB Organization

In order to enhance institutional memory and enable the development of medium and long term activities, the IAB has organized its work in several areas in the form of programs. A program is a high priority, long term activity scoped and managed by the IAB, which can be thought of as an IAB directorate, small task force, or an ad-hoc body of (independent) technical experts (see RFC 2850 Section 2.1). Program outputs include IAB documents and statements. All IAB members are expected to review and comment on program outputs that represent the consensus of the IAB. In order to ensure that all IAB activities have IAB participation, members of the IAB are expected to actively participate in one or more programs.

The program leads, who will usually be IAB members, communicate the program plan to the community, solicit feedback, facilitate activities within the program, provide oversight and ensure continuity. The program lead will typically nominate non-IAB members to the program, subject to IAB approval, will develop the program plan, will organize regular program conference calls, and will develop consensus within the program for recommendations to be made to the IAB. The lead doesn’t need to have specific expertise in the area, but must have good general understanding of the issues from technical, business, and or policy perspective. The IAB as a whole periodically reviews the state of the programs and their progress, and makes necessary adjustments and prioritization. This includes a review of the program membership, activity plan and progress against deliverables. Current IAB programs include:

IANA Program
IP Stack Evolution Program
Liaison Oversight Program
Plenary Planning Program
Privacy and Security Program
RFC Editor Series Oversight Committee

In addition, the IAB chooses a chair for a one year term at the March IETF meeting, after new members of the IAB are seated. The chair represents the IAB externally when necessary, and is an ex officio member of the IESG and the IAOC. There shall be at least two members of the IAB (among the nominated slate and the incumbents) who are willing and able to take the role of Chair.

IAB Member Qualities

IAB members are expected to act at the "Board" level.

The IAB is most effective when it is composed of a diverse set of individuals with a broad range of technical skills, architectural perspectives and backgrounds. For example, it is desirable for IAB members to have technical leadership experience, operational management backgrounds, research or academic backgrounds, implementation experience, and experience in other bodies involved in Internet governance. Likewise it is desirable for IAB members to have had experiences with differing technical challenges and requirements, including those that vary by geographic region. It is critical that IAB members be willing and able to work with each other to develop a shared viewpoint.

Some IAB activities are very specialized - for example, managing liaison relationships with other SDOs on behalf of the IETF. It is advantageous for the IAB when NomCom ensures that at least some IAB members have sufficient managerial skills to understand the issues that need to come to the IAB by managing and documenting inter-SDO liaison relationships on a strategic basis.

While it is advantageous for at least some IAB membership to have expertise in the IAB's current program topics, it is more important for the IAB to have membership who are experienced in managing volunteer teams, and who can build teams, motivate program work, and direct one or more programs even in the absence of in-depth knowledge about specific program topics. The IAB needs at least some members with program management skills that will facilitate interfacing between programs and the IAB.

IAB members...

are highly regarded in one or more domains of technical subject matter. They may be recognized in a particular area as being a domain expert, but also exhibit advanced architectural and technical competence.
are willing and able to apply those technical skills and analytic thinking to understand and usefully contribute to discussions in other areas and to have interests broad enough that they are willing and able to contribute to discussions on new areas as appropriate.
are willing and able to apply their managerial skills to new areas.
are willing and able to make introductions among their networks of technical experts in support of the IAB's community-building role.
are constructive in framing new approaches, technically or in terms of communication.
are willing and able to work well with others.
are willing and able to constructively contribute to consensus-based processes.
have substantial experience within the IETF, and an understanding of its processes and workings.
are willing and able to commit the time to follow IAB, IRTF and IETF discussions on a regular basis. This commitment should extend to regular attendance at IAB teleconferences and attendance in person at IETF meetings, IAB workshops, an annual IAB retreat, as well as the commitment to review material and generate and edit documentation. This may also extend to leading open discussion forums and active participation in IETF WG and IRTF RG activities.

Time Commitment

The time commitment for an IAB member averages about six to sixteen hours a week in normal weeks (with significant week-to-week variability), and full-time during IETF meetings, retreats, and IAB workshops. This commitment could be higher, since it is expected that IAB members also actively participate in IETF activities. Simply tracking the various mailing list and documents can take up to a day a week. About a quarter to half of the time is spent on the organizational activities. Leading a program is an equivalent time commitment to chairing a working group, and active participation in a program an equivalent time commitment to authoring one or more documents in a working group. Each IAB member should be able to commit to leading a program during their IAB term.

Some positions within the IAB require more time. The typical time commitment for the IAB Chair is three days a week, and this position may require more travel. The IAB Chair is an ex officio member of the IESG and the IAOC, as well, and must devote time to the meetings of these organizations. The ongoing IASA2.0 efforts may impact the time the IAB chair or delegates spend on IAOC activities.

IAB members may be tapped by ADs to do reviews of specialized documents and other tasks, potentially adding to those numbers. IAB members should plan to arrive at IETF meetings on the Saturday preceding the meeting. Time commitment during the meeting includes time on Sunday, early mornings during the week, Friday afternoons, as well as coverage of BoFs during the meeting for technical and architectural review.

An annual retreat will be scheduled for up to three days in late April or early May.

The IAB schedules workshops on topics of interest from time to time, and IAB members are encouraged to attend these as well.

Membership

The incumbents are:

Ted Hardie
Joe Hildebrand*
Lee Howard*
Erik Nordmark
Martin Thomson
Brian Trammell

(*) will not accept nomination for reappointment

Continuing IAB members are:

Jari Arkko
Gabriel Montenegro
Mark Nottingham
Robert Sparks
Jeff Tantsura
Suzanne Woolf

This is the summary of the required expertise for the position IAOC Member:

The NOMCOM is responsible for appointing a single individual from the IETF community to serve as a member of the IETF Administrative Oversight Committee (IAOC) and as a trustee of the IETF Trust.

IAOC/TRUST POSITION DESCRIPTION

This note outlines the expertise and duties for a member of the IAOC and the IETF Trust as regulated by BCP101. The administrative structure of the IETF is currently being reviewed as part of the IASA 2.0 discussions. Candidates should be aware of the IASA2.0 work and recognize that the term of IAOC appointees may be foreshortened or changed in the resulting structure. BCP101 defines the IASA as:

The IETF Administrative Support Activity (IASA) provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. As of the time at which this document was written, this included the work of IETF working groups, the IESG, the IAB, and the IRTF. Should the IETF standards process at some future date come to include other technical activities, the IAOC is responsible for developing plans to provide administrative support for them. Such support includes, as appropriate, undertaking or contracting for the work described in [RFC3716], including IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and the Internet Assigned Numbers Authority (IANA). The IASA is also ultimately responsible for the financial activities associated with IETF administrative support, such as collecting IETF meeting fees, paying invoices, managing budgets and financial accounts, and so forth.

The IASA is responsible for ensuring that the IETF's administrative needs are met, and met well. The IETF does not expect the IASA to undertake the bulk of this work directly; rather, the IETF expects the IASA to contract this work from others and to manage these contractual relationships to achieve efficiency, transparency, and cost effectiveness.

The IASA is distinct from IETF-related technical functions, such as the RFC Editor, the IANA, and the IETF standards process itself. The IASA has no influence on the technical decisions of the IETF or on the technical contents of IETF work. Note, however, that this in no way prevents people who form part of the IASA from participating as individuals in IETF technical activities. The exact mechanics of how the IAOC operates and governs are further described in BCP101. Besides providing the above-mentioned operational support for the IETF together with and through the IAD, the members of the IAOC as well as the IAD serve as Trustees of the IETF Trust. It holds the IETF's intellectual property assets, for example in the form of copyrights to the RFCs, the name IETF, logo etc.

BCP101 in Section 3.2 defines the role of the IAOC as:

The IAOC's role is to provide appropriate direction to the IAD, to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC's mission is not to be engaged in the day-to-day administrative work of the IASA, but rather to provide appropriate direction, oversight, and approval.

Therefore, the IAOC's responsibilities are as follows:

To select the IAD and to provide high-level review and direction for his or her work. This task should be handled by a sub-committee, as defined above [in BCP101].
To review the IAD's plans and contracts to ensure that they will meet the administrative needs of the IETF.
To track whether the IASA functions are meeting the IETF community's administrative needs, and to work with the IAD to determine a plan for corrective action if they are not.
To review the IAD's budget proposals to ensure that they will meet the IETF's needs, and to review the IAD's regular financial reports.
To ensure that the IASA is run in a transparent and accountable manner. Although the day-to-day work should be delegated to the IAD and others, the IAOC is responsible for ensuring that IASA finances and operational status are tracked appropriately, and that monthly, quarterly, and annual financial and operational reports are published to the IETF community.
To designate, in consultation with the IAB and the IESG, the person or people who carry out the tasks that other IETF process documents say are carried out by the IETF Executive Director.

The IAOC's role is to direct and review, not to perform, the work of the IAD and IASA. The IAOC holds periodic teleconferences and face-to-face meetings as needed to carry out the IAOC's duties efficiently and effectively.

If there is no IAD or if the IAD is unavailable, the IAOC may temporarily assign the IAD's duties to individual members of the IAOC.

The update (RFC4371) to the original BCP101 (RFC4071) outlines the IETF Trust. The IETF Trust is therein defined as:

A Trust ("the IETF Trust") has been formed for the purpose of acquiring, holding, maintaining, and licensing certain existing and future intellectual property and other property used in connection with the administration of the IETF. The Trust was formed by the signatures of its Settlors and initial Trustees. The Settlors, who contributed initial intellectual property to the Trust, were ISOC and the Corporation for National Research Initiatives. The Trustees of the IETF Trust are the members of the IAOC, and the Beneficiary of the IETF Trust is the IETF as a whole.

In its administration of IPR under the terms of BCP 101, the IASA, including the IAD and the IAOC, will treat the IETF Trust rather than ISOC as the proper entity for ownership and licensing of IETF IPR. Specifically, references to ISOC in sections 3.1, 5.3, and 7 of [1] shall be interpreted as referring to the IETF Trust wherever IPR issues are concerned. The duty to serve as Trustees is added to section 3.2 of [1].

IAOC members also serve as Trustees, and should be willing and able to agree in writing to fulfill the duties of a Trustee under the terms of the IETF Trust Agreement. The Trust Agreement is available at

http://trustee.ietf.org/documents/IETF-Trust-Agreement-Amended-and-Restated-02-20-2014.pdf

Based on the above mentioned roles, duties, responsibilities and experience in operating the IASA so far, the current IAOC believes the following base of experience is valuable in serving as a member of the IAOC as well bringing value to the IAOC:

Previous management experience, such as team-leader, group director, etc. is essential.
Previous budget responsibilities. The ability to work with budget and financial terminology, as well as basic knowledge of accounting and auditing practices and regulations is essential.
Previous experience in the IETF, and a good understanding of the IETF processes, such as having been a working-group chair, IESG or IAB member, certainly helps.
Have complementary backgrounds and experience.

Due to the structure of the IAOC and IETF trust only a subset of IAOC members can serve as IAOC and IETF Trust chairs. Only the NOMCOM, IESG, IAB, and ISOC appointed IAOC members are so eligible. The IAOC also believes it is inappropriate for the ISOC appointed IAOC member to serve as one of the chairs, even though it is not prohibited by BCP101 Overall, the IAOC believes that it is important that people appointed to the IAOC have the capability and interest to serve in one of the chair positions at some time during their IAOC term.

The IAOC has formed a number of subcommittees that are made up of its members and other, invited participants. These subcommittees make recommendations to the full IAOC. Committees conduct work through email and, typically, once-a-month calls.

At the time of writing, the set of subcommittees is:

Finance
Legal
Meetings
Technology Management
Request For Proposals (RFP)
Sponsorship

Information on the committees can be found at: http://iaoc.ietf.org/committees.html

The workload varies periodically, depending upon the items on the IAOC/Trust's plate. For example around times of RFPs issued for the various contracted services, the load is higher. On average over the year, the time commitment is likely to be 5-10 hours a week. Mail volume is generally low, but there are periods of contract and related paper reviews. There are also periods where the IAOC or the Trust is going through bigger changes. Ongoing changes in IANA arrangements and meeting arrangement processes and discussions thereof are consuming a considerable amount of time in within the current IAOC.

At the time this note is being written, the IAOC and the IETF Trust operate through conference calls, meetings at IETF meetings, and one or two face-to-face retreats per year. Minutes from these calls can be found:

https://iaoc.ietf.org/minutes.html

The current call schedule is usually at 12pm US Eastern Time on:

3rd Thursday of the month (90min)
1st Thursday of the month (if needed)

Each subcommittee typically has one call per month, usually during the second week of the month.

Call times are adapted to suit the current membership of the IAOC, and are only provided to give an overview of the regular, group workload.

General IAOC operating procedures and more detail can be found:

https://iaoc.ietf.org/policy-procedures.html

This is the summary of the required expertise for the position IAOC Short-term Member: