ietf
[Top] [All Lists]

Re: Thoughts from a past experimental Nomcom selection for TSV Area Director

2013-03-14 07:09:52
Dave,

Thank you for sharing your experiences in such an open way, and for your
long and dedicated service to the Internet community.

Eliot

On 3/12/13 4:41 PM, David Harrington wrote:
Hi,

Many suggestions have been made about ways to resolve the issue of finding
suitable candidates for TSV Area Director, or adjusting the job to fit
available candidates.

In 2010, I started as TSV AD, after the Nomcom had serious trouble filling
the TSV AD spot. I was encouraged to put my name in as a candidate since I
had solid IETF experience, even though I had no experience with the TSV
area. Interviewing for the position really confirmed for me how little I
knew about transport, so I was very surprised when I was nominated. 

After two years in that specific role, I have some insights I would like to
impart to the Nomcom and the community, and especially to any candidates for
the role who have never served on IESG. I'll repeat some of what has already
been suggested, but I'll try to put these things together to help explain
some contextual relationships that exist.

I. the overall workload

I found IESG/AD work to be a fulltime position, as in 100%. My first year, I
worked anywhere from 60 to 90 hours per week. Of course, I had a lot of
remedial learning to do; honestly, technical on-the-job training for a whole
area while working to perform your IESG review work and other AD tasks is a
tremendous burden. You won't do this in 50% of a normal work week. My second
year, I cut back the number of hours to 50-60 hours a week and took some
vacation time, so I could have a life beyond IESG, and the quality of my
work and my queue management suffered seriously as a result. YMMV. My main
concern is that a candidate with no area background can fall behind quickly,
and possibly never catch up fully within a two-year term.

The workload has two parts - the IESG/steering/approval part, and the area
directing/managing part. I learned over time to split this generally by week
- one week IESG, the next week AD. Otherwise it becomes hard to prioritize
because it is very difficult to prioritize both (time-competing) parts
simultaneously, without favoring one or the other. The job requires you to
do both.

II. workload - IESG 

IESG work requires review of about 15 documents every two weeks; those
documents come from anywhere in the IETF. Many of those documents require
the reviewer to understand the normative references upon which the document
is built. Internet standardization is now quite mature, and much of the new
standards work is dependent on older standards. I came from the SEC area and
the NM side of the OPS area, and those can be somewhat isolated from TSV,
INT, RAI, and routing. If your background has been limited to working in one
or two areas, you may need to learn a LOT about the technical developments
and the existing standards in the other areas. If you have been an active
reviewer in one or more directorates, and/or have previous IESG experience,
that should help a lot, but I still found it a challenge even after
experience in multiple directorates; when you do a security review of a
congestion control document, you look for security issues, not congestion
control issues.

You'll need enough understanding of the TSV issues to be able to spot bad
transport-related decisions in documents coming from elsewhere in the IETF.
You (and your co-AD) are effectively the reviewer of last resort for TSV
issues. If you don't understand control loops, congestion control
techniques, etc., you will NEED to rely on your directorate for assistance
in this role.

If you pride yourself on the thoroughness of your reviews, as I did, get
over it; you won't have time for thorough reviews.

Some have commented on the "extra" stuff related to IESG work, such as
cross-SDO coordination, process tweaking, and so on. These definitely take
time, and they are important because that is part of the job. But other IESG
members can handle the bulk of this extra work while you're still learning
the area.

III. workload - AD

The AD for an area becomes the spokesman/shepherd for all documents coming
from their area. When you bring it to the IESG, you will be asked about the
quality of the document, the technical content, whether certain questions
were considered, what impact this might have to existing networks, how well
the document follows established guidelines for security, management,
operations, IANA assignments, XML usage, and so on. You should know those
guidelines exist and have already asked most of the relevant questions and
had them addressed before you put a document on the telechat agenda. You can
ask various directorates for help. Not knowing the technology will require
you to go ask your experts and try again, possibly repeatedly (you don't get
to bring experts with you to IESG telechats); this can seriously slow the
advancement of a document, and the document should be in your high-priority
queue until it passes.

Sometimes the WG and its chairs submit documents that really are not ready
for IESG review and approval. You can use tools and the shepherd and your
directorate to help weed out the unready documents, but shepherds and
directorates are volunteers, and their time is a scarce resource. For an AD
without area background, I recommend making sure the shepherd is NOT the WG
chair, so you have another quality checkpoint in the loop before bringing
documents to a telechat.

AD Evaluation reviews are supposed to be done within two weeks of submission
of a document. This is really difficult if the AD doesn't know the
technology of the area, and know the standards upon which a document
depends; the learning curve needs to be added to the time required to
process a document. The slower processing will certainly make some people
unhappy. That's part of the cost of having somebody without adequate
technical knowledge in the role of AD.

One role of an AD is to help the community decide whether requests for new
working groups (and BOFs) should be approved or denied. This often requires
the AD/IESG member to "steer" the technology direction, and that can be
contentious - especially if the AD doesn't have a strong background in the
technology. Many requests for WGs are ill-prepared. The AD needs to work
closely with proponents to make clear what threshold needs to be met for
approval - community support, scope of work, clear chartered deliverables,
etc. The AD should definitely seek input and guidance from their directorate
and from other IESG members.

IV. Transport Area factors

Every area has its unique properties and ways of working. There are some
factors about the TSV area that should be considered before choosing an area
director with limited background in TSV technologies, and with limited
experience in the TSV political/economic environment.

V. The hourglass

TSV is partly responsible for the Internet hourglass - the transport
protocols and congestion control. There are four major protocols, and they
are critical to the functioning of the Internet. Here's my glib summary: TCP
is critical - discourage changes because the risk to Internet stability is
too high. UDP should generally be avoided in new work because it doesn't
control congestion. SCTP and DCCP get filtered out by middleboxes, so most
new development won't bother using these. But that's a glib summary.

The work that *is* being done in the transport protocols is very important,
and very research-oriented. TSV is much more research-oriented than other
areas I have worked in. We try to control risk by getting solid empirical
evidence - using safe research networks - about the potential impact of
proposed changes to hourglass protocols and their handling of congestion.
Understanding how research results can be used, where research results
cannot be used, to assess risk is important. It helps to understand the
motivations of researchers, and the academic and governmental environments
that support them.

IETF security standards build upon transport protocols. It is helpful for an
AD candidate to understand the holistic nature of security, and the
use/abuse of congestion in DoS attacks.

A TSV AD needs to assess proposals of new TSV work, and proposals from other
areas, and the potential to cause instability in the hourglass. There are
frequent requests for changes to transport protocols, and many of them carry
a lot of risk relative to the projected benefits. A TSV AD needs to be able
to explain the risks to the community, which often does not understand
congestion control risks, and sometimes stand firm against some of these
proposals. 

Typically, one TSV AD takes the main responsibility for the transport
protocols and congestion control, and the other deals with the miscellaneous
"other" WGs, like storage and content distribution. The current open
position is for an AD for the hourglass protocols, following Lars and Wes. 

Understanding the possible impact of changes to those protocols and
congestion controls **is** important for this role.

VI. Emerging growth areas

Beyond congestion control, the TSV area has a nebulous identity. This makes
the job of TSV AD harder.

Some currently emerging growth areas in the IETF include work related to
virtualization, data centers, clouds, and content distribution. Proponents
of this work are looking for a home. TSV currently has responsibility for
some parts of those growth areas, and a TSV AD (and the IESG) needs to
consider what "miscellany" work belongs in TSV and what doesn't (and this
changes over time). 

TSV has responsibility for storage protocols that need to operate over the
Internet. These include NFS, and Internet interfaces for SCSI and Fibre
Channel. All of these were developed elsewhere. Sun, of course, developed
NFS and donated version 4 for standardization. SCSI and Fiber Channel are
standardized by other SDOs, and we develop the interfaces to the Internet
(iSCSI, FCIP, etc.), and provide feedback to the SCSI and FC SDOs. The IETF
standards for these run in the 300-page document range, and are largely
unrelated to other IETF work. The chairs and the editors really understand
their stuff, and TSV ADs can generally just "let them run" - until they
submit their 300-page documents for IESG review.

Content distribution can cause congestion. This can be true whether big
content (movies, sporting events) is being distributed on the large scale
(your local ISP provides video on demand services), or small content is
being distributed on a small scale (peer-to-peer mp3 file sharing),
frequently. Some of this work could probably be moved into RAI if desired,
since it is often about audio-visual content distribution.

TSV area deals with end-to-end connectivity, and the impact of middleboxes,
such as NATs and firewalls, on this connectivity. Whether NATs are primarily
an IPv4 concept, or will be carried into IPv6 is an ongoing debate.
Hopefully sunset4 will help establish a strategic direction for IPv4
middleware, and an incoming AD will be spared making unpopular decisions
about this when fielding the many requests for new NAT work.

VII. Directorates and the TSV directorate

It has been suggested that an AD without good TSV knowledge should rely on
the TSV directorate for help. 

Directorates serve three main purposes. One is to help the area directors
(and the IESG) perform a "steering" function. Members are (or are becoming)
technical experts in their area, and they undestand the impact of emerging
trends and can help assess proposals for new work. Two is help area
directors, the IESG, and the IETF community assess work that has been
submitted for approval. This is the document review function. Third, a
directorate is a training ground. Directorates often include WG chairs, to
help emerging leaders gain a better understanding of what is happening in
other WGs within their area, and to gain exposure to work that is being done
in other areas.

I am/have been a member of multiple directorates - SIRS (the predecessor for
gen-art), MIB Doctors, OPS-dir, and secdir, plus a number of other
shorter-lived directorates. Each directorate has its own flavor, and its own
type/level of effectiveness. 

My favorite is secdir, because it seems the most effective. The secretary
uses a tool to assign/coordinate directorate reviews, the directorate
includes all area WG chairs plus additional contributors, and the members
are very responsive to requests to review. Reviewers simply check all
documents going to IESG, including checking to see whether anything related
to security is needed in the document. This is made easier by the IETF
requiring a Security Considerations section in every document, so a reviewer
can start there to see what has already been considered, and there are
guidelines about what must be considered. Regular secdir meetings are held,
and often contain discussion of emerging attacks, vulnerabilities,
regulations, cyphersuites, and emerging efforts that need security clue.

The TSV directorate is very different than this. I fully expected that the
TSV directorate would help overcome my lack of TSV experience by reviewing
documents. But this is a volunteer organization, and volunteers needs to
best decide what level of contribution they can and cannot sustain. 

When I started, I didn't understand the nature of TSV and its directorate. I
saw the TSV Directorate at the time as being an all-expenses-paid
somewhat-exclusive dinner club. The "dinner club" included a number of
ex-TSV-ADs and ex-IETF-chairs, plus other high-level guests. They did suffer
the unfortunate effect of being constantly disturbed by food-serving staff,
a lack of any notetaking abut the discussions, and a tendency to stop all
discussions once the main course arrived. However, these dinners were
actually wonderful for serving purpose #1 - identifying emerging trends that
could impact transport; very appropriate for CTO-level discussions, and for
the steering function of a "directorate". 

When I joined as TSV AD, after being on secdir, I was shocked at how few
reviews were done by the directorate. I discussed this with Lars, who
confirmed that ADs could not rely on most directorate members for reviews. A
few were very responsive, but many never did a review in the two years I
served. TSV has a different makeup than secdir or opsdir or the MIB Doctors.
Many are research academics who get very little support for reviewing IETF
documents. Many are senior corporate leaders (CTOs, senior scientists, etc.)
that have very limited time to devote to doing directory work.

Recent suggestions that the TSV directorate do more of the review work for
an AD without transport knowledge will be somewhat misguided, because the
TSV directorate makeup doesn't really support this approach very well. The
economics of academic research and the inclusion of high-level participants
(who don't do document reviews for TSV) hinders this approach a lot.

Lars and Wes and I worked hard to expand the directorate to include more
"mid-level" players - all WG chairs were encouraged to be part of the
directorate, and we moved the meetings from elaborate dinners to lunch-time
meetings like secdir has, and expanded the number of requests for document
reviews. We considered this change important to try to cultivate more
candidates for future Nomcom considerations.

To a degree, increasing the directorate size helped train a new generation
(goal#3), and it helped get more documents reviewed (goal#2) since we now
had a larger active pool to share the review burden. I still found the
directorate not very responsive, but that's volunteerism. I think the TSV
area lost out on steering advice (goal #1) by discontinuing the dinners,
since many chose not to attend the lunch work sessions. I see that Wes and
Martin re-established the dinners. That's a good thing.

Hope this helps,

David Harrington
dbharrington(_at_)comcast(_dot_)net
+1-603-828-1401