IESG MEMBER DESIRED EXPERTISE

General IESG Requirement :

This note describes the expertise desired in the candidates selected to fill the positions of all IESG members.

Under the Nominations Committee (NomCom) procedures defined in RFC 7437/BCP 10, the IESG is responsible for providing a summary of the skills and expertise desired of the candidates selected for open IESG positions. This information is included below and is suitable for publication to the community with the NomCom request for nominations.

The IESG realizes that this is a long list of desires and that no one person will be able to meet all of the skills and expertise for a specific position. The IESG trusts that the NomCom will weigh all of these qualities and choose IESG members who represent the best possible balance of them.

Generic IESG Member Expertise

The IESG members are responsible for managing the IETF standards process. They must possess a thorough understanding of IETF operations, recognize areas in which the organization needs to evolve, and excel in collaborative work. They must also be able to inspire and motivate volunteers to work together and be adept at handling strong personalities and loud voices, fostering an environment in which discussions regarding ideas and technical merit may be held freely. An important aspect of this is helping new participants become productive at the IETF and developing talent to fill important IETF roles in the future. And, of course, IESG members must also have sound technical judgment about IETF technologies and its relationship to technology developed elsewhere.

The Area Director (AD) role has a significant people management component, for which prior experience chairing a Working Group (WG) will be useful – although other people-management experience in any organisation can be a reasonable substitute, noting that IETF participants are volunteers. ADs select the WG Chairs and then work with them to manage IETF WGs. Consequently, IESG members should possess sufficient interpersonal and management skills to manage 20 to 40 part-time volunteers. 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 and rotate them for IETF work and leadership at all levels is crucial to the growth and success of the IETF.

ADs are also expected to recognize the need for changes in IETF processes or in the organization's overall role, in response to the evolving Internet and industry landscape.

An ideal IESG member has made significant technical contributions. Similarly, the ability to review and usefully provide constructive feedback on technical documents is a necessary skill for IESG members, for which serving as a document shepherd or on a directorate or review team would provide useful experience; active participation in working groups and other, non-IETF technical review activities can also help build such skills. A broad range of technical abilities and the capacity to quickly comprehend concepts outside their primary areas of expertise are more valuable than specific technical knowledge.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, 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 are at least as important as their technical abilities. Although the split varies from area to area, ADs can expect to spend approximately 30% of their IESG time on management tasks, with the remainder of their IESG time being spent on technical matters.

An AD must be able to thoroughly review every Internet Draft for which they are responsible, both those from their working groups and those that they sponsor directly. For other Internet Drafts, an AD combines personal review with the assistance of directorates to be satisfied that adequate review has taken place.

Experience attending multiple IETF meetings, creating Working Group (WG) session agendas, supervising WG sessions, and assisting in arranging interim WG meetings is highly beneficial for an IESG member.

IESG members must have strong oral and written communication skills. They must have experience 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 promptly.

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.

IESG members are expected to perform conflict resolution and process appeals that arise in the course of the IETF standards process. An AD is expected to familiarize themselves with the standards process and handle complaints individually or as part of the IESG team, as may be necessary.

ADs are also responsible for ensuring the review of errata; they may delegate the review to a WG or directorate or perform it personally. An AD should be able to process the errata, which will often require them to identify and reach out to relevant subject-matter experts.

ADs engage with the IANA to identify and approve designated experts for registries created and modified by document actions, and to verify the correctness of IANA actions.

ADs support working group chairs with liaison statements between SDOs in coordination with the IAB.

Basic IESG activities consume significant time during a typical non-meeting week. Enough time must be allocated to manage approximately 10 to 15 working groups, review up to 400 pages of Internet Drafts every two weeks, follow up on document processing tasks, and do management-related activities.There is a weekly 2-hour telechat for the full IESG, in addition to any meetings required to manage the area’s business. Many ADs allocate a minimum of 15 hours per week to such tasks and others up to 30 hours per week. Some ADs have been able to combine significant non-IETF responsibilities with an AD role and/or delegate work to area directorates, while others put a larger proportion of their hours into AD responsibilities. Additionally, an AD should plan to support their peer AD(s) in their area and those outside of their area by occasionally taking over part of their duties to address surges in load or to cover inevitable work or personal matters.

The time commitment varies by Area and by month, with the most intense periods immediately surrounding IETF meetings. ADs during their first year tend to spend more time per week on AD work. IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. ADs may need to interact with external groups such as other standards development organizations (SDOs), which could entail additional travel. We have also found IESG member in-person attendance at most IETF meetings to be imperative, typically arriving one or two days early and leaving one day later (to allow for pre/post-meeting activities). IESG members also attend (preferrably in person) at least one annual IESG Strategy Meeting, as well as occasional workshops and interim meetings. An IESG member should also be comfortable with working and developing professional relationships in a virtual environment. Because participants are in widely varying time zones, the ability to accommodate occasional meetings outside a normal 0900-1700 work day will be required.

All AD roles are volunteer positions and are expected to be self-funded by the AD or their respective sponsor or employer. No stipend, travel funding, or fee waivers are provided.

Do not be afraid of the long text above. Not a single AD matches all the above requirements: it is a matter of balance. On the benefit side, ADs learn a lot from reading 400 pages every 2 weeks, attending meetings outside of their expertise, and work in a nice team!

WIT AD :

The Web and Internet Transport (WIT) area covers protocols that provide the functions of the Transport Layer of the Internet, such as QUIC, TCP, UDP, SCTP, and DCCP, including congestion control and queue management. It also has responsibility for protocols that implement the World Wide Web (like HTTP) and adjacent technologies.

Unlike most IETF areas, the Web and Internet Transport Area is logically divided into two separate functions: Web Protocols and Transport Protocols. This year, the Transport Protocol AD role is open.

Together, the WIT Area Directors are expected to effectively charter, manage, and review current and new transport and web protocol work, including congestion control, loss recovery, Quality of Service (QoS, including Differentiated Services and reservation signaling), proxying and tunneling, QUIC and HTTP protocol extensions, application-network interaction, real-time communication, and storage protocols for the Internet.

The Transport AD should have a broad understanding of core end-to-end transport topics and knowledge about the widely used transport protocols, such as TCP and QUIC, as well as how transport protocols interact with network-layer technologies and application layer protocols. The WIT area includes application-layer protocols that 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 named “infrastructure protocols.” Current work in this category includes evolution, maintenance, and extensions to HTTP, Audio/Video Transport, and the network file system (nfs). A good understanding of infrastructure protocols would be advantageous, as the WIT ADs assist each other in various situations. However, they are not expected to be experts on all or even most of these topics. Rather, they are expected to work well with WIT Area participants who are experts and to have enough familiarity with the principles involved to exercise their judgment about what should be done and why.

Because the transport protocol part of the WIT area working groups often have common interests with IRTF research groups, especially ICCRG, MAPRG, and PANRG, familiarity with these research groups and their subject areas is helpful. Having at least one WIT Area AD with some background in the broader research community is also helpful. There are also open-source communities that implement transport area-related protocols which are beneficial to have contact with.

The Transport AD will manage and recruit volunteers in order to maintain the Transport Area Review Team (TSV-ART). The TSV triage team provides support for the ADs by assigning document reviews to TSV-ART, and TSV-ART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

Having an overall architectural view of security and privacy, NAT and Firewall, encapsulation and tunneling, and higher-layer technologies are of added value.

The WIT Area often discusses topics that involve other SDOs. As a result, the set of WIT ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP, and ITU-T.

Together, the WIT ADs are expected to organize their workload, e.g., document review, email discussions as follow-up to document review, IESG emails, WG management, etc., in such a way that the average workload for each AD is about 20 to 30 hours per week.

SEC AD:

The Security Area primarily focuses on protocols that provide one or more security services such as integrity, identification, authentication, authorization, confidentiality, access control and privacy.

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 and communication, including the use of common classes of cryptographic primitives and common misuse of such primitives. 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 major IETF security protocols and building blocks such as TLS, IPsec, SSH, OAuth, HPKE, EDHOC, EAP, and S/MIME. Ideally, at least one AD would be knowledgeable about governance, policy, and risk management; security and privacy controls in complex systems; the web security model; security operations and monitoring; incident response; and security in a systems development lifecycle.

The Security Area intersects with all other IETF Areas and some IRTF Research Groups, and the Security ADs are expected to review, assess and improve the security properties of all documents produced by all IETF Areas. Security ADs become personally involved with coordinating the involvement of 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.

RTG AD :

Routing Area Overview The Routing Area is tasked with ensuring the efficient operation of the Internet routing system. This involves maintaining and enhancing the scalability and stability of existing routing protocols, as well as developing new protocols, extensions, and errata. The area encompasses forwarding methods (e.g., destination-based unicast and multicast forwarding, MPLS, pseudowire), Source Routing and associated routing and signaling protocols (e.g., OSPF, IS-IS, BGP, PCEP, RSVP-TE, LDP, PIM, and VPNs at Layer 2 and Layer 3). Both centralized and distributed routing architectures, for intra- and inter-domain scenarios, including those addressing virtualization, service chaining, traffic engineering, and data center routing, fall within its scope. The Routing Area also manages interactions with configuration and orchestration platforms, such as routing-related device YANG models and path computation engines, and focuses on Generalized MPLS used in the control plane of optical networks, as well as the security and manageability of the routing system. The Working Groups (WGs) in this area cover a wide range of data plane technologies and control protocols.

