From exim@www1.ietf.org Tue Sep 2 18:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13131 for ; Tue, 2 Sep 2003 18:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJST-0003ud-13 for seamoby-archive@odin.ietf.org; Tue, 02 Sep 2003 18:17:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82MH4Ll015035 for seamoby-archive@odin.ietf.org; Tue, 2 Sep 2003 18:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJSS-0003uH-Te for seamoby-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 18:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13065 for ; Tue, 2 Sep 2003 18:16:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJSQ-0001Ik-00 for seamoby-web-archive@ietf.org; Tue, 02 Sep 2003 18:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uJSO-0001Ia-00 for seamoby-web-archive@ietf.org; Tue, 02 Sep 2003 18:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJSP-0003s5-6W; Tue, 02 Sep 2003 18:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJRx-0003rZ-56 for seamoby@optimus.ietf.org; Tue, 02 Sep 2003 18:16:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13003 for ; Tue, 2 Sep 2003 18:16:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJRu-0001Hk-00 for seamoby@ietf.org; Tue, 02 Sep 2003 18:16:30 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19uJRt-0001Hh-00 for seamoby@ietf.org; Tue, 02 Sep 2003 18:16:29 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h82MGUe06808 for ; Tue, 2 Sep 2003 18:16:30 -0400 Date: Tue, 2 Sep 2003 18:16:29 -0400 (EDT) From: Eyal de Lara X-X-Sender: delara@puppet.cs To: seamoby@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] MobiCom 2003 additional hotel available Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Please excuse us if you get multiple copies of this announcement. ---------------------------------------------------------------------- MobiCom 2003 additional hotel available Rooms at the main hotel for MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, are now fully sold out on some nights of the conference, and we have arranged an additional nearby hotel to handle the overflow. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in San Diego, California. We have now arranged an additional block of rooms for MobiCom attendees at the same rate at the U.S. Grant, a Wyndham Historic Hotel, which is located one block from the Westin Horton Plaza. MobiCom is the premier international forum addressing research in all areas of mobile computing and wireless and mobile networking at the link layer and above. For more information on MobiCom 2003, including hotel details and details on how to register to attend, please see the MobiCom 2003 web pages at http://www.sigmobile.org/mobicom/2003/ We have a very strong program this year, including 27 technical papers describing the best of recent research in mobile computing and networking, plus exciting research demos, a panel discussion on security and privacy in mobile and wireless systems, a student poster session, and a conference dinner banquet cruise. MobiCom 2003 will also feature 2 invited talks: - Keynote Speaker: Dr. Paul J. Kolodzy, Director of the Wireless Network Security Center (WiNSeC) at Stevens Institute of Technology, and previously Senior Spectrum Policy Advisor and Director of the Spectrum Policy Task Force at the United States FCC, and Program Manager at DARPA. - Luncheon Speaker: Dr. Ian F. Akyildiz, Ken Byers Distinguished Chair Professor in Telecommunications, School of Electrical and Computer Engineering, Georgia Institute of Technology. Professor Akyildiz will speak on "InterPlaNetary Internet: State-of-the-Art and Research Challenges". The conference will also include 5 tutorials on the latest research areas and background topics in mobile computing and networking: - Secure Routing in Ad Hoc Networks - Public-Area Wireless Networks - Mobile Ad Hoc Networking - IP Mobility Support in a Mobile Internet - Topology Control in Wireless Ad Hoc Networks MobiCom will also have 6 full-day workshops on emerging topics related to mobile computing and networking: - DIALM-POMC 2003 Joint Workshop on Foundations of Mobile Computing - MobiDE 2003: The Third ACM International Workshop on Data Engineering for Wireless and Mobile Access - MSWiM 2003: The Sixth ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems - WiSe 2003: The Second ACM International Workshop on Wireless Security - WMASH 2003: The First ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots - WSNA 2003: The Second ACM International Workshop on Wireless Sensor Networks and Applications We look forward to seeing you in San Diego for MobiCom 2003! ---------------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 3 09:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00995 for ; Wed, 3 Sep 2003 09:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXKq-0007f9-Fb for seamoby-archive@odin.ietf.org; Wed, 03 Sep 2003 09:06:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83D68pa029448 for seamoby-archive@odin.ietf.org; Wed, 3 Sep 2003 09:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXKq-0007et-AE for seamoby-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 09:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00931 for ; Wed, 3 Sep 2003 09:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uXKo-0004Cw-00 for seamoby-web-archive@ietf.org; Wed, 03 Sep 2003 09:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uXKn-0004Ct-00 for seamoby-web-archive@ietf.org; Wed, 03 Sep 2003 09:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXKk-0007e2-7p; Wed, 03 Sep 2003 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXKJ-0007ax-22 for seamoby@optimus.ietf.org; Wed, 03 Sep 2003 09:05:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00883 for ; Wed, 3 Sep 2003 09:05:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uXKH-0004C4-00 for seamoby@ietf.org; Wed, 03 Sep 2003 09:05:33 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19uXKG-0004Ah-00 for seamoby@ietf.org; Wed, 03 Sep 2003 09:05:32 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h83D51Ck084448 for ; Wed, 3 Sep 2003 15:05:01 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0CE17B153F for ; Wed, 3 Sep 2003 14:38:24 +0200 (CEST) Message-ID: <3F55E6FC.9030401@ccrle.nec.de> Date: Wed, 03 Sep 2003 15:05:00 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD protocol issue tracker updated Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, the CARD protocol issue tracker has been updated. https://roundup.machshav.com/seamoby/index Many issues have been solved during and after last meeting. These have been marked as closed. For many other issues, the tracker indicates "proposed text", and refers to the latest update of the draft (version 03) to solicit comments from the WG. http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-03.txt Some issues are still open and, in particular the technical ones, need to be resolved asap. Hence, we'll bring them up on the list again one after the other. Comments? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Sep 4 07:30:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13106 for ; Thu, 4 Sep 2003 07:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usJS-0002d2-Oc for seamoby-archive@odin.ietf.org; Thu, 04 Sep 2003 07:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84BU6Hi010098 for seamoby-archive@odin.ietf.org; Thu, 4 Sep 2003 07:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usJS-0002cn-KQ for seamoby-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 07:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13077 for ; Thu, 4 Sep 2003 07:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19usJR-0002qM-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 07:30:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19usJR-0002qI-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 07:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usJP-0002bs-5w; Thu, 04 Sep 2003 07:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usIU-0002ai-RH for seamoby@optimus.ietf.org; Thu, 04 Sep 2003 07:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13020 for ; Thu, 4 Sep 2003 07:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19usIU-0002p6-00 for seamoby@ietf.org; Thu, 04 Sep 2003 07:29:06 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 19usIT-0002p2-00 for seamoby@ietf.org; Thu, 04 Sep 2003 07:29:05 -0400 Received: (qmail 30950 invoked for bounce); 4 Sep 2003 11:39:10 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 4 Sep 2003 11:39:10 -0000 Message-ID: <3F573E0C.5060103@clarinet.u-strasbg.fr> Date: Thu, 04 Sep 2003 22:28:44 +0900 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030727 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Question on link definition Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a question about the definition of "link" in draft-ietf-seamoby-mobility-terminology-04.txt It is said: "A communication facility or physical medium that can sustain data communications between multiple network nodes, such as an Ethernet (simple or bridged). A link is the layer immediately below IP." As I undestand, the definition of link is not directly related to an IPv6 link. For example, consider the following example: One ethernet link where a router advertises a single IPv6 prefix, and an 802.11b access point connected to this ethernet link as illustrated here: AR ____ |__________________ | | AP Fixed node MN2 MN1 In this situation, is it right to say that : - there are 2 links and - there is one IPv6 link ? Thanks Regards, Nicolas _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Sep 4 12:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05892 for ; Thu, 4 Sep 2003 12:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux0m-0003dT-VI for seamoby-archive@odin.ietf.org; Thu, 04 Sep 2003 12:31:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84GV77S013967 for seamoby-archive@odin.ietf.org; Thu, 4 Sep 2003 12:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux0k-0003cx-ON for seamoby-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 12:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05864 for ; Thu, 4 Sep 2003 12:30:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux0i-0007Gy-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 12:31:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ux0i-0007Gv-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 12:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux0f-0003c6-M7; Thu, 04 Sep 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux0P-0003Z4-Oa for seamoby@optimus.ietf.org; Thu, 04 Sep 2003 12:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05843 for ; Thu, 4 Sep 2003 12:30:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux0O-0007GZ-00 for seamoby@ietf.org; Thu, 04 Sep 2003 12:30:44 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19ux0N-0007GT-00 for seamoby@ietf.org; Thu, 04 Sep 2003 12:30:43 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h84GUCCk058303 for ; Thu, 4 Sep 2003 18:30:12 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B91FD33B97 for ; Thu, 4 Sep 2003 18:03:23 +0200 (CEST) Message-ID: <3F576893.80201@ccrle.nec.de> Date: Thu, 04 Sep 2003 18:30:11 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD issue#40: 8 bit CARD options length not enough Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Taking into account, that a 16-bit length indicator has been proposed for the capability AVP sub-option, the 8-bit length indicator of the CARD REQUEST and CARD REPLY option is not enough. To find an appropriate solution, we should take the following into consideration: 1. Do we need a 16-bit length indicator for AVPs? 2. Taking a policy to indicate CARD REQ/REPL length as (n*8bit)units won't solve the problem when keeping 16-bit for the AVPs. 3. Increase the length indicator of the CARD REQ/REPL to 16 or event 24 bit. Are there rules/requirements for TLV encoding with regard to the L-size? If yes, then we must meet them. Comments? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Sep 4 12:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06303 for ; Thu, 4 Sep 2003 12:40:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux9T-0004LI-EV for seamoby-archive@odin.ietf.org; Thu, 04 Sep 2003 12:40:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Ge7Bc016634 for seamoby-archive@odin.ietf.org; Thu, 4 Sep 2003 12:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux9R-0004IO-MT for seamoby-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 12:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06296 for ; Thu, 4 Sep 2003 12:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux9P-0007Qo-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 12:40:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ux9P-0007Ql-00 for seamoby-web-archive@ietf.org; Thu, 04 Sep 2003 12:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux9P-0004Gn-41; Thu, 04 Sep 2003 12:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux8j-0004Am-N1 for seamoby@optimus.ietf.org; Thu, 04 Sep 2003 12:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06265 for ; Thu, 4 Sep 2003 12:39:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux8i-0007QG-00 for seamoby@ietf.org; Thu, 04 Sep 2003 12:39:20 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19ux8h-0007Pv-00 for seamoby@ietf.org; Thu, 04 Sep 2003 12:39:19 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h84GcmCk058817 for ; Thu, 4 Sep 2003 18:38:48 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 43293618CD for ; Thu, 4 Sep 2003 18:12:00 +0200 (CEST) Message-ID: <3F576A97.3010200@ccrle.nec.de> Date: Thu, 04 Sep 2003 18:38:47 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD issue#30: L2 type indicators to be assiged by IANA Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A proposal for the L2-type indicator in the L2_ID parameter was to request type IDs for one or two L2-types for now. We could not find any appropriate value, which has been assigned by IANA for L2 types and which can be reused. Current L2-type indicator has a length of 8 bit. 1. Anybody has a pointer to assigned L2_ID types we can possibly reuse? 2. In case we request IANA for assignment of one or two types for now, we need to specify in the IANA section which types we would like to register. Any preferences or proposal from the WG? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Sep 12 09:56:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23345 for ; Fri, 12 Sep 2003 09:56:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoOg-0007vO-I9 for seamoby-archive@odin.ietf.org; Fri, 12 Sep 2003 09:55:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDtchC030452 for seamoby-archive@odin.ietf.org; Fri, 12 Sep 2003 09:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoOg-0007v3-Dn for seamoby-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 09:55:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23211 for ; Fri, 12 Sep 2003 09:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoO8-0007jP-BP; Fri, 12 Sep 2003 09:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoNm-0007hY-L9 for seamoby@optimus.ietf.org; Fri, 12 Sep 2003 09:54:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23135 for ; Fri, 12 Sep 2003 09:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xoNk-0006tM-00 for seamoby@ietf.org; Fri, 12 Sep 2003 09:54:40 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19xoNk-0006tJ-00 for seamoby@ietf.org; Fri, 12 Sep 2003 09:54:40 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 12 Sep 2003 16:54:38 +0300 Date: Fri, 12 Sep 2003 16:54:38 +0300 (EEST) From: Jukka MJ Manner To: Seamoby Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] No piggybacking in CTP? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, a quick question: Is it so that CARD messages can be piggybacked in other ICMP messages, but CTP messages can't, especially the CTAR message? This was suggested in draft-rjaya-ct-fmip6-l2st-ant-ho-00, but I don't remember seeing any debates about it. Regards, Jukka _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 11:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22894 for ; Tue, 16 Sep 2003 11:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI0n-0004kX-SS for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GFj5O9018254 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI0n-0004kL-Mn for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 11:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22879 for ; Tue, 16 Sep 2003 11:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI0m-0004b5-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zI0m-0004b1-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI0j-0004ja-WB; Tue, 16 Sep 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI0X-0004j8-0P for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 11:44:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22860 for ; Tue, 16 Sep 2003 11:44:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI0V-0004am-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:44:47 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zI0V-0004aj-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:44:47 -0400 Message-ID: <016a01c37c69$7e3cccf0$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 08:45:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 29: CTP spec needs an example Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At the Vienna IETF meeting, we discussed the need for some example of CTP in order to show readers (and the IESG in particular) what the benefits of CTP are for smoothing handover. Header compression was discussed but some technical issues were raised that may take a while to work through, so it seems like header compression might not be simple enough. While Rajeev is working through those issues, a simpler example that we could include in the CTP document would be useful so that we can advance the CTP document sooner. Multicast was suggested as an example. Below is text for an appendix to the CTP spec for an example involving MLD state CT. Note that this text is not meant to be normative, but might be usefully separated out into an actual protocol when and if CTP goes to PS. Comments? jak ==================================== Multicast Listener Context Transfer =================================== Introduction ------------ As an example of how context transfer can improve the performance of IP layer handover, we consider transferring IPv6 MLD state [1]. MLD state is a particularly good example because every IPv6 node must perform two MLD messaging sequences on the wireless link to establish itself as an MLD listener prior to performing router discovery [2] or duplicate address detection [3] or before sending/receiving any application-specific traffic (including Mobile IP handover signaling, if any). The node must subscribe to the All Nodes Multicast Address and the Solicited Node Multicast Address as soon as it comes up on the link. In addition, any application-specific multicast addresses must be re-established as well. Context transfer can significantly speed up re-establishing multicast state by allowing the nAR to initialize MLD for a node that just completed handover; without any MLD signaling on the new wireless link. The same approach could be used for transferring multicast context in IPv4. An approximate qualitative estimate for the amount of savings in handover time can be obtained as follows. MLD messages are 24 bytes, to which the IPv6 header, 40 bytes, and a required Routing Header Type 0, 24 bytes, must be added (because there will be no header compression on the new link), for a total MLD message size of 88 bytes per message per subscribed address. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages per address subscription, since the Report message is unacknowledged. Assuming 2 MLD messages sent per address subscription, the mobile node would need to send a total of 4 MLD messages for the two pre-router discovery multicast addresses (All Nodes Multicast Address and Solicited Node Multicast Address for the link local address). This gives a total of 176 bytes per subscribed address or 352 bytes over the wireless link for both the pre-router discovery multicast addresses. The amount of time saved will, of course, depend on the wireless link bandwidth, but some representative numbers can be obtained by assuming bandwidths of 20 kbps or 100 kbps. The former is approximate for a narrowband 3G cellular link and the latter for a moderately utilized 802.11b WLAN link, both running Voice over IP (VoIP). With these two bit rates, the savings from not having to perform the pre-router discovery messages are 140.8 msec. and 28.2 msec., respectively. If any application-specific multicast addresses were subscribed, the amount of time saved could be substantially more. Considering most ATM-based 3G voice cellular protocols try to keep total voice handover delay less than 40-80 msec., MLD signaling could have a large impact on the performance of inter-subnet VoIP handover. The Protocol ------------ The context-specific data field for MLD context transfer included in the CTP Context Data Block message for a single IPv6 multicast address has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix on nAR Wireless Interface + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Subscribed IPv6 Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Subnet Prefix on nAR Wireless Interface field contains a subnet prefix that identifies the interface on which multicast routing should be established. The Subscribed IPv6 Multicast Address field contains the multicast address for which multicast routing should be established. The pAR sends one MLD context block per subscribed IPv6 multicast address. Router MLD State Machine Interactions ------------------------------------- No changes are required in the MLD state machine for the routers. Upon receipt of a CTP Context Data Block for MLD, if the router is in the No Listeners Present state, it transitions to the Listeners Present state for the Subscribed IPv6 Multicast Address on the wireless interface specified by the Subnet Prefix on nAR Wireless Interface and starts its timer, as if it had received a Report message in the No Listeners Present state. If the router is in the Listeners Present state for the multicast address, it remains in that state but restarts the timer, as if it had received a Report message in that state. If more than one MLD router is on the link, a router receiving a MLD context data block SHOULD send a CTP Context Data Block for the Subscribed IPv6 Multicast Address and the Subnet Prefix on nAR Wireless Interface to other MLD routers on the link. A router receiving an MLD context data block MAY send a proxy MLD Report message instead, if wireless bandwidth is not an issue. Since MLD routers do not keep track of which nodes are listening to multicast addresses, only whether a particular multicast address is being listened to, proxying the subscription should cause no difficulty. [1] Deering, S., Fenner, W., and Haberman, B., " Multicast Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. [2] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December, 1998. [3] Thompson, S., and Narten, T., "IPv6 Address Autoconfiguration," RFC 2462, December, 1998. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 11:51:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23228 for ; Tue, 16 Sep 2003 11:51:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI6a-00051A-OS for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GFp4Nh019282 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI6a-00050v-JH for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 11:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23209 for ; Tue, 16 Sep 2003 11:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI6Z-0004gr-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zI6Z-0004go-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI6Z-0004yd-2p; Tue, 16 Sep 2003 11:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI69-0004xj-6Y for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 11:50:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23196 for ; Tue, 16 Sep 2003 11:50:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI68-0004gM-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:50:36 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zI67-0004gJ-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:50:35 -0400 Message-ID: <017e01c37c6a$4da98a00$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 08:50:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 15: CTAR Relay Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The specification does not adequately define CTAR relay. Possible resolutions are: 1) Add text to define CTAR relay. 2) Drop CTAR relay. Suggested resolution: 2 Justification: Motivation for this function is not clear, simplifying the protocol at this point is likely to make it easier for people to understand and thus implement. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 11:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23432 for ; Tue, 16 Sep 2003 11:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI9S-0005C6-U6 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GFs2He019959 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI9S-0005Bq-PO for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 11:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23393 for ; Tue, 16 Sep 2003 11:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI9R-0004js-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:54:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zI9R-0004jp-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI9R-000578-Jd; Tue, 16 Sep 2003 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI90-00056f-Vh for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 11:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23340 for ; Tue, 16 Sep 2003 11:53:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI8z-0004j1-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:53:33 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zI8z-0004iy-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:53:33 -0400 Message-ID: <019001c37c6a$b768eb70$956015ac@dclkempt40> From: "James Kempf" To: "James Kempf" , References: <017e01c37c6a$4da98a00$956015ac@dclkempt40> Subject: Re: [Seamoby] CTP Issue 15: CTAR Relay Date: Tue, 16 Sep 2003 08:53:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for this post, the CTAR issue has been closed already. I'm still getting used to the issues page format. jak ----- Original Message ----- From: "James Kempf" To: Sent: Tuesday, September 16, 2003 8:50 AM Subject: [Seamoby] CTP Issue 15: CTAR Relay > The specification does not adequately define CTAR relay. Possible > resolutions are: > > 1) Add text to define CTAR relay. > > 2) Drop CTAR relay. > > Suggested resolution: 2 > Justification: Motivation for this function is not clear, simplifying the > protocol at this point is likely to make it easier for people to understand > and thus implement. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 11:59:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23737 for ; Tue, 16 Sep 2003 11:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIEJ-0005Hp-Oa for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:59:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GFx3vP020315 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 11:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIEJ-0005Ha-KI for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 11:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23688 for ; Tue, 16 Sep 2003 11:58:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zIEI-0004rU-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zIEI-0004rR-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 11:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIEH-0005Gj-Jb; Tue, 16 Sep 2003 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIDc-0005G8-AB for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 11:58:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23661 for ; Tue, 16 Sep 2003 11:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zIDb-0004qG-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:58:19 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zIDa-0004qD-00 for seamoby@ietf.org; Tue, 16 Sep 2003 11:58:18 -0400 Message-ID: <019801c37c6b$61cee600$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 08:58:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Issue 20: How to identify MNs with private addresses Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Summary: CTP utilizes the MN's previous IP address to uniquely identify the MN. If the previous IP address was behind a separate NAT, then there could be a conflict. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue20 for a detailed description. Possible resolutions: 1) Use something other than the previous IP address to identify the MN. 2) Clarify how CTP interacts with NATs. 3) Keep the current text, note in the text that additional work is required before CTP will work with nonglobal scope addresses. Suggsted resolution: 3 Justification: Figuring out how CTP works with NATs is likely to be difficult and time consuming (ex. the Mobile IPv4/NAT interaction), and might even require a separate document. The spec should be kept simple until there is compelling deployment justification. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:14:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27501 for ; Tue, 16 Sep 2003 13:14:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJOy-0007xz-W9 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:14:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHE8Pb030617 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJOy-0007xk-LH for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27494 for ; Tue, 16 Sep 2003 13:14:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJOw-0006E5-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:14:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJOw-0006E2-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJOr-0007wu-Fa; Tue, 16 Sep 2003 13:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJO7-0007wM-IC for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27474 for ; Tue, 16 Sep 2003 13:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJO5-0006Cy-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:13:13 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJO4-0006Cu-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:13:13 -0400 Message-ID: <01e101c37c75$d89ef5e0$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:13:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Issue 17: Clarifying text needed on deployment restrictions Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Issue 17 suggests that clarifying text should be added to the draft about deployment restrictions, specifically that CT within one ISP is the intended deployment model. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue17 for a detailed description. Possible resolutions: 1) Add such text. 2) Don't add any text on deployment. Suggested resolution: Don't add any text on deployment. Justification: Since this is an experimental draft, the exact deployment scenerios are not clear yet, so such text would not be appropriate. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:23:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27844 for ; Tue, 16 Sep 2003 13:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJXb-0008EH-7l for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:23:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHN3MS031627 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJXb-0008E2-3S for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27814 for ; Tue, 16 Sep 2003 13:22:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJXZ-0006KR-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:23:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJXY-0006KO-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJXZ-0008DE-IF; Tue, 16 Sep 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJXA-0008Cg-K0 for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:22:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27781 for ; Tue, 16 Sep 2003 13:22:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJX8-0006Je-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:22:34 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJX7-0006JU-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:22:33 -0400 Message-ID: <01f301c37c77$26c7da10$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:22:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 13 - Generic message header Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The text describing Issue 13 isn't quite clear to me, but I'm interpreting as follows: Section 2.4 of the spec defines a generic CTP header, but the subsections define specific headers that are different for specific messages. Which is correct? See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue13 for more details. Possible resolutions: 1) Modify the headers for specific messages to use the generic header. 2) Drop the generic header. Suggested resolution: Drop the generic header. Justification: The fact that the individual messages have their own headers suggests they need different information in the header. The simplest course therefore seems to drop the generic header. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28104 for ; Tue, 16 Sep 2003 13:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJaZ-0008PL-Di for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHQ7u6032313 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJaZ-0008P6-9i for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28048 for ; Tue, 16 Sep 2003 13:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJaV-0006Q3-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJaV-0006Q0-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJaV-0008Lz-UI; Tue, 16 Sep 2003 13:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJZl-0008KY-Ib for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28016 for ; Tue, 16 Sep 2003 13:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJZj-0006P4-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:25:15 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJZi-0006Ow-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:25:15 -0400 Message-ID: <01ff01c37c77$86e96120$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:25:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 12: Use of MN's new care-of address Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If MN's new care-of address is included in CTAR or CTD before it is assigned on the MN, nAR must defend new CoA (at least for IPv6 DAD) until MN claims it. Should this requirement be stated? Or can the new CoA only be used in CTAR or CTD if it is already assigned to the MN? If so, then it should be clearly stated. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue12 for details.Suggested resolution: Include text noting that the new AR must defend the address using proxy ARP/ND. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28751 for ; Tue, 16 Sep 2003 13:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJp3-0000qL-6f for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHf5aT003235 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJp3-0000q6-2N for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28730 for ; Tue, 16 Sep 2003 13:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJp0-0006eM-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJp0-0006eJ-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJoz-0000pO-NU; Tue, 16 Sep 2003 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJoY-0000oC-DC for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:40:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28664 for ; Tue, 16 Sep 2003 13:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJoW-0006e9-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:40:32 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJoV-0006e6-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:40:31 -0400 Message-ID: <020d01c37c79$a8ecbcc0$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:40:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Issue 22 suggests that 32 bits isn't enough for the authorization token. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for details. Possible resolutions: 1) Make the authorization token longer, say 64 bits. 2) Keep the authorization token at 32 bits. Suggested resolution: Make the authorization token longer, say 64 bits. Justification: The probability of a birthday attack is proportional to 2**(sqrt(n)), where n is the number of bits in the identifier. If n is 32, then sqrt(n) is 16, which is not enough protection (65536). Making n equal 64 means sqrt(n) is 32 (over 4 billion) which should be enough. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Tue, 16 Sep 2003 13:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJtt-0000y7-2m for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:46:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHk5Fw003716 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJts-0000xr-Ui for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28851 for ; Tue, 16 Sep 2003 13:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJtq-0006h0-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJtq-0006gx-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJtq-0000wx-4n; Tue, 16 Sep 2003 13:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJtR-0000wW-Al for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:45:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28843 for ; Tue, 16 Sep 2003 13:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJtP-0006go-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:45:35 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJtN-0006gl-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:45:34 -0400 Message-ID: <021a01c37c7a$5caa12d0$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:45:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit CTP currently doesn't specify how it interoperates with other handover protocols. A better integrated handover mechanism if CTP could be interoperate with other handover protocols. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue24 for details. Possible resolutions: 1) Text proposed in issue24 Web page. 2) Reject Suggested resolution: reject Justification: The protocol currently is designed to be standalone, which is sufficient for the experimental status. Further work on integrating CTP with other handover protocols should go on within the IRTF's new mobility research group. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 13:51:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28992 for ; Tue, 16 Sep 2003 13:51:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJyi-0001Df-TT for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHp4lU004681 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 13:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJyi-0001CP-9B for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 13:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28987 for ; Tue, 16 Sep 2003 13:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJyf-0006jY-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zJyf-0006jT-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 13:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJyg-000190-DX; Tue, 16 Sep 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJy4-00017z-FX for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 13:50:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28966 for ; Tue, 16 Sep 2003 13:50:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJy2-0006is-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:50:22 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zJy1-0006ip-00 for seamoby@ietf.org; Tue, 16 Sep 2003 13:50:21 -0400 Message-ID: <022001c37c7b$08e0aeb0$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 16 Sep 2003 10:50:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Issues Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I just posted a bunch of CTP issues to the mailing list for comment. These issues were culled from the Web page, and represent the technical issues for which no solution has yet been proposed. I did not post any editorial issues or technical issues for which text has been proposed or which have been resolved. Please send comments if you have any. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 15:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05198 for ; Tue, 16 Sep 2003 15:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLcM-0005CM-Jk for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 15:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJa6ES019978 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 15:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLcM-0005C9-Gd for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05153 for ; Tue, 16 Sep 2003 15:35:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLcL-0000WC-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 15:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zLcK-0000W9-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 15:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLcI-0005Ac-4z; Tue, 16 Sep 2003 15:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLbT-00059i-8A for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 15:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05099 for ; Tue, 16 Sep 2003 15:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLbQ-0000V2-00 for seamoby@ietf.org; Tue, 16 Sep 2003 15:35:08 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19zLbP-0000Uq-00 for seamoby@ietf.org; Tue, 16 Sep 2003 15:35:07 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8GJYZg22846; Tue, 16 Sep 2003 12:34:35 -0700 X-mProtect: <200309161934> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.214, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJdnIib; Tue, 16 Sep 2003 12:34:32 PDT Message-ID: <3F6765B9.5080103@iprg.nokia.com> Date: Tue, 16 Sep 2003 12:34:17 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits References: <020d01c37c79$a8ecbcc0$956015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello James, I don't think it is needed, for two reasons: - The authorization token is only going to be used once - The data being protected is only good for a few hundred milliseconds at most (typically). Regards, Charlie P. James Kempf wrote: >Issue 22 suggests that 32 bits isn't enough for the authorization token. > >See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for details. > >Possible resolutions: > >1) Make the authorization token longer, say 64 bits. >2) Keep the authorization token at 32 bits. > >Suggested resolution: Make the authorization token longer, say 64 bits. >Justification: The probability of a birthday attack is proportional to >2**(sqrt(n)), where n is the number of bits in the identifier. If n is 32, >then sqrt(n) is 16, which is not enough protection (65536). Making n equal >64 means sqrt(n) is 32 (over 4 billion) which should be enough. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 16:00:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08446 for ; Tue, 16 Sep 2003 16:00:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLzC-0006MU-6R for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 15:59:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJxg4m024454 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 15:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLzB-0006ML-Vh for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:59:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08394 for ; Tue, 16 Sep 2003 15:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLyZ-0006Gf-I5; Tue, 16 Sep 2003 15:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLyK-0006ED-2B for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 15:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08256 for ; Tue, 16 Sep 2003 15:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLyI-0001Ip-00 for seamoby@ietf.org; Tue, 16 Sep 2003 15:58:46 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zLyH-0001Ib-00 for seamoby@ietf.org; Tue, 16 Sep 2003 15:58:46 -0400 Message-ID: <029201c37c8c$f5b54870$956015ac@dclkempt40> From: "James Kempf" To: "Charlie Perkins" Cc: References: <020d01c37c79$a8ecbcc0$956015ac@dclkempt40> <3F6765B9.5080103@iprg.nokia.com> Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits Date: Tue, 16 Sep 2003 12:58:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, These are good arguments, but I don't see them swaying the security directorate. Assuming one instruction per cycle and perhaps 100 instructions to check, a 2 GHz Pentium can check about 20 million tokens per second. Assuming 200 ms active time, that's about 4 million tokens in the time that the token is active. One can argue with the details of the above calculation, but it is the kind of thing I'd expect to see pop out of a security review. Of course, I suppose we could argue that the document is Experimental anyway, so perfect security isn't necessary, but what's the harm in lengthening the field? jak ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: Sent: Tuesday, September 16, 2003 12:34 PM Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits > > Hello James, > > I don't think it is needed, for two reasons: > > - The authorization token is only going to be used once > > - The data being protected is only good for a few hundred > milliseconds at most (typically). > > Regards, > Charlie P. > > > James Kempf wrote: > > >Issue 22 suggests that 32 bits isn't enough for the authorization token. > > > >See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for details. > > > >Possible resolutions: > > > >1) Make the authorization token longer, say 64 bits. > >2) Keep the authorization token at 32 bits. > > > >Suggested resolution: Make the authorization token longer, say 64 bits. > >Justification: The probability of a birthday attack is proportional to > >2**(sqrt(n)), where n is the number of bits in the identifier. If n is 32, > >then sqrt(n) is 16, which is not enough protection (65536). Making n equal > >64 means sqrt(n) is 32 (over 4 billion) which should be enough. > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 16:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09566 for ; Tue, 16 Sep 2003 16:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMG0-00075k-PO for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 16:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GKH4no027254 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 16:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMG0-00075V-Ln for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 16:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09487 for ; Tue, 16 Sep 2003 16:16:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMFy-0001gT-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 16:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zMFy-0001gQ-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 16:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMFx-00074h-Vp; Tue, 16 Sep 2003 16:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMFQ-00073L-E4 for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 16:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09431 for ; Tue, 16 Sep 2003 16:16:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMFO-0001fT-00 for seamoby@ietf.org; Tue, 16 Sep 2003 16:16:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19zMFN-0001ee-00 for seamoby@ietf.org; Tue, 16 Sep 2003 16:16:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8GKFqw21996; Tue, 16 Sep 2003 13:15:52 -0700 X-mProtect: <200309162015> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.214, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBnWUk5; Tue, 16 Sep 2003 13:15:50 PDT Message-ID: <3F676F66.3010004@iprg.nokia.com> Date: Tue, 16 Sep 2003 13:15:34 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits References: <020d01c37c79$a8ecbcc0$956015ac@dclkempt40> <3F6765B9.5080103@iprg.nokia.com> <029201c37c8c$f5b54870$956015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jim, Maybe it's time to insert rationality back into security protocol design. I'm willing to stand the heat. Mainly I am concerned about data fields that have to be passed over the air. Conservatism is indicated for this reason, and the reward is less hogging the airwaves. I am not worried about silicon, but in fact it would be nice if we did try to avoid mandating every protocol to require a Pentium processor. Regards, Charlie P. James Kempf wrote: >Hi Charlie, > >These are good arguments, but I don't see them swaying the security >directorate. Assuming one instruction per cycle and perhaps 100 instructions >to check, a 2 GHz Pentium can check about 20 million tokens per second. >Assuming 200 ms active time, that's about 4 million tokens in the time that >the token is active. > >One can argue with the details of the above calculation, but it is the kind >of thing I'd expect to see pop out of a security review. Of course, I >suppose we could argue that the document is Experimental anyway, so perfect >security isn't necessary, but what's the harm in lengthening the field? > > jak > >----- Original Message ----- >From: "Charlie Perkins" >To: "James Kempf" >Cc: >Sent: Tuesday, September 16, 2003 12:34 PM >Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by >truncating the results of the HMAC_SHA1 computation to retain only the >leading 32 bits > > > > >>Hello James, >> >>I don't think it is needed, for two reasons: >> >>- The authorization token is only going to be used once >> >>- The data being protected is only good for a few hundred >> milliseconds at most (typically). >> >>Regards, >>Charlie P. >> >> >>James Kempf wrote: >> >> >> >>>Issue 22 suggests that 32 bits isn't enough for the authorization token. >>> >>>See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for >>> >>> >details. > > >>>Possible resolutions: >>> >>>1) Make the authorization token longer, say 64 bits. >>>2) Keep the authorization token at 32 bits. >>> >>>Suggested resolution: Make the authorization token longer, say 64 bits. >>>Justification: The probability of a birthday attack is proportional to >>>2**(sqrt(n)), where n is the number of bits in the identifier. If n is >>> >>> >32, > > >>>then sqrt(n) is 16, which is not enough protection (65536). Making n >>> >>> >equal > > >>>64 means sqrt(n) is 32 (over 4 billion) which should be enough. >>> >>> >>>_______________________________________________ >>>Seamoby mailing list >>>Seamoby@ietf.org >>>https://www1.ietf.org/mailman/listinfo/seamoby >>> >>> >>> >>> >> >> >> > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 16 16:27:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10300 for ; Tue, 16 Sep 2003 16:27:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMPf-0007g0-2z for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 16:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GKR3x6029502 for seamoby-archive@odin.ietf.org; Tue, 16 Sep 2003 16:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMPe-0007et-TQ for seamoby-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 16:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10278 for ; Tue, 16 Sep 2003 16:26:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMPd-0001um-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 16:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zMPc-0001ug-00 for seamoby-web-archive@ietf.org; Tue, 16 Sep 2003 16:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMPd-0007de-6O; Tue, 16 Sep 2003 16:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMOz-0007d2-7A for seamoby@optimus.ietf.org; Tue, 16 Sep 2003 16:26:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10250 for ; Tue, 16 Sep 2003 16:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMOx-0001u2-00 for seamoby@ietf.org; Tue, 16 Sep 2003 16:26:19 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zMOw-0001tz-00 for seamoby@ietf.org; Tue, 16 Sep 2003 16:26:18 -0400 Message-ID: <02b601c37c90$d251d8e0$956015ac@dclkempt40> From: "James Kempf" To: "Charlie Perkins" Cc: References: <020d01c37c79$a8ecbcc0$956015ac@dclkempt40> <3F6765B9.5080103@iprg.nokia.com> <029201c37c8c$f5b54870$956015ac@dclkempt40> <3F676F66.3010004@iprg.nokia.com> Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits Date: Tue, 16 Sep 2003 13:26:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Maybe it's time to insert rationality back into security protocol design. > I'm willing to stand the heat. Does that mean that you're willing to take over as WG chair? :-) >Mainly I am concerned about data fields > that have to be passed over the air. Conservatism is indicated for this > reason, and the reward is less hogging the airwaves. > Sure. > I am not worried about silicon, but in fact it would be nice if we > did try to avoid mandating every protocol to require a Pentium > processor. > Well, ok, we can leave it at 32 bits, but if we get this thrown back into our face by the IESG, I'm going to say "I told you so!" jak > Regards, > Charlie P. > > > James Kempf wrote: > > >Hi Charlie, > > > >These are good arguments, but I don't see them swaying the security > >directorate. Assuming one instruction per cycle and perhaps 100 instructions > >to check, a 2 GHz Pentium can check about 20 million tokens per second. > >Assuming 200 ms active time, that's about 4 million tokens in the time that > >the token is active. > > > >One can argue with the details of the above calculation, but it is the kind > >of thing I'd expect to see pop out of a security review. Of course, I > >suppose we could argue that the document is Experimental anyway, so perfect > >security isn't necessary, but what's the harm in lengthening the field? > > > > jak > > > >----- Original Message ----- > >From: "Charlie Perkins" > >To: "James Kempf" > >Cc: > >Sent: Tuesday, September 16, 2003 12:34 PM > >Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by > >truncating the results of the HMAC_SHA1 computation to retain only the > >leading 32 bits > > > > > > > > > >>Hello James, > >> > >>I don't think it is needed, for two reasons: > >> > >>- The authorization token is only going to be used once > >> > >>- The data being protected is only good for a few hundred > >> milliseconds at most (typically). > >> > >>Regards, > >>Charlie P. > >> > >> > >>James Kempf wrote: > >> > >> > >> > >>>Issue 22 suggests that 32 bits isn't enough for the authorization token. > >>> > >>>See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for > >>> > >>> > >details. > > > > > >>>Possible resolutions: > >>> > >>>1) Make the authorization token longer, say 64 bits. > >>>2) Keep the authorization token at 32 bits. > >>> > >>>Suggested resolution: Make the authorization token longer, say 64 bits. > >>>Justification: The probability of a birthday attack is proportional to > >>>2**(sqrt(n)), where n is the number of bits in the identifier. If n is > >>> > >>> > >32, > > > > > >>>then sqrt(n) is 16, which is not enough protection (65536). Making n > >>> > >>> > >equal > > > > > >>>64 means sqrt(n) is 32 (over 4 billion) which should be enough. > >>> > >>> > >>>_______________________________________________ > >>>Seamoby mailing list > >>>Seamoby@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/seamoby > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 17 03:36:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29910 for ; Wed, 17 Sep 2003 03:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWrB-0007wH-Ry for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 03:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H7a9Hr030518 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 03:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWrB-0007w9-AJ for seamoby-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 03:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29907 for ; Wed, 17 Sep 2003 03:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWr8-00029Q-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 03:36:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zWr8-00029N-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 03:36:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWr3-0007vP-P4; Wed, 17 Sep 2003 03:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zWqG-0007uQ-RK for seamoby@optimus.ietf.org; Wed, 17 Sep 2003 03:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29899 for ; Wed, 17 Sep 2003 03:35:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zWqD-00029C-00 for seamoby@ietf.org; Wed, 17 Sep 2003 03:35:09 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19zWqD-000299-00 for seamoby@ietf.org; Wed, 17 Sep 2003 03:35:09 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 17 Sep 2003 10:35:09 +0300 Date: Wed, 17 Sep 2003 10:35:09 +0300 (EEST) From: Jukka MJ Manner To: Seamoby Working Group Subject: Re: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols In-Reply-To: <021a01c37c7a$5caa12d0$956015ac@dclkempt40> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, This issue is related to my question sent to the list on Friday about not being able to integrate the CTAR message into other handover messages. If adding such possibility would not delay the finishing of the CTP document too much, I would personally like to see that feature available. Then again, I don't currently work for a manufacturer implementing CTP or handover protocols, so maybe people who's work may be affected could comment... John already had some proposed text to have this feature possible. Regards, Jukka On Tue, 16 Sep 2003, James Kempf wrote: > CTP currently doesn't specify how it interoperates with other handover > protocols. A better integrated handover mechanism if CTP could be > interoperate with other handover protocols. > > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue24 for details. > > Possible resolutions: > > 1) Text proposed in issue24 Web page. > 2) Reject > > Suggested resolution: reject > Justification: The protocol currently is designed to be standalone, which is > sufficient for the experimental status. Further work on integrating CTP with > other handover protocols should go on within the IRTF's new mobility > research group. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From ddd@ddd.com Wed Sep 17 07:49:27 2003 Received: from ddd2091.com ([61.235.68.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07368 for ; Wed, 17 Sep 2003 07:49:24 -0400 (EDT) Message-Id: <200309171149.HAA07368@ietf.org> From: ddd To: seamoby-archive@ietf.org Reply-To: ddd@ddd.com Subject: =?gb2312?q?3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E70755-26368636?= Date: Wed, 17 Sep 2003 19:48:59 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="2d0d3fee-e933-11d7-a9fa-5254ab2a31ff" This is a multi-part message in MIME format --2d0d3fee-e933-11d7-a9fa-5254ab2a31ff Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB= =CA=DB150=D4=AA

