Re: Request for community guidance on issue concerning afuture mee ting of the IETF
Hi, I think Steve has captured the core of the issue in this mail. I think his reasoning is the exact reason why we should go to Beijing with a positive attitude and have a great meetin in Beijing! Cheers, Jonne. --- original message --- From: ext Steve Crocker st...@shinkuro.com Subject: Re: Request for community guidance on issue concerning afuture meeting of the IETF Date: 19th September 2009 Time: 10:56:24 pm The choice is between engaging and not engaging. Engaging is better. Not engaging isn't constructive. The Internet and the IETF are all about engaging, expanding, communicating and being open. Much of this dialog has been worried about possible extreme situations. Let's focus on the center. More than a billion people live in China and their use of the Internet is expanding rapidly. They are building much of the technology and contributing technically. It's to everyone's advantage to have comfortable, constructive interaction. Our first slogan was Networks Bring People Together. If you prefer to focus on the negatives, here's my analysis: If we don't go to China, we have charted a downhill course and the rest of the world will come together without us. The IETF will lose relevance. If we do go to China and something bad happens, the consequences will be much worse for China than for the IETF. The work of the IETF will suffer a bit, but we'll recover quickly enough. However, China's quest for engagement with the rest of the world will be hurt more seriously. Bottom line: We should go to China with a positive attitude. We're robust enough to deal with any consequences. If we don't go to China, however, we have weakened ourselves. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request for community guidance on issue concerning a future me etingof the IETF
Everybody, How I read the condition text it is basically saying if the IETF breaks the Chinese law the meeting is over. Having it twice (once in the law and second time in the contract) seems to be just to remind the the meeting organizer the law exists as the law is for many people quite unusual. Even striking that text from the contract wouldn't IMHO change- anything, because the law basically says the same anyway. Entering a country puts you always under the local law - whether you agree with the laws or not. However, I think when not quite this strict, other countries restrict political activity of visitors. If I remember correctly, the US law restricts the possibility of political activism for visa holders. Regardless of what I think of the Chinese law, and having such text in the contract, I don't think the particular text is an issue for the IETF meeting. Many other organizations (3GPP, Wimax Forum, etc.) have had meetings in China for many years without any issues. Cheers, Jonne. --- original message --- From: ext Marshall Eubanks t...@americafree.tv Subject: Request for community guidance on issue concerning a future meetingof the IETF Date: 18th September 2009 Time: 6:48:36 pm Greetings; We have received numerous suggestions and requests for an IETF meeting in China and the IAOC has been working on a potential China meeting for several years. We are now close to making a decision on a potential upcoming meeting in China. However, the following issue has arisen and we would appreciate your feedback. The Chinese government has imposed a rule on all conferences held since 2008 regarding political speech. A fundamental law in China requires that one not criticize the government. Practically, this has reference to public political statements or protest marches, which are not the IETF's custom. The government, which is a party to the issue, requires that people who attend conferences in China (the IETF being but one example) not engage in political speech during their tour in China. We consider this to be acceptable, on the basis that the IETF intends to abide by the laws of whatever nations it visits and we don't believe that this impacts our ability to do technical work. The rule is implemented in the Hotel agreement and reads (note that the Client would be the Host, and the Group would be the IETF) : Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain any defamation against the Government of the People's Republic of China, or show any disrespect to the Chinese culture, or violates any laws of the People's Republic of China or feature any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. The Client will support and assist the Hotel with the necessary actions to handle such situations. Should there be any financial loss incurred to the Hotel or damage caused to the Hotel's reputation as a result of any or all of the above acts, the Hotel will claim compensation from the Client. What does this condition mean ? The hotel staff would have, in theory, the legal right to shut down the meeting and ask the offending participants to leave the property immediately. While we do not foresee a situation where such action would take place, we feel that it is proper to disclose these conditions to the community. The members of the IAOC, speaking as individuals, do not like this condition as a matter of principle. The IAOC does believe that this condition would not prevent the IETF from conducting its business. We note that the Vancouver/Quebec survey conducted earlier this year asked for people to suggest venues in Asia; an overwhelming majority (94%) of those who mentioned China were in favor of having a meeting there. We are therefore asking for input from the community by two means - by commenting on the IETF discussion list, and also by completing a very short survey on people's intentions to travel to China, or not, subject to these conditions. This survey can be found here : https://www.surveymonkey.com/s.aspx?sm=h4DUkRUOdG_2bVLqioPcYYHw_3d_3d All responses received by October 1, 2009 at 9:00 AM EDT (1300 UTC) will be considered by the IAOC in making its decision. We appreciate the assistance of the community in providing us with data that will help us to make an informed decision. Regards Marshall Eubanks (acting for the IAOC) ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: IETF74 T-Shirt Art Donated to IETF Trust
Hi, Though, I think IETF has been always in the lavanguardia of fashion, I think Henk is absolutely right. Let people have their t-shirt if they want to. As long as there is no risk for the IETF. Who would that hurt? The money goes for a good cause - making the Internet work. Cheers, Jonne. -Original Message- From: ext Henk Uijterwaal Sent: 02/08/2009 12:53:02 Cc: ietf@ietf.org Subject: Re: IETF74 T-Shirt Art Donated to IETF Trust Marshall Eubanks wrote: If the IETF sold 100 shirts we would IMO be doing well. If we sold 1000, we would be doing spectacularly well IMHO. That would net $ 5000. That's less than ten registrations at a meeting. I am neutral about whether or not we do this, but please don't imagine that it will supplant registration fees or otherwise lead to sudden riches. I'd be suprised if we sold more than a 100 shirts. I see this primarily as a service to attendees, not as a way to generate money. You get a shirt for free, if you want a 2nd one for whatever reason, you can buy it. The IETF gets a few $$ for the trouble. Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NomCom IAOC position (Was:Re: On being public (Was: Call for Nominees))
Hello everybody, Sorry to be a little late on this. However, I think openness and transparency is good, and should be encouraged. Therefore I would like to tell that I'm NOT going to rerun for the currently open IAOC position, and I hope people would propose good candidates for the IAOC position if they already haven't done it. Cheers, Jonne. On 9/13/08 6:25 AM, ext Pete Resnick [EMAIL PROTECTED] wrote: On 9/12/08 at 9:46 AM -0700, NomCom Chair wrote: If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. I'd like to take this opportunity to encourage people to do something more open and transparent than we have in the past, without any changes to rules or NomCom activity. As we all know, the NomCom process is confidential. That is, whatever one says to the NomCom with regard to nominees cannot be revealed by the NomCom. That's a good idea: People need to be frank and honest without worrying about jeopardizing personal relationships. However, the confidentiality requirement has always also been read to mean that the list of nominees must also be kept confidential. That's not entirely clear in RFC 3777, but that's always been the practice. (I believe the intent was to dissuade any kind of campaigning, to avoid discomfort about running against an incumbent or popular nominee, as well as avoiding embarrassment for nominees who are not chosen.) But this has a terrible side effect: The NomCom is unable to get full feedback on nominees, both in the positive and the negative. If you are unaware that Joe is up for the Foobar Area Director, you may not have the opportunity to say to the NomCom, Wow! It never even occurred to me to think of Joe as a potential Foobar AD. He'd be perfect! Or conversely, It never occurred to me that anyone (including Joe himself) would seriously consider him for Foobar AD. He'd be a disaster! There are just so many resources the NomCom has at its disposal to get good information about nominees. We want folks who could provide feedback to take the initiative, but they're really only going to do so if they know who has their hat in the ring. Though I think campaigning should be avoided, I think the other issues surrounding revealing the names of nominees are not all that problematic: - We should all get over the notion that any particular nominee must obviously be chosen. It may turn out (perhaps on the *day* that the NomCom is making their decision) that our favorite cannot serve because they lose all funding in their current position, or change jobs and no longer have the ability to serve, or die unexpectedly. (And these things have happened.) We should be able to comment on all of the candidates on the off chance that they are the NomCom's apparent best choice. - The fact that the NomCom must keep the reasons for *not* choosing any particular candidate confidential mitigates the embarrassment of not being chosen. Obviously we can't change 3777 for this NomCom. However, there is nothing in 3777 or elsewhere that *requires* any nominee to keep their own nomination confidential. So, I'd like to encourage nominees to be public. Here's what I have in mind: If you've been nominated, post a simple message to the IETF list of the following form: My name was submitted to the NomCom for the position of Foobar AD, and I've told the NomCom I'm willing to be considered. Of course, this is no guarantee that if I get selected, I'd still be able to serve. Please send them whatever positive or negative feedback you have. End of message. No commentary on why you'd be wonderful (or terrible) for the job. Just inviting people to comment. Thoughts on this? pr -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
Hi, I agree with Russ. I think the trust and the IAOC have a bit different focus and it makes sense at times have a different chair for the different positions. This does not mean that we couldn't go in the future back to the common IAOC/Trust chair, but currently the work split would make sense. Cheers, Jonne. On 4/7/08 10:45 PM, ext Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-netlmm-proxymip6
Ted, Thanks for your kind words and sorry for taking my time to answer. Please, find below some thoughts, comments, and questions to your mail. On 2/15/08 3:55 AM, ext Ted Hardie [EMAIL PROTECTED] wrote: Hi Jonne, Thanks for your reply; some comments inline. At 1:17 PM -0800 2/14/08, Soininen Jonne (NSN FI/Espoo) wrote: Hi Ted, I agree with you on the notion that we shouldn't publish anything that we know already that will need fixes or does not work properly for the intended use at this point. However, I think it is completely proper to revise specifications based on operational experience - ever rather quickly after publishing as a PS. Though, seldom done I have understood it is has been even the original idea of the three step standardization process. I agree that we should be able to revise specifications very quickly. RFC 2026 is pretty clear, though, that we shouldn't publish things that we believe are missing important pieces: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. I agree, and I think I wrote that as well in my mail. We shouldn't publish PS'es with known technical omissions. Instead we should fix the omissions or problems when we find them. However, I don't think we have such technical omissions in the current draft. I think the draft - due to extensive review and long debates - is in a pretty good shape. The tricky bit here is that the requirements placed on this have shifted since the work was chartered, and it is not clear whether the technical omissions here are meant to be consonant with the original charter, even though they don't meet the technical requirements of the current working scope. I think this is the general problem we seem to have sometimes in the IETF. We charter things for a year's worth of work, but in the end the work takes quite some years more than that. The requirements have shifted and the original scope doesn't fit the solution needed in the end. Hence, flexibility is needed. I think the right thing to do would have been to recharter the work already earlier to fit the right problem. However, it didn't seem worth the effort earlier as the main focus still should be on the technical work. As you should also note in reading my mail, I am encouraging the IESG to waive this requirement in order to get this document out in a timely fashion, but with a forward pointer in place that would allow us to indicate we intend to fill the empty slot in the toolbox and, generally speaking, where someone should eventually look for the tool. I'm happy that you also find the flexibility needed in this case. However, I'm not really sure what you are referring to with your comment about an empty slot in the toolbox. Which slot in your mind seems to be empty? [snip] I'm glad that you also support MN-AR going forward. I also hope that you are too pessimistic on the possibility of making a general mechanism. While the networks you cite are certainly complex and will no doubt have systems engineering documents which describe exactly how to use PMIP in their environments, that's not the work I'm suggesting the IETF should take on. Instead, I'm suggesting that we need and should complete the work of describing a general mechanism specifying how a mobile node talks to a mobile access gateway. That may well not replace the systems engineering work needed by the current customers for PMIP, but it will make the work more generally useful. It may even be in the fullness of time that the mobile-node to MAG signalling will be used in those environments, once it is generally available. I am generally a pessimist. I have heard that a pessimist is never disappointed. However, I think in this particular case I would say that it is not really pessimism. Practically the MN-AR interface is very link layer dependent. Different systems have quite different link layers and might have rather different procedures. So, I don't think a general view is really possible, or perhaps even desirable. I have to say that I don't see much use currently to specify a standard for MN-AR signalling in the IETF. Not at least currently. However, perhaps I'm missing something here. Thank you for your comments, and I guess I forgot to thank you for your review of the document as well! Cheers, Jonne. Thanks again for your thoughtful reply, regards, Ted Hardie I cross-posted this to the netlmm mailing list to make sure everybody knows this discussion is going on. Cheers, Jonne. On 2/14/08 3:01 AM, ext Ted Hardie [EMAIL PROTECTED] wrote: Summary: One issue needs resolution. First, let me start by saying that -09, which was put out
Re: Last Call on draft-ietf-netlmm-proxymip6
Hi Ted, I agree with you on the notion that we shouldn't publish anything that we know already that will need fixes or does not work properly for the intended use at this point. However, I think it is completely proper to revise specifications based on operational experience - ever rather quickly after publishing as a PS. Though, seldom done I have understood it is has been even the original idea of the three step standardization process. However, that is not my main point. And I don't quite agree that this document in its current format is in a shape where we would have to revise it right after publishing. I would like to comment a bit on your proposal to make the MN-AR draft a normative reference, and moving MN-AR to standards-track. First of all, I'm happy to say that the MN-AR draft has been revived and can be found at http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt Secondly, taking into account the multiple customers for the pmip6 and the multitude of environments where PMIP is either going to be used or potentially going to be used (3GPP, 3GPP2, Wimax to my understanding) I don't think it is possible to write a MN-AR draft that would cover adequately those networks and be really useful for them. I think the purpose of the MN-AN is not to show how PMIP6 should be deployed, but how it could be deployed. I however do agree that MN-AR draft should go forward in the working group and it should not be forgotten. I cross-posted this to the netlmm mailing list to make sure everybody knows this discussion is going on. Cheers, Jonne. On 2/14/08 3:01 AM, ext Ted Hardie [EMAIL PROTECTED] wrote: Summary: One issue needs resolution. First, let me start by saying that -09, which was put out for Last Call, was a substantial improvement over the -08. I normally read Last Call documents using a diff tool, and the number of really solid additions in this update was quite high. I was a bit surprised, given the extent of the new text, that there was no WG last call, but I assume that the WG is reviewing the changes in parallel. I assume that the issuance of -10, which came out during the last call, was a response to one or more reviews from the WG or solicited experts. To call out one particular improvement, I found the update's language around multi-homing much clearer, and I believe the risk of assignment of the same address to multiple interfaces is much reduced in this version. Given the potential consequences (watching your stack scream I'm melting! I'm melting! as someone entertainingly put it), that's a really good thing. There are still some opportunities for editorial update, and I hope that as the IESG enters its discussions that some of those are targets for resolution. I'd particularly like to see even more clear light on the description in bullet 4 of Section 6.9.1.1, as predictably knows is not as clean as it might be. (The current sentence is: The Handoff Indicator field MUST be set to value 1 (Attachment over a new interface), if the mobile access gateway predictably knows that the mobile node's current attachment to the network over this interface is not as a result of an handoff of an existing mobility session (over the same interface or through a different interface), but as a result of an attachment over a new interface. ). But that is really a language clarity problem, at least I hope, at this point. The big issue that remains is actually one that starts from the scope creep. I was on the IESG during the period when this charter was approved, and it was clear at the time that some of the limitations being put in were intended to focus NETLMM on cases where nodes were re-associating at layer 2 with the same network. The charter says, for example: The protocol will not attempt to hide handover between two separate interfaces on the mobile node.. This document (and, as I understand it, the working group discussion for some time) has gone beyond that initial scope. A good portion of this document's complexity is because it does handle the multi-interface case. While it would have been nice to have the charter updated to state the new scope, I don't personally have a problem with the scope. I am concerned, however, that the design constraints changed with that new scope and that other parts of the charter are limiting folks' understandings of what can be done here, when those restraints are really salient for the single layer 2 initial scope. To put it simply, given the inter-technology handoff, signalling from the mobile node to the network is one of the clearest and most likely to be interoperable ways to achieve the correct behavior in some of the base cases. At the moment, because the mechanisms for setting the handoff indicator do not necessarily involve the mobile node (and are appear to be below IP where between the mobile node and the networ), a mobile node
Re: Requirements for Open IESG Positions
Hi, I agree with Vidya. To be honest, I really thought this was an oversight and not intentional. If the Security area has a similar split as the OM area, I think this really should be discussed. To my understanding, we don't have such split documented to any other area and I think this kind of hard split should be discussed. Perhaps the split is right and I just wasn't aware of it. However, it seems other people were unaware of the split as well. BTW, are the explicit technologies Kerberos, GSS-API, and SASL representing the other half of the area. I'm asking, because I'm not a security expert and not active in the security area. Cheers, Jonne. On 7/25/07 1:12 AM, ext Narayanan, Vidya [EMAIL PROTECTED] wrote: I thought the requirements were too specific for the SEC area last year as well :) I do realize that the text has been largely reused from last year, but, I think we need to revisit some of these specific descriptions. We cannot expect the Nomcom to be familiar enough with all areas to use their judgment in addition to the requirements received. I think we need to get better at providing the requirements so that the Nomcom will really know what they are looking for in candidates. At the moment, I really think the SEC area requirements are misleading to the Nomcom and can use a revision. Vidya -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 2:01 PM To: Narayanan, Vidya Cc: ietf@ietf.org Subject: RE: Requirements for Open IESG Positions One important thing needs to be considered in the Security and OM Areas. There are two ADs, and they are expected to have somewhat different skill sets. For contrast, here are the requirements that were provided to NomCom2006 for these positions. Russ --- Operations Management Area: The primary technical areas covered by the Operations Management area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, Routing operations. Unlike most IETF areas, the Operations Management area is logically divided into two separate functions: Network Management and Operations. David Kessens is currently responsible for the Operations portion of the OPS area, so specific expertise required for the open position would include a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary. The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence. Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies. The Operations portion of the OPS area intersects most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful. --- Security Area: The WGs within the Security Area are primarily focused on security protocols. They provide one or more of the security services: integrity, authentication, non-repudiation, confidentiality, and access control. Since many of the security mechanisms needed to provide these security services are cryptographic, key management is also vital. Security ADs are expected to ensure that all IETF specifications are reviewed for adequate security coverage. They also manage a set of security resources that are available to most IETF areas and WGs. Specific expertise required for a Security AD would include a strong knowledge of IETF security protocols, particularly IPsec, IKE, and TLS, and a good working knowledge of security protocols and mechanisms that have been developed inside and outside the IETF, most notably including PKI. Also, a Security AD should understand how to weigh the security requirements of a protocol against operational and implementation requirements. We must be pragmatic; otherwise people will not implement and deploy the secure protocols that the IETF standardizes. The Security Area intersects with all other IETF areas, and its ADs are expected to read and understand the security implications of documents in all areas. So, broad knowledge of IETF technologies and the ability to assimilate new information
Re: Requirements for Open IESG Positions
Hi, I just happened to read this mail today. I don't remember seeing such a mail during previous nomcom rounds (they might have come, but I just didn't notice them). I think this is a very good overview of the requirements needed for the IESG positions and gives a nice background to think about the people who would fit the positions. However, I think one of the areas is described a bit too much in detail and perhaps give a wrong impression about the job. The following extract is from the Security Area: Specific expertise required for a Security AD includes strong knowledge of IETF security protocols. To complement Tim Polk, the person selected as Security AD should have a working understanding of Kerberos, GSS-API, SASL, and how these relate to security protocols and to their use in applications and other security protocols. A basic understanding of IPsec, IKE, TLS, PKI would also be useful. I'm sure this is an oversight, but I think it is generally not according the IETF process to specific technologies and hard coding the division of work in an area. To my understanding, the Ads in an area are free to divide the work between themselves as they wish according their strengths. So, if the a possible new security AD would not be interested to look at these technologies, perhaps Tim would look at them - according the new division of work in the area. In addition, I think it is a bit shaky to mention the current AD in this context even when the person is not up. Theoretically (I don't know if this has ever happened outside the creation of the RAI area), that AD could be moved to the IAB or another position in the IESG. So, it is not 100% sure that Tim would be continuing as the other security AD though probable. However, thanks for this clarification I think it is very useful. Cheers, Jonne. On 7/20/07 9:12 AM, ext Lakshminath Dondeti [EMAIL PROTECTED] wrote: RFC 3777 says the following about the qualifications required for open IESG/IAB positions: The IESG and IAB are responsible for providing summary of the expertise desired of the candidates selected for their respective open positions to the Executive Director. The summaries are provided to the nominating committee for its consideration. 2. The nominating committee selects candidates based on its understanding of the IETF community's consensus of the qualifications required and advises each confirming body of its respective candidates. The following is the information provided by the IESG to the nomcom. The nomcom is now accepting the community's input on the qualifications required for the open IESG positions. Please send your notes, either as commentary on the following or independent notes to [EMAIL PROTECTED] Thank you. best regards, Lakshminath This note describes the expertise desired in the candidates selected to fill the positions of the IESG members whose terms will expire during the first IETF Meeting in 2008. Under the Nominations Committee (NomCom) procedures defined in RFC 3777, the IESG is responsible for providing a summary of the expertise desired of the candidates selected for open IESG positions. This information is included below, and is suitable for publication to the community, along with the NomCom request for nominations. We realize that this is a long list of demanding qualifications, and that no one person will be able meet all of the requirements for a specific position. We trust that the NomCom will weigh all of these qualifications and choose IESG members who represent the best possible balance of these qualifications. GENERIC REQUIREMENTS IESG members are the managers of the IETF standards process. They they must understand the way the IETF works, be good at working with other people, be able to inspire and encourage other people to work together as volunteers, and have sound technical judgment about IETF technology and its relationship to technology developed elsewhere. Area Directors (ADs) select and directly manage the Working Group (WG) chairs, so IESG members should possess sufficient interpersonal and management skills to manage 15 to 30 part-time people. Most ADs are also responsible for one or more directorate or review teams. The ability to identify good leaders and technical experts, and then recruit them for IETF work is important. Having been a WG chair helps understand the WG chair role, and it will help when trying to resolve problems and issues that a WG chair may have. In addition, all IESG members should have strong technical expertise that crosses two or three IETF areas. Ideally, an IESG member would have made significant technical contributions in more than one IETF area, preferably authoring documents and/or chairing WGs in more than one area. (ADs are expected to personally review every Internet-Draft that they
Re: Requirements for Open IESG Positions
Hi Brian, On 7/24/07 2:29 AM, ext Brian E Carpenter [EMAIL PROTECTED] wrote: Jonne, On 2007-07-24 01:10, Soininen Jonne (NSN FI/Espoo) wrote: Hi, I just happened to read this mail today. I don't remember seeing such a mail during previous nomcom rounds (they might have come, but I just didn't notice them). You didn't notice them :-) Also these descriptions have evolved from year to year (there is a version in the IESG wiki too, at http://www3.tools.ietf.org/group/iesg/trac/wiki/AreasDescription, maybe the IESG should bring it up to date...) You mean there is e-mail in my inbox I haven't read? ;) I think this is a very good overview of the requirements needed for the IESG positions and gives a nice background to think about the people who would fit the positions. However, I think one of the areas is described a bit too much in detail and perhaps give a wrong impression about the job. The following extract is from the Security Area: Specific expertise required for a Security AD includes strong knowledge of IETF security protocols. To complement Tim Polk, the person selected as Security AD should have a working understanding of Kerberos, GSS-API, SASL, and how these relate to security protocols and to their use in applications and other security protocols. A basic understanding of IPsec, IKE, TLS, PKI would also be useful. I'm sure this is an oversight, but I think it is generally not according the IETF process to specific technologies and hard coding the division of work in an area. To my understanding, the Ads in an area are free to divide the work between themselves as they wish according their strengths. So, if the a possible new security AD would not be interested to look at these technologies, perhaps Tim would look at them - according the new division of work in the area. If you look at the description for the OM area you will also surely find it very specific to half the area. I think it's realistic to do this. I don't object to it. I think the OM area(s) is a bit different. Here there are three specific technologies mentioned whereas in OM area there are two quite different areas. There is perhaps not a such a clear division of task (like there isn't in other areas either). However, like I said this is most probably just an oversight. In addition, I think it is a bit shaky to mention the current AD in this context even when the person is not up. My personal taste would also be not to mention the co-AD by name. Theoretically (I don't know if this has ever happened outside the creation of the RAI area), that AD could be moved to the IAB or another position in the IESG. So, it is not 100% sure that Tim would be continuing as the other security AD though probable. True, but that would then invoke the mid-term replacement process for the person being moved - and it *has* happened. Cheers, Jonne. Brian -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