Requirements for a Routing Area Director (AD) A Routing Area Director must possess a comprehensive understanding of the Internet routing system and its operations. Proficiency in at least two mainstream routing protocols or technologies, such as BGP, OSPF, IS-IS, MPLS, GMPLS, Segment Routing, Traffic Engineering, or multicast, is essential. Knowledge of routing services (e.g., pseudowire, L2VPN, EVPN, L3VPN) and familiarity with recent routing trends (e.g., new routing management models, compute/network integration, time-sensitive routing) are beneficial. Experience in implementing routing protocols, while not mandatory, is highly valuable, as is operational experience and significant contributions to the Routing Area WGs. Experience in non-traditional environments, such as Artificial Intelligence, mobile, ad hoc, and sensor networks, and an understanding of interactions with other network systems, including security and service oriented management, are advantageous. Demonstrated experience in routing protocol security is also valuable.

Management and Coordination The Routing Area is managed by three Area Directors who typically distribute WG responsibilities based on workload and expertise. An active Routing Area directorate supports the ADs by providing technical reviews on demand. Given the broad range of related technical topics, the Routing ADs coordinate closely on the overall direction of the area and routinely engage with WG Chairs. In addition to IESG-level commitments, the Routing ADs hold periodic meetings and organize training and other informal sessions with the WG Chairs.

Interactions with Other Areas and SDOs The Routing Area frequently intersects with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area mainly involves IP forwarding and encapsulation, while work with the Operations and Management Area focuses on developing device and service YANG models and considering the management and operation of the routing infrastructure. Collaboration with the Security Area emphasizes routing protocol security and its broader role in ensuring the authentication, integrity, and authorization of both Internet and local network routing infrastructure. Cross-area expertise in any of these areas is beneficial. The Routing Area's work often overlaps with other Standard Development Organizations (SDOs), particularly the Broadband Forum (BBF), IEEE, 3GPP, and ITU-T, making knowledge of these organizations' workings advantageous.

OPS AD :

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

Unlike most IETF areas, the Operations and 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. The primary technical areas covered by the Operations side of Ops & Management include: operational topics facing the Internet such as DNS operations, IPv6 operations, global routing (including SIDR) operations, operational aspects of SRv6, benchmarking, IoT operations, IP Performance Measurement, operational security, as well as operational issues associated with Network Management. In addition, the Ops part of Ops & Management oversees and organizes the Technology Deep Dives sessions. The Operations AD role includes 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 as well as the ability to gather information from the operations community and then 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 those areas is critical to success. Even more than most AD roles, the Ops AD position requires a very wide range of cross-area knowledge; understanding if an RFC will impact operations requires being an in-depth generalist and the ability to know if an RFC will impact operations and actually be deployable in real networks.

To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, and YANG doctors). The role includes setting objectives for these directorates, coaching, and enhancing OPS-related reviews.

Externally, the Operations and Management Area also interacts with the operations community, operator organizations (e.g., NANOG, RIPE, and OpenConfig), and other SDOs doing work in network management (e.g., 3GPP, IEEE 802, BBF, ETSI, and MEF), and hence any existing relationships with these external communities are helpful.

INT AD :

The primary technical topics covered by the Internet Area include the IP layer (both IPv4 and IPv6), implications of IPv6 adoption, co-existence between the IP versions, DNS, DHCP, IP mobility, multihoming, multicast, host and router configuration, time protocols, Internet of Things, store-and-forward networking, and deep space networking 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. New link-layer protocols still 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, fragmentation, and wireless link-layers.

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, i.e., an INT AD does not need to know everything about all the topics described here. To assist the ADs, there are Internet, DNS, and IoT directorates.

However, with the number of WGs, the Internet Area has historically required some time commitment and breadth of expertise from its ADs. The Internet Area intersects frequently with all of the other Areas:

● Web and Internet Transport (WIT) Area on CoAP, tunneling, address translation, fragmentation, ICMP, and multihoming mechanisms. ● Routing Area on the relationship between the operation of the IP layer and routing functionality, as well as some specific touchpoints related to routing for constrained devices. ● Operations and Management Area on operations required for IPv6 adoption, new sub-IP technologies, YANG models development, and AAA interactions. ● Security Area on topics such as DNS security and privacy, IPsec usage, and network access control. ● Apps and Real Time (ART) area on DNS and about the IoT space where there are tight interactions between application-layer protocols.

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 3GPP, IEEE, BBF, ETSI, and CableLabs. There are also ad-hoc interactions with several standardization organizations in the IoT space. Knowledge of liaison processes and an understanding of how Internet Area protocols are used in various networks (such as broadband, wireless & cellular networks, low-power networks, large data centers, and the "Internet of Things"), is highly desirable.

The Internet Area also includes working groups focusing on space, high delay, and disruption tolerant communications. Experience with these kinds of protocols and operation regimes, as well as with organizations like CCSDS, is an important qualification.

Given all of the above an ideal candidate, in this cycle, should have a good understanding of IPv6, IoT and low-power networking, and constrained devices and networks.

It is perfectly acceptable for a candidate not to be an expert in all these topics -.

ART AD:

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.

This description is 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.

The ART Area works on the application layer and related protocols:

● Real-time applications. These are protocols that enable interactive human-to-human, human-to-agent, and agent-to-agent communication. 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 are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, provisioning and access protocols related to DNS and IP and support for constrained environments. ● Application building blocks. These are designed to be used with a variety of more specific applications. They include compression, codecs, internationalization; JSON, XML, and CBOR; 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, 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, WHATWG, 3GPP, and the Unicode Consortium.

It is important that for each of the following there be at least one AD with some understanding of it and an ability to find and leverage expertise on it when needed: internationalization; URI schemes; SIP, SDP and related services; RTP; media types; and email.

Cross-area expertise with the Security and Web and Internet 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 Web and Internet Transport Area.

ART ADs should be prepared to spend between 40% to 50% of their time on IESG-related activities, with bursts of work especially around IETF meeting time.

ART ADs maintain and support the ART Area Review Team (artart). ARTART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

IESG MEMBER DESIRED EXPERTISE

General IESG Requirement :

This note describes the expertise desired in the candidates selected to fill the positions of all IESG members.

Under the Nominations Committee (NomCom) procedures defined in RFC 7437/BCP 10, the IESG is responsible for providing a summary of the skills and expertise desired of the candidates selected for open IESG positions. This information is included below and is suitable for publication to the community with the NomCom request for nominations.

The IESG realizes that this is a long list of desires and that no one person will be able to meet all of the skills and expertise for a specific position. The IESG trusts that the NomCom will weigh all of these qualities and choose IESG members who represent the best possible balance of them.

Generic IESG Member Expertise

The IESG members are responsible for managing the IETF standards process. They must possess a thorough understanding of IETF operations, recognize areas in which the organization needs to evolve, and excel in collaborative work. They must also be able to inspire and motivate volunteers to work together and be adept at handling strong personalities and loud voices, fostering an environment in which discussions regarding ideas and technical merit may be held freely. An important aspect of this is helping new participants become productive at the IETF and developing talent to fill important IETF roles in the future. And, of course, IESG members must also have sound technical judgment about IETF technologies and its relationship to technology developed elsewhere.

The Area Director (AD) role has a significant people management component, for which prior experience chairing a Working Group (WG) will be useful – although other people-management experience in any organisation can be a reasonable substitute, noting that IETF participants are volunteers. ADs select the WG Chairs and then work with them to manage IETF WGs. Consequently, IESG members should possess sufficient interpersonal and management skills to manage 20 to 40 part-time volunteers. 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 and rotate them for IETF work and leadership at all levels is crucial to the growth and success of the IETF.

ADs are also expected to recognize the need for changes in IETF processes or in the organization's overall role, in response to the evolving Internet and industry landscape.

An ideal IESG member has made significant technical contributions. Similarly, the ability to review and usefully provide constructive feedback on technical documents is a necessary skill for IESG members, for which serving as a document shepherd or on a directorate or review team would provide useful experience; active participation in working groups and other, non-IETF technical review activities can also help build such skills. A broad range of technical abilities and the capacity to quickly comprehend concepts outside their primary areas of expertise are more valuable than specific technical knowledge.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, 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 are at least as important as their technical abilities. Although the split varies from area to area, ADs can expect to spend approximately 30% of their IESG time on management tasks, with the remainder of their IESG time being spent on technical matters.

An AD must be able to thoroughly review every Internet Draft for which they are responsible, both those from their working groups and those that they sponsor directly. For other Internet Drafts, an AD combines personal review with the assistance of directorates to be satisfied that adequate review has taken place.

Experience attending multiple IETF meetings, creating Working Group (WG) session agendas, supervising WG sessions, and assisting in arranging interim WG meetings is highly beneficial for an IESG member.

IESG members must have strong oral and written communication skills. They must have experience 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 promptly.

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.

IESG members are expected to perform conflict resolution and process appeals that arise in the course of the IETF standards process. An AD is expected to familiarize themselves with the standards process and handle complaints individually or as part of the IESG team, as may be necessary.

ADs are also responsible for ensuring the review of errata; they may delegate the review to a WG or directorate or perform it personally. An AD should be able to process the errata, which will often require them to identify and reach out to relevant subject-matter experts.

ADs engage with the IANA to identify and approve designated experts for registries created and modified by document actions, and to verify the correctness of IANA actions.

ADs support working group chairs with liaison statements between SDOs in coordination with the IAB.

Basic IESG activities consume significant time during a typical non-meeting week. Enough time must be allocated to manage approximately 10 to 15 working groups, review up to 400 pages of Internet Drafts every two weeks, follow up on document processing tasks, and do management-related activities.There is a weekly 2-hour telechat for the full IESG, in addition to any meetings required to manage the area’s business. Many ADs allocate a minimum of 15 hours per week to such tasks and others up to 30 hours per week. Some ADs have been able to combine significant non-IETF responsibilities with an AD role and/or delegate work to area directorates, while others put a larger proportion of their hours into AD responsibilities. Additionally, an AD should plan to support their peer AD(s) in their area and those outside of their area by occasionally taking over part of their duties to address surges in load or to cover inevitable work or personal matters.

