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