RE: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible AuthenticationProtocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA')) to Informational RFC

2008-10-16 Thread Joseph Salowey (jsalowey)
Hi Jari, -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 2:24 AM To: Joseph Salowey (jsalowey) Cc: Pasi Eronen; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible

Re: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible AuthenticationProtocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA')) to Informational RFC

2008-10-16 Thread Jari Arkko
Joe, First, after some discussion with some of the users of this spec from 3GPP, we have decided that AT_KDF=1 or the AKA fallback mode should be removed. AT_KDF_INPUT field values would indeed be dependent on which KDF is used. I will make the second change you suggested to fix this. On

Workshop on ROADM, Part of Globecom 2008

2008-10-16 Thread IWONT 2008
*Register before October 30 and take advantage of reduced registration rate * *The Ninth International Workshop on Optical Networking Technologies (IWONT) * *ROADMs: Components, Systems, and Networks* *Sunday, November 30, 2008, 2:00-5:00 pm** * ** *(Part of Globecom 2008, New Orleans , USA

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

2008-10-16 Thread Laird Popkin
I agree that (a) is where ALTO should focus. To elaborate a bit, (a) can only be provided by the ISP by definition (nobody else really knows the ISP's network and business policies), while (b) and (c) are, if I understand you correctly, both currently being done using internal communications

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

2008-10-16 Thread Das, Saumitra
Citing one of the responses from Vijay on Oct 13 For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely

BCP 142, RFC 5382 on NAT Behavioral Requirements for TCP

2008-10-16 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. BCP 142 RFC 5382 Title: NAT Behavioral Requirements for TCP Author: S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh

Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to Proposed Standard

2008-10-16 Thread The IESG
The IESG has received a request from an individual submitter to consider the following document: - 'IMAP METADATA Extension ' draft-daboo-imap-annotatemore-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.