The time commitment varies by Area and by month, with the most intense periods immediately surrounding IETF meetings. ADs during their first year tend to spend more time per week on AD work. IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. ADs may need to interact with external groups such as other standards development organizations (SDOs), which could entail additional travel. We have also found IESG member in-person attendance at most IETF meetings to be imperative, typically arriving one or two days early and leaving one day later (to allow for pre/post-meeting activities). IESG members also attend (preferrably in person) at least one annual IESG Strategy Meeting, as well as occasional workshops and interim meetings. An IESG member should also be comfortable with working and developing professional relationships in a virtual environment. Because participants are in widely varying time zones, the ability to accommodate occasional meetings outside a normal 0900-1700 work day will be required.

All AD roles are volunteer positions and are expected to be self-funded by the AD or their respective sponsor or employer. No stipend, travel funding, or fee waivers are provided.

Do not be afraid of the long text above. Not a single AD matches all the above requirements: it is a matter of balance. On the benefit side, ADs learn a lot from reading 400 pages every 2 weeks, attending meetings outside of their expertise, and work in a nice team!

WIT AD :

The Web and Internet Transport (WIT) area covers protocols that provide the functions of the Transport Layer of the Internet, such as QUIC, TCP, UDP, SCTP, and DCCP, including congestion control and queue management. It also has responsibility for protocols that implement the World Wide Web (like HTTP) and adjacent technologies.

Unlike most IETF areas, the Web and Internet Transport Area is logically divided into two separate functions: Web Protocols and Transport Protocols. This year, the Transport Protocol AD role is open.

Together, the WIT Area Directors are expected to effectively charter, manage, and review current and new transport and web protocol work, including congestion control, loss recovery, Quality of Service (QoS, including Differentiated Services and reservation signaling), proxying and tunneling, QUIC and HTTP protocol extensions, application-network interaction, real-time communication, and storage protocols for the Internet.

The Transport AD should have a broad understanding of core end-to-end transport topics and knowledge about the widely used transport protocols, such as TCP and QUIC, as well as how transport protocols interact with network-layer technologies and application layer protocols. The WIT area includes application-layer protocols that 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 named “infrastructure protocols.” Current work in this category includes evolution, maintenance, and extensions to HTTP, Audio/Video Transport, and the network file system (nfs). A good understanding of infrastructure protocols would be advantageous, as the WIT ADs assist each other in various situations. However, they are not expected to be experts on all or even most of these topics. Rather, they are expected to work well with WIT Area participants who are experts and to have enough familiarity with the principles involved to exercise their judgment about what should be done and why.

Because the transport protocol part of the WIT area working groups often have common interests with IRTF research groups, especially ICCRG, MAPRG, and PANRG, familiarity with these research groups and their subject areas is helpful. Having at least one WIT Area AD with some background in the broader research community is also helpful. There are also open-source communities that implement transport area-related protocols which are beneficial to have contact with.

The Transport AD will manage and recruit volunteers in order to maintain the Transport Area Review Team (TSV-ART). The TSV triage team provides support for the ADs by assigning document reviews to TSV-ART, and TSV-ART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

Having an overall architectural view of security and privacy, NAT and Firewall, encapsulation and tunneling, and higher-layer technologies are of added value.

The WIT Area often discusses topics that involve other SDOs. As a result, the set of WIT ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP, and ITU-T.

Together, the WIT ADs are expected to organize their workload, e.g., document review, email discussions as follow-up to document review, IESG emails, WG management, etc., in such a way that the average workload for each AD is about 20 to 30 hours per week.

SEC AD:

The Security Area primarily focuses on protocols that provide one or more security services such as integrity, identification, authentication, authorization, confidentiality, access control and privacy.

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 and communication, including the use of common classes of cryptographic primitives and common misuse of such primitives. 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 major IETF security protocols and building blocks such as TLS, IPsec, SSH, OAuth, HPKE, EDHOC, EAP, and S/MIME. Ideally, at least one AD would be knowledgeable about governance, policy, and risk management; security and privacy controls in complex systems; the web security model; security operations and monitoring; incident response; and security in a systems development lifecycle.

The Security Area intersects with all other IETF Areas and some IRTF Research Groups, and the Security ADs are expected to review, assess and improve the security properties of all documents produced by all IETF Areas. Security ADs become personally involved with coordinating the involvement of 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.

RTG AD :

Routing Area Overview The Routing Area is tasked with ensuring the efficient operation of the Internet routing system. This involves maintaining and enhancing the scalability and stability of existing routing protocols, as well as developing new protocols, extensions, and errata. The area encompasses forwarding methods (e.g., destination-based unicast and multicast forwarding, MPLS, pseudowire), Source Routing and associated routing and signaling protocols (e.g., OSPF, IS-IS, BGP, PCEP, RSVP-TE, LDP, PIM, and VPNs at Layer 2 and Layer 3). Both centralized and distributed routing architectures, for intra- and inter-domain scenarios, including those addressing virtualization, service chaining, traffic engineering, and data center routing, fall within its scope. The Routing Area also manages interactions with configuration and orchestration platforms, such as routing-related device YANG models and path computation engines, and focuses on Generalized MPLS used in the control plane of optical networks, as well as the security and manageability of the routing system. The Working Groups (WGs) in this area cover a wide range of data plane technologies and control protocols.

Requirements for a Routing Area Director (AD) A Routing Area Director must possess a comprehensive understanding of the Internet routing system and its operations. Proficiency in at least two mainstream routing protocols or technologies, such as BGP, OSPF, IS-IS, MPLS, GMPLS, Segment Routing, Traffic Engineering, or multicast, is essential. Knowledge of routing services (e.g., pseudowire, L2VPN, EVPN, L3VPN) and familiarity with recent routing trends (e.g., new routing management models, compute/network integration, time-sensitive routing) are beneficial. Experience in implementing routing protocols, while not mandatory, is highly valuable, as is operational experience and significant contributions to the Routing Area WGs. Experience in non-traditional environments, such as Artificial Intelligence, mobile, ad hoc, and sensor networks, and an understanding of interactions with other network systems, including security and service oriented management, are advantageous. Demonstrated experience in routing protocol security is also valuable.

Management and Coordination The Routing Area is managed by three Area Directors who typically distribute WG responsibilities based on workload and expertise. An active Routing Area directorate supports the ADs by providing technical reviews on demand. Given the broad range of related technical topics, the Routing ADs coordinate closely on the overall direction of the area and routinely engage with WG Chairs. In addition to IESG-level commitments, the Routing ADs hold periodic meetings and organize training and other informal sessions with the WG Chairs.

Interactions with Other Areas and SDOs The Routing Area frequently intersects with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area mainly involves IP forwarding and encapsulation, while work with the Operations and Management Area focuses on developing device and service YANG models and considering the management and operation of the routing infrastructure. Collaboration with the Security Area emphasizes routing protocol security and its broader role in ensuring the authentication, integrity, and authorization of both Internet and local network routing infrastructure. Cross-area expertise in any of these areas is beneficial. The Routing Area's work often overlaps with other Standard Development Organizations (SDOs), particularly the Broadband Forum (BBF), IEEE, 3GPP, and ITU-T, making knowledge of these organizations' workings advantageous.

OPS AD :

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

Unlike most IETF areas, the Operations and 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. The primary technical areas covered by the Operations side of Ops & Management include: operational topics facing the Internet such as DNS operations, IPv6 operations, global routing (including SIDR) operations, operational aspects of SRv6, benchmarking, IoT operations, IP Performance Measurement, operational security, as well as operational issues associated with Network Management. In addition, the Ops part of Ops & Management oversees and organizes the Technology Deep Dives sessions. The Operations AD role includes 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 as well as the ability to gather information from the operations community and then 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 those areas is critical to success. Even more than most AD roles, the Ops AD position requires a very wide range of cross-area knowledge; understanding if an RFC will impact operations requires being an in-depth generalist and the ability to know if an RFC will impact operations and actually be deployable in real networks.

To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, and YANG doctors). The role includes setting objectives for these directorates, coaching, and enhancing OPS-related reviews.

Externally, the Operations and Management Area also interacts with the operations community, operator organizations (e.g., NANOG, RIPE, and OpenConfig), and other SDOs doing work in network management (e.g., 3GPP, IEEE 802, BBF, ETSI, and MEF), and hence any existing relationships with these external communities are helpful.

INT AD :

The primary technical topics covered by the Internet Area include the IP layer (both IPv4 and IPv6), implications of IPv6 adoption, co-existence between the IP versions, DNS, DHCP, IP mobility, multihoming, multicast, host and router configuration, time protocols, Internet of Things, store-and-forward networking, and deep space networking 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. New link-layer protocols still 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, fragmentation, and wireless link-layers.

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, i.e., an INT AD does not need to know everything about all the topics described here. To assist the ADs, there are Internet, DNS, and IoT directorates.

However, with the number of WGs, the Internet Area has historically required some time commitment and breadth of expertise from its ADs. The Internet Area intersects frequently with all of the other Areas:

● Web and Internet Transport (WIT) Area on CoAP, tunneling, address translation, fragmentation, ICMP, and multihoming mechanisms. ● Routing Area on the relationship between the operation of the IP layer and routing functionality, as well as some specific touchpoints related to routing for constrained devices. ● Operations and Management Area on operations required for IPv6 adoption, new sub-IP technologies, YANG models development, and AAA interactions. ● Security Area on topics such as DNS security and privacy, IPsec usage, and network access control. ● Apps and Real Time (ART) area on DNS and about the IoT space where there are tight interactions between application-layer protocols.

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 3GPP, IEEE, BBF, ETSI, and CableLabs. There are also ad-hoc interactions with several standardization organizations in the IoT space. Knowledge of liaison processes and an understanding of how Internet Area protocols are used in various networks (such as broadband, wireless & cellular networks, low-power networks, large data centers, and the "Internet of Things"), is highly desirable.

