NomCom 2016

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 IAB Member:

Summary of desired expertise

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 Evolution Program
  • Internationalization Program
  • IP Stack Evolution Program
  • Liaison Oversight Program
  • Privacy and Security Program
  • Names and Identifiers Program
  • IETF Protocol Registries Oversight Committee
  • 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 eight to sixteen hours a week in normal weeks, and full-time during IETF meetings, retreats, and IAB workshops. 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.

Note that the while the IAB Chair is currently an ex officio member of the IAOC per RFC 4071, this may change in the near future to allow the IAB to appoint a member whose skills are better matched to the IAOC (see draft-hardie-iaoc-iab-update). If this is the case, this appointed member will also have to devote time to the IAOC.

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:

  • Ralph Droms (*)
  • Russ Housley (*)
  • Robert Sparks
  • Andrew Sullivan
  • Dave Thaler (*)
  • Suzanne Woolf

(*) will not accept nomination for reappointment

Continuing IAB members are:

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

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

Summary of desired expertise (2017)

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 is important. 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 substantial time commitment that serving on the IESG entails. The basic IESG activities can consume between 15-40 hours a week. Some ADs have been able to combine significant other responsibilities with an AD role. 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, 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. Historically, many ADs have spent approximately full time on IETF-related activities, especially new ADs during their first year. 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 large 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.)

IETF Chair / General AD

The IETF Chair has six major roles: overseeing the work of the IETF as a whole, representing the IETF to the outside world, overseeing the work of the IESG in particular, serving as the General AD, serving as a voting member of the IAB, and serving as a voting member of the IAOC and the IETF Trust.

Serving as IETF Chair is a full-time job. A candidate for this position needs to be willing to put aside his or her own technical work and other major professional roles for the duration of the term.

Chairing the IETF requires excellent communications skills, strong leadership skills, the ability and willingness to keep the community informed of all issues that are important to the IETF as a whole, the ability to establish community consensus on issues important to the IETF as a whole, and the ability to speak and act in accordance with that consensus. Among other things, this involves working with the IAB Chair to plan plenary sessions and effectively running meetings with over 1000 attendees.

In the IESG Chair role, the IETF Chair is responsible for coordinating the activities of the other ADs and providing top-level management for the IETF standards process. The IETF Chair must be capable of intervening when difficulties arise between ADs or between an AD and a WG Chair. The IETF Chair also oversees the handling of appeals sent to the IESG, the mechanisms for IESG internal process change, and the production of any statements issued by the IESG.

The General Area consists of very few WGs and other activities focused on supporting, updating and maintaining the IETF standards development process. As General AD, the IETF Chair should meet the generic requirements for an IESG member listed above, and is expected to play a full role in IESG document review and approval. The General AD must also have a strong understanding of the IETF standards process and a commitment to maintain and improve that process in a careful and open manner. The General AD manages the General Area Review Team (Gen-ART) and other IETF-wide directorates.

The IETF Chair is a voting member of the Internet Architecture Board (IAB). The IAB has a long history, but the IAB is currently viewed as the senior committee working with the IETF to provide both architectural and oversight functions for the development of the Internet. The IETF Chair brings important perspective to the oversight of the RFC Editor, the IANA functions, and the liaison process with other SDOs. The IAB also has a role in appeals and confirmation of NomCom? candidate selection for IESG members; however, since the IETF Chair is also an IESG member, IETF Chair is recused from these activities.

The IETF Chair serves as a voting member of the IETF Administrative Oversight Committee (IAOC) and as a Trustee of the IETF Trust. Although day-to-day management of administrative matters is handled by the IETF Administrative Director (IAD), the IETF Chair will spend some time each week on IAOC or Trust business, particularly in the context of ensuring the IETF is properly supported by its service providers, and that the IAD has adequate support.

The IETF Chair is asked to speak at numerous conferences and to represent the IETF to government officials, representatives of other standards bodies and the press. While the IETF Chair has control over which of these invitations he or she accepts, any candidate for this position should be willing and able to represent the IETF effectively in these fora, in consultation with the IAB Chair as appropriate.

The IETF Chair needs to be able to lead and work with others on communications related to the IETF and its visions, values, work activities, and successes. This includes answering requests to explain the IETF to people who are not familiar with it or its work. To do this, the IETF Chair uses different communication styles and methods than those needed to effectively lead and work with others within the IETF. For example, the IETF Chair may be asked to communicate with news media, help develop approaches for and use channels such as social media, and speak with non-technical audiences beyond the immediate IETF community.

