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 >