The Internet Area also includes working groups focusing on space, high delay, and disruption tolerant communications. Experience with these kinds of protocols and operation regimes, as well as with organizations like CCSDS, is an important qualification.

Given all of the above an ideal candidate, in this cycle, should have a good understanding of IPv6, IoT and low-power networking, and constrained devices and networks.

It is perfectly acceptable for a candidate not to be an expert in all these topics -.

ART AD:

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.

This description is 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.

The ART Area works on the application layer and related protocols:

● Real-time applications. These are protocols that enable interactive human-to-human, human-to-agent, and agent-to-agent communication. 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 are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, provisioning and access protocols related to DNS and IP and support for constrained environments. ● Application building blocks. These are designed to be used with a variety of more specific applications. They include compression, codecs, internationalization; JSON, XML, and CBOR; 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, 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, WHATWG, 3GPP, and the Unicode Consortium.

It is important that for each of the following there be at least one AD with some understanding of it and an ability to find and leverage expertise on it when needed: internationalization; URI schemes; SIP, SDP and related services; RTP; media types; and email.

Cross-area expertise with the Security and Web and Internet 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 Web and Internet Transport Area.

ART ADs should be prepared to spend between 40% to 50% of their time on IESG-related activities, with bursts of work especially around IETF meeting time.

ART ADs maintain and support the ART Area Review Team (artart). ARTART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

IESG MEMBER DESIRED EXPERTISE

General IESG Requirement :

This note describes the expertise desired in the candidates selected to fill the positions of all IESG members.

Under the Nominations Committee (NomCom) procedures defined in RFC 7437/BCP 10, the IESG is responsible for providing a summary of the skills and expertise desired of the candidates selected for open IESG positions. This information is included below and is suitable for publication to the community with the NomCom request for nominations.

The IESG realizes that this is a long list of desires and that no one person will be able to meet all of the skills and expertise for a specific position. The IESG trusts that the NomCom will weigh all of these qualities and choose IESG members who represent the best possible balance of them.

Generic IESG Member Expertise

The IESG members are responsible for managing the IETF standards process. They must possess a thorough understanding of IETF operations, recognize areas in which the organization needs to evolve, and excel in collaborative work. They must also be able to inspire and motivate volunteers to work together and be adept at handling strong personalities and loud voices, fostering an environment in which discussions regarding ideas and technical merit may be held freely. An important aspect of this is helping new participants become productive at the IETF and developing talent to fill important IETF roles in the future. And, of course, IESG members must also have sound technical judgment about IETF technologies and its relationship to technology developed elsewhere.

The Area Director (AD) role has a significant people management component, for which prior experience chairing a Working Group (WG) will be useful – although other people-management experience in any organisation can be a reasonable substitute, noting that IETF participants are volunteers. ADs select the WG Chairs and then work with them to manage IETF WGs. Consequently, IESG members should possess sufficient interpersonal and management skills to manage 20 to 40 part-time volunteers. 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 and rotate them for IETF work and leadership at all levels is crucial to the growth and success of the IETF.

ADs are also expected to recognize the need for changes in IETF processes or in the organization's overall role, in response to the evolving Internet and industry landscape.

An ideal IESG member has made significant technical contributions. Similarly, the ability to review and usefully provide constructive feedback on technical documents is a necessary skill for IESG members, for which serving as a document shepherd or on a directorate or review team would provide useful experience; active participation in working groups and other, non-IETF technical review activities can also help build such skills. A broad range of technical abilities and the capacity to quickly comprehend concepts outside their primary areas of expertise are more valuable than specific technical knowledge.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, 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 are at least as important as their technical abilities. Although the split varies from area to area, ADs can expect to spend approximately 30% of their IESG time on management tasks, with the remainder of their IESG time being spent on technical matters.

An AD must be able to thoroughly review every Internet Draft for which they are responsible, both those from their working groups and those that they sponsor directly. For other Internet Drafts, an AD combines personal review with the assistance of directorates to be satisfied that adequate review has taken place.

Experience attending multiple IETF meetings, creating Working Group (WG) session agendas, supervising WG sessions, and assisting in arranging interim WG meetings is highly beneficial for an IESG member.

IESG members must have strong oral and written communication skills. They must have experience 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 promptly.

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.

IESG members are expected to perform conflict resolution and process appeals that arise in the course of the IETF standards process. An AD is expected to familiarize themselves with the standards process and handle complaints individually or as part of the IESG team, as may be necessary.

ADs are also responsible for ensuring the review of errata; they may delegate the review to a WG or directorate or perform it personally. An AD should be able to process the errata, which will often require them to identify and reach out to relevant subject-matter experts.

ADs engage with the IANA to identify and approve designated experts for registries created and modified by document actions, and to verify the correctness of IANA actions.

ADs support working group chairs with liaison statements between SDOs in coordination with the IAB.

Basic IESG activities consume significant time during a typical non-meeting week. Enough time must be allocated to manage approximately 10 to 15 working groups, review up to 400 pages of Internet Drafts every two weeks, follow up on document processing tasks, and do management-related activities.There is a weekly 2-hour telechat for the full IESG, in addition to any meetings required to manage the area’s business. Many ADs allocate a minimum of 15 hours per week to such tasks and others up to 30 hours per week. Some ADs have been able to combine significant non-IETF responsibilities with an AD role and/or delegate work to area directorates, while others put a larger proportion of their hours into AD responsibilities. Additionally, an AD should plan to support their peer AD(s) in their area and those outside of their area by occasionally taking over part of their duties to address surges in load or to cover inevitable work or personal matters.

The time commitment varies by Area and by month, with the most intense periods immediately surrounding IETF meetings. ADs during their first year tend to spend more time per week on AD work. IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. ADs may need to interact with external groups such as other standards development organizations (SDOs), which could entail additional travel. We have also found IESG member in-person attendance at most IETF meetings to be imperative, typically arriving one or two days early and leaving one day later (to allow for pre/post-meeting activities). IESG members also attend (preferrably in person) at least one annual IESG Strategy Meeting, as well as occasional workshops and interim meetings. An IESG member should also be comfortable with working and developing professional relationships in a virtual environment. Because participants are in widely varying time zones, the ability to accommodate occasional meetings outside a normal 0900-1700 work day will be required.

All AD roles are volunteer positions and are expected to be self-funded by the AD or their respective sponsor or employer. No stipend, travel funding, or fee waivers are provided.

Do not be afraid of the long text above. Not a single AD matches all the above requirements: it is a matter of balance. On the benefit side, ADs learn a lot from reading 400 pages every 2 weeks, attending meetings outside of their expertise, and work in a nice team!

WIT AD :

The Web and Internet Transport (WIT) area covers protocols that provide the functions of the Transport Layer of the Internet, such as QUIC, TCP, UDP, SCTP, and DCCP, including congestion control and queue management. It also has responsibility for protocols that implement the World Wide Web (like HTTP) and adjacent technologies.

Unlike most IETF areas, the Web and Internet Transport Area is logically divided into two separate functions: Web Protocols and Transport Protocols. This year, the Transport Protocol AD role is open.

Together, the WIT Area Directors are expected to effectively charter, manage, and review current and new transport and web protocol work, including congestion control, loss recovery, Quality of Service (QoS, including Differentiated Services and reservation signaling), proxying and tunneling, QUIC and HTTP protocol extensions, application-network interaction, real-time communication, and storage protocols for the Internet.

The Transport AD should have a broad understanding of core end-to-end transport topics and knowledge about the widely used transport protocols, such as TCP and QUIC, as well as how transport protocols interact with network-layer technologies and application layer protocols. The WIT area includes application-layer protocols that 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 named “infrastructure protocols.” Current work in this category includes evolution, maintenance, and extensions to HTTP, Audio/Video Transport, and the network file system (nfs). A good understanding of infrastructure protocols would be advantageous, as the WIT ADs assist each other in various situations. However, they are not expected to be experts on all or even most of these topics. Rather, they are expected to work well with WIT Area participants who are experts and to have enough familiarity with the principles involved to exercise their judgment about what should be done and why.

Because the transport protocol part of the WIT area working groups often have common interests with IRTF research groups, especially ICCRG, MAPRG, and PANRG, familiarity with these research groups and their subject areas is helpful. Having at least one WIT Area AD with some background in the broader research community is also helpful. There are also open-source communities that implement transport area-related protocols which are beneficial to have contact with.

The Transport AD will manage and recruit volunteers in order to maintain the Transport Area Review Team (TSV-ART). The TSV triage team provides support for the ADs by assigning document reviews to TSV-ART, and TSV-ART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

Having an overall architectural view of security and privacy, NAT and Firewall, encapsulation and tunneling, and higher-layer technologies are of added value.

The WIT Area often discusses topics that involve other SDOs. As a result, the set of WIT ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP, and ITU-T.

Together, the WIT ADs are expected to organize their workload, e.g., document review, email discussions as follow-up to document review, IESG emails, WG management, etc., in such a way that the average workload for each AD is about 20 to 30 hours per week.

SEC AD:

The Security Area primarily focuses on protocols that provide one or more security services such as integrity, identification, authentication, authorization, confidentiality, access control and privacy.

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 and communication, including the use of common classes of cryptographic primitives and common misuse of such primitives. 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 major IETF security protocols and building blocks such as TLS, IPsec, SSH, OAuth, HPKE, EDHOC, EAP, and S/MIME. Ideally, at least one AD would be knowledgeable about governance, policy, and risk management; security and privacy controls in complex systems; the web security model; security operations and monitoring; incident response; and security in a systems development lifecycle.

The Security Area intersects with all other IETF Areas and some IRTF Research Groups, and the Security ADs are expected to review, assess and improve the security properties of all documents produced by all IETF Areas. Security ADs become personally involved with coordinating the involvement of 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.

RTG AD :

Routing Area Overview The Routing Area is tasked with ensuring the efficient operation of the Internet routing system. This involves maintaining and enhancing the scalability and stability of existing routing protocols, as well as developing new protocols, extensions, and errata. The area encompasses forwarding methods (e.g., destination-based unicast and multicast forwarding, MPLS, pseudowire), Source Routing and associated routing and signaling protocols (e.g., OSPF, IS-IS, BGP, PCEP, RSVP-TE, LDP, PIM, and VPNs at Layer 2 and Layer 3). Both centralized and distributed routing architectures, for intra- and inter-domain scenarios, including those addressing virtualization, service chaining, traffic engineering, and data center routing, fall within its scope. The Routing Area also manages interactions with configuration and orchestration platforms, such as routing-related device YANG models and path computation engines, and focuses on Generalized MPLS used in the control plane of optical networks, as well as the security and manageability of the routing system. The Working Groups (WGs) in this area cover a wide range of data plane technologies and control protocols.

Requirements for a Routing Area Director (AD) A Routing Area Director must possess a comprehensive understanding of the Internet routing system and its operations. Proficiency in at least two mainstream routing protocols or technologies, such as BGP, OSPF, IS-IS, MPLS, GMPLS, Segment Routing, Traffic Engineering, or multicast, is essential. Knowledge of routing services (e.g., pseudowire, L2VPN, EVPN, L3VPN) and familiarity with recent routing trends (e.g., new routing management models, compute/network integration, time-sensitive routing) are beneficial. Experience in implementing routing protocols, while not mandatory, is highly valuable, as is operational experience and significant contributions to the Routing Area WGs. Experience in non-traditional environments, such as Artificial Intelligence, mobile, ad hoc, and sensor networks, and an understanding of interactions with other network systems, including security and service oriented management, are advantageous. Demonstrated experience in routing protocol security is also valuable.

Management and Coordination The Routing Area is managed by three Area Directors who typically distribute WG responsibilities based on workload and expertise. An active Routing Area directorate supports the ADs by providing technical reviews on demand. Given the broad range of related technical topics, the Routing ADs coordinate closely on the overall direction of the area and routinely engage with WG Chairs. In addition to IESG-level commitments, the Routing ADs hold periodic meetings and organize training and other informal sessions with the WG Chairs.

Interactions with Other Areas and SDOs The Routing Area frequently intersects with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area mainly involves IP forwarding and encapsulation, while work with the Operations and Management Area focuses on developing device and service YANG models and considering the management and operation of the routing infrastructure. Collaboration with the Security Area emphasizes routing protocol security and its broader role in ensuring the authentication, integrity, and authorization of both Internet and local network routing infrastructure. Cross-area expertise in any of these areas is beneficial. The Routing Area's work often overlaps with other Standard Development Organizations (SDOs), particularly the Broadband Forum (BBF), IEEE, 3GPP, and ITU-T, making knowledge of these organizations' workings advantageous.

OPS AD :

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

Unlike most IETF areas, the Operations and 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. The primary technical areas covered by the Operations side of Ops & Management include: operational topics facing the Internet such as DNS operations, IPv6 operations, global routing (including SIDR) operations, operational aspects of SRv6, benchmarking, IoT operations, IP Performance Measurement, operational security, as well as operational issues associated with Network Management. In addition, the Ops part of Ops & Management oversees and organizes the Technology Deep Dives sessions. The Operations AD role includes 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 as well as the ability to gather information from the operations community and then 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 those areas is critical to success. Even more than most AD roles, the Ops AD position requires a very wide range of cross-area knowledge; understanding if an RFC will impact operations requires being an in-depth generalist and the ability to know if an RFC will impact operations and actually be deployable in real networks.

To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, and YANG doctors). The role includes setting objectives for these directorates, coaching, and enhancing OPS-related reviews.

Externally, the Operations and Management Area also interacts with the operations community, operator organizations (e.g., NANOG, RIPE, and OpenConfig), and other SDOs doing work in network management (e.g., 3GPP, IEEE 802, BBF, ETSI, and MEF), and hence any existing relationships with these external communities are helpful.

INT AD :

The primary technical topics covered by the Internet Area include the IP layer (both IPv4 and IPv6), implications of IPv6 adoption, co-existence between the IP versions, DNS, DHCP, IP mobility, multihoming, multicast, host and router configuration, time protocols, Internet of Things, store-and-forward networking, and deep space networking 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. New link-layer protocols still 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, fragmentation, and wireless link-layers.

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, i.e., an INT AD does not need to know everything about all the topics described here. To assist the ADs, there are Internet, DNS, and IoT directorates.

However, with the number of WGs, the Internet Area has historically required some time commitment and breadth of expertise from its ADs. The Internet Area intersects frequently with all of the other Areas:

● Web and Internet Transport (WIT) Area on CoAP, tunneling, address translation, fragmentation, ICMP, and multihoming mechanisms. ● Routing Area on the relationship between the operation of the IP layer and routing functionality, as well as some specific touchpoints related to routing for constrained devices. ● Operations and Management Area on operations required for IPv6 adoption, new sub-IP technologies, YANG models development, and AAA interactions. ● Security Area on topics such as DNS security and privacy, IPsec usage, and network access control. ● Apps and Real Time (ART) area on DNS and about the IoT space where there are tight interactions between application-layer protocols.

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 3GPP, IEEE, BBF, ETSI, and CableLabs. There are also ad-hoc interactions with several standardization organizations in the IoT space. Knowledge of liaison processes and an understanding of how Internet Area protocols are used in various networks (such as broadband, wireless & cellular networks, low-power networks, large data centers, and the "Internet of Things"), is highly desirable.

The Internet Area also includes working groups focusing on space, high delay, and disruption tolerant communications. Experience with these kinds of protocols and operation regimes, as well as with organizations like CCSDS, is an important qualification.

Given all of the above an ideal candidate, in this cycle, should have a good understanding of IPv6, IoT and low-power networking, and constrained devices and networks.

It is perfectly acceptable for a candidate not to be an expert in all these topics -.

ART AD:

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.

This description is 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.

The ART Area works on the application layer and related protocols:

● Real-time applications. These are protocols that enable interactive human-to-human, human-to-agent, and agent-to-agent communication. 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 are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, provisioning and access protocols related to DNS and IP and support for constrained environments. ● Application building blocks. These are designed to be used with a variety of more specific applications. They include compression, codecs, internationalization; JSON, XML, and CBOR; 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, 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, WHATWG, 3GPP, and the Unicode Consortium.

It is important that for each of the following there be at least one AD with some understanding of it and an ability to find and leverage expertise on it when needed: internationalization; URI schemes; SIP, SDP and related services; RTP; media types; and email.

Cross-area expertise with the Security and Web and Internet 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 Web and Internet Transport Area.

ART ADs should be prepared to spend between 40% to 50% of their time on IESG-related activities, with bursts of work especially around IETF meeting time.

ART ADs maintain and support the ART Area Review Team (artart). ARTART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

IESG MEMBER DESIRED EXPERTISE

General IESG Requirement :

This note describes the expertise desired in the candidates selected to fill the positions of all IESG members.

Under the Nominations Committee (NomCom) procedures defined in RFC 7437/BCP 10, the IESG is responsible for providing a summary of the skills and expertise desired of the candidates selected for open IESG positions. This information is included below and is suitable for publication to the community with the NomCom request for nominations.

The IESG realizes that this is a long list of desires and that no one person will be able to meet all of the skills and expertise for a specific position. The IESG trusts that the NomCom will weigh all of these qualities and choose IESG members who represent the best possible balance of them.

Generic IESG Member Expertise

The IESG members are responsible for managing the IETF standards process. They must possess a thorough understanding of IETF operations, recognize areas in which the organization needs to evolve, and excel in collaborative work. They must also be able to inspire and motivate volunteers to work together and be adept at handling strong personalities and loud voices, fostering an environment in which discussions regarding ideas and technical merit may be held freely. An important aspect of this is helping new participants become productive at the IETF and developing talent to fill important IETF roles in the future. And, of course, IESG members must also have sound technical judgment about IETF technologies and its relationship to technology developed elsewhere.

The Area Director (AD) role has a significant people management component, for which prior experience chairing a Working Group (WG) will be useful – although other people-management experience in any organisation can be a reasonable substitute, noting that IETF participants are volunteers. ADs select the WG Chairs and then work with them to manage IETF WGs. Consequently, IESG members should possess sufficient interpersonal and management skills to manage 20 to 40 part-time volunteers. 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 and rotate them for IETF work and leadership at all levels is crucial to the growth and success of the IETF.

ADs are also expected to recognize the need for changes in IETF processes or in the organization's overall role, in response to the evolving Internet and industry landscape.

An ideal IESG member has made significant technical contributions. Similarly, the ability to review and usefully provide constructive feedback on technical documents is a necessary skill for IESG members, for which serving as a document shepherd or on a directorate or review team would provide useful experience; active participation in working groups and other, non-IETF technical review activities can also help build such skills. A broad range of technical abilities and the capacity to quickly comprehend concepts outside their primary areas of expertise are more valuable than specific technical knowledge.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, 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 are at least as important as their technical abilities. Although the split varies from area to area, ADs can expect to spend approximately 30% of their IESG time on management tasks, with the remainder of their IESG time being spent on technical matters.

