Do you want to know what it is?
Hi Jose, As I would like to know what it is I watched http://www.youtube.com/watch?v=QAnW9HTkbsI It was a pleasant surprise to see a new approach instead of the usual boring presentations. People who are old might feel left out though. :-) Here a quote from Jack Haverty: If you always win, it means you're not taking enough risks. The IETF might say that it does not scale [1]. Who am I to prove that the IETF is wrong? :-) Regards, -sm 1. People who are old will actually understand the quote.
Re: Do you want to know what it is?
As I would like to know what it is I watched http://www.youtube.com/watch?v=QAnW9HTkbsI It was a pleasant surprise to see a new approach instead of the usual boring presentations. Very nice indeed. Thanks for doing it! (There's also http://www.youtube.com/watch?v=_G96ULX7Iak) Jari
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
Hi, Whatever the information is used for, or not used for, I think it would be useful to know the number of remote participants, and where they are located. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -Original Message- From: SM [s...@resistor.net] To: Christer Holmberg [christer.holmb...@ericsson.com] CC: John C Klensin [john-i...@jck.com]; ietf@ietf.org [ietf@ietf.org] Subject: Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception Hi Christer, At 13:54 24-07-2013, Christer Holmberg wrote: Why couldn't remote participants register to the meeting like all other participants? Remote participation would of course still be free, but it would allow remote participants to subscribe to the attendee list in the same way as other participants. A quick scan of that list shows the following topics: - coffee, sims - mailing list for IETF women and the following comment: I'm not sure why I should be required to give my contact information to get a document prepared by the Brussels airport for Brussels passengers. In addition, it would provide better knowledge to IETF about the number of remote participants, where they are physically located (which might be useful input when planning future meeting locations) etc. I doubt that the IETF chooses its meeting location based on where the remote participants are located. I'll go off-topic first. Mr Reschke once asked I was just trying to understand *why* the archive can't be at http://www.ietf.org/tao/archive. Mr Housley replied that I was told that we cannot have http://www.ietf.org/tao directed to the document and also be the directory containing the archive directory. Mr Hansen provided some technical details about how that can be done. The point here is it might be better to have a good answer as some IETF participant might deconstruct the answer and find the flaw in it. Mr Klensin's message was about how to find out about the 87all mailing list. Participants within the inner circle know how to find it. The rest of the participants will not be able to find that information as it is not easily accessible through the www.ietf.orghttp://www.ietf.org web site. There is probably a lack of information about what information is provided through the ietf-announce@ mailing list. Regards, -sm
Re: [Emu] Last Call: draft-ietf-emu-eap-tunnel-method-07.txt (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard
Section 3.2 of draft-wierenga-ietf-eduroam describes the issues presented by EAP's spartan support for error condition handling. Although these are described in the context of a particular roaming operator's experiences, I believe this is also likely to be true for other non-trivial deployments. To its credit this document (draft-ietf-emu-eap-tunnel-method) does address error handling more comprehensively than previous EAP methods, but I am not confident that it will yield error handling outcomes that could be understood and corrected by an end user. For example, from my understanding of the document, the most common failure modes (e.g., incorrect password; account locked; backend database offline, etc) will all yield an Inner_Method_Error. The other error messages are equally vague (General_PKI_Error) or cryptic from an end user's perspective. Is this something that could be discussed in Berlin next week? Josh. On 16/07/2013 15:19, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Tunnel EAP Method (TEAP) Version 1' draft-ietf-emu-eap-tunnel-method-07.txt as Proposed Standard 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 2013-07-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1902/ ___ Emu mailing list e...@ietf.org https://www.ietf.org/mailman/listinfo/emu Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
On 25/07/13 05:27, Moriarty, Kathleen wrote: I like Aaron's suggestion to update the web with important information about a meeting. There is a lot of mail on the list and that could be a useful way to communicate updates, etc. Thanks, in case the previous mail is down in the pile already... One thing that may also benefit both Remote and Meeting participants: An anchor point to distribute live update about IETF week, e.g., schedule change, latest bits-n-bytes info, WG/BoF agenda changes/slides uploaded(with embedded link), highlight/awards at plenary, emergent notice for facility issues/weather/traffic/hotel stealing... Most of those could be found if digging hard enough from hundreds of mails during IETF week, but a quick link definitely helps. It can be a live update bullet on the front page of IETF meeting http://www.ietf.org/meeting/87/ Cheers, Aaron Best regards, Kathleen Sent from my iPhone On Jul 25, 2013, at 12:12 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 25/07/2013 11:27, Scott Brim wrote: Brian: yes but non-registered thus non-ifentifiable subscribers, spammers etc don't. We're talking about a list with a useful lifetime of perhaps 3 weeks. I really don't think spam is a big issue. Trolls might be, but they would be *our* trolls ;-) Anyway - as John Klensin said, we should come up with a reasonably complete and welcoming set of info and facilities for the remotes. That may well include pro forma registration. Brian On Jul 24, 2013 3:56 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 25/07/2013 05:01, Scott Brim wrote: The point of having a separate list for participants was to avoid spamming the ietf list. It can be open to everyone to subscribe to, since anyone can see the archives, HOWEVER I recommend that only registered participants be allowed to post. Ahem. Either remote participants are allowed to post, or they need a list of their own. I would envisage a fair amount of chatter about specific remote-participation issues, like this new codec isn't working for me, is it OK for anyone else using browser version on operating system version? Brian
Re: [Emu] Last Call: draft-ietf-emu-eap-tunnel-method-07.txt (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard
Yes, this document is the main thing on the agenda. On Jul 25, 2013, at 6:26 AM, Josh Howlett josh.howl...@ja.net wrote: Section 3.2 of draft-wierenga-ietf-eduroam describes the issues presented by EAP's spartan support for error condition handling. Although these are described in the context of a particular roaming operator's experiences, I believe this is also likely to be true for other non-trivial deployments. To its credit this document (draft-ietf-emu-eap-tunnel-method) does address error handling more comprehensively than previous EAP methods, but I am not confident that it will yield error handling outcomes that could be understood and corrected by an end user. For example, from my understanding of the document, the most common failure modes (e.g., incorrect password; account locked; backend database offline, etc) will all yield an Inner_Method_Error. The other error messages are equally vague (General_PKI_Error) or cryptic from an end user's perspective. Is this something that could be discussed in Berlin next week? Josh. On 16/07/2013 15:19, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Tunnel EAP Method (TEAP) Version 1' draft-ietf-emu-eap-tunnel-method-07.txt as Proposed Standard 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 2013-07-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1902/ ___ Emu mailing list e...@ietf.org https://www.ietf.org/mailman/listinfo/emu Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 ___ Emu mailing list e...@ietf.org https://www.ietf.org/mailman/listinfo/emu
IEEE Internet Award winner: Jon Crowcroft
Some people here will remember that Jon was an IETF participant and an IAB member a number of years ago. Brian 2014 IEEE Technical Field Award Recipients and Citations IEEE INTERNET AWARD-recognizes exceptional contributions to the advancement of Internet technology for network architecture, mobility, and/or end-use applications-sponsored by Nokia Corporation-to JON CROWCROFT (FIEEE)-Professor, University of Cambridge, Cambridge, United Kingdom For contributions to research in and teaching of Internet protocols, including multicast, transport, quality of service, security, mobility, and opportunistic networking. (from http://www.ieee.org/about/awards/news/2014_ieee_tfa_recipients_and_citations_list.pdf)
Re: IEEE Internet Award winner: Jon Crowcroft
On Thu, Jul 25, 2013 at 1:16 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Some people here will remember that Jon was an IETF participant and an IAB member a number of years ago. Well deserved. Congrats Jon! --dmm Brian 2014 IEEE Technical Field Award Recipients and Citations IEEE INTERNET AWARD-recognizes exceptional contributions to the advancement of Internet technology for network architecture, mobility, and/or end-use applications-sponsored by Nokia Corporation-to JON CROWCROFT (FIEEE)-Professor, University of Cambridge, Cambridge, United Kingdom For contributions to research in and teaching of Internet protocols, including multicast, transport, quality of service, security, mobility, and opportunistic networking. (from http://www.ieee.org/about/awards/news/2014_ieee_tfa_recipients_and_citations_list.pdf)
Weekly posting summary for ietf@ietf.org
Total of 109 messages in the last 7 days. script run at: Fri Jul 26 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 13.76% | 15 | 21.67% | 210921 | aal...@blackberry.com 9.17% | 10 | 12.47% | 121366 | tb...@textuality.com 8.26% |9 | 5.89% |57325 | john-i...@jck.com 5.50% |6 | 4.62% |44943 | sm+i...@elandsys.com 5.50% |6 | 3.65% |35534 | jari.ar...@piuha.net 4.59% |5 | 3.33% |32388 | scott.b...@gmail.com 3.67% |4 | 2.80% |27207 | brian.e.carpen...@gmail.com 3.67% |4 | 2.55% |24814 | stephen.farr...@cs.tcd.ie 2.75% |3 | 2.30% |22369 | s...@resistor.net 2.75% |3 | 1.93% |18799 | martin.thom...@gmail.com 1.83% |2 | 2.54% |24758 | christer.holmb...@ericsson.com 0.92% |1 | 3.11% |30309 | kewi...@gmail.com 1.83% |2 | 1.92% |18643 | nar...@us.ibm.com 1.83% |2 | 1.89% |18402 | yd...@cs.helsinki.fi 1.83% |2 | 1.53% |14864 | hous...@vigilsec.com 1.83% |2 | 1.48% |14368 | barryle...@computer.org 1.83% |2 | 1.34% |13036 | melinda.sh...@gmail.com 1.83% |2 | 1.09% |10638 | do...@dougbarton.us 1.83% |2 | 1.08% |10477 | ra...@psg.com 0.92% |1 | 1.35% |13094 | stefan.win...@restena.lu 0.92% |1 | 1.24% |12041 | f...@cisco.com 0.92% |1 | 1.20% |11680 | b...@nostrum.com 0.92% |1 | 1.11% |10772 | david.bl...@emc.com 0.92% |1 | 1.01% | 9859 | jgu...@csc.com 0.92% |1 | 1.01% | 9791 | flu...@cisco.com 0.92% |1 | 1.01% | 9790 | ted.i...@gmail.com 0.92% |1 | 0.99% | 9631 | d3e...@gmail.com 0.92% |1 | 0.97% | 9427 | ch...@ietf.org 0.92% |1 | 0.94% | 9194 | jsalo...@cisco.com 0.92% |1 | 0.92% | 8995 | hsan...@isdg.net 0.92% |1 | 0.86% | 8343 | presn...@qti.qualcomm.com 0.92% |1 | 0.82% | 7966 | eric.g...@ericsson.com 0.92% |1 | 0.82% | 7933 | josh.howl...@ja.net 0.92% |1 | 0.80% | 7752 | t...@ecs.soton.ac.uk 0.92% |1 | 0.79% | 7722 | kathleen.moria...@emc.com 0.92% |1 | 0.78% | 7598 | br...@innovationslab.net 0.92% |1 | 0.72% | 7008 | ted.le...@nominum.com 0.92% |1 | 0.68% | 6631 | zehn@gmail.com 0.92% |1 | 0.68% | 6610 | joe...@bogus.com 0.92% |1 | 0.64% | 6216 | d...@1-4-5.net 0.92% |1 | 0.62% | 6060 | garbak...@gmail.com 0.92% |1 | 0.59% | 5790 | simon.perrea...@viagenie.ca 0.92% |1 | 0.59% | 5731 | a...@anvilwalrusden.com 0.92% |1 | 0.58% | 5663 | tterr...@xiph.org 0.92% |1 | 0.58% | 5617 | f...@isoc.org 0.92% |1 | 0.52% | 5085 | j...@jck.com +--++--+ 100.00% | 109 |100.00% | 973160 | Total
IETF 87 - Online Registration and Payment Cutoff
87th IETF Meeting Berlin, Germany July 28-August 2, 2013 Platinum Sponsor: DENIC Gold Sponsors: Deutsche Telekom and EURid Bronze Sponsor: Dyn Meeting venue: InterContinental Berlin: http://www.berlin.intercontinental.com/ Register online at: http://www.ietf.org/meetings/87/ Online Registration and Payment ends Friday, 26 July 2013, 1700 local Berlin time. On-site Registration starting Sunday, 28 July 2013 at 1100 local Berlin time. Only 3 days until the Berlin IETF!
RFC 6954 on Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
A new Request for Comments is now available in online RFC libraries. RFC 6954 Title: Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) Author: J. Merkle, M. Lochter Status: Informational Stream: IETF Date: July 2013 Mailbox:johannes.mer...@secunet.com, manfred.loch...@bsi.bund.de Pages: 11 Characters: 20366 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-merkle-ikev2-ke-brainpool-06.txt URL:http://www.rfc-editor.org/rfc/rfc6954.txt This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2). INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6989 on Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
A new Request for Comments is now available in online RFC libraries. RFC 6989 Title: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Author: Y. Sheffer, S. Fluhrer Status: Standards Track Stream: IETF Date: July 2013 Mailbox:yaronf.i...@gmail.com, sfluh...@cisco.com Pages: 10 Characters: 21099 Updates:RFC5996 I-D Tag:draft-ietf-ipsecme-dh-checks-05.txt URL:http://www.rfc-editor.org/rfc/rfc6989.txt This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
