Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
Stewart, On Thu, Mar 28, 2013 at 01:13:44PM +, Stewart Bryant wrote: In this particular case the candidate pool would have been tiny, because the criteria would surely have included being experienced with both the ITU process and the IETF liaison process, including knowing and understanding the liaison history. Therefore it seems unlikely that there would be any candidate that the IAB did not already know about. So whilst I agree in general, this is not a case that should raise any concerns. This is exactly the reaction that makes me worried: if the pool of candidates is already considered to be thin to begin with, it makes even more sense to do a call for volunteers to make 100% sure that nobody gets overlooked. It's not a healthy culture to only allow positions to be filled from the inside crowd. It's time to fix that. David Kessens ---
Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
Mike, On Thu, Mar 28, 2013 at 09:03:25PM -0400, Michael StJohns wrote: The process for selecting and appointing liaisons is the purview of the IAB and not currently subject to external review - and I don't find any problem with that. I fully agree with this. All I am asking for is a call for volunteers. I am not even asking for publication of the resulting list of volunteers to allow for public comments. The IAB, the IESG or whatever body in the IETF that needs to fill a position cannot possibly know all possible candidates for a position. The IETF is not a small community any longer where everybody knows each other. It is very easy to overlook good potential candidates. An open call helps the bodies that make the decisions to find as many candidates as possible. How can potential candidates even know that somebody is looking for a candidate if the potential candidate is not part of the incrowd him/herself ? And yes, I speak from experience: I have been an Area Director and I did open calls for volunteers whenever a position needed to filled. It involves some extra work but I did find that there were many more capable people that could fullfill the roles than I would have thought before I initiated such a call (the pool of candidates often turned out to much heathier than my initial guess of a thin pool). David Kessens ---
Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
Russ, Jari, IAB, Recently, there has been a lot of discussion in the IETF about diversity. A lot of people observed that the IETF is not good in fostering a culture that naturally promotes diversity and that is attractive for younger people to join. One way to make the IETF more accessible and approachable is to stop making appointments for open positions by recruiting only behind closed doors. I am very disappointed that the IAB again has chosen to fill a position without a clear and open call for volunteers. We can talk a long time about diversity in this community, but it is time to take concrete actions. David Kessens PS This message doesn't in any way intends to doubt Scott's skills. I am disappointed about the process used. --- On Wed, Mar 27, 2013 at 03:13:33PM -0400, IAB Chair wrote: The IAB has just notified the ITU-T that Scott mansfield will be the new IETF Liaison Manager to the ITU-T. Please congratulate Scott when you see him. He has done a good job as liaison manager for MPLS, and I am sure he will do a good job in his new role. Please thank Eliot Lear for his past service in this role. Eliot no has a seat on the IAB, and I am sure he will provide valuable support for Scott. Thanks, Russ = = = = = = = = = = Liaison Statement: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T Submission Date: 27 March 2013 From: The IAB (Russ Housley) To: ITU-T TSAG (tsbt...@itu.int) Cc: IAB i...@iab.org, The IAB Executive Director ex...@iab.org, tsbd...@itu.int tsb...@itu.int, IESG i...@ietf.org Title: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T The IAB would like to bring to the ITU-T's attention the appointment of Mr. Scott Mansfield as the new IETF Liaison Manager to the ITU-T. The IETF Liaison Manager to the ITU-T sees to the day to day aspects of the relationship with the ITU-T, provides guidance to the IESG, IAB, and the IETF as a whole on strategic matters involving both organizations. In addition, Mr. Mansfield will work closely with our other liaison managers to assure consistency of approach across technologies, as well as see that liaisons from the ITU-T to the IETF are appropriately allocated and responded to. We expect Mr. Mansfield to play a significant supporting role in strategic discussions between the IETF and ITU leadership. Mr. Scott Mansfield has over twenty of experience in software development and network management. He is a Principal Engineer in Ericsson’s DUIB Technology Network Architecture group. A long time technologist, Scott has built object-oriented workflow systems for the US Treasury Department, The United States Naval Reserve, Federal Express, and the United Parcel Service. Scott has also been the Lead Architect for Ericsson’s North American Mobile Backhaul Solutions, before moving into a position of Standards Engineer. Scott has been Ericsson’s MEF Coordinator for the past 5 years and is also an active contributor to the IETF and the ITU-T, and has been liaison manager from the IETF to ITU-T for MPLS for the past two years. The IAB thanks the outgoing Liaison Manager, Mr. Eliot Lear, for his valuable service. For the IAB, Russ Housley IAB Chair David Kessens ---
Re: Appointment of a Transport Area Director
Sam, Can we please stop the hairsplitting ? It is not the IESG's fault if you feel that the nomcom is taking the IESG input as absolute software style 'requirements' as opposed to often more lightly interpreted 'job requirements' as desirable from the IESG's perspective. Please take that message to the nomcom if you wish. The grander picture here is that there will be a session where the community can discuss the topic of what to do with the TSV area director position. You are part of that community and I have no doubt that you will be given a chance to speak up. This session is clearly not about the finer details of the nomcom process. David Kessens --- On Thu, Mar 07, 2013 at 10:41:55AM -0500, Sam Hartman wrote: Martin == Martin Stiemerling martin.stiemerl...@neclab.eu writes: Martin Hi Margaret, I will answer as the agenda below is out of the Martin TSVAREA session. Martin On 03/07/2013 03:21 PM, Margaret Wasserman wrote: Hi Russ, On Mar 5, 2013, at 11:18 AM, Russ Housley hous...@vigilsec.com wrote: The rest of your question ought to be discussed at the TSVAREA meeting in Orlando. I have looked at the agenda of the TSV Area Open Meeting (on Wednesday from 9:00am to 11:30am), and it includes the following item: - Open Mic about Area Expectations for the TSV ADs -- 60 minutes The questions we will ask the community: - what is the existing description we gave to NomCom. - does the community agree with it? - is it reasonable, or are we asking too much? By description we gave to the NomCom do you mean the IESG's list of desired criteria? Is the NomCom also going to report on the criteria that they came up with, after considering the IESG's input and whatever input they received from the community? Martin The IESG has sent these requirements [1] to the nomcom, as Martin stated on that site. That's what is meant with what is the Martin existing description we gave to NomCom. Hi, after reading your message I still don't understand the answer to Margaret's question. Also, I'd like to remind you that the IESg does not send requirements to the nomcom. According to RFC 3777 the IESG sends a set of desired expertise. The nomcom develops a set of required qualifications based on these and community input. It's not just a semantic point. I think over the years the IESG has started to believe that the IESG rather the community sets the job requirements for ADs. I'd like to ask IESG members especially to be very careful about the terminology and to respect the process. David Kessens ---
Re: Appointment of a Transport Area Director
Sam, On Thu, Mar 07, 2013 at 01:32:59PM -0500, Sam Hartman wrote: I don't think there is hair splitting going on here; I think the issues that are being raised are quite real and important. It's not the IESG's fault if the nomcom does x. It is the IESG's fault if the IESG takes on tasks delegated to the nomcom in RFC 3777. As you are aware, I have taken concerns I believe are best handled by the IAB and nomcom to the IAB and nomcom. The nomcom makes the appointments. There is nothing the IESG can take away from that. It is the nomcom that interprets the requirements from the IESG. There is nothing the IESG can do about that. If you are unhappy how the nomcom does the interpretation, contact the nomcom. David Kessens ---
Re: Appointment of a Transport Area Director
Russ, On Tue, Mar 05, 2013 at 11:18:20AM -0500, Russ Housley wrote: The split between Transport and RAI was needed. Together it is too much work for one Area. Not everybody believed at the time, and still believes that increasing the size of a committee makes the committee function better. David Kessens ---
Re: IAOC Request for community feedback
Doug, On Tue, Oct 23, 2012 at 12:26:58PM -0700, Doug Barton wrote: You're not proposing a change in procedure. You're proposing to ignore one. No procedure is ignored. BCP 101 does not define the rules for declaring a position vacant. In absense of such rules, the IAOC decided to consult with the community whether the community agrees that the position is now vacant. Another avenue, which is also mentioned in the BCP, that could have been followed is the recall procedure. However, the IAOC felt that it was not really intended for a situation where somebody apparently has vacated their position. David Kessens ---
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Dave, On Thu, Sep 13, 2012 at 03:10:51PM -0700, Dave Crocker wrote: I believe we /do/ need a written policy that has been reviewed by legal counsel. I think the lengthy discussion that we have seen on this topic proofs that we should NOT have a written policy. Deal with this on a case-by-case basis seems the most efficient way until we hear that the IESG spends more time arguing on a particular case than the IETF community does on a written policy. David Kessens ---
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Dave, On Thu, Sep 13, 2012 at 03:43:01PM -0700, Dave Crocker wrote: Essentially none of the enlightened discussion on this thread considered legal ramifications of potentially arbitrary censorship by a public group such as ourselves. Aren't you going a little overboard in hyperbole here ? David Kessens ---
Re: IAOC: delegating ex-officio responsibility
Bob, Olaf, On Wed, Sep 21, 2011 at 05:27:11PM +0300, Bob Hinden wrote: To repeat what I said, I didn't see the new draft resolving issues that I and other raised on the list. The new draft is a different approach, but as Leslie pointed out, it might be worse. In the old draft, the I* chairs were allowed to appoint someone to represent them, in the new one they are non-voting advisors. Busy people being busy, will tend to not follow or attend the meetings. Many small decisions can have unintended consequences. I reviewed the new draft and I agree with Leslie and Bob that the new draft seems to be a step in the wrong direction. The critical thing is that we don't loose the participation of the IETF chair, IAB chair and ISOC President/CEO while at the same time finding a way to lighten their workload. From the discussion we had on the previous draft, it seemed to me that a differentation between these positions is actually very important. There was very little support to have the IETF chair delegating the full job of his/her IAOC membership. At the same time, there were much less strong feelings about this for the IAB chair and ISOC CEO/president. I agree with the sentiment that the IETF chair should remain a full voting member of the IAOC. However, I don't object if the IETF chair would have a designated backup for the voting role when he/she cannot attend to IAOC business. I believe it would be useful for the designated backup to be a non voting permanent IAOC member in order to make sure the backup understands what is going on. However, the important thing is that the vote is still a vote that the IETF chair is responsible for. Furthermore, I am not sure whether there is a real need to do a similar setup for the Trust as well. And finally, for full disclosure, I have been present myself at IAOC meetings as a guest from the IAB. This allowed for an IAB perspective to be present when the IAB chair couldn't make it to the IAOC meetings but of course I had no voting power etc. I'll leave it up to the current IAOC members and the IAB chair to comment on that experience. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
Russ, On Mon, Aug 01, 2011 at 11:10:24AM -0400, Russ Housley wrote: I am discussing the possibility with the Secretariat and the IESG. I will report back to the community as soon as possible. I don't think this proposal should be pursued. The breaks fulfil an important function and there is nothing wrong with a starting time of 9am. The friday meetings are always going to be tough at the end of a week long meeting but trying to compress the friday schedule would only make it harder. David Kessens --- On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
Margaret, On Mon, Aug 01, 2011 at 07:02:22PM -0400, Margaret Wasserman wrote: If we don't want to hold meetings on Friday afternoons due to conflicts, I'd much rather see us eliminate one of the plenaries and hold meetings during that time slot. I was already planning to bring this up again in the IAB, but now that you mention it here, I fully agree! David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Jari, On Mon, Aug 09, 2010 at 12:31:02AM +0300, Jari Arkko wrote: I think we should not over-analyze the selection process too much. I support 1-1-1 because its a simple model, it feels right, and because I believe general IETF participation is headed towards the 1-1-1 model even if we are not there by all measures yet. I think all these models that are based on where we are from are really beside the point as where we are from really doesn't necessarily have any connection with where we like to go. My preference is to pick meeting sides that have the right capacity for the IETF meeting and the right infrastructure for a good meeting, are relatively easy to get to and allow for reasonable attendance cost for my employer. It is totally fine by me if that means that we end up more often in Asia if it happens to be easier to get larger venues at a decent price. Quite frankly, whether my air travel is a few hours more or less is really not that important in the grander scheme of things especially if the resulting venue is an excellent and cost effective location with a supportive local organization team. At the same time, I expect that the IAOC is made up of intelligent people and that they wouldn't go completely overboard and have each and every meeting in only one part of the world. Do we really need these kind of rigid rules ? David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal to the IESG concerning the approbation of the IDNA2008 document set.
On Wed, Mar 10, 2010 at 03:42:12PM -0800, Dave CROCKER wrote: The prudent action is to return it to the appellant, stating that it cannot be processed until it has been made clear and concise. I fully support such an approach (and did propose the same strategy to the IESG while I was a member of the IESG myself). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
Melinda, On Thu, Sep 24, 2009 at 03:41:17PM -0800, Melinda Shore wrote: Looking at it from a threat evaluation framework, it seems to me that the actual likelihood of something happening along these lines is pretty small, but the impact of it, if it did happen, would be enormous, and it's the enormity of the consequences that makes this look more risky than meetings in other places where the hotel contract doesn't include clauses about shutting the meeting down if attendees criticize the local government. On the other hand, to put this into perspective, some people might argue that the chance of a huge winterstorm on the sunday before an IETF meeting in cities like Minneapolis/Chicago causing the airport to close for three days, an earthquake striking the bay area/Japan/LA basin right before/during a meeting or something mundane like a hotel roof collapsing due to rainoverload and flooding of a hotel are risks that are perhaps much more worthy to keep the secretariatIAOC members up late at night. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Dave, On Wed, Sep 16, 2009 at 11:36:53AM -0400, IETF Member Dave Aronson wrote: Given IPv6's rate of adoption so far, how soon do you think IPv4 will *really* be in so little use as to be obsolete or historic? With the growth rate of the Internet and home/office networking, and IPv6's adoption rate, I'd be willing to bet that the number of IPv4 installations is *growing* per year, not shrinking, and that that trend will continue for at least the next several years, barring any highly unusual events. ^ Like running out of easily available/cheap IPv4 address space ? David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Trust response to the appeal by John C Klensin (July 18, 2009
John, On Thu, Sep 03, 2009 at 07:33:37PM -0400, John C Klensin wrote: Instead, it was about the behavior of the Trustees and their interactions with the IETF Community. _That_ discussion is better carried out on the IETF list, in plain sight of the community, even that portion who do not feel personally compelled to track the of IPR policies. While you seem to imply that you can determine for the rest of us on the IETF list what is, and what is not a topic of general interest for the IETF community, I would not like to let this statement pass unchallenged. I fully support the idea of moving this discussion to another public mailing list. Thanks, David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC Meeting location selection
John, On Thu, May 28, 2009 at 03:39:17PM -0400, John C Klensin wrote: When you have time, I (and I believe others) would like to understand better how you evaluate reasonable costs for the IETF and attendees. I think it is general knowledge that it is possible to trade IETF costs off against participant costs (e.g., making things cheaper for the IETF and more expensive for participants). It would be good to know how the participant costs are estimated and how the two are balanced. While I appreciate your interest in such details, I believe we should also be realistic in how precise such trade-offs can be made. Eg. the IAOC just doesn't have the staff or budget to create detailed models on the cost/benefit analysis and the IAOC would easily end up in a situation where more money/energy gets spend to try to determine the optimum site location and to fully inform the community on every decision it makes. Basically, what I expect the IAOC to do is to make a judgement call based on the various variables. So far, I don't believe there is any evidence that IAOC has made decisions to hold meetings in places that are completely out of the question. At the same time, by occasionally holding a meeting in a location that is somewhat unusual, we will continue to be able to evaluate whether all our assumptions about the importance of airline hubs or the desirability of a short train trip are really that important for all participants. Basically, instead of endless discussions on the merits of a required short railtrip from 1 of 3 different very large airports that are all listed very high in the european top 10 hub airports, let's go to Maastricht and see how it will work out. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78 Annoucement
Antoin, On Tue, May 26, 2009 at 03:45:20PM +0200, Antoin Verschuren wrote: Paris Charles de Gaulle airport Is a reasonable alternative if your airline doesn't do Amsterdam or Brussels. The train journey to Maastricht will take you approx 3,5 hours, and includes 2 stopovers. First from Paris CDG to Paris Nord by RER, then take the TGV to Brussels, and then to Maastricht: Aeroport Charles de Gaulle 1--Paris Nord Paris Nord-- Bruxelles-Sud/Midi Bruxelles-Sud/Midi--Maastricht There are many TGVs that go directly from CDG to brussels which cuts out one connection and if your plane arrives at the right time, cuts down the trip to 3 hours and 10 minutes which puts it in the same order of magnitude as traveling from Amsterdam and has the advantage of not having to travel at all on the congested dutch railway system (and in fact one could argue whether you ever set foot on dutch soil ;-)) Iljitsch van Beijnum wrote: So suppose you're flying from SFO with Northwest, leaving on friday. Land at 10:30 on saturday. (Results based on doing all of this the same week this year.) I don't think you'll make the 11:00 train, so it would have to be the 11:30 or 12:00 one, which gets you to the Maastricht train station at 14:04 or 14:34 with 6 minutes to change trains in Utrecht. So far so good. Having flown this route many times, it is entirely possible to catch the 11:00am train if you didn't check in, and even if you checked in, more often than not this flight and other transatlantic flights arrive early and you can also make it. Also, if the meeting was held in Amsterdam, you would have still needed to catch a train to Amsterdam. Catching the train to Maastricht from Schiphol airport would not have caused an increase in difficulty level compared to a train to Amsterdam. The only difference would have been the longer travel time. I agree that Maastricht is not an ideal location from a travel time perspective and that locations like Paris are a better choice if venues and sponsors happened to be available. On the other hand it is really not that hard to get to Maastricht and certainly worth the few extra travel hours compared to some of the cold and icy locations that the IETF has visited in the recent past. And when comparing it to Dublin, getting from the airport to the meeting venue might actually not be much of a difference time wise thanks to the horrible traffic situation around Dublin (unless you were one of the lucky few who managed to into one of the black helicopters). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Danny, On Wed, Nov 12, 2008 at 01:15:07PM -0700, Danny McPherson wrote: On Nov 11, 2008, at 11:57 AM, David Kessens wrote: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. No, the methodology is outlined in the referenced report. Given what we were measures and what data was supplied, those were the results. The report as presented at the RIPE meeting indeed mentions the possibility of undercounting. However, it appears that there is an undercount of several orders of magnitude. At that point you really cannot claim that the report provides a perspective on Internet IPv6 traffic as it does. It is quite reasonable to conclude that something went wrong with the methodology, measurements or analysis. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) Indeed, and multiple orders (less than two) of magnitude is still, from this, only .1% on average. I believe the point remains very much the same. The difference between something that is barely measurable and something small but measurable like 0.1% is huge. Basically, 0.1% on the scale of the Internet means that a very large group of people is using IPv6 today. There is no question that that group pales to the total number of Internet users but it sure is more than a few people in IETF experimenting with IPv6. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Danny, On Wed, Nov 12, 2008 at 06:11:11PM -0700, Danny McPherson wrote: I look forward to any credible data that you can provide to support wider adoption, or being made aware of any unacknowledged issues with our methodology. As I mentioned in another mail to the ietf list today: various presentations on this topic from the last RIPE meeting are available on rosie.ripe.net, look for ipv6 working group or plenary David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Joe, On Tue, Nov 11, 2008 at 08:20:11AM -0800, Joe St Sauver wrote: I'm not aware of DNS block lists which cover IPv6 address spaces at this time, probably in part because IPv6 traffic remains de minimis (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ showing IPv6 traffic as constituting only 0.002% of all Internet traffic). For the record: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposals to improve the scribe situation
Dan, On Tue, Aug 05, 2008 at 12:43:10PM +0200, Romascanu, Dan (Dan) wrote: From Joel Jaeggli [ ... ] have one. I suspect that if they have anything with an intel 2100 or with a prism 2 wireless chipset it's probably time to upgrade preferably with a fresh os as well... Many people do not have the liberty of upgrading machines or OSs at ease. But is that a problem for you or for the network team ? There is a point where certain legacy hardware is just not going to cut it anymore and I don't believe that that is the fault of the network team. Basically, whether you like it or not, this is a problem between you and your IT department (and yes, I do understand that that is not necessary an issue that you would like to deal with). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposals to improve the scribe situation
Joel, On Tue, Aug 05, 2008 at 10:53:08AM -0400, Joel M. Halpern wrote: So I do not think that telling people to use 11g is an answer. And 11a has much to limited use for me to pay extra to have it included in my laptop. It is not hard to find 11a capable minipci or pccards that sell for less than what shipping of the card costs. I cannot speak for you, but these are prices I stop using words like investment but instead you could consider just buying one as an experiment and see how far it gets you. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB Open Microphone session on Thursday?
Olaf, On Wed, Jul 30, 2008 at 11:52:36AM -0700, IAB Chair wrote: We would like to create such opportunity on Thursday but only if interest is demonstrated. If you have a question for the IAB, please sent it to [EMAIL PROTECTED], by 2pm Thursday 31st. I am afraid that this procedure itself is a reason for questions. I don't see why sending a question to the IAB in advance is necessary to determine whether there is interest in the community to have a discussion with the IAB. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB Open Microphone session on Thursday?
Olaf, On Thu, Jul 31, 2008 at 03:09:10PM +0100, Olaf Kolkman wrote: Personally, I think there is benefit to questions being mailed in advance. It serves two purposes: It helps with phrasing the question concisely and it helps the IAB members to provide a response that has been given more than a few seconds thought. Thanks. I don't have a problem with encouraging people to send their questions in advance. The original message just sounded a bit heavyhanded due to the requirement to send the actual question before an arbritrary deadline. I have no further questions ;-). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Lakshminath, On Fri, Jun 13, 2008 at 11:01:17PM -0700, Lakshminath Dondeti wrote: I have also been disappointed by the IESG not once invoking the override procedures even when a DISCUSS is clearly inappropriate. For the record, during my time in the IESG, we have had at least two cases where override procedures were requested. One vote was requested by me to clear a document that I was the shepherd for that got stuck in the IESG for a very long period and where the DISCUSSing AD was not responsive while trying to resolve a DISCUSS. In another case, I asked the shepherding AD to request an override vote as I had fundamental issues with a document that was not likely to be resolved in a timely matter due to the nature of my problems with the document. Therefore, instead of me holding a DISCUSS forever and leaving the document in limbo, I proposed that an override vote could help us to force a decision early. If my memory serves me correctly, we didn't have to do a formal override vote in both cases as the request of an override vote was enough to get the first case moving, while in the second case I decided that an informal strawpoll was enough to decide that I didn't have enough support for my opinion so I switched to an ABSTAIN. David Kessens --- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Jonathan, On Fri, Feb 15, 2008 at 05:49:35PM -0500, Jonathan Rosenberg wrote: A big mistake was made in IPv4, where NAT was declared 'evil' and we didn't spend enough time defining it well. Now, it is wildly successful and a part of what the Internet is, and it is harder to deal with it. Had we done standards work up front and early, and defining exactly how NAT work, things would work much better. We should have had RFC4787 in 1997 and NOT 2007. NATs are *not* on the wire protocols but middleboxes that break havoc with peer-to-peer applications but that help to get people that don't have enough IP addresses to use or have reasons why they cannot do a network renumbering. For interoperability, there is no necessity for all NATs to work in exactly the same way, hence the incentive for anybody to follow a standard would be rather low. If we had defined NAT in 1997, it would have been obsoleted before it had even reached the RFC editor as competition in the marketplace would have forced vendors/open source community to leap frog each other with small and big improvements over the IETF standard. The only useful role for IETF would have been and still is to provide some beHAVIORal advice on what we have observed as a common lowest denominator between the different implentations. There is nothing special about NATs, we know what problems they cause, we know what problems they solve. We even have relatively simple protocols that can traverse them. Observations that it is hard to deploy new transport protocols are not exactly very new either and it is quite obvious that NATs are part of the story why deploying anything new on the Internet has become much harder. Can we perhaps move on to a topic that involves new insights or ideas ? David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Dave, On Wed, Feb 06, 2008 at 11:54:43AM -0800, Dave Crocker wrote: Hence the question about priorities. Start with declaring Dublin the venue and it well might be true that this is the best venue. Start with a requirement that the venue have ample resources within walking distance and Dublin well might be disqualitied. It's all about priorities. And no, I would not have queried if I hadn't felt that attendee convenience were not the priority that should be highest, but that it appears not to have been for the Dublin event. Maybe you should volunteer for a position on the IAOC if you believe you can set these priorities better than the people who are currently responsible for this job. Quite frankly, I am not looking forward for a resort hotel setting in the proximity of Dublin as opposed to for example a meeting in Paris. However, that is just based on personal preferences that don't really disqualify this location as a good location for a productive meeting (we don't even know whether there are not a decent number of restaurants etc. nearby the venue). On the other hand, considering the origin of Alcatel-Lucent, I have my suspicions that Paris actually has been considered and didn't work out for other reasons. I am sure Ray can give us a bit more background why we ended up in this venue (and why my corporate rate was quite a bit more attractive than the IETF rate ... ) David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Richard, On Wed, Feb 06, 2008 at 04:48:15PM -0500, Richard Shockey wrote: Sites that are substantially distant from city centers or major transportation hubs IMHO don't work for the IETF community irrespective of whether they are in North America, Asia or ECMA. While I don't particularly like this location, I don't see how you can imply that it is hard to get to Dublin airport and from there to the meeting site. Aer Lingus has reasonably priced (for summer time) direct flights from most large US cities. Most european cities are served by Aer Lingus and by Ryan Air which is quite possible the cheapest airline on earth. David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Richard, On Wed, Feb 06, 2008 at 10:41:07PM -0500, Richard Shockey wrote: My comment said or as in one or the other, if you had re read the comment properly before going snarky. I don't dispute Dublin airport is a useful transportation hub. I want to know why this particular venue was selected and what was the criterion used to make the evaluation. That is a simple question given the legitimate questions many of us are asking. By mentioning 'major hub' it appeared as if you were concerned about that as well while in fact this location is an excellant choice from that perspective: not only is it easy to get to, but it is also comparatively cheap for many IETF participants. IMHO it was a bad selection and I think many of us want to make sure it does NOT happen again. that really remains to be seen: as many people have mentioned before, there might actually be some reasonible local food options. In addition, with a little planning, it should be possible for many of us to go once or twice to Dublin itself or perhaps stay a day extra. I admit, not 100% ideal but meetings always have their tradeoffs. In this case, I certainly see the potential for problems, but on the other hand, if the connectivity is particularly good, the hotel rooms a bit better than average and the local restaurant situation a tiny bit better than what many people expect, one can hardly claim that this meeting is going to be a disaster. Let's first go there before we make a judgement that this was a terrible mistake, the data so far simply doesn't justify that (yet ;-)). David Kessens PS anyways, maybe the local/Dublin restaurant scene is really not what we should be looking for in Ireland: should we not care more about the local brews ? --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Fred, On Wed, Dec 19, 2007 at 04:16:22PM -0800, Fred Baker wrote: On Dec 18, 2007, at 12:39 PM, Hallam-Baker, Phillip wrote: In the same way that there is a difference between a bricklayer and an architect there is a difference between an engineer and a network admin. On Dec 19, 2007, at 8:07 AM, David Kessens wrote: This issue will only develop into an outage if you bring the wrong survival tools: I suggest you leave your hammer home and make sure that you can use ipv6 only. There is no rocket science here. People have done this before. David, I think you missed Phillip's point. The average engineer at the IETF meeting isn't in control of significant aspects of his IT infrastructure, such as whether his IT department has enabled IPv6 access to his mail server. Sure, I have IPv6 running on my Mac (it defaults on and I dont turn it off) and someone with IPv6 in their network can presumably get web pages from www.ipv6.cisco.com. That's not the same as being productive. No, I don't think I missed Phillip's point at all. Some engineers are apparently more creative than others in their ability to reach the mothership over an ipv6 only network despite the fact that the mothership doesn't have ipv6 vpn support (yet). This certainly hasn't stopped me from connecting back to the company that I work for and it should not stop any competent engineer. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, Dec 19, 2007 at 07:30:31AM -0800, ext Eric Rescorla wrote: At Tue, 18 Dec 2007 12:39:32 -0800, David Kessens wrote: Basically, anybody who cannot survive without 60 minutes of network connectivity during an IETF and who has not taken measures to provide for backup connectivity during *any* outage cannot be taken serious. Of course one can survive 60 minutes of network outage. I could also survive a broken finger, but I'm still carefeful when I use a hammer. Just because people could survive an outage is no reason to inflict one on ourselves. This issue will only develop into an outage if you bring the wrong survival tools: I suggest you leave your hammer home and make sure that you can use ipv6 only. There is no rocket science here. People have done this before. David Kessens PS If there is a need for hammers in order to break fingers or to make ipv6 working, I suspect one can easily borrow one from the construction crews --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, Dec 19, 2007 at 08:17:17AM -0800, Eric Rescorla wrote: Absolutely they have, but I don't see why we should be put into a situation where I need to have survival tools. Again, what is the value of this experiment? Since I seem to be into analogies this morning, let me try another one. When we were in YVR, there were water turbidity issues and people were told not to drink the water out of the tap. The hotel supplied bottled water. If we were to hear tomorrow that due to the renovations the hotel water was to be unpotable, would your answer be that they should fix that or that each IETFer should bring a survival tool in the form of a water filter? If water problems occur regularly, it seems prudent to bring a waterfilter. If you are traveling and experience frequent problems with connectivity and you believe that 60 minutes without it could lead to fatalities it might be wise to bring backup gear. However, this is really beside the point: there is not going to be any break in connectivity, there will be plenty of ipv6 available. And on another topic, I would hope that (members of) the IAB will spend the same amount of time and energy as used on this discussion on more important topics like to get ICANN to have ipv6 and DNSSEC root service available before the next IETF meeting. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Tue, Dec 18, 2007 at 01:04:52PM -0600, Pete Resnick wrote: Proposal that the IETF use IPv6 exclusively for 60 minutes causes widespread panic I would also like to observe that the people who seem to be suffering from said wide spread panic have managed to produce enough mail to waste at least another 60 minutes of work time of everybody subscribed to this mailing list. Quite frankly, I could care less about this whole experiment: I have no problems tunneling all my traffic back home over ipv6. I don't even rely on relatively modern innovations like the DNS. I also have a backup plan in the form of several mobile phone devices and hotspot subscriptions that are able to attach me to the legacy network as well. Basically, anybody who cannot survive without 60 minutes of network connectivity during an IETF and who has not taken measures to provide for backup connectivity during *any* outage cannot be taken serious. We have had plenty of outages in the past that have lasted longer than 60 minutes that sometimes involved the whole network being down but at other times involved infrastructure outages that caused ipv4 to be down and ipv6 being up or the other way around. I would like to suggest that people who really cannot do without 60 minutes of connectivity spend some time in actually investigating what kind of alternate methods of connectivity are available in case of a network outage as that might come in handy during other unscheduled network events as well. The network might have been working well last time, but that doesn't mean that past performance gives any guaratees for the future. One of the cheapest preparations and one that would have saved you already way more than 60 minutes of extra connectivity time is to make sure you can use ipv6 as backup for ipv4 and vice versa. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NAT+PT for IPv6 Transition Operator Feedback generally
Iljitsch, On Thu, Nov 15, 2007 at 10:37:03AM +0100, Iljitsch van Beijnum wrote: On 15 nov 2007, at 8:27, David Kessens wrote: PS as my personal opinion on NAT-PT, as long as we define it as middlebox as opposed to a protocol that has strong interoperation needs, I am not convinced that it actually even needs to be standardized by IETF as it is perfectly possible to implement NAT-PT without a stable IETF specification and to make it work across the Internet. We did that with NAT, and I think we lived to regret it. I am not part of that 'we'. I don't believe we would have been able to produce a standard that was not already overtaken by innovation in the marketplace before we got it out. On the other hand, now that NAT has evolved into a more stable product, it seems useful to find commonalities like BEHAVE has been doing. In fact, I was thinking about adding text to my modified NAT-PT draft to mandate some specific NAT behavior rather than letting the vendors figure it out in order to make it easier for applications to work around the problems that the NAT part in NAT-PT creates. But sometimes we first need to try things out in the real world before we actually know what behavior works best. I agree that it can be useful to document some NAT behavior, but I don't believe it is necessary that NAT itself is standardized in order to achieve interoperability (in fact, I am not sure whether this is the right word, it is more about better application expections for certain behavior to achieve easier and more predictable NAT traversal). I also believe we are moving towards a consensus that a NAT-PT like solution that purely exists in a middlebox is probably not workable for exactly the reasons that RFC 4966 explains so changes on either the IPv6 or IPv4 host that communicates through the NAT-PT translator are required. In that case, I am not sure whether we should still call it NAT-PT. What we are really developing then are NAT-PT control protocols or perhaps something completely new that deserves a new name. I have no issue with that, although I would like to note that we don't have a strong trackrecord when it comes to protocols that control middleboxes. In addition, I don't have a lot of hope to solve all issues with NAT behavior as they are inherent to the process of address translation itself. For the record, I believe that most people on this list are really tired of any discussion that involves NATs in any form or shape. My opinion is now known and I don't intend to send any more mail on this topic. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NAT+PT for IPv6 Transition Operator Feedback generally
Ran, On Wed, Nov 14, 2007 at 08:19:56AM -0500, RJ Atkinson wrote: Given that the IESG ignored inputs from some number of people noting that the RFC in question was actually deployed [1], it seems doubtful that it would be worthwhile for any of the operators who have deployed NAT+PT to travel to an IETF for the purpose of commenting in person. This paragraph is misleading in many ways: your reference [1] actually points to a reference that indicates that a company that you are very familiar with does not have a NAT-PT product, let alone that any customers of that company might be able to deploy it. I would not call such a reference supportive of the point that the RFC is actually deployed as you claim. Furthermore, you seem to know that the IESG ignored inputs when this draft was up for Last Call. I was the shepherding AD at the time and reality was very different: I was very reluctant to take this draft on as I didn't look forward for yet another inconclusive round of discussions on the merits of NAT. In addition, personally I am not convinced that the Historic status really has any value, especially if one considers the amount of work to actually get it done as opposed to using the same energy for other important work. However, it was very clear that there was consensus within the working group to request this status change as an alternative to moving it to experimental as the process didn't seem to allow us to do that. I talked to the chairs at multiple occasions and made it clear that in my judegement, I expected that this status change might not be easily accepted by the wider IETF community. However, to my own surprise, after I issued the Last Call, it became very clear from the comments received that there was no significant opposition to making NAT-PT historic. Your statement that the IESG just ignored inputs from some number of people seems thus not to reflect what actually happened. I do understand why quite a few operators have a somewhat cynical view due to a believe that the IETF is not listening enough to them. While there is definitely some truth there, there is very often also a serious amount of misunderstanding due to incomplete information and often misleading information spread by self-appointed spokes(wo)men for the IETF. For example in this particular case, the working group really wanted to move NAT-PT to experimental with the intention to show that it is was not the preferred IETF solution but at the same time not completely rule it's use out either (in fact even Historic doesn't really say that one should not use it under any circumstance), but as mentioned earlier we didn't find a way to actually do that with our process rules. At the same time, there were already quite a few voices within the IETF pushing for a new and improved NAT-PT. I honestly cannot call that a situation where the IETF simply ignores the needs of operators. David Kessens PS as my personal opinion on NAT-PT, as long as we define it as middlebox as opposed to a protocol that has strong interoperation needs, I am not convinced that it actually even needs to be standardized by IETF as it is perfectly possible to implement NAT-PT without a stable IETF specification and to make it work across the Internet. --- More than one person in the operator community now refers to the IVTF rather than IETF, because of the perception that the large vendors and professional standards-goers dominate IETF processes and IESG decisions and that network operators [2] are mostly ignored. It seems a bit of hubris for one to insist that operators must come to IETF given the history of IETF and IESG ignoring many operator inputs for much of the past decade.[3] The main bit of operator input that has been undertaken by IETF has been NetConf (basically standardising an equivalent to the then already deployed, albeit then proprietary, JunOS Script). That was done because of the recommendation from the IAB Network Management Workshop held in Reston earlier this decade (which itself was a bit of IAB outreach, rather than IESG/IETF outreach). Rather than demanding that operators come to IETF as if supplicants, particularly given the history, some would prefer to see the IETF/IESG engage in more outreach to the operational community -- not as a one-time thing but as an ongoing obligation. IETF and IESG should go to the operational community, rather than expecting or demanding that they come to the IETF. [4] This burden of operator outreach ought not be levied only on the OM Area, but across the whole IESG. IETF WG chairs should similarly be encouraged to actively reach out to collect operational feedback. Several operators have said that they have deployed this IPv6::IPv4 NAT+PT technology. So the data seems to indicate at least some operational folks view that RFC as good enough, even if some IETF folks view it as imperfect. (The separate
Re: Last call comment on draft-weiler-dnssec-dlv-iana-00
Olaf, On Mon, Sep 24, 2007 at 09:31:18AM +0200, Olaf M. Kolkman wrote: In response to my message: The IAB, obviously, favors expedient deployment of DNSSEC in the DNS root. David Kessens asked: Is there any activity by the IAB to achieve this goal ? In addition to statements like the sentence above there is a bit of 'silent diplomacy'. Considering that the root is still not signed, is the IAB considering a different approach than 'silent diplomacy' towards achieving this goal ? I would like to note that the RIPE community has issued a public statement (http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf) while I have not seen anything directly addressed to ICANN from the IAB. I would expect that the IAB, with it's Internet Architecture interest in mind, should be taking a much more active and public role as delays in DNSSEC deployment at the root level may very well inspire short-term non optimal solutions that will affect the overal security architecture as defined by the IETF for the DNS. Besides, under the header of leading by example we are working with the operators of the zones for which the IAB has certain responsibility to get those signed (e.g. [1]). For example the RIPE NCC will be announcing that they will be signing E164.arpa any time soon (see [2],[3] for the ongoing message exchange). I appreciate this. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Thomas, On Tue, Aug 28, 2007 at 04:09:14PM -0400, Thomas Narten wrote: We shouldn't be surprised that a one size fits all approach (where home users get the same amount of space by default as an IBM or Microsoft) doesn't seem to make a lot of sense to some people. US 2001:49c0::/32 2001:49c0::/32 IBM-IPV6-01 US 2001:4898::/32 2001:4898::/32 MICROSOFT-IPV6-BLK If there really is a one size fits all policy, where can I get my personal IPv6 /32 allocation ? David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Thomas, On Tue, Aug 28, 2007 at 07:26:03PM -0400, Thomas Narten wrote: This is the key point. And as David well knew when he posted his note, LIRs are not end sites and are treated _very_ differently. A /32 is the default minimum size an LIR gets. What you are saying here is that there is no one size fits all policy. For those not familiar with the terminology, an LIR is what we usually think of as a ISP or provider, where the organization provides internet connectivity for a number of other organizations. The definition of LIR is different in different Regional Registries. I can think of at least one region where there is no connection between being an LIR and providing connectivity to other organizations. As a data point, ARIN (in the last year) adopted a IPv6 PI for end sites doing multihoming policy. Such end sites get a /48. The policy says something different: The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. (from 6.5.8.2. Initial assignment size: http://www.arin.net/policy/nrpm.html#six582) Again, no one size fits all policy. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weiler-dnssec-dlv-iana (DNSSEC Lookaside Validation (DLV) IANA Registry) to Informational RFC
Mark, On Fri, Aug 24, 2007 at 10:54:41AM +1000, Mark Andrews wrote: This proposal is a way to move forward without waiting for the politics of signing the root to resolve. This is the classic case of the network routing around a blockage. I do believe that it will eventually resolve but at glacial pace. Or is it helping the blockage to persist as there will be less pressure to get this issue resolved ? As the RIPE community stated in an earlier message to ICANN, blocking the operational deployment of IETF technology is in fact undermining the security and stability of the Internet (http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf) and is thereby a very serious issue. I much prefer to have the IAB and IESG work on encouraging ICANN to get the root signed than that they (and IANA) spend time and resources on temporary workarounds. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
Stephen, On Thu, Aug 09, 2007 at 04:35:02PM -0400, Stephen Kent wrote: At 11:40 AM -0700 8/9/07, Bill Manning wrote: O... ICANN is also a legal entity, with the same vulnerabilities as all other companies including RIR's... which was my point. Special is reserved for governments... :) The U.S. Dept. of Commerce recognizes ICANN exclusively (via an MoU) with regard to certain Internet functions, so maybe that makes ICANN special, once removed :-). For many other governments and companies anywhere in the world, a large shareholder owned company is way more neutral than an entity that is special in the way you just described. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John, On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote: If the IESG is going to claim a silent majority in favor of approving this document, so be it. But to claim that there were no Last Call comments and that those that were solicited were positive is deeply problematic.It even leads one to wonder whether the IESG has ignored critical comments in other cases, but I trust that has not occurred. For the record, not everybody in the IESG was convinced that this document should be approved considering the discussion that happened on the IETF list. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC
On Wed, Feb 28, 2007 at 05:12:45PM +0100, Brian E Carpenter wrote: Good catch - that seems to be a little obsolete text that's sitting around in the I-D tracker. The draft itself is clear that Historic is the intention. For your information: I have asked the secretariat to reissue the Last Call with a new 2 week period and corrected text. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: addressing Last Call comments [Re: Discuss criteria]
On Sun, Jan 14, 2007 at 09:31:29AM +0100, Brian E Carpenter wrote: On 2007-01-12 09:54, Pekka Savola wrote: That depends on the AD's judgement whether the comments are serious enough to definitely require a new I-D. Quite often the AD will prefer to get any DISCUSSes on the table at the same time, again to reduce delay. It's highly unlikely that a document would get approved in its first appearance on the agenda in the presence of non-editorial LC comments. As an AD, I do expect other ADs to remove a document from the agenda if the Last Call comments are substantial and don't have a completely obvious resolution and/or really fall into the rough part of the consensus as determined by the working group chair and AD. Basically, that means I don't have a problem with documents on the agenda that have known minor editorial issues or issues that have a simple and straightforward solution that were brought up during the Last Call. Obviously, this involves a judgement call and I am happy to trust my colleagues to make such decision. As with all human decision making, we sometimes don't agree and have a discussion whether a document should really be on the agenda or not. In addition, there is the factor of time differences, vacation time and otherwise that sometimes will result in a situation that the document is only removed at quite a late stage. Personnally, I rather have us occasionally fix a problem because we are a bit too aggressive in getting a document on the agenda than being so careful that all documents end up incurring more delays during the IESG review phase. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
My availability for a new term as Operations Management Area Director
Many people have approached me and asked the question whether I am available for a new term as one of the Operations Management Area Directors. I have no problem answering this question but I personally felt a bit uncomfortable with answering this question in a private setting as some people get to know the answer while others are kept in the dark. To avoid such situations, I would like to let you know that I am available for another term as Operations Management Area Director. I hope this helps, David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [David Kessens] DISCUSS: draft-carpenter-rescind-3683
support keeping a mechanism which generates denial-of-service-like situations on this mailing-list and within the IESG. I don't see what you base this on. Not having this mechanism created way bigger problems than having this mechanism. This mechanism was created for a reason and it worked. That doesn't mean that anybody believes that this is mechanism should be invoked very often though, it is designed for extreme cases and it is not a pleasure at all to invoke it. In fact, that alone is good a way to make sure that it will not be used for minor cases. I personally was very involved in one of the PR actions. It was an enormous amount of work but I believe that it was worth it as the results are that we can now finally hold a civilized discussion on this list again. - it rescinds 3683 - it allows longer than 30 day mailing list posting suspension From a management perspective, these actions would normally be used together: eg. 3883 actions would only be used after longer than 30 day mailing list suspension have been tried and were unsuccessful. David has had quite a while to propose an I-D to allow that. There has been no such proposal. If one emerges, I'll be happy to comment on it; but unless it actually _required_ say 90-day suspensions to have been tried and failed, I'd worry about denial-of-service on the lists. We already have an experiment on the books that allows us to just do this as an experiment. I don't see any reason why we need more process and procedures. It is haphazardous at best to rescind one control mechanism and to replace it with one that leaves non working group mail management completely out in the dark, especially considering that we have had most problems recently on non working group mailing lists and that the only PR actions that were taken were specifically used to deal with issues on non working group lists. This, IMHO, is David's strongest point. But I believe we have to, first, get RFC 3683 out of the way, and second, look at why we've found ourselves discussing P-R actions when possibly honest differences of opinion arise (by which I mean only that Dean Anderson and JFC Morfin appeared to honestly believe what they were saying). So what do people do who manage non-working group IETF lists in the mean time ? I don't believe we _know_ the right apprach for non-WG lists. I strongly support trying the geometrically-increasing suspensions being tried on ietf@ietf.org We need experience with such ideas before we can claim to have a solution for non-WG lists. We should not hold up Brian's proposal in search of a perfection which may be beyond our reach. Is there any particular reason why you believe that problem is really so different from working group lists ? I for one note that the problems that we have had with certain individuals were no different whether they had chosen to disrupt working group mailing lists or non working group mailing lists. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF-related spam from JFC Morfin
Ted, I am surprised that you don't mention Mr Morfin's implicit accusation that Tony is incompetent. I wonder how many more warnings Mr Morfin will need to get before his posting rights are finally revoked? Mr Morfin is the subject of an active PR Action and as one of the sergeant-in-arms, you have the right to revoke his posting rights right away and for as long as the PR action lasts. The PR action itself has already served as the final warning to Mr Morfin that he should modify his behavior. He clearly hasn't done so, and apparently has ignored your latest warning as well. Unfortunately, I don't have the option, as so many other people have done earlier, to unsubscribe form this list. As an Area Director, I feel it is my duty to be subscribed on this list. I would very much appreciate if you could take action to make sure that we don't end up in a situation where the last people that are still subscribed to this list are the IESG, the IAB and Mr Morfin. Thanks, David Kessens --- On Thu, Sep 28, 2006 at 10:44:11AM -0400, Theodore Tso wrote: On Thu, Sep 28, 2006 at 04:15:01PM +0200, Jefsey_Morfin wrote: Dear Tony, I am afraid your are spaming the ietf mailing list. This mail was only sent to people I thought competent in language issues. I apologise indeed for having counted you as one of them. This will not happen again. Jefsey, We have received complaints that you may be Bcc'ing people who are on the IETF mailing list, who believe that you did this with the motivation to bypass their killfile rules. If you are in fact doing this, please desist. It's not a particularly professional thing to do; in fact, the times when Bcc's are appropriate are generally quite rare. Thanks, regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Jordi, On Thu, Mar 23, 2006 at 06:11:06PM -0600, JORDI PALET MARTINEZ wrote: We need to calculate the average cost of IETF hosted in all the continents, and that cost is the one that need to be put on the table by any sponsor/host regardless of where the meeting is actually going to be hosted. Why would we go for the average instead of the cheapest ? Overall price of a meeting location is an easier criteria to measure and more fair than all kind of political considerations. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Keith, On Thu, Mar 23, 2006 at 07:46:21PM -0500, Keith Moore wrote: I have also been of the impression that our hotel bills and meeting fees were paying for most of the cost of our meetings, and that the sponsors were mostly providing local logistical support and paying for incidental costs - terminal room and wireless, t-shirts, subsidizing the social, etc. These costs vary a lot as well: telco costs are very differrent in various locale, local staff cost is very different, social cost depends a lot on the location etc. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
Andy, I have been involved as local host now for two times (although I wasn't very local this time ;-)). I agree that it doesn't make sense to build a network each and every time completely from scratch. It is an enormous effort to beg potential sponsors for accesspoints (or spend a lot of money to buy them), to figure out how to build a terminal room and how to equip it, to buy servers and install monitoring software that gets wiped out right after the meeting to mention just a few examples. Luckily, we and the very experienced group of volunteers that helped us did have some memories (nightmares?) from previous meetings but it would have been way more efficient if a lot of the building blocks were simply already in place before a host even volunteers to be the host (and I think a host would more easily take on this role if the job was a bit more manageable). I personally believe that we would be better off if the same experienced (paid for) group would build the network each and every time with the same equipment owned by IETF, while the sponsor does what they are best at, and that is providing funding for the actual meeting. David Kessens PS it will also be easier to deal with complaints: no cookies at the break ? well, maybe you or employer should have sponsored the break then. --- On Thu, Mar 23, 2006 at 07:34:00PM -0800, Andy Bierman wrote: Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
Dave, On Fri, Jan 27, 2006 at 07:57:08AM -0800, Dave Crocker wrote: This makes it inconvenient not only for getting to restaurants but also for attendees wanting to stay at cheaper hotels. There is a wide selection of cheaper hotels available around the meeting hotel that are all walking distance. Restaurants at walking distance are indeed problematic. However, the hotel has quite a few choices of it's own and there are quite a few very good restaurants a short cab ride away. We realize that this is not ideal. Site selection is a compromise. To give a bit of background: unfortunately, the hotel selection process started very late which limited the amount of available venues such that we didn't had the luxury to select a hotel that could satisfy all criteria as much as we would have liked. We as Nokia offered to host the meeting when we heard at a fairly late stage that IETF was still in need for a host and that Dallas was being considered by the secretariat (Our US headquarters are in Dallas). My personal hope is that the selection process will happen more in advance future now that we have Ray in place as our IAD. Frequently it even makes it difficult to just walk around. As everything in Dallas, this hotel is quite large. Just a walk around the premises will be quite a bit. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
Steve, On Wed, Jan 25, 2006 at 01:38:03PM -0500, Steven M. Bellovin wrote: I agree with your observation -- 802.11a users are more satisfied with the network. I made sure that I got an 802.11a-capable interface when I bought a new laptop. But I'm reluctant to tell everyone to do that without more assurance that it will solve the problem. We've heard lots of hypotheses over the years on what to do about 802.11b/g, including lower-power access points, more attention to channel assignment, and getting people to turn off ad hoc mode. None of those have solved the problem. Will switching to 802.11a? Is there other prior art we need to look at? Theory and practical experience both indicate that 802.11a can give you better performance in IETF settings. And for the record, we are not talking about switching to 802.11a (check out: http://www.ietf.org/meetings/notes_noc65.html). We are advising people to bring a card/dongle that is capable of 802.11a to take advantage of this better performing technology. At current prices (it is not hard to find prices well below US$50), this seems a rather small investment to make. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
Francis, On Wed, Jan 25, 2006 at 08:27:37PM +0100, Francis Dupont wrote: PS: I need a local (Dallas) place to buy it too. www.frys.com Fry's Electronics 12710 Executive Drive Dallas, TX (214) 342-5900 about 14 miles from the hotel. We will see whether we can post this information to the webpage and we will check if there are more nearby stores. Of course, Fry's tends to be well worth the drive even if there are stores that are more nearby. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
Jordi, On Wed, Jan 25, 2006 at 05:47:17PM -0400, JORDI PALET MARTINEZ wrote: I understand your point, which somehow has been replied by some other comments in the list such as: - Is not so clear that this technology (a) will still work if all use it. - We are asking to change to 75% of the attendees. I don't understand why you keep harping on this issue that only exists because you have misread our announcement. We have been very forthcoming and clear why we like people to bring 802.11a cards. We are not forcing anybody to use 802.11a and there is absolutely no talk of not providing 802.11b wireless access. We *RECOMMEND* that people bring and use 802.11a gear because we believe that *EVERYBODY*, including people who only have 802.11b cards, will have a better network experience. The only thing that we should have mentioned, but that we overlooked as most cards/dongles on the market now do 802.11a,bg, is that we don't recommend to leave your 802.11b equipment at home. The hotel is very large and there will be areas in the fringes that will have better 802.11b coverage or that are only covered by the hotels own 802.11b service. - 50USD may be a lot for some people. You can easily get cards *LESS* than US$50. It is your judgement call whether you believe that this investment is worth it. Don't buy a 802.11a card/dongle if you think it is too much. Nobody forces you to buy one. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
Jordi, On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote: I'm not sure if I got it. My MUST was on the other way around: We really need to warrantee good coverage for b/g to 75% of the participants. We hope to offer good connectivity to the other 25% of the participants as well. You can help us by bringing a configured 802.11a card. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Subject: IETF Last Call under RFC 3683 concerning Dean Anderson (reissued)
[NOTE: It has come to the attention of the IESG that the original Last Call message was posted to the IETF announcements mail list while RFC 3683 specifies that it should have been posted to the general IETF discussion list. To correct for this oversight, this Last Call message is reissued with a new expiry date and posted to the correct mail list as prescribed by RFC 3683.] --- The IESG received a request from Dave Crocker to take action under RFC 3683 against Dean Anderson. Mr Crocker alleged disruption of the IETF and DNSEXT lists and provided sample emails [4]. In addition, Dean Anderson was recently warned by David Kessens [2], Operations Management Area Director, that a recent posting on the DNSOP working group mail list was not acceptable after which he responded to the DNSOP list by sending a brief message but with a similar accusation as the one he was warned not to repeat. While these messages alone might not suffice to justify action, Mr Anderson has repeatedly posted, before and since, on these and other IETF lists, messages that refer offensively to individuals or organizations [1]. For a small sample of such messages, we refer to the urls provided at the bottom of this Last Call message. Many of them are off topic for the IETF, since the IETF can only produce general technical recommendations for operators; it may not criticise individual operators or tell them how to conduct their business. We wish to make it clear that quarrels and disagreements between software suppliers, operators and the like have no place in the IETF and must be discussed and settled elsewhere. Although sometimes Mr Anderson's messages address technical topics, this is not enough to excuse the frequent offensiveness. He has been warned to desist from offensive postings multiple times and has often ignored such warnings [2,3]. The IESG therefore proposes to ban Dean Anderson from posting to the main IETF list and to authorize all WG chairs to ban him from posting to their working group lists. This message calls for comments on this proposed action from the IETF, which should be sent to iesg@ietf.org (or ietf@ietf.org) by 12 November 2005. For the IESG, David Kessens Operations Management Area Director --- Please see below for a sample of abusive behavior on maillists: [1] Personal attack on Bill Strahm and alleges that Rob Austein defames av8 Internet: http://www1.ietf.org/mail-archive/web/ietf/current/msg37889.html IETF management is accused of harassment and it is stated that Stephen Sprunk is untrustworthy (end of message). In addition, the message implies that David Kessens is the responsible Area Director for dnsext, while this working group is part of the INT area: http://www1.ietf.org/mail-archive/web/ietf/current/msg37931.html Dean uses a very unpleasant tone to make it clear to David Kessens that he doesn't agree with him and adds another attack by twisting Steven Bellovin's own words and smearing Steven Bellovin's reputation: http://www1.ietf.org/mail-archive/web/ietf/current/msg37873.html (Dean apperently referred to: http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html) Please see below for a sample of messages that ignore requests to Dean Anderson to stop his disruptive behavior: [2] Example of an attack on a well known organization on the dnsop list: Dean Anderson attacks a well known root name server operator and talks about uncontrolled corruption in the IETF: http://darkwing.uoregon.edu/~llynch/dnsop/msg03551.html Message by David Kessens to Dean Anderson that warns him not to bring up any issues he apparently has with a well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03552.html Dean's response in which he reaffirms his accusations towards the well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03553.html [3] Dean alleges that some IETF participants are liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36027.html Brian Carpenter warns not to continue allegations about liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36034.html Dean continues discussion on the list http://www1.ietf.org/mail-archive/web/ietf/current/msg36087.html [4] Materials provided by Dave Crocker to support his request (IETF and dnsext list): Dean continues to discuss topic that was declared off-topic by working group chair: http://www1.ietf.org/mail-archive/web/ietf/current/msg37550.html Dave's response on part of Dean's mail: http://www1.ietf.org/mail-archive/web/ietf/current/msg37554.html Two messages by other participants who continue to discuss Dean's point: http://www1.ietf.org/mail-archive/web/ietf/current/msg37555.html http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html Personal attack on Dave Crocker (and attack on Paul Vixie) by Dean. In addition his message does not substantiate his earlier claims about IPR
Re: Can the USA welcome IETF (was: Last Call under RFC 3683 concerning Dean Anderson (reissued))
Eduardo, On Sat, Oct 15, 2005 at 10:51:54PM +0200, Eduardo Mendez wrote: 2005/10/14, David Kessens [EMAIL PROTECTED]: [NOTE: It has come to the attention of the IESG that the original Last Call message was posted to the IETF announcements mail list while RFC 3683 specifies that it should have been posted to the general IETF discussion list. To correct for this oversight, this Last Call message is reissued with a new expiry date and posted to the correct mail list as prescribed by RFC 3683.] So, the proscutor/judge AD saw no one was interested. One yes, one no. He thinks one month will be too short. So he finds a way to do it again. I don't appreciate your suggestion that there could be another motive for reissuing the Last Call as the explanation in the note that accompanied the reissued Last Call message was quite clear in it's motivation. The Last Call was reissued since the first message was inadvertently send to the the IETF announce list (where all other IETF Last Call messages are send) instead of the IETF discussion list as specified by RFC 3683. It seemed prudent to reset the Last Call timer to avoid any conflicts on whether the Last Call would have been of sufficient duration. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Subject: IETF Last Call under RFC 3683 concerning Dean Anderson (reissued)
[NOTE: It has come to the attention of the IESG that the original Last Call message was posted to the IETF announcements mail list while RFC 3683 specifies that it should have been posted to the general IETF discussion list. To correct for this oversight, this Last Call message is reissued with a new expiry date and posted to the correct mail list as prescribed by RFC 3683.] --- The IESG received a request from Dave Crocker to take action under RFC 3683 against Dean Anderson. Mr Crocker alleged disruption of the IETF and DNSEXT lists and provided sample emails [4]. In addition, Dean Anderson was recently warned by David Kessens [2], Operations Management Area Director, that a recent posting on the DNSOP working group mail list was not acceptable after which he responded to the DNSOP list by sending a brief message but with a similar accusation as the one he was warned not to repeat. While these messages alone might not suffice to justify action, Mr Anderson has repeatedly posted, before and since, on these and other IETF lists, messages that refer offensively to individuals or organizations [1]. For a small sample of such messages, we refer to the urls provided at the bottom of this Last Call message. Many of them are off topic for the IETF, since the IETF can only produce general technical recommendations for operators; it may not criticise individual operators or tell them how to conduct their business. We wish to make it clear that quarrels and disagreements between software suppliers, operators and the like have no place in the IETF and must be discussed and settled elsewhere. Although sometimes Mr Anderson's messages address technical topics, this is not enough to excuse the frequent offensiveness. He has been warned to desist from offensive postings multiple times and has often ignored such warnings [2,3]. The IESG therefore proposes to ban Dean Anderson from posting to the main IETF list and to authorize all WG chairs to ban him from posting to their working group lists. This message calls for comments on this proposed action from the IETF, which should be sent to iesg@ietf.org (or ietf@ietf.org) by 12 November 2005. For the IESG, David Kessens Operations Management Area Director --- Please see below for a sample of abusive behavior on maillists: [1] Personal attack on Bill Strahm and alleges that Rob Austein defames av8 Internet: http://www1.ietf.org/mail-archive/web/ietf/current/msg37889.html IETF management is accused of harassment and it is stated that Stephen Sprunk is untrustworthy (end of message). In addition, the message implies that David Kessens is the responsible Area Director for dnsext, while this working group is part of the INT area: http://www1.ietf.org/mail-archive/web/ietf/current/msg37931.html Dean uses a very unpleasant tone to make it clear to David Kessens that he doesn't agree with him and adds another attack by twisting Steven Bellovin's own words and smearing Steven Bellovin's reputation: http://www1.ietf.org/mail-archive/web/ietf/current/msg37873.html (Dean apperently referred to: http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html) Please see below for a sample of messages that ignore requests to Dean Anderson to stop his disruptive behavior: [2] Example of an attack on a well known organization on the dnsop list: Dean Anderson attacks a well known root name server operator and talks about uncontrolled corruption in the IETF: http://darkwing.uoregon.edu/~llynch/dnsop/msg03551.html Message by David Kessens to Dean Anderson that warns him not to bring up any issues he apparently has with a well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03552.html Dean's response in which he reaffirms his accusations towards the well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03553.html [3] Dean alleges that some IETF participants are liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36027.html Brian Carpenter warns not to continue allegations about liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36034.html Dean continues discussion on the list http://www1.ietf.org/mail-archive/web/ietf/current/msg36087.html [4] Materials provided by Dave Crocker to support his request (IETF and dnsext list): Dean continues to discuss topic that was declared off-topic by working group chair: http://www1.ietf.org/mail-archive/web/ietf/current/msg37550.html Dave's response on part of Dean's mail: http://www1.ietf.org/mail-archive/web/ietf/current/msg37554.html Two messages by other participants who continue to discuss Dean's point: http://www1.ietf.org/mail-archive/web/ietf/current/msg37555.html http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html Personal attack on Dave Crocker (and attack on Paul Vixie) by Dean. In addition his message does not substantiate his earlier claims about IPR
Re: Reexamining premises (was Re: UN plans to take over our job!)
Harald, On Fri, Sep 30, 2005 at 10:59:47PM +0200, Harald Tveit Alvestrand wrote: --On fredag, september 30, 2005 16:36:13 -0400 Michael Mealling [EMAIL PROTECTED] wrote: There is no reason why the addresses that system uses need to be remotely understandable by humans. The identifier I use to look you up and be able to differentiate you from someone else would be run completely differently from the addressing system used to route a message through a store and forward network. X.400 tried that. So did X.25. I think one of the less-appreciated reasons the Internet succeedd was that its unique identifiers were *memorable*. And the use of a very simple characterset for these identifiers helped a lot too. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
Nicholas, On Sat, Sep 24, 2005 at 05:46:33PM -0700, Nicholas Staff wrote: David, the way it reads to me is you warned Dean you would go to the IESG if he continued what you felt were abusive posts. I first sent a message on the dnsop mail list that most people would interpret as a clear warning to behave better or face the consequences. However, considering earlier misunderstandings, I sent him a private message to make sure he fully understood what I was telling him. Dean in turn informed the IESG of your warning because he felt it was unwarranted and being used by you as a tool to silence someone who had a differing technical opinion. He did two things: He sent another inflammatory message to the dnsop mail list in which he again attacked a well-known organization while he was just told to refrain from such attacks. In addition, he forwarded my private message to the IETF mail list. However, he not just forwarded my private messsage, he added simular accusations as the ones in his earlier messages to the dnsop mail list. You then used his complaint to the IESG as an instance of another abusive post and requested to have his privileges removed. Is that basically correct? No, it was not his complaint as he did not sent a complaint. It was the fact that he used his messages to repeat the same accusations that he was warned not to repeat. If so are you telling me that I have to be afraid of ever voicing a complaint or problem to the IESG because an AD can use that as a reason for retribution? I did not send my request to the IESG just because he voiced his opinion or filed a complaint. I sent my request, because, among others, his comments were out of scope for the dnsop working group, he voiced his opinion in a totally unprofessional manner and repeated this behavior on two different mail lists right after he was warned. I hope this helps to clarify the events. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[EMAIL PROTECTED]: Mismanagement of the DNSOP list]
IESG, I would like to request that we consider Dean Anderson posting privileges to be removed for the dnsop and ietf maillist. As you can see from my private mail that Dean forwarded to the IETF list, I have given him an official warning to refrain from sending any more abusive mails to IETF maillists. Despite this, he immediately followed up by sending more abusive mails to the dnsop and ietf mail lists. I hope that we can discuss this as soon as possible. Until then, I will try to refrain from sending any more messages on this topic as I don't believe that this will be productive. People on this mail list might want to consider to do the same thing. Thanks, David Kessens Operations Management Area Director --- - Forwarded message from Dean Anderson [EMAIL PROTECTED] - Date: Fri, 23 Sep 2005 20:08:46 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] X-X-Sender: [EMAIL PROTECTED] To: ietf@ietf.org Subject: Mismanagement of the DNSOP list FYI: I am being threatened for posting operationally relevant criticism of mis-operation of the F DNS Root server on the DNSOP list. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- Forwarded message -- Date: Fri, 23 Sep 2005 15:55:20 -0700 From: David Kessens [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: David Meyer [EMAIL PROTECTED], Rob Austein [EMAIL PROTECTED], Bert Wijnen [EMAIL PROTECTED] Subject: [EMAIL PROTECTED]: Re: [dnsop] An attack that DNSSEC would have defended against...] Dean, To avoid any misunderstandings: My message is an official warning to you that I will propose to the IESG to remove your posting privileges if I see one more abusive mail from you. Thanks, David Kessens --- - Forwarded message from David Kessens [EMAIL PROTECTED] - Date: Fri, 23 Sep 2005 15:36:11 -0700 From: David Kessens [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: Harald Tveit Alvestrand [EMAIL PROTECTED], dnsop@lists.uoregon.edu Subject: Re: [dnsop] An attack that DNSSEC would have defended against... Dean, You are welcome to post to this list if you have DNS operational issues to discuss. Any issues that you might have with ISC are outside the charter of this working group and I would like to request you to take them up privately with ISC. Thanks, David Kessens --- On Fri, Sep 23, 2005 at 06:09:23PM -0400, Dean Anderson wrote: Harald, you may be right about DNSSEC protecting from this. I haven't looked at your data, yet. However, you probably aren't about to be very well protected by DNSSEC, despite the progress of specifications on DNSEXT. DNSSEC isn't deployable on F-root nor the other anycast'ed* roots, nor a lot of other anycast'ed non-root servers. DNS servers with the Anycast Extension are increasingly popular due to suppression of discussion of negative aspects of the Anycast Extension on forums such as Nanog as recently as May, 2005 because only information that promotes ISC's view is allowed on Nanog, misleading network operators about the Anycast Extension. Many root server operators accepted ISC's assurances as an unofficial IETF liason and deployed Anycast Extension on production servers and on root servers in violation of RFC 2870**. They appear not to have understood that they were deploying an untested, undocumented, and unapproved Anycast Extension. And despite substantiated criticism on DNSEXT and DNSOP by persons including Dan Bernstein, Iljitsch van Beijnum, Dean Anderson, and others since the 2002 Nanog presentation by ISC, ISC has not yet even publicly acknowledged the problems with the Anycast Extension, and continues to promote the extension as completely safe. ISC even describes it to prospective customers as uncontroversial, despite the controversies on DNSEXT, DNSOP, and Nanog beginning after the Nanog presentation in 2002. The Anycast Extension is now proposed to the GROW working group some 3 years after being described to Nanog as operationally safe and stable. At present, the Anycast Extension proposal appears to be dead or dying on both DNSOP and GROW WGs because of evidence that it can't work in general, and the specialized conditions where it can work are uninteresting to the current users such as root DNS operators and other DNS operators, and thus uninteresting to ISC. The only reason there are no present complaints with root operations is that DNS is mostly still stateless small UDP packets, reducing to RFC 1546 Anycast***, which works fine with stateless small UDP packets. And it may well be that those working on DNSSEC testing comply with the assumptions stated on the Anycast Extension. So the question is when will F-root and other roots be able to handle TCP and large UDP packets from any internet host, including those hosts serviced by networks that use fine-grained load-splitting
Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
Yaakov, On Wed, Sep 21, 2005 at 08:58:12AM +0200, Yaakov Stein wrote: Most of the comments have questioned the cost of adding 2 ADs to the lucky number 13. However, there are a other large numbers to consider. For example 26 and 24 - the number of WGs in the transport and Internet areas, respectively. I have never seen a senior manager in a commercial enterprise to whom 26 subordinates, each responsible for completely distinct disciplines, directly report. Decreasing the number of WGs per area to a number that can be reasonably managed and technically lead by the AD is one of the advantages of the proposal. Most Areas organize themselves in such a way that each AD manages about half of the total. Having said that, even in that case, the transport area is still quite large and there is indeed a misfit for some working groups. I do support a reorganization to address this problem. However, I believe that we should try to do this reorganization without adding more ADs to the IESG. Nobody has seriously looked at this option. What we are proposing now is the traditional way how organizations keep growing in size as we all get focussed on adding features to solve our problems instead of balancing scarce resources and reducing our coverage in areas that have grown less important or are relatively small but are still served by two ADs. For example, I proposed that we could also add the Real-Time Applications to the Applications area with a new updated charter to reflect this change (Or add the Applications Area to the Real-Time Applications area). That way, all these groups will be under the same roof too without having to increase the number of ADs. Other solutions are possible too, like creating this area but for example reducing the number of ADs in other areas or combining them. I can even think of a few variants where the Ops Mgmt area gets some additional work at the Mgmt side as we are for example already quite active with infrastructure applications like Radius. We could in that case become the Ops Infrastructure Area. I notice that nobody has really responded with suggestions on how this could be achieved or with alternatives for my suggestion as there are obviously many possible variants. Is it perhaps easier to let the bureaucracy grow instead of looking seriously at ways to make us operate more efficient ? And growing before we have the structure in place to actually allow this growth seems real risky: this is the perfect way to get to a situation of total gridlock. This is what we have been doing in the past and it hasn't worked so well. It is time to stop this. And this will still leave a manageable 15 members in the IESG. First of all I don't believe that 15 members in the IESG is manageable in any way or form. In fact, I believe that 13 members is already not manageable. Note that the next proposal for an additional area is just around the corner: the Internet area has a very heavy load of working groups as well and the next thing that could easily be imagined is a Mobility Area which also sounds very reasonable. Are we going to tell them then that they cannot have their own area while we just added another one for Real-Time Applications ? David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
Lakshminath, On Wed, Sep 21, 2005 at 02:35:21PM -0700, Lakshminath Dondeti wrote: I am curious about the scheduling issues. If the IESG job is a full-time job, why can't the people on IESG find time to meet with each other, f2f or in telecons; perhaps someone will help me understand that. The other issue that comes up is time zones. We've had this in the Nomcom and I found out recently that telecons at odd hours is the norm if you work in some SDOs. I think these should be non-issues really. Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. I think you have a reasonable understanding of the amount of time involved and issues with time zones. I think we should step away a bit from the word full time for the IESG job. We recently discussed this in the IESG and it was felt my most of us that a time commitment of at least 30 hours per week is needed, while many ADs spend more than that. Whether people than find even more time to do additional work is not really our problem as long it doesn't affect IESG performance. Many of our scheduling problems are related to timezones as you already guessed: in practice we have a 8am-11am window (Pacific Time Zone) that we can use for calls in the morning (from my perspective and assuming that I am not traveling ;-)). Other issues are our different expertises: eg. I am the OPS AD and feel that it is quite important to show up at various fora where operational people show up like NANOG, Apricot and RIPE. I bet that the Security Area Directors have their own security conferences etc. that they feel that are important to attend. In addition, despite the fact that many of us spend most of our time on the AD job, many of us occasionally have a need to show up at our company headquarters. Other issues include things like if you need to schedule something with X people also X people need to respond and progress on finding a common time is only as fast as the last person who reacts. And the larger the group, the more likely this last person is quite late due to various reasons from vacations, illness or to just being extra busy during business travel. Basically, trying to coordinate times that we can all be available is often already challenging and results in scheduling meetings further in the future than we would like to. Note that is just one of the issues, there are many issues that occur in the dynamics of a large group, whether is scheduling or simple things like finding a problem on a conference call bridge where one line causes a lot of noise which clearly takes a lot more time to debug when the group is larger. And all these issues together are decreasing our overall efficiency up to a point where things get extremely hard to get any work done (see Harald's mail for a nice explanation). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Cost vs. Benefit of Real-Time Applications and Infrastucture Area
I am very worried about the discussion on the new proposed area. Most mails are along the line that it sounds nice to have a new area formed. Forming a new area comes at a cost for the IETF, while there are also potential benefits. I believe it is very important for the community to consider and understand the costs versus the benefits for the creation of a new area. As for the benefits, I see that we would give more well deserved attention to an important area of work within the IETF. In addition, it should help to alleviate overload within the transport area. However, there are also many costs associated with this proposal, among others: - we need two more people out of the community who are going to spend a lot of their time on the administrative side of our organization instead of producing real work for the IETF. - the nomcom will need to do more work to appoint more ADs. - IETF documents will receive more scrutiny in the IESG. While this could be considered a good thing, there has been a significant amount of backlash in the community that enough is enough. I for one believe that we currently already provide enough review, and possibly already too much. - Management research has shown that optimal group sizes are in general quite a bit smaller than the current IESG. In fact, I see already significant strains within the IESG due to our group size. For example, we have a hard time to find a time, date and location for our retreats that work for all of our members. The definition of A hard time is that we spend significant amount of time trying to find a date and time that works for all of us. Other examples in terms of meetings where we all have to attend is a conference call regarding an appeal. We spend time on checking out who is actually present during an IESG call. We have issues with conference calls where somebody causes an echo on the conference system. The more people attend, the more time it takes to debug the problem. We send mail among each other, the more members we have the more mail we will receive and the more time we will need to read and respond to IESG internal mails. The more we specialize the function of areas, the more inter-area coordination will be needed. We have discussions about drafts and many other issues during the telechats, the more people we have the more time we will spend on these discussions. Adding two more ADs has the potential to make this quite a bit worse as our group size is already in the territory of too large to operate efficiently. Two more ADs will bring us yet another step closer to the tipping point of where we will only be busy among ourselves instead of serving the community. I guess it comes as no surprise that I have serious issues with this proposal. While the idea sounds nice, the operational details will cause us more pain than it provides benefits. An IESG that doesn't operate efficiently is not in the benefit of the IETF. I believe that many of the benefits of a new area can be had without adding a new area. Alternatives could be to create a special attention area towards Real Time Applications within the Application area with one of the two ADs in the Applications area specializing on such applications. Another approach could be to do serious surgery on how the IESG operates to make it a more scalable group. I believe it is very dangerous to add an area before addressing the issues associated with a larger IESG as it will get ever harder to make such changes while our group grows less efficient by piecemeal fixes instead of looking at the larger issue of how the IESG as a whole can become more efficient to the benefit of the IETF. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
John, On Tue, Sep 20, 2005 at 09:37:43PM -0400, John C Klensin wrote: If it is possible, I'd be most happy to see this viewed as an experiment in the general spirit of RFC3933 but without some of the trappings. Treat it as a real area, appoint AD(s) as appropriate, but go into it with an agreement and the expectation that it, and the area structure more generally, will be carefully reviewed, and these tradeoffs reexamined, in a year or so. If it turns out to cause more problems then it is worth, perhaps we could then get rid of it --with no assumption of poor behavior on the part of the ADs-- and try something else. I am all for experiments but this one would be particularly tricky to setup. It is extremely hard to measure whether productivity of the IESG increased in a given period as none of the determining factors remain unchanged. Eg., the number of appeals in a given period is not the constant, the number of documents that we process is not the same, the number of new working groups considered is not the constant, the total number of working groups that is being managed is not constant either and finally the cast of area directors (outside of the area directors that would be added) is different too. I wonder how productive it is to do an experiment about efficient group size while we already know that it hasn't worked in so many other settings. It is not like there are no warning signs already that we are spending already a significant amount of time on overhead instead of doing the work that we were appointed for. At some point we have to decide that the IESG cannot become any larger. It is very easy to add one/two ADs at a time. Each time, it is unlikely that the addition of a single AD would cause the system to collapse. However, at the same time this is a very slippery slope. I believe that at some point we have to draw a line in the sand. Considering that we are already larger than optimal, now would be good time to make such a decision. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
Lakshminath, On Tue, Sep 20, 2005 at 05:45:27PM -0700, Lakshminath Dondeti wrote: Ok, I'll bite :-). I for one, think it is a good idea to have the additional area and this is inline with my support of additional ADs for areas that have a large number of drafts in waiting. I consider this more than nice to have; it is essential IMO and a natural way of areas being formed and deleted from the IETF. Now, if only we can find an area to delete: SEC anyone ;-). Just kidding, of course. I would have a lot less trouble with the proposal of adding an area if we would be able to find another one that could be abolished, or reorganize ourselves in some way or form that would result in no net addition of Area Directors. Just like a company that has limited resources available, I would very much prefer to keep a constant number of ADs (or actually even less than our current number) and allocate the resources where we need them most, instead of keeping to throw more resources at the problem. Although we don't have money changing hands, there still is a real cost of adding such resources and we should be very careful that we don't ignore these costs. In addition to that, the argument made to me was that some topics didn't quite belong in the APPS area or the TRANSPORT area. So there were meeting scheduling conflicts and the like as a result of that. I hope that we have more effective ways to deal with scheduling conflicts than adding an area. However, there are also many costs associated with this proposal, among others: - we need two more people out of the community who are going to spend a lot of their time on the administrative side of our organization instead of producing real work for the IETF. Unless the work increases due to the formation of the new area, the flip side is that we have 2 people doing 4 people's work. The latter is true, unfortunately, I believe that the first part of this statement is also true (though obviously, the workload increase will be felt more in the areas that are not able to move working groups to the new area). - the nomcom will need to do more work to appoint more ADs. I wish you said this last year :-) with all the IAOC work we had to do (I am on the outgoing Nomcom). Frankly, I would have found it easier to select two more people with technical expertise than two with administration type of expertise -- there are only a few of those in the IETF and they are already active in ISOC activities and are now pulling double duty (actually triple, considering they all want to be active in the technical side of things as well). ;-). Thanks for doing this work. Serving on the nomcom is a lot of hard work with very low payout. On the points below, I can't argue with you. Perhaps a more hierarchical structure is needed or perhaps only a subset of the IESG (randomly picked or voluntary+assignment based allotment might reduce the number of people) needs to review documents and discuss them. Anyway, I don't have the insight to discuss IESG operation (people say you have to be in it to know) :-). If IESG review is what's substituting for cross-area review, we need to fix that. Feel free to comment on IESG operations ;-). While it helps to be on the IESG to understand it's workings, it is also very useful to have people taking a fresh look at our operating procedures. And as you can see from the postings by various ADs, we have our own diverse views on our own role and how the IESG should operate too. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness.
Dave, On Wed, May 18, 2005 at 01:08:39PM -0700, Dave Crocker wrote: For example, as you note, the IESG approves working groups and working group charters. So the IESG does, in fact, have the ability to control the later demand placed on it. Are you suggesting that we start disapproving new working groups since they cause work for the IESG ? We can help to fine tune charters. We can engage the community to scope the work better. However, we are explicitly not chartered to review charters for the amount of work that they cause for the IESG. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Email account utilization warning.
Dean, On Mon, Jul 12, 2004 at 12:55:07PM -0400, Dean Anderson wrote: http://www.ietf.org/html.charters/dnsop-charter.html Yes, I've read this carefully. Did you really ? If you did, you would have found a mail address of Rob Austein that you can use to send him mail. David Kessens --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Email account utilization warning.
Dean, On Wed, Jul 07, 2004 at 02:19:20AM -0400, Dean Anderson wrote: P.S. I am still blocked from emailing DNS WG chair, and prevented from registering complaint about improper DNS WG RFC process activity by ISC and DNS WG chair Austein, because the IETF chairman Alvestrand demands that such complaints be made offlist, yet chairman Alvestrand refuses to require the WG Chairs to accept email from participants. Can you please keep the facts straight: - there is no such thing as the DNS WG do you mean the dnsop working group by any chance ? - the dnsop working group has two chairpeople, not just Rob Austein - you are not blocked by Rob Austein or prevented from registering a complaint. it has been pointed out to you that you have the ability to communicate with Rob Austein using the mail address that is posted on the ietf dnsop charter web page: http://www.ietf.org/html.charters/dnsop-charter.html Thanks, David Kessens --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