An AD must be able to thoroughly review every Internet Draft for which they are responsible, both those from their working groups and those that they sponsor directly. For other Internet Drafts, an AD combines personal review with the assistance of directorates to be satisfied that adequate review has taken place.

Experience attending multiple IETF meetings, creating Working Group (WG) session agendas, supervising WG sessions, and assisting in arranging interim WG meetings is highly beneficial for an IESG member.

IESG members must have strong oral and written communication skills. They must have experience 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 promptly.

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.

IESG members are expected to perform conflict resolution and process appeals that arise in the course of the IETF standards process. An AD is expected to familiarize themselves with the standards process and handle complaints individually or as part of the IESG team, as may be necessary.

ADs are also responsible for ensuring the review of errata; they may delegate the review to a WG or directorate or perform it personally. An AD should be able to process the errata, which will often require them to identify and reach out to relevant subject-matter experts.

ADs engage with the IANA to identify and approve designated experts for registries created and modified by document actions, and to verify the correctness of IANA actions.

ADs support working group chairs with liaison statements between SDOs in coordination with the IAB.

Basic IESG activities consume significant time during a typical non-meeting week. Enough time must be allocated to manage approximately 10 to 15 working groups, review up to 400 pages of Internet Drafts every two weeks, follow up on document processing tasks, and do management-related activities.There is a weekly 2-hour telechat for the full IESG, in addition to any meetings required to manage the area’s business. Many ADs allocate a minimum of 15 hours per week to such tasks and others up to 30 hours per week. Some ADs have been able to combine significant non-IETF responsibilities with an AD role and/or delegate work to area directorates, while others put a larger proportion of their hours into AD responsibilities. Additionally, an AD should plan to support their peer AD(s) in their area and those outside of their area by occasionally taking over part of their duties to address surges in load or to cover inevitable work or personal matters.

The time commitment varies by Area and by month, with the most intense periods immediately surrounding IETF meetings. ADs during their first year tend to spend more time per week on AD work. IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. ADs may need to interact with external groups such as other standards development organizations (SDOs), which could entail additional travel. We have also found IESG member in-person attendance at most IETF meetings to be imperative, typically arriving one or two days early and leaving one day later (to allow for pre/post-meeting activities). IESG members also attend (preferrably in person) at least one annual IESG Strategy Meeting, as well as occasional workshops and interim meetings. An IESG member should also be comfortable with working and developing professional relationships in a virtual environment. Because participants are in widely varying time zones, the ability to accommodate occasional meetings outside a normal 0900-1700 work day will be required.

All AD roles are volunteer positions and are expected to be self-funded by the AD or their respective sponsor or employer. No stipend, travel funding, or fee waivers are provided.

Do not be afraid of the long text above. Not a single AD matches all the above requirements: it is a matter of balance. On the benefit side, ADs learn a lot from reading 400 pages every 2 weeks, attending meetings outside of their expertise, and work in a nice team!

WIT AD :

The Web and Internet Transport (WIT) area covers protocols that provide the functions of the Transport Layer of the Internet, such as QUIC, TCP, UDP, SCTP, and DCCP, including congestion control and queue management. It also has responsibility for protocols that implement the World Wide Web (like HTTP) and adjacent technologies.

Unlike most IETF areas, the Web and Internet Transport Area is logically divided into two separate functions: Web Protocols and Transport Protocols. This year, the Transport Protocol AD role is open.

Together, the WIT Area Directors are expected to effectively charter, manage, and review current and new transport and web protocol work, including congestion control, loss recovery, Quality of Service (QoS, including Differentiated Services and reservation signaling), proxying and tunneling, QUIC and HTTP protocol extensions, application-network interaction, real-time communication, and storage protocols for the Internet.

The Transport AD should have a broad understanding of core end-to-end transport topics and knowledge about the widely used transport protocols, such as TCP and QUIC, as well as how transport protocols interact with network-layer technologies and application layer protocols. The WIT area includes application-layer protocols that 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 named “infrastructure protocols.” Current work in this category includes evolution, maintenance, and extensions to HTTP, Audio/Video Transport, and the network file system (nfs). A good understanding of infrastructure protocols would be advantageous, as the WIT ADs assist each other in various situations. However, they are not expected to be experts on all or even most of these topics. Rather, they are expected to work well with WIT Area participants who are experts and to have enough familiarity with the principles involved to exercise their judgment about what should be done and why.

Because the transport protocol part of the WIT area working groups often have common interests with IRTF research groups, especially ICCRG, MAPRG, and PANRG, familiarity with these research groups and their subject areas is helpful. Having at least one WIT Area AD with some background in the broader research community is also helpful. There are also open-source communities that implement transport area-related protocols which are beneficial to have contact with.

The Transport AD will manage and recruit volunteers in order to maintain the Transport Area Review Team (TSV-ART). The TSV triage team provides support for the ADs by assigning document reviews to TSV-ART, and TSV-ART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

Having an overall architectural view of security and privacy, NAT and Firewall, encapsulation and tunneling, and higher-layer technologies are of added value.

The WIT Area often discusses topics that involve other SDOs. As a result, the set of WIT ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP, and ITU-T.

Together, the WIT ADs are expected to organize their workload, e.g., document review, email discussions as follow-up to document review, IESG emails, WG management, etc., in such a way that the average workload for each AD is about 20 to 30 hours per week.

SEC AD:

The Security Area primarily focuses on protocols that provide one or more security services such as integrity, identification, authentication, authorization, confidentiality, access control and privacy.

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 and communication, including the use of common classes of cryptographic primitives and common misuse of such primitives. 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 major IETF security protocols and building blocks such as TLS, IPsec, SSH, OAuth, HPKE, EDHOC, EAP, and S/MIME. Ideally, at least one AD would be knowledgeable about governance, policy, and risk management; security and privacy controls in complex systems; the web security model; security operations and monitoring; incident response; and security in a systems development lifecycle.

The Security Area intersects with all other IETF Areas and some IRTF Research Groups, and the Security ADs are expected to review, assess and improve the security properties of all documents produced by all IETF Areas. Security ADs become personally involved with coordinating the involvement of 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.

RTG AD :

Routing Area Overview The Routing Area is tasked with ensuring the efficient operation of the Internet routing system. This involves maintaining and enhancing the scalability and stability of existing routing protocols, as well as developing new protocols, extensions, and errata. The area encompasses forwarding methods (e.g., destination-based unicast and multicast forwarding, MPLS, pseudowire), Source Routing and associated routing and signaling protocols (e.g., OSPF, IS-IS, BGP, PCEP, RSVP-TE, LDP, PIM, and VPNs at Layer 2 and Layer 3). Both centralized and distributed routing architectures, for intra- and inter-domain scenarios, including those addressing virtualization, service chaining, traffic engineering, and data center routing, fall within its scope. The Routing Area also manages interactions with configuration and orchestration platforms, such as routing-related device YANG models and path computation engines, and focuses on Generalized MPLS used in the control plane of optical networks, as well as the security and manageability of the routing system. The Working Groups (WGs) in this area cover a wide range of data plane technologies and control protocols.

Requirements for a Routing Area Director (AD) A Routing Area Director must possess a comprehensive understanding of the Internet routing system and its operations. Proficiency in at least two mainstream routing protocols or technologies, such as BGP, OSPF, IS-IS, MPLS, GMPLS, Segment Routing, Traffic Engineering, or multicast, is essential. Knowledge of routing services (e.g., pseudowire, L2VPN, EVPN, L3VPN) and familiarity with recent routing trends (e.g., new routing management models, compute/network integration, time-sensitive routing) are beneficial. Experience in implementing routing protocols, while not mandatory, is highly valuable, as is operational experience and significant contributions to the Routing Area WGs. Experience in non-traditional environments, such as Artificial Intelligence, mobile, ad hoc, and sensor networks, and an understanding of interactions with other network systems, including security and service oriented management, are advantageous. Demonstrated experience in routing protocol security is also valuable.

Management and Coordination The Routing Area is managed by three Area Directors who typically distribute WG responsibilities based on workload and expertise. An active Routing Area directorate supports the ADs by providing technical reviews on demand. Given the broad range of related technical topics, the Routing ADs coordinate closely on the overall direction of the area and routinely engage with WG Chairs. In addition to IESG-level commitments, the Routing ADs hold periodic meetings and organize training and other informal sessions with the WG Chairs.

Interactions with Other Areas and SDOs The Routing Area frequently intersects with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area mainly involves IP forwarding and encapsulation, while work with the Operations and Management Area focuses on developing device and service YANG models and considering the management and operation of the routing infrastructure. Collaboration with the Security Area emphasizes routing protocol security and its broader role in ensuring the authentication, integrity, and authorization of both Internet and local network routing infrastructure. Cross-area expertise in any of these areas is beneficial. The Routing Area's work often overlaps with other Standard Development Organizations (SDOs), particularly the Broadband Forum (BBF), IEEE, 3GPP, and ITU-T, making knowledge of these organizations' workings advantageous.

OPS AD :

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

Unlike most IETF areas, the Operations and 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. The primary technical areas covered by the Operations side of Ops & Management include: operational topics facing the Internet such as DNS operations, IPv6 operations, global routing (including SIDR) operations, operational aspects of SRv6, benchmarking, IoT operations, IP Performance Measurement, operational security, as well as operational issues associated with Network Management. In addition, the Ops part of Ops & Management oversees and organizes the Technology Deep Dives sessions. The Operations AD role includes 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 as well as the ability to gather information from the operations community and then 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 those areas is critical to success. Even more than most AD roles, the Ops AD position requires a very wide range of cross-area knowledge; understanding if an RFC will impact operations requires being an in-depth generalist and the ability to know if an RFC will impact operations and actually be deployable in real networks.