For various reasons, the amount of visibility of IETF-related issues in the world has risen (e.g., due to pervasive monitoring work), and there has also been an increased need for IETF involvement in the greater Internet community (e.g., in IANA-related discussions). This situation is expected to last at least for the next couple of years, and as a result, it places additional requirements on the IETF Chair's involvement as well.

Applications and Real Time (ART)

The ART Area has recently been created by merging the former Applications Area with the RAI Area, and encompasses several areas of work:

  1. "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.
  2. 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.
  3. 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.
  4. 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

Internet

The primary technical topics covered by the Internet Area include: IP layer (both IPv4 and IPv6), implications of IPv4 address depletion, 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. 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 Directorate 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 has traditionally intersected most frequently with the Transport, Routing, Operations and Management, and Security Areas. Due to the burgeoning work in the IoT/constrained space, there is now increasing interworking with the ART area as well. 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, MIB 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 other organizations such as the ITU, IEEE, BBF, and CableLabs. Expertise with liaison processes and an understanding of how Internet Area protocols are used in various networks (including Broadband, wireless & cellular networks, low-power networks, and the "Internet of Things"), and so on is desirable.

Operations and Management

The primary technical areas covered by the Operations & Management Area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, and Routing operations.

Unlike most IETF areas, the Operations & Management area is logically divided into two separate functions: Network Management and Operations. This year, the Operations AD role is open, so specific expertise required for the open position includes a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary.

The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence to maintain constructive engagement.

Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies.

The Operations portion of the OPS area interacts most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful.

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.

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

Security

The Security Area primarily focuses on protocols that provide one or more security services -- integrity, authentication, confidentiality, and access control -- and on protocols that provide infrastructure that supports such security services. Since many security mechanisms that are needed to provide these security services employ cryptography, key management is also vital. Privacy and usability issues have become more important, so an appreciation of the potential privacy and usability impacts of IETF protocols is useful for a Security AD.

Specific expertise required for a Security AD includes a strong knowledge of IETF security protocols and a good working knowledge of 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 broader aspects of network and Internet security as well as the practical issues in securing Internet resources, such as techniques for denial-of-service mitigation or Web application-level attacks.

Security ADs must match the cost of security to the value of the resources being protected, and they must balance security against usability. A good understanding of industry and operational 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, Kerberos, 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.

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 technologies and the ability to assimilate new information quickly are imperative for a Security 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 Internet Area, the ART Area, the Security Area, the Routing Area, and Transport-related IRTF research groups, especially ICCRG. 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, peer-to-peer streaming, 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. 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.

[1] https://www.ietf.org/proceedings/92/minutes/minutes-92-tsvarea

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

Summary of desired expertise

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. The structure of the IETF Administrative Support Activity (IASA) is described in and regulated by BCP101.

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:

o 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].
o To review the IAD's plans and contracts to ensure that they will
meet the administrative needs of the IETF.
o 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.
o 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.
o 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.
o 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:

o Previous management experience, such as team-leader, group director,
etc. is essential.
o 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.
o 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.

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

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

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 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 ART AD:

Summary of desired expertise

Applications and Real Time (ART)

The ART Area has recently been created by merging the former Applications Area with the RAI Area, and encompasses several areas of work:

  1. "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.
  2. 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.
  3. 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.
  4. 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:

Summary of desired expertise

Internet

The primary technical topics covered by the Internet Area include: IP layer (both IPv4 and IPv6), implications of IPv4 address depletion, 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. 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 Directorate 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 has traditionally intersected most frequently with the Transport, Routing, Operations and Management, and Security Areas. Due to the burgeoning work in the IoT/constrained space, there is now increasing interworking with the ART area as well. 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, MIB 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 other organizations such as the ITU, IEEE, BBF, and CableLabs. Expertise with liaison processes and an understanding of how Internet Area protocols are used in various networks (including Broadband, wireless & cellular networks, low-power networks, and the "Internet of Things"), and so on is desirable.

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

Summary of desired expertise

Operations and Management

The primary technical areas covered by the Operations & Management Area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, and Routing operations.

Unlike most IETF areas, the Operations & Management area is logically divided into two separate functions: Network Management and Operations. This year, the Operations AD role is open, so specific expertise required for the open position includes a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary.

The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence to maintain constructive engagement.

Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies.

The Operations portion of the OPS area interacts most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful.

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

Summary of desired expertise

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.

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 MIB modules 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:

Summary of desired expertise

Security

The Security Area primarily focuses on protocols that provide one or more security services -- integrity, authentication, confidentiality, and access control -- and on protocols that provide infrastructure that supports such security services. Since many security mechanisms that are needed to provide these security services employ cryptography, key management is also vital. Privacy and usability issues have become more important, so an appreciation of the potential privacy and usability impacts of IETF protocols is useful for a Security AD.

