RFC 3777 says the following about the qualifications required for open
IESG/IAB positions:
"The IESG and IAB are responsible for providing summary of the
expertise desired of the candidates selected for their
respective open positions to the Executive Director. The
summaries are provided to the nominating committee for its
consideration.
2. The nominating committee selects candidates based on its
understanding of the IETF community's consensus of the
qualifications required and advises each confirming body of its
respective candidates."
The following is the information provided by the IESG to the nomcom.
The nomcom is now accepting the community's input on the qualifications
required for the open IESG positions. Please send your notes, either as
commentary on the following or independent notes to nomcom07 at ietf.org.
Thank you.
best regards,
Lakshminath
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 2008.
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, along
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.
GENERIC REQUIREMENTS
IESG members are the managers of the IETF standards process. They 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 one or more directorate or review teams. The ability to
identify good leaders and technical experts, and then recruit them for
IETF work is important. Having been a WG chair helps understand the WG
chair role, and it will help when trying to resolve problems and issues
that a WG chair may have.
In addition, all IESG members should have strong technical expertise that
crosses two or three IETF areas. Ideally, an IESG member would have made
significant technical contributions in more than one IETF area,
preferably authoring documents and/or chairing WGs in more than one area.
(ADs are expected to personally review every Internet-Draft that they
sponsor. For other Internet-Drafts, ADs must be satisified 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.
IESG members must also 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 an 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 fulfil IETF leadership
roles in the future.
A FEW COMMENTS ON THE IESG ROLE
Serving on the IESG requires a substantial time commitment. The basic
IESG activities consume between 25 and 40 hours per week (varying by area
and by month, with the most time required immediately before IETF
meetings). 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 bodies 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) and attend one, and sometimes two, IESG retreats
per year.
Because of the large time and travel commitments, employer support for a
full two year term is essential. Because of personal impact, including
awkwardly timed conference calls, an IESG member's family must also be
supportive.
APPLICATIONS AREA
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
and the web). The second cluster contains protocols which are used for
Internet infrastructure (e.g., epp and iris). The third cluster contains
"building block" protocols which are designed for re-use in a variety of
more specific applications (e.g., LDAP). Current working groups include
topics such as: email, calendaring, web protocols, blogging, directories,
registries, language support, and user-interface-level communications.
The Applications Area often discusses whether something is properly the
realm of the IETF or "belongs" to other SDOs. Because of this, an
Applications AD needs to be willing and able to relate to a wide range of
non-IETF organizations. 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. Because of this, and Applications AD needs to be
willing and able to relate to a wide range of non-IETF organizations.
Because of the breadth of the Applications Area, an Application AD will
have to deal with a large set of Internet applications 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.
Because the set of people in the Applications Area changes with the
protocols under development at the time, the ability to clearly explain
how the IETF works, and to help new WGs work well within the IETF
framework is also important.
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, so cross-area expertise in any of these areas would be particularly
useful.
INTERNET AREA
The primary technical areas covered by the Internet Area include: IP
(both v4 and v6), Layer 2 and 3 VPNs (and related MPLS issues), DNS, Host
and Router Configuration, DHCP, Mobility, Multihoming, Identifier-Locator
Separation, Network Access Control, and various link-layer technologies.
The Internet Area is also 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. It
has been typical of the Internet Area to have its two ADs divide the
topics they specialize in, because it is too much to expect that both ADs
will have a very strong command of all topics in the Area. To assist
them, there are active Mobility, DNS, and IP directorates. However, the
NomCom should consider the skills of the sitting Internet AD and look for
technical balance with even more care than in other Areas. With the large
number of WGs, the Internet Area is likely to require full-time
attention.
The Internet Area intersects most frequently with the Routing, Operations
& Management, and Security Areas. Interaction with the Routing Area
concentrates mainly on IP Forwarding, Multicast, and MPLS issues. With
the Operations & Management Area the focus is on MIB development and AAA-
based network access control mechanisms. With the Security area the focus
is on topics such as DNS security, EAP, and network access control.
Cross-area expertise in any of these Areas would be particularly useful.
OPERATIONS & MANAGEMENT AREA
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.
Rob Bonica is currently responsible for the Operations portion of the OPS
area, and NomCom will select a person who will be responsible for the
Management portion of the OPS area. Specific expertise required for this
open position would include a strong understanding of Internet management
and AAA and of the related protocols, including but not limited to SNMP,
SMI, RADIUS, Diameter, Netconf, and CAPWAP.
Another important role of the Management AD is to identify potential or
actual management issues regarding IETF protocols and documents in all
areas, and to work with the other Areas to resolve those issues. This
requires a strong understanding of how new and updated protocols should
be managed, including aspects related to configuration, monitoring and
alarms. It also requires a good understanding of the operational
environment and a strong cross-area understanding of IETF protocol
architecture and technologies.
The Management portion of the OPS area intersects with all Areas,
specifically in reviewing and assisting with documents related to
management or AAA aspects (for example documents defining MIB modules or
usage of RADIUS and Diameter). Thus, cross-area expertise in any Area
would be useful. Security of network management is a particularly current
topic.
REAL-TIME APPLICATIONS AND INFRASTRUCTURE AREA
The Real-Time Applications and Infrastructure Area develops protocols and
architectures for delay-sensitive interpersonal communications. Work in
this 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.
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.
ROUTING AREA
The Routing Area is responsible for ensuring continuous operational
status 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.
In particular, forwarding methods (such as destination-based unicast and
multicast forwarding, and MPLS), as well as associated routing and
signalling protocols (e.g., OSPF, IS-IS, BGP, RSVP-TE, PIM) are within
the scope of the Routing Area. The Routing Area also works on Generalized
MPLS used in the control plane of optical networks and on security
aspects of the routing system.
A Routing AD is required to 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
(particularly for IP Forwarding and Multicast), the Operations &
Management Area (for MIB development), and the Security Area (for Routing
Protocol security). Cross-area expertise in any of those areas would be
particularly useful.
SECURITY AREA
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 are cryptographic, key management is also vital.
Security ADs are expected to ensure that all IETF specifications are
reviewed for adequate security coverage. They also manage a set of
security resources that are available to most IETF Areas and WGs.
Specific expertise required for a Security AD includes strong knowledge
of IETF security protocols. To complement Tim Polk, the person selected
as Security AD should have a working understanding of Kerberos, GSS-API,
SASL, and how these relate to security protocols and to their use in
applications and other security protocols. A basic understanding of
IPsec, IKE, TLS, PKI would also be useful.
Also, a Security AD should understand how to weigh the security
requirements of a protocol against operational and implementation
requirements. We must be pragmatic; otherwise people will not implement
and deploy the secure protocols that the IETF standardizes.
The Security Area intersects with all other IETF areas, and its ADs are
expected to read and understand the security implications of documents in
all Areas. Broad knowledge of IETF technologies and the ability to
assimilate new information quickly are imperative for a Security AD.
TRANSPORT AREA
The technical topics covered by the Transport Area are those with data
transport goals or with transport design issues and impact on congestion
in the Internet. To illustrate the latter: the Pseudowire Emulation Edge
to Edge Working Group (PWE3) was initially in Transport Area until the
architecture was developed, and then moved to the Internet Area. The
major topics in the Transport Area are protocols (TCP, UDP, SCTP, DCCP),
congestion control, multicast and forward-error-correction transports,
QoS and reservation signaling, DiffServ and congestion control for
unresponsive flows, performance metrics, NAT regularization, and NFS. The
Transport Area is considering future work in very high bandwidth traffic,
interactions between transports and network-layer mobility and
multihoming mechanisms as well as new Internet architectures, and
experimentation with congestion control schemes developed in the IRTF.
A Transport AD should have a good understanding of congestion control,
flow control, real-time transport protocols, NAT and firewalls and other
transport-level issues that affect application layer protocols. These
basic transport skills should also be augmented by strong interest and
skills in such issues as NAT and identity. Some topics in the Transport
Area have strong ties to the research community, therefore a 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.