To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, and YANG doctors). The role includes setting objectives for these directorates, coaching, and enhancing OPS-related reviews.

Externally, the Operations and Management Area also interacts with the operations community, operator organizations (e.g., NANOG, RIPE, and OpenConfig), and other SDOs doing work in network management (e.g., 3GPP, IEEE 802, BBF, ETSI, and MEF), and hence any existing relationships with these external communities are helpful.

INT AD :

The primary technical topics covered by the Internet Area include the IP layer (both IPv4 and IPv6), implications of IPv6 adoption, co-existence between the IP versions, DNS, DHCP, IP mobility, multihoming, multicast, host and router configuration, time protocols, Internet of Things, store-and-forward networking, and deep space networking 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. New link-layer protocols still 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, fragmentation, and wireless link-layers.

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, i.e., an INT AD does not need to know everything about all the topics described here. To assist the ADs, there are Internet, DNS, and IoT directorates.

However, with the number of WGs, the Internet Area has historically required some time commitment and breadth of expertise from its ADs. The Internet Area intersects frequently with all of the other Areas:

● Web and Internet Transport (WIT) Area on CoAP, tunneling, address translation, fragmentation, ICMP, and multihoming mechanisms. ● Routing Area on the relationship between the operation of the IP layer and routing functionality, as well as some specific touchpoints related to routing for constrained devices. ● Operations and Management Area on operations required for IPv6 adoption, new sub-IP technologies, YANG models development, and AAA interactions. ● Security Area on topics such as DNS security and privacy, IPsec usage, and network access control. ● Apps and Real Time (ART) area on DNS and about the IoT space where there are tight interactions between application-layer protocols.

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 3GPP, IEEE, BBF, ETSI, and CableLabs. There are also ad-hoc interactions with several standardization organizations in the IoT space. Knowledge of liaison processes and an understanding of how Internet Area protocols are used in various networks (such as broadband, wireless & cellular networks, low-power networks, large data centers, and the "Internet of Things"), is highly desirable.

The Internet Area also includes working groups focusing on space, high delay, and disruption tolerant communications. Experience with these kinds of protocols and operation regimes, as well as with organizations like CCSDS, is an important qualification.

Given all of the above an ideal candidate, in this cycle, should have a good understanding of IPv6, IoT and low-power networking, and constrained devices and networks.

It is perfectly acceptable for a candidate not to be an expert in all these topics -.

ART AD:

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.

This description is 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.

The ART Area works on the application layer and related protocols:

● Real-time applications. These are protocols that enable interactive human-to-human, human-to-agent, and agent-to-agent communication. 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 are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, provisioning and access protocols related to DNS and IP and support for constrained environments. ● Application building blocks. These are designed to be used with a variety of more specific applications. They include compression, codecs, internationalization; JSON, XML, and CBOR; 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, 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, WHATWG, 3GPP, and the Unicode Consortium.

It is important that for each of the following there be at least one AD with some understanding of it and an ability to find and leverage expertise on it when needed: internationalization; URI schemes; SIP, SDP and related services; RTP; media types; and email.

Cross-area expertise with the Security and Web and Internet 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 Web and Internet Transport Area.

ART ADs should be prepared to spend between 40% to 50% of their time on IESG-related activities, with bursts of work especially around IETF meeting time.

ART ADs maintain and support the ART Area Review Team (artart). ARTART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

IESG MEMBER DESIRED EXPERTISE

General IESG Requirement :

This note describes the expertise desired in the candidates selected to fill the positions of all IESG members.

Under the Nominations Committee (NomCom) procedures defined in RFC 7437/BCP 10, the IESG is responsible for providing a summary of the skills and expertise desired of the candidates selected for open IESG positions. This information is included below and is suitable for publication to the community with the NomCom request for nominations.

The IESG realizes that this is a long list of desires and that no one person will be able to meet all of the skills and expertise for a specific position. The IESG trusts that the NomCom will weigh all of these qualities and choose IESG members who represent the best possible balance of them.

Generic IESG Member Expertise

The IESG members are responsible for managing the IETF standards process. They must possess a thorough understanding of IETF operations, recognize areas in which the organization needs to evolve, and excel in collaborative work. They must also be able to inspire and motivate volunteers to work together and be adept at handling strong personalities and loud voices, fostering an environment in which discussions regarding ideas and technical merit may be held freely. An important aspect of this is helping new participants become productive at the IETF and developing talent to fill important IETF roles in the future. And, of course, IESG members must also have sound technical judgment about IETF technologies and its relationship to technology developed elsewhere.

The Area Director (AD) role has a significant people management component, for which prior experience chairing a Working Group (WG) will be useful – although other people-management experience in any organisation can be a reasonable substitute, noting that IETF participants are volunteers. ADs select the WG Chairs and then work with them to manage IETF WGs. Consequently, IESG members should possess sufficient interpersonal and management skills to manage 20 to 40 part-time volunteers. 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 and rotate them for IETF work and leadership at all levels is crucial to the growth and success of the IETF.

ADs are also expected to recognize the need for changes in IETF processes or in the organization's overall role, in response to the evolving Internet and industry landscape.

An ideal IESG member has made significant technical contributions. Similarly, the ability to review and usefully provide constructive feedback on technical documents is a necessary skill for IESG members, for which serving as a document shepherd or on a directorate or review team would provide useful experience; active participation in working groups and other, non-IETF technical review activities can also help build such skills. A broad range of technical abilities and the capacity to quickly comprehend concepts outside their primary areas of expertise are more valuable than specific technical knowledge.

An AD need not be the ultimate expert and authority in any technical area. The abilities to manage, 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 are at least as important as their technical abilities. Although the split varies from area to area, ADs can expect to spend approximately 30% of their IESG time on management tasks, with the remainder of their IESG time being spent on technical matters.

An AD must be able to thoroughly review every Internet Draft for which they are responsible, both those from their working groups and those that they sponsor directly. For other Internet Drafts, an AD combines personal review with the assistance of directorates to be satisfied that adequate review has taken place.

Experience attending multiple IETF meetings, creating Working Group (WG) session agendas, supervising WG sessions, and assisting in arranging interim WG meetings is highly beneficial for an IESG member.

IESG members must have strong oral and written communication skills. They must have experience 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 promptly.

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.

IESG members are expected to perform conflict resolution and process appeals that arise in the course of the IETF standards process. An AD is expected to familiarize themselves with the standards process and handle complaints individually or as part of the IESG team, as may be necessary.

ADs are also responsible for ensuring the review of errata; they may delegate the review to a WG or directorate or perform it personally. An AD should be able to process the errata, which will often require them to identify and reach out to relevant subject-matter experts.

ADs engage with the IANA to identify and approve designated experts for registries created and modified by document actions, and to verify the correctness of IANA actions.

ADs support working group chairs with liaison statements between SDOs in coordination with the IAB.

Basic IESG activities consume significant time during a typical non-meeting week. Enough time must be allocated to manage approximately 10 to 15 working groups, review up to 400 pages of Internet Drafts every two weeks, follow up on document processing tasks, and do management-related activities.There is a weekly 2-hour telechat for the full IESG, in addition to any meetings required to manage the area’s business. Many ADs allocate a minimum of 15 hours per week to such tasks and others up to 30 hours per week. Some ADs have been able to combine significant non-IETF responsibilities with an AD role and/or delegate work to area directorates, while others put a larger proportion of their hours into AD responsibilities. Additionally, an AD should plan to support their peer AD(s) in their area and those outside of their area by occasionally taking over part of their duties to address surges in load or to cover inevitable work or personal matters.

The time commitment varies by Area and by month, with the most intense periods immediately surrounding IETF meetings. ADs during their first year tend to spend more time per week on AD work. IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. ADs may need to interact with external groups such as other standards development organizations (SDOs), which could entail additional travel. We have also found IESG member in-person attendance at most IETF meetings to be imperative, typically arriving one or two days early and leaving one day later (to allow for pre/post-meeting activities). IESG members also attend (preferrably in person) at least one annual IESG Strategy Meeting, as well as occasional workshops and interim meetings. An IESG member should also be comfortable with working and developing professional relationships in a virtual environment. Because participants are in widely varying time zones, the ability to accommodate occasional meetings outside a normal 0900-1700 work day will be required.

All AD roles are volunteer positions and are expected to be self-funded by the AD or their respective sponsor or employer. No stipend, travel funding, or fee waivers are provided.

Do not be afraid of the long text above. Not a single AD matches all the above requirements: it is a matter of balance. On the benefit side, ADs learn a lot from reading 400 pages every 2 weeks, attending meetings outside of their expertise, and work in a nice team!

WIT AD :

The Web and Internet Transport (WIT) area covers protocols that provide the functions of the Transport Layer of the Internet, such as QUIC, TCP, UDP, SCTP, and DCCP, including congestion control and queue management. It also has responsibility for protocols that implement the World Wide Web (like HTTP) and adjacent technologies.

Unlike most IETF areas, the Web and Internet Transport Area is logically divided into two separate functions: Web Protocols and Transport Protocols. This year, the Transport Protocol AD role is open.

Together, the WIT Area Directors are expected to effectively charter, manage, and review current and new transport and web protocol work, including congestion control, loss recovery, Quality of Service (QoS, including Differentiated Services and reservation signaling), proxying and tunneling, QUIC and HTTP protocol extensions, application-network interaction, real-time communication, and storage protocols for the Internet.