Specific expertise required for a Security AD includes a strong knowledge of IETF security protocols and a good working knowledge of 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 broader aspects of network and Internet security as well as the practical issues in securing Internet resources, such as techniques for denial-of-service mitigation or Web application-level attacks.

Security ADs must match the cost of security to the value of the resources being protected, and they must balance security against usability. A good understanding of industry and operational 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, Kerberos, 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.

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

Summary of desired expertise

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 Internet Area, the ART Area, the Security Area, the Routing Area, and Transport-related IRTF research groups, especially ICCRG. 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, peer-to-peer streaming, 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. 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.

[1] https://www.ietf.org/proceedings/92/minutes/minutes-92-tsvarea

This is the summary of the required expertise for the position IETF Chair/GEN AD:

Summary of desired expertise

IETF Chair / General AD

The IETF Chair has six major roles: overseeing the work of the IETF as a whole, representing the IETF to the outside world, overseeing the work of the IESG in particular, serving as the General AD, serving as a voting member of the IAB, and serving as a voting member of the IAOC and the IETF Trust.

Serving as IETF Chair is a full-time job. A candidate for this position needs to be willing to put aside his or her own technical work and other major professional roles for the duration of the term.

Chairing the IETF requires excellent communications skills, strong leadership skills, the ability and willingness to keep the community informed of all issues that are important to the IETF as a whole, the ability to establish community consensus on issues important to the IETF as a whole, and the ability to speak and act in accordance with that consensus. Among other things, this involves working with the IAB Chair to plan plenary sessions and effectively running meetings with over 1000 attendees.

In the IESG Chair role, the IETF Chair is responsible for coordinating the activities of the other ADs and providing top-level management for the IETF standards process. The IETF Chair must be capable of intervening when difficulties arise between ADs or between an AD and a WG Chair. The IETF Chair also oversees the handling of appeals sent to the IESG, the mechanisms for IESG internal process change, and the production of any statements issued by the IESG.

The General Area consists of very few WGs and other activities focused on supporting, updating and maintaining the IETF standards development process. As General AD, the IETF Chair should meet the generic requirements for an IESG member listed above, and is expected to play a full role in IESG document review and approval. The General AD must also have a strong understanding of the IETF standards process and a commitment to maintain and improve that process in a careful and open manner. The General AD manages the General Area Review Team (Gen-ART) and other IETF-wide directorates.

The IETF Chair is a voting member of the Internet Architecture Board (IAB). The IAB has a long history, but the IAB is currently viewed as the senior committee working with the IETF to provide both architectural and oversight functions for the development of the Internet. The IETF Chair brings important perspective to the oversight of the RFC Editor, the IANA functions, and the liaison process with other SDOs. The IAB also has a role in appeals and confirmation of NomCom? candidate selection for IESG members; however, since the IETF Chair is also an IESG member, IETF Chair is recused from these activities.

The IETF Chair serves as a voting member of the IETF Administrative Oversight Committee (IAOC) and as a Trustee of the IETF Trust. Although day-to-day management of administrative matters is handled by the IETF Administrative Director (IAD), the IETF Chair will spend some time each week on IAOC or Trust business, particularly in the context of ensuring the IETF is properly supported by its service providers, and that the IAD has adequate support.

The IETF Chair is asked to speak at numerous conferences and to represent the IETF to government officials, representatives of other standards bodies and the press. While the IETF Chair has control over which of these invitations he or she accepts, any candidate for this position should be willing and able to represent the IETF effectively in these fora, in consultation with the IAB Chair as appropriate.

The IETF Chair needs to be able to lead and work with others on communications related to the IETF and its visions, values, work activities, and successes. This includes answering requests to explain the IETF to people who are not familiar with it or its work. To do this, the IETF Chair uses different communication styles and methods than those needed to effectively lead and work with others within the IETF. For example, the IETF Chair may be asked to communicate with news media, help develop approaches for and use channels such as social media, and speak with non-technical audiences beyond the immediate IETF community.

For various reasons, the amount of visibility of IETF-related issues in the world has risen (e.g., due to pervasive monitoring work), and there has also been an increased need for IETF involvement in the greater Internet community (e.g., in IANA-related discussions). This situation is expected to last at least for the next couple of years, and as a result, it places additional requirements on the IETF Chair's involvement as well.

Summary of desired expertise

This is the summary of the required expertise for the position ART AD II (Vacancy 2017):

This is a one-term appointment based on the vacancy announced by Alissa Cooper

Applications and Real Time (ART)

The ART Area has recently been created by merging the former Applications Area with the RAI Area, and encompasses several areas of work:

  1. "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.
  2. 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.
  3. 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.
  4. 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