Subject: Re: Requirements for Open IESG Positions

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 24 Jul 2007 02:10:44 +0300

Hi,

I just happened to read this mail today. I don't remember seeing such a mail
during previous nomcom rounds (they might have come, but I just didn't
notice them). I think this is a very good overview of the requirements
needed for the IESG positions and gives a nice background to think about the
people who would fit the positions.

However, I think one of the areas is described a bit too much in detail and
perhaps give a wrong impression about the job. The following extract is from
the Security Area:

> 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.

I'm sure this is an oversight, but I think it is generally not according the
IETF process to specific technologies and "hard coding" the division of work
in an area. To my understanding, the Ads in an area are free to divide the
work between themselves as they wish according their strengths. So, if the a
possible new security AD would not be interested to look at these
technologies, perhaps Tim would look at them - according the new division of
work in the area.

In addition, I think it is a bit shaky to mention the current AD in this
context even when the person is not up. Theoretically (I don't know if this
has ever happened outside the creation of the RAI area), that AD could be
moved to the IAB or another position in the IESG. So, it is not 100% sure
that Tim would be continuing as the other security AD though probable.

However, thanks for this clarification I think it is very useful.

Cheers,

Jonne.

On 7/20/07 9:12 AM, "ext Lakshminath Dondeti" <[email-masked]> wrote:

> 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 [email-masked].
> 
> 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.
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 01:29:35 +0200

Jonne,

On 2007-07-24 01:10, Soininen Jonne (NSN FI/Espoo) wrote:
> notice them).

You didn't notice them :-)
Also these descriptions have evolved from year to year
(there is a version in the IESG wiki too, at
http://www3.tools.ietf.org/group/iesg/trac/wiki/AreasDescription,
maybe the IESG should bring it up to date...)

> I think this is a very good overview of the requirements

If you look at the description for the O&M area you will also surely find it
very specific to half the area. I think it's realistic to do this. I don't
object to it.

> context even when the person is not up. 

My personal taste would also be not to mention the co-AD by name.

> Theoretically (I don't know if this

True, but that would then invoke the mid-term replacement process
for the person being moved - and it *has* happened.

    Brian

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 24 Jul 2007 06:59:02 +0300

Hi Brian,

> maybe the IESG should bring it up to date...)

You mean there is e-mail in my inbox I haven't read? ;)
> very specific to half the area. I think it's realistic to do this. I don't

I think the O&M area(s) is a bit different. Here there are three specific
technologies mentioned whereas in O&M area there are two quite different
areas. There is perhaps not a such a clear division of task (like there
isn't in other areas either).

However, like I said this is most probably just an oversight.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Jul 2007 12:03:23 -0400

>>>>> "Soininen" == Soininen Jonne (NSN FI/Espoo) <[email-masked]> writes:

    Soininen> Hi, I just happened to read this mail today. I don't
    Soininen> remember seeing such a mail during previous nomcom
    Soininen> rounds (they might have come, but I just didn't notice
    Soininen> them). I think this is a very good overview of the
    Soininen> requirements needed for the IESG positions and gives a
    Soininen> nice background to think about the people who would fit
    Soininen> the positions.

    Soininen> However, I think one of the areas is described a bit too
    Soininen> much in detail and perhaps give a wrong impression about
    Soininen> the job. The following extract is from the Security
    Soininen> Area:

    >> 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.

    Soininen> I'm sure this is an oversight, but I think it is
    Soininen> generally not according the IETF process to specific
    Soininen> technologies and "hard coding" the division of work in
    Soininen> an area. To my understanding, the Ads in an area are
    Soininen> free to divide the work between themselves as they wish
    Soininen> according their strengths. So, if the a possible new
    Soininen> security AD would not be interested to look at these
    Soininen> technologies, perhaps Tim would look at them - according
    Soininen> the new division of work in the area.

I tend to agree that this is not an ideal practice, but it has been
going on for many years.  The set of technologies listed there are
things that I'm mostly doing these days with particular emphasis on
things Tim doesn't have as much experience with.  Last year, the
description focused on areas Russ had the most experience in.

It's kind of complicated to fix.  If you stuck two security ads in
with my experience or with Tim's experience it would not be ideal.

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Jul 2007 12:07:19 -0500

Done.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Jul 2007 12:44:40 -0700

Some additional comments on the topic: 

In particular, taking the security area requirements as an example, the
description provided talks about expertise needed based on the current
ongoing work in the security area.  While this is one part, we want ADs
that can bring in/ evaluate new work which may or may not be related to
any of the ongoing work in the area.  Especially in the security area,
such relation to other work is very hard to predict.  

Personally, I don't think it is a requirement for an AD to have a deep
understanding of all the protocols produced by the area; rather, for the
security area, for example, I think it is important that the ADs are
capable of analyzing threat models and evaulating the security
implications of work happening in other areas, or have a sufficient
security background to grasp issues raised by experts of a certain
protocol, etc.  I think it is much less important that the AD has a
top-to-bottom understanding of TLS or Kerberos or IKEv2 or any one thing
in particular.  

I provided this input last year as well and I think it is very important
for us to select an "area generalist" as an AD over a specialist in a
particular set of protocols. 

Vidya

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Jul 2007 16:01:10 -0500

One important thing needs to be considered in the Security and O&M 
Areas.  There are two ADs, and they are expected to have somewhat 
different skill sets.  For contrast, here are the requirements that 
were provided to NomCom2006 for these positions.

Russ

-----------------------------------------------
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.
David Kessens is currently responsible for the Operations portion
of the OPS area, so specific expertise required for the open
position would include 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.

-----------------------------------------------
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.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jul 2007 16:31:10 -0500

Sam, Jonne,

Its important to find the right balance between getting
someone who fits exactly the current situation and getting
someone who is the best candidate in a more long term
view.

The ADs in an area need to have an excellent understanding
of the technology the area deals with. Typically, no one
covers everything that we work in an area, so you end
up wanting to have a pair that complements each other.

Having said that, when a new BOF proposal comes in,
you may learn that you suddenly need some new expertise.
We also don't know how long the other AD in the
pair continues to be in that position. Typically at least a year
(given the cycles are on alternating years), but resignations
and movements to other positions have been known to happen.
And the two ADs can change how they divide the area
between themselves. And there are different approaches
to managing an area. Generalist vs.  specialist, for instance.
And you can use experts, directorates,  etc. to help you in
topics that you are not sufficiently good expert in.

(I also thought that the SEC requirements were a bit
too specific this year.)

Jari

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Jul 2007 17:35:38 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> (I also thought that the SEC requirements were a bit too
    Jari> specific this year.)

They are no more specific this year than they have been in the past.
The only change is that they were at least specific in a direction
that would actually compliment the sitting AD.

I personally have never liked the way the security AD requirements
were stated.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jul 2007 16:54:00 -0500

Sam,

> They are no more specific this year than they have been in the past.

Ok -- I did not re-read the ones from past years. Just reacting on
the current text.

> that would actually compliment the sitting AD.

That's fine.

> I personally have never liked the way the security AD requirements
Hmm. Ok. Perhaps we should consider stating them in
a better way then?

Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Jul 2007 15:12:07 -0700

I thought the requirements were too specific for the SEC area last year
as well :) I do realize that the text has been largely reused from last
year, but, I think we need to revisit some of these specific
descriptions.  

We cannot expect the Nomcom to be familiar enough with all areas to use
their judgment in addition to the requirements received.  I think we
need to get better at providing the requirements so that the Nomcom will
really know what they are looking for in candidates.  

At the moment, I really think the SEC area requirements are misleading
to the Nomcom and can use a revision.  

Vidya 

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 2:01 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: RE: Requirements for Open IESG Positions
> 
> One important thing needs to be considered in the Security 
> and O&M Areas.  There are two ADs, and they are expected to 
> have somewhat different skill sets.  For contrast, here are 
> the requirements that were provided to NomCom2006 for these positions.
> 
> Russ
> 
> 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.
> David Kessens is currently responsible for the Operations 
> portion of the OPS area, so specific expertise required for 
> the open position would include 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 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.
> 
> 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.
> 
> >understanding of all the protocols produced by the area; rather, for 
> >the security area, for example, I think it is important that the ADs 
> >are capable of analyzing threat models and evaulating the security 
> >top-to-bottom understanding of TLS or Kerberos or IKEv2 or any one 
> >thing in particular.
> >
> >I provided this input last year as well and I think it is very 
> >important for us to select an "area generalist" as an AD over a 
> >specialist in a particular set of protocols.
> >
> >Vidya
> >
> >

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jul 2007 01:35:20 +0300

Hi,

I agree with Vidya. To be honest, I really thought this was an oversight and
not intentional. 

If the Security area has a similar split as the O&M area, I think this
really should be discussed. To my understanding, we don't have such split
documented to any other area and I think this kind of "hard" split should be
discussed. Perhaps the split is right and I just wasn't aware of it.
However, it seems other people were unaware of the split as well.

BTW, are the explicit technologies Kerberos, GSS-API, and SASL representing
the "other half" of the area. I'm asking, because I'm not a security expert
and not active in the security area.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34