On Mar 14, 2013, at 8:08 AM, Eliot Lear <lear@xxxxxxxxx> wrote: > Dave, > > Thank you for sharing your experiences in such an open way, and for your > long and dedicated service to the Internet community. > > Eliot Unequivocally and enthusiastically +1 - Ralph > > 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@xxxxxxxxxxx >> +1-603-828-1401 >> >> >> >