3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7= =A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E7= 0755-26368636

EMAIL:  usa123678@yahoo.com.cn=D7=C9=D1=AF 

30000000 emailaddress for you = only 15$ ,if you need please download here,(download1 download2)they are tow winrar files,needs password open it,how to use it?please sent a mail = to me ,my email:  usa123678@yahoo.com.cn

=
2003=C4=EA=D7= =EE=D0=C2=B1=E0=BC=AD=B5=C43000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7,=B0=FC=C0=A8=D0= =D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6,=D0=D0=D2=B5=B0=E6=B7=D6=CE=AA:=B0=B2= =C8=AB=B7=C0=BB=A4=A1=A2=B0=EC=B9=AB=D3=C3=C6=B7=A1=A2=B5=E7=C4=D4=BC=B0=C8=ED= =BC=FE=A1=A2=B5=E7=D7=D3=B5=E7=B9=A4=A1=A2=B7=C4=D6=AF=B7=FE=D7=B0=A1=A2=C6=A4= =B8=EF=A1=A2=BB=AF=B9=A4=A1=A2=BB=B7=B1=A3=A1=A2=BB=FA=D0=B5=BC=B0=B9=A4=D2=B5= =D6=C6=C6=B7=A1=A2=BC=D2=BE=D3=D3=C3=C6=B7=A1=A2=BC=D2=D3=C3=B5=E7=C6=F7=A1=A2= =BD=A8=B2=C4=B7=BF=B5=D8=B2=FA=A1=A2=BD=BB=CD=A8=D4=CB=CA=E4=A1=A2=BF=E2=B4=E6= =BB=FD=D1=B9=A1=A2=C0=F1=C6=B7=B9=A4=D2=D5=C6=B7=A1=A2=C4=DC=D4=B4=A1=A2=C5=A9= =D2=B5=A1=A2=C9=CC=D2=B5=B7=FE=CE=F1=A1=A2=CA=B3=C6=B7=D2=FB=C6=B7=A1=A2=CD=A8= =D1=B6=B2=FA=C6=B7=A1=A2=CD=E6=BE=DF=A1=A2=D0=DD=CF=D0=D4=CB=B6=AF=A1=A2=D2=B1= =BD=F0=BF=F3=B2=FA=A1=A2=D2=BD=D2=A9=B1=A3=D1=F8=A1=A2=B0=FC=D7=B0=D3=A1=CB=A2= =B3=F6=B0=E6=B5=C8,=B5=D8=D3=F2=B0=E6=B0=B4=C8=AB=B9=FA=B8=F7=CA=A1,=B8=F7=CA= =D0=C7=F8=C0=B4=BB=AE=B7=D6=B2=A2=D3=D0=B2=BF=B7=D6=CA=C7=CD=E2=B9=FA=B5=C4= ,=B2=A2=CB=CD=C8=BA=B7=A2=C8=ED=BC=FE=D2=BB=CC=D7,=C8=ED=BC=FE=C3=BF=B7=D6=D6= =D3=BF=C9=B7=A23000-10000=B7=E2=D3=CA=BC=FE,=C8=E7=B9=FB=C4=E3=C8=B7=B6=A8=D0= =E8=D2=AA=C7=EB=CF=C8=CF=C2=D4=D8=D0=D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6=BC= =D3=C3=DC=D1=B9=CB=F5=CE=C4=BC=FE,=C8=BB=BA=F3=BD=AB150=D4=AA=B4=E6=C8=EB=A3= =A8=D5=D0=C9=CC=D2=F8=D0=D0=D2=BB=BF=A8=CD=A8=D5=CA=BA=C5=A3=BA9555 5075 5199 5818  =BB=A7=C3=FB=A3=BA=B7=EB=C0=F2=C4=C8=A3=A9=BA=F3=B8=F8=CE=D2=B7=A2=D3= =CA=BC=FE=A3=AC=BB=F2=B8=F8=CE=D2=B5=E7=BB=B0=A1=A3=CE=D2=BB=E1=BD=AB=C3=DC=C2= =EB=B8=E6=CB=DF=C4=E3.(=D0=D0=D2=B5= =B0=E6=CF=C2=D4=D8)(=B5=D8=D3= =F2=B0=E6=CF=C2=D4=D8)
=D7=A8=D2=B5=B6= =A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CE=D2=C3=C7=BB=E1=B8=F9=BE=DD=C4=E3=B5=C4= =D2=AA=C7=F3=CE=AA=C4=E3=B6=A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CA=D5=B7=D1:=C3= =BF30=CD=F2150=D4=AA
=C8=E7=B9=FB=C4=FA=B6=D4=CE=D2=C3= =C7=B5=C4=B7=FE=CE=F1=D3=D0=C8=CE=BA=CE=D2=E2=BC=FB=BB=F2=BD=A8=D2=E9=A3=AC=C7= =EB=BB=DD=B4=CDE-mail=D6=C1: usa123678@yahoo.com.cn
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=BA=CD=C6=BD=C2=B7118=BA=C55=B6=B0504 =  
=BF=CD=BB=A7=B7=FE=CE=F1=B5=E7=BB=B0=A3=BA=A3=A886-0755-26368636)=B7=EB=D0= =A1=BD=E3 =D1=EE=CF=C8=C9=FA
OICQ:76576669
--2d0d3fee-e933-11d7-a9fa-5254ab2a31ff-- From ddd@ddd.com Wed Sep 17 07:50:38 2003 Received: from ddd2091.com ([61.235.68.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07435 for ; Wed, 17 Sep 2003 07:50:35 -0400 (EDT) Message-Id: <200309171150.HAA07435@ietf.org> From: ddd To: seamoby-archive@ietf.org Reply-To: ddd@ddd.com Subject: =?gb2312?q?3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E70755-26368636?= Date: Wed, 17 Sep 2003 19:50:09 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="2d0d42e8-e933-11d7-a9fa-5254ab2a31ff" This is a multi-part message in MIME format --2d0d42e8-e933-11d7-a9fa-5254ab2a31ff Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB= =CA=DB150=D4=AA

3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7= =A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E7= 0755-26368636

EMAIL:  usa123678@yahoo.com.cn=D7=C9=D1=AF 

30000000 emailaddress for you = only 15$ ,if you need please download here,(download1 download2)they are tow winrar files,needs password open it,how to use it?please sent a mail = to me ,my email:  usa123678@yahoo.com.cn

=
2003=C4=EA=D7= =EE=D0=C2=B1=E0=BC=AD=B5=C43000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7,=B0=FC=C0=A8=D0= =D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6,=D0=D0=D2=B5=B0=E6=B7=D6=CE=AA:=B0=B2= =C8=AB=B7=C0=BB=A4=A1=A2=B0=EC=B9=AB=D3=C3=C6=B7=A1=A2=B5=E7=C4=D4=BC=B0=C8=ED= =BC=FE=A1=A2=B5=E7=D7=D3=B5=E7=B9=A4=A1=A2=B7=C4=D6=AF=B7=FE=D7=B0=A1=A2=C6=A4= =B8=EF=A1=A2=BB=AF=B9=A4=A1=A2=BB=B7=B1=A3=A1=A2=BB=FA=D0=B5=BC=B0=B9=A4=D2=B5= =D6=C6=C6=B7=A1=A2=BC=D2=BE=D3=D3=C3=C6=B7=A1=A2=BC=D2=D3=C3=B5=E7=C6=F7=A1=A2= =BD=A8=B2=C4=B7=BF=B5=D8=B2=FA=A1=A2=BD=BB=CD=A8=D4=CB=CA=E4=A1=A2=BF=E2=B4=E6= =BB=FD=D1=B9=A1=A2=C0=F1=C6=B7=B9=A4=D2=D5=C6=B7=A1=A2=C4=DC=D4=B4=A1=A2=C5=A9= =D2=B5=A1=A2=C9=CC=D2=B5=B7=FE=CE=F1=A1=A2=CA=B3=C6=B7=D2=FB=C6=B7=A1=A2=CD=A8= =D1=B6=B2=FA=C6=B7=A1=A2=CD=E6=BE=DF=A1=A2=D0=DD=CF=D0=D4=CB=B6=AF=A1=A2=D2=B1= =BD=F0=BF=F3=B2=FA=A1=A2=D2=BD=D2=A9=B1=A3=D1=F8=A1=A2=B0=FC=D7=B0=D3=A1=CB=A2= =B3=F6=B0=E6=B5=C8,=B5=D8=D3=F2=B0=E6=B0=B4=C8=AB=B9=FA=B8=F7=CA=A1,=B8=F7=CA= =D0=C7=F8=C0=B4=BB=AE=B7=D6=B2=A2=D3=D0=B2=BF=B7=D6=CA=C7=CD=E2=B9=FA=B5=C4= ,=B2=A2=CB=CD=C8=BA=B7=A2=C8=ED=BC=FE=D2=BB=CC=D7,=C8=ED=BC=FE=C3=BF=B7=D6=D6= =D3=BF=C9=B7=A23000-10000=B7=E2=D3=CA=BC=FE,=C8=E7=B9=FB=C4=E3=C8=B7=B6=A8=D0= =E8=D2=AA=C7=EB=CF=C8=CF=C2=D4=D8=D0=D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6=BC= =D3=C3=DC=D1=B9=CB=F5=CE=C4=BC=FE,=C8=BB=BA=F3=BD=AB150=D4=AA=B4=E6=C8=EB=A3= =A8=D5=D0=C9=CC=D2=F8=D0=D0=D2=BB=BF=A8=CD=A8=D5=CA=BA=C5=A3=BA9555 5075 5199 5818  =BB=A7=C3=FB=A3=BA=B7=EB=C0=F2=C4=C8=A3=A9=BA=F3=B8=F8=CE=D2=B7=A2=D3= =CA=BC=FE=A3=AC=BB=F2=B8=F8=CE=D2=B5=E7=BB=B0=A1=A3=CE=D2=BB=E1=BD=AB=C3=DC=C2= =EB=B8=E6=CB=DF=C4=E3.(=D0=D0=D2=B5= =B0=E6=CF=C2=D4=D8)(=B5=D8=D3= =F2=B0=E6=CF=C2=D4=D8)
=D7=A8=D2=B5=B6= =A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CE=D2=C3=C7=BB=E1=B8=F9=BE=DD=C4=E3=B5=C4= =D2=AA=C7=F3=CE=AA=C4=E3=B6=A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CA=D5=B7=D1:=C3= =BF30=CD=F2150=D4=AA
=C8=E7=B9=FB=C4=FA=B6=D4=CE=D2=C3= =C7=B5=C4=B7=FE=CE=F1=D3=D0=C8=CE=BA=CE=D2=E2=BC=FB=BB=F2=BD=A8=D2=E9=A3=AC=C7= =EB=BB=DD=B4=CDE-mail=D6=C1: usa123678@yahoo.com.cn
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=BA=CD=C6=BD=C2=B7118=BA=C55=B6=B0504 =  
=BF=CD=BB=A7=B7=FE=CE=F1=B5=E7=BB=B0=A3=BA=A3=A886-0755-26368636)=B7=EB=D0= =A1=BD=E3 =D1=EE=CF=C8=C9=FA
OICQ:76576669
--2d0d42e8-e933-11d7-a9fa-5254ab2a31ff-- From exim@www1.ietf.org Wed Sep 17 08:50:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09372 for ; Wed, 17 Sep 2003 08:50:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbl8-0004Jd-SL for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 08:50:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HCoE4s016585 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 08:50:14 -0400 Received: from [61.235.68.66] (helo=ddd1411.com) by optimus.ietf.org with smtp (Exim 4.20) id 19zbl6-0004JJ-Vd for seamoby-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 08:50:13 -0400 From: ddd To: seamoby-web-archive@optimus.ietf.org Reply-To: ddd@ddd.com Subject: =?gb2312?q?3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E70755-26368636?= Date: Wed, 17 Sep 2003 20:49:20 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="2d0db97a-e933-11d7-a9fa-5254ab2a31ff" Message-Id: This is a multi-part message in MIME format --2d0db97a-e933-11d7-a9fa-5254ab2a31ff Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB= =CA=DB150=D4=AA

3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7= =A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E7= 0755-26368636

EMAIL:  usa123678@yahoo.com.cn=D7=C9=D1=AF 

30000000 emailaddress for you = only 15$ ,if you need please download here,(download1 download2)they are tow winrar files,needs password open it,how to use it?please sent a mail = to me ,my email:  usa123678@yahoo.com.cn

=
2003=C4=EA=D7= =EE=D0=C2=B1=E0=BC=AD=B5=C43000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7,=B0=FC=C0=A8=D0= =D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6,=D0=D0=D2=B5=B0=E6=B7=D6=CE=AA:=B0=B2= =C8=AB=B7=C0=BB=A4=A1=A2=B0=EC=B9=AB=D3=C3=C6=B7=A1=A2=B5=E7=C4=D4=BC=B0=C8=ED= =BC=FE=A1=A2=B5=E7=D7=D3=B5=E7=B9=A4=A1=A2=B7=C4=D6=AF=B7=FE=D7=B0=A1=A2=C6=A4= =B8=EF=A1=A2=BB=AF=B9=A4=A1=A2=BB=B7=B1=A3=A1=A2=BB=FA=D0=B5=BC=B0=B9=A4=D2=B5= =D6=C6=C6=B7=A1=A2=BC=D2=BE=D3=D3=C3=C6=B7=A1=A2=BC=D2=D3=C3=B5=E7=C6=F7=A1=A2= =BD=A8=B2=C4=B7=BF=B5=D8=B2=FA=A1=A2=BD=BB=CD=A8=D4=CB=CA=E4=A1=A2=BF=E2=B4=E6= =BB=FD=D1=B9=A1=A2=C0=F1=C6=B7=B9=A4=D2=D5=C6=B7=A1=A2=C4=DC=D4=B4=A1=A2=C5=A9= =D2=B5=A1=A2=C9=CC=D2=B5=B7=FE=CE=F1=A1=A2=CA=B3=C6=B7=D2=FB=C6=B7=A1=A2=CD=A8= =D1=B6=B2=FA=C6=B7=A1=A2=CD=E6=BE=DF=A1=A2=D0=DD=CF=D0=D4=CB=B6=AF=A1=A2=D2=B1= =BD=F0=BF=F3=B2=FA=A1=A2=D2=BD=D2=A9=B1=A3=D1=F8=A1=A2=B0=FC=D7=B0=D3=A1=CB=A2= =B3=F6=B0=E6=B5=C8,=B5=D8=D3=F2=B0=E6=B0=B4=C8=AB=B9=FA=B8=F7=CA=A1,=B8=F7=CA= =D0=C7=F8=C0=B4=BB=AE=B7=D6=B2=A2=D3=D0=B2=BF=B7=D6=CA=C7=CD=E2=B9=FA=B5=C4= ,=B2=A2=CB=CD=C8=BA=B7=A2=C8=ED=BC=FE=D2=BB=CC=D7,=C8=ED=BC=FE=C3=BF=B7=D6=D6= =D3=BF=C9=B7=A23000-10000=B7=E2=D3=CA=BC=FE,=C8=E7=B9=FB=C4=E3=C8=B7=B6=A8=D0= =E8=D2=AA=C7=EB=CF=C8=CF=C2=D4=D8=D0=D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6=BC= =D3=C3=DC=D1=B9=CB=F5=CE=C4=BC=FE,=C8=BB=BA=F3=BD=AB150=D4=AA=B4=E6=C8=EB=A3= =A8=D5=D0=C9=CC=D2=F8=D0=D0=D2=BB=BF=A8=CD=A8=D5=CA=BA=C5=A3=BA9555 5075 5199 5818  =BB=A7=C3=FB=A3=BA=B7=EB=C0=F2=C4=C8=A3=A9=BA=F3=B8=F8=CE=D2=B7=A2=D3= =CA=BC=FE=A3=AC=BB=F2=B8=F8=CE=D2=B5=E7=BB=B0=A1=A3=CE=D2=BB=E1=BD=AB=C3=DC=C2= =EB=B8=E6=CB=DF=C4=E3.(=D0=D0=D2=B5= =B0=E6=CF=C2=D4=D8)(=B5=D8=D3= =F2=B0=E6=CF=C2=D4=D8)
=D7=A8=D2=B5=B6= =A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CE=D2=C3=C7=BB=E1=B8=F9=BE=DD=C4=E3=B5=C4= =D2=AA=C7=F3=CE=AA=C4=E3=B6=A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CA=D5=B7=D1:=C3= =BF30=CD=F2150=D4=AA
=C8=E7=B9=FB=C4=FA=B6=D4=CE=D2=C3= =C7=B5=C4=B7=FE=CE=F1=D3=D0=C8=CE=BA=CE=D2=E2=BC=FB=BB=F2=BD=A8=D2=E9=A3=AC=C7= =EB=BB=DD=B4=CDE-mail=D6=C1: usa123678@yahoo.com.cn
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=BA=CD=C6=BD=C2=B7118=BA=C55=B6=B0504 =  
=BF=CD=BB=A7=B7=FE=CE=F1=B5=E7=BB=B0=A3=BA=A3=A886-0755-26368636)=B7=EB=D0= =A1=BD=E3 =D1=EE=CF=C8=C9=FA
OICQ:76576669
--2d0db97a-e933-11d7-a9fa-5254ab2a31ff-- From exim@www1.ietf.org Wed Sep 17 12:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19102 for ; Wed, 17 Sep 2003 12:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zezO-0005IA-P0 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 12:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HGHArN020342 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 12:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zezO-0005I1-LO for seamoby-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 12:17:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19095 for ; Wed, 17 Sep 2003 12:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zezN-0000cV-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 12:17:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zezM-0000cR-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 12:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zezF-0005Gu-4u; Wed, 17 Sep 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zez8-0005Gg-P9 for seamoby@optimus.ietf.org; Wed, 17 Sep 2003 12:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19082 for ; Wed, 17 Sep 2003 12:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zez7-0000cE-00 for seamoby@ietf.org; Wed, 17 Sep 2003 12:16:53 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=gamma.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 19zez6-0000by-00 for seamoby@ietf.org; Wed, 17 Sep 2003 12:16:53 -0400 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Sep 2003 09:16:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Sep 2003 12:16:21 -0400 Message-ID: Thread-Topic: LWAPP/CAPWAP charter => my two cents Thread-Index: AcN9NwgEZFeYSvwpQfWHuJP443gFVg== From: "Jerome Moisand" To: X-OriginalArrivalTime: 17 Sep 2003 16:16:21.0209 (UTC) FILETIME=[08479C90:01C37D37] Content-Transfer-Encoding: quoted-printable Subject: [Seamoby] LWAPP/CAPWAP charter => my two cents Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, The lwapp/capwap discussion has been raised to my attention by several = industry players. I am catching up on this topic, and didn't have an = opportunity to attend the corresponding BOF at the last IETF meeting, so = pardon me if some topics I mention were already discussed. I do see the point of distributing processing between an 802.11 Access = Point and some "controlling & aggregation device", based on multiple = experiences with the deployment of HotSpots services by carriers. Which = usually express a desire to lower the capex/opex for the gear located in = the HotSpots, leveraging on more semi-centralized smarts in a = "controlling & aggregation device". Which could be viewed as a NAS = (Network Access Server). So my first comment is: let's make sure the problem statement includes = topologies for carrier-based services (HotSpots being only one = incarnation of this) as well as topologies for private WLAN within an = enterprise site or a campus. But this is probably obvious for you guys. Next, I'd like to point out (hoping to not be disruptive, but maybe I = will!) that this problem seems to be only one incarnation of a larger = problem. The more general problem I'd see is the case of a lightweigh = (usually layer2 "+", but not always) access device which requires some = level of inband control by a "controlling & aggregation" (usually layer = 3 "+") NAS device of some sort, which is itself likely somewhat driven = by a policy/AAA server of some sort. The aggregation is typically hub-like, a controlling device aggregating = X lite access devices, with some hierarchical layer2 connectivity (or = sometimes a layer3 tunnel). And then the capex and opex goals strike = again, exactly like in the 802.11 space. And betting on external OSS = systems to directly control the "lite" access devices is usually a = non-starter (doesn't scale, doesn't allow fast sub-second policy = decisions).=20 Let me give a few examples (which are carrier-oriented, because it's my = area of expertise, but I'm sure there is more): a) in the DSL world, the DSL residential gateway (a CPE) is becoming = more than a simple modem (look at the recent work in the DSL-Forum), but = actually a service point. Yet one would like to keep it low capex/opex, = which may spell out an inband control protocol from a BRAS/NAS system to = push some form of policy/service rules, or pull some form of topology = information. b) again, in the DSL world, you can make a similar case between DSLAMs = and BRAS systems. For similar reasons, including multicast scenarios and = access topology discovery.=20 c) in the same vein, the cable Docsis world ended up specifying an = inband control protocol between Cable Modems (which are clearly more = than modems!) an Cable Modem Termination Systems (CMTS). This was done = at the MAC layer, which always made me cringe. I'm not saying IETF = should revolutionize this specific cable space (too late!), but just = making a point that the problem is bigger than a specific access = technology area. d) more generally, whatever the broadband access technology (DSL, Cable, = Metro-Ethernet, PON, Fixed Wireless, etc), one will likely always find a = couple of service-related parameters & mechanisms that would benefit = from some inband control mechanism from a "controlling & aggregation = device". And will always find benefits in some form of auto-discovery of = the access topology. And in some cases, may find some necessary linkage = with authentication/authorization dynamic processes and the various = access devices being involved.=20 e) again, I'm no expert here, but I can venture a guess that in the = enterprise/campus space, there are similar "wireline" scenarios in = addition to the WLAN scenario. Heck, there isn't that much difference = between a wireless LAN and a wireline LAN... So let me suggest to possibly explore a wider scope for such an inband = control protocol, taking some of the fundamental ideas behind = lwapp/capwap, but extending it to a more generic mechanism. This = mechanism would of course require a generic framework (and protocol or = set of protocols), but then allow technology-specific extensions (a form = of information model, I would venture to guess) to address peculiarities = of DSL, 802,11, PON, etc. This topic obviously deserves more detailed discussion to find a good = balance, not go out-of-bounds, nor get too narrow... Not so easy! ;-) Thoughts? Feedback? Tx Jerome Moisand Juniper Networks _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 17 13:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21485 for ; Wed, 17 Sep 2003 13:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgKW-0008D4-Gn for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 13:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HHh4Uc031552 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 13:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgKW-0008Cp-CI for seamoby-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 13:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21473 for ; Wed, 17 Sep 2003 13:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zgKU-0001SW-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 13:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zgKT-0001ST-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 13:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgKT-0008C7-Qp; Wed, 17 Sep 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgJk-0008Bb-GT for seamoby@optimus.ietf.org; Wed, 17 Sep 2003 13:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21442 for ; Wed, 17 Sep 2003 13:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zgJi-0001S8-00 for seamoby@ietf.org; Wed, 17 Sep 2003 13:42:14 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19zgJh-0001S4-00 for seamoby@ietf.org; Wed, 17 Sep 2003 13:42:13 -0400 Message-ID: <009501c37d43$0bd64b20$956015ac@dclkempt40> From: "James Kempf" To: "Jukka MJ Manner" , "Seamoby Working Group" References: Subject: Re: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols Date: Wed, 17 Sep 2003 10:42:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jukka, CTP is not currently intended to be implemented in product deployments. It is intended to be an Experimental RFC, for input into the IRTF Mobility Research group. One task of this group will be to complete the integration of fast handover protocols that has currently been left unfinished in the IETF. We've attempted to accomplish this within Seamoby, but the current organizational structure - with half the fast handover work being done in the Mobile IP group and half in Seamoby - has proven a hinderance to getting a well-integrated IP level fast handover protocol. The IRTF Mobility Research group won't have that constraint. For that reason, I would recommend against trying to achieve the integration in this draft. If you are interested in participating in this effort, I'd urge you to become involved in the IRTF Mobility Research group. Personally, I'd like to see a well-engineered, integrated fast handover protocol with research work to back it up come popping out of the ITRF group in a year or two, ready for standardization. jak ----- Original Message ----- From: "Jukka MJ Manner" To: "Seamoby Working Group" Sent: Wednesday, September 17, 2003 12:35 AM Subject: Re: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols > > Hi, > > This issue is related to my question sent to the list on Friday about not > being able to integrate the CTAR message into other handover messages. If > adding such possibility would not delay the finishing of the CTP document > too much, I would personally like to see that feature available. Then > again, I don't currently work for a manufacturer implementing CTP or > handover protocols, so maybe people who's work may be affected could > comment... John already had some proposed text to have this feature > possible. > > Regards, > Jukka > > On Tue, 16 Sep 2003, James Kempf wrote: > > > CTP currently doesn't specify how it interoperates with other handover > > protocols. A better integrated handover mechanism if CTP could be > > interoperate with other handover protocols. > > > > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue24 for details. > > > > Possible resolutions: > > > > 1) Text proposed in issue24 Web page. > > 2) Reject > > > > Suggested resolution: reject > > Justification: The protocol currently is designed to be standalone, which is > > sufficient for the experimental status. Further work on integrating CTP with > > other handover protocols should go on within the IRTF's new mobility > > research group. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 17 16:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28031 for ; Wed, 17 Sep 2003 16:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj12-0004v5-L0 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 16:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HKZ82I018907 for seamoby-archive@odin.ietf.org; Wed, 17 Sep 2003 16:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj12-0004us-HW for seamoby-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 16:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27972 for ; Wed, 17 Sep 2003 16:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zj10-00035j-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 16:35:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zj10-00035e-00 for seamoby-web-archive@ietf.org; Wed, 17 Sep 2003 16:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj0y-0004tL-AB; Wed, 17 Sep 2003 16:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj0d-0004sZ-CQ for seamoby@optimus.ietf.org; Wed, 17 Sep 2003 16:34:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27956 for ; Wed, 17 Sep 2003 16:34:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zj0b-00035Q-00 for seamoby@ietf.org; Wed, 17 Sep 2003 16:34:41 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=alpha.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 19zj0b-000354-00 for seamoby@ietf.org; Wed, 17 Sep 2003 16:34:41 -0400 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Sep 2003 13:34:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Sep 2003 16:34:09 -0400 Message-ID: Thread-Topic: LWAPP/CAPWAP charter => my two cents Thread-Index: AcN9NwgEZFeYSvwpQfWHuJP443gFVgAI8J/A From: "Jerome Moisand" To: X-OriginalArrivalTime: 17 Sep 2003 20:34:09.0971 (UTC) FILETIME=[0C616030:01C37D5B] Content-Transfer-Encoding: quoted-printable Subject: [Seamoby] RE: LWAPP/CAPWAP charter => my two cents Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, seemed that I didn't use the proper e-mail list for this discussion. As = I said, I'm catching up on this topic... ;-) So apologies for this mistake, and thanks to the nice folks who told me = where to go: lwapp@frascone.com I will send my e-mail again to this list, then... Tx Jerome > -----Original Message----- > From: Jerome Moisand =20 > Sent: Wednesday, September 17, 2003 12:16 PM > To: 'seamoby@ietf.org' > Subject: LWAPP/CAPWAP charter =3D> my two cents >=20 >=20 > Folks, >=20 > The lwapp/capwap discussion has been raised to my attention by several = industry players. I am catching up on this topic, and didn't have an = opportunity to attend the corresponding BOF at the last IETF meeting, so = pardon me if some topics I mention were already discussed. >=20 > I do see the point of distributing processing between an 802.11 Access = Point and some "controlling & aggregation device", based on multiple = experiences with the deployment of HotSpots services by carriers. Which = usually express a desire to lower the capex/opex for the gear located in = the HotSpots, leveraging on more semi-centralized smarts in a = "controlling & aggregation device". Which could be viewed as a NAS = (Network Access Server). >=20 > So my first comment is: let's make sure the problem statement includes = topologies for carrier-based services (HotSpots being only one = incarnation of this) as well as topologies for private WLAN within an = enterprise site or a campus. But this is probably obvious for you guys. >=20 > Next, I'd like to point out (hoping to not be disruptive, but maybe I = will!) that this problem seems to be only one incarnation of a larger = problem. The more general problem I'd see is the case of a lightweigh = (usually layer2 "+", but not always) access device which requires some = level of inband control by a "controlling & aggregation" (usually layer = 3 "+") NAS device of some sort, which is itself likely somewhat driven = by a policy/AAA server of some sort. >=20 > The aggregation is typically hub-like, a controlling device = aggregating X lite access devices, with some hierarchical layer2 = connectivity (or sometimes a layer3 tunnel). And then the capex and opex = goals strike again, exactly like in the 802.11 space. And betting on = external OSS systems to directly control the "lite" access devices is = usually a non-starter (doesn't scale, doesn't allow fast sub-second = policy decisions).=20 >=20 > Let me give a few examples (which are carrier-oriented, because it's = my area of expertise, but I'm sure there is more): >=20 > a) in the DSL world, the DSL residential gateway (a CPE) is becoming = more than a simple modem (look at the recent work in the DSL-Forum), but = actually a service point. Yet one would like to keep it low capex/opex, = which may spell out an inband control protocol from a BRAS/NAS system to = push some form of policy/service rules, or pull some form of topology = information. >=20 > b) again, in the DSL world, you can make a similar case between DSLAMs = and BRAS systems. For similar reasons, including multicast scenarios and = access topology discovery.=20 >=20 > c) in the same vein, the cable Docsis world ended up specifying an = inband control protocol between Cable Modems (which are clearly more = than modems!) an Cable Modem Termination Systems (CMTS). This was done = at the MAC layer, which always made me cringe. I'm not saying IETF = should revolutionize this specific cable space (too late!), but just = making a point that the problem is bigger than a specific access = technology area. >=20 > d) more generally, whatever the broadband access technology (DSL, = Cable, Metro-Ethernet, PON, Fixed Wireless, etc), one will likely always = find a couple of service-related parameters & mechanisms that would = benefit from some inband control mechanism from a "controlling & = aggregation device". And will always find benefits in some form of = auto-discovery of the access topology. And in some cases, may find some = necessary linkage with authentication/authorization dynamic processes = and the various access devices being involved. >=20 >=20 > e) again, I'm no expert here, but I can venture a guess that in the = enterprise/campus space, there are similar "wireline" scenarios in = addition to the WLAN scenario. Heck, there isn't that much difference = between a wireless LAN and a wireline LAN... >=20 > So let me suggest to possibly explore a wider scope for such an inband = control protocol, taking some of the fundamental ideas behind = lwapp/capwap, but extending it to a more generic mechanism. This = mechanism would of course require a generic framework (and protocol or = set of protocols), but then allow technology-specific extensions (a form = of information model, I would venture to guess) to address peculiarities = of DSL, 802,11, PON, etc. >=20 > This topic obviously deserves more detailed discussion to find a good = balance, not go out-of-bounds, nor get too narrow... Not so easy! ;-) >=20 > Thoughts? Feedback? >=20 > Tx > Jerome Moisand > Juniper Networks _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Sep 18 12:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22411 for ; Thu, 18 Sep 2003 12:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q8-0005Ol-VO for seamoby-archive@odin.ietf.org; Thu, 18 Sep 2003 12:41:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IGf8a2020747 for seamoby-archive@odin.ietf.org; Thu, 18 Sep 2003 12:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q7-0005Nl-Dx for seamoby-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22275 for ; Thu, 18 Sep 2003 12:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01q5-0001ZJ-00 for seamoby-web-archive@ietf.org; Thu, 18 Sep 2003 12:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A01q5-0001ZG-00 for seamoby-web-archive@ietf.org; Thu, 18 Sep 2003 12:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q2-0005MY-78; Thu, 18 Sep 2003 12:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01pN-0005HL-Vo for seamoby@optimus.ietf.org; Thu, 18 Sep 2003 12:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22197 for ; Thu, 18 Sep 2003 12:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01pM-0001UN-00 for seamoby@ietf.org; Thu, 18 Sep 2003 12:40:20 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1A01pL-0001Qg-00 for seamoby@ietf.org; Thu, 18 Sep 2003 12:40:19 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8IGdigu033850 for ; Thu, 18 Sep 2003 18:39:44 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B0A0EB5C7F for ; Thu, 18 Sep 2003 18:10:41 +0200 (CEST) Message-ID: <3F69DFCF.5050709@ccrle.nec.de> Date: Thu, 18 Sep 2003 18:39:43 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proposal to resolve remaining CARD issues Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, to resolve the remaining issues of the CARD protocol specification, please find below a list of these issues with a short description of a proposed solution appended to all of them. If there are no concerns or negative comments, we'll incorporate the proposed mechanisms into the next updated version of the CARD protocol document, which will be available beginning of next week. marco Issue#5: static vs. dynamic capabilities. ----------------------------------------- Since there were some objections w.r.t the S-flag in the Capability AVP encoding format, we drop the S-flag for now and take over the proposal of indicating a static capability by means of setting the lifetime to 0. Lifetime field will be reduced to 16 bit (unit is seconds) and will be always present. Issue#6,issue#15 and issue#23: addressing and protection of unsolicited CARD Reply messages. ----------------------------------------------- Addressing of unsolicited CARD Reply messages will be done using a well-known multicast address. This requires to request a well known multicast address from IANA for IPv4 and IPv6 (link-local). For authentication of unsolicited CARD Reply messages, refer to the use of Digital Signatures in the Security Consideration section. Since this is a problem which is common to other protocols (Router Advertisements), hope there will be more efficient mechanisms in the future. Issue#9: Reverse Address Translation function - CARD vs. FMIPv6 (Piggybacking approach) ----------------------------------------------- Proposal is to include an additional flag in the CARD Request message, which allows a mobile terminal, when performing CARD protocol piggybacking with FMIPv6, to use CARD only for Capability Discovery without Reverse Address Translation (will be performed using the related FMIPv6 function). This implies, that no L2 ID will be appended to the CARD Request message and only Capability Container parameters will come back to the mobile terminal with the CARD Reply. Correct association of CARs' Capability Containers (coming with CARD Reply) with CARs' IP address (coming with PrRtAdv) will be done according to the order of how resolved IP addresses are listed in the PrRtAdv, whereas the Context-ID of the Capability Container indicates the position in that table (1,2,3...). Issue#17: Preferences/Requirements sub-option - One of them is sufficient? --------------------------------------------------- Proposal is to keep both, since this implies just the definition of a further sub-option type, which indicates that only Attributes without any Data field will follow in case of receiving a Preferences sub-option. The Requirements parameter sub-option will carry then a list of Attribute-Value pairs, the Preferences parameter carries a list of Attributes (just the AVP Code and Length, no Lifetime, no Data). Issue#40: 8-bit CARD Option length not enough --------------------------------------------- Length indicator units of CARD messages and parameters have been adjusted: CARD Request/Reply: 8-bit length indicator in units of 8 octets including the message header. Capability Container sub-option: 8-bit length indicator in units of 8 octets, not including the sub-option header. Remaining sub-options: 8-bit length indicator in units of octets including the header. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Sep 19 21:36:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00602 for ; Fri, 19 Sep 2003 21:36:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAX020140 for ; Fri, 19 Sep 2003 21:36:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG9xfF029306 for seamoby-archive@odin.ietf.org; Fri, 12 Sep 2003 12:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqUh-0007cb-Gq for seamoby-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:09:59 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00515 for ; Fri, 12 Sep 2003 12:09:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqTp-0007Se-Nl; Fri, 12 Sep 2003 12:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqSz-00072k-3f for seamoby@optimus.ietf.org; Fri, 12 Sep 2003 12:08:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00117 for ; Fri, 12 Sep 2003 12:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqSx-0000sT-00 for seamoby@ietf.org; Fri, 12 Sep 2003 12:08:11 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19xqSw-0000sA-00 for seamoby@ietf.org; Fri, 12 Sep 2003 12:08:11 -0400 Message-ID: <010601c37948$14c46f90$956015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 12 Sep 2003 09:08:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Fw: ID Tracker State Update Notice: draft-ietf-send-psreq Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "The IESG" To: ; Sent: Friday, September 12, 2003 8:58 AM Subject: ID Tracker State Update Notice: draft-ietf-send-psreq > 'State Changes to IESG Evaluation from AD Evaluation by Margaret Wasserman' > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Sat Sep 20 14:14:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18140 for ; Sat, 20 Sep 2003 14:14:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mFQ-00052z-DZ for seamoby-archive@odin.ietf.org; Sat, 20 Sep 2003 14:14:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KIEKpe019395 for seamoby-archive@odin.ietf.org; Sat, 20 Sep 2003 14:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mFQ-00052g-6g for seamoby-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 14:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18106 for ; Sat, 20 Sep 2003 14:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0mFN-0007OL-00 for seamoby-web-archive@ietf.org; Sat, 20 Sep 2003 14:14:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0mFI-0007O1-00 for seamoby-web-archive@ietf.org; Sat, 20 Sep 2003 14:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mF7-00051N-4F; Sat, 20 Sep 2003 14:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NhA-0007sB-TT for seamoby@optimus.ietf.org; Fri, 19 Sep 2003 12:01:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03705 for ; Fri, 19 Sep 2003 12:01:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0JdK-000647-00 for seamoby@ietf.org; Fri, 19 Sep 2003 07:41:06 -0400 Received: from viap098.atea.be ([194.78.143.98] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1A0J6u-0006cz-00 for seamoby@ietf.org; Fri, 19 Sep 2003 07:07:36 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS6ABNCK; Fri, 19 Sep 2003 13:07:05 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 13:07:06 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195450A5E@hrtades7.atea.be> From: Van Puyvelde Wim To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Issue 20: How to identify MNs with private addresse s Date: Fri, 19 Sep 2003 13:07:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: dinsdag 16 september 2003 17:59 To: seamoby@ietf.org Subject: [Seamoby] Issue 20: How to identify MNs with private addresses Summary: CTP utilizes the MN's previous IP address to uniquely identify the MN. If the previous IP address was behind a separate NAT, then there could be a conflict. See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue20 for a detailed description. Possible resolutions: 1) Use something other than the previous IP address to identify the MN. 2) Clarify how CTP interacts with NATs. 3) Keep the current text, note in the text that additional work is required before CTP will work with nonglobal scope addresses. Suggsted resolution: 3 Justification: Figuring out how CTP works with NATs is likely to be difficult and time consuming (ex. the Mobile IPv4/NAT interaction), and might even require a separate document. The spec should be kept simple until there is compelling deployment justification. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Sep 22 04:13:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05378 for ; Mon, 22 Sep 2003 04:13:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Lou-0006Xy-Vg for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 04:13:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M8DImw025159 for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 04:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Los-0006Xi-6N for seamoby-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 04:13:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05372 for ; Mon, 22 Sep 2003 04:13:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Lop-00041B-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 04:13:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1Loi-000414-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 04:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Lob-0006Wd-OK; Mon, 22 Sep 2003 04:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Lnr-0006Vx-Vv for seamoby@optimus.ietf.org; Mon, 22 Sep 2003 04:12:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05357 for ; Mon, 22 Sep 2003 04:12:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Lnk-00040V-00 for seamoby@ietf.org; Mon, 22 Sep 2003 04:12:08 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A1LnU-00040J-00 for seamoby@ietf.org; Mon, 22 Sep 2003 04:11:52 -0400 Received: from inwind.it ([193.204.86.121]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h8M8BOt14739 for ; Mon, 22 Sep 2003 10:11:24 +0200 (CEST) Date: Mon, 22 Sep 2003 10:09:07 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <09AE8DC0-ECD4-11D7-8943-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] Information Request Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I'm a new user of ML I read the seamoby draft about Mobility on IPv4, and I saw that You have to use a metric about QoS, bandwith, etc etc. Now, if I would misure the metric, which parameters Have I to Consider? Is there a formula or something such this to select parametres corretly? Many Thanx Ivano _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Sep 22 05:21:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06885 for ; Mon, 22 Sep 2003 05:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1MsZ-0000gH-6X for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 05:21:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M9LBs1002617 for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 05:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1MsZ-0000g8-3Y for seamoby-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 05:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06860 for ; Mon, 22 Sep 2003 05:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1MsV-0004bI-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 05:21:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1MsQ-0004bF-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 05:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1MsP-0000fF-W9; Mon, 22 Sep 2003 05:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1MrN-0000cr-ND for seamoby@optimus.ietf.org; Mon, 22 Sep 2003 05:20:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06825 for ; Mon, 22 Sep 2003 05:19:48 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1MrK-0004aW-00 for seamoby@ietf.org; Mon, 22 Sep 2003 05:19:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A1Mr9-0004aN-00 for seamoby@ietf.org; Mon, 22 Sep 2003 05:19:43 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8M9J9t08350 for ; Mon, 22 Sep 2003 12:19:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 12:19:09 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 12:19:09 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 12:19:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols Date: Mon, 22 Sep 2003 12:19:08 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Issue 24:Interoperability with other Handover Protocols Thread-Index: AcN9QyzfgA92feNvTL2H2fUOLE/nkwDp1IbQ To: , , X-OriginalArrivalTime: 22 Sep 2003 09:19:08.0840 (UTC) FILETIME=[93E3FA80:01C380EA] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I agree with James on this issue. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 17 September, 2003 20:42 > To: Jukka MJ Manner; Seamoby Working Group > Subject: Re: [Seamoby] CTP Issue 24:Interoperability with=20 > other Handover > Protocols >=20 >=20 > Jukka, >=20 > CTP is not currently intended to be implemented in product=20 > deployments. It > is intended to be an Experimental RFC, for input into the=20 > IRTF Mobility > Research group. One task of this group will be to complete=20 > the integration > of fast handover protocols that has currently been left=20 > unfinished in the > IETF. We've attempted to accomplish this within Seamoby, but=20 > the current > organizational structure - with half the fast handover work=20 > being done in > the Mobile IP group and half in Seamoby - has proven a=20 > hinderance to getting > a well-integrated IP level fast handover protocol. The IRTF Mobility > Research group won't have that constraint. For that reason, I would > recommend against trying to achieve the integration in this draft. >=20 > If you are interested in participating in this effort, I'd urge you to > become involved in the IRTF Mobility Research group.=20 > Personally, I'd like to > see a well-engineered, integrated fast handover protocol with=20 > research work > to back it up come popping out of the ITRF group in a year or=20 > two, ready for > standardization. >=20 > jak >=20 >=20 > ----- Original Message -----=20 > From: "Jukka MJ Manner" > To: "Seamoby Working Group" > Sent: Wednesday, September 17, 2003 12:35 AM > Subject: Re: [Seamoby] CTP Issue 24:Interoperability with=20 > other Handover > Protocols >=20 >=20 > > > > Hi, > > > > This issue is related to my question sent to the list on=20 > Friday about not > > being able to integrate the CTAR message into other=20 > handover messages. If > > adding such possibility would not delay the finishing of=20 > the CTP document > > too much, I would personally like to see that feature=20 > available. Then > > again, I don't currently work for a manufacturer implementing CTP or > > handover protocols, so maybe people who's work may be affected could > > comment... John already had some proposed text to have this feature > > possible. > > > > Regards, > > Jukka > > > > On Tue, 16 Sep 2003, James Kempf wrote: > > > > > CTP currently doesn't specify how it interoperates with=20 > other handover > > > protocols. A better integrated handover mechanism if CTP could be > > > interoperate with other handover protocols. > > > > > > See=20 > http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue24 for > details. > > > > > > Possible resolutions: > > > > > > 1) Text proposed in issue24 Web page. > > > 2) Reject > > > > > > Suggested resolution: reject > > > Justification: The protocol currently is designed to be=20 > standalone, > which is > > > sufficient for the experimental status. Further work on=20 > integrating CTP > with > > > other handover protocols should go on within the IRTF's=20 > new mobility > > > research group. > > > > > > Comments? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Sep 22 08:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12702 for ; Mon, 22 Sep 2003 08:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Q07-0001L1-Oy for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 08:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MCfBg2005137 for seamoby-archive@odin.ietf.org; Mon, 22 Sep 2003 08:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Q07-0001Km-Lp for seamoby-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 08:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12688 for ; Mon, 22 Sep 2003 08:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Q06-0006ZV-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 08:41:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1Q00-0006ZS-00 for seamoby-web-archive@ietf.org; Mon, 22 Sep 2003 08:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Pzx-0001Jp-H7; Mon, 22 Sep 2003 08:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Pz8-0001FC-Qh for seamoby@optimus.ietf.org; Mon, 22 Sep 2003 08:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12625 for ; Mon, 22 Sep 2003 08:40:02 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Pz7-0006YE-00 for seamoby@ietf.org; Mon, 22 Sep 2003 08:40:09 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1Pyw-0006XV-00 for seamoby@ietf.org; Mon, 22 Sep 2003 08:39:58 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MCcR623280 for ; Mon, 22 Sep 2003 15:38:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 15:38:18 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 15:38:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 15:38:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] Issue 20: How to identify MNs with private addresses Date: Mon, 22 Sep 2003 15:38:17 +0300 Message-ID: Thread-Topic: [Seamoby] Issue 20: How to identify MNs with private addresses Thread-Index: AcN8a/Q2J5bsVnq9SWGcNrFqCNh18wEmmvGA To: , X-OriginalArrivalTime: 22 Sep 2003 12:38:18.0475 (UTC) FILETIME=[666D93B0:01C38106] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, This sounds reasonable to me. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 18:59 > To: seamoby@ietf.org > Subject: [Seamoby] Issue 20: How to identify MNs with private=20 > addresses >=20 >=20 > Summary: CTP utilizes the MN's previous IP address to=20 > uniquely identify the > MN. If the previous IP address was behind a separate NAT,=20 > then there could > be a conflict. >=20 > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue20 for a > detailed description. >=20 > Possible resolutions: >=20 > 1) Use something other than the previous IP address to=20 > identify the MN. > 2) Clarify how CTP interacts with NATs. > 3) Keep the current text, note in the text that additional=20 > work is required > before CTP will work with nonglobal scope addresses. >=20 > Suggsted resolution: 3 > Justification: Figuring out how CTP works with NATs is likely to be > difficult and time consuming (ex. the Mobile IPv4/NAT=20 > interaction), and > might even require a separate document. The spec should be=20 > kept simple until > there is compelling deployment justification. >=20 > Comments? >=20 > jak >=20 >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 06:06:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03705 for ; Tue, 23 Sep 2003 06:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k3o-0002fz-JP for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:06:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NA6KAL010282 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k3o-0002fk-Ew for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:06:20 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03496 for ; Tue, 23 Sep 2003 06:06:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k2Y-0002HF-5g; Tue, 23 Sep 2003 06:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k1w-0002D3-6L for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 06:04:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03035 for ; Tue, 23 Sep 2003 06:04:15 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1k1s-0004Um-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:04:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A1k1s-0004Ud-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:04:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NA4Kt20560 for ; Tue, 23 Sep 2003 13:04:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Sep 2003 13:04:20 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:04:20 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:04:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] Issue 20: How to identify MNs with private addresses Date: Tue, 23 Sep 2003 13:04:19 +0300 Message-ID: Thread-Topic: [Seamoby] Issue 20: How to identify MNs with private addresses Thread-Index: AcN8a/Q2J5bsVnq9SWGcNrFqCNh18wFTgrxQ To: , X-OriginalArrivalTime: 23 Sep 2003 10:04:19.0835 (UTC) FILETIME=[0E2EBCB0:01C381BA] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable James, I have added this text at the end of section 1: The protocol supports both IPv4 and IPv6, though support for IPv4 = private=20 addresses is for future study. br, John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 18:59 > To: seamoby@ietf.org > Subject: [Seamoby] Issue 20: How to identify MNs with private=20 > addresses >=20 >=20 > Summary: CTP utilizes the MN's previous IP address to=20 > uniquely identify the > MN. If the previous IP address was behind a separate NAT,=20 > then there could > be a conflict. >=20 > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue20 for a > detailed description. >=20 > Possible resolutions: >=20 > 1) Use something other than the previous IP address to=20 > identify the MN. > 2) Clarify how CTP interacts with NATs. > 3) Keep the current text, note in the text that additional=20 > work is required > before CTP will work with nonglobal scope addresses. >=20 > Suggsted resolution: 3 > Justification: Figuring out how CTP works with NATs is likely to be > difficult and time consuming (ex. the Mobile IPv4/NAT=20 > interaction), and > might even require a separate document. The spec should be=20 > kept simple until > there is compelling deployment justification. >=20 > Comments? >=20 > jak >=20 >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 06:08:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03930 for ; Tue, 23 Sep 2003 06:08:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k5c-0003WH-Mh for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NA8CNe013523 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k5c-0003W2-JP for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:08:12 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03901 for ; Tue, 23 Sep 2003 06:08:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k4U-0002tz-2Z; Tue, 23 Sep 2003 06:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k3a-0002bf-Pe for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 06:06:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03410 for ; Tue, 23 Sep 2003 06:05:57 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1k3V-0004hF-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:06:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A1k3U-0004h1-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:06:00 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NA60t22221 for ; Tue, 23 Sep 2003 13:06:00 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Sep 2003 13:06:00 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:06:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:06:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] Issue 17: Clarifying text needed on deployment restrictions Date: Tue, 23 Sep 2003 13:05:58 +0300 Message-ID: Thread-Topic: [Seamoby] Issue 17: Clarifying text needed on deployment restrictions Thread-Index: AcN8df9E5/shItYUSeeft16d6VPVnwFREQNA To: , X-OriginalArrivalTime: 23 Sep 2003 10:06:00.0232 (UTC) FILETIME=[4A061A80:01C381BA] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, I have marked this as rejected. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 20:13 > To: seamoby@ietf.org > Subject: [Seamoby] Issue 17: Clarifying text needed on deployment > restrictions >=20 >=20 > Issue 17 suggests that clarifying text should be added to the=20 > draft about > deployment restrictions, specifically that CT within one ISP=20 > is the intended > deployment model. >=20 > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue17 for a > detailed description. >=20 > Possible resolutions: >=20 > 1) Add such text. > 2) Don't add any text on deployment. >=20 > Suggested resolution: Don't add any text on deployment. > Justification: Since this is an experimental draft, the exact=20 > deployment > scenerios are not clear yet, so such text would not be appropriate. >=20 > Comments? >=20 > jak >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 06:20:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04887 for ; Tue, 23 Sep 2003 06:20:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kHF-0005R2-I5 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NAKDWq020886 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kHF-0005Qm-EL for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:20:13 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04786 for ; Tue, 23 Sep 2003 06:20:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kG5-0005Dq-R1; Tue, 23 Sep 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kFd-0005AX-Tq for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 06:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04718 for ; Tue, 23 Sep 2003 06:18:24 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kFa-0005xt-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:18:30 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A1kFZ-0005xl-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:18:29 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NAITt08682 for ; Tue, 23 Sep 2003 13:18:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 23 Sep 2003 13:18:29 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:18:29 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:18:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] CTP Issue 12: Use of MN's new care-of address Date: Tue, 23 Sep 2003 13:18:27 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Issue 12: Use of MN's new care-of address Thread-Index: AcN8d6wxXymTI7eqQhuqJSaXOO+SvAFQyvSQ To: , X-OriginalArrivalTime: 23 Sep 2003 10:18:29.0425 (UTC) FILETIME=[0893E210:01C381BC] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, I have added the following text to the CTD message: Note that the new AR must defend the new Care-of-Address using proxy = ARP=20 or Neighbor Discovery.=20 John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 20:26 > To: seamoby@ietf.org > Subject: [Seamoby] CTP Issue 12: Use of MN's new care-of address >=20 >=20 > If MN's new care-of address is included in CTAR or CTD > before it is assigned on the MN, nAR must defend new CoA > (at least for IPv6 DAD) until MN claims it. Should this > requirement be stated? Or can the new CoA only be used in > CTAR or CTD if it is already assigned to the MN? If so, > then it should be clearly stated. > See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue12 for > details.Suggested resolution: Include text noting that the new AR must > defend the address using proxy ARP/ND. >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 06:42:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05781 for ; Tue, 23 Sep 2003 06:42:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kc4-0008Px-6Z for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:41:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NAfiY2032351 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kc4-0008Pi-2F for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05710 for ; Tue, 23 Sep 2003 06:41:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kc0-0000Pj-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 06:41:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1kbz-0000Pf-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 06:41:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kbO-0008GM-3M; Tue, 23 Sep 2003 06:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kax-0008Cc-SM for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 06:40:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05627 for ; Tue, 23 Sep 2003 06:40:26 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kat-0000HR-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:40:31 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1kas-0000HI-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:40:31 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NAeV601272 for ; Tue, 23 Sep 2003 13:40:31 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Sep 2003 13:40:30 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:40:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:37:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Sep 2003 13:37:19 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Issue 29: CTP spec needs an example Thread-Index: AcN8bMrNLRJWg7F7SZu5fvJYhwmncwFUb0/A To: , X-OriginalArrivalTime: 23 Sep 2003 10:37:34.0003 (UTC) FILETIME=[B2CCA030:01C381BE] Content-Transfer-Encoding: quoted-printable Subject: [Seamoby] Issue26: Mostly editorial comments from Michael Georgiades Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I have updated the draft in accordance with issue 26, mostly editorial type stuff. Issue 26 is now marked as closed. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 06:48:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06116 for ; Tue, 23 Sep 2003 06:48:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kht-0000h4-Jj for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:47:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NAljeF002660 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 06:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kht-0000go-FM for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06045 for ; Tue, 23 Sep 2003 06:47:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1khn-00011Q-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 06:47:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1khn-00011L-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 06:47:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1khB-0000XQ-HJ; Tue, 23 Sep 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kgP-0000Sh-Pp for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 06:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05939 for ; Tue, 23 Sep 2003 06:46:04 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kgL-0000ru-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:46:09 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1kgL-0000rm-00 for seamoby@ietf.org; Tue, 23 Sep 2003 06:46:09 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NAk9607608 for ; Tue, 23 Sep 2003 13:46:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Sep 2003 13:46:09 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:46:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 13:46:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] CTP Issue 29: CTP spec needs an example Date: Tue, 23 Sep 2003 13:46:07 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Issue 29: CTP spec needs an example Thread-Index: AcN8bMrNLRJWg7F7SZu5fvJYhwmncwFUwcaw To: , X-OriginalArrivalTime: 23 Sep 2003 10:46:08.0570 (UTC) FILETIME=[E58151A0:01C381BF] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable James, I think that this is a useful example to give as an appendix, so I=20 think we should add it. thanks, John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 18:45 > To: seamoby@ietf.org > Subject: [Seamoby] CTP Issue 29: CTP spec needs an example >=20 >=20 > At the Vienna IETF meeting, we discussed the need for some=20 > example of CTP in > order to show readers (and the IESG in particular) what the=20 > benefits of CTP > are for smoothing handover. Header compression was discussed but some > technical issues were raised that may take a while to work=20 > through, so it > seems like header compression might not be simple enough.=20 > While Rajeev is > working through those issues, a simpler example that we could=20 > include in the > CTP document would be useful so that we can advance the CTP=20 > document sooner. > Multicast was suggested as an example. Below is text for an=20 > appendix to the > CTP spec for an example involving MLD state CT. Note that=20 > this text is not > meant to be normative, but might be usefully separated out=20 > into an actual > protocol when and if CTP goes to PS. >=20 > Comments? >=20 > jak >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Multicast Listener Context Transfer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Introduction > ------------ >=20 > As an example of how context transfer can improve the=20 > performance of IP > layer handover, we consider transferring IPv6 MLD state [1].=20 > MLD state is a > particularly good example because every IPv6 node must perform two MLD > messaging sequences on the wireless link to establish itself as an MLD > listener prior to performing router discovery [2] or duplicate address > detection [3] or before sending/receiving any=20 > application-specific traffic > (including Mobile IP handover signaling, if any). The node=20 > must subscribe to > the All Nodes Multicast Address and the Solicited Node=20 > Multicast Address as > soon as it comes up on the link. In addition, any application-specific > multicast addresses must be re-established as well. Context=20 > transfer can > significantly speed up re-establishing multicast state by=20 > allowing the nAR > to initialize MLD for a node that just completed handover;=20 > without any MLD > signaling on the new wireless link. The same approach could=20 > be used for > transferring multicast context in IPv4. >=20 > An approximate qualitative estimate for the amount of savings=20 > in handover > time can be obtained as follows. MLD messages are 24 bytes,=20 > to which the > IPv6 header, 40 bytes, and a required Routing Header Type 0,=20 > 24 bytes, must > be added (because there will be no header compression on the=20 > new link), for > a total MLD message size of 88 bytes per message per=20 > subscribed address. RFC > 2710 recommends that nodes send 2 to 3 MLD Report messages per address > subscription, since the Report message is unacknowledged.=20 > Assuming 2 MLD > messages sent per address subscription, the mobile node would=20 > need to send a > total of 4 MLD messages for the two pre-router discovery=20 > multicast addresses > (All Nodes Multicast Address and Solicited Node Multicast=20 > Address for the > link local address). This gives a total of 176 bytes per=20 > subscribed address > or 352 bytes over the wireless link for both the pre-router discovery > multicast addresses. The amount of time saved will, of=20 > course, depend on the > wireless link bandwidth, but some representative numbers can=20 > be obtained by > assuming bandwidths of 20 kbps or 100 kbps. The former is=20 > approximate for a > narrowband 3G cellular link and the latter for a moderately=20 > utilized 802.11b > WLAN link, both running Voice over IP (VoIP). With these two=20 > bit rates, the > savings from not having to perform the pre-router discovery=20 > messages are > 140.8 msec. and 28.2 msec., respectively. If any application-specific > multicast addresses were subscribed, the amount of time saved could be > substantially more. Considering most ATM-based 3G voice=20 > cellular protocols > try to keep total voice handover delay less than 40-80 msec.,=20 > MLD signaling > could have a large impact on the performance of inter-subnet=20 > VoIP handover. >=20 > The Protocol > ------------ >=20 > The context-specific data field for MLD context transfer=20 > included in the CTP > Context Data Block message for a single IPv6 multicast address has the > following format: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =20 > | > + Subnet Prefix on nAR Wireless Interface =20 > + > | =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =20 > | > + =20 > + > | =20 > | > + Subscribed IPv6 Multicast Address =20 > + > | =20 > | > + =20 > + > | =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The Subnet Prefix on nAR Wireless Interface field contains a=20 > subnet prefix > that identifies the interface on which multicast routing should be > established. The Subscribed IPv6 Multicast Address field contains the > multicast address for which multicast routing should be established. >=20 > The pAR sends one MLD context block per subscribed IPv6=20 > multicast address. >=20 > Router MLD State Machine Interactions > ------------------------------------- >=20 > No changes are required in the MLD state machine for the routers. >=20 > Upon receipt of a CTP Context Data Block for MLD, if the=20 > router is in the No > Listeners Present state, it transitions to the Listeners=20 > Present state for > the Subscribed IPv6 Multicast Address on the wireless=20 > interface specified by > the Subnet Prefix on nAR Wireless Interface and starts its=20 > timer, as if it > had received a Report message in the No Listeners Present=20 > state. If the > router is in the Listeners Present state for the multicast address, it > remains in that state but restarts the timer, as if it had=20 > received a Report > message in that state. >=20 > If more than one MLD router is on the link, a router=20 > receiving a MLD context > data block SHOULD send a CTP Context Data Block for the=20 > Subscribed IPv6 > Multicast Address and the Subnet Prefix on nAR Wireless=20 > Interface to other > MLD routers on the link. A router receiving an MLD context=20 > data block MAY > send a proxy MLD Report message instead, if wireless=20 > bandwidth is not an > issue. Since MLD routers do not keep track of which nodes are=20 > listening to > multicast addresses, only whether a particular multicast=20 > address is being > listened to, proxying the subscription should cause no difficulty. >=20 > [1] Deering, S., Fenner, W., and Haberman, B., " Multicast Listener > Discovery (MLD) for IPv6," RFC 2710, October, 1999. >=20 > [2] Narten, T., Nordmark, E., and Simpson. W., "Neighbor=20 > Discovery for IP > Version 6 (IPv6)," RFC 2461, December, 1998. >=20 > [3] Thompson, S., and Narten, T., "IPv6 Address=20 > Autoconfiguration," RFC > 2462, December, 1998. >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 07:14:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07081 for ; Tue, 23 Sep 2003 07:14:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1l72-00041k-VT for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 07:13:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NBDiBM015474 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 07:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1l72-00041V-Rg for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 07:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07056 for ; Tue, 23 Sep 2003 07:13:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1l72-0003T6-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 07:13:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1l71-0003T3-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 07:13:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1l6J-0003sI-Dc; Tue, 23 Sep 2003 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1l5x-0003pt-7k for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 07:12:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06990 for ; Tue, 23 Sep 2003 07:12:31 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1l5w-0003Lz-00 for seamoby@ietf.org; Tue, 23 Sep 2003 07:12:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A1l5v-0003Lr-00 for seamoby@ietf.org; Tue, 23 Sep 2003 07:12:36 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8NBCYt12104 for ; Tue, 23 Sep 2003 14:12:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Sep 2003 14:12:34 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 14:12:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 23 Sep 2003 14:10:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Seamoby] CTP Issue 13 - Generic message header Date: Tue, 23 Sep 2003 14:10:18 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Issue 13 - Generic message header Thread-Index: AcN8dzaVuvTvfBJuRBO4KCFGEbQUFQFTADEw To: , X-OriginalArrivalTime: 23 Sep 2003 11:10:19.0418 (UTC) FILETIME=[464727A0:01C381C3] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, I think that this is reasonable. We can delete the generic header. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2003 20:23 > To: seamoby@ietf.org > Subject: [Seamoby] CTP Issue 13 - Generic message header >=20 >=20 > The text describing Issue 13 isn't quite clear to me, but I'm=20 > interpreting > as follows: >=20 > Section 2.4 of the spec defines a generic CTP header, but the=20 > subsections > define specific headers that are different for specific=20 > messages. Which is > correct? >=20 > See=20 > http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue13 for more > details. >=20 > Possible resolutions: >=20 > 1) Modify the headers for specific messages to use the generic header. > 2) Drop the generic header. >=20 > Suggested resolution: Drop the generic header. > Justification: The fact that the individual messages have=20 > their own headers > suggests they need different information in the header. The=20 > simplest course > therefore seems to drop the generic header. >=20 > Comments? >=20 > jak >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 09:59:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13668 for ; Tue, 23 Sep 2003 09:59:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ngh-0005PQ-1I for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 09:58:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDwhgh020786 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 09:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ngg-0005PB-TA for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 09:58:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13645 for ; Tue, 23 Sep 2003 09:58:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nge-0000Au-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 09:58:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1nge-0000Ar-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 09:58:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ng0-0005KM-ND; Tue, 23 Sep 2003 09:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nfH-0005Hw-Lq for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 09:57:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13569 for ; Tue, 23 Sep 2003 09:57:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nfF-00009l-00 for seamoby@ietf.org; Tue, 23 Sep 2003 09:57:13 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A1nfE-00009b-00 for seamoby@ietf.org; Tue, 23 Sep 2003 09:57:12 -0400 Received: from inwind.it ([193.204.86.118]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h8NDv9t16274 for ; Tue, 23 Sep 2003 15:57:09 +0200 (CEST) Date: Tue, 23 Sep 2003 15:54:37 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <787D5628-EDCD-11D7-AE53-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] Mean Context Block Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I read draft about CTP and CARD Protocol....but what is the mean of First Context Block or Next Context Block (Context Transfer Data (CTD) Message) ? I know that MN has to send the Context Parameters like QoS, Bandwith, etc.. but How could it send this? Many Thanx and God be with you. Ivano _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 10:16:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15508 for ; Tue, 23 Sep 2003 10:16:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nxC-0006b1-8K for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 10:15:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEFkWi025349 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 10:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nxB-0006am-Vx for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 10:15:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15411 for ; Tue, 23 Sep 2003 10:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nx9-0000Ot-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 10:15:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1nx9-0000Oq-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 10:15:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nwU-0006Sl-Ho; Tue, 23 Sep 2003 10:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nw7-0006Rh-3X for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 10:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15228 for ; Tue, 23 Sep 2003 10:14:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nw4-0000NK-00 for seamoby@ietf.org; Tue, 23 Sep 2003 10:14:36 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1A1nw4-0000N0-00 for seamoby@ietf.org; Tue, 23 Sep 2003 10:14:36 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 22198345C3; Tue, 23 Sep 2003 16:06:16 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 141BD3F468; Tue, 23 Sep 2003 16:21:08 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003092316061327385 ; Tue, 23 Sep 2003 16:06:15 +0200 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id D1E1E3F46C; Tue, 23 Sep 2003 16:21:05 +0200 (CEST) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1A1nnY-00048D-3h; Tue, 23 Sep 2003 16:05:48 +0200 Date: Tue, 23 Sep 2003 16:05:48 +0200 From: Julien Bournelle To: Ivano De Luca Cc: seamoby@ietf.org Subject: Re: [Seamoby] Mean Context Block Message-ID: <20030923140548.GF15542@ipv6-5.int-evry.fr> References: <787D5628-EDCD-11D7-AE53-000A95946ED6@inwind.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <787D5628-EDCD-11D7-AE53-000A95946ED6@inwind.it> Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Tue, Sep 23, 2003 at 03:54:37PM +0200, Ivano De Luca wrote: > I read draft about CTP and CARD Protocol....but what is the mean of > First Context Block or Next Context Block (Context Transfer Data (CTD) > Message) ? > I know that MN has to send the Context Parameters like QoS, Bandwith, > etc.. but How could it send this? it uses the Context BLock to send the parameters. The context type identify which context you are sending. The way parameters must be formatted must be defined in a document. Hope it helps, -- julien.bournelle@int-evry.fr _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Sep 23 13:52:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27396 for ; Tue, 23 Sep 2003 13:52:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rKl-0002s5-K9 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 13:52:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHqJcM011031 for seamoby-archive@odin.ietf.org; Tue, 23 Sep 2003 13:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rKl-0002rp-F5 for seamoby-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 13:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27386 for ; Tue, 23 Sep 2003 13:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rKj-00047G-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 13:52:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1rKi-00047D-00 for seamoby-web-archive@ietf.org; Tue, 23 Sep 2003 13:52:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rKT-0002ok-AZ; Tue, 23 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rJb-0002mm-B8 for seamoby@optimus.ietf.org; Tue, 23 Sep 2003 13:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27312 for ; Tue, 23 Sep 2003 13:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rJZ-00045i-00 for seamoby@ietf.org; Tue, 23 Sep 2003 13:51:05 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A1rJY-000451-00 for seamoby@ietf.org; Tue, 23 Sep 2003 13:51:04 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8NHoX9D000639 for ; Tue, 23 Sep 2003 19:50:33 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A3829BD38 for ; Tue, 23 Sep 2003 19:20:42 +0200 (CEST) Message-ID: <3F7087E9.9060204@ccrle.nec.de> Date: Tue, 23 Sep 2003 19:50:33 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD protocol draft updated and submitted Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, the CARD protocol draft has been updated and submitted. You can also have immediate access to the draft version 04 through the following link: http://www.ccrle.nec.de/I-D/draft-ietf-seamoby-card-protocol-04.txt The update has the proposed mechanisms to solve the remaining issues on the protocol incorporated, following the mail, which has been sent to the list on the 18th Sept. Comments are welcome. Thanks, marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 24 10:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17391 for ; Wed, 24 Sep 2003 10:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AUz-0006fi-FI for seamoby-archive@odin.ietf.org; Wed, 24 Sep 2003 10:20:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OEK9O5025640 for seamoby-archive@odin.ietf.org; Wed, 24 Sep 2003 10:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AUy-0006fL-Oz for seamoby-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 10:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17345 for ; Wed, 24 Sep 2003 10:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2AUw-0004gR-00 for seamoby-web-archive@ietf.org; Wed, 24 Sep 2003 10:20:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2AUw-0004gN-00 for seamoby-web-archive@ietf.org; Wed, 24 Sep 2003 10:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AUt-0006eb-IB; Wed, 24 Sep 2003 10:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AIZ-00058d-5U for seamoby@optimus.ietf.org; Wed, 24 Sep 2003 10:07:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15553; Wed, 24 Sep 2003 10:07:10 -0400 (EDT) Message-Id: <200309241407.KAA15553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 24 Sep 2003 10:07:10 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-protocol-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Candidate Access Router Discovery Author(s) : M. Liebsch et al. Filename : draft-ietf-seamoby-card-protocol-04.txt Pages : 47 Date : 2003-9-24 To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called 'candidate access router discovery' (CARD). At the time of IP-layer handover, that CAR, whose capabilities is a good match to the preferences of the MN, may be chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-protocol-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-protocol-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-24092309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-24092309.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Sep 24 11:57:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23670 for ; Wed, 24 Sep 2003 11:57:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C0o-0004lH-2T for seamoby-archive@odin.ietf.org; Wed, 24 Sep 2003 11:57:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFv6tA018297 for seamoby-archive@odin.ietf.org; Wed, 24 Sep 2003 11:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C0n-0004l2-Tc for seamoby-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 11:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23632 for ; Wed, 24 Sep 2003 11:56:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2C0m-0006dN-00 for seamoby-web-archive@ietf.org; Wed, 24 Sep 2003 11:57:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2C0m-0006dK-00 for seamoby-web-archive@ietf.org; Wed, 24 Sep 2003 11:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C0j-0004jC-OB; Wed, 24 Sep 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C0Z-0004iO-8a for seamoby@optimus.ietf.org; Wed, 24 Sep 2003 11:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23603 for ; Wed, 24 Sep 2003 11:56:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2C0T-0006cr-00 for seamoby@ietf.org; Wed, 24 Sep 2003 11:56:45 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A2C0S-0006cj-00 for seamoby@ietf.org; Wed, 24 Sep 2003 11:56:44 -0400 Message-ID: <017901c382b4$7ca41c80$956015ac@dclkempt40> From: "James Kempf" To: Cc: Date: Wed, 24 Sep 2003 08:56:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Last Call on draft-ietf-seamoby-card-protocol-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, WG Last Call on draft-ietf-seamoby-card-protocol-04.txt starts today and runs until Oct. 7. Please read the CARD protocol design draft and send any comments to the list. After this review, Marco and Ajoy will be incorporating comments, and we will send the draft to the IESG for publication as an Experimental RFC. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Sep 29 09:14:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13498 for ; Mon, 29 Sep 2003 09:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3xqn-00011Z-ED for seamoby-archive@odin.ietf.org; Mon, 29 Sep 2003 09:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDE54O003931 for seamoby-archive@odin.ietf.org; Mon, 29 Sep 2003 09:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3xqn-00011K-86 for seamoby-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 09:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13491 for ; Mon, 29 Sep 2003 09:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3xql-0005Xg-00 for seamoby-web-archive@ietf.org; Mon, 29 Sep 2003 09:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3xql-0005Xc-00 for seamoby-web-archive@ietf.org; Mon, 29 Sep 2003 09:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3xqi-00010Y-PR; Mon, 29 Sep 2003 09:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3xqc-00010I-Rk for seamoby@optimus.ietf.org; Mon, 29 Sep 2003 09:13:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13481 for ; Mon, 29 Sep 2003 09:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3xqb-0005XN-00 for seamoby@ietf.org; Mon, 29 Sep 2003 09:13:53 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A3xqa-0005XE-00 for seamoby@ietf.org; Mon, 29 Sep 2003 09:13:52 -0400 Received: from inwind.it ([193.204.86.121]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h8TDDdN18292 for ; Mon, 29 Sep 2003 15:13:39 +0200 (CEST) Date: Mon, 29 Sep 2003 15:11:28 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <6FFB8B68-F27E-11D7-AD94-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] About DATA AVPs Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I saw that seamoby card protocol is giong to be an RFC. I posted you a question about the metric used by MobileNode to make handover among ARs. But up to now I don't know how MobileNode can misure this metric...... Where could I find Informations about coding of AVP data to get the metric ? Answer me,,,,,,please please Ivano _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Sep 29 16:39:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10906 for ; Mon, 29 Sep 2003 16:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44nT-0001lN-Ob for seamoby-archive@odin.ietf.org; Mon, 29 Sep 2003 16:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TKd73r006773 for seamoby-archive@odin.ietf.org; Mon, 29 Sep 2003 16:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44nT-0001lA-DN for seamoby-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 16:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10886 for ; Mon, 29 Sep 2003 16:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44nR-0004rN-00 for seamoby-web-archive@ietf.org; Mon, 29 Sep 2003 16:39:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A44nR-0004rK-00 for seamoby-web-archive@ietf.org; Mon, 29 Sep 2003 16:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44nN-0001kS-JF; Mon, 29 Sep 2003 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44mP-0001ji-Hh for seamoby@optimus.ietf.org; Mon, 29 Sep 2003 16:38:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10854 for ; Mon, 29 Sep 2003 16:37:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44mN-0004qy-00 for seamoby@ietf.org; Mon, 29 Sep 2003 16:37:59 -0400 Received: from mailer.ccrl.nj.nec.com ([138.15.108.3] helo=mailer.nec-labs.com) by ietf-mx with esmtp (Exim 4.12) id 1A44mN-0004qv-00 for seamoby@ietf.org; Mon, 29 Sep 2003 16:37:59 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Sep 2003 16:37:59 -0400 Message-ID: <008b01c386ca$3f02a6c0$c96b0f8a@peace> From: "Eunsoo Shim" To: "Ivano De Luca" , References: <6FFB8B68-F27E-11D7-AD94-000A95946ED6@inwind.it> Subject: Re: [Seamoby] About DATA AVPs Date: Mon, 29 Sep 2003 16:42:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Sep 2003 20:37:59.0734 (UTC) FILETIME=[92496D60:01C386C9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The CARD protocol provides mechanisms a mobile node can receive information about candidate access routers. But the current specification does not define any specific attribute or metric to be delivered by the CARD protocol. The current specification defines the general format of the AVP but again does not define the specific encoding rule of any attribute or metric which is the value portion of the AVP. Definition of attributes or metric or their encoding rules is out of scope of the current draft. So for now, you can define your own attributes and their encoding rules. Hope this helps. Eunsoo ----- Original Message ----- From: "Ivano De Luca" To: Sent: Monday, September 29, 2003 9:11 AM Subject: [Seamoby] About DATA AVPs > I saw that seamoby card protocol is giong to be an RFC. > I posted you a question about the metric used by MobileNode to make > handover among ARs. > But up to now I don't know how MobileNode can misure this metric...... > > Where could I find Informations about coding of AVP data to get the > metric ? > > Answer me,,,,,,please please > > Ivano > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby