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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for describing this, David. I found it very useful and enlightening.

Jari

On Mar 12, 2013, at 4:41 PM, David Harrington <dbharrington@xxxxxxxxxxx> 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@xxxxxxxxxxx
> +1-603-828-1401
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]