From exim@www1.ietf.org Fri Aug 1 04:57:44 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 EAA03053 for ; Fri, 1 Aug 2003 04:57: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 19iViu-0008ET-2G for seamoby-archive@odin.ietf.org; Fri, 01 Aug 2003 04:57:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h718vGbc031618 for seamoby-archive@odin.ietf.org; Fri, 1 Aug 2003 04:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVit-0008Ck-BW for seamoby-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 04: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 EAA03039 for ; Fri, 1 Aug 2003 04:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iViq-0003Yz-00 for seamoby-web-archive@ietf.org; Fri, 01 Aug 2003 04:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iVip-0003Yv-00 for seamoby-web-archive@ietf.org; Fri, 01 Aug 2003 04:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVif-0008Bv-AM; Fri, 01 Aug 2003 04: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 19iVi2-00088c-At for seamoby@optimus.ietf.org; Fri, 01 Aug 2003 04:56:22 -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 EAA03019 for ; Fri, 1 Aug 2003 04:56:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVhz-0003Yp-00 for seamoby@ietf.org; Fri, 01 Aug 2003 04:56:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19iVhy-0003Ym-00 for seamoby@ietf.org; Fri, 01 Aug 2003 04:56:18 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h718tiVI031726; Fri, 1 Aug 2003 10:55: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 501249D589; Fri, 1 Aug 2003 10:34:26 +0200 (CEST) Message-ID: <3F2A2B10.8000402@ccrle.nec.de> Date: Fri, 01 Aug 2003 10:55:44 +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: Vijay Devarapalli Cc: Seamoby Subject: Re: [Seamoby] CARD issue#29: more text on use of "Context-ID" and "M-flag"required References: <3F1FCBF8.6000301@ccrle.nec.de> <3F2575BD.BE68E5D2@iprg.nokia.com> 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 This is exactly what the current protocol description proposes. But only adding the L2_ID sub-option in the reply does not solve the problem. You can see in the example below that in case two or more L2_IDs connect to the "same" CAR, this is indicated with the M-flag (M=matched) in the L2_ID coming back to the MN with the CARD Reply. Sending back L2_ID with a CARD Reply in case this particular L2 ID does "not" connect to a CAR that has been already previously resolved, is redundant. Actually, a L2 ID that comes back with a CARD Reply could be taken already as an indicator that the respective context-ID has been adjusted to a previously received conext, this could avoid the M-flag. What do you think? marco Vijay Devarapalli wrote: >I am against using this mechanism. why not just include >the L2_ID suboption in the CARD reply too? ofcourse it >would increase the number of bytes in the CARD reply, >but I think it helps in reducing the overall complexity >of the CARD protocol. > >Vijay > >Marco Liebsch wrote: > > >>Hi all, >> >>going through the remaining open issues, there are some >>important ones, which have not been discussed during the >>meeting in Vienna. Here is one: >> >>There was a comment that more text w.r.t use of Context-ID >>and the M-flag is required. The proposal is to briefly describe >>the mechanism again and to solicit comments. After having agreed >>on a mechanism, more text will be added to the document. >>Please find a desciption/example of the proposed mechanism below: >> >>Since the L2 ID, a CAR's IP address and associated capabilities come >>with separate sub-options in a CARD Request/Reply message, >>association is indicated using a Context-ID. >>Example: >> >>MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR >>in a CARD Request for resolution: >> >>CARD Request (MN->AR) >>L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1 >>L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2 >> >>Now, first assume both L2_IDs (APs) connect to 2 different >>CARs, hence, associated IP address and capability container >>is identified with the respective Context-ID : >> >>CARD Reply (AR->MN) >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. >>IP address of CAR(2) comes with capability container(2), both carry Context-ID=2. >> >>Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR: >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. >>L2_ID(2) comes back with "Context-ID=1", "M-flag=1". >> >>M-flag avoids to send IP address and capability container of the same CAR >>back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed >>to Context-ID=1, M-flag indicates that Context-ID has been modified by the >>AR and that associated CAR IP address and associated capability container >>is the same as for a previously received IP-address/capability >>container pair, here indicated with Context-ID=1. >> >>Comments? >> >>marco >> >>_______________________________________________ >>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 Fri Aug 1 05:05:41 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 FAA03290 for ; Fri, 1 Aug 2003 05:05:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVqd-00008e-7w for seamoby-archive@odin.ietf.org; Fri, 01 Aug 2003 05:05:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7195Fig000526 for seamoby-archive@odin.ietf.org; Fri, 1 Aug 2003 05:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVqd-00008P-2p for seamoby-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 05:05: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 FAA03278 for ; Fri, 1 Aug 2003 05:05:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVqZ-0003cC-00 for seamoby-web-archive@ietf.org; Fri, 01 Aug 2003 05:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iVqZ-0003c9-00 for seamoby-web-archive@ietf.org; Fri, 01 Aug 2003 05:05:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVqO-0008Vg-Ry; Fri, 01 Aug 2003 05:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVq1-0008Tw-Gk for seamoby@optimus.ietf.org; Fri, 01 Aug 2003 05:04: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 FAA03275 for ; Fri, 1 Aug 2003 05:04:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVpy-0003c2-00 for seamoby@ietf.org; Fri, 01 Aug 2003 05:04:34 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19iVpx-0003bz-00 for seamoby@ietf.org; Fri, 01 Aug 2003 05:04:33 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h71944VI032580; Fri, 1 Aug 2003 11:04:04 +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 8770D8900F; Fri, 1 Aug 2003 10:42:46 +0200 (CEST) Message-ID: <3F2A2D04.1050606@ccrle.nec.de> Date: Fri, 01 Aug 2003 11:04:04 +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: Vijay Devarapalli Cc: Seamoby Subject: Re: [Seamoby] CARD issue#30: L2 type indicators to be assigned by IANA References: <3F1FE773.7090703@ccrle.nec.de> <3F2577BD.EC02A19D@iprg.nokia.com> 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 Following James' proposal, we can check whether of not there are already type indicators assigned, which can be re-used. However, in case there are no proper values available, is it preferred to drop this field or should we go for requesting a sample of technology IDs (Ethernet, IEEE802.11b, ...)? I think it could be reasonable to have this indicator in a L2 ID, hence I support James' proposal to request an ID for one or two technologies. What do you think? marco Vijay Devarapalli wrote: >I dont see any other option. IANA assignment is needed. >otherwise how can the AR and the MN agree to the same >type values for different types of interfaces? > > > >>One of the comments to the L2 ID sub-option was that >>"L2-type" identifiers need to be assigned by IANA. >>Now, I assume that in case we ask IANA for type >>identifiers, we need to give also a list of interface >>types. This lists needs then to be extended later for >>future technologies... >> >> > >this means there is a fundamental problem. maybe you >should remove the L2 type field from the L2_ID suboption. >it is considered optional already. the Sub-Option Len >can indicate the length of the L2 ID field. > > > >>I am not sure if this is really required for the >>experimental protocol. Take into account that using >>the L2-type identifier has been indicated to be >>optional. >> >>Comments? >> >>marco >> >>_______________________________________________ >>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 Aug 4 11:34: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 SMTP id LAA01729 for ; Mon, 4 Aug 2003 11:34: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 19jhLY-00028v-SL for seamoby-archive@odin.ietf.org; Mon, 04 Aug 2003 11:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74FY4eJ008231 for seamoby-archive@odin.ietf.org; Mon, 4 Aug 2003 11:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhLY-00028g-Nw for seamoby-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 11:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01691 for ; Mon, 4 Aug 2003 11:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhLX-0002yI-00 for seamoby-web-archive@ietf.org; Mon, 04 Aug 2003 11:34:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jhLX-0002yE-00 for seamoby-web-archive@ietf.org; Mon, 04 Aug 2003 11:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhLV-00027z-I5; Mon, 04 Aug 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhLR-00027X-6Q for seamoby@optimus.ietf.org; Mon, 04 Aug 2003 11:33:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01674 for ; Mon, 4 Aug 2003 11:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhLQ-0002xi-00 for seamoby@ietf.org; Mon, 04 Aug 2003 11:33:56 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19jhLO-0002wc-00 for seamoby@ietf.org; Mon, 04 Aug 2003 11:33:54 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h74FW6VI050101 for ; Mon, 4 Aug 2003 17:32:07 +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 B52F543E30 for ; Mon, 4 Aug 2003 17:10:16 +0200 (CEST) Message-ID: <3F2E7C76.3020301@ccrle.nec.de> Date: Mon, 04 Aug 2003 17:32:06 +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 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD issue#40: Proposal is to use 16 bit length indicator for CARD options 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, let me bring up issue#40 again, which proposes to extend the CARD option length to 16 bit. Referring to Pat's mail, this issue is still open and we did not get a consensus yet. However, proposal was to extend the 8 bit lenght to 16 bit length field, still indicating number of bytes as unit. Comments? marco --------- from Pat's mail ----------- 2. Issue #40: 8 bit CARD option length not enough. The proposal is to extend the length of the field to 16 bit. There is no consensus, and this needs to be taken to the list. comments? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 5 10:30: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 KAA13642 for ; Tue, 5 Aug 2003 10:30: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 19k2pA-0001T9-AG for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 10:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75EU4Zu005643 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 10:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2pA-0001Sw-71 for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:30: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 KAA13579 for ; Tue, 5 Aug 2003 10:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2p7-0002RF-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10:30:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2p7-0002RC-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2p8-0001S8-5X; Tue, 05 Aug 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2on-0001RV-KG for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 10:29:41 -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 KAA13568 for ; Tue, 5 Aug 2003 10:29:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2ol-0002R0-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:29:39 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19k2ok-0002Qw-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:29:38 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h75ETbLe011626 for ; Tue, 5 Aug 2003 07:29:37 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h75ETTrx011627 for ; Tue, 5 Aug 2003 09:29:29 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Tue, 5 Aug 2003 09:29:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A26A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat R. Calhoun'" , seamoby@ietf.org Subject: RE: [Seamoby] Opinions on unresolved CARD issues Date: Tue, 5 Aug 2003 09:29:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) 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: , 1. Issue #23: Protection of broadcast unsolicited CARD reply messages. A broadcast unsolicted CARD reply message cannot be protected with IPSec, so how are the SAs established? Similar problem to Router Advertisements. If we leave broadcast/multicast to be determined (see issue #6) then this does not need to be solved right now. There is no WG consensus at this time - we need to take this to the list. comments please. AJOY-> We have not heard any comments so far. So, We are assuming that this issue need not be addressed by the CARD protocol. Any comments? We are assuming that CARD protocol is not required to solve this issue in short term. Any comments? -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Friday, July 18, 2003 1:21 AM To: seamoby@ietf.org Subject: [Seamoby] Opinions on unresolved CARD issues Below are the issues that we were unable to get some resolution at the meeting in Vienna. Please send your comments on the following two issues: 1. Issue #23: Protection of broadcast unsolicited CARD reply messages. A broadcast unsolicted CARD reply message cannot be protected with IPSec, so how are the SAs established? Similar problem to Router Advertisements. If we leave broadcast/multicast to be determined (see issue #6) then this does not need to be solved right now. There is no WG consensus at this time - we need to take this to the list. comments please. 2. Issue #40: 8 bit CARD option length not enough. The proposal is to extend the length of the field to 16 bit. There is no consensus, and this needs to be taken to the list. comments? Thanks, Pat & James _______________________________________________ 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 Aug 5 10:46: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 KAA14053 for ; Tue, 5 Aug 2003 10:46: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 19k34f-0002Gy-Ie for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 10:46:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Ek5KY008730 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 10: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 19k34f-0002GP-Dt for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:46: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 KAA14045 for ; Tue, 5 Aug 2003 10:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k34c-0002XP-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k34c-0002XM-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10: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 19k34c-0002EU-H7; Tue, 05 Aug 2003 10: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 19k34F-0002Dy-VP for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 10:45: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 KAA14037 for ; Tue, 5 Aug 2003 10:45:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k34D-0002XD-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:45:37 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19k34C-0002XA-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:45:36 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h75EjZLe023506 for ; Tue, 5 Aug 2003 07:45:35 -0700 (MST) Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h75EjWke004576 for ; Tue, 5 Aug 2003 09:45:33 -0500 Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Tue, 5 Aug 2003 09:45:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A26B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat R. Calhoun'" , seamoby@ietf.org Subject: RE: [Seamoby] (virtual) hum on CARD open issues Date: Tue, 5 Aug 2003 09:45:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) 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: , 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit. AJOY-> We need WG consensus about this issue. So far Vijay has suggested us to drop the "S" bit but we have not heard from other members of the WG. Should we drop the "S" bit or keep it? Please send your comments. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 5 10:56: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 KAA14659 for ; Tue, 5 Aug 2003 10:56: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 19k3EO-0002cf-5D for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 10:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Eu8jH010075 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 10:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3EN-0002cQ-Nb for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:56: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 KAA14586 for ; Tue, 5 Aug 2003 10:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3EG-0002fw-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10:56:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k3EF-0002ft-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 10:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3EG-0002a7-Qa; Tue, 05 Aug 2003 10:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3DY-0002Sm-Er for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 10:55: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 KAA14336 for ; Tue, 5 Aug 2003 10:55:05 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3DQ-0002dS-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:55:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19k3DP-0002dI-00 for seamoby@ietf.org; Tue, 05 Aug 2003 10:55:07 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h75Et5B24037 for ; Tue, 5 Aug 2003 17:55:05 +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, 5 Aug 2003 17:55:04 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 17:55:04 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 5 Aug 2003 07:54:52 -0700 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] (virtual) hum on CARD open issues Date: Tue, 5 Aug 2003 10:54:51 -0400 Message-ID: Thread-Topic: [Seamoby] (virtual) hum on CARD open issues Thread-Index: AcNbYFJiRRtFyg+WSOm0Gb/GX/bhYQAAIwpQ To: , , X-OriginalArrivalTime: 05 Aug 2003 14:54:52.0271 (UTC) FILETIME=[867B9FF0:01C35B61] 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 Participating in the online humming ;-) I support the meeting consensus to keep the S-bit.=20 Reducing air bandwidth usage still ranks higher in my priority than = processing overhead,=20 in particular since we don't quite have an understanding as to how many = capabilities we might=20 have in the future.=20 Further, keeping the S-bit for now also allows to still go for the = "lifetime=3D0 equals static capability" later, deprecating the S-bit usage (having it in the = structure does not really hurt), when progressing with the experimental draft. Dirk >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Tuesday, August 05, 2003 10:45 AM >To: 'Pat R. Calhoun'; seamoby@ietf.org >Subject: RE: [Seamoby] (virtual) hum on CARD open issues > > >4. Issue #5: Static vs. dynamic capability attributes. The=20 >editor recommends that we keep the S-bit and use the 32-bit=20 >lifetime only when really required for dynamic capabilities.=20 >This saves bandwidth, but does complicate processing. Meeting=20 >consensus is to keep S-bit. > >AJOY-> We need WG consensus about this issue. So far Vijay has=20 >suggested us to drop the "S" bit but we have not heard from=20 >other members of the WG. Should we drop the "S" bit or keep=20 >it? Please send your comments. > > > > > > > > > >_______________________________________________ >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 Aug 5 14:21:41 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 OAA21046 for ; Tue, 5 Aug 2003 14:21:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6Qs-0001cw-Ok for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 14:21:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75ILEuv006255 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 14:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6Qs-0001co-Ei for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 14:21:14 -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 OAA21027 for ; Tue, 5 Aug 2003 14:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6Qp-0004Qv-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 14:21:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k6Qp-0004Qr-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 14:21:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6Qf-0001c4-Hi; Tue, 05 Aug 2003 14: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 19k6Ph-0001al-Lu for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 14:20: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 OAA20990 for ; Tue, 5 Aug 2003 14:19:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6Pf-0004Qg-00 for seamoby@ietf.org; Tue, 05 Aug 2003 14:19:59 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k6Pd-0004QI-00 for seamoby@ietf.org; Tue, 05 Aug 2003 14:19:58 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA14099; Tue, 5 Aug 2003 11:19:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75IJPY27869; Tue, 5 Aug 2003 11:19:25 -0700 X-mProtect: <200308051819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNLaU0b; Tue, 05 Aug 2003 11:19:22 PDT Message-ID: <3F2FF52B.9CF228FA@iprg.nokia.com> Date: Tue, 05 Aug 2003 11:19:23 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Pat R. Calhoun'" , seamoby@ietf.org Subject: Re: [Seamoby] Opinions on unresolved CARD issues References: <35DBB8B7AC89D4118E98009027B1009B1221A26A@IL27EXM10.cig.mot.com> 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 Singh Ajoy-ASINGH1 wrote: > > 1. Issue #23: Protection of broadcast unsolicited CARD reply messages. A broadcast unsolicted CARD reply message cannot be protected with IPSec, so how are the SAs established? Similar problem to Router Advertisements. If we leave broadcast/multicast to be determined (see issue #6) then this does not need to be solved right now. There is no WG consensus at this time - we need to take this to the list. comments please. > > AJOY-> We have not heard any comments so far. So, We are assuming that this issue need not be addressed by the CARD protocol. Any comments? > > We are assuming that CARD protocol is not required to solve this issue in short term. Any comments? currently you cannot protect broadcast messsages with IPsec. multicast messages could be protected if all the members of the multicast group have the key. so you should probably just mention this in the spec. the spec shouldnt assume unsolicited CARD reply messages will be protected and remain silent. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 5 14:24: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 OAA21231 for ; Tue, 5 Aug 2003 14:24: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 19k6Ta-0001jE-Pe for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 14:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75IO2mY006638 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 14:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6Ta-0001iz-MF for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 14:24: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 OAA21097 for ; Tue, 5 Aug 2003 14:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6TY-0004S4-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 14:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k6TX-0004S1-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 14:23:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6TZ-0001iI-Hf; Tue, 05 Aug 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6TP-0001i2-2N for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 14:23: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 OAA21088 for ; Tue, 5 Aug 2003 14:23:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6TM-0004Rq-00 for seamoby@ietf.org; Tue, 05 Aug 2003 14:23:48 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k6TL-0004Rm-00 for seamoby@ietf.org; Tue, 05 Aug 2003 14:23:47 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA14278; Tue, 5 Aug 2003 11:23:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75INGa32052; Tue, 5 Aug 2003 11:23:16 -0700 X-mProtect: <200308051823> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFStJKd; Tue, 05 Aug 2003 11:23:14 PDT Message-ID: <3F2FF612.A2D24FA8@iprg.nokia.com> Date: Tue, 05 Aug 2003 11:23:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Pat R. Calhoun'" , seamoby@ietf.org Subject: Re: [Seamoby] (virtual) hum on CARD open issues References: <35DBB8B7AC89D4118E98009027B1009B1221A26B@IL27EXM10.cig.mot.com> 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 Singh Ajoy-ASINGH1 wrote: > > 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit. > > AJOY-> We need WG consensus about this issue. So far Vijay has suggested us to drop the "S" bit but we have not heard from other members of the WG. Should we drop the "S" bit or keep it? Please send your comments. I suggested an alternative to make the lifetime field a bit shorter, from 4 bytes to 2 bytes. 65535 seconds should be enough to specify the lifetime of an attribute. you should also keep in mind the point Robert Chalmers made. having an optional field in the middle of a data structure is plain bad for implementations. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 5 15:48: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 PAA26252 for ; Tue, 5 Aug 2003 15:48: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 19k7mu-0005Ze-T6 for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 15:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Jm44G021420 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 15:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7mu-0005ZP-Pu for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 15:48: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 PAA26249 for ; Tue, 5 Aug 2003 15:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7mt-0005Je-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 15:48:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k7ms-0005Jb-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 15:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7mr-0005Yd-Nv; Tue, 05 Aug 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7md-0005YL-Qk for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 15:47:47 -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 PAA26223 for ; Tue, 5 Aug 2003 15:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7mc-0005Iu-00 for seamoby@ietf.org; Tue, 05 Aug 2003 15:47:46 -0400 Received: from bay2-f164.bay2.hotmail.com ([65.54.247.164] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19k7mb-0005Io-00 for seamoby@ietf.org; Tue, 05 Aug 2003 15:47:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Aug 2003 12:47:15 -0700 Received: from 63.78.179.5 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 05 Aug 2003 19:47:15 GMT X-Originating-IP: [63.78.179.5] X-Originating-Email: [hchaskar@hotmail.com] From: "Hemant Chaskar" To: vijayd@iprg.nokia.com, ASINGH1@motorola.com Cc: pcalhoun@airespace.com, seamoby@ietf.org Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Tue, 05 Aug 2003 19:47:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Aug 2003 19:47:15.0624 (UTC) FILETIME=[5F22DA80:01C35B8A] 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: , Having optional field may be bad/may not be bad, I do not know. But this has been case even in IPv6. There are optional headers in IPv6. If those can be handled, why can't this be? My 2 cents - Hemant. >From: Vijay Devarapalli >To: Singh Ajoy-ASINGH1 >CC: "'Pat R. Calhoun'" , seamoby@ietf.org >Subject: Re: [Seamoby] (virtual) hum on CARD open issues >Date: Tue, 05 Aug 2003 11:23:14 -0700 > >Singh Ajoy-ASINGH1 wrote: > > > > 4. Issue #5: Static vs. dynamic capability attributes. The editor >recommends that we keep the S-bit and use the 32-bit lifetime only when >really required for dynamic capabilities. This saves bandwidth, but does >complicate processing. Meeting consensus is to keep S-bit. > > > > AJOY-> We need WG consensus about this issue. So far Vijay has suggested >us to drop the "S" bit but we have not heard from other members of the WG. >Should we drop the "S" bit or keep it? Please send your comments. > >I suggested an alternative to make the lifetime field >a bit shorter, from 4 bytes to 2 bytes. 65535 seconds >should be enough to specify the lifetime of an attribute. > >you should also keep in mind the point Robert Chalmers >made. having an optional field in the middle of a data >structure is plain bad for implementations. > >Vijay > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 5 16:52: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 QAA28322 for ; Tue, 5 Aug 2003 16:52: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 19k8ms-0008Pz-VK for seamoby-archive@odin.ietf.org; Tue, 05 Aug 2003 16:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Kq61J032353 for seamoby-archive@odin.ietf.org; Tue, 5 Aug 2003 16:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8ms-0008Pk-Rp for seamoby-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 16:52: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 QAA28308 for ; Tue, 5 Aug 2003 16:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8mq-0005or-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 16:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8mq-0005oo-00 for seamoby-web-archive@ietf.org; Tue, 05 Aug 2003 16:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8mo-0008Os-2U; Tue, 05 Aug 2003 16:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8lz-0008Nk-2P for seamoby@optimus.ietf.org; Tue, 05 Aug 2003 16:51: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 QAA28291 for ; Tue, 5 Aug 2003 16:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8lx-0005oa-00 for seamoby@ietf.org; Tue, 05 Aug 2003 16:51:09 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k8lw-0005oA-00 for seamoby@ietf.org; Tue, 05 Aug 2003 16:51:08 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22995; Tue, 5 Aug 2003 13:50:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75Koaa09128; Tue, 5 Aug 2003 13:50:36 -0700 X-mProtect: <200308052050> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdamn94h; Tue, 05 Aug 2003 13:50:34 PDT Message-ID: <3F30189B.679C1D23@iprg.nokia.com> Date: Tue, 05 Aug 2003 13:50:35 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant Chaskar CC: ASINGH1@motorola.com, pcalhoun@airespace.com, seamoby@ietf.org Subject: Re: [Seamoby] (virtual) hum on CARD open issues References: 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 Hemant Chaskar wrote: > > Having optional field may be bad/may not be bad, I do not know. But this has > been case even in IPv6. There are optional headers in IPv6. If those can be > handled, why can't this be? its a totally different thing. the entire IPv6 packet is never copied onto a singe data structure. and IPv6 has a nice header chaining mechanism to process one protocol header after the other. Vijay > > >From: Vijay Devarapalli > >To: Singh Ajoy-ASINGH1 > >CC: "'Pat R. Calhoun'" , seamoby@ietf.org > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > >Date: Tue, 05 Aug 2003 11:23:14 -0700 > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > 4. Issue #5: Static vs. dynamic capability attributes. The editor > >recommends that we keep the S-bit and use the 32-bit lifetime only when > >really required for dynamic capabilities. This saves bandwidth, but does > >complicate processing. Meeting consensus is to keep S-bit. > > > > > > AJOY-> We need WG consensus about this issue. So far Vijay has suggested > >us to drop the "S" bit but we have not heard from other members of the WG. > >Should we drop the "S" bit or keep it? Please send your comments. > > > >I suggested an alternative to make the lifetime field > >a bit shorter, from 4 bytes to 2 bytes. 65535 seconds > >should be enough to specify the lifetime of an attribute. > > > >you should also keep in mind the point Robert Chalmers > >made. having an optional field in the middle of a data > >structure is plain bad for implementations. > > > >Vijay > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Aug 6 13:15: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 NAA25188 for ; Wed, 6 Aug 2003 13:15: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 19kRsO-0007Ad-QK for seamoby-archive@odin.ietf.org; Wed, 06 Aug 2003 13:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HF4sg027559 for seamoby-archive@odin.ietf.org; Wed, 6 Aug 2003 13:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRsO-0007AQ-Ll for seamoby-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:15: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 NAA25177 for ; Wed, 6 Aug 2003 13:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRsM-0004nY-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 13:15:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kRsM-0004nV-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 13:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRsL-00079i-Ea; Wed, 06 Aug 2003 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRrT-00078h-14 for seamoby@optimus.ietf.org; Wed, 06 Aug 2003 13:14: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 NAA25139 for ; Wed, 6 Aug 2003 13:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRrR-0004mq-00 for seamoby@ietf.org; Wed, 06 Aug 2003 13:14:05 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19kRrQ-0004md-00 for seamoby@ietf.org; Wed, 06 Aug 2003 13:14:04 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h76HDLVI074996; Wed, 6 Aug 2003 19:13:21 +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 72D32E4D8; Wed, 6 Aug 2003 18:51:11 +0200 (CEST) Message-ID: <3F313730.2090101@ccrle.nec.de> Date: Wed, 06 Aug 2003 19:13:20 +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: James Kempf Cc: Hemant Chaskar , vijayd@iprg.nokia.com, ASINGH1@motorola.com, pcalhoun@airespace.com, seamoby@ietf.org Subject: CARD issue#2: rate limiting - about to be closed /Re: [Seamoby] (virtual) hum on CARD open issues References: <016e01c353a8$59b08e60$2a6015ac@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 Since there were no further comments to this issue and the respective proposal, I guess we can regard this issue as closed and take over the proposed approach on rate limiting to the document. marco James Kempf wrote: >I agree. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: >Cc: ; ; >; >Sent: Monday, July 21, 2003 7:37 PM >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > >>Hi all, >> >>Does WG agree to text provided by Vijay? Pat, James could you do consensus >>call on this text. >> >>Hemant >> >> >> >>>From: Vijay Devarapalli >>>To: Hemant Chaskar >>>CC: ASINGH1@motorola.com, pcalhoun@airespace.com, >>> >>> >kempf@docomolabs-usa.com, > > >>> seamoby@ietf.org >>>Subject: Re: [Seamoby] (virtual) hum on CARD open issues >>>Date: Mon, 21 Jul 2003 09:37:26 -0700 >>> >>> >>>I already provided the text when I reviewed the CARD protocol. >>> >>> The MN MUST send only one CARD Request per >>> CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. >>> If the MN sends requests more frequently, the AR SHOULD drop the >>> CARD requests and not process them. >>> >>>and add to the constants section >>> >>> CARD_RETRANSMISSION_INTERVAL 1 second >>> CARD_MAX_RETRIES 3 >>> >>>this is similar to ICMP rate limiting. >>> >>>TCP rate limiting is different, not applicable here. in general >>>in any protocol where there is a request and a reply (and no >>>more messages), ICMP rate limiting is best suited. you dont have >>>to "source-quench" the Mobile Node. :) >>> >>>Vijay >>> >>>Hemant Chaskar wrote: >>> >>> >>>>Dear Vijay, >>>> >>>>Could you provide a text to be included in the draft on rate limiting. >>>> >>>> >>>We >>> >>> >>>>can include it in the draft after discussing it over mailing list. It >>>>probably wont suffice to say that rate limiting is in lot of protocols >>>> >>>> >>>and >>> >>> >>>>hence not needed here. Different protocols use different rate >>>> >>>> >limiting. > > >>>E.g. >>> >>> >>>>TCP uses rate limiting, but it wont be appropriate for CARD. >>>> >>>>If you are proposing to limit the rate by simply enforcing limit on >>>>aggregate rate of requests, I can easily argue that it is ineffective. >>>> >>>> >>>So >>> >>> >>>>the question is: Wheater WG wants per MN rate limiting? If so, does it >>>> >>>> >>>have >>> >>> >>>>to be using R flag or using limit on per-MN rate of request? And then, >>>> >>>> >>>you >>> >>> >>>>can refer us to protocol that uses that type of rate limiting and we >>>> >>>> >>>will >>> >>> >>>>simply refer to it - will save lot of writing. >>>> >>>>Hemant >>>> >>>> >>>> >>>>>From: Vijay Devarapalli >>>>>To: Singh Ajoy-ASINGH1 >>>>>CC: "Pat R. Calhoun" , >>>>> >>>>> >>>kempf@docomolabs-usa.com, >>> >>> >>>>> seamoby@ietf.org >>>>>Subject: Re: [Seamoby] (virtual) hum on CARD open issues >>>>>Date: Fri, 18 Jul 2003 15:39:12 -0700 >>>>> >>>>>Singh Ajoy-ASINGH1 wrote: >>>>> >>>>> >>>>>>>1. Issue #2: R-flag for CARD Request rate limiting. What to do >>>>>>> >>>>>>> >>>about >>> >>> >>>>>potential Dos issues? WG consensus is to Keep the R-flag approach. >>>>> >>>>> >>>Meeting >>> >>> >>>>>consensus is to add clarifying text to section 4.2 (4.3?) >>>>> >>>>> >>>>>>this is wrong, IMHO. rate limiting is a well known mechanism. >>>>>>introducing a new flag is not a bright idea. >>>>>> >>>>>>ajoy-> Why it is a bad idea? Well, I am neutral in this >>>>>>issue but I am not convinced why using R bit is worse than >>>>>>your proposed solution. >>>>>> >>>>>> >>>>>simple. rate-limiting is implemented in a wide variety of >>>>>protocols (infact for any message that creates state at >>>>>the receiving node). nothing new here. you dont need a new >>>>>mechanism for this. >>>>> >>>>> >>>>> >>>>>>>3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. >>>>>>> >>>>>>> >>>The >>> >>> >>>>>editor recommends the use of ICMP to make it consistent with the >>>>> >>>>> >mobile > > >>>>>interface. Potential downsides: ICMP has potential security >>>>> >>>>> >>>implications. >>> >>> >>>>>ICMP message types on binding is also very implementation specific. >>>>> >>>>> >>>Also, >>> >>> >>>>>securing ICMP would require that all ICMP packets be secured. Meeting >>>>>consensus is to keep UDP. >>>>> >>>>> >>>>>>2 and 3 dont go togetheer. defining CARD messages as ICMP >>>>>>options lets you piggyback these options on FMIPv6 messages. >>>>>>I am not sure how you can achieve piggybacking if the MN-AR >>>>>>signaling becomes UDP. ICMP was the right choice between >>>>>>the MN and the AR. >>>>>> >>>>>>AJOY-> Well I did not attend IETF meeting, but I guess this means >>>>>> >>>>>> >>>ICMP >>> >>> >>>>>for >>>>> >>>>> >>>>>>MN-AR and UDP for AR-AR interface. Others' please correct me. >>>>>> >>>>>> >>>>>oops... I misunderstood. I thought the concensus at the >>>>>meeting was to use UDP for both. >>>>> >>>>> >>>>> >>>>>>BTW, why are you in favor of >>>>>>using ICMP for AR-AR interface? >>>>>> >>>>>> >>>>>otherwise you need seperate code for processing an ICMP >>>>>CARD Request (from the MN) and UDP CARD Request (from >>>>>the PAR). also, if it is an ICMP message, I can piggyback >>>>>CARD messages on HI/HACK messages of FMIPv6. >>>>> >>>>> >>>>> >>>>> >>>>>>unbelievable. the CARD protocol is already complicated (IMO). >>>>>>the emphasis should be on reducing the complexity. just use >>>>>>a value of infinity for the lifetime field to indicate a >>>>>>static capability. any other value for the lifetime indicates >>>>>>dynamic capability. I think for the CARD protocol, emphasis >>>>>>should be on making it a simpler protocol than saving 4 bytes >>>>>>over the air. :) >>>>>> >>>>>>if you are concerned about an overhead of 4 bytes, make the >>>>>>lifetime field 2 bytes. a 2 byte lifetime field gives you >>>>>>65536 seconds which should be enough. do you need a 4 byte >>>>>>lifetime field? >>>>>> >>>>>>AJOY-> I disagree here. Saving even 2 bytes per capability is >>>>>>huge saving for bandwidth constraint network. I am not sure >>>>>>processing one flag will make CARD protocol any more complicated. >>>>>>Btw, in cellular standard I have seen even more complicated >>>>>>procedure for saving 4 bits per frame. Please note that >>>>>>the CARD protocol is being proposed as an experimental >>>>>>protocol so we will have opportunity to make such >>>>>>changes in future if required. >>>>>> >>>>>> >>>>>but in the current form not many people are going to use >>>>>it. it might remain forever as an experimental, untouched, >>>>>ignored, just another RFC.... that is something we should >>>>>avoid. I want a protocol that I can use. :) >>>>> >>>>>Vijay >>>>> >>>>>_______________________________________________ >>>>>Seamoby mailing list >>>>>Seamoby@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/seamoby >>>>> >>>>> >>>>_________________________________________________________________ >>>>Add photos to your e-mail with MSN 8. Get 2 months FREE*. >>>>http://join.msn.com/?page=features/featuredemail >>>> >>>> >>_________________________________________________________________ >>Help STOP SPAM with the new MSN 8 and get 2 months FREE* >>http://join.msn.com/?page=features/junkmail >> >> >> >> > > >_______________________________________________ >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 Aug 6 16:51: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 QAA04174 for ; Wed, 6 Aug 2003 16:51: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 19kVFQ-000117-9P for seamoby-archive@odin.ietf.org; Wed, 06 Aug 2003 16:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Kp4Nn003905 for seamoby-archive@odin.ietf.org; Wed, 6 Aug 2003 16: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 19kVFQ-00010u-6e for seamoby-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 16: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 QAA04154 for ; Wed, 6 Aug 2003 16:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kVFO-0006wu-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 16:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kVFN-0006wn-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 16: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 19kVFN-0000zU-3l; Wed, 06 Aug 2003 16:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kVEW-0000oY-Ph for seamoby@optimus.ietf.org; Wed, 06 Aug 2003 16:50: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 QAA04086 for ; Wed, 6 Aug 2003 16:50:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kVEU-0006v9-00 for seamoby@ietf.org; Wed, 06 Aug 2003 16:50:06 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19kVEU-0006v6-00 for seamoby@ietf.org; Wed, 06 Aug 2003 16:50:06 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h76Ko5023616 for ; Wed, 6 Aug 2003 16:50:06 -0400 Date: Wed, 6 Aug 2003 16:50:05 -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 registration is now open! 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: , The on-line registration system for MobiCom 2003 is now open. MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in beautiful, sunny San Diego, California. Sponsored by ACM SIGMOBILE, MobiCom is the premier international forum focusing on all areas of mobile computing and mobile and wireless networking at the link layer and above. The MobiCom 2003 program will feature: - Presentation of 27 technical papers describing the best of recent research in mobile computing and mobile and wireless networking - Two days of tutorials, with 1 full-day tutorial and 4 half-day tutorials, covering background and advanced topics in mobile computing and networking - Six full-day workshops on emerging topics related to mobile computing and networking - Research demos, plus exhibits of the latest mobile computing and networking products and services - A conference dinner banquet cruise aboard the Spirit of San Diego, offering an excellent dining experience, great views of San Diego bay, and opportunities for socializing with the other conference participants - A student poster session, panel discussion, Welcome Reception, and other events you won't want to miss For more information, please see the MobiCom 2003 web site at http://www.sigmobile.org/mobicom/2003/ The deadline for special discounted registration fees for early registration is August 28, 2003. Registration after September 5, 2003 will be accepted on-site only. 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 Aug 6 19:05: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 TAA09630 for ; Wed, 6 Aug 2003 19:05: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 19kXL6-0006jC-IW for seamoby-archive@odin.ietf.org; Wed, 06 Aug 2003 19:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76N54R2025858 for seamoby-archive@odin.ietf.org; Wed, 6 Aug 2003 19:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXL6-0006iz-FI for seamoby-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 19:05: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 TAA09627 for ; Wed, 6 Aug 2003 19:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXL3-0000I5-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 19:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kXL2-0000I2-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 19:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXL3-0006iD-6K; Wed, 06 Aug 2003 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXKJ-0006hv-F6 for seamoby@optimus.ietf.org; Wed, 06 Aug 2003 19:04: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 TAA09622 for ; Wed, 6 Aug 2003 19:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXKG-0000Ht-00 for seamoby@ietf.org; Wed, 06 Aug 2003 19:04:12 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kXKF-0000Hl-00 for seamoby@ietf.org; Wed, 06 Aug 2003 19:04:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76N3YM11405; Wed, 6 Aug 2003 16:03:34 -0700 X-mProtect: <200308062303> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9r0Rb9; Wed, 06 Aug 2003 16:03:32 PDT Message-ID: <3F318945.E07D1AEB@iprg.nokia.com> Date: Wed, 06 Aug 2003 16:03:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Liebsch CC: Seamoby Subject: Re: [Seamoby] CARD issue#30: L2 type indicators to be assigned byIANA References: <3F1FE773.7090703@ccrle.nec.de> <3F2577BD.EC02A19D@iprg.nokia.com> <3F2A2D04.1050606@ccrle.nec.de> 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 Marco Liebsch wrote: > > Following James' proposal, we can check whether of not there are > already type indicators assigned, which can be re-used. > However, in case there are no proper values available, > is it preferred to drop this field or should we go for requesting > a sample of technology IDs (Ethernet, IEEE802.11b, ...)? > I think it could be reasonable to have this indicator in a > L2 ID, hence I support James' proposal to request an ID for > one or two technologies. > > What do you think? sure. as long as IANA assigns L2 type values, there wont be any interop problems. Vijay > > marco > > Vijay Devarapalli wrote: > > >I dont see any other option. IANA assignment is needed. > >otherwise how can the AR and the MN agree to the same > >type values for different types of interfaces? > > > > > > > >>One of the comments to the L2 ID sub-option was that > >>"L2-type" identifiers need to be assigned by IANA. > >>Now, I assume that in case we ask IANA for type > >>identifiers, we need to give also a list of interface > >>types. This lists needs then to be extended later for > >>future technologies... > >> > >> > > > >this means there is a fundamental problem. maybe you > >should remove the L2 type field from the L2_ID suboption. > >it is considered optional already. the Sub-Option Len > >can indicate the length of the L2 ID field. > > > > > > > >>I am not sure if this is really required for the > >>experimental protocol. Take into account that using > >>the L2-type identifier has been indicated to be > >>optional. > >> > >>Comments? > >> > >>marco > >> > >>_______________________________________________ > >>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 Aug 6 19:27: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 TAA09985 for ; Wed, 6 Aug 2003 19:27: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 19kXgN-0007WZ-Ao for seamoby-archive@odin.ietf.org; Wed, 06 Aug 2003 19:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76NR3ed028918 for seamoby-archive@odin.ietf.org; Wed, 6 Aug 2003 19: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 19kXgN-0007WL-7U for seamoby-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 19:27: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 TAA09974 for ; Wed, 6 Aug 2003 19:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXgL-0000OP-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 19:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kXgK-0000OM-00 for seamoby-web-archive@ietf.org; Wed, 06 Aug 2003 19: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 19kXgK-0007V2-Nc; Wed, 06 Aug 2003 19:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXgG-0007Uc-FP for seamoby@optimus.ietf.org; Wed, 06 Aug 2003 19:26:56 -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 TAA09966 for ; Wed, 6 Aug 2003 19:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXgE-0000OD-00 for seamoby@ietf.org; Wed, 06 Aug 2003 19:26:54 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kXgD-0000Nx-00 for seamoby@ietf.org; Wed, 06 Aug 2003 19:26:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76NQGk22909; Wed, 6 Aug 2003 16:26:16 -0700 X-mProtect: <200308062326> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8o9LEi; Wed, 06 Aug 2003 16:26:15 PDT Message-ID: <3F318E97.3AF2682C@iprg.nokia.com> Date: Wed, 06 Aug 2003 16:26:15 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Liebsch CC: Seamoby Subject: Re: [Seamoby] CARD issue#29: more text on use of "Context-ID" and"M-flag"required References: <3F1FCBF8.6000301@ccrle.nec.de> <3F2575BD.BE68E5D2@iprg.nokia.com> <3F2A2B10.8000402@ccrle.nec.de> 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 Marco Liebsch wrote: > > This is exactly what the current protocol description proposes. But only > adding the L2_ID sub-option in the reply does not solve the problem. You > can see in the > example below that in case two or more L2_IDs connect to the "same" CAR, > this is indicated with the M-flag (M=matched) in the L2_ID coming back > to the MN with the > CARD Reply. Sending back L2_ID with a CARD Reply in case this > particular L2 ID does "not" connect to a CAR that has been already > previously resolved, is redundant. Actually, a L2 ID that comes back with > a CARD Reply could be taken already as an indicator that the respective > context-ID > has been adjusted to a previously received conext, this could avoid the > M-flag. > > What do you think? this sounds fine. but now there is a need to explain how the Context-ID is managed at the MN. the MN needs to store the Context-ID along with the information it stores for a particular L2-ID. and it probably makes sense to use a linearly increasing number space for the Context-ID so that Context-IDs are not reused often. Vijay > > marco > > Vijay Devarapalli wrote: > > >I am against using this mechanism. why not just include > >the L2_ID suboption in the CARD reply too? ofcourse it > >would increase the number of bytes in the CARD reply, > >but I think it helps in reducing the overall complexity > >of the CARD protocol. > > > >Vijay > > > >Marco Liebsch wrote: > > > > > >>Hi all, > >> > >>going through the remaining open issues, there are some > >>important ones, which have not been discussed during the > >>meeting in Vienna. Here is one: > >> > >>There was a comment that more text w.r.t use of Context-ID > >>and the M-flag is required. The proposal is to briefly describe > >>the mechanism again and to solicit comments. After having agreed > >>on a mechanism, more text will be added to the document. > >>Please find a desciption/example of the proposed mechanism below: > >> > >>Since the L2 ID, a CAR's IP address and associated capabilities come > >>with separate sub-options in a CARD Request/Reply message, > >>association is indicated using a Context-ID. > >>Example: > >> > >>MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR > >>in a CARD Request for resolution: > >> > >>CARD Request (MN->AR) > >>L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1 > >>L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2 > >> > >>Now, first assume both L2_IDs (APs) connect to 2 different > >>CARs, hence, associated IP address and capability container > >>is identified with the respective Context-ID : > >> > >>CARD Reply (AR->MN) > >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. > >>IP address of CAR(2) comes with capability container(2), both carry Context-ID=2. > >> > >>Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR: > >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. > >>L2_ID(2) comes back with "Context-ID=1", "M-flag=1". > >> > >>M-flag avoids to send IP address and capability container of the same CAR > >>back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed > >>to Context-ID=1, M-flag indicates that Context-ID has been modified by the > >>AR and that associated CAR IP address and associated capability container > >>is the same as for a previously received IP-address/capability > >>container pair, here indicated with Context-ID=1. > >> > >>Comments? > >> > >>marco > >> > >>_______________________________________________ > >>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 Thu Aug 7 04: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 EAA04590 for ; Thu, 7 Aug 2003 04: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 19kgFj-00030h-Jv for seamoby-archive@odin.ietf.org; Thu, 07 Aug 2003 04:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h778a7d9011570 for seamoby-archive@odin.ietf.org; Thu, 7 Aug 2003 04:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgFh-00030X-Ph for seamoby-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 04:36: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 EAA04579 for ; Thu, 7 Aug 2003 04:35:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgFe-00044u-00 for seamoby-web-archive@ietf.org; Thu, 07 Aug 2003 04:36:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kgFe-00044r-00 for seamoby-web-archive@ietf.org; Thu, 07 Aug 2003 04:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgFd-0002zn-G2; Thu, 07 Aug 2003 04: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 19kgEy-0002wR-5x for seamoby@optimus.ietf.org; Thu, 07 Aug 2003 04:35: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 EAA04561 for ; Thu, 7 Aug 2003 04:35:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgEv-00044f-00 for seamoby@ietf.org; Thu, 07 Aug 2003 04:35:17 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19kgEu-00044W-00 for seamoby@ietf.org; Thu, 07 Aug 2003 04:35:16 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h778YlVI091922; Thu, 7 Aug 2003 10:34:47 +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 9F995E4E6; Thu, 7 Aug 2003 10:12:31 +0200 (CEST) Message-ID: <3F320F24.5010404@ccrle.nec.de> Date: Thu, 07 Aug 2003 10:34:44 +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: Vijay Devarapalli Cc: Seamoby Subject: Re: [Seamoby] CARD issue#29: more text on use of "Context-ID" and"M-flag"required References: <3F1FCBF8.6000301@ccrle.nec.de> <3F2575BD.BE68E5D2@iprg.nokia.com> <3F2A2B10.8000402@ccrle.nec.de> <3F318E97.3AF2682C@iprg.nokia.com> 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 Vijay Devarapalli wrote: >Marco Liebsch wrote: > > >>This is exactly what the current protocol description proposes. But only >>adding the L2_ID sub-option in the reply does not solve the problem. You >>can see in the >>example below that in case two or more L2_IDs connect to the "same" CAR, >>this is indicated with the M-flag (M=matched) in the L2_ID coming back >>to the MN with the >>CARD Reply. Sending back L2_ID with a CARD Reply in case this >>particular L2 ID does "not" connect to a CAR that has been already >>previously resolved, is redundant. Actually, a L2 ID that comes back with >>a CARD Reply could be taken already as an indicator that the respective >>context-ID >>has been adjusted to a previously received conext, this could avoid the >>M-flag. >> >>What do you think? >> >> > >this sounds fine. but now there is a need to explain how >the Context-ID is managed at the MN. the MN needs to store >the Context-ID along with the information it stores for >a particular L2-ID. and it probably makes sense to use a >linearly increasing number space for the Context-ID so that >Context-IDs are not reused often. > > I agree. Also specific text on use of the context-id will be incorporated. However, since we found that the L2 ID has to carry kind of status code to indicate to the MN in a reply that AR was not able to resolve the requested L2 ID (issue#39), we can avoid the M-flag and incorporate all these notifications into an 8 bit status code field within the L2 ID sub-option. This means for example. 0x00 set by default in a CARD Request when MN sends the L2 ID for resolution to its AR. AR can return 0x01 as an OK indicator, 0x02 could be the indicator that L2 ID matches with a previously resolved CAR IP address (context-id match, replaces the M-flag), 0x03 could indicate the error case due to the AR was not able to resolve the L2 ID... What do you think? marco >Vijay > > > > >>marco >> >>Vijay Devarapalli wrote: >> >> >> >>>I am against using this mechanism. why not just include >>>the L2_ID suboption in the CARD reply too? ofcourse it >>>would increase the number of bytes in the CARD reply, >>>but I think it helps in reducing the overall complexity >>>of the CARD protocol. >>> >>>Vijay >>> >>>Marco Liebsch wrote: >>> >>> >>> >>> >>>>Hi all, >>>> >>>>going through the remaining open issues, there are some >>>>important ones, which have not been discussed during the >>>>meeting in Vienna. Here is one: >>>> >>>>There was a comment that more text w.r.t use of Context-ID >>>>and the M-flag is required. The proposal is to briefly describe >>>>the mechanism again and to solicit comments. After having agreed >>>>on a mechanism, more text will be added to the document. >>>>Please find a desciption/example of the proposed mechanism below: >>>> >>>>Since the L2 ID, a CAR's IP address and associated capabilities come >>>>with separate sub-options in a CARD Request/Reply message, >>>>association is indicated using a Context-ID. >>>>Example: >>>> >>>>MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR >>>>in a CARD Request for resolution: >>>> >>>>CARD Request (MN->AR) >>>>L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1 >>>>L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2 >>>> >>>>Now, first assume both L2_IDs (APs) connect to 2 different >>>>CARs, hence, associated IP address and capability container >>>>is identified with the respective Context-ID : >>>> >>>>CARD Reply (AR->MN) >>>>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. >>>>IP address of CAR(2) comes with capability container(2), both carry Context-ID=2. >>>> >>>>Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR: >>>>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1. >>>>L2_ID(2) comes back with "Context-ID=1", "M-flag=1". >>>> >>>>M-flag avoids to send IP address and capability container of the same CAR >>>>back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed >>>>to Context-ID=1, M-flag indicates that Context-ID has been modified by the >>>>AR and that associated CAR IP address and associated capability container >>>>is the same as for a previously received IP-address/capability >>>>container pair, here indicated with Context-ID=1. >>>> >>>>Comments? >>>> >>>>marco >>>> >>>>_______________________________________________ >>>>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 Thu Aug 7 14:01: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 OAA24501 for ; Thu, 7 Aug 2003 14:01: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 19kp4T-0004fx-SN for seamoby-archive@odin.ietf.org; Thu, 07 Aug 2003 14:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77I15cV017969 for seamoby-archive@odin.ietf.org; Thu, 7 Aug 2003 14:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kp4T-0004fk-OO for seamoby-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 14:01: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 OAA24482 for ; Thu, 7 Aug 2003 14:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kp4R-0001FC-00 for seamoby-web-archive@ietf.org; Thu, 07 Aug 2003 14:01:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kp4Q-0001F9-00 for seamoby-web-archive@ietf.org; Thu, 07 Aug 2003 14:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kp4Q-0004ew-Gx; Thu, 07 Aug 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kp4B-0004eB-5s for seamoby@optimus.ietf.org; Thu, 07 Aug 2003 14:00:47 -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 OAA24477 for ; Thu, 7 Aug 2003 14:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kp48-0001F3-00 for seamoby@ietf.org; Thu, 07 Aug 2003 14:00:44 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kp47-0001Er-00 for seamoby@ietf.org; Thu, 07 Aug 2003 14:00:43 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77I01U13276; Thu, 7 Aug 2003 11:00:01 -0700 X-mProtect: <200308071800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYsRwKf; Thu, 07 Aug 2003 10:59:59 PDT Message-ID: <3F32939F.DBEF1711@iprg.nokia.com> Date: Thu, 07 Aug 2003 10:59:59 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Liebsch CC: Seamoby Subject: Re: [Seamoby] CARD issue#29: more text on use of "Context-ID" and"M-flag"required References: <3F1FCBF8.6000301@ccrle.nec.de> <3F2575BD.BE68E5D2@iprg.nokia.com> <3F2A2B10.8000402@ccrle.nec.de> <3F318E97.3AF2682C@iprg.nokia.com> <3F320F24.5010404@ccrle.nec.de> 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 fine with me. Marco Liebsch wrote: > > I agree. Also specific text on use of the context-id will be incorporated. > However, since we found that the L2 ID has to carry kind of status code > to indicate to the MN in a reply that AR was not able to resolve the > requested L2 ID (issue#39), we can avoid the M-flag and incorporate all > these > notifications into an 8 bit status code field within the L2 ID sub-option. > This means for example. 0x00 set by default in a CARD Request when > MN sends the L2 ID for resolution to its AR. AR can return 0x01 as an > OK indicator, 0x02 could be the indicator that L2 ID matches with a > previously > resolved CAR IP address (context-id match, replaces the M-flag), 0x03 could > indicate the error case due to the AR was not able to resolve the L2 ID... > > What do you think? > > marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Aug 11 13:01:39 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 NAA23051 for ; Mon, 11 Aug 2003 13:01:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2k-0003Wi-1h for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:01:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BH1Em8013556 for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2j-0003WY-Ud for seamoby-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:01: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 NAA23022 for ; Mon, 11 Aug 2003 13:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG2i-0007Ch-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:01:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mG2h-0007Cd-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:01:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2Y-0003VP-4o; Mon, 11 Aug 2003 13:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG1a-0003U1-Gf for seamoby@optimus.ietf.org; Mon, 11 Aug 2003 13:00: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 MAA22968; Mon, 11 Aug 2003 12:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG1Y-0007Bu-00; Mon, 11 Aug 2003 13:00:00 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mG1X-0007Bh-00; Mon, 11 Aug 2003 12:59:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BGxPT04669; Mon, 11 Aug 2003 09:59:25 -0700 X-mProtect: <200308111659> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdN6gMSi; Mon, 11 Aug 2003 09:59:24 PDT Message-ID: <3F37CB6C.3C9D9956@iprg.nokia.com> Date: Mon, 11 Aug 2003 09:59:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo , seamoby@ietf.org References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology 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 have cc'ed Seamoby list. Thierry Ernst wrote: > > Dear all, > > draft-ietf-nemo-basic-support-pre01.txt > > Mobile Network Prefix > > The IPv6 prefix advertised in the Mobile Network > by one or more Mobile Routers. There could be multiple > prefixes in the Mobile Network. > > This is already defined in the terminology drafts (seamoby and NEMO): > > draft-ietf-seamoby-mobility-terminology-04.txt > > Mobile Network Prefix > > A bit string that consists of some number of initial bits of an > IP address which identifies the entire mobile network within the > Internet topology. All nodes in a mobile network necessarily have > an address named after this prefix. > > draft-ietf-neno-terminology-00.txt > > MNP > An acronym for Mobile Network Prefix (defined in [Mobility]) > > So, I think it's useless to define it here again in basic-support. that was deliberately added. I didnt want a normative reference to a draft which is not controlled by this WG. what is the status of this draft in the Seamoby WG? Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Aug 11 13:09: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 NAA23439 for ; Mon, 11 Aug 2003 13:09: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 19mGAM-000451-JF for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BH96hN015677 for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAM-00044m-Ff for seamoby-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:09: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 NAA23323 for ; Mon, 11 Aug 2003 13:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGAK-0007Gz-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:09:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGAJ-0007Gw-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAH-00042v-EY; Mon, 11 Aug 2003 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG9S-00041v-12 for seamoby@optimus.ietf.org; Mon, 11 Aug 2003 13:08: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 NAA23254; Mon, 11 Aug 2003 13:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG9Q-0007F3-00; Mon, 11 Aug 2003 13:08:08 -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 19mG9P-0007Eu-00; Mon, 11 Aug 2003 13:08:07 -0400 Message-ID: <025a01c3602b$26e46b70$9f6015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , "Thierry Ernst" Cc: "nemo" , References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology Date: Mon, 11 Aug 2003 10:08:14 -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 The draft is currently with the IESG, recommended to be published as Informational. According to Draft Tracker, the state is AD Evaluation. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Thierry Ernst" Cc: "nemo" ; Sent: Monday, August 11, 2003 9:59 AM Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > I have cc'ed Seamoby list. > > Thierry Ernst wrote: > > > > Dear all, > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > Mobile Network Prefix > > > > The IPv6 prefix advertised in the Mobile Network > > by one or more Mobile Routers. There could be multiple > > prefixes in the Mobile Network. > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > Mobile Network Prefix > > > > A bit string that consists of some number of initial bits of an > > IP address which identifies the entire mobile network within the > > Internet topology. All nodes in a mobile network necessarily have > > an address named after this prefix. > > > > draft-ietf-neno-terminology-00.txt > > > > MNP > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > So, I think it's useless to define it here again in basic-support. > > that was deliberately added. I didnt want a normative > reference to a draft which is not controlled by this > WG. what is the status of this draft in the Seamoby > WG? > > Vijay > > _______________________________________________ > 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 Aug 11 13:21: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 NAA24676 for ; Mon, 11 Aug 2003 13:21: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 19mGLx-0004ls-U9 for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHL5hZ018334 for seamoby-archive@odin.ietf.org; Mon, 11 Aug 2003 13:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLx-0004ld-Qu for seamoby-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:21: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 NAA24637 for ; Mon, 11 Aug 2003 13:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGLv-0007fg-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGLv-0007fd-00 for seamoby-web-archive@ietf.org; Mon, 11 Aug 2003 13:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLu-0004ih-1o; Mon, 11 Aug 2003 13:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLa-0004hq-GY for seamoby@optimus.ietf.org; Mon, 11 Aug 2003 13:20: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 NAA24598; Mon, 11 Aug 2003 13:20:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGLY-0007fK-00; Mon, 11 Aug 2003 13:20:40 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mGLX-0007eE-00; Mon, 11 Aug 2003 13:20:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BHK5429197; Mon, 11 Aug 2003 10:20:05 -0700 X-mProtect: <200308111720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd25SKBS; Mon, 11 Aug 2003 10:20:03 PDT Message-ID: <3F37D044.F2099D78@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:20:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Thierry Ernst , nemo , seamoby@ietf.org Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> <025a01c3602b$26e46b70$9f6015ac@dclkempt40> 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 I should have checked the ID tracker before sending the mail. sorry. James Kempf wrote: > > The draft is currently with the IESG, recommended to be published as > Informational. According to Draft Tracker, the state is AD Evaluation. great. that means we can have a reference to this draft in the NEMO drafts. Vijay > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Thierry Ernst" > Cc: "nemo" ; > Sent: Monday, August 11, 2003 9:59 AM > Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > > > I have cc'ed Seamoby list. > > > > Thierry Ernst wrote: > > > > > > Dear all, > > > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > > > Mobile Network Prefix > > > > > > The IPv6 prefix advertised in the Mobile Network > > > by one or more Mobile Routers. There could be multiple > > > prefixes in the Mobile Network. > > > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > > > Mobile Network Prefix > > > > > > A bit string that consists of some number of initial bits of an > > > IP address which identifies the entire mobile network within the > > > Internet topology. All nodes in a mobile network necessarily have > > > an address named after this prefix. > > > > > > draft-ietf-neno-terminology-00.txt > > > > > > MNP > > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > > > So, I think it's useless to define it here again in basic-support. > > > > that was deliberately added. I didnt want a normative > > reference to a draft which is not controlled by this > > WG. what is the status of this draft in the Seamoby > > WG? > > > > Vijay > > > > _______________________________________________ > > 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 Fri Aug 15 10:23:12 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 KAA29021 for ; Fri, 15 Aug 2003 10:23:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfTb-00050j-5H for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 10:22:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FEMlm3019257 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 10:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfTb-00050W-2F for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 10:22:47 -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 KAA29010 for ; Fri, 15 Aug 2003 10:22:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nfTY-0002qT-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 10:22:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nfTY-0002qP-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 10:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfSr-0004xj-AC; Fri, 15 Aug 2003 10:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfS5-0004ws-Qr for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 10:21: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 KAA28983 for ; Fri, 15 Aug 2003 10:21:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nfS3-0002q5-00 for seamoby@ietf.org; Fri, 15 Aug 2003 10:21:11 -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 19nfS2-0002q2-00 for seamoby@ietf.org; Fri, 15 Aug 2003 10:21:11 -0400 Received: from peace ([138.15.107.210]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Aug 2003 10:21:05 -0400 Message-ID: <00b301c36339$238302a0$d26b0f8a@peace> From: "Eunsoo Shim" To: "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 10:25:55 -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: 15 Aug 2003 14:21:05.0093 (UTC) FILETIME=[76524F50:01C36338] 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, Vijay, I am afraid my question is so long after your posting. But please let me ask a few questions. Is there any base for 1 second inter-message interval you suggested? Also is the value valid or justified in any wireless network environment? Let's consider a scenario that a mobile node receives a list of CARs and then requests more information on a specific CAR. If this happens as a part of the handoff procedure, the 1 second CARD inter-message interval will slow down the handoff procedure. I am not sure this is desirable. What do you think? Eunsoo ----- Original Message ----- From: "Vijay Devarapalli" To: "Hemant Chaskar" Cc: ; ; ; Sent: Monday, July 21, 2003 12:37 PM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > I already provided the text when I reviewed the CARD protocol. > > The MN MUST send only one CARD Request per > CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. > If the MN sends requests more frequently, the AR SHOULD drop the > CARD requests and not process them. > > and add to the constants section > > CARD_RETRANSMISSION_INTERVAL 1 second > CARD_MAX_RETRIES 3 > > this is similar to ICMP rate limiting. > > TCP rate limiting is different, not applicable here. in general > in any protocol where there is a request and a reply (and no > more messages), ICMP rate limiting is best suited. you dont have > to "source-quench" the Mobile Node. :) > > Vijay > > Hemant Chaskar wrote: > > > > Dear Vijay, > > > > Could you provide a text to be included in the draft on rate limiting. We > > can include it in the draft after discussing it over mailing list. It > > probably wont suffice to say that rate limiting is in lot of protocols and > > hence not needed here. Different protocols use different rate limiting. E.g. > > TCP uses rate limiting, but it wont be appropriate for CARD. > > > > If you are proposing to limit the rate by simply enforcing limit on > > aggregate rate of requests, I can easily argue that it is ineffective. So > > the question is: Wheater WG wants per MN rate limiting? If so, does it have > > to be using R flag or using limit on per-MN rate of request? And then, you > > can refer us to protocol that uses that type of rate limiting and we will > > simply refer to it - will save lot of writing. > > > > Hemant > > > > >From: Vijay Devarapalli > > >To: Singh Ajoy-ASINGH1 > > >CC: "Pat R. Calhoun" , kempf@docomolabs-usa.com, > > > seamoby@ietf.org > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > >Date: Fri, 18 Jul 2003 15:39:12 -0700 > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about > > >potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting > > >consensus is to add clarifying text to section 4.2 (4.3?) > > > > > > > > this is wrong, IMHO. rate limiting is a well known mechanism. > > > > introducing a new flag is not a bright idea. > > > > > > > > ajoy-> Why it is a bad idea? Well, I am neutral in this > > > > issue but I am not convinced why using R bit is worse than > > > > your proposed solution. > > > > > >simple. rate-limiting is implemented in a wide variety of > > >protocols (infact for any message that creates state at > > >the receiving node). nothing new here. you dont need a new > > >mechanism for this. > > > > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The > > >editor recommends the use of ICMP to make it consistent with the mobile > > >interface. Potential downsides: ICMP has potential security implications. > > >ICMP message types on binding is also very implementation specific. Also, > > >securing ICMP would require that all ICMP packets be secured. Meeting > > >consensus is to keep UDP. > > > > > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP > > > > options lets you piggyback these options on FMIPv6 messages. > > > > I am not sure how you can achieve piggybacking if the MN-AR > > > > signaling becomes UDP. ICMP was the right choice between > > > > the MN and the AR. > > > > > > > > AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP > > >for > > > > MN-AR and UDP for AR-AR interface. Others' please correct me. > > > > > >oops... I misunderstood. I thought the concensus at the > > >meeting was to use UDP for both. > > > > > > > BTW, why are you in favor of > > > > using ICMP for AR-AR interface? > > > > > >otherwise you need seperate code for processing an ICMP > > >CARD Request (from the MN) and UDP CARD Request (from > > >the PAR). also, if it is an ICMP message, I can piggyback > > >CARD messages on HI/HACK messages of FMIPv6. > > > > > > > > > > unbelievable. the CARD protocol is already complicated (IMO). > > > > the emphasis should be on reducing the complexity. just use > > > > a value of infinity for the lifetime field to indicate a > > > > static capability. any other value for the lifetime indicates > > > > dynamic capability. I think for the CARD protocol, emphasis > > > > should be on making it a simpler protocol than saving 4 bytes > > > > over the air. :) > > > > > > > > if you are concerned about an overhead of 4 bytes, make the > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you > > > > 65536 seconds which should be enough. do you need a 4 byte > > > > lifetime field? > > > > > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is > > > > huge saving for bandwidth constraint network. I am not sure > > > > processing one flag will make CARD protocol any more complicated. > > > > Btw, in cellular standard I have seen even more complicated > > > > procedure for saving 4 bits per frame. Please note that > > > > the CARD protocol is being proposed as an experimental > > > > protocol so we will have opportunity to make such > > > > changes in future if required. > > > > > >but in the current form not many people are going to use > > >it. it might remain forever as an experimental, untouched, > > >ignored, just another RFC.... that is something we should > > >avoid. I want a protocol that I can use. :) > > > > > >Vijay > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > 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 Fri Aug 15 11:59:10 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 LAA01577 for ; Fri, 15 Aug 2003 11:59:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngyS-0001hp-G9 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 11:58:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFwiEr006551 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 11:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngyS-0001ha-Br for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:58: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 LAA01569 for ; Fri, 15 Aug 2003 11:58:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngyR-0003Se-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 11:58:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ngyQ-0003Sb-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 11:58:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngxl-0001bx-3v; Fri, 15 Aug 2003 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngxI-0001bC-FA for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 11:57:32 -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 LAA01510 for ; Fri, 15 Aug 2003 11:57:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngxH-0003Rf-00 for seamoby@ietf.org; Fri, 15 Aug 2003 11:57:31 -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 19ngxG-0003Rc-00 for seamoby@ietf.org; Fri, 15 Aug 2003 11:57:30 -0400 Message-ID: <012101c36345$f685c140$976015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 08:57:43 -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 Eunsoo, In general, a node shouldn't be synchronizing CARD so closely with handover that the intermessage interval is an issue. The less L3 traffic at the time of handover, the more likely the handover is to succeed within the constraints of the unavoidable L2 traffic (this is a generalization that we have arrived at from experiments). I would think a node would typically send a CARD request immediately after handing over into a new subnet, so the intermessage interval shouldn't really be an issue. However, the number is intended only as a default and can be altered in particular circumstances. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Vijay Devarapalli" Cc: Sent: Friday, August 15, 2003 7:25 AM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > Hi, Vijay, > > I am afraid my question is so long after your posting. > But please let me ask a few questions. > Is there any base for 1 second inter-message interval you suggested? > Also is the value valid or justified in any wireless network environment? > > Let's consider a scenario that a mobile node receives a list of CARs and > then requests more information on a specific CAR. If this happens as a part > of the handoff procedure, the 1 second CARD inter-message interval will slow > down the handoff procedure. I am not sure this is desirable. > What do you think? > > Eunsoo > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Hemant Chaskar" > Cc: ; ; > ; > Sent: Monday, July 21, 2003 12:37 PM > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > I already provided the text when I reviewed the CARD protocol. > > > > The MN MUST send only one CARD Request per > > CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. > > If the MN sends requests more frequently, the AR SHOULD drop the > > CARD requests and not process them. > > > > and add to the constants section > > > > CARD_RETRANSMISSION_INTERVAL 1 second > > CARD_MAX_RETRIES 3 > > > > this is similar to ICMP rate limiting. > > > > TCP rate limiting is different, not applicable here. in general > > in any protocol where there is a request and a reply (and no > > more messages), ICMP rate limiting is best suited. you dont have > > to "source-quench" the Mobile Node. :) > > > > Vijay > > > > Hemant Chaskar wrote: > > > > > > Dear Vijay, > > > > > > Could you provide a text to be included in the draft on rate limiting. > We > > > can include it in the draft after discussing it over mailing list. It > > > probably wont suffice to say that rate limiting is in lot of protocols > and > > > hence not needed here. Different protocols use different rate limiting. > E.g. > > > TCP uses rate limiting, but it wont be appropriate for CARD. > > > > > > If you are proposing to limit the rate by simply enforcing limit on > > > aggregate rate of requests, I can easily argue that it is ineffective. > So > > > the question is: Wheater WG wants per MN rate limiting? If so, does it > have > > > to be using R flag or using limit on per-MN rate of request? And then, > you > > > can refer us to protocol that uses that type of rate limiting and we > will > > > simply refer to it - will save lot of writing. > > > > > > Hemant > > > > > > >From: Vijay Devarapalli > > > >To: Singh Ajoy-ASINGH1 > > > >CC: "Pat R. Calhoun" , > kempf@docomolabs-usa.com, > > > > seamoby@ietf.org > > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > >Date: Fri, 18 Jul 2003 15:39:12 -0700 > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do > about > > > >potential Dos issues? WG consensus is to Keep the R-flag approach. > Meeting > > > >consensus is to add clarifying text to section 4.2 (4.3?) > > > > > > > > > > this is wrong, IMHO. rate limiting is a well known mechanism. > > > > > introducing a new flag is not a bright idea. > > > > > > > > > > ajoy-> Why it is a bad idea? Well, I am neutral in this > > > > > issue but I am not convinced why using R bit is worse than > > > > > your proposed solution. > > > > > > > >simple. rate-limiting is implemented in a wide variety of > > > >protocols (infact for any message that creates state at > > > >the receiving node). nothing new here. you dont need a new > > > >mechanism for this. > > > > > > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. > The > > > >editor recommends the use of ICMP to make it consistent with the mobile > > > >interface. Potential downsides: ICMP has potential security > implications. > > > >ICMP message types on binding is also very implementation specific. > Also, > > > >securing ICMP would require that all ICMP packets be secured. Meeting > > > >consensus is to keep UDP. > > > > > > > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP > > > > > options lets you piggyback these options on FMIPv6 messages. > > > > > I am not sure how you can achieve piggybacking if the MN-AR > > > > > signaling becomes UDP. ICMP was the right choice between > > > > > the MN and the AR. > > > > > > > > > > AJOY-> Well I did not attend IETF meeting, but I guess this means > ICMP > > > >for > > > > > MN-AR and UDP for AR-AR interface. Others' please correct me. > > > > > > > >oops... I misunderstood. I thought the concensus at the > > > >meeting was to use UDP for both. > > > > > > > > > BTW, why are you in favor of > > > > > using ICMP for AR-AR interface? > > > > > > > >otherwise you need seperate code for processing an ICMP > > > >CARD Request (from the MN) and UDP CARD Request (from > > > >the PAR). also, if it is an ICMP message, I can piggyback > > > >CARD messages on HI/HACK messages of FMIPv6. > > > > > > > > > > > > > unbelievable. the CARD protocol is already complicated (IMO). > > > > > the emphasis should be on reducing the complexity. just use > > > > > a value of infinity for the lifetime field to indicate a > > > > > static capability. any other value for the lifetime indicates > > > > > dynamic capability. I think for the CARD protocol, emphasis > > > > > should be on making it a simpler protocol than saving 4 bytes > > > > > over the air. :) > > > > > > > > > > if you are concerned about an overhead of 4 bytes, make the > > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you > > > > > 65536 seconds which should be enough. do you need a 4 byte > > > > > lifetime field? > > > > > > > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is > > > > > huge saving for bandwidth constraint network. I am not sure > > > > > processing one flag will make CARD protocol any more complicated. > > > > > Btw, in cellular standard I have seen even more complicated > > > > > procedure for saving 4 bits per frame. Please note that > > > > > the CARD protocol is being proposed as an experimental > > > > > protocol so we will have opportunity to make such > > > > > changes in future if required. > > > > > > > >but in the current form not many people are going to use > > > >it. it might remain forever as an experimental, untouched, > > > >ignored, just another RFC.... that is something we should > > > >avoid. I want a protocol that I can use. :) > > > > > > > >Vijay > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > > http://join.msn.com/?page=features/featuredemail > > > > _______________________________________________ > > 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 Fri Aug 15 12:14: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 MAA01969 for ; Fri, 15 Aug 2003 12:14: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 19nhCx-00037D-Du for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 12:13:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FGDhdv011969 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 12:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhCx-00036y-AE for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 12:13: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 MAA01946 for ; Fri, 15 Aug 2003 12:13:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhCv-0003Yh-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 12:13:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nhCv-0003Ye-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 12:13:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhCG-0002wa-S9; Fri, 15 Aug 2003 12:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhCE-0002wM-S4 for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 12:12:58 -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 MAA01908 for ; Fri, 15 Aug 2003 12:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhCD-0003Y3-00 for seamoby@ietf.org; Fri, 15 Aug 2003 12:12:57 -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 19nhCC-0003Y0-00 for seamoby@ietf.org; Fri, 15 Aug 2003 12:12:57 -0400 Received: from peace ([138.15.107.210]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Aug 2003 12:12:57 -0400 Message-ID: <011501c36348$c3ce53e0$d26b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <012101c36345$f685c140$976015ac@dclkempt40> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 12:17:46 -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: 15 Aug 2003 16:12:57.0026 (UTC) FILETIME=[16F20220:01C36348] 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, James, I understand your point but I am not sure whether we should put such restrictions on use scenarios. If you mean the number is just a default value and alteration should be allowed, we have the question that how the mobile node will learn the value set at each access router. Actually that is the point the authors of the draft thought of and why we wanted to support a dynamic approach. I don't suggest any negotiation or complicated algorithm for rate control between AR and MN. If we want to support configuration of the value at each access router, we should provide a way for the access router to inform the MN of the value different from the default value. What do you think? Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Vijay Devarapalli" Cc: Sent: Friday, August 15, 2003 11:57 AM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > Eunsoo, > > In general, a node shouldn't be synchronizing CARD so closely with handover > that the intermessage interval is an issue. The less L3 traffic at the time > of handover, the more likely the handover is to succeed within the > constraints of the unavoidable L2 traffic (this is a generalization that we > have arrived at from experiments). I would think a node would typically send > a CARD request immediately after handing over into a new subnet, so the > intermessage interval shouldn't really be an issue. > > However, the number is intended only as a default and can be altered in > particular circumstances. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "Vijay Devarapalli" > Cc: > Sent: Friday, August 15, 2003 7:25 AM > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > Hi, Vijay, > > > > I am afraid my question is so long after your posting. > > But please let me ask a few questions. > > Is there any base for 1 second inter-message interval you suggested? > > Also is the value valid or justified in any wireless network environment? > > > > Let's consider a scenario that a mobile node receives a list of CARs and > > then requests more information on a specific CAR. If this happens as a > part > > of the handoff procedure, the 1 second CARD inter-message interval will > slow > > down the handoff procedure. I am not sure this is desirable. > > What do you think? > > > > Eunsoo > > > > ----- Original Message ----- > > From: "Vijay Devarapalli" > > To: "Hemant Chaskar" > > Cc: ; ; > > ; > > Sent: Monday, July 21, 2003 12:37 PM > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > > > > I already provided the text when I reviewed the CARD protocol. > > > > > > The MN MUST send only one CARD Request per > > > CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. > > > If the MN sends requests more frequently, the AR SHOULD drop the > > > CARD requests and not process them. > > > > > > and add to the constants section > > > > > > CARD_RETRANSMISSION_INTERVAL 1 second > > > CARD_MAX_RETRIES 3 > > > > > > this is similar to ICMP rate limiting. > > > > > > TCP rate limiting is different, not applicable here. in general > > > in any protocol where there is a request and a reply (and no > > > more messages), ICMP rate limiting is best suited. you dont have > > > to "source-quench" the Mobile Node. :) > > > > > > Vijay > > > > > > Hemant Chaskar wrote: > > > > > > > > Dear Vijay, > > > > > > > > Could you provide a text to be included in the draft on rate limiting. > > We > > > > can include it in the draft after discussing it over mailing list. It > > > > probably wont suffice to say that rate limiting is in lot of protocols > > and > > > > hence not needed here. Different protocols use different rate > limiting. > > E.g. > > > > TCP uses rate limiting, but it wont be appropriate for CARD. > > > > > > > > If you are proposing to limit the rate by simply enforcing limit on > > > > aggregate rate of requests, I can easily argue that it is ineffective. > > So > > > > the question is: Wheater WG wants per MN rate limiting? If so, does it > > have > > > > to be using R flag or using limit on per-MN rate of request? And then, > > you > > > > can refer us to protocol that uses that type of rate limiting and we > > will > > > > simply refer to it - will save lot of writing. > > > > > > > > Hemant > > > > > > > > >From: Vijay Devarapalli > > > > >To: Singh Ajoy-ASINGH1 > > > > >CC: "Pat R. Calhoun" , > > kempf@docomolabs-usa.com, > > > > > seamoby@ietf.org > > > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > >Date: Fri, 18 Jul 2003 15:39:12 -0700 > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do > > about > > > > >potential Dos issues? WG consensus is to Keep the R-flag approach. > > Meeting > > > > >consensus is to add clarifying text to section 4.2 (4.3?) > > > > > > > > > > > > this is wrong, IMHO. rate limiting is a well known mechanism. > > > > > > introducing a new flag is not a bright idea. > > > > > > > > > > > > ajoy-> Why it is a bad idea? Well, I am neutral in this > > > > > > issue but I am not convinced why using R bit is worse than > > > > > > your proposed solution. > > > > > > > > > >simple. rate-limiting is implemented in a wide variety of > > > > >protocols (infact for any message that creates state at > > > > >the receiving node). nothing new here. you dont need a new > > > > >mechanism for this. > > > > > > > > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. > > The > > > > >editor recommends the use of ICMP to make it consistent with the > mobile > > > > >interface. Potential downsides: ICMP has potential security > > implications. > > > > >ICMP message types on binding is also very implementation specific. > > Also, > > > > >securing ICMP would require that all ICMP packets be secured. Meeting > > > > >consensus is to keep UDP. > > > > > > > > > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP > > > > > > options lets you piggyback these options on FMIPv6 messages. > > > > > > I am not sure how you can achieve piggybacking if the MN-AR > > > > > > signaling becomes UDP. ICMP was the right choice between > > > > > > the MN and the AR. > > > > > > > > > > > > AJOY-> Well I did not attend IETF meeting, but I guess this means > > ICMP > > > > >for > > > > > > MN-AR and UDP for AR-AR interface. Others' please correct me. > > > > > > > > > >oops... I misunderstood. I thought the concensus at the > > > > >meeting was to use UDP for both. > > > > > > > > > > > BTW, why are you in favor of > > > > > > using ICMP for AR-AR interface? > > > > > > > > > >otherwise you need seperate code for processing an ICMP > > > > >CARD Request (from the MN) and UDP CARD Request (from > > > > >the PAR). also, if it is an ICMP message, I can piggyback > > > > >CARD messages on HI/HACK messages of FMIPv6. > > > > > > > > > > > > > > > > unbelievable. the CARD protocol is already complicated (IMO). > > > > > > the emphasis should be on reducing the complexity. just use > > > > > > a value of infinity for the lifetime field to indicate a > > > > > > static capability. any other value for the lifetime indicates > > > > > > dynamic capability. I think for the CARD protocol, emphasis > > > > > > should be on making it a simpler protocol than saving 4 bytes > > > > > > over the air. :) > > > > > > > > > > > > if you are concerned about an overhead of 4 bytes, make the > > > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you > > > > > > 65536 seconds which should be enough. do you need a 4 byte > > > > > > lifetime field? > > > > > > > > > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is > > > > > > huge saving for bandwidth constraint network. I am not sure > > > > > > processing one flag will make CARD protocol any more complicated. > > > > > > Btw, in cellular standard I have seen even more complicated > > > > > > procedure for saving 4 bits per frame. Please note that > > > > > > the CARD protocol is being proposed as an experimental > > > > > > protocol so we will have opportunity to make such > > > > > > changes in future if required. > > > > > > > > > >but in the current form not many people are going to use > > > > >it. it might remain forever as an experimental, untouched, > > > > >ignored, just another RFC.... that is something we should > > > > >avoid. I want a protocol that I can use. :) > > > > > > > > > >Vijay > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _________________________________________________________________ > > > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 12:38: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 MAA02765 for ; Fri, 15 Aug 2003 12:38: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 19nhaC-000484-3V for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 12:37:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FGbibl015866 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 12:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhaB-00047p-TW for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 12:37: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 MAA02751 for ; Fri, 15 Aug 2003 12:37:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhaA-0003kc-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 12:37:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nha9-0003kZ-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 12:37:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhZV-0003qS-1M; Fri, 15 Aug 2003 12:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhZ6-0003pd-8M for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 12:36: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 MAA02740 for ; Fri, 15 Aug 2003 12:36:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhZ4-0003kF-00 for seamoby@ietf.org; Fri, 15 Aug 2003 12:36: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 19nhZ3-0003k6-00 for seamoby@ietf.org; Fri, 15 Aug 2003 12:36:33 -0400 Message-ID: <01ba01c3634b$6b1b3cb0$976015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <012101c36345$f685c140$976015ac@dclkempt40> <011501c36348$c3ce53e0$d26b0f8a@peace> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 09:36:46 -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 The number doesn't have to be determined at each router, it would depend on the deployment and radio protocol. W.r.t. restrictions, this is an experimental protocol, so the draft might suggest a possible use (CARD right after handover) then suggest this as an open question, for experimental determination. A default is necessary, however, and one second seems right to me. It can be changed if the draft is ever advanced to Proposed Standard. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Vijay Devarapalli" Cc: Sent: Friday, August 15, 2003 9:17 AM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > Hi, James, > > I understand your point but I am not sure whether we should put such > restrictions on use scenarios. > > If you mean the number is just a default value and alteration should be > allowed, we have the question that how the mobile node will learn the value > set at each access router. > Actually that is the point the authors of the draft thought of and why we > wanted to support a dynamic approach. > I don't suggest any negotiation or complicated algorithm for rate control > between AR and MN. If we want to support configuration of the value at each > access router, we should provide a way for the access router to inform the > MN of the value different from the default value. What do you think? > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; "Vijay Devarapalli" > > Cc: > Sent: Friday, August 15, 2003 11:57 AM > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > Eunsoo, > > > > In general, a node shouldn't be synchronizing CARD so closely with > handover > > that the intermessage interval is an issue. The less L3 traffic at the > time > > of handover, the more likely the handover is to succeed within the > > constraints of the unavoidable L2 traffic (this is a generalization that > we > > have arrived at from experiments). I would think a node would typically > send > > a CARD request immediately after handing over into a new subnet, so the > > intermessage interval shouldn't really be an issue. > > > > However, the number is intended only as a default and can be altered in > > particular circumstances. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "Vijay Devarapalli" > > Cc: > > Sent: Friday, August 15, 2003 7:25 AM > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > Hi, Vijay, > > > > > > I am afraid my question is so long after your posting. > > > But please let me ask a few questions. > > > Is there any base for 1 second inter-message interval you suggested? > > > Also is the value valid or justified in any wireless network > environment? > > > > > > Let's consider a scenario that a mobile node receives a list of CARs and > > > then requests more information on a specific CAR. If this happens as a > > part > > > of the handoff procedure, the 1 second CARD inter-message interval will > > slow > > > down the handoff procedure. I am not sure this is desirable. > > > What do you think? > > > > > > Eunsoo > > > > > > ----- Original Message ----- > > > From: "Vijay Devarapalli" > > > To: "Hemant Chaskar" > > > Cc: ; ; > > > ; > > > Sent: Monday, July 21, 2003 12:37 PM > > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > > > > > > > > I already provided the text when I reviewed the CARD protocol. > > > > > > > > The MN MUST send only one CARD Request per > > > > CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. > > > > If the MN sends requests more frequently, the AR SHOULD drop the > > > > CARD requests and not process them. > > > > > > > > and add to the constants section > > > > > > > > CARD_RETRANSMISSION_INTERVAL 1 second > > > > CARD_MAX_RETRIES 3 > > > > > > > > this is similar to ICMP rate limiting. > > > > > > > > TCP rate limiting is different, not applicable here. in general > > > > in any protocol where there is a request and a reply (and no > > > > more messages), ICMP rate limiting is best suited. you dont have > > > > to "source-quench" the Mobile Node. :) > > > > > > > > Vijay > > > > > > > > Hemant Chaskar wrote: > > > > > > > > > > Dear Vijay, > > > > > > > > > > Could you provide a text to be included in the draft on rate > limiting. > > > We > > > > > can include it in the draft after discussing it over mailing list. > It > > > > > probably wont suffice to say that rate limiting is in lot of > protocols > > > and > > > > > hence not needed here. Different protocols use different rate > > limiting. > > > E.g. > > > > > TCP uses rate limiting, but it wont be appropriate for CARD. > > > > > > > > > > If you are proposing to limit the rate by simply enforcing limit on > > > > > aggregate rate of requests, I can easily argue that it is > ineffective. > > > So > > > > > the question is: Wheater WG wants per MN rate limiting? If so, does > it > > > have > > > > > to be using R flag or using limit on per-MN rate of request? And > then, > > > you > > > > > can refer us to protocol that uses that type of rate limiting and we > > > will > > > > > simply refer to it - will save lot of writing. > > > > > > > > > > Hemant > > > > > > > > > > >From: Vijay Devarapalli > > > > > >To: Singh Ajoy-ASINGH1 > > > > > >CC: "Pat R. Calhoun" , > > > kempf@docomolabs-usa.com, > > > > > > seamoby@ietf.org > > > > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > >Date: Fri, 18 Jul 2003 15:39:12 -0700 > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do > > > about > > > > > >potential Dos issues? WG consensus is to Keep the R-flag approach. > > > Meeting > > > > > >consensus is to add clarifying text to section 4.2 (4.3?) > > > > > > > > > > > > > > this is wrong, IMHO. rate limiting is a well known mechanism. > > > > > > > introducing a new flag is not a bright idea. > > > > > > > > > > > > > > ajoy-> Why it is a bad idea? Well, I am neutral in this > > > > > > > issue but I am not convinced why using R bit is worse than > > > > > > > your proposed solution. > > > > > > > > > > > >simple. rate-limiting is implemented in a wide variety of > > > > > >protocols (infact for any message that creates state at > > > > > >the receiving node). nothing new here. you dont need a new > > > > > >mechanism for this. > > > > > > > > > > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to > ICMP. > > > The > > > > > >editor recommends the use of ICMP to make it consistent with the > > mobile > > > > > >interface. Potential downsides: ICMP has potential security > > > implications. > > > > > >ICMP message types on binding is also very implementation specific. > > > Also, > > > > > >securing ICMP would require that all ICMP packets be secured. > Meeting > > > > > >consensus is to keep UDP. > > > > > > > > > > > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP > > > > > > > options lets you piggyback these options on FMIPv6 messages. > > > > > > > I am not sure how you can achieve piggybacking if the MN-AR > > > > > > > signaling becomes UDP. ICMP was the right choice between > > > > > > > the MN and the AR. > > > > > > > > > > > > > > AJOY-> Well I did not attend IETF meeting, but I guess this > means > > > ICMP > > > > > >for > > > > > > > MN-AR and UDP for AR-AR interface. Others' please correct me. > > > > > > > > > > > >oops... I misunderstood. I thought the concensus at the > > > > > >meeting was to use UDP for both. > > > > > > > > > > > > > BTW, why are you in favor of > > > > > > > using ICMP for AR-AR interface? > > > > > > > > > > > >otherwise you need seperate code for processing an ICMP > > > > > >CARD Request (from the MN) and UDP CARD Request (from > > > > > >the PAR). also, if it is an ICMP message, I can piggyback > > > > > >CARD messages on HI/HACK messages of FMIPv6. > > > > > > > > > > > > > > > > > > > unbelievable. the CARD protocol is already complicated (IMO). > > > > > > > the emphasis should be on reducing the complexity. just use > > > > > > > a value of infinity for the lifetime field to indicate a > > > > > > > static capability. any other value for the lifetime indicates > > > > > > > dynamic capability. I think for the CARD protocol, emphasis > > > > > > > should be on making it a simpler protocol than saving 4 bytes > > > > > > > over the air. :) > > > > > > > > > > > > > > if you are concerned about an overhead of 4 bytes, make the > > > > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you > > > > > > > 65536 seconds which should be enough. do you need a 4 byte > > > > > > > lifetime field? > > > > > > > > > > > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is > > > > > > > huge saving for bandwidth constraint network. I am not sure > > > > > > > processing one flag will make CARD protocol any more > complicated. > > > > > > > Btw, in cellular standard I have seen even more complicated > > > > > > > procedure for saving 4 bits per frame. Please note that > > > > > > > the CARD protocol is being proposed as an experimental > > > > > > > protocol so we will have opportunity to make such > > > > > > > changes in future if required. > > > > > > > > > > > >but in the current form not many people are going to use > > > > > >it. it might remain forever as an experimental, untouched, > > > > > >ignored, just another RFC.... that is something we should > > > > > >avoid. I want a protocol that I can use. :) > > > > > > > > > > > >Vijay > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > > > > http://join.msn.com/?page=features/featuredemail > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 15:01: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 PAA08528 for ; Fri, 15 Aug 2003 15:01: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 19njou-0003jL-0K for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJ13eH014335 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njot-0003j8-To for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:01: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 PAA08497 for ; Fri, 15 Aug 2003 15:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njoq-0005CM-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:01:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19njoq-0005CJ-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njoq-0003ik-Sz; Fri, 15 Aug 2003 15:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19njnu-0003hX-Tt for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 15:00: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 OAA08465 for ; Fri, 15 Aug 2003 14:59:57 -0400 (EDT) From: phil.neumiller@convergys.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19njnr-0005Bp-00 for seamoby@ietf.org; Fri, 15 Aug 2003 14:59:59 -0400 Received: from cvgmx1.convergys.com ([63.210.255.12] ident=mirapoint) by ietf-mx with esmtp (Exim 4.12) id 19njnp-0005Bg-00 for seamoby@ietf.org; Fri, 15 Aug 2003 14:59:59 -0400 Received: from nd.convergys.com (cvgsmtp1.img.convergys.com [155.90.14.35]) by cvgmx1.convergys.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AOP62347; Fri, 15 Aug 2003 14:59:50 -0400 (EDT) To: seamoby@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 15 Aug 2003 15:00:26 -0400 X-MIMETrack: Serialize by Router on CVGSMTP1/SRVR/CVG(Release 5.0.11 |July 24, 2002) at 08/15/2003 02:59:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Seamoby] SAML, Liberty Aliance, SISO, EAP vs SeaMoby CT 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: , Hi, I am curious what some folks on this list think about SeaMoby CT versus the notion of federated identity being promoted by the Liberty Alliance. see http://www.projectliberty.org/ It seems that an Internet wide identity coupled with Diameter reauthentication could obviate the need for context transfer (at least for (A)aa context). My assumption is that a new EAP method would be implemented, possibly an extension of EAP-TTLS or EAP-SPEKE (password based) that would be Liberty Alliance friendly. Does anybody know of any work being done to make sure that EAP issues are supported properly in Diameter (especially the ability to enter a password once and be able to simply re-authenticate when roaming of admin domains in roaming agreement). Ideally WECA WPA would adopt this and TGi eventually. However, this is likely to be a relatively heavy weight transaction and perhaps SeaMoby CT is still best for fast / smooth / seamless handovers between AR with a pre-established trust relationship (long lived IPsec tunnels?). Novell's e-directory and Sun's iPlanet already have some support for the Liberty Alliance identity scheme (being standardized through OASIS). see http://www.oasis-open.org/home/index.php Another thought that occured to me was using SAML for CT between ARs. Can we assume that ARs will have XML parsers? yuck... Is anybody planning on implementing SeaMoby CT? Thoughts? Best regards, Phil N -- "NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 15:17: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 PAA09907 for ; Fri, 15 Aug 2003 15:17: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 19nk4N-0004wv-Rf for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJH3O9019020 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nk4N-0004wh-OO for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:17: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 PAA09854 for ; Fri, 15 Aug 2003 15:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nk4M-0005IK-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nk4L-0005IH-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nk4L-0004wI-5O; Fri, 15 Aug 2003 15: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 19nk43-0004vl-9C for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 15:16: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 PAA09809 for ; Fri, 15 Aug 2003 15:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nk41-0005Ho-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:16:41 -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 19nk40-0005Hl-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:16:40 -0400 Received: from peace ([138.15.107.210]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Aug 2003 15:16:40 -0400 Message-ID: <016f01c36362$6e26d790$d26b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <012101c36345$f685c140$976015ac@dclkempt40> <011501c36348$c3ce53e0$d26b0f8a@peace> <01ba01c3634b$6b1b3cb0$976015ac@dclkempt40> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 15:21:30 -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: 15 Aug 2003 19:16:40.0897 (UTC) FILETIME=[C1AF3B10:01C36361] 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 number doesn't have to be determined at each router, it would depend on > the deployment and radio protocol. > O.K. Anyway you agree that the value would not be the same for various wireless environment. The value will be configured by the network admin. The visiting or even home mobile nodes should learn about the value. My point is how the mobile node will learn the value, in particular, when the value is different from the default value. > W.r.t. restrictions, this is an experimental protocol, so the draft might > suggest a possible use (CARD right after handover) then suggest this as an > open question, for experimental determination. If we consider that the protocol is experimental, wouldn't it be better to allow more options for the application of the protocol and let people figure out what's the best way to use the protocol? Putting the restriction just for the rate control does not look good to me. > A default is necessary, > however, and one second seems right to me. It can be changed if the draft is > ever advanced to Proposed Standard. > Again, my point is that a single default value is likely to invalid in heterogeneous wireless environment. So the question is how we alllow the mobile node to learn the value when it is different from the default value. Eunsoo > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; "Vijay Devarapalli" > > Cc: > Sent: Friday, August 15, 2003 9:17 AM > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > Hi, James, > > > > I understand your point but I am not sure whether we should put such > > restrictions on use scenarios. > > > > If you mean the number is just a default value and alteration should be > > allowed, we have the question that how the mobile node will learn the > value > > set at each access router. > > Actually that is the point the authors of the draft thought of and why we > > wanted to support a dynamic approach. > > I don't suggest any negotiation or complicated algorithm for rate control > > between AR and MN. If we want to support configuration of the value at > each > > access router, we should provide a way for the access router to inform the > > MN of the value different from the default value. What do you think? > > > > Eunsoo > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Eunsoo Shim" ; "Vijay Devarapalli" > > > > Cc: > > Sent: Friday, August 15, 2003 11:57 AM > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > Eunsoo, > > > > > > In general, a node shouldn't be synchronizing CARD so closely with > > handover > > > that the intermessage interval is an issue. The less L3 traffic at the > > time > > > of handover, the more likely the handover is to succeed within the > > > constraints of the unavoidable L2 traffic (this is a generalization that > > we > > > have arrived at from experiments). I would think a node would typically > > send > > > a CARD request immediately after handing over into a new subnet, so the > > > intermessage interval shouldn't really be an issue. > > > > > > However, the number is intended only as a default and can be altered in > > > particular circumstances. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Eunsoo Shim" > > > To: "Vijay Devarapalli" > > > Cc: > > > Sent: Friday, August 15, 2003 7:25 AM > > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > > > > Hi, Vijay, > > > > > > > > I am afraid my question is so long after your posting. > > > > But please let me ask a few questions. > > > > Is there any base for 1 second inter-message interval you suggested? > > > > Also is the value valid or justified in any wireless network > > environment? > > > > > > > > Let's consider a scenario that a mobile node receives a list of CARs > and > > > > then requests more information on a specific CAR. If this happens as a > > > part > > > > of the handoff procedure, the 1 second CARD inter-message interval > will > > > slow > > > > down the handoff procedure. I am not sure this is desirable. > > > > What do you think? > > > > > > > > Eunsoo > > > > > > > > ----- Original Message ----- > > > > From: "Vijay Devarapalli" > > > > To: "Hemant Chaskar" > > > > Cc: ; ; > > > > ; > > > > Sent: Monday, July 21, 2003 12:37 PM > > > > Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > > > > > > > > > > > > > I already provided the text when I reviewed the CARD protocol. > > > > > > > > > > The MN MUST send only one CARD Request per > > > > > CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. > > > > > If the MN sends requests more frequently, the AR SHOULD drop the > > > > > CARD requests and not process them. > > > > > > > > > > and add to the constants section > > > > > > > > > > CARD_RETRANSMISSION_INTERVAL 1 second > > > > > CARD_MAX_RETRIES 3 > > > > > > > > > > this is similar to ICMP rate limiting. > > > > > > > > > > TCP rate limiting is different, not applicable here. in general > > > > > in any protocol where there is a request and a reply (and no > > > > > more messages), ICMP rate limiting is best suited. you dont have > > > > > to "source-quench" the Mobile Node. :) > > > > > > > > > > Vijay > > > > > > > > > > Hemant Chaskar wrote: > > > > > > > > > > > > Dear Vijay, > > > > > > > > > > > > Could you provide a text to be included in the draft on rate > > limiting. > > > > We > > > > > > can include it in the draft after discussing it over mailing list. > > It > > > > > > probably wont suffice to say that rate limiting is in lot of > > protocols > > > > and > > > > > > hence not needed here. Different protocols use different rate > > > limiting. > > > > E.g. > > > > > > TCP uses rate limiting, but it wont be appropriate for CARD. > > > > > > > > > > > > If you are proposing to limit the rate by simply enforcing limit > on > > > > > > aggregate rate of requests, I can easily argue that it is > > ineffective. > > > > So > > > > > > the question is: Wheater WG wants per MN rate limiting? If so, > does > > it > > > > have > > > > > > to be using R flag or using limit on per-MN rate of request? And > > then, > > > > you > > > > > > can refer us to protocol that uses that type of rate limiting and > we > > > > will > > > > > > simply refer to it - will save lot of writing. > > > > > > > > > > > > Hemant > > > > > > > > > > > > >From: Vijay Devarapalli > > > > > > >To: Singh Ajoy-ASINGH1 > > > > > > >CC: "Pat R. Calhoun" , > > > > kempf@docomolabs-usa.com, > > > > > > > seamoby@ietf.org > > > > > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues > > > > > > >Date: Fri, 18 Jul 2003 15:39:12 -0700 > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > > > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to > do > > > > about > > > > > > >potential Dos issues? WG consensus is to Keep the R-flag > approach. > > > > Meeting > > > > > > >consensus is to add clarifying text to section 4.2 (4.3?) > > > > > > > > > > > > > > > > this is wrong, IMHO. rate limiting is a well known mechanism. > > > > > > > > introducing a new flag is not a bright idea. > > > > > > > > > > > > > > > > ajoy-> Why it is a bad idea? Well, I am neutral in this > > > > > > > > issue but I am not convinced why using R bit is worse than > > > > > > > > your proposed solution. > > > > > > > > > > > > > >simple. rate-limiting is implemented in a wide variety of > > > > > > >protocols (infact for any message that creates state at > > > > > > >the receiving node). nothing new here. you dont need a new > > > > > > >mechanism for this. > > > > > > > > > > > > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to > > ICMP. > > > > The > > > > > > >editor recommends the use of ICMP to make it consistent with the > > > mobile > > > > > > >interface. Potential downsides: ICMP has potential security > > > > implications. > > > > > > >ICMP message types on binding is also very implementation > specific. > > > > Also, > > > > > > >securing ICMP would require that all ICMP packets be secured. > > Meeting > > > > > > >consensus is to keep UDP. > > > > > > > > > > > > > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP > > > > > > > > options lets you piggyback these options on FMIPv6 messages. > > > > > > > > I am not sure how you can achieve piggybacking if the MN-AR > > > > > > > > signaling becomes UDP. ICMP was the right choice between > > > > > > > > the MN and the AR. > > > > > > > > > > > > > > > > AJOY-> Well I did not attend IETF meeting, but I guess this > > means > > > > ICMP > > > > > > >for > > > > > > > > MN-AR and UDP for AR-AR interface. Others' please correct me. > > > > > > > > > > > > > >oops... I misunderstood. I thought the concensus at the > > > > > > >meeting was to use UDP for both. > > > > > > > > > > > > > > > BTW, why are you in favor of > > > > > > > > using ICMP for AR-AR interface? > > > > > > > > > > > > > >otherwise you need seperate code for processing an ICMP > > > > > > >CARD Request (from the MN) and UDP CARD Request (from > > > > > > >the PAR). also, if it is an ICMP message, I can piggyback > > > > > > >CARD messages on HI/HACK messages of FMIPv6. > > > > > > > > > > > > > > > > > > > > > > unbelievable. the CARD protocol is already complicated (IMO). > > > > > > > > the emphasis should be on reducing the complexity. just use > > > > > > > > a value of infinity for the lifetime field to indicate a > > > > > > > > static capability. any other value for the lifetime indicates > > > > > > > > dynamic capability. I think for the CARD protocol, emphasis > > > > > > > > should be on making it a simpler protocol than saving 4 bytes > > > > > > > > over the air. :) > > > > > > > > > > > > > > > > if you are concerned about an overhead of 4 bytes, make the > > > > > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you > > > > > > > > 65536 seconds which should be enough. do you need a 4 byte > > > > > > > > lifetime field? > > > > > > > > > > > > > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is > > > > > > > > huge saving for bandwidth constraint network. I am not sure > > > > > > > > processing one flag will make CARD protocol any more > > complicated. > > > > > > > > Btw, in cellular standard I have seen even more complicated > > > > > > > > procedure for saving 4 bits per frame. Please note that > > > > > > > > the CARD protocol is being proposed as an experimental > > > > > > > > protocol so we will have opportunity to make such > > > > > > > > changes in future if required. > > > > > > > > > > > > > >but in the current form not many people are going to use > > > > > > >it. it might remain forever as an experimental, untouched, > > > > > > >ignored, just another RFC.... that is something we should > > > > > > >avoid. I want a protocol that I can use. :) > > > > > > > > > > > > > >Vijay > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Seamoby mailing list > > > > > > >Seamoby@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > > > > > http://join.msn.com/?page=features/featuredemail > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 15:28: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 PAA10526 for ; Fri, 15 Aug 2003 15:28: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 19nkF1-0005d2-FZ for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJS3Uk021636 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkF1-0005ct-9W for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:28: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 PAA10508 for ; Fri, 15 Aug 2003 15:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkEz-0005OE-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkEz-0005OB-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkEz-0005cQ-E9; Fri, 15 Aug 2003 15:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkEt-0005Zs-52 for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 15:27:55 -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 PAA10502 for ; Fri, 15 Aug 2003 15:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkEr-0005O1-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:27:53 -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 19nkEq-0005Ny-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:27:53 -0400 Message-ID: <02fd01c36363$58634a00$976015ac@dclkempt40> From: "James Kempf" To: , References: Subject: Re: [Seamoby] SAML, Liberty Aliance, SISO, EAP vs SeaMoby CT Date: Fri, 15 Aug 2003 12:28:00 -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 Phil, The AAA stuff you mention is not in scope of this WG. There are other uses for CT, so I don't think it's a total loss even if Diameter is used as you mention. Wrt. implementing CT, it will be published as Experimental, and, since DoCoMo Labs USA is a research lab, we have been discussing implementing it. We are interested in it for header compression and multicast group subscription context. jak ----- Original Message ----- From: To: Sent: Friday, August 15, 2003 12:00 PM Subject: [Seamoby] SAML, Liberty Aliance, SISO, EAP vs SeaMoby CT > Hi, > > I am curious what some folks on this list think about > SeaMoby CT versus the notion of federated identity > being promoted by the Liberty Alliance. > > see http://www.projectliberty.org/ > > It seems that an Internet wide identity coupled with > Diameter reauthentication could obviate the need for > context transfer (at least for (A)aa context). My assumption > is that a new EAP method would be implemented, possibly > an extension of EAP-TTLS or EAP-SPEKE (password based) that > would be Liberty Alliance friendly. Does anybody know of > any work being done to make sure that EAP issues are > supported properly in Diameter (especially the ability to > enter a password once and be able to simply re-authenticate > when roaming of admin domains in roaming agreement). > Ideally WECA WPA would adopt this and TGi eventually. > > However, this is likely to be a relatively heavy weight > transaction and perhaps SeaMoby CT is still best for > fast / smooth / seamless handovers between AR with a > pre-established trust relationship (long lived IPsec > tunnels?). > > Novell's e-directory and Sun's iPlanet already have > some support for the Liberty Alliance identity > scheme (being standardized through OASIS). > > see http://www.oasis-open.org/home/index.php > > Another thought that occured to me was using SAML > for CT between ARs. Can we assume that ARs will have > XML parsers? yuck... > > Is anybody planning on implementing SeaMoby CT? > > Thoughts? > > Best regards, > > Phil N > > > > -- > "NOTICE: The information contained in this electronic mail transmission is > intended by Convergys Corporation for the use of the named individual or > entity to which it is directed and may contain information that is > privileged or otherwise confidential. If you have received this electronic > mail transmission in error, please delete it from your system without > copying or forwarding it, and notify the sender of the error by reply email > or by telephone (collect), so that the sender's address records can be > corrected." > > > > _______________________________________________ > 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 Fri Aug 15 15:34: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 PAA10824 for ; Fri, 15 Aug 2003 15:34: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 19nkKq-0006Ck-AX for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJY4V3023846 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkKq-0006CX-7k for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:34: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 PAA10802 for ; Fri, 15 Aug 2003 15:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkKo-0005R9-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:34:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkKo-0005R6-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkKm-00068Z-R2; Fri, 15 Aug 2003 15:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkK0-0005wm-UY for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 15:33: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 PAA10709 for ; Fri, 15 Aug 2003 15:33:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkJz-0005Qr-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:33: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 19nkJy-0005Qn-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:33:10 -0400 Message-ID: <030701c36364$178be770$976015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <012101c36345$f685c140$976015ac@dclkempt40> <011501c36348$c3ce53e0$d26b0f8a@peace> <01ba01c3634b$6b1b3cb0$976015ac@dclkempt40> <016f01c36362$6e26d790$d26b0f8a@peace> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Fri, 15 Aug 2003 12:33:23 -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 > > W.r.t. restrictions, this is an experimental protocol, so the draft might > > suggest a possible use (CARD right after handover) then suggest this as an > > open question, for experimental determination. > If we consider that the protocol is experimental, wouldn't it be better to > allow more options for the application of the protocol and let people figure > out what's the best way to use the protocol? > Putting the restriction just for the rate control does not look good to me. > We need to put in what is the concensus of the WG. Concensus right now looks to restrict it, since you are the only person who has expressed any interest in not restricting it. > > A default is necessary, > > however, and one second seems right to me. It can be changed if the draft > is > > ever advanced to Proposed Standard. > > > Again, my point is that a single default value is likely to invalid in > heterogeneous wireless environment. So the question is how we alllow the > mobile node to learn the value when it is different from the default value. > Somebody configures it into the wireless device when you buy it or when your account with the WISP is initiated. The device doesn't have to learn it dynamically on a case by case basis. This protocol is complicated enough already, we need to eliminate bells and whistles not put any more in. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 15:44: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 PAA11135 for ; Fri, 15 Aug 2003 15:44: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 19nkUV-0006nu-92 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJi3pn026148 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 15:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkUV-0006nf-5w for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:44: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 PAA11093 for ; Fri, 15 Aug 2003 15:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkUT-0005UE-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:44:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkUT-0005UB-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 15:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkUS-0006nG-SV; Fri, 15 Aug 2003 15:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkTq-0006mw-Nl for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 15:43:22 -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 PAA11086 for ; Fri, 15 Aug 2003 15:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkTp-0005U1-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:43:21 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19nkTo-0005Ts-00 for seamoby@ietf.org; Fri, 15 Aug 2003 15:43:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7FJgnT25961; Fri, 15 Aug 2003 12:42:49 -0700 X-mProtect: <200308151942> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.215, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKWeMhU; Fri, 15 Aug 2003 12:42:47 PDT Message-ID: <3F3D37AB.6010008@iprg.nokia.com> Date: Fri, 15 Aug 2003 12:42:35 -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: phil.neumiller@convergys.com CC: seamoby@ietf.org Subject: Re: [Seamoby] SAML, Liberty Aliance, SISO, EAP vs SeaMoby CT References: 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 Phil, Welcome back! phil.neumiller@convergys.com wrote: >I am curious what some folks on this list think about >SeaMoby CT versus the notion of federated identity >being promoted by the Liberty Alliance. > Since access routers are unlikely to check the federated identity credentials locally, I reckon that we would need a new security profile type for such data, and that it would be subject to context transfer in the same way as envisioned for other security data. >Is anybody planning on implementing SeaMoby CT? > > We already have implemented a pretty complete system with it. My belief is that it should be about ready for actual standardization, regardless of the "Experimental" designation. >"NOTICE: The information contained in this electronic mail transmission is >intended by Convergys Corporation for the use of the named individual or >entity to which it is directed and may contain information that is >privileged or otherwise confidential. If you have received this electronic >mail transmission in error, please delete it from your system without >copying or forwarding it, and notify the sender of the error by reply email >or by telephone (collect), so that the sender's address records can be >corrected." > > O.K. Point noted. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 15 16:36: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 QAA12814 for ; Fri, 15 Aug 2003 16:36: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 19nlIu-0001hD-Cz for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 16:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKa85l006513 for seamoby-archive@odin.ietf.org; Fri, 15 Aug 2003 16:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlIu-0001gt-A4 for seamoby-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:36: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 QAA12757 for ; Fri, 15 Aug 2003 16:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlIr-0005uZ-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 16:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlIq-0005uW-00 for seamoby-web-archive@ietf.org; Fri, 15 Aug 2003 16: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 19nlIn-0001eP-Rh; Fri, 15 Aug 2003 16: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 19nlIc-0001dY-QY for seamoby@optimus.ietf.org; Fri, 15 Aug 2003 16:35:50 -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 QAA12719 for ; Fri, 15 Aug 2003 16:35:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlIa-0005u1-00 for seamoby@ietf.org; Fri, 15 Aug 2003 16:35:48 -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 19nlIZ-0005tt-00 for seamoby@ietf.org; Fri, 15 Aug 2003 16:35:48 -0400 Message-ID: <039c01c3636c$d5d500b0$976015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 15 Aug 2003 13:35:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Call for Journal Papers: Next Generation Mobile Security 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 Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Aug 18 16:19: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 QAA03187 for ; Mon, 18 Aug 2003 16:19: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 19oqT3-0003ib-Dr for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 16:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IKJ5xR014287 for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 16:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqT3-0003iM-6s for seamoby-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 16:19: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 QAA03179 for ; Mon, 18 Aug 2003 16:19:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqT1-0002Gi-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 16:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oqT0-0002Ge-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 16:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqSy-0003hd-Nl; Mon, 18 Aug 2003 16:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqSs-0003hC-2S for seamoby@optimus.ietf.org; Mon, 18 Aug 2003 16:18: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 QAA03173 for ; Mon, 18 Aug 2003 16:18:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqSq-0002Gb-00 for seamoby@ietf.org; Mon, 18 Aug 2003 16:18:52 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19oqSp-0002GW-00 for seamoby@ietf.org; Mon, 18 Aug 2003 16:18:51 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7IKIDZ01700; Mon, 18 Aug 2003 13:18:13 -0700 X-mProtect: <200308182018> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYyWXux; Mon, 18 Aug 2003 13:18:12 PDT Message-ID: <3F413484.1D5B4E82@iprg.nokia.com> Date: Mon, 18 Aug 2003 13:18:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: seamoby@ietf.org Subject: Re: [Seamoby] (virtual) hum on CARD open issues References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> 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 Eunsoo Shim wrote: > > Hi, Vijay, > > I am afraid my question is so long after your posting. > But please let me ask a few questions. > Is there any base for 1 second inter-message interval you suggested? typical ICMP rate limiting. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Aug 18 18:51: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 SAA08394 for ; Mon, 18 Aug 2003 18:51: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 19osq9-0000sB-Ji for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 18:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IMp5qm003349 for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 18:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osq9-0000rw-FH for seamoby-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 18:51: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 SAA08388 for ; Mon, 18 Aug 2003 18:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osq6-0003DQ-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 18:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19osq5-0003DN-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 18: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 19osq6-0000r8-FQ; Mon, 18 Aug 2003 18: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 19ospK-0000n7-FX for seamoby@optimus.ietf.org; Mon, 18 Aug 2003 18:50:14 -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 SAA08357 for ; Mon, 18 Aug 2003 18:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ospH-0003Ct-00 for seamoby@ietf.org; Mon, 18 Aug 2003 18:50:11 -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 19ospG-0003Cp-00 for seamoby@ietf.org; Mon, 18 Aug 2003 18:50:10 -0400 Received: from peace ([138.15.107.210]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Aug 2003 18:50:06 -0400 Message-ID: <01fe01c365db$c13ed6f0$d26b0f8a@peace> From: "Eunsoo Shim" To: "Vijay Devarapalli" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <3F413484.1D5B4E82@iprg.nokia.com> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Mon, 18 Aug 2003 18:55:01 -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: 18 Aug 2003 22:50:06.0877 (UTC) FILETIME=[11E1F4D0:01C365DB] 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 Vijay, ICMP was chosen for MN-AR interaction because we wanted to use the same protocol with the fast handoff protocol. Actually there was an consideration about using UDP instead of MN-AR interaction, too. If UDP was chosen for MN-AR interaction, would you change the value or the rate limiting mechanism? BTW, I'd appreciate if you provide your opinion about my other questions, too. Eunsoo ----- Original Message ----- From: "Vijay Devarapalli" To: "Eunsoo Shim" Cc: Sent: Monday, August 18, 2003 4:18 PM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > Eunsoo Shim wrote: > > > > Hi, Vijay, > > > > I am afraid my question is so long after your posting. > > But please let me ask a few questions. > > Is there any base for 1 second inter-message interval you suggested? > > typical ICMP rate limiting. > > Vijay > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Aug 18 20:14: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 UAA10160 for ; Mon, 18 Aug 2003 20:14: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 19ou8T-00036w-BC for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 20:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J0E5uE011952 for seamoby-archive@odin.ietf.org; Mon, 18 Aug 2003 20: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 19ou8T-00036h-3L for seamoby-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 20: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 UAA10154 for ; Mon, 18 Aug 2003 20:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ou8R-0003ey-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 20:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ou8Q-0003ev-00 for seamoby-web-archive@ietf.org; Mon, 18 Aug 2003 20:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ou8P-00035y-5I; Mon, 18 Aug 2003 20: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 19ou8A-00035h-Ep for seamoby@optimus.ietf.org; Mon, 18 Aug 2003 20:13: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 UAA10138 for ; Mon, 18 Aug 2003 20:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ou88-0003er-00 for seamoby@ietf.org; Mon, 18 Aug 2003 20:13:44 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19ou87-0003eo-00 for seamoby@ietf.org; Mon, 18 Aug 2003 20:13:43 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7J0D6703199; Mon, 18 Aug 2003 17:13:06 -0700 X-mProtect: <200308190013> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh86A6p; Mon, 18 Aug 2003 17:13:04 PDT Message-ID: <3F416B90.2B6B4F4A@iprg.nokia.com> Date: Mon, 18 Aug 2003 17:13:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: seamoby@ietf.org Subject: Re: [Seamoby] (virtual) hum on CARD open issues References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <3F413484.1D5B4E82@iprg.nokia.com> <01fe01c365db$c13ed6f0$d26b0f8a@peace> 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 Eunsoo Shim wrote: > > Vijay, > > ICMP was chosen for MN-AR interaction because we wanted to use the same > protocol with the fast handoff protocol. Actually there was an consideration > about using UDP instead of MN-AR interaction, too. If UDP was chosen for > MN-AR interaction, would you change the value or the rate limiting > mechanism? no, you missed the point. you wanted to know what the basis was for the 1 second retransmission interval. > BTW, I'd appreciate if you provide your opinion about my other questions, > too. I would be repeating myself. I think I made it clear which rate-limiting mechanism I prefer. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Aug 19 11:19:36 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 LAA17560 for ; Tue, 19 Aug 2003 11:19:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p8GJ-0001OJ-Id for seamoby-archive@odin.ietf.org; Tue, 19 Aug 2003 11:19:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JFJ7Ga005343 for seamoby-archive@odin.ietf.org; Tue, 19 Aug 2003 11:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p8GJ-0001O6-Fh for seamoby-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 11:19: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 LAA17552 for ; Tue, 19 Aug 2003 11:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p8GI-0001y3-00 for seamoby-web-archive@ietf.org; Tue, 19 Aug 2003 11:19:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p8GI-0001y0-00 for seamoby-web-archive@ietf.org; Tue, 19 Aug 2003 11:19:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p8GD-0001NP-DE; Tue, 19 Aug 2003 11: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 19p8Fe-0001Mm-3g for seamoby@optimus.ietf.org; Tue, 19 Aug 2003 11:18:26 -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 LAA17511 for ; Tue, 19 Aug 2003 11:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p8Fd-0001xI-00 for seamoby@ietf.org; Tue, 19 Aug 2003 11:18:25 -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 19p8Fb-0001xC-00 for seamoby@ietf.org; Tue, 19 Aug 2003 11:18:24 -0400 Message-ID: <001801c36665$2944ca50$0a6015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , "Eunsoo Shim" Cc: References: <3F1C16C6.330CDA85@iprg.nokia.com> <00b301c36339$238302a0$d26b0f8a@peace> <3F413484.1D5B4E82@iprg.nokia.com> <01fe01c365db$c13ed6f0$d26b0f8a@peace> <3F416B90.2B6B4F4A@iprg.nokia.com> Subject: Re: [Seamoby] (virtual) hum on CARD open issues Date: Tue, 19 Aug 2003 08:18:36 -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 Ensuoo, I think we have concensus on rate limiting. It's time to cut off discussion and move on. Thanx. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Eunsoo Shim" Cc: Sent: Monday, August 18, 2003 5:13 PM Subject: Re: [Seamoby] (virtual) hum on CARD open issues > Eunsoo Shim wrote: > > > > Vijay, > > > > ICMP was chosen for MN-AR interaction because we wanted to use the same > > protocol with the fast handoff protocol. Actually there was an consideration > > about using UDP instead of MN-AR interaction, too. If UDP was chosen for > > MN-AR interaction, would you change the value or the rate limiting > > mechanism? > > no, you missed the point. you wanted to know what the > basis was for the 1 second retransmission interval. > > > BTW, I'd appreciate if you provide your opinion about my other questions, > > too. > > I would be repeating myself. I think I made it clear which > rate-limiting mechanism I prefer. > > Vijay > > _______________________________________________ > 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 Aug 20 15:20: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 PAA02149 for ; Wed, 20 Aug 2003 15:20: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 19pYV2-00077J-KO for seamoby-archive@odin.ietf.org; Wed, 20 Aug 2003 15:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KJK4M8027346 for seamoby-archive@odin.ietf.org; Wed, 20 Aug 2003 15:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYV2-00076t-9K for seamoby-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 15:20: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 PAA02133 for ; Wed, 20 Aug 2003 15:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYV1-0005l5-00 for seamoby-web-archive@ietf.org; Wed, 20 Aug 2003 15:20:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pYV0-0005l1-00 for seamoby-web-archive@ietf.org; Wed, 20 Aug 2003 15:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYUz-00074H-CM; Wed, 20 Aug 2003 15:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYJZ-0006fR-W2 for seamoby@optimus.ietf.org; Wed, 20 Aug 2003 15:08:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00691; Wed, 20 Aug 2003 15:08:06 -0400 (EDT) Message-Id: <200308201908.PAA00691@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, 20 Aug 2003 15:08:05 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-protocol-03.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-03.txt Pages : 47 Date : 2003-8-20 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-03.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-03.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-03.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-8-20112329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112329.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 Aug 20 15:46: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 PAA05808 for ; Wed, 20 Aug 2003 15:46: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 19pYuF-0000on-CN for seamoby-archive@odin.ietf.org; Wed, 20 Aug 2003 15:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KJk7iP003139 for seamoby-archive@odin.ietf.org; Wed, 20 Aug 2003 15:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYuF-0000oY-7f for seamoby-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 15:46: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 PAA05777 for ; Wed, 20 Aug 2003 15:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYuD-0006gg-00 for seamoby-web-archive@ietf.org; Wed, 20 Aug 2003 15:46:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pYuC-0006gd-00 for seamoby-web-archive@ietf.org; Wed, 20 Aug 2003 15:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pYuA-0000na-QU; Wed, 20 Aug 2003 15: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 19pYtr-0000mQ-Sg for seamoby@optimus.ietf.org; Wed, 20 Aug 2003 15:45: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 PAA05760 for ; Wed, 20 Aug 2003 15:45:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYtq-0006gB-00 for seamoby@ietf.org; Wed, 20 Aug 2003 15:45:42 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19pYtp-0006g8-00 for seamoby@ietf.org; Wed, 20 Aug 2003 15:45:41 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h7KJjf410006 for ; Wed, 20 Aug 2003 15:45:41 -0400 Date: Wed, 20 Aug 2003 15:45:41 -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 early registration and hotel deadline is August 28 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 receive multiple copies of this message. ---------------------------------- Just a reminder that the deadline for early discounted registration and hotel reservation for MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, is next Thursday, August 28. MobiCom is the premier international forum addressing all issues in mobile computing and wireless and mobile networking at the link layer and above. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in beautiful, sunny San Diego, California. The program for MobiCom 2003 includes 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 There will also be 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 For complete details about MobiCom 2003, including registration and hotel information, plus all the latest MobiCom 2003 news, please see http://www.sigmobile.org/mobicom/2003/ Again, the deadlines for special discounted early registration fees and for special hotel room rates are both Thursday, August 28, 2003. 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 Fri Aug 22 00:45: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 AAA20521 for ; Fri, 22 Aug 2003 00:45: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 19q3nP-0003Mc-9j for seamoby-archive@odin.ietf.org; Fri, 22 Aug 2003 00:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M4j7lq012924 for seamoby-archive@odin.ietf.org; Fri, 22 Aug 2003 00:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3nP-0003MN-5X for seamoby-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 00:45: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 AAA20501 for ; Fri, 22 Aug 2003 00:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3nM-0006UU-00 for seamoby-web-archive@ietf.org; Fri, 22 Aug 2003 00:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q3nL-0006UQ-00 for seamoby-web-archive@ietf.org; Fri, 22 Aug 2003 00:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3nK-0003La-KL; Fri, 22 Aug 2003 00:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3n3-0003L7-EL for seamoby@optimus.ietf.org; Fri, 22 Aug 2003 00:44: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 AAA20488 for ; Fri, 22 Aug 2003 00:44:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3n0-0006U9-00 for seamoby@ietf.org; Fri, 22 Aug 2003 00:44:42 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19q3mz-0006U6-00 for seamoby@ietf.org; Fri, 22 Aug 2003 00:44:42 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7M4igLf008366 for ; Thu, 21 Aug 2003 21:44:42 -0700 (MST) Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7M4idLR002246 for ; Thu, 21 Aug 2003 23:44:39 -0500 Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 21 Aug 2003 23:44:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A29E@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'seamoby@ietf.org'" Date: Thu, 21 Aug 2003 23:44:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [Seamoby] Submitted intermediate version of CARD draft 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: , Hi, We have submitted an updated version of the CARD draft for WG review. The updated draft contains the resolution of the some of important issues raised by the WG members. We plan to resolve the remaining issues in next revision. Since Marco and I are on vacation, so most probably we will submit the next update some time next month. Regards, Ajoy http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-03.txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Aug 22 13:37:22 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 NAA09270 for ; Fri, 22 Aug 2003 13:37:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFqI-0005r3-F1 for seamoby-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHasPo022499 for seamoby-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFqI-0005qo-AJ for seamoby-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 13:36:54 -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 NAA09123 for ; Fri, 22 Aug 2003 13:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFph-0005PL-Su; Fri, 22 Aug 2003 13:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFJX-00046k-My for seamoby@optimus.ietf.org; Fri, 22 Aug 2003 13:03: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 NAA07289 for ; Fri, 22 Aug 2003 13:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qFJV-0006zR-00 for seamoby@ietf.org; Fri, 22 Aug 2003 13:03:02 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19qFJU-0006zO-00 for seamoby@ietf.org; Fri, 22 Aug 2003 13:03:01 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7MH2w5J009803 for ; Fri, 22 Aug 2003 10:02:59 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7MH2sLR000470 for ; Fri, 22 Aug 2003 12:02:55 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 22 Aug 2003 12:02:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A2A0@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'seamoby@ietf.org'" Date: Fri, 22 Aug 2003 12:02:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [Seamoby] Submitted intermediate version of CARD draft 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: , Hi, We have submitted an updated version of the CARD for WG review. The updated draft contains resolutions of the some of the important issues raised by the WG members. We plan to resolve the remaining issues in next revision. Since Marco and I are on vacation so probably we will submit the next revision some time next month. Regards, Ajoy http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-03. txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Aug 27 02:29:36 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 CAA22941 for ; Wed, 27 Aug 2003 02:29: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 19rtfT-0002bE-JY for seamoby-archive@odin.ietf.org; Wed, 27 Aug 2003 02:20:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6KToa009957 for seamoby-archive@odin.ietf.org; Wed, 27 Aug 2003 02:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rrPB-0001vw-97 for seamoby-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 23:55: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 XAA15363 for ; Tue, 26 Aug 2003 23:55:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rrP8-0003BB-00 for seamoby-web-archive@ietf.org; Tue, 26 Aug 2003 23:55:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rrP7-0003B7-00 for seamoby-web-archive@ietf.org; Tue, 26 Aug 2003 23:55:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmp1-0005E4-03; Tue, 26 Aug 2003 19:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdMQ-0002a7-KJ for seamoby@optimus.ietf.org; Tue, 26 Aug 2003 08:55: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 IAA02029 for ; Tue, 26 Aug 2003 08:55:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdMP-0000Nd-00 for seamoby@ietf.org; Tue, 26 Aug 2003 08:55:45 -0400 Received: from [133.11.236.3] (helo=saffron.mlab.t.u-tokyo.ac.jp) by ietf-mx with esmtp (Exim 4.12) id 19rdMO-0000Na-00 for seamoby@ietf.org; Tue, 26 Aug 2003 08:55:44 -0400 Received: from saffron.mlab.t.u-tokyo.ac.jp (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id ED4352CE9FB for ; Tue, 26 Aug 2003 21:55:42 +0900 (JST) Received: from MORI-T40.mlab.t.u-tokyo.ac.jp (unknown [133.11.236.2]) by saffron.mlab.t.u-tokyo.ac.jp (Postfix) with ESMTP id 5354F2CE9FA for ; Tue, 26 Aug 2003 21:55:42 +0900 (JST) Message-Id: <5.1.1.9.2.20030826215508.0677e6f8@mail.mlab.t.u-tokyo.ac.jp> X-Sender: mori@mail.mlab.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4 Date: Tue, 26 Aug 2003 21:55:12 +0900 To: seamoby@ietf.org From: Hiroyuki Morikawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] WiSe: Call for Participation 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 CALL FOR PARTICIPATION Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2003 September 19, 2003 Westin Horton Plaza Hotel San Diego, CA http://www.ece.cmu.edu/~adrian/wise2003 Sponsored by SIGMOBILE ACM WMASH 2003 Registration is available via the ACM MobiCom website http://www.sigmobile.org/mobicom/2003/registration.html (Early registration ends August 28, 2003) ==================================================== TECHNICAL PROGRAM ==================================================== Location -------- Session Chair: Stephen Zabele 8:30-9:30am * Secure Verification of Location Claims Naveen Sastry (UC Berkeley), Umesh Shankar (UC Berkeley), and David Wagner (UC Berkeley) * Wireless LAN Location-Sensing for Security Applications Ping Tao (Rice), Algis Rudys (Rice), Andrew Ladd (Rice), and Dan Wallach (Rice) Secure Routing -------------- Session Chair: Brian van Leeuwen 9:45-11:15am * BISS: Building secure routing out of an incomplete set of security associations Srdjan Capkun (EPFL) and Jean-Pierre Hubaux (EPFL) * Rushing Attacks and Defense in Wireless Ad Hoc Network Routing Protocols Yih-Chun Hu (CMU), Adrian Perrig (CMU), and David Johnson (Rice) * Secure Data Transmission in Mobile Ad Hoc Networks Panagiotis Papadimitratos (Cornell) and Zygmunt Haas (Cornell) Poster Session -------------- 11:15-11:45pm * Key Pre-Distribution Using Sensor Pre-Deployment Knowledge Wenliang Du (Syracuse University), Lei Fang (Syracuse University), Ronghua Wang (Syracuse University), and Shigang Chen (University of Florida) * Detecting Wormhole Attacks in Ad Hoc Networks without Clock Synchronization Assumption Weichao Wang (Purdue) * Authentication for Network Access Control using DHCPv6 Parijat Mishra (Institute for Infocomm Research Singapore), Matthew Lim Boon Kiat (National University of Singapore), and Winston Seah Khoon Guan (Institute for Infocomm Research Singapore) * Dynamic Fingerprints: Improving the Usability of Peer-to-Peer Authentication Lyn Bartram (Colligo), Barry Jinks (Colligo), Nick Sawadsky (Colligo) Lunch ----- 11:45am-1pm Invited Presentations --------------------- Session Chair: Douglas Maughan 1-2pm Speakers TBD. Securing Wireless Applications ------------------------------ Session Chair: Jean-Pierre Hubaux 2:15-3:15pm * ESCORT: A Decentralized and Localized Access Control System for Mobile Wireless Access to Secured Domains Jiejun Kong (UCLA), Shirshanka Das (UCLA), Edward Tsai (UCLA), and Mario Gerla (UCLA) * On Securely Enabling Intermediary-Based Services and Performance Enhancements for Wireless Mobile Users Sneha Kasera (Bell Labs), Semyon Mizikovsky (Bell Labs), Ganapathy Sundaram (Bell Labs), and Thomas Woo (Bell Labs) Secure Wireless Protocols ------------------------- Session Chair: Markus Jakobsson 3:30-5pm * Alert Aggregation in Mobile Ad Hoc Networks Bo Sun (Texas A&M), Kui Wu (University of Victoria), and Udo Pooch (Texas A&M) * An Authentication Framework for Hierarchical Ad Hoc Sensor Networks Mathias Bohge (TU Berlin) and Wade Trappe (Rutgers) * On the Security of Wireless Network Access with Enhancements Lein Harn (University of Missouri) and Wen-Jung Hsin (University of Missouri) ========================================================= ORGANIZERS ========================================================= Workshop Co-Chairs: Douglas Maughan, Defense Advanced Research Projects Agency Adrian Perrig, Carnegie Mellon University Program Committee: Bill Arbaugh, University of Maryland Brian Noble, University of Michigan Brian Van Leeuwen, Sandia National Laboratories Chinya Ravishankar, University of California at Riverside Jean-Pierre Hubaux, EPFL Jonathan Smith, University of Pennsylvania Leendert van Doorn, IBM Markus Jakobsson, RSA Security Radha Poovendran, University of Washington Stephen Zabele, Alphatech Wenke Lee, Georgia Institute of Technology Yair Amir, Johns Hopkins University Publicity Co-Chairs: Mohsen Guizani, Western Michigan University Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Treasurer Yongguang Zhang, HRL Labs and UT-Austin ============================================================ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Sat Aug 30 03:58:15 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 DAA00117 for ; Sat, 30 Aug 2003 03:58:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19szZ2-0006oe-5s for seamoby-archive@odin.ietf.org; Sat, 30 Aug 2003 02:50:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U6oNQq026186 for seamoby-archive@odin.ietf.org; Sat, 30 Aug 2003 02:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19syNt-0002Ch-A1 for seamoby-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 01:34: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 BAA11219 for ; Sat, 30 Aug 2003 01:34:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19syNq-0000Pg-00 for seamoby-web-archive@ietf.org; Sat, 30 Aug 2003 01:34:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19syNp-0000Pc-00 for seamoby-web-archive@ietf.org; Sat, 30 Aug 2003 01:34:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sv8H-0008M8-V3; Fri, 29 Aug 2003 22:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssCD-0008Ok-3H for seamoby@optimus.ietf.org; Fri, 29 Aug 2003 18:58: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 SAA15278 for ; Fri, 29 Aug 2003 18:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ssC9-0002n7-00 for seamoby@ietf.org; Fri, 29 Aug 2003 18:58:17 -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 19ssC8-0002n2-00 for seamoby@ietf.org; Fri, 29 Aug 2003 18:58:17 -0400 Message-ID: <041301c36e81$102d8100$956015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 29 Aug 2003 15:58:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Issue: Variable Length Context Blocks for 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 Section 2.3 in the CTP spec says that the length of the context block is fixed in the context type definition. But what if the context block could be variable length? Note that it is possible to define multiple blocks that carry different instances, but that would require a Context Data Block header on each, plus possibly duplicated context specific data. It might be helpful to have a specific length field. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby