To: Mary Barnes, 2009-2010 Nomcom Chair
On behalf of the IESG, please see below for the official IESG
requirements for your consideration and review. These were approved today,
June 18, 2009, on the IESG telechat.
Kind regards,
Alexa Morris
IETF Executive Director
------
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 2010.
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 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 volunteers. Most ADs are
also responsible for 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. 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 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.
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 fulfill 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. 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
bodies, 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, 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., IDNA, 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, XML namespaces, URI
schemes, MIME types, LTRU, HTTP, OAuth, and BEEP). Current topics
include: internationalization, email, calendaring, personal address
books, web protocols, blogging, directories, registries, and language
support.
The Applications Area often makes use of technology developed elsewhere,
and it often must consider whether the IETF or another SDO is the best
home for proposed work. 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.
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 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, identifier-locator
separation, VPNs and pseudowires along with related MPLS issues, 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.
The Internet Area ADs typically divide the WGs that they manage based
on workload and expertise. To assist the ADs, there are active
Mobility, 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.
Expertise with liaison processes and an understanding of how Internet
Area protocols are used in various access networks, including Broadband
(DSL and Cable), wireless and cellular networks, low-power, satellite,
and so on is desirable. Similarly, interaction with the ITU on various
topics is often required.
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, of the related protocols, including but not limited
to NETCONF, SNMP, RADIUS, Diameter, and CAPWAP, and of data modeling and
data modeling languages used in management such as SMI and YANG (from
the netmod WG). A strong architectural background is desirable taking
into account that the evolution of the management architecture of the
Internet is expected to be one of the principal subjects of interest and
work for the OPS Area in the coming years.
Another important role of the Management AD is to identify potential or
actual management issues regarding IETF protocols and documents in all
Areas, and to work with the other Areas to resolve those issues. This
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 the Internet
architecture and of the IETF protocols.
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
important topic. The OPS Area also interacts with the operations
community, operator organizations like NANOG, and other SDOs doing work
in network management such as the ITU-T or the IEEE 802.
REAL-TIME APPLICATIONS AND INFRASTRUCTURE AREA
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.
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 (such as OSPF, IS-IS, BGP, RSVP-TE, PIM, L1- 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 and security aspects of the routing system.
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
(particularly for IP forwarding, multicast, and VPN), 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.
Current work in the Routing Area has some overlap with work in other
SDOs, in particular the ITU-T. This requires careful interaction
through the liaison process and may require attending ITU-T meetings.
A willingness to participate in these meetings is an advantage, and a
knowledge of the workings of the ITU-T would be beneficial.
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 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. Between
them, the Security ADs should have a strong understanding of security
technologies under active development including: IPsec, TLS, SASL,
Kerberos, GSS-API, EAP, CMS, and S/MIME. A strong candidate will have
significant experience with a number of these protocols.
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 IETF areas, from providing security for higher-level
protocols and applications to securing the network infrastructure such
as routing and IP. Security ADs are both 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.
It is also important for Security ADs to understand the broader
aspects of network and Internet security and the practical issues in
securing Internet resources, including matching the cost of security
to the value of the resources being protected and balancing security
against usability.
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 specification, and NFS.
The Transport Area is considering future work on transport mechanisms to
support applications that exchange large volumes of traffic at
potentially high bandwidths, investigating the interactions between
transport protocols and network-layer extensions for mobility,
multihoming and new routing approaches, experimentation with congestion
control schemes arriving via the IRTF, multipath extensions to the
existing transport protocols and extensions to the IETF's current
protocols for multimedia transport, including peer-to-peer live
streaming.
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. The 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 a
research background can be helpful.
The Transport Area intersects most frequently with the Internet, RAI,
Applications, and Security Areas, as well as several IRTF research
groups. Cross-area expertise in any of these Areas would be
particularly useful.