The Transport AD should have a broad understanding of core end-to-end transport topics and knowledge about the widely used transport protocols, such as TCP and QUIC, as well as how transport protocols interact with network-layer technologies and application layer protocols. The WIT area includes application-layer protocols that 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 named “infrastructure protocols.” Current work in this category includes evolution, maintenance, and extensions to HTTP, Audio/Video Transport, and the network file system (nfs). A good understanding of infrastructure protocols would be advantageous, as the WIT ADs assist each other in various situations. However, they are not expected to be experts on all or even most of these topics. Rather, they are expected to work well with WIT Area participants who are experts and to have enough familiarity with the principles involved to exercise their judgment about what should be done and why.

Because the transport protocol part of the WIT area working groups often have common interests with IRTF research groups, especially ICCRG, MAPRG, and PANRG, familiarity with these research groups and their subject areas is helpful. Having at least one WIT Area AD with some background in the broader research community is also helpful. There are also open-source communities that implement transport area-related protocols which are beneficial to have contact with.

The Transport AD will manage and recruit volunteers in order to maintain the Transport Area Review Team (TSV-ART). The TSV triage team provides support for the ADs by assigning document reviews to TSV-ART, and TSV-ART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.

Having an overall architectural view of security and privacy, NAT and Firewall, encapsulation and tunneling, and higher-layer technologies are of added value.

The WIT Area often discusses topics that involve other SDOs. As a result, the set of WIT ADs needs to include the ability and experience to relate to a wide range of non-IETF organizations, such as the W3C, 3GPP, and ITU-T.

Together, the WIT ADs are expected to organize their workload, e.g., document review, email discussions as follow-up to document review, IESG emails, WG management, etc., in such a way that the average workload for each AD is about 20 to 30 hours per week.

SEC AD:

The Security Area primarily focuses on protocols that provide one or more security services such as integrity, identification, authentication, authorization, confidentiality, access control and privacy.

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 and communication, including the use of common classes of cryptographic primitives and common misuse of such primitives. 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 major IETF security protocols and building blocks such as TLS, IPsec, SSH, OAuth, HPKE, EDHOC, EAP, and S/MIME. Ideally, at least one AD would be knowledgeable about governance, policy, and risk management; security and privacy controls in complex systems; the web security model; security operations and monitoring; incident response; and security in a systems development lifecycle.

The Security Area intersects with all other IETF Areas and some IRTF Research Groups, and the Security ADs are expected to review, assess and improve the security properties of all documents produced by all IETF Areas. Security ADs become personally involved with coordinating the involvement of 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.

RTG AD :

Routing Area Overview The Routing Area is tasked with ensuring the efficient operation of the Internet routing system. This involves maintaining and enhancing the scalability and stability of existing routing protocols, as well as developing new protocols, extensions, and errata. The area encompasses forwarding methods (e.g., destination-based unicast and multicast forwarding, MPLS, pseudowire), Source Routing and associated routing and signaling protocols (e.g., OSPF, IS-IS, BGP, PCEP, RSVP-TE, LDP, PIM, and VPNs at Layer 2 and Layer 3). Both centralized and distributed routing architectures, for intra- and inter-domain scenarios, including those addressing virtualization, service chaining, traffic engineering, and data center routing, fall within its scope. The Routing Area also manages interactions with configuration and orchestration platforms, such as routing-related device YANG models and path computation engines, and focuses on Generalized MPLS used in the control plane of optical networks, as well as the security and manageability of the routing system. The Working Groups (WGs) in this area cover a wide range of data plane technologies and control protocols.

Requirements for a Routing Area Director (AD) A Routing Area Director must possess a comprehensive understanding of the Internet routing system and its operations. Proficiency in at least two mainstream routing protocols or technologies, such as BGP, OSPF, IS-IS, MPLS, GMPLS, Segment Routing, Traffic Engineering, or multicast, is essential. Knowledge of routing services (e.g., pseudowire, L2VPN, EVPN, L3VPN) and familiarity with recent routing trends (e.g., new routing management models, compute/network integration, time-sensitive routing) are beneficial. Experience in implementing routing protocols, while not mandatory, is highly valuable, as is operational experience and significant contributions to the Routing Area WGs. Experience in non-traditional environments, such as Artificial Intelligence, mobile, ad hoc, and sensor networks, and an understanding of interactions with other network systems, including security and service oriented management, are advantageous. Demonstrated experience in routing protocol security is also valuable.

Management and Coordination The Routing Area is managed by three Area Directors who typically distribute WG responsibilities based on workload and expertise. An active Routing Area directorate supports the ADs by providing technical reviews on demand. Given the broad range of related technical topics, the Routing ADs coordinate closely on the overall direction of the area and routinely engage with WG Chairs. In addition to IESG-level commitments, the Routing ADs hold periodic meetings and organize training and other informal sessions with the WG Chairs.

Interactions with Other Areas and SDOs The Routing Area frequently intersects with the Internet Area, the Operations and Management Area, and the Security Area. Interaction with the Internet Area mainly involves IP forwarding and encapsulation, while work with the Operations and Management Area focuses on developing device and service YANG models and considering the management and operation of the routing infrastructure. Collaboration with the Security Area emphasizes routing protocol security and its broader role in ensuring the authentication, integrity, and authorization of both Internet and local network routing infrastructure. Cross-area expertise in any of these areas is beneficial. The Routing Area's work often overlaps with other Standard Development Organizations (SDOs), particularly the Broadband Forum (BBF), IEEE, 3GPP, and ITU-T, making knowledge of these organizations' workings advantageous.

OPS AD :

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

Unlike most IETF areas, the Operations and 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. The primary technical areas covered by the Operations side of Ops & Management include: operational topics facing the Internet such as DNS operations, IPv6 operations, global routing (including SIDR) operations, operational aspects of SRv6, benchmarking, IoT operations, IP Performance Measurement, operational security, as well as operational issues associated with Network Management. In addition, the Ops part of Ops & Management oversees and organizes the Technology Deep Dives sessions. The Operations AD role includes 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 as well as the ability to gather information from the operations community and then 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 those areas is critical to success. Even more than most AD roles, the Ops AD position requires a very wide range of cross-area knowledge; understanding if an RFC will impact operations requires being an in-depth generalist and the ability to know if an RFC will impact operations and actually be deployable in real networks.

To assist the ADs, there are active directorates (OPS directorate, AAA doctors, Performance Metrics directorate, MIB doctors, and YANG doctors). The role includes setting objectives for these directorates, coaching, and enhancing OPS-related reviews.

Externally, the Operations and Management Area also interacts with the operations community, operator organizations (e.g., NANOG, RIPE, and OpenConfig), and other SDOs doing work in network management (e.g., 3GPP, IEEE 802, BBF, ETSI, and MEF), and hence any existing relationships with these external communities are helpful.

INT AD :

The primary technical topics covered by the Internet Area include the IP layer (both IPv4 and IPv6), implications of IPv6 adoption, co-existence between the IP versions, DNS, DHCP, IP mobility, multihoming, multicast, host and router configuration, time protocols, Internet of Things, store-and-forward networking, and deep space networking 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. New link-layer protocols still 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, fragmentation, and wireless link-layers.

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, i.e., an INT AD does not need to know everything about all the topics described here. To assist the ADs, there are Internet, DNS, and IoT directorates.

However, with the number of WGs, the Internet Area has historically required some time commitment and breadth of expertise from its ADs. The Internet Area intersects frequently with all of the other Areas:

● Web and Internet Transport (WIT) Area on CoAP, tunneling, address translation, fragmentation, ICMP, and multihoming mechanisms. ● Routing Area on the relationship between the operation of the IP layer and routing functionality, as well as some specific touchpoints related to routing for constrained devices. ● Operations and Management Area on operations required for IPv6 adoption, new sub-IP technologies, YANG models development, and AAA interactions. ● Security Area on topics such as DNS security and privacy, IPsec usage, and network access control. ● Apps and Real Time (ART) area on DNS and about the IoT space where there are tight interactions between application-layer protocols.

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 3GPP, IEEE, BBF, ETSI, and CableLabs. There are also ad-hoc interactions with several standardization organizations in the IoT space. Knowledge of liaison processes and an understanding of how Internet Area protocols are used in various networks (such as broadband, wireless & cellular networks, low-power networks, large data centers, and the "Internet of Things"), is highly desirable.

The Internet Area also includes working groups focusing on space, high delay, and disruption tolerant communications. Experience with these kinds of protocols and operation regimes, as well as with organizations like CCSDS, is an important qualification.

Given all of the above an ideal candidate, in this cycle, should have a good understanding of IPv6, IoT and low-power networking, and constrained devices and networks.

It is perfectly acceptable for a candidate not to be an expert in all these topics -.

ART AD:

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.

This description is 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.

The ART Area works on the application layer and related protocols:

● Real-time applications. These are protocols that enable interactive human-to-human, human-to-agent, and agent-to-agent communication. 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 are the protocols we've generally thought of in relation to the application layer. They include such things as email, calendaring, directory services, provisioning and access protocols related to DNS and IP and support for constrained environments. ● Application building blocks. These are designed to be used with a variety of more specific applications. They include compression, codecs, internationalization; JSON, XML, and CBOR; 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, 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, WHATWG, 3GPP, and the Unicode Consortium.

It is important that for each of the following there be at least one AD with some understanding of it and an ability to find and leverage expertise on it when needed: internationalization; URI schemes; SIP, SDP and related services; RTP; media types; and email.

Cross-area expertise with the Security and Web and Internet 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 Web and Internet Transport Area.

ART ADs should be prepared to spend between 40% to 50% of their time on IESG-related activities, with bursts of work especially around IETF meeting time.

ART ADs maintain and support the ART Area Review Team (artart). ARTART provides reviews on request and during Last Call that can be used by the ADs as input for their ballot positions.