datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Announcement: November 11, 2005 - [Fwd: Requirements for Open IESG Positions]

From: Ralph Droms <rdroms@cisco.com>
To: IETF Announcement list <ietf-announce@ietf.org>
Date: November 11, 2005
Subject: [Fwd: Requirements for Open IESG Positions]


Under the Nominations Committee 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 Nomination Committee's 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. This
means that 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 on a volunteer basis, and have sound technical
judgment about IETF technology and its relationship to technology
developed elsewhere.

ADs select and directly manage the WG chairs, so IESG members should
possess sufficient interpersonal and management skills to manage
~15-30 part-time people. Most ADs are also responsible for one or
more directorates or review teams. So the ability to identify good
leaders and technical experts and recruit them for IETF work is
required. Having been a WG chair helps in understanding the WG chair
role, and will help in resolving 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.

IESG members are expected to make sure that every document coming
before the IESG is properly reviewed. Although IESG members may
delegate the actual review to individuals or review teams, the IESG
members will need to understand and represent the reviewers'
objections or comments. So the ability and willingness to read and
understand complex information quickly is another important attribute
in an IESG member. (Note that this does not mean that every AD
must review every draft personally - but they must be satisified
that adequate review has taken place.)

It is 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 and a proven track record of leading and contributing to the
consensus of diverse groups.

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 organizations, which may require travel. It is
also imperative that IESG members attend all IETF meetings and up
to two additional IESG retreats per year.

Because of the large time and travel commitments, employer support for
a full two year stint is essential for an IESG member. Because of
personal impact including awkwardly timed conference calls, an IESG
member's family must also be supportive.

-----------------------------------------------
Applications Area:

The Applications Area focuses on applications that run across the
Internet and require some sort of standardized infrastructure to be
effective. This includes, but is not limited to: E-Mail, Web protocols,
Directory services, printing services and NetNews.

The Applications area often discusses whether something is properly
the realm of the IETF or "belongs" to other organizations. Because of
this, and Applications AD needs to be willing and able to relate to a
wide range of non-IETF organizations. An Applications AD also needs
to be someone that we can trust 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.
So, 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 currently under development, 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
working groups or work items with, the Security Area (for
application-level security, or applications where security is an
important aspect) and the Transport Area (for issues with congestion
in applications), so cross-area expertise in either of these areas
would be particularly useful.

-----------------------------------------------
Internet Area:

The primary technical areas covered by the Internet area include:
IP(v4 & v6), Layer 2 and 3 VPNs and related MPLS issues, DNS, Host
and Router Configuration, Mobility, DHCP, Network Access
Control and 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 the above, also including MTU and fragmentation
related issues, various types of IP addressing, IP forwarding and
IP tunneling.

The Internet area has one of the broadest ranges of technical
topics. It has been typical of the Internet area to have its two Area
Directors 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 and
DNS directorates to draw upon. However, the NomCom should consider
the skills of the sitting Internet Area Director and look for technical
balance with even more care than in other areas.

The Internet area intersects most frequently with the Routing Area
(particularly for IP Forwarding, Multicast and MPLS), the Operations &
Management Area (for MIB development & Link-layer security mechanisms
(AAA/RADIUS)) and the Security Area (for IPsec and IKE). So,
cross-area expertise in any of those 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,
Routing operations.

Unlike most IETF areas, the Operations & Management area is logically
divided into two separate functions: Network Management and Operations.
Bert Wijnen is responsible for the Network Management portion
of the OPS area, so specific expertise required for the 2005 open
position would include a strong understanding of Internet management,
including but not limited to SNMP, SMI and Netconf.

The Network Management AD is largely responsible for development and
direction of Network Management protocols like SNMP, SMI, NetConf,
CAPWAP etc.

Another important role of the Network 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 may be monitored and configured. It also requires a strong
cross-area understanding of IETF protocol architecture and technologies.

The Network Management portion of the OPS area intersects with all
areas, specifically in reviewing and assisting with MIB documents.
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 set out in RFC 1889.

The RAI Area is seeded with existing working groups from the Transport
and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM,
IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, AVT, and SIGTRAN.
A good rule of thumb for the incorporation of new work into RAI, as opposed to
Transport or Applications, is that the work in question is needed to support
real-time interpersonal communication. The infrastructure applications needed
to support such communications are explicitly in scope, as are discussions of
operational concerns specific to this area. 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 can be no neat mathematical boundaries
delineating RAI's work from the rest of the IETF. The new area will
allow an existing community within the IETF to solidify its vision and
to benefit from increased institutional support.

-----------------------------------------------
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 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 and 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
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). So, 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 would include a
strong knowledge of IETF security protocols, particularly IPsec, IKE,
and TLS, and a good working knowledge of security protocols and
mechanisms that have been developed inside and outside the IETF, most
notably including PKI.

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. So, broad knowledge of IETF technologies and
the ability to assimilate new information quickly are imperative for a
Security AD.

-----------------------------------------------
Transport Area:

The technical areas covered by the Transport area are those with data
transport goals or with transport design issues and impact on
congestion in Internet. To illustrate the latter: the Pseudowire
Emulation Edge to Edge working group (PWE3) was initially in Transport
until the architecture was developed, and then moved to the Internet
area. The major topics in Transport are protocols (TCP, UDP, SCTP,
DCCP), congestion control, multicast transports, QOS and reservation
signaling, performance metrics, NAT regularization, NFS, and
Internet storage. Transport is considering future work in generalized
forward error correction, overlay multicast, very high bandwidth traffic,
and peer to peer protocol transport.

A Transport AD should have a good understanding of congestion control,
flow control, real-time transport protocols 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.

The Transport area intersects most frequently with Internet Area, the
Applications Area, the RAI Area, and the Security Area. So, cross-area
expertise in any of those areas would be particularly useful.

The Transport area has a strong management tradition. Although the
technical areas are many, a Transport Area Director should have not
just technical skills but also strong management and communication skills.
Two of the critical skills that the Area values especially:
o Guiding working groups to follow their charters closely
o Nurturing new talent for the area's leadership