This note describes the expertise desired in the candidates selected to fill the positions of the IESG members whose terms will expire during the first IETF Meeting in 2011.
Under the Nominations Committee (NomCom) procedures defined in RFC 3777, the IESG is responsible for providing a summary of the 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.
We realize that this is a long list of demanding qualifications, and that no one person will be able meet all of the requirements for a specific position. We trust that the NomCom will weigh all of these qualifications and choose IESG members who represent the best possible balance of these qualifications.
IESG members are the managers of the IETF standards process. They must understand the way the IETF works, be good at working with other people, be able to inspire and encourage other people to work together as volunteers, and have sound technical judgment about IETF technology and its relationship to technology developed elsewhere.
Area Directors (ADs) select and directly manage the Working Group (WG) Chairs, so IESG members should possess sufficient interpersonal and management skills to manage 15 to 30 part-time people. Most ADs are also responsible for the management of one or more directorate or review team. The ability to identify good leaders and technical experts, and then recruit them for IETF work is important. Experience as a WG Chair provides important understanding of that role, and it will help when trying to resolve problems and issues that a WG Chair may have.
All IESG members should have strong technical expertise that crosses two or three IETF Areas. An ideal IESG member has made significant technical contributions in more than one IETF Area, preferably authoring documents and/or chairing WGs in more than one IETF Area. ADs are expected to personally review every Internet-Draft that they sponsor. For other Internet-Drafts, ADs must be satisfied that adequate review has taken place.
It is very helpful for an IESG member to have a good working knowledge of the IETF document process and WG creation and chartering process. This knowledge is most likely to be found in experienced IETF WG Chairs, but may also be found in authors of multiple documents. It is very helpful for an IESG member to have experience attending multiple IETF meetings, creating agendas and supervising WG sessions, and helping to arrange interim WG meetings.
IESG members must have strong verbal and written communications skills. They must have a proven track record of leading and contributing to the consensus of diverse groups.
IESG members must deal with many technical topics, so a strong technical background is required, but IESG members should also have strong management and communication skills. An IESG member should guide WGs to follow their charters and nurture new talent to fulfill IETF leadership roles in the future.
Serving on the IESG requires a substantial time commitment. The basic IESG activities consume between 25 and 40 hours per week. The time commitment varies by Area and by month, with the most intense periods immediately before and during IETF meetings. Historically, many ADs have spent approximately full time on IETF-related activities. Most IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. Even if they do not occupy formal liaison positions, ADs may also need to interact with external groups such as other standards development organizations (SDOs), which may require travel. It is also imperative that IESG members attend all IETF meetings, typically arriving one or two days early. IESG members also attend one, and sometimes two, IESG retreats per year.
Because of the large time and travel commitments, sponsor support for a full two year term is essential. Because of personal impact, including awkwardly timed conference calls, the family of the IESG member must also be supportive.
The Applications Area has historically focused on three clusters of protocols. The first cluster contains application protocols that have been ubiquitous for some time but which continue to develop (e.g., email, HTTP, FTP). The second cluster contains protocols which are used for Internet infrastructure (e.g., IDNA and EPP). The third cluster contains "building block" protocols which are designed for re-use in a variety of more specific applications (e.g., LDAP, MIME types, URI schemes, URNs, OAuth, language tags). Current working groups include topics such as: email, web foundations and security, internationalization, virtual worlds, calendaring, personal address books, simple resource manipulation protocol for devices in constrained networks, some helper technologies for network storage and peer-to-peer applications.
The Applications Area often discusses whether something is properly the realm of the IETF or "belongs" to other SDOs. As a result, an Applications AD needs to be willing and able to relate to a wide range of non-IETF organizations, such as the W3C. An Applications AD is also trusted to make these critical decisions about the scope of the IETF's work.
The Applications Area often re-uses technology developed elsewhere, and it often must consider whether the IETF or another SDO is the best home for proposed work. Thus an Applications AD needs to be willing and able to relate to a wide range of non-IETF organizations, such as the Unicode Consortium.
Because of the breadth of the Applications Area, an Application AD needs to deal with a large set of Internet application protocols, including many with which he or she may not have direct experience. An Applications AD needs to be good at evaluating new approaches to new problems and assessing the expertise of the people who bring them to the IETF.
The set of people in the Applications Area changes with the protocols under development at the time. Therefore it is good if an Applications AD can clearly explain how the IETF works and can help new WGs work well within the IETF framework. The ability to reach out to new technology communities is also important so that the Applications Area stays relevant to the ongoing evolution of Internet applications.
The Applications Area most often intersects with, and sometimes swaps WGs or work items with, the Security Area, the RAI Area, and the Transport Area. In addition, WGs in other areas often re-use technologies that were developed or formalized in the Applications Area (e.g., URIs, MIME, and XML). Therefore cross-area expertise in any of these areas would be particularly useful.
The primary technical topics covered by the Internet Area include: IP layer (both IPv4 and IPv6), implications of IPv4 address depletion, co-existence between the IP versions, DNS, host and router configuration, DHCP, mobility, multihoming, multicast, time protocols, and identifier-locator separation 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.
Between them, the Internet ADs are expected to have a solid understanding of these technologies, including issues related to IP addressing, forwarding, tunneling, and fragmentation.
The Internet Area has one of the broadest ranges of technical topics. The Internet Area ADs typically divide the WGs that they manage based on workload and expertise. To assist the ADs, there are active DNS and IP directorates. However, with the large number of WGs and high rate of BOF proposals, the Internet Area has historically required considerable time commitment and breadth of expertise from its ADs.
The Internet Area intersects most frequently with the Transport, Routing, Operations & Management, and Security Areas. Interaction with the Transport Area is related to work on address translation, IPv4-IPv6 co-existence, and multihoming mechanisms. Interaction with the Routing Area concentrates mainly on the relationship between the operation of the IP layer and routing functionality. Interaction with the Operations & Management Area is focused on operations required for IPv6 adoption, MIB development, and AAA interactions. Interaction with the Security Area is focused on topics such as IPsec usage, DNS security, and network access control. Cross-area expertise in any of these Areas is particularly useful. The Internet Area is also often involved in the adaptation of a variety of technologies to IP, some of which may require interactions with other organizations such as the ITU, IEEE, CableLabs?? and the BBF. Expertise with liaison processes and an understanding of how Internet Area protocols are used in various networks, including Broadband (DSL and Cable), wireless and cellular networks, low-power networks and the "Internet of Things", and so on is desirable.
The primary technical areas covered by the Operations & Management Area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, and Routing operations.
Unlike most IETF areas, the Operations & Management area is logically divided into two separate functions: Network Management and Operations. This year, the Operations AD role is open, so specific expertise required for the open position includes a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary.
The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence.
Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies.
The Operations portion of the OPS area intersects most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful.
The Real-Time Applications and Infrastructure (RAI) Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in the RAI Area serves an industry whose applications and services include voice and video over IP, instant messaging, and presence. These applications and services are "real-time" in the sense described in RFC 1889.
The infrastructure applications needed to support real-time interpersonal communication are also part of the RAI Area, as are discussions of operational concerns specific to these protocols. For example, work might relate to presence services, to session signaling protocols and emergency call routing solutions, or to work on the "layer five" issues for Internet telephony.
Historically, RAI ADs have spent approximately full time on IETF-related activities.
Like all Areas of the IETF, the RAI Area draws on the work of numerous other Areas, and as such there cannot be knife edge boundaries delineating the work in the RAI Area from the rest of the IETF.
The Routing Area is responsible for ensuring continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols, as well as developing new protocols, extensions, and bug fixes in a timely manner. Forwarding methods (such as destination-based unicast and multicast forwarding, MPLS, and pseudowire) as well as associated routing and signalling protocols (such as OSPF, IS-IS, BGP, RSVP-TE, LDP, PIM, L1-, L2-, and L3-VPNs) are within the scope of the Routing Area. The Routing Area also works on Generalized MPLS used in the control plane of optical networks as well as security aspects of the routing system. New work in the Routing Area is developing a routing protocol (RPL) for use in low-powered and lossy networks.
A Routing AD must have solid knowledge of the Internet routing system and its operations. A Routing AD must be proficient in at least one of the mainstream routing protocols/technologies such as BGP, OSPF, IS-IS, MPLS, GMPLS, or multicast. Implementation and deployment experience as well as significant contributions to the WGs in the Routing Area are highly desirable.
The Routing Area intersects most frequently with the Internet Area, the Operations & Management Area, and the Security Area. Interaction with the Internet Area concentrates mainly on IP Forwarding, Multicast, and VPNs. With the Operations & Management Area the focus is on MIB development. With the Security area the focus is on routing protocol security. Cross-area expertise in any of those areas would be particularly useful.
Current work in the Routing Area has some overlap with work in other SDOs, in particular interactions with the ITU-T on MPLS-TP can be expected to consume a considerable amount of the ADs' time. This requires careful interaction through the liaison process and requires attendance at ITU-T plenary meetings and possibly a number of MPLS-TP- related interim meetings. Knowledge of the workings of the ITU-T would be beneficial.
The WGs within the Security Area are primarily focused on security protocols. They provide one or more of the security services: integrity, authentication, non-repudiation, confidentiality, and access control. Since many of the security mechanisms needed to provide these security services employ cryptography, key management is also vital.
Specific expertise required for a Security AD includes a strong knowledge of IETF security protocols and a good working knowledge of security protocols and mechanisms that have been developed in the Security Area, other Areas of the IETF, and outside the IETF. It is also important for Security ADs to understand broader aspects of network and Internet security as well as the practical issues in securing Internet resources, such as techniques for denial-of-service mitigation. Security ADs must match the cost of security to the value of the resources being protected, and they must balance security against usability. Between the two Security ADs there needs to be knowledge about many of the following security protocols: PKIX, IPsec, TLS, SASL, Kerberos, GSS-API, EAP, CMS, and S/MIME.
The Security Area intersects with all other IETF Areas, and its ADs are expected to read and understand the security implications of documents produced by all IETF Areas. Security ADs become personally involved and coordinate the involvement of other security experts in the work of other IETF Areas. Broad knowledge of IETF technologies and the ability to assimilate new information quickly are imperative for a Security AD.
The Transport Area works on mechanisms related to end-to-end data transport to support Internet applications and services that exchange potentially large volumes of traffic at potentially high bandwidths. A key focus are mechanisms to detect and react to congestion in the Internet, such as the congestion control algorithms in Internet transport control protocols such as TCP, SCTP, and DCCP, as well as congestion management schemes such as PCN and CONEX.
Current and new transport work includes congestion signaling and reporting, forward error correction, multicast, QoS and reservation signaling, DiffServ and congestion control for unresponsive flows, NAT regularization and specification, storage protocols for the Internet, peer-to-peer streaming, performance metrics for Internet paths, experimentation with congestion control schemes developed in the IRTF, multipath extensions to existing transport protocols, congestion control for "background" bulk transfers, and extensions to the IETF protocols for multimedia transport.
A Transport AD should have a good understanding of core end-to-end transport topics such as congestion control, flow control, real-time transport protocols, NATs, and firewalls. A Transport AD also needs to be familiar with the end-to-end aspects of various applications and application-layer protocols, in order to have a view on how Transport Area efforts will impact the users of the Area's work. A Transport AD needs to be familiar with the IP layer technologies and protocols on top of which most Transport Area work occurs. Finally, some topics in the Transport Area have strong ties to the research community, therefore some research background can be helpful.
The Transport Area intersects most frequently with Internet Area, the Applications Area, the RAI Area, the Security Area, and several IRTF research groups. Cross-area expertise in any of those Areas would be particularly useful.
The IETF Chair has six major roles: overseeing the work of the IETF as a whole, representing the IETF to the outside world, overseeing the work of the IESG in particular, serving as the General AD, serving as a voting member of the IAB, and serving as a voting member of the IAOC and the IETF Trust.
Serving as IETF Chair is a full-time job. A candidate for this position needs to be willing to put aside his or her own technical work and other major professional roles for the duration of the term.
Chairing the IETF requires excellent communications skills, strong leadership skills, the ability and willingness to keep the community informed of all issues that are important to the IETF as a whole, the ability to establish community consensus on issues important to the IETF as a whole, and the ability to speak and act in accordance with that consensus. Among other things, this involves working with the IAB Chair to plan plenary sessions and effectively running meetings with over 1000 attendees.
In the IESG Chair role, the IETF Chair is responsible for coordinating the activities of the other ADs and providing top-level management for the IETF standards process. The IETF Chair must be capable of intervening when difficulties arise between ADs or between an AD and a WG Chair. The IETF Chair also oversees the handling of appeals sent to the IESG, the mechanisms for IESG internal process change, and the production of any statements issued by the IESG.
The General Area consists of a few IETF WGs and other activities focused on supporting, updating and maintaining the IETF standards development process. As General AD, the IETF Chair should meet the generic requirements for an IESG member listed above, and is expected to play a full role in IESG document review and approval. The General AD must also have a strong understanding of the IETF standards process and a commitment to maintain and improve that process in a careful and open manner. The General AD manages the General Area Review Team (Gen-ART) and other IETF-wide directorates.
The IETF Chair is a voting member of the Internet Architecture Board (IAB). The IAB has a long history, but the IAB is currently viewed as the senior committee working with the IETF to provide both architectural and oversight functions for the development of the Internet. The IETF Chair brings important perspective to the oversight of the RFC Editor, the IANA functions, and the liaison process with other SDOs. The IAB also has a role in appeals and confirmation of NomCom candidate selection for IESG members; however, since the IETF Chair is also an IESG member, IETF Chair is recused from these activities.
The IETF Chair serves as a voting member of the IETF Administrative Oversight Committee (IAOC) and as a Trustee of the IETF Trust. Although day-to-day management of administrative matters is handled by the IETF Administrative Director (IAD), the IETF Chair will spend some time each week on IAOC or Trust business, particularly in the context of ensuring the IETF is properly supported by its service providers, and that the IAD has adequate support.
The IETF Chair is asked to speak at numerous conferences and to represent the IETF to government officials, representatives of other standards bodies and the press. While the IETF Chair has control over which of these invitations he or she accepts, any candidate for this position should be willing and able to represent the IETF effectively in these fora, in consultation with the IAB Chair as appropriate.
The content of this page was last updated on 2010-06-24. It was migrated from the old Trac wiki on 2023-02-17.