Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
Hi, I'm part of the design team. SM has written this document to begin a discussion with the broader IETF. The document does not have the consensus of the design team, and it is therefore obviously not a recommendation by the design team. Lars On Oct 10, 2013, at 20:10, S Moonesamy sm+i...@elandsys.com wrote: Hi Jari, Here's is a draft about improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF. The draft builds upon the ISOC work, proposing adjustments and additional efforts, with the goal of enabling more sustained and active participation by contributors from under-represented regions. In a blog article ( http://www.ietf.org/blog/2013/04/diversity/ ), it is mentioned that: The design team will present their recommendations to the community, and engage in the discussion. Recommendations with community support will be taken forward. The draft only makes suggestions instead of recommendations. I am copying this message to ietf@ietf.org so that the community can comment about the draft. Regards, S. Moonesamydraft-ddt-fellowship-03.txt signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
Hi, On Oct 11, 2013, at 10:41, Abdussalam Baryun abdussalambar...@gmail.com wrote: I am part of the community design team as well because I participate with community more than the private hidden groups. I think that the draft is a true work open to IETF. I haven't said that anything to the contrary. I am simply pointing out that the draft is not a recommendation by the design team (which we will still make at some point in the near future, hopefully.) I still did not get a reply to my request to know what is the DT authority, very strange name without any procedure in IETF, please explain, Jari formed the design team in order to collect the issues that people have raised, organize them and then propose a few recommendations to the broader community. The design team has no authority, all we will do is propose some actions to the broader community, which will then need to get consensus there. Nothing is stopping anyone outside the design team from also thinking about these issues and making proposals. Also, the IETF has a long history of using design teams in working groups. We also use small, focused groups for other purposes, such as BOF planning. Whatever these groups still needs to get consensus in the broader community. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
Hi, On Oct 11, 2013, at 14:43, Jari Arkko jari.ar...@piuha.net wrote: I do have a question for Lars though. What are your opinions on this? (You said that there is no consensus, but I'd like to hear also your thoughts.) so one key question is what influence the IETF actually has on an ISOC program. We can certainly state our wishes, but my belief is that it's ISOC's program in the end, and they can basically chose to run it as they see fit. That doesn't come out in the draft at all. Another issue I have with the the draft is written with the implied understanding that the program should fund the repeated attendance of residents of under-represented regions who are actively participating in some sort of way. It's not clear to me that this is really what would be best in terms of increasing organizational diversity over time. I wouldn't want to fund the same people over and over; I'd much rather bring in new people all the time in the hopes of spreading the word about the IETF widely and hoping that some folks will end up in roles where they can occasionally attend on their own dime. I'd like to be able to bring in other under-represented groups (students, academics, women, etc.) We can certainly have a discussion about what is best; my point is that the draft has already decided that one approach is the way to go. I also have a few issues with the suggestions it makes: Section 4.1 requires that an applicant needs to already have been a participant in the IETF. That seems excessive. For returning fellows, some sort of engagement in the IETF after a while would be nice, but I can see valid cases for supporting someone's repeated attendance who isn't contributing in a very visible role. Also, I question the possibility to quantify and compare someone's impact of IETF involvement. And again, there are others than resident of a country in an under-represented region who we might want to bring in, and we probably don't need to fund the attendance of employees of large vendors who happen to be residents of under-represented regions. The evaluation panel in Section 4.2 is therefore also problematic. And I wouldn't want to blindly prioritize people who have been contributing over time to real IETF work - we need to keep the flexibility of bringing in someone new who has high potential even if it means that someone who has been funded to attend in the past isn't going to be covered. But my main issue is that the draft sounds like its trying to take over and redefine an ISOC program, which I don't think the IETF can or should do. The ISOC program has a purpose, a history and at least from my perspective is working pretty well with the budget it has available. I'm not sure we can actually improve it much. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Applied Networking Research Prize 2013 presentation at IETF-88
Hi, we are extremely pleased to report that for the 2013 award period of the Applied Networking Research Prize (ANRP), 36 eligible nominations were received. Each submission was reviewed by eight members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, four submissions were awarded an Applied Networking Research Prize in 2013. The fourth winning paper for 2013 will be presented at IETF-88 in Vancouver, BC, Canada. The award for IETF-88 goes to: *** Idilio Drago *** for characterizing traffic and workloads of the Dropbox cloud storage system: Idilio Drago, Marco Mellia, Maurizio M. Munafo, Anna Sperotto, Ramin Sadre and Aiko Pras. Inside Dropbox: Understanding Personal Cloud Storage Services. Proc. ACM Internet Measurement Conference (IMC), November 2012, Boston, MA, USA. Idilio has been invited to present his findings in the IRTF Open Meeting during IETF-88 in Vancouver, BC, Canada. Join him there! The call for ANRP nominations for the 2014 awards cycle will open in the fall of 2013. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2013 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Yang Richard Yang, Yale Lixia Zhang, UCLA
Berlin was awesome, let's come again
Venue was great, food options here and in the city were great, all-around great experience. Let's come again! (I do kinda wonder how there wasn't a single local company willing to step up to be the host. That's embarrassing to me as a German, esp. if the IETF meets in the self-declared IT hub of Germany. Better luck next time, I hope.) Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Berlin was awesome, let's come again
Hi, On Aug 2, 2013, at 13:04, Russ Housley hous...@vigilsec.com wrote: I have also enjoyed my time in Berlin. However, we need to complete the analysis on the impact of VAT. I hope there is a way to avoid a cost to each participant of an 19%. We heard in plenary that VAT clearly applies to conferences, but it may not apply to standards meeting. agreed. Snarky side comment: We should also analyze the impact of over-the-top tipping customs in some countries :-) Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Berlin was awesome, let's come again
On Aug 2, 2013, at 13:56, Deen, Glenn (NBCUniversal) glenn.d...@nbcuni.com wrote: -1 on doing it during the winter speaking as a Californian who doesn't even own a winter coat You are not going to like going to Vancouver for IETF-88... Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFC 6234 code
Hi, On Jun 28, 2013, at 10:53, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: But the broader point is that if it's worth the IETF publishing the code as an RFC, it's worth making the code available straightforwardly. some WGs are good at this. RFC5662 for example includes the shell commands to extract the sources it contains. It would certainly be nice if other WGs did this, too, but I'm not sure we need to make it a requirement. Lars
Re: The Nominating Committee Process: Eligibility
Hi, Section 2 says: RFC 3777 [RFC3777], Section 5, Nominating Committee Operation, Paragraph 1 of Rule 14, is replaced as follows: Members of the IETF community must have attended at least 3 of last 5 IETF meetings remotely or in person including at least 1 of the 5 last IETF meetings in person in order to volunteer. A few questions: (1) How do you define remote attendance? (2) How does the secretariat determine whether someone has remotely attended? (Based on whatever definition of remote attendance you have in mind.) Thanks, Lars
Re: The Nominating Committee Process: Eligibility
Hi, On Jun 27, 2013, at 18:26, S Moonesamy sm+i...@elandsys.com wrote: (1) How do you define remote attendance? (2) How does the secretariat determine whether someone has remotely attended? (Based on whatever definition of remote attendance you have in mind.) I prefer not to get into a definition of remote attendance for now. sorry, but it's silly to attempt to propose that remote attendees be permitted to volunteer for NomCom without defining what defines a remote attendee. For what it is worth the current system only tells us that a person has paid the registration fee. That person could have gone shopping, fallen asleep during the WG sessions, or sitting in a corner as he or she does not have a dot and is not considered as important. The issue you are raising - that limiting the NomCom pool to recent attendees of physical IETF meetings may have downsides - is valid. But at least the requirements the current policy sets are clearly defined. Until you nail down what exactly defines a remote attendee, I can't really form an opinion on whether allowing them into the NomCom pool is a good idea or not. Lars
Re: RFC 6234 code
Hi, On Jun 27, 2013, at 17:49, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: RFC 6234 contains, embedded in it, code to implement various functions, including SHA-2. Extracting that code from the RFC is not a clean process. https://tools.ietf.org/tools/rfcstrip/ can take the headers/footers out. Extracting the code from its output should be relatively easy. Lars
Re: [IAB] RSOC Appointments
On Jun 25, 2013, at 7:53, Randy Bush ra...@psg.com wrote: Congratulations, gentlemen. and they are all male Well, all the volunteers were male, so no real surprise here. (And yes, I wish the volunteer pool had been more diverse. But it wasn't.) Lars
Re: [IAB] RSOC Appointments
On Jun 25, 2013, at 7:53, Randy Bush ra...@psg.com wrote: Congratulations, gentlemen. and they are all male Well, all the volunteers were male, so no real surprise here. (And yes, I wish the volunteer pool had been more diverse. But it wasn't.) Lars
Call for Nominations: Applied Networking Research Prize 2014
CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2014 http://irtf.org/anrp *** Submit nominations for the 2014 award period of the *** *** Applied Networking Research Prize until November 30, 2013! *** *** *** ***(Please share this announcement with your colleagues.)*** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2014/. In exceptional cases, nominations may also be submitted by email to a...@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: November 30, 2013 (hard) Notifications: December 20, 2013 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2014-flyer.pdf smime.p7s Description: S/MIME cryptographic signature
Re: Participation per Region of Authoring IETF documents vs Marketing
Hi, On May 28, 2013, at 19:46, Abdussalam Baryun abdussalambar...@gmail.com wrote: by looking into the statistics of I-Ds and RFCs, it is strange that we get sometimes high rate in the I-D going in IETF from some regions but the success rate of I-Ds to become RFCs is very low (5- 50). which IDs and RFCs are you basing this statement on? Thanks, Lars
Fwd: [IRTF-Announce] Applied Networking Research Prize 2013 presentation at IETF-87
Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [IRTF-Announce] Applied Networking Research Prize 2013 presentation at IETF-87 Date: May 27, 2013 12:01:01 GMT+02:00 To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Reply-To: a...@irtf.org a...@irtf.org Hi, we are extremely pleased to report that for the 2013 award period of the Applied Networking Research Prize (ANRP), 36 eligible nominations were received. Each submission was reviewed by eight members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, four submissions were awarded an ANRP in 2013, the first of which was already presented at IETF-86. The second and third awards will happen at IETF-87 in Berlin, Germany. They go to: *** Te-Yuan Huang *** for insights into the difficulties of rate adaptation for streaming video: Te-Yuan Huang, Nikhil Handigol, Brandon Heller, Nick McKeown and Ramesh Johari. Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard. Proc. ACM Internet Measurement Conference (IMC),November 2012, Boston, MA, USA. *** Laurent Vanbever *** for proposing a framework to allow seamless BGP reconfigurations: Stefano Vissicchio, Laurent Vanbever, Cristel Pelsser, Luca Cittadini, Pierre Francois and Olivier Bonaventure. Improving Network Agility with Seamless BGP Reconfigurations. Proc. IEEE/ACM Transactions on Networking (TON), To Appear. Te-Yuan and Laurent have been invited to present her findings in the IRTF Open Meeting during IETF-87, July 28 - August 2, 2013 in Berlin, Germany. Join them there! The call for ANRP nominations for the 2014 awards cycle will open in the fall of 2013. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2013 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Yang Richard Yang, Yale Lixia Zhang, UCLA
Re: Participation per Region of Authoring IETF documents vs Marketing
On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages Lars
Re: Participation per Region of Authoring IETF documents vs Marketing
On May 27, 2013, at 15:31, Abdussalam Baryun abdussalambar...@gmail.com wrote: On 5/27/13, Eggert, Lars l...@netapp.com wrote: On May 27, 2013, at 12:10, Abdussalam Baryun abdussalambar...@gmail.com wrote: Each IETF document mentions the authors place address (I may suggest adding region, as a categorised by IETF), but not sure of history statistics of how many IETF-documents produced by authors in South America, Africa, or Asia, or others. http://www.arkko.com/tools/stats/d-countrydistr.html and related pages I read that before, but does not show documents/RFCs per region. It shows drafts per countries. For example, does not show the drafts from South America. Does not show all regions in sequence of the most participated region. That's why I wrote *and related pages*. Clicking around Jari's pages, you will easily find http://www.arkko.com/tools/rfcstats/d-contdistr.html as well as many more stats. As for most participated region, look at the reports from the IAOC: http://iaoc.ietf.org/reports.html Lars
Re: call for ideas: tail-heavy IETF process
On May 1, 2013, at 19:35, Peter Saint-Andre stpe...@stpeter.im wrote: Sorry: oughtn't that be Proposed Standard? Yep, it ought to. Crazy idea: Call a draft PS when it completes WG last-call and give it an RFC number, call it something else when it passes IESG review (draft standard? :-) and republish the RFC. When there is interop experience, call it full standard and republish as needed. Yeah, all kinds of issues, but if we created a new thing here in between WGLC and PS, the broader industry would never understand. Lars
emerging regions IETF/IRTF discussion list
Hi, On Apr 17, 2013, at 14:50, Eggert, Lars l...@netapp.com wrote: I've been talking to a few folks about whether there would be interest and energy for a new IRTF RG focusing on - for the lack of a better term - Internet challenges and solutions for emerging regions. Basically, a forum where we can discuss the challenges the Internet is facing in those regions, and share experiences and proposals to successfully address some of those challenges. ... I'd be thrilled to discuss this in more detail with interested folks. This list, however, is probably not the place for this. Contact me directly, and maybe I'll set up a separate list under irtf.org. I head the secretariat create a discussion list for Emerging Regions Internet Challenges And Solutions aka ERICAS. Subscribe at https://www.ietf.org/mailman/listinfo/ericas and email the list at eri...@ietf.org. Please feel free to invite everyone you feel should be involved in this discussion, IETF attendee or not! Also, while I'll be on the list and at least initially act as administrator in terms of whitelisting posts, etc., I do believe strongly that in order for this discussion/effort to be useful, it needs to be owned by and run by a group of people from those emerging regions. So I encourage everyone to step up and actively shape the discussion! Thanks, Lars
Re: emerging regions IETF/IRTF discussion list
CORRECTION: The list got created under irtf.org, i.e.: Subscribe at https://www.irtf.org/mailman/listinfo/ericas and email the list at eri...@irtf.org. Lars (The list creation message I got from the system said it was created under both the IETF and IRTF domains, but apparently not.) On Apr 23, 2013, at 10:40, Lars Eggert l...@netapp.com wrote: Hi, On Apr 17, 2013, at 14:50, Eggert, Lars l...@netapp.com wrote: I've been talking to a few folks about whether there would be interest and energy for a new IRTF RG focusing on - for the lack of a better term - Internet challenges and solutions for emerging regions. Basically, a forum where we can discuss the challenges the Internet is facing in those regions, and share experiences and proposals to successfully address some of those challenges. ... I'd be thrilled to discuss this in more detail with interested folks. This list, however, is probably not the place for this. Contact me directly, and maybe I'll set up a separate list under irtf.org. I head the secretariat create a discussion list for Emerging Regions Internet Challenges And Solutions aka ERICAS. Subscribe at https://www.ietf.org/mailman/listinfo/ericas and email the list at eri...@ietf.org. Please feel free to invite everyone you feel should be involved in this discussion, IETF attendee or not! Also, while I'll be on the list and at least initially act as administrator in terms of whitelisting posts, etc., I do believe strongly that in order for this discussion/effort to be useful, it needs to be owned by and run by a group of people from those emerging regions. So I encourage everyone to step up and actively shape the discussion! Thanks, Lars
Re: Mentoring
Hi, I sent the following proposal to Alissa yesterday after she spoke on the mike: What if we created an ietf-mentors list that all newcomers were auto-subscribed to. Those of us who want to mentor send a brief description of who they are and what they work on to the list, and the newcomers can approach those folks that sound like they would like to be mentored by. The mentor and newcomer meet at the meetgreet, and the mentors commit to actively trying to helping their mentorees along for at least that first meeting week. That doesn't quite solve the issue for very shy newcomers, but it would at least establish some sort of contact. Lars
Re: Mentoring
Hi, On Mar 14, 2013, at 16:26, Murray S. Kucherawy superu...@gmail.com wrote: I haven't observed that many newcomers at the newcomer meet-and-greet. They seem to be overwhelmed (numerically) by the ADs+chairs that go, which is reinforced by ADs+chairs using it as a taking-care-of-business opportunity as John observed. So, also along the much as I like free beer, maybe it should be just the ADs, unless the number of newcomers that go increases. if we do the newcomer-mentor-mailing-list-syncup proposal I described, you could restrict attendance to the beer to mentors that have been chosen by a mentoree... This may also widen the mentor pool. Lars
Gonca's ANRP talk is at 10:30
Probably of interest to RTG folks. Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [irtf-discuss] Applied Networking Research Prize 2013 presentation at IETF-86 Date: January 22, 2013 9:51:13 EST To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Reply-To: a...@irtf.org a...@irtf.org Hi, we are extremely pleased to report that for the 2013 award period of the Applied Networking Research Prize (ANRP), 36 eligible nominations were received. Each submission was reviewed by eight members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, four submissions will be awarded an ANRP in 2013. The first of these awards will happen at IETF-86 in Orlando, FL, USA. It goes to: *** Gonca Gürsun *** for defining a metric that allows an analysis of BGP routing policies: Gonca Gürsun, Natali Ruchansky, Evimaria Terzi and Mark Crovella. Routing State Distance: A Path-based Metric For Network Analysis. Proc. ACM IMC, Boston, MA, USA, Nov. 2012. http://cs-people.bu.edu/goncag/papers/imc12-rsd.pdf Gonca has been invited to present her findings in the IRTF Open Meeting during IETF-86, March 10-15, 2013 in Orlando, FL, USA. Join her there! The other three ANRP winners of 2013 will be announced before IETF-87 and IETF-88, respectively. The call for ANRP nominations for the 2014 awards cycle will open in the fall of 2013. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2013 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Yang Richard Yang, Yale Lixia Zhang, UCLA
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 12:43, t.p. daedu...@btconnect.com wrote: but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed I have seen too many WGs trying to build lightweight UDP-based application protocols that do not correctly back off under loss to agree with you here. It's solved IFF a standard transport like TCP is used. Not otherwise. (And even when TCP is used, questions like how many parallel connections remain.) Lars
Fwd: [e2e] Why do we need congestion control?
Begin forwarded message: From: Srinivasan Keshav kes...@uwaterloo.ca Subject: [e2e] Why do we need congestion control? Date: March 5, 2013 15:04:48 GMT+01:00 To: end2end-inter...@postel.org end2end-inter...@postel.org To answer this question, I put together some slides for a presentation at the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size a shared resource (such as a link or a router) smaller than the sum of peak demands. This can result in transient or persistent overloads, reducing user-perceived performance. Transient overloads are easily relieved by a buffer, but persistent overload requires reductions of source loads, which is the role of congestion control. Lacking congestion control, or worse, with an inappropriate response to a performance problem (such as by increasing the load), shared network resources are always overloaded leading to delays, losses, and eventually collapse, where every packet that is sent is a retransmission and no source makes progress. A more detailed description can also be found in chapter 1 of my PhD thesis [2]. Incidentally, the distributed optimization approach that Jon mentioned is described beautifully in [3]. hope this helps, keshav [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published as UC Berkeley TR-654, September 1991 http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf [3] Palomar, Daniel P., and Mung Chiang. A tutorial on decomposition methods for network utility maximization. Selected Areas in Communications, IEEE Journal on 24.8 (2006): 1439-1451. http://www.princeton.edu/~chiangm/decomptutorial.pdf
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 15:10, t.p. daedu...@btconnect.com wrote: The question is can we do with a Transport Area Director whose congestion control skills are limited; I am suggesting we can, because of all the work over the years in congestion control and the relative stability of the topic. Martin already mentioned RMCAT. And I mentioned Wgs wanting to build lightweight UDP-based protocols, which are hitting transport issues incl. congestion control all the time. See these slides (mostly done by Magnus) for some of those issues. We want someone on the IESG who is very familiar with them: http://eggert.org/talks/ietf73-wgchairs-training.pdf Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 4, 2013, at 23:44, Allison Mankin allison.man...@gmail.com wrote: Was there something causative about extracting RAI from Transport? a lot of thought went into making sure that the WGs that went on to form RAI formed a cohesive whole. In hindsight, we should have thought more about how cohesive the set of WGs was that ended up remaining in TSV. After the split, TSV consisted of an assortment of odd WGs without much of a shared identity. Moreover, all the WGs that had any sort of direct relation to product features were moved into RAI. (With the exception of storage, but they are their own little clique.) That severely limited the pool of AD candidates from industry, because it's difficult to construct a business case to one's management. That has been changing over the last year or two, with Google, Apple and others beginning some serious work on extending and enhancing transport protocols in an attempt to improve latencies. Unfortunately, the transport folks at such employers are probably to valuable internally to be able to volunteer. Finally, let's not forget that this year was a special case, because the incumbent was forced to pull out at a very late stage of the process. This left the community very little time to come up with alternatives. I believe that if that had happened earlier, we would have been able to deepen the pool. Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 3, 2013, at 21:14, Michael Richardson mcr+i...@sandelman.ca wrote: To be considered qualified the candidate needed to: a) have demonstrated subject matter expertise (congestion in this case) b) have demonstrated IETF management expertise (current/former WG chair) c) have time available Generally speaking, people who can not satisfy (c) do not show up on the list of nominees, as they have to decline the nomination. There definitely are many people who have (a) and (b), but not (c). Were money not an issue, filing this position would be easy. it's not money issue. There are basically two pools of qualified people for a TSV AD position that requires a CC background: academia and industry. Academia typically means folks on tenure track. Putting that on hold for 2-4 years - even if someone (e.g., ISOC) would pay for the involvement - is not going to happen. You'd be severely risking getting tenure. Even for someone that already is tenured, the time commitment is too high. There are qualified people in the industry, and that's where most of the past ADs have come from. In the last few years, it's been increasingly harder to get them to step forward, because their employers are reluctant to let them spend the time. I actually think that this is because employers realize that these skills are important and rare to find, and so you want these guys to work on internal things and not donate them to the IETF. Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote: I will say it again - the IETF is organized by us. Therefore, this situation is created by us. We have the power to fix it. We have to want to fix it. Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it. what is the fix? The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out. This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time. I don't see how we can maintain the quality of our output if we turn the AD position into a management job. Especially when technical expertise is delegated to bodies that rely on volunteers. Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, and it's also difficult to get them to stick to deadlines. They're volunteers, after all. And, as Joel said earlier, unless we delegate the right to raise and clear discusses to the directorates as well, the AD still needs to be able to understand and defend a technical argument on behalf of a reviewer. If there is a controversy, the time for that involvement dwarfs the time needed for the initial review. There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents... Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 4, 2013, at 15:57, John Leslie j...@jlc.net wrote: Eggert, Lars l...@netapp.com wrote: Especially when technical expertise is delegated to bodies that rely on volunteers. We're _all_ volunteers! right, but ADs are basically full-time volunteers of whom the community expects a certain timeliness in terms of their actions and decisions. If those actions are delegated to volunteer bodies that feel less strongly about timeliness, the community isn't going to be very happy with the delays, or the review quality is going down (because some don't happen). Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, How important is that, really? I feel it is important. If some IDs get discusses for a certain problems and others slide under the radar, that's not a great result. and it's also difficult to get them to stick to deadlines. They're volunteers, after all. I don't think we really believe in deadlines. Really? After all the scribing you've done, surely you know that almost all the IESG reviewing happens on very strict deadlines. Two weeks, and in rare cases a defer adds another two weeks. Reviews not in by that time come too late. It *is* a challenge to get directorate reviews to appear within that timeframe. When Magnus and me ran the TSV directorate, we tried to schedule directorate reviews during IETF LC, and still quite a number didn't arrive by the IESG telechat date. The General Area is the most obvious place where scaling has hit us: the IETF Chair has grown so far beyond full-time that something has to give. Russ, I believe, reads Gen-ART reviews, not the original documents, and points out areas that rise to DISCUSS level. He asks for text to address these issues, and tends to clear his DISCUSS once the issue is better understood. (I should perhaps note that today's IESG has made great progress in trusting each other to put significant concerns in RFC Editor notes instead of continuing to block documents.) I think SAAG is a better example. The general area has no technical focus area it's responsible for, and so the reviews are all over the place. (But they are still useful! More eyes help.) But even with the large amount of quality reviewing SAAG is doing, the expertise of the SEC ADs is still crucial. I wouldn't want to only rely on SAAG. If a management AD wanted to substitute directorate expertise for personal expertise, that particular directorate would as a whole need to operate under the timeliness, consistency and quality constraints that a technical expert AD would. I simply don't see that happening. Lars
Re: Appointment of a Transport Area Director
On Mar 4, 2013, at 16:42, Dale R. Worley wor...@ariadne.com wrote: One possibility might be to split TSV into two areas, so the workload on the TSV ADs (both technical and social) is reduced. Doesn't help much. Management of ones area takes some time, but at least as much time is spend on dealing with document review and discussions outside the area. Lars
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca wrote: The Transport Area has all of the groups that deal with transport protocols that need to do congestion control. Further, the (current) split of work means that all of the groups that need congestion oversight would be cared for by the position that is currently becoming empty as Wes leaves. Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.) Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot. Lars
Re: Appointment of a Transport Area Director
On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote: There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 3, 2013, at 15:35, Brian E Carpenter brian.e.carpen...@gmail.com wrote: What I'm getting at is that this line of argument doesn't scale. The only solution I see is to replace it by Several people on the Y Directorate need to understand X. only if the Y directorate reviews all IDs going through the IESG. Which in itself is a scaling issue. It may work for some topics, but things will fall through the cracks for various reasons. IMO congestion control is important and fundamental enough that the IESG itself needs to have the knowledge. YEs, I'm biased. Lars
Re: Appointment of a Transport Area Director
Hi, On Mar 3, 2013, at 13:56, Eric Burger ebur...@standardstrack.com wrote: The 50% time commitment is an IESG-imposed requirement. it isn't. The The IETF process (which the IESG cannot unilaterally change) requires an AD to manage his or her area, and review all documents going through the IESG. The later is typically what constitutes the bulk of the work, at least for the areas that aren't RAI or INT. If that is really the problem, we have had areas with more than two ADs. We could do that, but then we need to tell the NomCom that it's OK to pick people for the job who will focus on only one or a few aspects of the overall job description. Lars
Re: Appointment of a Transport Area Director
On Mar 3, 2013, at 18:42, Joel M. Halpern j...@joelhalpern.com wrote: Otherwise, the AD gets a directorate review calling out congestion problems. He puts in the discuss. And can not discuss it with the other ADs. It is not his discuss. He can not work out how to resolve it. Directorates are critical. I would hope tat all areas can move to a situation where finding the issues rests primarily with the directorates. But the AD has to have enough details in his area to deal with it. +1 Lars
Re: presenting vs discussion in WG meetings (was re:Remote Participation Services)
On Feb 16, 2013, at 9:04, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Why not have a poster session as part of Bits-n-Bites? It would give new ideas a chance to be seen without wasting WG time. Make it official enough that people can use it in their travel requests. Great idea! (Or do it during the welcome reception - bigger room.) Lars
Fwd: [irtf-discuss] Applied Networking Research Prize 2013 presentation at IETF-86
Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [irtf-discuss] Applied Networking Research Prize 2013 presentation at IETF-86 Date: January 22, 2013 15:51:13 GMT+01:00 To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Reply-To: a...@irtf.org a...@irtf.org Hi, we are extremely pleased to report that for the 2013 award period of the Applied Networking Research Prize (ANRP), 36 eligible nominations were received. Each submission was reviewed by eight members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, four submissions will be awarded an ANRP in 2013. The first of these awards will happen at IETF-86 in Orlando, FL, USA. It goes to: *** Gonca Gürsun *** for defining a metric that allows an analysis of BGP routing policies: Gonca Gürsun, Natali Ruchansky, Evimaria Terzi and Mark Crovella. Routing State Distance: A Path-based Metric For Network Analysis. Proc. ACM IMC, Boston, MA, USA, Nov. 2012. http://cs-people.bu.edu/goncag/papers/imc12-rsd.pdf Gonca has been invited to present her findings in the IRTF Open Meeting during IETF-86, March 10-15, 2013 in Orlando, FL, USA. Join her there! The other three ANRP winners of 2013 will be announced before IETF-87 and IETF-88, respectively. The call for ANRP nominations for the 2014 awards cycle will open in the fall of 2013. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2013 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Volker Hilt, Bell Labs Suresh Krishnan, Ericsson Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Yang Richard Yang, Yale Lixia Zhang, UCLA
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Hi, On Jan 14, 2013, at 10:08, Marc Petit-Huguenin petit...@acm.org wrote: I think that you underestimate the IETF community, who certainly know how to see through all the FUD about the GPL. Sure it may be a bad idea to literally copy 300 lines of GPL code in your code, but that does not apply to what we are talking about, which is reading code. I have worked for employers before where reading GPL code was considered highly problematic. Lars
Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG)
Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) Date: January 14, 2013 10:24:57 GMT+01:00 To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Cc: s...@irtf.org s...@irtf.org Reply-To: irtf-disc...@irtf.org irtf-disc...@irtf.org A new IRTF research group on Software-Defined Networking has been chartered: The Software-Defined Networking Research Group (SDNRG) investigates SDN from various perspectives with the goal of identifying the approaches that can be defined, deployed and used in the near term as well identifying future research challenges. In particular, key areas of interest include solution scalability, abstractions, and programming languages and paradigms particularly useful in the context of SDN. In addition, it is an explicit goal of the SDNRG to provide a forum for researchers to investigate key and interesting problems in the Software-Defined Networking field. Charter and participation information can be found at http://irtf.org/sdnrg Lars Eggert IRTF Chair
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
Full agreement with Stephan. Lars On Jan 11, 2013, at 22:02, Stephan Wenger st...@stewe.org wrote: Hi, Sorry for replying to this advise to secretariat thread and not to the ietf-announce thread--I'm not subscribed to ietf-announce. I have three comments, and regret that I have not followed all of the discussions regarding this draft before, so please advise if those comments have already been raised and/or resolved. First, I'm glad that the direct preferences of open source implementations over implementations compliant with other business models are mostly gone. Still, there is one reference that worries me, and that is the reference to GPLv3 code as an extreme in section 2.1. Yes, the GPL (and similar copyleft licenses) is an extreme, at least in terms of open source licensing models. However, it is not an extreme of openness or accessibility of the source code for review by WG chair, AD, and community. I would hope that we are all aware that many (most?) commercial software developers, by company policy or common sense, avoid looking at GPL-ed code, out of fear of contamination of their own closed source code. GPL-ed code is, therefore, inaccessible for verification by a large part of the IETF community, and does not serve as a good example for openness, which is how I interpret the spectrum laid out in section 2.1. A better example would be source code that is almost universally accessible. The extreme here would be source code in the public domain. Somewhat less convincing but perhaps a bit more realistically, source code under a BSD-style license like the one the IETF Trust is using. Second, the draft suggest that the existence of an implementation of the specification should serve as a shortcut towards RFC, presumably because such an implementation speak favorably to the implementability of the specification. That, however, is not universally true. Specifically, if implementer and spec writer are the same person (or part of the same team), it is quite likely that the spec takes certain assumptions made by the implementers for granted, and does not document it. That would be a bad spec, accessible implementation or not. The solution to this issue is IMO not, as the draft appears to be to suggest, to put burden on WG chairs and ADs to ensure that the spec and the implementation match. Both WG chairs and ADs have enough to do, and the incentive for rubber-stamping is quite high. A more sensible solution may be to require that the implementer is unaffiliated with the spec author; in other words, the implementation is derived from the spec + IETF discussion context. A third comment would be that, if you interpret the draft strictly, it is highly unlikely that the experiment would ever be exercised, as the implementation needs to match the draft to be advanced, and that would mean that the implementation has to follow in lockstep with the draft development up until the final version. With respect to the core subject matter of a draft, that may be fine. However, many of the final edits in a draft come as input from IETF wide community review; things like security, congestion control, and the like. Those are often trivial to write down, but can have a major implementation impact. To cure this, it would IMO be acceptable if the implementation would be required to match the latest or a reasonably young, i.e. a few months old version of the draft. Please consider this. Thanks, Stephan On 1.11.2013 08:21 , Adrian Farrel adr...@olddog.co.uk wrote: Hi Alexa, Please be aware of this document that has just entered a four-week IETF last call. The document describes a proposed IETF process experiment under the rules of RFC 3933. The proposed experiment calls on the IETF Secretariat to take specific actions under certain circumstances in corner cases of the experiment. Could you please have someone in the Secretariat look at the draft and comment on the practicalities of the actions. Note that, at this stage, no changes to the tools are proposed so any actions would require manual intervention (if the experiment were successful and resulted in permanent changes to IETF process we might make changes to the tools at some future time). Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 11 January 2013 15:15 To: IETF-Announce Subject: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by
Re: IESG Considering a Revision to NOTE WELL
On Nov 6, 2012, at 10:25, John Levine jo...@taugh.com wrote: Perhaps disclose that fact promptly. +1 Since not everyone is aware of what's going on in the IRTF: we recently made a minor modification to our IPR statement to that effect. See https://www.irtf.org/ipr One possibility would be that the IESG adopt what we did for the IRTF also for the IRTF... Lars smime.p7s Description: S/MIME cryptographic signature
Re: IESG Considering a Revision to NOTE WELL
Hi, On Nov 6, 2012, at 10:34, Fred Baker (fred) f...@cisco.com wrote: There is a point of disagreement between IRTF and IETF IPR Policy, or at least there appeared to be yesterday in ICCRG. http://tools.ietf.org/html/rfc3979#section-6.1.3 states that a person who knows that someone else has IPR on something is not required, but is encouraged, to make it known. The note well used in ICCRG yesterday said that someone that knew of IPR belonging to someone else was required to disclose it. I'm not sure what should be done about that, but the difference seems unhelpful. the IRTF statement is at https://www.irtf.org/ipr. For the case you mention, it says: Finally, the IRTF requests that you file an IPR disclosure with the IETF if you recognize IPR owned by others in any IRTF contribution. Requests does not mean required. Lars smime.p7s Description: S/MIME cryptographic signature
Re: IAOC Request for community feedback
On Oct 23, 2012, at 4:42, Barry Leiba barryle...@computer.org wrote: The IAOC is requesting feedback from the community whether it is reasonable to declare Marshall's IAOC position vacant. Yes. +1 Lars smime.p7s Description: S/MIME cryptographic signature
Re: Last Call: draft-gont-intarea-obsolete-eid-option-01.txt (Obsoleting the Endpoint Identifier (EID) Option) to Proposed Standard
On Oct 4, 2012, at 20:23, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Obsoleting the Endpoint Identifier (EID) Option' draft-gont-intarea-obsolete-eid-option-01.txt as Proposed Standard Have the original authors been contacted? Also, I see no reason why this RFC would need to be standards track. Lars smime.p7s Description: S/MIME cryptographic signature
Call for Nominations: Applied Networking Research Prize 2013
CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2013 http://irtf.org/anrp *** Submit nominations for the 2013 award period of the *** *** Applied Networking Research Prize until November 30, 2012! *** *** *** ***(Please share this announcement with your colleagues.)*** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2013/. In exceptional cases, nominations may also be submitted by email to a...@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: November 30, 2012 (hard) Notifications: December 20, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2013-flyer.pdf smime.p7s Description: S/MIME
Fwd: [irtf-discuss] Applied Networking Research Prize 2012 presentation s at IETF-85
Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [irtf-discuss] Applied Networking Research Prize 2012 presentation s at IETF-85 Date: September 3, 2012 11:38:33 GMT+02:00 To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Reply-To: a...@irtf.org a...@irtf.org Hi, we are extremely pleased to report that for the 2012 award period of the Applied Networking Research Prize (ANRP), 20 eligible nominations were received. Each submission was reviewed by 5-7 members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, three submissions were awarded an Applied Networking Research Prize in 2012. One of these submissions was already presenteded at IETF-84 in Vancouver, Canada. Two additional winning papers will be presented at IETF-85 in Atlanta, USA. The awards for IETF-85 go to: *** Srikanth Sundaresan *** for his measurement study of access link performance on home gateway devices: Srikanth Sundaresan, Walter de Donato, Nick Feamster, Renata Teixeira, Sam Crawford and Antonio Pescapè. Broadband Internet Performance: A View From the Gateway. Proc. ACM SIGCOMM,August 2011, Toronto, Canada. *** Peyman Kazemian *** for developing a general and protocol-agnostic framework for statically checking network specifications and configurations: Peyman Kazemian, George Varghese and Nick McKeown. Header Space Analysis: Static Checking For Networks. Proc. USENIX Symposium on Networked Systems Design and Implementation (NSDI), April 2012, San Jose, CA, USA. Srikanth and Peyman have been invited to present their findings in the IRTF Open Meeting during IETF-85, November 4-9, 2012 in Atlanta, GA, USA. Join them there! The call for ANRP nominations for the 2013 awards cycle will open in the fall of 2012. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2012 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Andrei Gurtov, HIIT Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Lixia Zhang, UCLA smime.p7s Description: S/MIME cryptographic signature
Re: [IAB] Last Call: Modern Global Standards Paradigm
On Aug 11, 2012, at 1:55, Bob Hinden bob.hin...@gmail.com wrote: I support the IETF and IAB chairs signing document. +1 (I'd even co-sign for the IRTF, but I think that isn't really appropriate in this case.) Lars smime.p7s Description: S/MIME cryptographic signature
Re: RFC and I-D Citation Tool
Hi, one suggestion: I-Ds must be cited as Work in Progress only. From the boilerplate text: Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference ^^^ material or to cite them other than as work in progress. ^^ I typically do it like this. Instead of: Alia Atlas, Cisco Systems, Dave Ward, Juniper Networks, and Thomas Nadeau, Interface to the Routing System Framework, July 2012, draft-ward-irs-framework-00. I use: Alia Atlas, Cisco Systems, Dave Ward, Juniper Networks, and Thomas Nadeau, Interface to the Routing System Framework, Internet-Draft draft-ward-irs-framework-00, Work in Progress, July 2012. Lars smime.p7s Description: S/MIME cryptographic signature
Re: [IAB] Draft Fees for Processing Legal Requests Policy
Looks good to me, but I agree with whoever suggested to increase the fees. I think you could easily double or triple them. On Aug 2, 2012, at 9:47, IETF Administrative Director i...@ietf.org wrote: A reminder of the deadline of 6 August for input. Thanks The IAOC is seeking community feedback on a proposed policy by the IAOC to impose fees to produce information and authenticate documents in response to subpoenas and other legal requests. The IETF receives requests for information, documentation, authentication or other matters through subpoenas and less formal means that require manpower and materials to be expended. These requests are on the rise. During the period 2005 to 2010 the IETF responded to nine subpoenas. Since 2011 the IETF has received five subpoenas and three other legal requests for authenticated documents. Each such request is time sensitive and involves the IETF Counsel, the IAD, and members of the IAOC, who together form the Legal Management Committee, to rapidly analyze and identify the means for satisfying the request. Often there is a need to retain outside counsel, especially in cases that might lead to depositions or court testimony. The IAOC believes a Schedule of Fees is an appropriate and reasonable means to recover costs associated with such efforts. The draft policy entitled Draft Fee Policy for Legal Requests can be found at: http://iaoc.ietf.org/policyandprocedures.html Before adopting a policy the IAOC would like feedback on this before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director smime.p7s Description: S/MIME cryptographic signature
Re: [IAB] Draft Fees for Processing Legal Requests Policy
On Aug 2, 2012, at 16:29, Steven Bellovin s...@cs.columbia.edu wrote: I don't think this can be a profit center; as I understand it, the judge in any case will rule on the reasonableness of any fees. Agreed. My intent is not to create a profit center. But I do also avoid this remaining a loss center for us. But I guess we don't need to discuss this here further. I'm sure the IAOC has taken note and will look into this. Lars smime.p7s Description: S/MIME cryptographic signature
Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt
Agreed. I suggest we stop discussing this proposal. On Aug 1, 2012, at 9:03, Barry Leiba barryle...@computer.org wrote: I written this draft starting a RFC2119 update for the reasons of discussion threads in [1] and [2]. Please check draft and feedback, thanking you. I agree with what Paul and Melinda have said. This document is pointless, as there is no actual problem that it's solving and no misunderstanding that it's clarifying. Further, it's actively *harmful*. It's arguable that 2119 already reserves too many words by giving them specific, normative meanings (SHALL *and* MUST; SHOULD *and* RECOMMENDED). Adding IF, THEN, and ELSE would not only be unnecessary, but downright *bad*. Barry smime.p7s Description: S/MIME cryptographic signature
Re: RFC and I-D Citation Tool
And for those of us who write academic papers, there is of course Roland's and Miguel's BibTex collections: http://tm.uka.de/~bless/bibrfcindex.html https://sites.google.com/site/ea1dof/bibtex Lars On Jul 31, 2012, at 11:16, Ole Jacobsen o...@cisco.com wrote: In The Internet Protocol Journal I have been using the following citation format, best illustrated by an example: Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou Berger, GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs), RFC 6387, September 2011. So, that's full author names and before the last author name, title, document number and date, using the American quotation outside punctuation rule. I got tired of doing this by hand so I asked Henrik if he could write me a tool. He did (THANKS!), and the result is here: http://tools.ietf.org/tools/citation/ This will take either the draft name or the RFC number as input and produce a citation similar to the one above. You can of course play with the elements and generate a format that suits your own taste, for example, for I-Ds, in print it might be good to have the FILE NAME as the last entry: Adam Langley, Serializing DNS Records with DNSSEC Authentication, Internet Draft, work in progress, July 2011, draft-agl-dane-serializechain-01 ...since I like having filenames or URLs on one line (not wrapping) as much as possible. Many thanks again to Henrik, and I hope you will find it useful too! Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo smime.p7s Description: S/MIME cryptographic signature
Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07
On Jul 3, 2012, at 14:24, Alexey Melnikov wrote: I found it is to be odd to have a requirements document as a BCP, but I am sure you can sort the right status out with IESG. +1 I fail to see why Informational wouldn't be the better status. Lars smime.p7s Description: S/MIME cryptographic signature
Re: Proposed Update to Note Well
Hi, having just gone through a similar exercise over on the IRTF side of things (see http://irtf.org/ipr), I wonder if what we came up with as a text couldn't be adapted to also work for the IETF: The IRTF follows the IETF Intellectual Property Rights (IPR) disclosure rules. This is a summary of these rules as they relate to IRTF research group discussions, mailing lists and Internet Drafts: • If you include your own or your employer’s IPR in a contribution to an IRTF research group, then you must file an IPR disclosure with the IETF. • If you recognize your own or your employer’s IPR in someone else’s contribution and you are participating in the discussions in the research group relating to that contribution, then you must file an IPR disclosure with the IETF. Even if you are not participating in the discussion, the IRTFstill requests that you file an IPR disclosure with the IETF. • Finally, the IRTF requests that you file an IPR disclosure with the IETF if you recognize IPR owned by others in any IRTF contribution. You may file an IPR disclosure here: http://www.ietf.org/ipr/file-disclosure See RFC 3979 (BCP 79) for definitions of “IPR” and “contribution” and for the detailed rules (substituting “IRTF” for “IETF”). Lars smime.p7s Description: S/MIME cryptographic signature
Fwd: [IRTF-Announce] Applied Networking Research Prize 2012 presentation at IETF-84
Begin forwarded message: From: Eggert, Lars l...@netapp.com Subject: [IRTF-Announce] Applied Networking Research Prize 2012 presentation at IETF-84 Date: June 5, 2012 16:10:58 GMT+02:00 To: irtf-annou...@irtf.org irtf-annou...@irtf.org, irtf-disc...@irtf.org irtf-disc...@irtf.org Reply-To: a...@irtf.org a...@irtf.org Hi, we are extremely pleased to report that for the 2012 award period of the Applied Networking Research Prize (ANRP), 20 eligible nominations were received. Each submission was reviewed by 5-7 members of the selection committee according to a diverse set of criteria, including scientific excellence and substance, timeliness, relevance, and potential impact on the Internet. Based on this review, three submissions were awarded an Applied Networking Research Prize in 2012. One of these submissions will be presented at IETF-84 in Vancouver, Canada, and two of them will be presented at IETF-85 in Atlanta, USA. The award for IETF-84 goes to: *** Alberto Dainotti *** for his research into Internet communication disruptions due to filtering: Alberto Dainotti, Claudio Squarcella, Emile Aben, K.C. Claffy, Marco Chiesa, Michele Russo and Antonio Pescapé. Analysis of Country-wide Internet Outages Caused by Censorship. Proc. ACM SIGCOMM/SIGMETRICS Internet Measurement Conference (IMC), November 2011, Berlin, Germany. Alberto has been invited to present his findings in the IRTF Open Meeting during IETF-84, July 29 - August 3, 2012 in Vancouver, Canada. Join him there! The other two prize winners of the 2012 ANRP will be announced before IETF-85 in Atlanta, USA. The call for ANRP nominations for the 2013 awards cycle will open in the fall of 2012. Read more about the ANRP at http://irtf.org/anrp. Please subscribe to the IRTF-Announce mailing list in order to receive future calls for ANRP nominations and join ISOC to stay informed of other networking research initiatives: http://irtf.org/mailman/listinfo/irtf-announce http://isoc.org/join Regards, Lars Eggert, IRTF Chairhttp://irtf.org/anrp Mat Ford, Internet Society http://isoc.org/research -- 2012 ANRP Selection Committee Mark Allman, ICIR Marcelo Bagnulo, UC3M Lou Berger, LabN Olivier Bonaventure, UCL Louvain Ross Callon, Juniper Lars Eggert, NetApp Olivier Festor, INRIA Mat Ford, ISOC Lisandro Granville, UFRGS Andrei Gurtov, HIIT Dan Massey, Colorado State Al Morton, ATT Laboratories Jörg Ott, Aalto University Colin Perkins, University of Glasgow Stefano Previdi, Cisco Jürgen Schönwälder, Jacobs University Bremen Lixia Zhang, UCLA smime.p7s Description: S/MIME cryptographic signature
Re: Mailing list for IETF women
Also related: http://cms.comsoc.org/eprise/main/SiteGen/n2women/Content/Home.html There is a meeting at least once a year at SIGCOMM. Lars On May 2, 2012, at 12:08, Mary Barnes wrote: There have been some offline discussions as to how we can improve the situation and encourage the participation of women in the IETF. One of the things was a mailing list. There actually already is one hosted on ietf.org (setup by Mirjam and Margaret) -syst...@ietf.org: https://www.ietf.org/mailman/listinfo/systers In the past, lunches have been organized. So, I do encourage the women to join the list if you aren't already a member. Regards, Mary. smime.p7s Description: S/MIME cryptographic signature
IRTF IPR Disclosure Rules
Until now, the IRTF didn't have a clearly formulated statement of how IPR is handled by the organization. For the last year, the IRSG has been discussing this topic with the IETF's legal counsel and other community members with a deep understanding of the issues. The result of this discussion is a short statement describing the IRTF's IPR disclosure rules, which you can find below as well as online at http://irtf.org/ipr. The short version is: the IRTF follows the IETF's IPR disclosure rules. Because researchers participating in the IRTF may not be very familiar with the IETF's rules, the IRTF IPR disclosure rules describe what is required of the individual participant in the most common cases. Just as the IETF, the IRTF expects participants to be familiar with these rules and follow them when they make contributions. Please email any comments or questions to irtf-disc...@irtf.org. Lars Eggert IRTF Chair --- IRTF IPR Disclosure Rules The IRTF follows the IETF IPR disclosure rules. This is a summary of these rules as they relate to IRTF research group discussions, mailing lists and Internet Drafts: - If you include your own or your employer's IPR in a contribution to an IRTF research group, then you must file an IPR disclosure with the IETF. - If you recognize your own or your employer's IPR in someone else's contribution and you are participating in the discussions in the research group relating to that contribution, then you must file an IPR disclosure with the IETF. Even if you are not participating in the discussion, the IRTF still requests that you file an IPR disclosure with the IETF. - Finally, the IRTF requests that you file an IPR disclosure with the IETF if you recognize IPR owned by others in any IRTF contribution. You may file an IPR disclosure here: http://www.ietf.org/ipr/file-disclosure See RFC 3979 (BCP 79) for definitions of IPR and contribution and for the detailed rules (substituting IRTF for IETF). smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [IP] EFF calls for signatures from Internet Engineers against censorship
Begin forwarded message: From: Dave Farber d...@farber.net Subject: [IP] EFF calls for signatures from Internet Engineers against censorship Date: December 14, 2011 4:12:20 GMT+02:00 To: ip i...@listbox.com Reply-To: d...@farber.net -- Forwarded message -- From: Peter Eckersley Date: Tuesday, December 13, 2011 Subject: EFF call for signatures from Internet Engineers against censorship To: David Farber d...@farber.net (For the IP list) Last year, EFF organized an open letter against Internet censorship legislation being considered by the US Senate (https://eff.org/deeplinks/2010/09/open-letter). Along with other activists efforts, we successfully delayed that proposal, but need to update the letter for two bills, SOPA and PIPA, that are close to passing through US Congress now. If you would like to sign, please email me at p...@eff.org, with a one-line summary of what part of the Internet you helped to helped to design, implement, debug or run. We need signatures by 8am GMT on Thursday (midnight Wednesday US Pacific, 3am US Eastern). Also feel free to forward this to colleagues who played a role in designing and building the network. The updated letter's text is below: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. Last year, many of us wrote to you and your colleagues to warn about the proposed COICA copyright and censorship legislation. Today, we are writing again to reiterate our concerns about the SOPA and PIPA derivatives of last year's bill, that are under consideration in the House and Senate. In many respects, these proposals are worse than the one we were alarmed to read last year. If enacted, either of these bills will create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. Regardless of recent amendments to SOPA, both bills will risk fragmenting the Internet's global domain name system (DNS) and have other capricious technical consequences. In exchange for this, such legislation would engender censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' right and ability to communicate and express themselves online. All censorship schemes impact speech beyond the category they were intended to restrict, but these bills are particularly egregious in that regard because they cause entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under these proposals. In fact, it seems that this has already begun to happen under the nascent DHS/ICE seizures program. Censorship of Internet infrastructure will inevitably cause network errors and security problems. This is true in China, Iran and other countries that censor the network today; it will be just as true of American censorship. It is also true regardless of whether censorship is implemented via the DNS, proxies, firewalls, or any other method. Types of network errors and insecurity that we wrestle with today will become more widespread, and will affect sites other than those blacklisted by the American government. The current bills -- SOPA explicitly and PIPA implicitly -- also threaten engineers who build Internet systems or offer services that are not readily and automatically compliant with censorship actions by the U.S. government. When we designed the Internet the first time, our priorities were reliability, robustness and minimizing central points of failure or control. We are alarmed that Congress is so close to mandating censorship-compliance as a design requirement for new Internet innovations. This can only damage the security of the network, and give authoritarian governments more power over what their citizens can read and publish. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We cannot have a free and open Internet unless its naming and routing systems sit above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US begins to use its central in the network for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, Congressmen, we believe the Internet is too important and too
