From exim@www1.ietf.org Wed Oct 1 06:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06977 for ; Wed, 1 Oct 2003 06:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4e7Q-0006mf-LO for seamoby-archive@odin.ietf.org; Wed, 01 Oct 2003 06:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91AM4wK026071 for seamoby-archive@odin.ietf.org; Wed, 1 Oct 2003 06:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4e7Q-0006mQ-G5 for seamoby-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 06:22: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 GAA06964 for ; Wed, 1 Oct 2003 06:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4e7M-0005Le-00 for seamoby-web-archive@ietf.org; Wed, 01 Oct 2003 06:22:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4e7M-0005La-00 for seamoby-web-archive@ietf.org; Wed, 01 Oct 2003 06:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4e7N-0006li-5A; Wed, 01 Oct 2003 06: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 1A4e6Y-0006eq-4f for seamoby@optimus.ietf.org; Wed, 01 Oct 2003 06:21: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 GAA06956 for ; Wed, 1 Oct 2003 06:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4e6Q-0005LQ-00 for seamoby@ietf.org; Wed, 01 Oct 2003 06:21:02 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A4e6P-0005LH-00 for seamoby@ietf.org; Wed, 01 Oct 2003 06:21:02 -0400 Received: from inwind.it ([193.204.86.111]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h91AKxN01193 for ; Wed, 1 Oct 2003 12:20:59 +0200 (CEST) Date: Wed, 1 Oct 2003 12:18:33 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] A Question about L2 ID ..... 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, One question for you. Which is exactly the ID at L2 that MN listen to make handover decisions? Is it the ESSID of AP? Or is it the MAC Address? Or other? I've understood that it is the ESSID, but it is not the one by definition.... If there are some APs in MN's range with the same name, what happens? Ivano _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 1 11:24:01 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 LAA18493 for ; Wed, 1 Oct 2003 11:24:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ipE-0007RB-TH for seamoby-archive@odin.ietf.org; Wed, 01 Oct 2003 11:23:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FNawv028585 for seamoby-archive@odin.ietf.org; Wed, 1 Oct 2003 11:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ipE-0007Qy-PD for seamoby-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:23:36 -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 LAA18452 for ; Wed, 1 Oct 2003 11:23: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 1A4iof-0007OJ-DQ; Wed, 01 Oct 2003 11:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4inx-00079j-7U for seamoby@optimus.ietf.org; Wed, 01 Oct 2003 11:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18329 for ; Wed, 1 Oct 2003 11:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4inv-0000hZ-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:22:15 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A4inu-0000hD-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:22:14 -0400 Message-ID: <008b01c3882f$d3eb75d0$956015ac@dclkempt40> From: "James Kempf" To: "Ivano De Luca" , References: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> Subject: Re: [Seamoby] A Question about L2 ID ..... Date: Wed, 1 Oct 2003 08:22:29 -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 It's the MAC address. jak ----- Original Message ----- From: "Ivano De Luca" To: Sent: Wednesday, October 01, 2003 3:18 AM Subject: [Seamoby] A Question about L2 ID ..... > Hello, > One question for you. > Which is exactly the ID at L2 that MN listen to make handover decisions? > Is it the ESSID of AP? Or is it the MAC Address? Or other? > > I've understood that it is the ESSID, but it is not the one by > definition.... > If there are some APs in MN's range with the same name, what happens? > > Ivano > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 1 11:26:57 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 LAA18949 for ; Wed, 1 Oct 2003 11:26:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4is5-0007hH-Tl for seamoby-archive@odin.ietf.org; Wed, 01 Oct 2003 11:26:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FQXBo029581 for seamoby-archive@odin.ietf.org; Wed, 1 Oct 2003 11:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4is5-0007h2-Qg for seamoby-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:26:33 -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 LAA18918 for ; Wed, 1 Oct 2003 11:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4irZ-0007W4-JP; Wed, 01 Oct 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iqf-0007V9-D1 for seamoby@optimus.ietf.org; Wed, 01 Oct 2003 11:25: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 LAA18690 for ; Wed, 1 Oct 2003 11:24:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4iqe-0000na-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:25:04 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A4iqd-0000nS-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:25:03 -0400 Received: from inwind.it ([193.204.86.111]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h91FOxN18499; Wed, 1 Oct 2003 17:24:59 +0200 (CEST) Date: Wed, 1 Oct 2003 17:22:07 +0200 Subject: Re: [Seamoby] A Question about L2 ID ..... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: seamoby@ietf.org To: "James Kempf" From: Ivano De Luca In-Reply-To: <008b01c3882f$d3eb75d0$956015ac@dclkempt40> Message-Id: <04E870EB-F423-11D7-9D63-000A95946ED6@inwind.it> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) 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 Mercoled=EC, 1 Ott 2003, alle 17:22 Europe/Rome, James Kempf ha scritto: > It's the MAC address. But do you know that tha AP's MAC address could be changed by users ?=20 So I don't think it's a good ID for AP Don't you ? Ivano _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 1 11:28:55 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 LAA19072 for ; Wed, 1 Oct 2003 11:28:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iu0-0007vj-5e for seamoby-archive@odin.ietf.org; Wed, 01 Oct 2003 11:28:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FSWH8030477 for seamoby-archive@odin.ietf.org; Wed, 1 Oct 2003 11:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4itz-0007um-BN for seamoby-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:28:31 -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 LAA19031 for ; Wed, 1 Oct 2003 11:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4itU-0007pi-PQ; Wed, 01 Oct 2003 11:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iss-0007ii-RP for seamoby@optimus.ietf.org; Wed, 01 Oct 2003 11:27: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 LAA18972 for ; Wed, 1 Oct 2003 11:27:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4isr-0000s6-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:27:21 -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 1A4isr-0000s3-00 for seamoby@ietf.org; Wed, 01 Oct 2003 11:27:21 -0400 Message-ID: <00f501c38830$8b7dc8b0$956015ac@dclkempt40> From: "James Kempf" To: "Ivano De Luca" Cc: References: <04E870EB-F423-11D7-9D63-000A95946ED6@inwind.it> Subject: Re: [Seamoby] A Question about L2 ID ..... Date: Wed, 1 Oct 2003 08:27:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 The ESSID could be changed as well. The attacker would need to break int= o the AP in order to change either. The assumption is that the AP has been secured. The security for that is outside of the scope of the CARD protoc= ol. jak ----- Original Message -----=20 From: "Ivano De Luca" To: "James Kempf" Cc: Sent: Wednesday, October 01, 2003 8:22 AM Subject: Re: [Seamoby] A Question about L2 ID ..... > > Mercoled=EC, 1 Ott 2003, alle 17:22 Europe/Rome, James Kempf ha scritto= : > > > It's the MAC address. > But do you know that tha AP's MAC address could be changed by users ? > So I don't think it's a good ID for AP > Don't you ? > > Ivano > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 3 09:30: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 JAA06256 for ; Fri, 3 Oct 2003 09:30: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 1A5Q0W-0005bq-8E for seamoby-archive@odin.ietf.org; Fri, 03 Oct 2003 09:30:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93DU8vb021537 for seamoby-archive@odin.ietf.org; Fri, 3 Oct 2003 09:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q0V-0005bI-Tv for seamoby-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 09:30: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 JAA06205 for ; Fri, 3 Oct 2003 09:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0T-0000m8-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 09:30:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Q0T-0000m4-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 09:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q0Q-0005ao-Lo; Fri, 03 Oct 2003 09: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 1A5PzV-0005Xh-4c for seamoby@optimus.ietf.org; Fri, 03 Oct 2003 09:29: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 JAA06146 for ; Fri, 3 Oct 2003 09:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5PzT-0000kc-00 for seamoby@ietf.org; Fri, 03 Oct 2003 09:29:03 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A5PzS-0000kY-00 for seamoby@ietf.org; Fri, 03 Oct 2003 09:29:02 -0400 Received: from [193.204.77.163] (localhost [127.0.0.1]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h93DSqN09725; Fri, 3 Oct 2003 15:28:52 +0200 (CEST) Mime-Version: 1.0 X-Sender: molendin@mailing.unile.it Message-Id: In-Reply-To: <008b01c3882f$d3eb75d0$956015ac@dclkempt40> References: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> <008b01c3882f$d3eb75d0$956015ac@dclkempt40> Date: Fri, 3 Oct 2003 15:28:51 +0200 To: "James Kempf" From: Simone Molendini Subject: Re: [Seamoby] A Question about L2 ID ..... Cc: seamoby@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , I have concerns on the fact that par. 5.1.3.1 defines the "L2 type" and "L2 ID" fields as a L2 general ID (with unassigned values and prefixes). The fixed-length EUI-64 is used as a global identifier in a number of the format prefixes Interface IDs (including IEEE802). Why using what haven't been already defined when something else has been defined and registered? Simone >It's the MAC address. > > jak > >----- Original Message ----- >From: "Ivano De Luca" >To: >Sent: Wednesday, October 01, 2003 3:18 AM >Subject: [Seamoby] A Question about L2 ID ..... > > >> Hello, >> One question for you. >> Which is exactly the ID at L2 that MN listen to make handover decisions? >> Is it the ESSID of AP? Or is it the MAC Address? Or other? >> >> I've understood that it is the ESSID, but it is not the one by >> definition.... >> If there are some APs in MN's range with the same name, what happens? >> >> Ivano >> >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 3 10: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 KAA10762 for ; Fri, 3 Oct 2003 10: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 1A5RGs-00016r-F1 for seamoby-archive@odin.ietf.org; Fri, 03 Oct 2003 10:51:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Ep6Wj004264 for seamoby-archive@odin.ietf.org; Fri, 3 Oct 2003 10:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RGs-00016h-BT for seamoby-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 10:51: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 KAA10691 for ; Fri, 3 Oct 2003 10:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RGp-0001kw-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 10:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5RGp-0001kt-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 10:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RGo-00015z-El; Fri, 03 Oct 2003 10: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 1A5RFw-0000zp-5Q for seamoby@optimus.ietf.org; Fri, 03 Oct 2003 10: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 KAA10627 for ; Fri, 3 Oct 2003 10:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RFq-0001jx-00 for seamoby@ietf.org; Fri, 03 Oct 2003 10:50:02 -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 1A5RFq-0001jm-00 for seamoby@ietf.org; Fri, 03 Oct 2003 10:50:02 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Oct 2003 10:49:56 -0400 Message-ID: <00a801c389be$4ad46190$c96b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Simone Molendini" Cc: References: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> <008b01c3882f$d3eb75d0$956015ac@dclkempt40> Subject: Re: [Seamoby] A Question about L2 ID ..... Date: Fri, 3 Oct 2003 10:54:48 -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: 03 Oct 2003 14:49:56.0732 (UTC) FILETIME=[9CB333C0:01C389BD] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The CARD protocol should be able to operate on any kind of (wireless) L2 technologies including their various MAC/link address formats. So the CARD protocol does not assume any single format for MAC/link addresses. Hope this answers your question. Eunsoo ----- Original Message ----- From: "Simone Molendini" To: "James Kempf" Cc: Sent: Friday, October 03, 2003 9:28 AM Subject: Re: [Seamoby] A Question about L2 ID ..... > I have concerns on the fact that par. 5.1.3.1 defines the "L2 type" > and "L2 ID" fields as a L2 general ID (with unassigned values and > prefixes). > > The fixed-length EUI-64 is used as a global identifier in a number of > the format prefixes Interface IDs (including IEEE802). > > Why using what haven't been already defined when something else has > been defined and registered? > > Simone > > >It's the MAC address. > > > > jak > > > >----- Original Message ----- > >From: "Ivano De Luca" > >To: > >Sent: Wednesday, October 01, 2003 3:18 AM > >Subject: [Seamoby] A Question about L2 ID ..... > > > > > >> Hello, > >> One question for you. > >> Which is exactly the ID at L2 that MN listen to make handover decisions? > >> Is it the ESSID of AP? Or is it the MAC Address? Or other? > >> > >> I've understood that it is the ESSID, but it is not the one by > >> definition.... > >> If there are some APs in MN's range with the same name, what happens? > >> > >> Ivano > >> > >> > >> _______________________________________________ > >> Seamoby mailing list > >> Seamoby@ietf.org > >> https://www1.ietf.org/mailman/listinfo/seamoby > >> > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > 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 Oct 3 11:24: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 LAA11936 for ; Fri, 3 Oct 2003 11:24: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 1A5Rmm-0002dT-4W for seamoby-archive@odin.ietf.org; Fri, 03 Oct 2003 11:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93FO4FZ010125 for seamoby-archive@odin.ietf.org; Fri, 3 Oct 2003 11:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rmm-0002dE-0k for seamoby-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 11:24: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 LAA11932 for ; Fri, 3 Oct 2003 11:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Rml-00025q-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 11:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Rmk-00025n-00 for seamoby-web-archive@ietf.org; Fri, 03 Oct 2003 11:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rmj-0002cX-Dv; Fri, 03 Oct 2003 11: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 1A5RmR-0002c8-8s for seamoby@optimus.ietf.org; Fri, 03 Oct 2003 11:23: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 LAA11929 for ; Fri, 3 Oct 2003 11:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RmQ-00025e-00 for seamoby@ietf.org; Fri, 03 Oct 2003 11:23:42 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1A5RmP-00025b-00 for seamoby@ietf.org; Fri, 03 Oct 2003 11:23:41 -0400 Received: from [193.204.77.163] (localhost [127.0.0.1]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h93FNMN14778; Fri, 3 Oct 2003 17:23:22 +0200 (CEST) Mime-Version: 1.0 X-Sender: molendin@mailing.unile.it Message-Id: In-Reply-To: <00a801c389be$4ad46190$c96b0f8a@peace> References: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> <008b01c3882f$d3eb75d0$956015ac@dclkempt40> <00a801c389be$4ad46190$c96b0f8a@peace> Date: Fri, 3 Oct 2003 17:23:21 +0200 To: "Eunsoo Shim" From: Simone Molendini Subject: Re: [Seamoby] A Question about L2 ID ..... Cc: seamoby@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 CARD protocol should be able to operate on any kind of (wireless) L2 >technologies including their various MAC/link address formats. >So the CARD protocol does not assume any single format for MAC/link >addresses. >Hope this answers your question. First of all, thank you for your help. I've got this point and I agree: the use of a L2 (wireless) MAC for a plurality of technologies needs. I just think that it's a waste of work defining a syntax when a standard, to this purpose, already exists: the (Modified) EUI-64 is used, for example, to derive a *number* of kind of MACs into IPv6 addresses (see Appendix A in RFC3513). If the CARD protocol aims to define a global MAC, EUI-64 is an easy solution (IMHO). Simone > >Eunsoo > >----- Original Message ----- >From: "Simone Molendini" >To: "James Kempf" >Cc: >Sent: Friday, October 03, 2003 9:28 AM >Subject: Re: [Seamoby] A Question about L2 ID ..... > > >> I have concerns on the fact that par. 5.1.3.1 defines the "L2 type" >> and "L2 ID" fields as a L2 general ID (with unassigned values and >> prefixes). >> >> The fixed-length EUI-64 is used as a global identifier in a number of >> the format prefixes Interface IDs (including IEEE802). >> >> Why using what haven't been already defined when something else has >> been defined and registered? >> >> Simone >> >> >It's the MAC address. >> > > > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 7 10:33: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 KAA04274 for ; Tue, 7 Oct 2003 10:33: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 1A6stj-0003ZO-Qf for seamoby-archive@odin.ietf.org; Tue, 07 Oct 2003 10:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97EXBI1013719 for seamoby-archive@odin.ietf.org; Tue, 7 Oct 2003 10:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6stj-0003ZC-Jr for seamoby-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 10:33: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 KAA04254 for ; Tue, 7 Oct 2003 10:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6sth-0006Fp-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 10:33:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6stg-0006Fl-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 10:33:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6stY-0003YN-Va; Tue, 07 Oct 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6stC-0003Xy-PT for seamoby@optimus.ietf.org; Tue, 07 Oct 2003 10:32:38 -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 KAA04233 for ; Tue, 7 Oct 2003 10:32:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6stA-0006FJ-00 for seamoby@ietf.org; Tue, 07 Oct 2003 10:32:36 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A6st9-0006Eu-00 for seamoby@ietf.org; Tue, 07 Oct 2003 10:32:35 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h97EVvev045420 for ; Tue, 7 Oct 2003 16:31:58 +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 865C0D28EE for ; Tue, 7 Oct 2003 15:59:52 +0200 (CEST) Message-ID: <3F82CE5C.2060706@ccrle.nec.de> Date: Tue, 07 Oct 2003 16:31:56 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD issue tracker updated Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The CARD protocol issue tracker has been updated (https://roundup.machshav.com/seamoby/index). Since the proposals for pending issues have been incorporated into the draft version 04, these issues indicate now "text proposed" and will be considered as accepted in case no concerns will be addressed on the mailing list. So, please check and comment. marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 7 10:57:24 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 KAA05293 for ; Tue, 7 Oct 2003 10:57:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tGp-0005EY-DG for seamoby-archive@odin.ietf.org; Tue, 07 Oct 2003 10:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Ev30R020104 for seamoby-archive@odin.ietf.org; Tue, 7 Oct 2003 10:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tGp-0005EB-4g for seamoby-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 10:57: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 KAA05247 for ; Tue, 7 Oct 2003 10:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tGm-0006YV-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 10:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6tGm-0006YS-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 10:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tGn-0005DS-96; Tue, 07 Oct 2003 10: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 1A6tGj-0005D0-7z for seamoby@optimus.ietf.org; Tue, 07 Oct 2003 10:56:57 -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 KAA05241 for ; Tue, 7 Oct 2003 10:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tGf-0006YH-00 for seamoby@ietf.org; Tue, 07 Oct 2003 10:56:53 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A6tGe-0006Xg-00 for seamoby@ietf.org; Tue, 07 Oct 2003 10:56:52 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h97EuHf5046891 for ; Tue, 7 Oct 2003 16:56:21 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h97EpOA6046411 for ; Tue, 7 Oct 2003 16:51:24 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h97EpNev046408; Tue, 07 Oct 2003 16:51:24 +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 307B97B68B; Tue, 7 Oct 2003 16:19:18 +0200 (CEST) Message-ID: <3F82D2EA.6070809@ccrle.nec.de> Date: Tue, 07 Oct 2003 16:51:22 +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: Simone Molendini Cc: Eunsoo Shim , seamoby@ietf.org Subject: Re: [Seamoby] A Question about L2 ID ..... References: <9CD3511E-F3F8-11D7-B02C-000A95946ED6@inwind.it> <008b01c3882f$d3eb75d0$956015ac@dclkempt40> <00a801c389be$4ad46190$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 Simone, I think the current specification doesn't conflict with using the format for actual identifiers you refer to, as long as it contains a unique (technology specific) L2 identifier (like MAC addresses). I also agree that we should reuse specified numbers and formats if possible. However, I don't see a need to specify in the CARD protocol document the actual L2 identifier to be used for individual access technologies. But I also think it is needed to have control on the numbers assigned to L2 "type" (see issue#30), hence, the proposal is to request IANA for number assignment and initial types could be the ones indicated in the recent draft. If accuracy of types must be larger (802.11a, 802.11b, FDD CDMA, TDD CDMA,...), this should be discussed on the mailing list. We checked also here whether or not already existing type identifiers can be re-used, but did not find something appropriate. If you know about available type identifiers, please send a pointer to this information. marco Simone Molendini wrote: >> The CARD protocol should be able to operate on any kind of (wireless) L2 >> technologies including their various MAC/link address formats. >> So the CARD protocol does not assume any single format for MAC/link >> addresses. >> Hope this answers your question. > > > First of all, thank you for your help. > I've got this point and I agree: the use of a L2 (wireless) MAC for a > plurality of technologies needs. > > I just think that it's a waste of work defining a syntax when a > standard, to this purpose, already exists: the (Modified) EUI-64 is > used, for example, to derive a *number* of kind of MACs into IPv6 > addresses (see Appendix A in RFC3513). > > If the CARD protocol aims to define a global MAC, EUI-64 is an easy > solution (IMHO). > > Simone > >> >> Eunsoo >> >> ----- Original Message ----- >> From: "Simone Molendini" >> To: "James Kempf" >> Cc: >> Sent: Friday, October 03, 2003 9:28 AM >> Subject: Re: [Seamoby] A Question about L2 ID ..... >> >> >>> I have concerns on the fact that par. 5.1.3.1 defines the "L2 type" >>> and "L2 ID" fields as a L2 general ID (with unassigned values and >>> prefixes). >>> >>> The fixed-length EUI-64 is used as a global identifier in a number of >>> the format prefixes Interface IDs (including IEEE802). >>> >>> Why using what haven't been already defined when something else has >>> been defined and registered? >>> >>> Simone >>> >>> >It's the MAC address. >>> > >> >> > > jak > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 7 12:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10643 for ; Tue, 7 Oct 2003 12:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uf2-0001pk-Ss for seamoby-archive@odin.ietf.org; Tue, 07 Oct 2003 12:26:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97GQ8VC007042 for seamoby-archive@odin.ietf.org; Tue, 7 Oct 2003 12:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uf2-0001pU-Iv for seamoby-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 12:26: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 MAA10622 for ; Tue, 7 Oct 2003 12:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6uf1-0000Rp-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 12:26:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6uf0-0000Rk-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 12:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uev-0001od-E5; Tue, 07 Oct 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ueX-0001ne-OB for seamoby@optimus.ietf.org; Tue, 07 Oct 2003 12:25: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 MAA10602 for ; Tue, 7 Oct 2003 12:25:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ueW-0000R6-00 for seamoby@ietf.org; Tue, 07 Oct 2003 12:25:36 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A6ueV-0000R1-00 for seamoby@ietf.org; Tue, 07 Oct 2003 12:25:35 -0400 Message-ID: <018501c38cef$acd8d630$956015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 7 Oct 2003 09:25:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD Review from Henrik Petander 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 Below is a Last Call review from Henrik Petander. Vijay has requested more time for his review. jak ---------------------------------------------------------------- 1. Protocol issues ================== The handling of sequence numbers in MN and RA for resending is not defined. Should MN increase the sequence number on resend? Should AR identify a CARD request similar to an old one, except for the sequence number, as a resend and set a new timer for AR-AR resending? How does AR identify a "new" request from MN from resends of an old one? The timeout values in MN -AR resending and AR-AR resending make AR-AR resending overlap: If a message is lost between AR and CAR, both MN and AR will resend it at the same time. Based on the discussion about AR-AR resending, I understood that its purpose was to decrease the amount of over-the-air messages, if a message is lost in the fixed network. Now this does not happen. To fix this, change the values for resending, so that MN_AR_CARD_TIMEOUT > AR_AR_CARD_TIMEOUT * MN_AR_CARD_RETRIES. This should IMO be done by decreasing the AR_AR timeout and amount of retries to avoid problems with MN noticing messages lost between MN and AR slowly. Should the sequence number be stored in CAR table to enforce ordering of CARD replies ? Now unsolicited CARD replies are to be authenticated with signatures, which MN can verify with the public key of the AR, that MN has learned from somewhere. This is very vague. The description of CARD should be sufficient for two implementations to be interoperable. IMO you should either remove the whole unsolicited CARD reply functionality, or clarify the use of signatures so that it will actually work between two independent implementations. L2 id suboption should have address length field which MUST be used at least with with L2 type = 0x00. 2. Editorial issues =================== 4. ...CARD Reply contains one or more L2 ids and IP addresses" Isn't this contradictory with the use of context id of L2 IDs from CARD Request in CARD reply to avoid including L2 ids? Change this to "may contain". 5.1.1 The text in 5.1.1 on including suboptions in CARD MN-AR request is confusing to me. Which suboptions must be present in all messages? Isn't it valid to send just a MN-AR CARD request to get all CARs and their capabilities from AR? 5.1.2 Should maybe have a note that flag combination A= 0 with C=0 is invalid. 6.3 Second paragraph is repeated from 4.6. Shouldn't this section analyze the security, whereas section 4.6 should describe the implementation of the security mechanisms. 6.4 CARD Reply DoS: Is this really a relevant threat, since CAR is authenticated with IPSec ESP? It seems to require compromise of CAR, so IMO this is out of scope. 7. Protocol constants What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 7 13: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 NAA12402 for ; Tue, 7 Oct 2003 13: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 1A6vVJ-0004RQ-Gp for seamoby-archive@odin.ietf.org; Tue, 07 Oct 2003 13:20:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97HK9iu017066 for seamoby-archive@odin.ietf.org; Tue, 7 Oct 2003 13:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vVJ-0004RB-4g for seamoby-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12380 for ; Tue, 7 Oct 2003 13:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vVH-00011c-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 13:20:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6vVG-00011Z-00 for seamoby-web-archive@ietf.org; Tue, 07 Oct 2003 13:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vVE-0004QE-I2; Tue, 07 Oct 2003 13: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 1A6vUb-0004PG-E5 for seamoby@optimus.ietf.org; Tue, 07 Oct 2003 13:19:25 -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 NAA12339 for ; Tue, 7 Oct 2003 13:19:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vUZ-000110-00 for seamoby@ietf.org; Tue, 07 Oct 2003 13:19:23 -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 1A6vUY-00010x-00 for seamoby@ietf.org; Tue, 07 Oct 2003 13:19:23 -0400 Message-ID: <01ef01c38cf7$314dd120$956015ac@dclkempt40> From: "James Kempf" To: Cc: Date: Tue, 7 Oct 2003 10:19:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Working Group Last Call on draft-ietf-seamoby-ctp-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Working Group Last Call on the CTP draft (draft-ietf-seamoby-ctp-04.txt) starts today and runs until Oct. 21. The document is currently being processed by the IETF drafts editor, but I've posted a copy here: http://www.geocities.com/kempf42/draft-ietf-seamoby-ctp-04.txt so we can get started reviewing it. Please carefully review the draft and post comments to the mailing list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 8 10:49:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18712 for ; Wed, 8 Oct 2003 10:49:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fcg-0001zf-VN for seamoby-archive@odin.ietf.org; Wed, 08 Oct 2003 10:49:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98En6dA007659 for seamoby-archive@odin.ietf.org; Wed, 8 Oct 2003 10:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fcg-0001zS-S3 for seamoby-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 10:49: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 KAA18683 for ; Wed, 8 Oct 2003 10:48:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Fce-00063t-00 for seamoby-web-archive@ietf.org; Wed, 08 Oct 2003 10:49:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Fce-00063p-00 for seamoby-web-archive@ietf.org; Wed, 08 Oct 2003 10:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fcb-0001yb-OL; Wed, 08 Oct 2003 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FTT-0001QF-NL for seamoby@optimus.ietf.org; Wed, 08 Oct 2003 10:39:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17937; Wed, 8 Oct 2003 10:39:24 -0400 (EDT) Message-Id: <200310081439.KAA17937@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, 08 Oct 2003 10:39:24 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Context Transfer Protocol Author(s) : J. Loughney, et. al. Filename : draft-ietf-seamoby-ctp-04.txt Pages : 23 Date : 2003-10-8 This document presents a context transfer protocol that enables mobile nodes to authorize context transfers between access routers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency, packet losses and avoiding re-initiation of signaling to and from the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ctp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-ctp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-ctp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-8102239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ctp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ctp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-8102239.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 Oct 8 10:57:24 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 KAA19866 for ; Wed, 8 Oct 2003 10:57:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FkN-0002eb-Oq for seamoby-archive@odin.ietf.org; Wed, 08 Oct 2003 10:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ev3ju010194 for seamoby-archive@odin.ietf.org; Wed, 8 Oct 2003 10:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FkN-0002eL-KW for seamoby-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 10:57: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 KAA19816 for ; Wed, 8 Oct 2003 10:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7FkK-0006L4-00 for seamoby-web-archive@ietf.org; Wed, 08 Oct 2003 10:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7FkK-0006L0-00 for seamoby-web-archive@ietf.org; Wed, 08 Oct 2003 10:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FkL-0002bo-26; Wed, 08 Oct 2003 10: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 1A7FjZ-0002Wk-Kp for seamoby@optimus.ietf.org; Wed, 08 Oct 2003 10:56: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 KAA19687 for ; Wed, 8 Oct 2003 10:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7FjW-0006Ir-00 for seamoby@ietf.org; Wed, 08 Oct 2003 10:56:10 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1A7FjW-0006Gx-00 for seamoby@ietf.org; Wed, 08 Oct 2003 10:56:10 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 31DB833D3C; Wed, 8 Oct 2003 16:55:39 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id E7B303F412; Wed, 8 Oct 2003 17:15:56 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003100816553807947 ; Wed, 08 Oct 2003 16:55:38 +0200 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 6281B3F416; Wed, 8 Oct 2003 17:15:56 +0200 (CEST) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1A7Fib-000I0P-A8; Wed, 08 Oct 2003 16:55:13 +0200 Date: Wed, 8 Oct 2003 16:55:13 +0200 From: Julien Bournelle To: James Kempf Cc: seamoby@ietf.org, mankin@psg.com Subject: Re: [Seamoby] Working Group Last Call on draft-ietf-seamoby-ctp-04.txt Message-ID: <20031008145513.GC54713@ipv6-5.int-evry.fr> References: <01ef01c38cf7$314dd120$956015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <01ef01c38cf7$314dd120$956015ac@dclkempt40> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA19688 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, =20 after a quick review, these are my questions/comments concerning ctp-04.. 1. p4. 3 =A7 We call such an event as a Context Transfer Trigger -> We call such en event a Context Transfer Trigger 2. In the second scenario, nAR may itself generates a Context Transfer Request as a response to an internal trigger.=20 The problem is that nAR "must" supply, the MN's previous IP address, the feature contexts to be transferred and a token authorizing the transfer. So, I guess that either we offer a way to the nAR to retrieve this info from MN or the nAR can't generate a Context Transfer as a response to an internal trigger. Do I miss something ? 3. At the last paragraph p5. we have "[1].* contexts ...the [2]algorithm[3]" 4. In =A7 2.3 Context Data Block, it is written: "The Cxt-Type indicates the type of the feature context messages itself (such as QoS Context Request, Qos Context Transfer etc,).." can't it be deduce from CTAR/CTD/CTR ? 5. In =A7 2.4.1 Context Transfer Activate Request=20 While a MN sends a CTAR to pAR, the MN includes the nAR's address and its new IP address (if known). If these addresses are not known, what does MN include ? (his previous IP address or 0.0.0.0/0::0 ?) 6. I can't find "Context Transfer Framework for Seamless Mobility" :-( Hope it helps :-) --=20 julien.bournelle@int-evry.fr _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 9 20:39:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19077 for ; Thu, 9 Oct 2003 20:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lJC-0004Is-Oa for seamoby-archive@odin.ietf.org; Thu, 09 Oct 2003 20:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A0d6ex016536 for seamoby-archive@odin.ietf.org; Thu, 9 Oct 2003 20:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lJC-0004Id-JL for seamoby-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 20:39: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 UAA19071 for ; Thu, 9 Oct 2003 20:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7lJA-0006w3-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 20:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7lJ9-0006vz-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 20:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lJ6-0004Ht-Vj; Thu, 09 Oct 2003 20:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7lIV-0004G8-Em for seamoby@optimus.ietf.org; Thu, 09 Oct 2003 20:38:23 -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 UAA19043 for ; Thu, 9 Oct 2003 20:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7lIO-0006vJ-00 for seamoby@ietf.org; Thu, 09 Oct 2003 20:38:16 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7lIN-0006tk-00 for seamoby@ietf.org; Thu, 09 Oct 2003 20:38:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9A0bXS08446; Thu, 9 Oct 2003 17:37:33 -0700 X-mProtect: <200310100037> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd75zjhR; Thu, 09 Oct 2003 17:37:32 PDT Message-ID: <3F85FF9C.30505@iprg.nokia.com> Date: Thu, 09 Oct 2003 17:38:52 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lpetande@morphine.tml.hut.fi CC: seamoby@ietf.org Subject: Re: [Seamoby] CARD Review from Henrik Petander References: <018501c38cef$acd8d630$956015ac@dclkempt40> In-Reply-To: <018501c38cef$acd8d630$956015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Henrik, >What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? > they are used in rate-limiting MN requests 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. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 9 22: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 WAA20792 for ; Thu, 9 Oct 2003 22: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 1A7mab-0000LG-KF for seamoby-archive@odin.ietf.org; Thu, 09 Oct 2003 22:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A219xm001308 for seamoby-archive@odin.ietf.org; Thu, 9 Oct 2003 22:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mab-0000L1-GW for seamoby-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 22:01:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20771 for ; Thu, 9 Oct 2003 22:01:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7maY-0007dz-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7maX-0007dw-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7maU-0000JM-Li; Thu, 09 Oct 2003 22: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 1A7mZV-0000F1-6G for seamoby@optimus.ietf.org; Thu, 09 Oct 2003 22:00: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 VAA20729 for ; Thu, 9 Oct 2003 21:59:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mZS-0007d8-00 for seamoby@ietf.org; Thu, 09 Oct 2003 21:59:58 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7mZR-0007cO-00 for seamoby@ietf.org; Thu, 09 Oct 2003 21:59:57 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9A1x9E27121; Thu, 9 Oct 2003 18:59:09 -0700 X-mProtect: <200310100159> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVyaT9f; Thu, 09 Oct 2003 18:59:07 PDT Message-ID: <3F8612BC.7090709@iprg.nokia.com> Date: Thu, 09 Oct 2003 19:00:28 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander CC: lpetande@tml.hut.fi, seamoby@ietf.org Subject: Re: [Seamoby] CARD Review from Henrik Petander References: <018501c38cef$acd8d630$956015ac@dclkempt40> <3F85FF9C.30505@iprg.nokia.com> In-Reply-To: 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 you are right. the names for the protocol constants are confusing. basically we need to do the following 1. We need to rate-limit requests from the MN. 2. specify retransmission behavior for the MN. 3. specify retransmission behavior for the Current AR. 4. specify sending behavior for unsolicited CARD replies for (1), we need a protocol constant to say that the MN is not allowed to send more than a certain number of requests per second. if it sends more than that, the current AR just drops the requests. There shouldnt be an upper limit on the number of requests. for (2), we need protocol constants. one to say when to retransmit and one to say when to give up. for (3), same as (2). (2) and (3) could share the same protocol constants. (4) is already clearly defined. Vijay Henrik Petander wrote: >Hi Vijay and all, > >Vijay, thanks for the clarification. CARD_MAX_RETRIES is 3 and >MN_AR_CARD_RETRIES is 5, so MN can try to resend the same query for 5 >times, but can make new queries (for different L2 addresses) only 3 times. >Did I understand this correctly? > >If yes, then this scheme is a little confusing to me and raises some >questions: Why is the interval called CARD_RETRANSMISSION_INTERVAL, if it >concerns new requests, which are not resends? > >Why is there a fixed ceiling on how many new CARD requests MN can send ? >Shouldn't there at least be a wait period after which MN can set the >counter to zero? > >Thanks, > >Henrik > >On Thu, 9 Oct 2003, Vijay Devarapalli wrote: > > > >>hi Henrik, >> >> >> >>>What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? >>> >>> >>> >>they are used in rate-limiting MN requests >> >> 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. >> >>Vijay >> >> >> >> >> >> _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 9 22:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21721 for ; Thu, 9 Oct 2003 22:26: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 1A7myl-0001wx-DP for seamoby-archive@odin.ietf.org; Thu, 09 Oct 2003 22:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A2Q7MJ007489 for seamoby-archive@odin.ietf.org; Thu, 9 Oct 2003 22:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7myl-0001wi-A2 for seamoby-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 22:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21713 for ; Thu, 9 Oct 2003 22:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7myh-0000Bm-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7myh-0000Bj-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7myf-0001vh-Rt; Thu, 09 Oct 2003 22:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7my8-0001uy-IO for seamoby@optimus.ietf.org; Thu, 09 Oct 2003 22:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21680 for ; Thu, 9 Oct 2003 22:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7my5-0000As-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:25:25 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7my4-0000AQ-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:25:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9A2OsA10366; Thu, 9 Oct 2003 19:24:54 -0700 X-mProtect: <200310100224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXMqXV0; Thu, 09 Oct 2003 19:24:52 PDT Message-ID: <3F8618C5.8030408@iprg.nokia.com> Date: Thu, 09 Oct 2003 19:26:13 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org CC: kempf@docomolabs-usa.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD review - Minor issues Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, version 04 is a much improved draft. thanks. here are some minor issues that I could spot. > If a MN can listen to L2 IDs of new APs prior to making decision > about IP-level handover to CARs, a mechanism is needed for reverse > address translation. This function of the CARD protocol enables the > MN to map the received L2 ID of an AP to the IP address of the > associated CAR that connects to the AP. To get the CAR's IP address, > the MN sends the L2 ID of the AP to the current AR and the current > AR provides the associated CAR's IP address to the MN. > > In cases where the MN can acquire IP connectivity with CARs prior to > making handover decisions, this functionality is trivially realized, > since the MN can request CARs individually for discovery of > capabilities. > > doesnt the second paragraph belong to section 3.2? in section 4.2.1, delete >For example, > using the Preferences message parameter, a MN may indicate that it > is only interested in these CAR(s) supporting a specific air > interface technology. Similarly, using the Requirements message > parameter, a MN can indicate the list of capability attributes and > associated capabilities' values to its current AR. The Requirements > message parameter may be used to indicate the cut off values of the > capabilities for the desired CAR(s). > the above is a repeat. it is previously described in detail in section 4. section 4.3.1 >the MN's current AR > SHALL extract the capability information from the payload of the > received message and buffer the received capabilities in its local > CAR table. > s/buffer/store/ section 4.3.2 >AR-AR CARD Request. The CAR SHALL buffer the received capabilities > same as above section 4.4.1 >A MN SHALL detect the loss of a > MN-AR CARD Request or MN-AR CARD Reply Message using a timeout > mechanism (MN_AR_CARD_TIMEOUT). The MN SHALL start a timer > (MN_AR_CARD_TIMER) after sending a MN-AR CARD Request message with > the given sequence number. The MN SHALL stop the timer as soon as > the reply to the MN-AR CARD Request is received by it. Upon > expiration of the MN_AR_CARD_TIMER, the MN SHALL declare the > outstanding message as lost, resends the same message and restart > > the MN_AR_CARD_TIMER. > replace the above by A MN SHOULD retransmit the CARD Request, if it does not receive a CARD Reply within MR_AR_CARD_TIMEOUT seconds. section 4.4.2 >The MN's current AR MAY detect the loss of an AR-AR CARD > Request or an AR-AR CARD Reply message using a timeout mechanism > (AR_AR_CARD_TIMEOUT). The current AR MAY start a timer > (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the > given sequence number. The current AR should then stop the timer as > soon as the reply to the AR-AR CARD Request is received by it. Upon > expiration of the AR_AR_CARD_TIMER, the MN's current AR declares the > outstanding AR-AR CARD Request as lost and then resends the same > message to the CAR. > replace the above by The MN's current AR SHOULD retransmit the CARD Request, if it does not receive a CARD Reply within AR_AR_CARD_TIMEOUT seconds. section 4.5 > To allow MNs and ARs appending the ICMP-option type CARD Request and > CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6 > signaling messages > I think this is the first time Fast MIPv6 appears. a reference to the FMIPv6 draft will be useful. section 4.6 > The MN-AR and AR-AR messages' authenticity MUST be ensured using > IPsec ESP [10]. It is safe to assume that there will be an > s/it is safe to assume/The CARD protocol assumes/ > appropriate SA between a MN and its connected AR, which MAY be used > s/appropriate SA/IPsec Security Association/ > The proposed mechanism for authenticating unsolicited and multicast > MN-AR CARD Reply messages at MNs is the use of digital signatures. > This assumes that the MN has discovered the respective AR's public > key before the received unsolicited CARD Reply messages can be > validated. > this is too vague. why not just say This document does not specify a mechanism for securing unsolicted multicast MN-AR CARD Reply messages. section 5.1.1, delete the following. it is already said in a couple of places in the draft. > Encapsulating Security Payload (ESP) Header: > IPSec ESP MUST be used with a non-null > integrity protection and origin authentication > algorithm and SHOULD be used with a non-null > encryption algorithm for protecting the > confidentiality of the CARD information. > section 5.1.3.1 > L2 type: Indicates the interface type (optional). > > If the L2 type indicator is not used, this field MUST > be set to 0x00. > > The following types are initially defined: > > Technology | L2 type > --------------+--------- > IEEE802.11 | T.B.A. > CDMA2000 | T.B.A. > WCDMA | T.B.A. > I think IANA does not have assign the L2 type. it can be done in this draft itself. I know I was the one who raised this issue earlier. but now I realise IANA's role is not needed for the L2 type. my mistake. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 9 22:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21940 for ; Thu, 9 Oct 2003 22:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7n7R-0002Or-DP for seamoby-archive@odin.ietf.org; Thu, 09 Oct 2003 22:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A2Z5YY009219 for seamoby-archive@odin.ietf.org; Thu, 9 Oct 2003 22:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7n7R-0002Oc-7X for seamoby-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 22:35: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 WAA21937 for ; Thu, 9 Oct 2003 22:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7n7N-0000HS-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:35:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7n7N-0000HP-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7n7N-0002Nk-PW; Thu, 09 Oct 2003 22:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7n6U-0002NJ-JJ for seamoby@optimus.ietf.org; Thu, 09 Oct 2003 22:34: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 WAA21911 for ; Thu, 9 Oct 2003 22:33:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7n6R-0000GX-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:34:03 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7n6Q-0000GD-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:34:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9A2XVI15885; Thu, 9 Oct 2003 19:33:31 -0700 X-mProtect: <200310100233> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6PA9Mm; Thu, 09 Oct 2003 19:33:30 PDT Message-ID: <3F861AC9.1020507@iprg.nokia.com> Date: Thu, 09 Oct 2003 19:34:49 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org CC: kempf@docomolabs-usa.com Subject: Re: [Seamoby] CARD review - Minor issues References: <3F8618C5.8030408@iprg.nokia.com> In-Reply-To: <3F8618C5.8030408@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 missed this in the earlier mail. in section 8, delete > This document authorizes IANA to assign the new ICMP type to the > CARD protocol main header and to the CARD Request and CARD Reply > option, as well as to assign the UDP port number for inter-AR > protocol operation and an IPv6 link-local and IPv4 well known > multicast address for unsolicited CARD Reply message multicast. This > document also authorizes IANA to assign fixed L2 Type values for the > wireless technologies IEEE802.11, CDMA 2000 and WCDMA. Note that it > is not possible to identify all possible access technologies where > CARD can be applicable, so we have chosen three access technologies > to begin with. > it is a repeat of the earlier paragraph in the same section. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 9 22:57: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 WAA22351 for ; Thu, 9 Oct 2003 22:57: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 1A7nSo-0003PT-HC for seamoby-archive@odin.ietf.org; Thu, 09 Oct 2003 22:57:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A2vAJS013104 for seamoby-archive@odin.ietf.org; Thu, 9 Oct 2003 22:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7nSo-0003PH-Ao for seamoby-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 22:57: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 WAA22348 for ; Thu, 9 Oct 2003 22:57:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7nSk-0000Q3-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:57:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7nSk-0000Q0-00 for seamoby-web-archive@ietf.org; Thu, 09 Oct 2003 22:57:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7nSg-0003Oa-2f; Thu, 09 Oct 2003 22:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7nS8-0003L2-Km for seamoby@optimus.ietf.org; Thu, 09 Oct 2003 22:56:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22321 for ; Thu, 9 Oct 2003 22:56:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7nS4-0000Pi-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:56:24 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7nS4-0000Op-00 for seamoby@ietf.org; Thu, 09 Oct 2003 22:56:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9A2tkB27652; Thu, 9 Oct 2003 19:55:46 -0700 X-mProtect: <200310100255> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUWol2Q; Thu, 09 Oct 2003 19:55:45 PDT Message-ID: <3F862001.1010705@iprg.nokia.com> Date: Thu, 09 Oct 2003 19:57:05 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Liebsch CC: Seamoby Subject: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) References: <3F69DFCF.5050709@ccrle.nec.de> In-Reply-To: <3F69DFCF.5050709@ccrle.nec.de> 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 hi Marco, Marco Liebsch wrote: > > Issue#17: Preferences/Requirements sub-option - One > of them is sufficient? > --------------------------------------------------- > Proposal is to keep both, since this implies just the definition of a > further sub-option type, which indicates > that only Attributes without any Data field will follow > in case of receiving a Preferences sub-option. > The Requirements parameter sub-option will carry then a > list of Attribute-Value pairs, the Preferences parameter > carries a list of Attributes (just the AVP Code and > Length, no Lifetime, no Data). one has to still implement both, right? I still think one of them is enough. I suggest removing the Requirements Sub-Option. it causes more harm than benefit. here is one example. lets assume none of the CARs were able to meet the MN's requirements. the CARD Reply returns empty. because of the MN's strict requirements, it loses connectivity. isnt that worse than picking a CAR with less capabilities? a local decision at the MN is better than the MN not getting any CARs. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 09:49: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 JAA27975 for ; Fri, 10 Oct 2003 09:49: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 1A7xdj-0003tl-07 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 09:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ADn6Dg014981 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 09:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xdi-0003tY-T0 for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 09:49: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 JAA27951 for ; Fri, 10 Oct 2003 09:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xdg-0003fv-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 09:49:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7xdg-0003fs-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 09:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xdd-0003so-7P; Fri, 10 Oct 2003 09:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xcq-0003sS-EP for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 09:48: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 JAA27942 for ; Fri, 10 Oct 2003 09:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xco-0003fc-00 for seamoby@ietf.org; Fri, 10 Oct 2003 09:48:10 -0400 Received: from [138.15.108.3] (helo=mailer.nec-labs.com) by ietf-mx with esmtp (Exim 4.12) id 1A7xcn-0003fX-00 for seamoby@ietf.org; Fri, 10 Oct 2003 09:48:10 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Oct 2003 09:47:27 -0400 Message-ID: <002401c38f35$b8d6a820$c96b0f8a@peace> From: "Eunsoo Shim" To: "Vijay Devarapalli" , "Marco Liebsch" Cc: "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Fri, 10 Oct 2003 09:51:39 -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: 10 Oct 2003 13:47:27.0569 (UTC) FILETIME=[0AEA9410:01C38F35] 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 > > > > Issue#17: Preferences/Requirements sub-option - One > > of them is sufficient? > > --------------------------------------------------- > > Proposal is to keep both, since this implies just the definition of a > > further sub-option type, which indicates > > that only Attributes without any Data field will follow > > in case of receiving a Preferences sub-option. > > The Requirements parameter sub-option will carry then a > > list of Attribute-Value pairs, the Preferences parameter > > carries a list of Attributes (just the AVP Code and > > Length, no Lifetime, no Data). > > > one has to still implement both, right? > > I still think one of them is enough. I suggest removing the Requirements > Sub-Option. > it causes more harm than benefit. here is one example. > > lets assume none of the CARs were able to meet the MN's requirements. > the CARD > Reply returns empty. because of the MN's strict requirements, it loses > connectivity. > isnt that worse than picking a CAR with less capabilities? a local > decision at the > MN is better than the MN not getting any CARs. > Vijay, The MN does not lose connectivity necessarily in the case you described. It depends on the timing of the CARD Request/Reply in the handoff process. If the requirements are something the MN can have flexibility on such as bandwidth, the MN should send the query much earlier before the MN's old link gets too weak. However, if the requirements are something in which there is no flexibility with the MN such as link type, the empty reply means there is no access network supporting the link type. In the case, losing connectivity may not be unavoidable if the MN keeps moving far from the old access point/base station. Filtering out CARs based on supported link types is an obvious example showing the benefit of the Requirements sub-option. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 11:59: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 LAA04590 for ; Fri, 10 Oct 2003 11:59: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 1A7zfY-0004Gm-C8 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 11:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AFx834016408 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 11:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zfY-0004GZ-7U for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:59: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 LAA04571 for ; Fri, 10 Oct 2003 11:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zfW-0005Su-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 11:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zfW-0005Sr-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 11:59:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zfQ-0004Fn-NN; Fri, 10 Oct 2003 11:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zf6-0004F9-CI for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 11:58:40 -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 LAA04553 for ; Fri, 10 Oct 2003 11:58:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zf4-0005SL-00 for seamoby@ietf.org; Fri, 10 Oct 2003 11:58:39 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7zf3-0005RF-00 for seamoby@ietf.org; Fri, 10 Oct 2003 11:58:38 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AFw5xu073495 for ; Fri, 10 Oct 2003 17:58:06 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AFw3am073494 for ; Fri, 10 Oct 2003 17:58:03 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AFw2xs073492; Fri, 10 Oct 2003 17:58:03 +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 55A5E8FC7B; Fri, 10 Oct 2003 17:25:28 +0200 (CEST) Message-ID: <3F86D709.6070706@ccrle.nec.de> Date: Fri, 10 Oct 2003 17:58:01 +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: Henrik Petander Cc: seamoby@ietf.org Subject: Re: [Seamoby] CARD Review from Henrik Petander References: <018501c38cef$acd8d630$956015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 Henrik, thanks for the review. Maybe better to discuss individual issues in separate mails, which will follow this one. marco James Kempf wrote: >Below is a Last Call review from Henrik Petander. Vijay has requested more >time for his review. > > jak >---------------------------------------------------------------- > >1. Protocol issues >================== > >The handling of sequence numbers in MN and RA for resending is not >defined. Should MN increase the sequence number on resend? Should AR >identify a CARD request similar to an old one, except for the sequence >number, as a resend and set a new timer for AR-AR resending? How does >AR identify a "new" request from MN from resends of an old one? > >The timeout values in MN -AR resending and AR-AR resending make AR-AR >resending overlap: If a message is lost between AR and CAR, both MN and >AR will resend it at the same time. Based on the discussion about AR-AR >resending, I understood that its purpose was to decrease the amount >of over-the-air messages, if a message is lost in the fixed >network. Now this does not happen. > >To fix this, change the values for resending, so that MN_AR_CARD_TIMEOUT > >AR_AR_CARD_TIMEOUT * MN_AR_CARD_RETRIES. This should IMO be done by >decreasing the AR_AR timeout and amount of retries to avoid problems >with MN noticing messages lost between MN and AR slowly. > >Should the sequence number be stored in CAR table to enforce ordering >of CARD replies ? > >Now unsolicited CARD replies are to be authenticated with signatures, >which MN can verify with the public key of the AR, that MN has learned >from somewhere. This is very vague. The description of CARD should be >sufficient for two implementations to be interoperable. IMO you should >either remove the whole unsolicited CARD reply functionality, or clarify >the use of signatures so that it will actually work between two >independent implementations. > >L2 id suboption should have address length field which MUST be >used at least with with L2 type = 0x00. > >2. Editorial issues >=================== > >4. ...CARD Reply contains one or more L2 ids and IP addresses" Isn't > this contradictory with the use of context id of L2 IDs from CARD > Request in CARD reply to avoid including L2 ids? Change this to > "may contain". > >5.1.1 > >The text in 5.1.1 on including suboptions in CARD MN-AR request is >confusing to me. Which suboptions must be present in all messages? Isn't >it valid to send just a MN-AR CARD request to get all CARs and their >capabilities from AR? > >5.1.2 Should maybe have a note that flag combination A= 0 with C=0 is >invalid. > >6.3 Second paragraph is repeated from 4.6. Shouldn't this section >analyze the security, whereas section 4.6 should describe the >implementation of the security mechanisms. > >6.4 CARD Reply DoS: Is this really a relevant threat, since CAR is > authenticated with IPSec ESP? It seems to require compromise of CAR, > so IMO this is out of scope. > >7. Protocol constants > >What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? > > > >_______________________________________________ >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 Oct 10 12:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05129 for ; Fri, 10 Oct 2003 12:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zs5-0005bY-98 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGC530021538 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zs5-0005bJ-5a for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:12: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 MAA05088 for ; Fri, 10 Oct 2003 12:11:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zs3-0005e3-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zs3-0005e0-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zs1-0005aT-UG; Fri, 10 Oct 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zrd-0005ZG-OJ for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 12:11: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 MAA05083 for ; Fri, 10 Oct 2003 12:11:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zrc-0005dr-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:11:36 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A7zrb-0005cs-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:11:35 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AGB3xu074305 for ; Fri, 10 Oct 2003 18:11:04 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AGB2nH074304 for ; Fri, 10 Oct 2003 18:11:02 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AGB1xs074302; Fri, 10 Oct 2003 18:11:02 +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 50E33A2552; Fri, 10 Oct 2003 17:38:27 +0200 (CEST) Message-ID: <3F86DA14.9010202@ccrle.nec.de> Date: Fri, 10 Oct 2003 18:11:00 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: handling of sequence numbers 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 handling of sequence numbers in MN and RA for resending is not defined. Should MN increase the sequence number on resend? Should AR identify a CARD request similar to an old one, except for the sequence number, as a resend and set a new timer for AR-AR resending? How does AR identify a "new" request from MN from resends of an old one?" I agree that we need to be more specific here. In my opinion, the MN should always increase the sequence number also for resent messages. In case of a huge delay, a MN may resend a packet and receive 2 replies. Different sequence numbers allow the MN to associate each of the 2 replies to a request. Otherwise we need to specify how the MN should behave what to do when receiving 2 replies with the same sequence number... To your last point: Is an AR really required to distinguish a "resent" Request from a "new" one? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 12:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05705 for ; Fri, 10 Oct 2003 12:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A803h-0007Dq-Cr for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGO5E4027752 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A803h-0007DW-4I for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:24: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 MAA05691 for ; Fri, 10 Oct 2003 12:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A803f-0005pY-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A803e-0005pV-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A803c-00079g-8p; Fri, 10 Oct 2003 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8030-00077C-79 for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 12:23: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 MAA05684 for ; Fri, 10 Oct 2003 12:23:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A802y-0005pD-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:23:20 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A802x-0005om-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:23:20 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AGMlxu074993 for ; Fri, 10 Oct 2003 18:22:48 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AGMioY074991 for ; Fri, 10 Oct 2003 18:22:44 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AGMhxs074989; Fri, 10 Oct 2003 18:22: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 CDFB7A2552; Fri, 10 Oct 2003 17:50:09 +0200 (CEST) Message-ID: <3F86DCD3.8000202@ccrle.nec.de> Date: Fri, 10 Oct 2003 18:22:43 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: Timeout and retransmission of signaling messages 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 timeout values in MN -AR resending and AR-AR resending make AR-AR resending overlap: If a message is lost between AR and CAR, both MN and AR will resend it at the same time. Based on the discussion about AR-AR resending, I understood that its purpose was to decrease the amount of over-the-air messages, if a message is lost in the fixed network. Now this does not happen. To fix this, change the values for resending, so that MN_AR_CARD_TIMEOUT > AR_AR_CARD_TIMEOUT * MN_AR_CARD_RETRIES. This should IMO be done by decreasing the AR_AR timeout and amount of retries to avoid problems with MN noticing messages lost between MN and AR slowly." Shouln't the algorithm be MN_AR_CARD_TIMEOUT > AR_AR_CARD_TIMEOUT * AR_AR_CARD_RETRIES...? Proposal for costants: MN_AR_CARD_TIMEOUT: keep 1 sec. MN_AR_CARD_RETRIES: keep 5 AR_AR_CARD_TIMEOUT: 300 ms AR_AR_CARD_RETRIES: 2 Any comments? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 12:41:24 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 MAA06557 for ; Fri, 10 Oct 2003 12:41:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80K7-0000AB-Lv for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGf3oE000621 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80K7-00009w-I4 for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:41: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 MAA06491 for ; Fri, 10 Oct 2003 12:40:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80K5-00063t-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A80K5-00063q-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80K5-000091-Cp; Fri, 10 Oct 2003 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80JW-00008A-DX for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 12:40: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 MAA06466 for ; Fri, 10 Oct 2003 12:40:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80JU-00063D-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:40:24 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A80JT-00062p-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:40:24 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AGdqxs075797 for ; Fri, 10 Oct 2003 18:39:53 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AGb1RF075653 for ; Fri, 10 Oct 2003 18:37:01 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AGb1xs075651; Fri, 10 Oct 2003 18:37:01 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C1D05D2A66; Fri, 10 Oct 2003 18:04:26 +0200 (CEST) Message-ID: <3F86E02C.6050208@ccrle.nec.de> Date: Fri, 10 Oct 2003 18:37:00 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: Storing sequence numbers in ARs' CAR table? 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 "...Should the sequence number be stored in CAR table to enforce ordering of CARD replies ?" In my opinion, an AR needs to remember the sequence number of a request only until the associated reply can be sent. What could be the advantage of maintaining the sequence number in an AR's CAR table for a longer time? Info flow is from AR->MN, so it's the MN's responsibility to choose sequence numbers appropriately for correlating replies with requests and possibly to counteract replay attacks. In case there is a positive offset in sequence numbers between two consecutive Requests, this should not matter, or? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 12:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07047 for ; Fri, 10 Oct 2003 12:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80Wi-00013G-PB for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGs47e003982 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80Wi-000129-E6 for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:54: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 MAA07024 for ; Fri, 10 Oct 2003 12:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80Wg-0006B0-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A80Wg-0006Ax-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80Wf-000115-TV; Fri, 10 Oct 2003 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80WS-0000wY-0Y for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 12:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07000 for ; Fri, 10 Oct 2003 12:53:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80WQ-0006AH-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:53:46 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A80WP-00069y-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:53:45 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AGrDxu076150 for ; Fri, 10 Oct 2003 18:53:14 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AGmdPO076085 for ; Fri, 10 Oct 2003 18:48:39 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AGmdxs076083; Fri, 10 Oct 2003 18:48:39 +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 569CC86AB7; Fri, 10 Oct 2003 18:16:05 +0200 (CEST) Message-ID: <3F86E2E7.40606@ccrle.nec.de> Date: Fri, 10 Oct 2003 18:48:39 +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: Henrik Petander Cc: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages 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 "...Now unsolicited CARD replies are to be authenticated with signatures, which MN can verify with the public key of the AR, that MN has learned from somewhere. This is very vague. The description of CARD should be sufficient for two implementations to be interoperable. IMO you should either remove the whole unsolicited CARD reply functionality, or clarify the use of signatures so that it will actually work between two independent implementations." To be honest, removing the advertisement of unsolicited CARD Replies is not the solution I would support. The issue of authentication of advertised messages is common to many other protocols. The question is whether or not the CARD protocol spec sould be specific to a solution. If there are more efficient solutions in the future, why not keeping the flexibility to adopt the CARD protocol to that mechanism? But I am also fine with adding some more details here. Any proposals for details on a mechanisms? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 12:59:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07258 for ; Fri, 10 Oct 2003 12:59:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80ba-0001Y1-QJ for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:59:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGx6m2005942 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 12:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80ba-0001Xl-JO for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:59: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 MAA07221 for ; Fri, 10 Oct 2003 12:58:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80bY-0006F5-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:59:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A80bY-0006F2-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 12:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80bW-0001TA-91; Fri, 10 Oct 2003 12:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80bO-0001S9-BO for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 12:58: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 MAA07200 for ; Fri, 10 Oct 2003 12:58:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80bM-0006EO-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:58:52 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A80bL-0006Dt-00 for seamoby@ietf.org; Fri, 10 Oct 2003 12:58:51 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9AGwFxu076402 for ; Fri, 10 Oct 2003 18:58:16 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9AGs8LU076184 for ; Fri, 10 Oct 2003 18:54:08 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9AGs7xs076182; Fri, 10 Oct 2003 18:54:08 +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 62C40CFDA7; Fri, 10 Oct 2003 18:21:33 +0200 (CEST) Message-ID: <3F86E42F.5070903@ccrle.nec.de> Date: Fri, 10 Oct 2003 18:54:07 +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: Henrik Petander Cc: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: Address length in L2-ID parameter 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 "...L2 id suboption should have address length field which MUST be used at least with with L2 type = 0x00." Maybe I misunderstood the issue, but the actual address length can be calculated from the L2-ID sub-option's Length indicator, which is always present, isn't it? address length = Sub-option length - 5 octets marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 14:22: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 OAA10697 for ; Fri, 10 Oct 2003 14:22: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 1A81tv-0007ha-6Q for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 14:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIM7B2029569 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 14:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81tv-0007gq-0U for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:22: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 OAA10680 for ; Fri, 10 Oct 2003 14:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81ts-0007FK-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 14:22:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81tr-0007FH-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 14:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81to-0007fj-SX; Fri, 10 Oct 2003 14:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81t4-0007dQ-NB for seamoby@optimus.ietf.org; Fri, 10 Oct 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 OAA10656 for ; Fri, 10 Oct 2003 14:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81t1-0007Eg-00 for seamoby@ietf.org; Fri, 10 Oct 2003 14:21:12 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A81t1-0007E6-00 for seamoby@ietf.org; Fri, 10 Oct 2003 14:21:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9AIKN427417; Fri, 10 Oct 2003 11:20:23 -0700 X-mProtect: <200310101820> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.12, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbA3LVW; Fri, 10 Oct 2003 11:20:21 PDT Message-ID: <3F86F863.1070608@iprg.nokia.com> Date: Fri, 10 Oct 2003 11:20:19 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eunsoo Shim CC: Marco Liebsch , Seamoby Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> In-Reply-To: <002401c38f35$b8d6a820$c96b0f8a@peace> 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 Eunsoo Shim wrote: > The MN does not lose connectivity necessarily in the case you described. what I meant, if there are no candidate ARs, the MN loses connectivity eventually. > However, if the requirements are something in which there is no flexibility > with the MN such as link type, the empty reply means there is no access > network supporting the link type. In the case, losing connectivity may not > be unavoidable if the MN keeps moving far from the old access point/base > station. let the MN make the decision, if no CARs can satisfy its requirements. and you have the preferences options for the MN to tell the current AR what it wants. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 10 16:10:55 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 QAA19438 for ; Fri, 10 Oct 2003 16:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83aq-0000er-Qg for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 16:10:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKAWWZ002518 for seamoby-archive@odin.ietf.org; Fri, 10 Oct 2003 16:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83aq-0000eH-1s for seamoby-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:10: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 QAA19412 for ; Fri, 10 Oct 2003 16:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83ao-0001dd-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 16:10:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83an-0001da-00 for seamoby-web-archive@ietf.org; Fri, 10 Oct 2003 16:10:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83aM-0000b5-U2; Fri, 10 Oct 2003 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83a7-0000Zz-HT for seamoby@optimus.ietf.org; Fri, 10 Oct 2003 16:09: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 QAA19347 for ; Fri, 10 Oct 2003 16:09:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83a5-0001c0-00 for seamoby@ietf.org; Fri, 10 Oct 2003 16:09:45 -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 1A83a5-0001bs-00 for seamoby@ietf.org; Fri, 10 Oct 2003 16:09:45 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Oct 2003 16:09:37 -0400 Message-ID: <001f01c38f6b$1c969890$c96b0f8a@peace> From: "Eunsoo Shim" To: "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Fri, 10 Oct 2003 16:13:20 -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: 10 Oct 2003 20:09:37.0738 (UTC) FILETIME=[6E5CB2A0:01C38F6A] 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 MN does not lose connectivity necessarily in the case you described. > > what I meant, if there are no candidate ARs, the MN loses connectivity > eventually. > If there is no candidate ARs supporting any link type available for the MN, certainly the MN will lose connectivity. It is the case regardless of CARD Request/Reply or the Requirements sub-option. If the Requirements sub-option is used by the MN, the MN should consider what it will do in the case the Reply is empty. > > However, if the requirements are something in which there is no flexibility > > with the MN such as link type, the empty reply means there is no access > > network supporting the link type. In the case, losing connectivity may not > > be unavoidable if the MN keeps moving far from the old access point/base > > station. > > let the MN make the decision, if no CARs can satisfy its requirements. > and you have the preferences options for the MN to tell the current AR > what it wants. > Sending a Requirements sub-option is upto the MN, that is, the MN's decision. It is not the current AR that decides the target AR even if the Requirements sub-option is used. Certainly the Requirements should be explicit and clear. The need of Requirements sub-option arises because there could be many CARs in the area. In the case, the CARD Reply may contain much information that is not useful for the MN at all. It is waste of bandwidth and resources of the MN. The Preferences sub-option is used to specify what attributes of CARs should be included in the CARD Reply while the Requirements sub-option is used to specify what CARs should be included in the CARD Reply. So the two sub-options have different roles. Please let me stress that sending a Requirements sub-option is OPTIONAL to the MN. The MN does not even have to support it if the developer decides so. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Sun Oct 12 22:42: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 WAA07303 for ; Sun, 12 Oct 2003 22:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8sf9-00088Q-Kx for seamoby-archive@odin.ietf.org; Sun, 12 Oct 2003 22:42:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D2gN2m031264 for seamoby-archive@odin.ietf.org; Sun, 12 Oct 2003 22:42:23 -0400 Received: from [218.58.208.242] (helo=126.com) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8sf5-00086r-Kk for seamoby-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 22:42:21 -0400 From: =?GB2312?B?zajBqtDFz6LW0NDE?= Subject: =?GB2312?B?zajBqtDFz6LW0NDEu7bTrcTj?= To: seamoby-web-archive@optimus.ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: tlxx_668@126.com Date: Mon, 13 Oct 2003 10:44:56 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] Message-Id: 通联信息中心欢迎你 这是一封商务代理广告，也是摆在你面前的一个机遇．我是《农业信息报》社记者，做商务代理已经一个多月了，发现确实可以赚到钱，而且很轻松，一个月2000左右应该是 没问题的．只要你会上网，每天可以抽出一个小时左右作宣传就足够了，不用忙着做决定， 先看看具体信息 成功网：http://www3.cn-soho.com/cgw/?mid=bfgcb 机会不容错过！ EMAIL: 5651518@126.com 为协助各位搞好宣传工作，凡已注册者特优价购买：信息发布专家 60元、商务奇兵60元、名扬四海60元、登陆奇兵60元、快速群邮60元！赠送企业个人邮址两亿个！！非注册者购买以上软件共收600元！特快邮寄。登陆www.tlxx.net 咨询： tixx_668@126.com 《农业信息报》、《农界》杂志正在招聘专刊、专栏主编，详情点：www.tlxx.net 申请域名，自助建站（会打字就会建网站）只收费298元！15158@126.com 通联信息中心 <<---以上邮件内容与中资源网络及软件开发商无关--->> ----------------------------------------------- 中资源网络--域名先注册后付款;主机先开通后收费。 申请100M虚拟主机350元/年，送国际域名+5个信箱 新浪，搜狐，网易排名，百度竟价，超值大赠送。 http://www.800asp.net ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ ★优联网络全球专业的域名主机提供商 http://www.chinasql.com★ ★套餐： 国际域名 + 100M主机 送10个企业邮箱，支持二级域名★ ★每年318元,不满意可退款。 ★ ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 欢迎使用亿虎Email商务系列软件 免费下载地址: http://www.ehoosoft.com 定向客户搜索: 亿虎Email搜索大师 信息特快群发: 亿虎Email邮差 病毒邮件克星: 亿虎Email安全大师 ...... From exim@www1.ietf.org Mon Oct 13 11:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12227 for ; Mon, 13 Oct 2003 11:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A94uX-0008C4-Ep for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 11:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DFl5sZ031492 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 11:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A94uX-0008Bl-0O for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 11:47: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 LAA12195 for ; Mon, 13 Oct 2003 11:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A94uV-0004ba-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 11:47:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A94uV-0004bW-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 11:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A94uS-0008Ay-M2; Mon, 13 Oct 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A94tj-00089t-Gz for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 11:46: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 LAA12149 for ; Mon, 13 Oct 2003 11:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A94ti-0004b3-00 for seamoby@ietf.org; Mon, 13 Oct 2003 11:46:14 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A94th-0004aP-00 for seamoby@ietf.org; Mon, 13 Oct 2003 11:46:14 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9DFjfxu036955 for ; Mon, 13 Oct 2003 17:45:42 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9DFiH9L036838 for ; Mon, 13 Oct 2003 17:44:17 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9DFiDxs036835; Mon, 13 Oct 2003 17:44:17 +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 B1479D5A30; Mon, 13 Oct 2003 17:11:10 +0200 (CEST) Message-ID: <3F8AC84C.2050209@ccrle.nec.de> Date: Mon, 13 Oct 2003 17:44:12 +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@ietf.org, kempf@docomolabs-usa.com Subject: Re: [Seamoby] CARD review - Minor issues References: <3F8618C5.8030408@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: >> L2 type: Indicates the interface type (optional). >> >> If the L2 type indicator is not used, this field MUST >> be set to 0x00. >> >> The following types are initially defined: >> >> Technology | L2 type >> --------------+--------- >> IEEE802.11 | T.B.A. >> CDMA2000 | T.B.A. >> WCDMA | T.B.A. >> > > I think IANA does not have assign the L2 type. it can be done in > this draft itself. I know I was the one who raised this issue > earlier. but now I realise IANA's role is not needed for the L2 > type. my mistake. > > > Vijay > I am not sure about this. If we want type identifiers to be valid beyond the scope of a specific operator's domain or a specific implementation, the control on these numers should be assigned to somebody, ensuring their use in a unique manner. Why do you think this is not necessary, or, more precisely, who, if not IANA, should take over the control function on these identifiers? 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 Oct 13 11:56:24 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 LAA12437 for ; Mon, 13 Oct 2003 11:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A953E-0008Tc-1E for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 11:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DFu3go032578 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 11:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A953D-0008TN-Qm for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 11:56: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 LAA12423 for ; Mon, 13 Oct 2003 11:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A953C-0004gE-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 11:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A953C-0004gB-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 11:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A953C-0008SZ-Cg; Mon, 13 Oct 2003 11:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A952F-0008R9-3t for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 11:55: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 LAA12383 for ; Mon, 13 Oct 2003 11:54:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A952D-0004fc-00 for seamoby@ietf.org; Mon, 13 Oct 2003 11:55:01 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A952C-0004fP-00 for seamoby@ietf.org; Mon, 13 Oct 2003 11:55:01 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9DFsTxs037414 for ; Mon, 13 Oct 2003 17:54:29 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9DFsTrT037412 for ; Mon, 13 Oct 2003 17:54:29 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9DFsSxs037411; Mon, 13 Oct 2003 17:54:29 +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 200FF31F2D; Mon, 13 Oct 2003 17:21:26 +0200 (CEST) Message-ID: <3F8ACAB4.7010400@ccrle.nec.de> Date: Mon, 13 Oct 2003 17:54:28 +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: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: >> >> Issue#17: Preferences/Requirements sub-option - One >> of them is sufficient? >> --------------------------------------------------- >> Proposal is to keep both, since this implies just the definition of a >> further sub-option type, which indicates >> that only Attributes without any Data field will follow >> in case of receiving a Preferences sub-option. >> The Requirements parameter sub-option will carry then a >> list of Attribute-Value pairs, the Preferences parameter >> carries a list of Attributes (just the AVP Code and >> Length, no Lifetime, no Data). > > > > one has to still implement both, right? > > I still think one of them is enough. I suggest removing the > Requirements Sub-Option. > it causes more harm than benefit. here is one example. > > lets assume none of the CARs were able to meet the MN's requirements. > the CARD > Reply returns empty. because of the MN's strict requirements, it loses > connectivity. > isnt that worse than picking a CAR with less capabilities? a local > decision at the > MN is better than the MN not getting any CARs. > > Vijay > > I don't want to provide input for a huge discussion here, but I don't see any reason why not to have 2 separate sub-options for 2 separate functions. If these should be merged, ARs need to check always whether or not AVPs carry a Data field, if not then this is interpreted as a "preference", otherwise as a "requirement" parameters..... However, from implementation point of view, the current one is the simplest case, since the format for both are the same, just use a separate type number for these sub-options, that's it. This makes the meaning of the parameters already clear when processing the header of the sub-option, right? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 13 12:44:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14811 for ; Mon, 13 Oct 2003 12:44:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95nh-0003hl-Dx for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 12:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DGi56D014235 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 12:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95nh-0003hW-Ag for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 12:44: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 MAA14804 for ; Mon, 13 Oct 2003 12:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95nf-0005Jn-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 12:44:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A95nf-0005Jk-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 12:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95nd-0003gj-0Y; Mon, 13 Oct 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95nU-0003gX-4C for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 12:43:52 -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 MAA14794 for ; Mon, 13 Oct 2003 12:43:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95nS-0005JV-00 for seamoby@ietf.org; Mon, 13 Oct 2003 12:43:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A95nR-0005I9-00 for seamoby@ietf.org; Mon, 13 Oct 2003 12:43:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9DGh9R29719; Mon, 13 Oct 2003 09:43:09 -0700 X-mProtect: <200310131643> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0NJBHb; Mon, 13 Oct 2003 09:43:07 PDT Message-ID: <3F8AD67D.1040301@iprg.nokia.com> Date: Mon, 13 Oct 2003 09:44:45 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Liebsch CC: seamoby@ietf.org, kempf@docomolabs-usa.com Subject: Re: [Seamoby] CARD review - Minor issues References: <3F8618C5.8030408@iprg.nokia.com> <3F8AC84C.2050209@ccrle.nec.de> In-Reply-To: <3F8AC84C.2050209@ccrle.nec.de> Content-Type: text/plain; charset=ISO-8859-1; 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 Marco Liebsch wrote: > > > Vijay Devarapalli wrote: > >>> L2 type: Indicates the interface type (optional). >>> >>> If the L2 type indicator is not used, this field MUST >>> be set to 0x00. >>> >>> The following types are initially defined: >>> >>> Technology | L2 type >>> --------------+--------- >>> IEEE802.11 | T.B.A. >>> CDMA2000 | T.B.A. >>> WCDMA | T.B.A. >>> >> >> I think IANA does not have assign the L2 type. it can be done in >> this draft itself. I know I was the one who raised this issue >> earlier. but now I realise IANA's role is not needed for the L2 >> type. my mistake. >> >> >> Vijay >> > I am not sure about this. If we want type identifiers to be valid beyond > the scope of a specific operator's domain or a specific implementation, > the control on these numers should be assigned to somebody, ensuring > their use in a unique manner. > > Why do you think this is not necessary, or, more precisely, who, > if not IANA, should take over the control function on these identifiers? define them in the CARD protocol document itself. anybody who implements CARD will use the same type values from this document. there shouldnt be any interoperability problems. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 13 13:45:40 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 NAA16941 for ; Mon, 13 Oct 2003 13:45:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96ku-0006Lg-8o for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 13:45:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DHjG5B024398 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 13:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96ku-0006LR-2w for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 13:45: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 NAA16927 for ; Mon, 13 Oct 2003 13:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96kr-0005z4-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 13:45:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A96kr-0005z1-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 13:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96kg-0006HA-0q; Mon, 13 Oct 2003 13: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 1A96kA-0006Bs-4B for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 13:44:30 -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 NAA16890 for ; Mon, 13 Oct 2003 13:44:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96k7-0005yP-00 for seamoby@ietf.org; Mon, 13 Oct 2003 13:44:27 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A96k6-0005xy-00 for seamoby@ietf.org; Mon, 13 Oct 2003 13:44:27 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9DHhsxu041205 for ; Mon, 13 Oct 2003 19:43:55 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9DHe0LW041166 for ; Mon, 13 Oct 2003 19:40:00 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9DHdxxs041158; Mon, 13 Oct 2003 19:40:00 +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 62D418DC61; Mon, 13 Oct 2003 19:06:56 +0200 (CEST) Message-ID: <3F8AE36F.90006@ccrle.nec.de> Date: Mon, 13 Oct 2003 19:39:59 +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@ietf.org, kempf@docomolabs-usa.com Subject: Re: [Seamoby] CARD review - Minor issues References: <3F8618C5.8030408@iprg.nokia.com> <3F8AC84C.2050209@ccrle.nec.de> <3F8AD67D.1040301@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: > >> >> >> Vijay Devarapalli wrote: >> >>>> L2 type: Indicates the interface type (optional). >>>> >>>> If the L2 type indicator is not used, this field MUST >>>> be set to 0x00. >>>> >>>> The following types are initially defined: >>>> >>>> Technology | L2 type >>>> --------------+--------- >>>> IEEE802.11 | T.B.A. >>>> CDMA2000 | T.B.A. >>>> WCDMA | T.B.A. >>>> >>> >>> I think IANA does not have assign the L2 type. it can be done in >>> this draft itself. I know I was the one who raised this issue >>> earlier. but now I realise IANA's role is not needed for the L2 >>> type. my mistake. >>> >>> >>> Vijay >>> >> I am not sure about this. If we want type identifiers to be valid beyond >> the scope of a specific operator's domain or a specific implementation, >> the control on these numers should be assigned to somebody, ensuring >> their use in a unique manner. >> >> Why do you think this is not necessary, or, more precisely, who, >> if not IANA, should take over the control function on these identifiers? > > > define them in the CARD protocol document itself. anybody who implements > CARD will use the same type values from this document. there shouldnt be > any interoperability problems. This works for some selected access technologies. What about future ones or some we might forget? Preferably would be to use something existing or at least something that can be re-used by others when specified once. Wouldn't be reasonable if every protocol defines its own types, or? marco > > Vijay > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 13 13:51:24 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 NAA17262 for ; Mon, 13 Oct 2003 13:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qV-0006j5-CM for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 13:51:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DHp3aH025849 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 13:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qV-0006iq-8R for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 13:51: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 NAA17243 for ; Mon, 13 Oct 2003 13:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96qS-00064d-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 13:51:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A96qS-00064a-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 13:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qT-0006ha-DT; Mon, 13 Oct 2003 13: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 1A96pZ-0006fG-DY for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 13:50: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 NAA17184 for ; Mon, 13 Oct 2003 13:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96pX-000647-00 for seamoby@ietf.org; Mon, 13 Oct 2003 13:50:03 -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 1A96pW-00063q-00 for seamoby@ietf.org; Mon, 13 Oct 2003 13:50:02 -0400 Message-ID: <045b01c391b2$7506ec20$956015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , "Eunsoo Shim" Cc: "Marco Liebsch" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 10:50: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 Marco/Eunsoo, Can you explain what the exact semantic difference is between these two options? If it isn't large, then I'd suggest merging them, based on the premise that "simpler is better"? jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Eunsoo Shim" Cc: "Marco Liebsch" ; "Seamoby" Sent: Friday, October 10, 2003 11:20 AM Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) > > > Eunsoo Shim wrote: > > > The MN does not lose connectivity necessarily in the case you described. > > what I meant, if there are no candidate ARs, the MN loses connectivity > eventually. > > > However, if the requirements are something in which there is no flexibility > > with the MN such as link type, the empty reply means there is no access > > network supporting the link type. In the case, losing connectivity may not > > be unavoidable if the MN keeps moving far from the old access point/base > > station. > > let the MN make the decision, if no CARs can satisfy its requirements. > and you have the preferences options for the MN to tell the current AR > what it wants. > > 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 Oct 13 14:07: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 OAA18104 for ; Mon, 13 Oct 2003 14:07: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 1A9767-0007R9-L9 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 14:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DI7BiI028582 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 14:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9766-0007P3-VO for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 14:07: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 OAA18089 for ; Mon, 13 Oct 2003 14:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9763-0006GS-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 14:07:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9762-0006GP-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 14:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A975x-0007M9-Aq; Mon, 13 Oct 2003 14:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A975Y-0007LT-87 for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 14:06: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 OAA18063 for ; Mon, 13 Oct 2003 14:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A975V-0006G3-00 for seamoby@ietf.org; Mon, 13 Oct 2003 14:06:33 -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 1A975V-0006G0-00 for seamoby@ietf.org; Mon, 13 Oct 2003 14:06:33 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 14:06:28 -0400 Message-ID: <013601c391b5$66583230$c96b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 14:10: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: 13 Oct 2003 18:06:28.0466 (UTC) FILETIME=[B9408520:01C391B4] 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 Requirements sub-option is used to filter out the CARs to be included in the Reply. For example, it can say " CARs supporting 802.11b interface". Then the current AR puts CAR information satisfying the conditions (requirements). It is useful since any CAR that does not support the link types available for the MN should not be included in the Reply. Since the current AR does not know what link types are available for each MN, it is the MN that should tell the current AR about them. The Preferences sub-option is used to filter out the attributes to be included in the Reply. For example, it can say "link types, supported IP versions, authentication protocols". Then the current AR puts those attributes among all the capability (attributes) of the CARs. That is, the Reply does not contain "cost = free" of the CARs but it can contain information such as "link type = 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated protocols = RADIUS" for each CAR entry. So the two sub-options are for independent filtering of the CAR information. One cannot replace the other. Also, merging the two sub-options does NOT make anything simpler. Rather, it makes the sub-option more complex to decode. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Vijay Devarapalli" ; "Eunsoo Shim" Cc: "Marco Liebsch" ; "Seamoby" Sent: Monday, October 13, 2003 1:50 PM Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) > Marco/Eunsoo, > > Can you explain what the exact semantic difference is between these two > options? If it isn't large, then I'd suggest merging them, based on the > premise that "simpler is better"? > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Eunsoo Shim" > Cc: "Marco Liebsch" ; "Seamoby" > > Sent: Friday, October 10, 2003 11:20 AM > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > Proposal to resolve remaining CARD issues) > > > > > > > > Eunsoo Shim wrote: > > > > > The MN does not lose connectivity necessarily in the case you described. > > > > what I meant, if there are no candidate ARs, the MN loses connectivity > > eventually. > > > > > However, if the requirements are something in which there is no > flexibility > > > with the MN such as link type, the empty reply means there is no access > > > network supporting the link type. In the case, losing connectivity may > not > > > be unavoidable if the MN keeps moving far from the old access point/base > > > station. > > > > let the MN make the decision, if no CARs can satisfy its requirements. > > and you have the preferences options for the MN to tell the current AR > > what it wants. > > > > 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 Oct 13 15:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23154 for ; Mon, 13 Oct 2003 15:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98at-00044Z-Ou for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJh3lO015649 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98at-00044K-LQ for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 15:43: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 PAA23131 for ; Mon, 13 Oct 2003 15:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98as-0007KX-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A98ar-0007KU-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98aq-00043T-Ul; Mon, 13 Oct 2003 15:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98aU-00042p-Rg for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 15:42:38 -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 PAA23118 for ; Mon, 13 Oct 2003 15:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98aR-0007KC-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:42:35 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A98aQ-0007K9-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:42:35 -0400 Message-ID: <075201c391c2$2e6a57b0$956015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 12:42:48 -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 So why not merge them into a "filter" suboption? And have the filter language reflect the two different uses? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Vijay Devarapalli" Cc: "Marco Liebsch" ; "Seamoby" Sent: Monday, October 13, 2003 11:10 AM Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) > The Requirements sub-option is used to filter out the CARs to be included in > the Reply. > For example, it can say " CARs supporting 802.11b interface". Then the > current AR puts CAR information satisfying the conditions (requirements). It > is useful since any CAR that does not support the link types available for > the MN should not be included in the Reply. Since the current AR does not > know what link types are available for each MN, it is the MN that should > tell the current AR about them. > > The Preferences sub-option is used to filter out the attributes to be > included in the Reply. > For example, it can say "link types, supported IP versions, authentication > protocols". Then the current AR puts those attributes among all the > capability (attributes) of the CARs. That is, the Reply does not contain > "cost = free" of the CARs but it can contain information such as "link type > = 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated > protocols = RADIUS" for each CAR entry. > > So the two sub-options are for independent filtering of the CAR information. > One cannot replace the other. > > Also, merging the two sub-options does NOT make anything simpler. Rather, it > makes the sub-option more complex to decode. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: "Vijay Devarapalli" ; "Eunsoo Shim" > > Cc: "Marco Liebsch" ; "Seamoby" > > Sent: Monday, October 13, 2003 1:50 PM > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > Proposal to resolve remaining CARD issues) > > > > Marco/Eunsoo, > > > > Can you explain what the exact semantic difference is between these two > > options? If it isn't large, then I'd suggest merging them, based on the > > premise that "simpler is better"? > > > > jak > > > > ----- Original Message ----- > > From: "Vijay Devarapalli" > > To: "Eunsoo Shim" > > Cc: "Marco Liebsch" ; "Seamoby" > > > > Sent: Friday, October 10, 2003 11:20 AM > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > Proposal to resolve remaining CARD issues) > > > > > > > > > > > > > Eunsoo Shim wrote: > > > > > > > The MN does not lose connectivity necessarily in the case you > described. > > > > > > what I meant, if there are no candidate ARs, the MN loses connectivity > > > eventually. > > > > > > > However, if the requirements are something in which there is no > > flexibility > > > > with the MN such as link type, the empty reply means there is no > access > > > > network supporting the link type. In the case, losing connectivity may > > not > > > > be unavoidable if the MN keeps moving far from the old access > point/base > > > > station. > > > > > > let the MN make the decision, if no CARs can satisfy its requirements. > > > and you have the preferences options for the MN to tell the current AR > > > what it wants. > > > > > > 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 Oct 13 15:49:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23476 for ; Mon, 13 Oct 2003 15:49:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98gh-0004by-OI for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJn356017720 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98gh-0004bj-L1 for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 15:49: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 PAA23467 for ; Mon, 13 Oct 2003 15:48:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98gg-0007Si-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A98gf-0007Sf-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98gg-0004bM-6Y; Mon, 13 Oct 2003 15:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98gR-0004b1-LA for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 15:48: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 PAA23463 for ; Mon, 13 Oct 2003 15:48:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98gQ-0007Sa-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:48:46 -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 1A98gP-0007SS-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:48:45 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 15:48:44 -0400 Message-ID: <01f601c391c3$af2343c0$c96b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 15:52:45 -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: 13 Oct 2003 19:48:44.0168 (UTC) FILETIME=[026A5880:01C391C3] 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 two sub-options have different formats as well as different semantics. Two separately defined sub-options are simpler in usage and encoding/decoding, I think. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Vijay Devarapalli" Cc: "Marco Liebsch" ; "Seamoby" Sent: Monday, October 13, 2003 3:42 PM Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) > So why not merge them into a "filter" suboption? And have the filter > language reflect the two different uses? > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; "Vijay Devarapalli" > > Cc: "Marco Liebsch" ; "Seamoby" > > Sent: Monday, October 13, 2003 11:10 AM > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > Proposal to resolve remaining CARD issues) > > > > The Requirements sub-option is used to filter out the CARs to be included > in > > the Reply. > > For example, it can say " CARs supporting 802.11b interface". Then the > > current AR puts CAR information satisfying the conditions (requirements). > It > > is useful since any CAR that does not support the link types available for > > the MN should not be included in the Reply. Since the current AR does not > > know what link types are available for each MN, it is the MN that should > > tell the current AR about them. > > > > The Preferences sub-option is used to filter out the attributes to be > > included in the Reply. > > For example, it can say "link types, supported IP versions, authentication > > protocols". Then the current AR puts those attributes among all the > > capability (attributes) of the CARs. That is, the Reply does not contain > > "cost = free" of the CARs but it can contain information such as "link > type > > = 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated > > protocols = RADIUS" for each CAR entry. > > > > So the two sub-options are for independent filtering of the CAR > information. > > One cannot replace the other. > > > > Also, merging the two sub-options does NOT make anything simpler. Rather, > it > > makes the sub-option more complex to decode. > > > > Eunsoo > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Vijay Devarapalli" ; "Eunsoo Shim" > > > > Cc: "Marco Liebsch" ; "Seamoby" > > > > Sent: Monday, October 13, 2003 1:50 PM > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > Proposal to resolve remaining CARD issues) > > > > > > > Marco/Eunsoo, > > > > > > Can you explain what the exact semantic difference is between these two > > > options? If it isn't large, then I'd suggest merging them, based on the > > > premise that "simpler is better"? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Vijay Devarapalli" > > > To: "Eunsoo Shim" > > > Cc: "Marco Liebsch" ; "Seamoby" > > > > > > Sent: Friday, October 10, 2003 11:20 AM > > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > > Proposal to resolve remaining CARD issues) > > > > > > > > > > > > > > > > > > Eunsoo Shim wrote: > > > > > > > > > The MN does not lose connectivity necessarily in the case you > > described. > > > > > > > > what I meant, if there are no candidate ARs, the MN loses connectivity > > > > eventually. > > > > > > > > > However, if the requirements are something in which there is no > > > flexibility > > > > > with the MN such as link type, the empty reply means there is no > > access > > > > > network supporting the link type. In the case, losing connectivity > may > > > not > > > > > be unavoidable if the MN keeps moving far from the old access > > point/base > > > > > station. > > > > > > > > let the MN make the decision, if no CARs can satisfy its requirements. > > > > and you have the preferences options for the MN to tell the current AR > > > > what it wants. > > > > > > > > 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 Oct 13 15:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23752 for ; Mon, 13 Oct 2003 15:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98lY-0004sJ-1P for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJs3sD018733 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 15:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98lX-0004s4-TE for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 15:54: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 PAA23721 for ; Mon, 13 Oct 2003 15:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98lW-0007Wk-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A98lV-0007Wh-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 15:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98lV-0004rK-3b; Mon, 13 Oct 2003 15:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98lI-0004r1-F6 for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 15:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23717 for ; Mon, 13 Oct 2003 15:53:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98lG-0007Wa-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:53:46 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A98lF-0007WX-00 for seamoby@ietf.org; Mon, 13 Oct 2003 15:53:46 -0400 Message-ID: <07b601c391c3$bee27bf0$956015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" , "Kempf" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> <01f601c391c3$af2343c0$c96b0f8a@peace> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 12:54: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 Eunsoo, I do not have a lot of time to discuss this, so this will be my last email on the topic. > The two sub-options have different formats as well as different semantics. > Two separately defined sub-options are simpler in usage and > encoding/decoding, I think. > Can you explain how having two sets of parsing code is simpler than having one? jak > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; "Vijay Devarapalli" > > Cc: "Marco Liebsch" ; "Seamoby" > > Sent: Monday, October 13, 2003 3:42 PM > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > Proposal to resolve remaining CARD issues) > > > > So why not merge them into a "filter" suboption? And have the filter > > language reflect the two different uses? > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; "Vijay Devarapalli" > > > > Cc: "Marco Liebsch" ; "Seamoby" > > > > Sent: Monday, October 13, 2003 11:10 AM > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > Proposal to resolve remaining CARD issues) > > > > > > > The Requirements sub-option is used to filter out the CARs to be > included > > in > > > the Reply. > > > For example, it can say " CARs supporting 802.11b interface". Then the > > > current AR puts CAR information satisfying the conditions > (requirements). > > It > > > is useful since any CAR that does not support the link types available > for > > > the MN should not be included in the Reply. Since the current AR does > not > > > know what link types are available for each MN, it is the MN that should > > > tell the current AR about them. > > > > > > The Preferences sub-option is used to filter out the attributes to be > > > included in the Reply. > > > For example, it can say "link types, supported IP versions, > authentication > > > protocols". Then the current AR puts those attributes among all the > > > capability (attributes) of the CARs. That is, the Reply does not contain > > > "cost = free" of the CARs but it can contain information such as "link > > type > > > = 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated > > > protocols = RADIUS" for each CAR entry. > > > > > > So the two sub-options are for independent filtering of the CAR > > information. > > > One cannot replace the other. > > > > > > Also, merging the two sub-options does NOT make anything simpler. > Rather, > > it > > > makes the sub-option more complex to decode. > > > > > > Eunsoo > > > > > > ----- Original Message ----- > > > From: "James Kempf" > > > To: "Vijay Devarapalli" ; "Eunsoo Shim" > > > > > > Cc: "Marco Liebsch" ; "Seamoby" > > > > > > Sent: Monday, October 13, 2003 1:50 PM > > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > > Proposal to resolve remaining CARD issues) > > > > > > > > > > Marco/Eunsoo, > > > > > > > > Can you explain what the exact semantic difference is between these > two > > > > options? If it isn't large, then I'd suggest merging them, based on > the > > > > premise that "simpler is better"? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Vijay Devarapalli" > > > > To: "Eunsoo Shim" > > > > Cc: "Marco Liebsch" ; "Seamoby" > > > > > > > > Sent: Friday, October 10, 2003 11:20 AM > > > > Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] > > > > Proposal to resolve remaining CARD issues) > > > > > > > > > > > > > > > > > > > > > > > Eunsoo Shim wrote: > > > > > > > > > > > The MN does not lose connectivity necessarily in the case you > > > described. > > > > > > > > > > what I meant, if there are no candidate ARs, the MN loses > connectivity > > > > > eventually. > > > > > > > > > > > However, if the requirements are something in which there is no > > > > flexibility > > > > > > with the MN such as link type, the empty reply means there is no > > > access > > > > > > network supporting the link type. In the case, losing connectivity > > may > > > > not > > > > > > be unavoidable if the MN keeps moving far from the old access > > > point/base > > > > > > station. > > > > > > > > > > let the MN make the decision, if no CARs can satisfy its > requirements. > > > > > and you have the preferences options for the MN to tell the current > AR > > > > > what it wants. > > > > > > > > > > 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 Oct 13 16:22: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 QAA26187 for ; Mon, 13 Oct 2003 16:22: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 1A99Ck-0006u0-41 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 16:22:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DKMAhC026529 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 16:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Cj-0006to-Sn for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 16:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26142 for ; Mon, 13 Oct 2003 16:22:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99Ch-0000Hu-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 16:22:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A99Ch-0000Hr-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 16:22:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Ca-0006sk-IH; Mon, 13 Oct 2003 16:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99Bv-0006rj-1C for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 16:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26084 for ; Mon, 13 Oct 2003 16:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99Bt-0000GY-00 for seamoby@ietf.org; Mon, 13 Oct 2003 16:21:17 -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 1A99Bs-0000GV-00 for seamoby@ietf.org; Mon, 13 Oct 2003 16:21:16 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 16:21:16 -0400 Message-ID: <023901c391c8$3ab84f30$c96b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Vijay Devarapalli" Cc: "Marco Liebsch" , "Seamoby" , "Kempf" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> <01f601c391c3$af2343c0$c96b0f8a@peace> <07b601c391c3$bee27bf0$956015ac@dclkempt40> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Mon, 13 Oct 2003 16:25:42 -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: 13 Oct 2003 20:21:16.0665 (UTC) FILETIME=[8E31BE90:01C391C7] 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 two sub-options have different formats as well as different semantics. > > Two separately defined sub-options are simpler in usage and > > encoding/decoding, I think. > > > > Can you explain how having two sets of parsing code is simpler than having > one? > The Requirements sub-option should contain a list of AVP while the Preferences sub-option should contain only a list of attribute IDs. That is, they have different formats. By knowing the type of sub-option from the sub-option header, the receiver knows what format to be expected. Also by putting all the Requirements separately from the Preferences, the receiver can get the Requirements at once without having to figure out whether each filter is for Requirements or Preferences. An alternative suggested in the mailing list to merge the two sub-options was putting a empty value for the AVP to indicate the AVP was for Preferences. To do this, each AVP for Preferences should have the length field as well which indicates always zero. It is waste of bandwidth. Reading the length field is waste of the receiver resources (time and power). In the end, the receiver should logically separate Requirements from Preferences from the merged filter. So from the viewpoint of implementers, merging the two sub-options into a single sub-option requires another step to separte them in the receiver side. Logically the two filters are separte to the sender as well as the receiver. Having them separated physically is clearer for both of the sender and the receiver. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 13 22:44:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10507 for ; Mon, 13 Oct 2003 22:44:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FAM-000712-9x for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 22:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E2i6EB026962 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 22:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FAM-00070n-5U for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 22:44: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 WAA10485 for ; Mon, 13 Oct 2003 22:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9FAI-0004qW-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 22:44:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9FAI-0004qT-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 22:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FAH-0006zq-Eb; Mon, 13 Oct 2003 22:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FA5-0006z9-Vr for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 22:43: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 WAA10458 for ; Mon, 13 Oct 2003 22:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9FA2-0004pj-00 for seamoby@ietf.org; Mon, 13 Oct 2003 22:43:46 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1A9FA1-0004pc-00 for seamoby@ietf.org; Mon, 13 Oct 2003 22:43:45 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 66F7C8001F3; Tue, 14 Oct 2003 05:43:40 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E2heGn003608; Tue, 14 Oct 2003 05:43:40 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E2hdJs003604; Tue, 14 Oct 2003 05:43:39 +0300 Date: Tue, 14 Oct 2003 05:43:39 +0300 (EEST) From: Henrik Petander To: Marco Liebsch Cc: Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers In-Reply-To: <3F86DA14.9010202@ccrle.nec.de> Message-ID: References: <3F86DA14.9010202@ccrle.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Marco, On Fri, 10 Oct 2003, Marco Liebsch wrote: > To your last point: Is an AR really required to distinguish a > "resent" Request from a "new" one? Yes, if AR-AR resending is implemented, since AR will set a new AR-AR resend timer when it receives a "new" request from MN. It should not do the same for resends from MN for which it already has a timer. If MN increases the sequence number for each resend, then AR needs to be able to differentiate the new and resent messages by other fields. I don't think this is a problem, though, since AR can just compare the L2-ids of the messages. Henrik > > 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 Oct 13 23:19: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 XAA11366 for ; Mon, 13 Oct 2003 23:19: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 1A9FiH-00008R-Nn for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 23:19:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E3J9Hn000517 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 23:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FiH-00008E-4S for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 23:19:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11353 for ; Mon, 13 Oct 2003 23:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9FiE-00058r-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 23:19:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9FiE-00058o-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 23: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 1A9Fi9-00007S-Qj; Mon, 13 Oct 2003 23: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 1A9FhW-00006s-Al for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 23:18: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 XAA11348 for ; Mon, 13 Oct 2003 23:18:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9FhT-00058h-00 for seamoby@ietf.org; Mon, 13 Oct 2003 23:18:20 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1A9FhT-00058e-00 for seamoby@ietf.org; Mon, 13 Oct 2003 23:18:19 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 0FFAA8002FE; Tue, 14 Oct 2003 06:18:20 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E3IJGn003677; Tue, 14 Oct 2003 06:18:19 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E3IJ8i003673; Tue, 14 Oct 2003 06:18:19 +0300 Date: Tue, 14 Oct 2003 06:18:19 +0300 (EEST) From: Henrik Petander To: Marco Liebsch Cc: Seamoby In-Reply-To: <3F86E02C.6050208@ccrle.nec.de> Message-ID: References: <3F86E02C.6050208@ccrle.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? 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 Marco, On Fri, 10 Oct 2003, Marco Liebsch wrote: > "...Should the sequence number be stored in CAR table to enforce ordering > of CARD replies ?" > > In my opinion, an AR needs to remember the sequence number > of a request only until the associated reply can be sent. > What could be the advantage of maintaining the sequence > number in an AR's CAR table for a longer time? Info flow > is from AR->MN, so it's the MN's responsibility to choose > sequence numbers appropriately for correlating replies > with requests and possibly to counteract replay attacks. > In case there is a positive offset in sequence numbers between > two consecutive Requests, this should not matter, or? AR also receives piggybacked and other unsolicited AR-AR replies from other ARs. For these to have ordering, AR should IMO store the sequence number from the AR-AR CARD message header it receives. Then the sequence number in CARD request and reply could be used just for matching the messages. There is a similar problem is in the MN-AR protocol, with the ordering of solicited and unsolicited replies. A new field in the MN-AR CARD message header is _probably_ needed for sequence number, if strict ordering is a requirement. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 13 23:55:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12160 for ; Mon, 13 Oct 2003 23:55:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GH4-0001m8-2j for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 23:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E3t68v006824 for seamoby-archive@odin.ietf.org; Mon, 13 Oct 2003 23:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GH3-0001lz-QS for seamoby-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 23:55: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 XAA12122 for ; Mon, 13 Oct 2003 23:54:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9GH1-0005QX-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 23:55:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9GH0-0005QU-00 for seamoby-web-archive@ietf.org; Mon, 13 Oct 2003 23:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GGz-0001lD-CY; Mon, 13 Oct 2003 23:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GGf-0001km-NV for seamoby@optimus.ietf.org; Mon, 13 Oct 2003 23:54:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12115 for ; Mon, 13 Oct 2003 23:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9GGd-0005QH-00 for seamoby@ietf.org; Mon, 13 Oct 2003 23:54:39 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1A9GGc-0005Q2-00 for seamoby@ietf.org; Mon, 13 Oct 2003 23:54:39 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 1664F800300; Tue, 14 Oct 2003 06:53:35 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E3rYGn003980; Tue, 14 Oct 2003 06:53:34 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9E3rYiI003976; Tue, 14 Oct 2003 06:53:34 +0300 Date: Tue, 14 Oct 2003 06:53:34 +0300 (EEST) From: Henrik Petander To: Marco Liebsch Cc: Henrik Petander , Seamoby Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages In-Reply-To: <3F86E2E7.40606@ccrle.nec.de> Message-ID: References: <3F86E2E7.40606@ccrle.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Fri, 10 Oct 2003, Marco Liebsch wrote: > > The issue of authentication of advertised messages is common to many > other protocols. The question is whether or not the CARD protocol spec > sould be specific to a solution. If there are more efficient solutions > in the future, why not keeping the flexibility to adopt the CARD > protocol to that mechanism? IMO, if you have a mechanism such as the unsolicited multicast replies, which cannot be secured with standard security protocols, then the security mechanism should be specified in the protocol spec for interoperability. If interoperability is not needed, then it can be left open. Vijay's suggestion, to just say that the mechanism is not defined here, might be an easy way to handle this issue and maybe sufficient for an experimental RFC. > But I am also fine with adding some more details here. Any > proposals for details on a mechanisms? You could look at how TLS does this and use some PKCS standard with RSA. This would still leave open how MN learns the public key of AR. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 14 07:44: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 HAA04687 for ; Tue, 14 Oct 2003 07:44: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 1A9Naw-0007zh-29 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 07:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EBi61a030723 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 07:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nav-0007zS-UK for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 07:44: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 HAA04663 for ; Tue, 14 Oct 2003 07:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Nav-0001Cj-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 07:44:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Nau-0001Cg-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 07:44:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nas-0007xm-CW; Tue, 14 Oct 2003 07:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Na7-0007wG-5e for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 07:43: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 HAA04649 for ; Tue, 14 Oct 2003 07:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Na6-0001BU-00 for seamoby@ietf.org; Tue, 14 Oct 2003 07:43:14 -0400 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1A9Na5-0001B6-00 for seamoby@ietf.org; Tue, 14 Oct 2003 07:43:13 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp6.clb.oleane.net with SMTP id h9EBgg6f024167 for ; Tue, 14 Oct 2003 13:42:42 +0200 Message-ID: <020501c39248$9f868640$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Tue, 14 Oct 2003 13:45:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0202_01C39259.62D55A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Seamoby] The 2004 WiFi Voice Conference 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0202_01C39259.62D55A80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Today, the voice over WLAN market is an extremely small and immature = market but in the longer term, all users of WLAN networks could = eventually find a business case within the context of interoperability = between WLANs and 2.5G and 3G networks.=20 The 2004 WiFi Voice Conference will be held in Paris on May 25 to 28, = 2004.=20 A call for papers has been launched on-line, effective until November = 15, 2003.=20 More details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm ------=_NextPart_000_0202_01C39259.62D55A80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Today, the voice over WLAN market is an extremely = small and=20 immature market but in the longer term, all users of WLAN networks could = eventually find a business case within the context of interoperability = between=20 WLANs and 2.5G and 3G networks.
The 2004 WiFi Voice = Conference=20 will be held in Paris on May 25 to 28, = 2004.=20

A call for papers has been launched on-line, effective until = November 15, 2003.
More details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
------=_NextPart_000_0202_01C39259.62D55A80-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 14 09:07: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 JAA07710 for ; Tue, 14 Oct 2003 09:07: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 1A9OtG-0004QM-RR for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 09:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ED76gp016997 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 09:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OtF-0004Pz-Qd for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 09:07: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 JAA07665 for ; Tue, 14 Oct 2003 09:06:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9OtE-0002CG-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 09:07:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9OtD-0002CD-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 09:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OtB-0004NC-BZ; Tue, 14 Oct 2003 09:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OsQ-0004Ju-PV for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 09:06: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 JAA07631 for ; Tue, 14 Oct 2003 09:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9OsP-0002BA-00 for seamoby@ietf.org; Tue, 14 Oct 2003 09:06:13 -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 1A9OsO-0002B7-00 for seamoby@ietf.org; Tue, 14 Oct 2003 09:06:12 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Oct 2003 09:06:11 -0400 Message-ID: <002501c39254$9e4a6650$c96b0f8a@peace> From: "Eunsoo Shim" To: "Henrik Petander" , "Marco Liebsch" Cc: "Henrik Petander" , "Seamoby" References: <3F86E2E7.40606@ccrle.nec.de> Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages Date: Tue, 14 Oct 2003 09:10:48 -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: 14 Oct 2003 13:06:11.0358 (UTC) FILETIME=[F0A1C3E0:01C39253] 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 issue of authentication of advertised messages is common to many > > other protocols. The question is whether or not the CARD protocol spec > > sould be specific to a solution. If there are more efficient solutions > > in the future, why not keeping the flexibility to adopt the CARD > > protocol to that mechanism? > > IMO, if you have a mechanism such as the unsolicited multicast replies, > which cannot be secured with standard security protocols, then the > security mechanism should be specified in the protocol spec for > interoperability. If interoperability is not needed, then it can be left > open. > > Vijay's suggestion, to just say that the mechanism is not defined here, > might be an easy way to handle this issue and maybe sufficient for an > experimental RFC. > > > But I am also fine with adding some more details here. Any > > proposals for details on a mechanisms? > > You could look at how TLS does this and use some PKCS standard with RSA. > This would still leave open how MN learns the public key of AR. > Henrik, There are some examples of unsecured broadcast/multicast messages such as Router Advertisement (Mobile IP). A typical solution to secure such messages is using public key to authenticate the messages but it could be a quite heavy computation for the MN. Also it requires a key distribution system behind it as you pointed out above. I am quite reluctant to put all these issues into the CARD protocol specification at this stage. If any good solution to secure such broadcast/multicast messages comes up, we could revise the specification later to incorporate it. So I'd support Vijay's suggestion that the current specification simply points out the security issue and the security mechanism is not defined. The statements can be inserted into the "security considerations" section. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 14 10:11: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 KAA10971 for ; Tue, 14 Oct 2003 10:11: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 1A9PtG-0000De-90 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 10:11:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EEBAMS000838 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 10:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PtG-0000DQ-2F for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 10:11: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 KAA10896 for ; Tue, 14 Oct 2003 10:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9PtD-00034N-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 10:11:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9PtD-00034K-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 10:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Pt7-0000CH-Ng; Tue, 14 Oct 2003 10:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PsR-0000Al-Vl for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 10:10: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 KAA10809 for ; Tue, 14 Oct 2003 10:10:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9PsD-00033m-00 for seamoby@ietf.org; Tue, 14 Oct 2003 10:10:05 -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 1A9PsD-00033j-00 for seamoby@ietf.org; Tue, 14 Oct 2003 10:10:05 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Oct 2003 10:10:04 -0400 Message-ID: <00d101c3925d$8a4c83f0$c96b0f8a@peace> From: "Eunsoo Shim" To: "Henrik Petander" , "Marco Liebsch" Cc: "Seamoby" References: <3F86E02C.6050208@ccrle.nec.de> Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? Date: Tue, 14 Oct 2003 10:14:54 -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: 14 Oct 2003 14:10:04.0260 (UTC) FILETIME=[DD383240:01C3925C] 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 Henrik and Marco, My comments are inline. > > > "...Should the sequence number be stored in CAR table to enforce ordering > > of CARD replies ?" > > > > In my opinion, an AR needs to remember the sequence number > > of a request only until the associated reply can be sent. > > What could be the advantage of maintaining the sequence > > number in an AR's CAR table for a longer time? Info flow > > is from AR->MN, so it's the MN's responsibility to choose > > sequence numbers appropriately for correlating replies > > with requests and possibly to counteract replay attacks. > > In case there is a positive offset in sequence numbers between > > two consecutive Requests, this should not matter, or? > [eunsoo] I agree with Marco that any gap between sequence numbers of two consecutive Requests is not a problem. The CARD protocol does not have to guarantee the order of the received Requests. > AR also receives piggybacked and other unsolicited AR-AR replies from > other ARs. For these to have ordering, AR should IMO store the sequence > number from the AR-AR CARD message header it receives. [eunsoo] Right. MN or AR should remember the sequence number of the latest unsolicited message from any (other) AR so that it can figure out the newer information. Then the sequence > number in CARD request and reply could be used just for matching the > messages. > [eunsoo] Right. I think we all agree to this. > There is a similar problem is in the MN-AR protocol, with the ordering of > solicited and unsolicited replies. A new field in the MN-AR CARD message > header is _probably_ needed for sequence number, if strict ordering is a > requirement. > [eunsoo] There is already the sequence number field in the headers of CARD Request and Reply. Do you suggest any other field? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 14 12:16: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 MAA17685 for ; Tue, 14 Oct 2003 12:16: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 1A9RqB-00009P-Nj for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 12:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGG7we000575 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 12:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RqB-00009C-KV for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 12:16: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 MAA17680 for ; Tue, 14 Oct 2003 12:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RqA-0004uf-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 12:16:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Rq9-0004ub-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 12:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Rq5-00006X-IM; Tue, 14 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RpV-0008WK-PN for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 12:15:25 -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 MAA17666 for ; Tue, 14 Oct 2003 12:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RpU-0004uP-00 for seamoby@ietf.org; Tue, 14 Oct 2003 12:15:24 -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 1A9RpT-0004uL-00 for seamoby@ietf.org; Tue, 14 Oct 2003 12:15:23 -0400 Message-ID: <014701c3926e$67d2c530$956015ac@dclkempt40> From: "James Kempf" To: "Eunsoo Shim" , "Henrik Petander" , "Marco Liebsch" Cc: "Henrik Petander" , "Seamoby" References: <3F86E2E7.40606@ccrle.nec.de> <002501c39254$9e4a6650$c96b0f8a@peace> Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages Date: Tue, 14 Oct 2003 09:15:38 -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, The example you give (Router Advertisements) is the subject of the Securing Neighbor Discovery Working Group (SEND) for IPv6. The SEND specification defines an authentication option for RAs. The protocol depends on certificate distribution between router and host and defines a certification distribution message for the local link (specifically for that, it likely won't work well in multilink situations due to fragmentation). A similar solution, or possibly even SEND itself for IPv6, could be used by CARD. That said, I agree with Henrik's point that it can be left open, but it should be explicitly listed as an open issue in the Security Considerations section. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Henrik Petander" ; "Marco Liebsch" Cc: "Henrik Petander" ; "Seamoby" Sent: Tuesday, October 14, 2003 6:10 AM Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages > > > > > > The issue of authentication of advertised messages is common to many > > > other protocols. The question is whether or not the CARD protocol spec > > > sould be specific to a solution. If there are more efficient solutions > > > in the future, why not keeping the flexibility to adopt the CARD > > > protocol to that mechanism? > > > > IMO, if you have a mechanism such as the unsolicited multicast replies, > > which cannot be secured with standard security protocols, then the > > security mechanism should be specified in the protocol spec for > > interoperability. If interoperability is not needed, then it can be left > > open. > > > > Vijay's suggestion, to just say that the mechanism is not defined here, > > might be an easy way to handle this issue and maybe sufficient for an > > experimental RFC. > > > > > But I am also fine with adding some more details here. Any > > > proposals for details on a mechanisms? > > > > You could look at how TLS does this and use some PKCS standard with RSA. > > This would still leave open how MN learns the public key of AR. > > > > > Henrik, > > There are some examples of unsecured broadcast/multicast messages such as > Router Advertisement (Mobile IP). A typical solution to secure such messages > is using public key to authenticate the messages but it could be a quite > heavy computation for the MN. Also it requires a key distribution system > behind it as you pointed out above. I am quite reluctant to put all these > issues into the CARD protocol specification at this stage. If any good > solution to secure such broadcast/multicast messages comes up, we could > revise the specification later to incorporate it. > > So I'd support Vijay's suggestion that the current specification simply > points out the security issue and the security mechanism is not defined. The > statements can be inserted into the "security considerations" section. > > Eunsoo > > > > _______________________________________________ > 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 Oct 14 12:33:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18298 for ; Tue, 14 Oct 2003 12:33:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S6b-0000sC-Bj for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 12:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGX5ZO003350 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 12:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S6a-0000rx-UU for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 12:33: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 MAA18274 for ; Tue, 14 Oct 2003 12:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9S6Z-00054Z-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 12:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9S6Y-00054W-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 12:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S6X-0000qu-T6; Tue, 14 Oct 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9S6P-0000qJ-5O for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 12:32:53 -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 MAA18267 for ; Tue, 14 Oct 2003 12:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9S6N-00054I-00 for seamoby@ietf.org; Tue, 14 Oct 2003 12:32:51 -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 1A9S6N-00054F-00 for seamoby@ietf.org; Tue, 14 Oct 2003 12:32:51 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Oct 2003 12:32:50 -0400 Message-ID: <006a01c39271$7af4f720$c96b0f8a@peace> From: "Eunsoo Shim" To: "James Kempf" , "Henrik Petander" , "Marco Liebsch" Cc: "Henrik Petander" , "Seamoby" References: <3F86E2E7.40606@ccrle.nec.de> <002501c39254$9e4a6650$c96b0f8a@peace> <014701c3926e$67d2c530$956015ac@dclkempt40> Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages Date: Tue, 14 Oct 2003 12:37:38 -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: 14 Oct 2003 16:32:50.0400 (UTC) FILETIME=[CF096E00:01C39270] 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 example you give (Router Advertisements) is the subject of the Securing > Neighbor Discovery Working Group (SEND) for IPv6. The SEND specification > defines an authentication option for RAs. The protocol depends on > certificate distribution between router and host and defines a certification > distribution message for the local link (specifically for that, it likely > won't work well in multilink situations due to fragmentation). A similar > solution, or possibly even SEND itself for IPv6, could be used by CARD. > > That said, I agree with Henrik's point that it can be left open, but it > should be explicitly listed as an open issue in the Security Considerations > section. > > jak James, It is fine with me to leave it as an open issue in the Security Considerations section. It is what I said anyway in my previous email. So I guess Henrik, Vijay, you and I are all in the same page. I remember it was also an option positively considered among the authors of the draft. Eunsoo > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "Henrik Petander" ; "Marco Liebsch" > > Cc: "Henrik Petander" ; "Seamoby" > > Sent: Tuesday, October 14, 2003 6:10 AM > Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply > messages > > > > > > > > > > The issue of authentication of advertised messages is common to many > > > > other protocols. The question is whether or not the CARD protocol spec > > > > sould be specific to a solution. If there are more efficient solutions > > > > in the future, why not keeping the flexibility to adopt the CARD > > > > protocol to that mechanism? > > > > > > IMO, if you have a mechanism such as the unsolicited multicast replies, > > > which cannot be secured with standard security protocols, then the > > > security mechanism should be specified in the protocol spec for > > > interoperability. If interoperability is not needed, then it can be left > > > open. > > > > > > Vijay's suggestion, to just say that the mechanism is not defined here, > > > might be an easy way to handle this issue and maybe sufficient for an > > > experimental RFC. > > > > > > > But I am also fine with adding some more details here. Any > > > > proposals for details on a mechanisms? > > > > > > You could look at how TLS does this and use some PKCS standard with RSA. > > > This would still leave open how MN learns the public key of AR. > > > > > > > > > Henrik, > > > > There are some examples of unsecured broadcast/multicast messages such as > > Router Advertisement (Mobile IP). A typical solution to secure such > messages > > is using public key to authenticate the messages but it could be a quite > > heavy computation for the MN. Also it requires a key distribution system > > behind it as you pointed out above. I am quite reluctant to put all these > > issues into the CARD protocol specification at this stage. If any good > > solution to secure such broadcast/multicast messages comes up, we could > > revise the specification later to incorporate it. > > > > So I'd support Vijay's suggestion that the current specification simply > > points out the security issue and the security mechanism is not defined. > The > > statements can be inserted into the "security considerations" section. > > > > Eunsoo > > > > > > > > _______________________________________________ > > 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 Oct 14 13:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19813 for ; Tue, 14 Oct 2003 13:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SpA-0003Nk-1U for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 13:19:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EHJ8F5012998 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 13:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sp9-0003NZ-OY for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 13: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 NAA19803 for ; Tue, 14 Oct 2003 13:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Sp7-0005Tm-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 13:19:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Sp7-0005Tj-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 13:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sp3-0003Ms-6P; Tue, 14 Oct 2003 13: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 1A9SoJ-0003M6-TB for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 13:18: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 NAA19779 for ; Tue, 14 Oct 2003 13:18:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9SoH-0005Te-00 for seamoby@ietf.org; Tue, 14 Oct 2003 13:18:13 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A9SoG-0005Tb-00 for seamoby@ietf.org; Tue, 14 Oct 2003 13:18:13 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9EHHW02089534 for ; Tue, 14 Oct 2003 19:17:37 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9EHFRCO089489 for ; Tue, 14 Oct 2003 19:15:27 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9EHFPxs089484; Tue, 14 Oct 2003 19:15:27 +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 B3D6311EAD; Tue, 14 Oct 2003 18:42:11 +0200 (CEST) Message-ID: <3F8C2F2C.5050309@ccrle.nec.de> Date: Tue, 14 Oct 2003 19:15:24 +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: Eunsoo Shim Cc: James Kempf , Henrik Petander , Henrik Petander , Seamoby Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages References: <3F86E2E7.40606@ccrle.nec.de> <002501c39254$9e4a6650$c96b0f8a@peace> <014701c3926e$67d2c530$956015ac@dclkempt40> <006a01c39271$7af4f720$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 Sounds good. Any objections to consider this issue as closed? If not, related text will be modified in an updated version of the document and an explicit statement on this issue will be part of the security consideration section. marco Eunsoo Shim wrote: >>The example you give (Router Advertisements) is the subject of the >> >> >Securing > > >>Neighbor Discovery Working Group (SEND) for IPv6. The SEND specification >>defines an authentication option for RAs. The protocol depends on >>certificate distribution between router and host and defines a >> >> >certification > > >>distribution message for the local link (specifically for that, it likely >>won't work well in multilink situations due to fragmentation). A similar >>solution, or possibly even SEND itself for IPv6, could be used by CARD. >> >>That said, I agree with Henrik's point that it can be left open, but it >>should be explicitly listed as an open issue in the Security >> >> >Considerations > > >>section. >> >> jak >> >> > >James, > >It is fine with me to leave it as an open issue in the Security >Considerations section. It is what I said anyway in my previous email. >So I guess Henrik, Vijay, you and I are all in the same page. I remember it >was also an option positively considered among the authors of the draft. > >Eunsoo > > > >>----- Original Message ----- >>From: "Eunsoo Shim" >>To: "Henrik Petander" ; "Marco Liebsch" >> >>Cc: "Henrik Petander" ; "Seamoby" >> >>Sent: Tuesday, October 14, 2003 6:10 AM >>Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply >>messages >> >> >> >> >>>>>The issue of authentication of advertised messages is common to many >>>>>other protocols. The question is whether or not the CARD protocol >>>>> >>>>> >spec > > >>>>>sould be specific to a solution. If there are more efficient >>>>> >>>>> >solutions > > >>>>>in the future, why not keeping the flexibility to adopt the CARD >>>>>protocol to that mechanism? >>>>> >>>>> >>>>IMO, if you have a mechanism such as the unsolicited multicast >>>> >>>> >replies, > > >>>>which cannot be secured with standard security protocols, then the >>>>security mechanism should be specified in the protocol spec for >>>>interoperability. If interoperability is not needed, then it can be >>>> >>>> >left > > >>>>open. >>>> >>>>Vijay's suggestion, to just say that the mechanism is not defined >>>> >>>> >here, > > >>>>might be an easy way to handle this issue and maybe sufficient for an >>>>experimental RFC. >>>> >>>> >>>> >>>>>But I am also fine with adding some more details here. Any >>>>>proposals for details on a mechanisms? >>>>> >>>>> >>>>You could look at how TLS does this and use some PKCS standard with >>>> >>>> >RSA. > > >>>>This would still leave open how MN learns the public key of AR. >>>> >>>> >>>> >>>Henrik, >>> >>>There are some examples of unsecured broadcast/multicast messages such >>> >>> >as > > >>>Router Advertisement (Mobile IP). A typical solution to secure such >>> >>> >>messages >> >> >>>is using public key to authenticate the messages but it could be a quite >>>heavy computation for the MN. Also it requires a key distribution system >>>behind it as you pointed out above. I am quite reluctant to put all >>> >>> >these > > >>>issues into the CARD protocol specification at this stage. If any good >>>solution to secure such broadcast/multicast messages comes up, we could >>>revise the specification later to incorporate it. >>> >>>So I'd support Vijay's suggestion that the current specification simply >>>points out the security issue and the security mechanism is not defined. >>> >>> >>The >> >> >>>statements can be inserted into the "security considerations" section. >>> >>>Eunsoo >>> >>> >>> >>>_______________________________________________ >>>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 Oct 14 22:02: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 WAA13566 for ; Tue, 14 Oct 2003 22:02: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 1A9azL-00034T-DF for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 22:02:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F22Biv011806 for seamoby-archive@odin.ietf.org; Tue, 14 Oct 2003 22:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9azL-00034L-8e for seamoby-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 22:02: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 WAA13547 for ; Tue, 14 Oct 2003 22:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9azI-00050L-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 22:02:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9azH-00050I-00 for seamoby-web-archive@ietf.org; Tue, 14 Oct 2003 22:02:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9azD-00033d-0b; Tue, 14 Oct 2003 22:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9az4-00033C-87 for seamoby@optimus.ietf.org; Tue, 14 Oct 2003 22:01: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 WAA13530 for ; Tue, 14 Oct 2003 22:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9az1-0004zy-00 for seamoby@ietf.org; Tue, 14 Oct 2003 22:01:51 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1A9az0-0004zv-00 for seamoby@ietf.org; Tue, 14 Oct 2003 22:01:50 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id CBF878001C3; Wed, 15 Oct 2003 05:01:49 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9F21nGn007571; Wed, 15 Oct 2003 05:01:49 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9F21m99007567; Wed, 15 Oct 2003 05:01:49 +0300 Date: Wed, 15 Oct 2003 05:01:48 +0300 (EEST) From: Henrik Petander To: Eunsoo Shim Cc: Marco Liebsch , Seamoby Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? In-Reply-To: <00d101c3925d$8a4c83f0$c96b0f8a@peace> Message-ID: References: <3F86E02C.6050208@ccrle.nec.de> <00d101c3925d$8a4c83f0$c96b0f8a@peace> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Tue, 14 Oct 2003, Eunsoo Shim wrote: > Henrik and Marco, > > My comments are inline. > > > There is a similar problem is in the MN-AR protocol, with the ordering of > > solicited and unsolicited replies. A new field in the MN-AR CARD message > > header is _probably_ needed for sequence number, if strict ordering is a > > requirement. > > > [eunsoo] There is already the sequence number field in the headers of CARD > Request and Reply. Do you suggest any other field? Actually the problem in MN was more complex than I had thought: MN can get unsolicited CARD replies from multiple ARs and the information in ARs about CARs is not synchronized. It seems that a per-CAR sequence number / timestamp is needed in AR-MN reply for ordering to work. A potential solution is to include the original sequence number from the AR-AR CARD reply message header (not reply option) in some field for each CAR, e.g. in the capability container suboption, in the MN-AR CARD reply. Provided that the CAR increases the sequence number for every AR-AR CARD message it sends, this should work. The sequence number handling might need to work with wrap around, though. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 15 11:20:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04268 for ; Wed, 15 Oct 2003 11:20:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nRd-0004Tz-7Z for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:20:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFKCTo017223 for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nRa-0004Ti-Tw for seamoby-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:20: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 LAA04261 for ; Wed, 15 Oct 2003 11:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nRZ-0005mm-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:20:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nRZ-0005mj-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nRU-0004Sy-0l; Wed, 15 Oct 2003 11: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 1A9nRO-0004SA-4K for seamoby@optimus.ietf.org; Wed, 15 Oct 2003 11:19:59 -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 LAA04246 for ; Wed, 15 Oct 2003 11:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nRN-0005mQ-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:19: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 1A9nRM-0005mH-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:19:56 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Oct 2003 11:19:48 -0400 Message-ID: <00c801c39330$7365cab0$c96b0f8a@peace> From: "Eunsoo Shim" To: "Henrik Petander" Cc: "Marco Liebsch" , "Seamoby" References: <3F86E02C.6050208@ccrle.nec.de> <00d101c3925d$8a4c83f0$c96b0f8a@peace> Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? Date: Wed, 15 Oct 2003 11:24:39 -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 Oct 2003 15:19:48.0116 (UTC) FILETIME=[C567B540:01C3932F] 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 Henrik, My comments are inline. > > > There is a similar problem is in the MN-AR protocol, with the ordering of > > > solicited and unsolicited replies. A new field in the MN-AR CARD message > > > header is _probably_ needed for sequence number, if strict ordering is a > > > requirement. > > > > > [eunsoo] There is already the sequence number field in the headers of CARD > > Request and Reply. Do you suggest any other field? > > Actually the problem in MN was more complex than I had thought: MN can get > unsolicited CARD replies from multiple ARs and the information in ARs > about CARs is not synchronized. In most cases, a MN will have a single current AR and therefore it will receive CAR info only from the current AR. But in multi-homing cases, a MN can have multiple "current ARs", in which case, your point is right. > It seems that a per-CAR sequence number / > timestamp is needed in AR-MN reply for ordering to work. > This problem occurs because there can be multiple information distribution channels and scenarios. For example, one attribute value can be updated between two ARs using Request/Reply while another attribute value can be updated via the Unsolicited Reply.To enforce strictive synchornization or ordering of information, we would need timestamp for each attribute including the IP address and MAC address. This seems creating lots overhead. > A potential solution is to include the original sequence number from the > AR-AR CARD reply message header (not reply option) in some field for each > CAR, e.g. in the capability container suboption, in the MN-AR CARD reply. > Provided that the CAR increases the sequence number for every AR-AR CARD > message it sends, this should work. The sequence number handling might > need to work with wrap around, though. > As mentioned in the above. just copying the original sequence number may not work because the original sequence numbers for Solicited Reply and Unsolicited Reply would be relevant. Again, every Reply should have a timestamp(or sequence number) of the (Reply) sender and it should be copied for each attribute value separately for strict ordering. I'd like to suggest a very simple approach instead of the strict information synchronization or ordering. How about letting the MN use the following simple policy? 1) First, it takes Unsolicited Reply only from the default router (one of the multiple current ARs in the case of multihoming). 2) Second, it gives higher priority on the more recent information if it is from the same sender (not the original source) --- In this case, the order is determined by the sequence number for Unsolicited Replies. If the MN receives Unsolicited Reply and Solicited Reply from the default router, it takes more recently received information. 3) Third, if the MN sent inquiry (Request) to multiple ARs, it takes the most recently received information (Reply). Certainly this approach opens a (little) chance that the MN may NOT get the most up-to-date information. However, since we don't make sure the ARs synchronize their information in hard real-time, such a chance exists anyway. So inserting timestamp for every attribute value may not be justified by the gain compared to its cost. What do you think? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 15 11:27:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04516 for ; Wed, 15 Oct 2003 11:27:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nYH-00051O-Fx for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFR5o9019296 for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nYH-000519-C4 for seamoby-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:27: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 LAA04502 for ; Wed, 15 Oct 2003 11:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nYG-0005rx-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nYF-0005ru-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nYF-0004y1-63; Wed, 15 Oct 2003 11: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 1A9nY4-0004x3-9C for seamoby@optimus.ietf.org; Wed, 15 Oct 2003 11:26:52 -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 LAA04492 for ; Wed, 15 Oct 2003 11:26:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nY3-0005ri-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:26:51 -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 1A9nY2-0005rf-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:26:50 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Oct 2003 11:26:50 -0400 Message-ID: <00e201c39331$6f08e3c0$c96b0f8a@peace> From: "Eunsoo Shim" To: "Eunsoo Shim" , "Henrik Petander" Cc: "Marco Liebsch" , "Seamoby" References: <3F86E02C.6050208@ccrle.nec.de> <00d101c3925d$8a4c83f0$c96b0f8a@peace> <00c801c39330$7365cab0$c96b0f8a@peace> Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? Date: Wed, 15 Oct 2003 11:31:42 -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 Oct 2003 15:26:50.0318 (UTC) FILETIME=[C10E9EE0:01C39330] 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 Please let me fix one typo. > As mentioned in the above. just copying the original sequence number may not > work because the original sequence numbers for Solicited Reply and > Unsolicited Reply would be relevant. Should be > Unsolicited Reply would be IRRELEVANT. Thanks for your understanding. Eunsoo ----- Original Message ----- From: "Eunsoo Shim" To: "Henrik Petander" Cc: "Marco Liebsch" ; "Seamoby" Sent: Wednesday, October 15, 2003 11:24 AM Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? > Henrik, > > My comments are inline. > > > > > There is a similar problem is in the MN-AR protocol, with the ordering > of > > > > solicited and unsolicited replies. A new field in the MN-AR CARD > message > > > > header is _probably_ needed for sequence number, if strict ordering is > a > > > > requirement. > > > > > > > [eunsoo] There is already the sequence number field in the headers of > CARD > > > Request and Reply. Do you suggest any other field? > > > > Actually the problem in MN was more complex than I had thought: MN can get > > unsolicited CARD replies from multiple ARs and the information in ARs > > about CARs is not synchronized. > > In most cases, a MN will have a single current AR and therefore it will > receive CAR info only from the current AR. But in multi-homing cases, a MN > can have multiple "current ARs", in which case, your point is right. > > > It seems that a per-CAR sequence number / > > timestamp is needed in AR-MN reply for ordering to work. > > > This problem occurs because there can be multiple information distribution > channels and scenarios. For example, one attribute value can be updated > between two ARs using Request/Reply while another attribute value can be > updated via the Unsolicited Reply.To enforce strictive synchornization or > ordering of information, we would need timestamp for each attribute > including the IP address and MAC address. This seems creating lots overhead. > > > A potential solution is to include the original sequence number from the > > AR-AR CARD reply message header (not reply option) in some field for each > > CAR, e.g. in the capability container suboption, in the MN-AR CARD reply. > > Provided that the CAR increases the sequence number for every AR-AR CARD > > message it sends, this should work. The sequence number handling might > > need to work with wrap around, though. > > > > As mentioned in the above. just copying the original sequence number may not > work because the original sequence numbers for Solicited Reply and > Unsolicited Reply would be relevant. Again, every Reply should have a > timestamp(or sequence number) of the (Reply) sender and it should be copied > for each attribute value separately for strict ordering. > > I'd like to suggest a very simple approach instead of the strict information > synchronization or ordering. > How about letting the MN use the following simple policy? > 1) First, it takes Unsolicited Reply only from the default router (one of > the multiple current ARs in the case of multihoming). > 2) Second, it gives higher priority on the more recent information if it is > from the same sender (not the original source) --- In this case, the order > is determined by the sequence number for Unsolicited Replies. If the MN > receives Unsolicited Reply and Solicited Reply from the default router, it > takes more recently received information. > 3) Third, if the MN sent inquiry (Request) to multiple ARs, it takes the > most recently received information (Reply). > > Certainly this approach opens a (little) chance that the MN may NOT get the > most up-to-date information. However, since we don't make sure the ARs > synchronize their information in hard real-time, such a chance exists > anyway. So inserting timestamp for every attribute value may not be > justified by the gain compared to its cost. > > What do you think? > > Eunsoo > > > _______________________________________________ > 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 Oct 15 11:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05372 for ; Wed, 15 Oct 2003 11:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nnk-0006vq-MH for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFh41F026640 for seamoby-archive@odin.ietf.org; Wed, 15 Oct 2003 11:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nnk-0006va-H2 for seamoby-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05357 for ; Wed, 15 Oct 2003 11:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nnj-0006AD-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:43:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nni-0006AA-00 for seamoby-web-archive@ietf.org; Wed, 15 Oct 2003 11:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nnh-0006uZ-4M; Wed, 15 Oct 2003 11:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nmx-0006t1-DQ for seamoby@optimus.ietf.org; Wed, 15 Oct 2003 11:42: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 LAA05343 for ; Wed, 15 Oct 2003 11:42:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nmi-00069W-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:42:00 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A9nmh-00069T-00 for seamoby@ietf.org; Wed, 15 Oct 2003 11:42:00 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9FFfQ2s044913 for ; Wed, 15 Oct 2003 17:41:28 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9FFdPwm044799 for ; Wed, 15 Oct 2003 17:39:25 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9FFdO2o044797; Wed, 15 Oct 2003 17:39:25 +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 32A9A293A1; Wed, 15 Oct 2003 17:06:02 +0200 (CEST) Message-ID: <3F8D6A2B.1080407@ccrle.nec.de> Date: Wed, 15 Oct 2003 17:39:23 +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: Henrik Petander Cc: Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 Henrik Petander wrote: >Hi Marco, > >On Fri, 10 Oct 2003, Marco Liebsch wrote: > > > >>To your last point: Is an AR really required to distinguish a >>"resent" Request from a "new" one? >> >> > >Yes, if AR-AR resending is implemented, since AR will set a new AR-AR >resend timer when it receives a "new" request from MN. It should not do >the same for resends from MN for which it already has a timer. > That means an AR should refrain from creating a new timer in case it is a retransmit (which is reasonable), but should create a new timer in case a MN sends two requests directly after each other, right? The current spec allows the MN to send only one request per CARD_RETRANSMISSION_INTERVAL, which is set to 1 second. In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be a conflict, right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case it is a retransmission. But I guess this introcuced more complexity compared to the benefit. What do you think? > > >If MN increases the sequence number for each resend, then AR needs >to be able to differentiate the new and resent messages by other fields. I >don't think this is a problem, though, since AR can just compare the >L2-ids of the messages. > In a MN_AR CARD Request there is not necessarily to be a L2_ID present. But don't you think we get rid of this problem with the updated design of allowed retransmissions, where, according to your recent proposal, the MN-AR timeout should cover all possible retransmissions between ARs? Or, as described above, we could have a flag set in MN-AR CARD_REQUEST in case of a retransmit... (???) What do you think? marco > >Henrik > > > > >>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 Oct 17 03:41: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 DAA22670 for ; Fri, 17 Oct 2003 03:41: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 1AAPEV-0005PO-8p for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 03:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H7fBwM020786 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 03:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPEV-0005PB-1u for seamoby-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 03:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22627 for ; Fri, 17 Oct 2003 03:41:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPES-000050-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 03:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAPES-00004w-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 03:41:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPEO-0005OO-PH; Fri, 17 Oct 2003 03:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPDw-0005NS-Qa for seamoby@optimus.ietf.org; Fri, 17 Oct 2003 03:40: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 DAA22603 for ; Fri, 17 Oct 2003 03:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPDu-000041-00 for seamoby@ietf.org; Fri, 17 Oct 2003 03:40:34 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1AAPDs-00003o-00 for seamoby@ietf.org; Fri, 17 Oct 2003 03:40:33 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 2BD9380019F; Fri, 17 Oct 2003 10:40:32 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9H7eWGn016546; Fri, 17 Oct 2003 10:40:32 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9H7eSCb016542; Fri, 17 Oct 2003 10:40:31 +0300 Date: Fri, 17 Oct 2003 10:40:28 +0300 (EEST) From: Henrik Petander To: Marco Liebsch Cc: Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers In-Reply-To: <3F8D6A2B.1080407@ccrle.nec.de> Message-ID: References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Wed, 15 Oct 2003, Marco Liebsch wrote: > In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be > a conflict, > right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case > it is a retransmission. > But I guess this introcuced more complexity compared to the benefit. > What do you think? Isn't the MN-AR request resend interval the same as the minimum interval for new requests? So a flag may be the easiest way to allow AR to distinguish new requests from resends. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 17 03:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22768 for ; Fri, 17 Oct 2003 03:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPIG-0005a1-Pz for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 03:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H7j43m021450 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 03:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPIF-0005Zs-OI for seamoby-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 03:45: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 DAA22754 for ; Fri, 17 Oct 2003 03:44:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPID-00008K-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 03:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAPIC-00008H-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 03:45:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPID-0005Xd-LT; Fri, 17 Oct 2003 03:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPI3-0005XK-H0 for seamoby@optimus.ietf.org; Fri, 17 Oct 2003 03:44: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 DAA22751 for ; Fri, 17 Oct 2003 03:44:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPI0-00008B-00 for seamoby@ietf.org; Fri, 17 Oct 2003 03:44:49 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1AAPI0-000084-00 for seamoby@ietf.org; Fri, 17 Oct 2003 03:44:48 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 7ADA380019F; Fri, 17 Oct 2003 10:44:49 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9H7inGn016580; Fri, 17 Oct 2003 10:44:49 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9H7inKN016576; Fri, 17 Oct 2003 10:44:49 +0300 Date: Fri, 17 Oct 2003 10:44:48 +0300 (EEST) From: Henrik Petander To: Eunsoo Shim Cc: Marco Liebsch , Seamoby Subject: Re: [Seamoby] Re: CARD: Storing sequence numbers in ARs' CAR table? In-Reply-To: <00c801c39330$7365cab0$c96b0f8a@peace> Message-ID: References: <3F86E02C.6050208@ccrle.nec.de> <00d101c3925d$8a4c83f0$c96b0f8a@peace> <00c801c39330$7365cab0$c96b0f8a@peace> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Wed, 15 Oct 2003, Eunsoo Shim wrote: > I'd like to suggest a very simple approach instead of the strict information > synchronization or ordering. > How about letting the MN use the following simple policy? > 1) First, it takes Unsolicited Reply only from the default router (one of > the multiple current ARs in the case of multihoming). > 2) Second, it gives higher priority on the more recent information if it is > from the same sender (not the original source) --- In this case, the order > is determined by the sequence number for Unsolicited Replies. If the MN > receives Unsolicited Reply and Solicited Reply from the default router, it > takes more recently received information. > 3) Third, if the MN sent inquiry (Request) to multiple ARs, it takes the > most recently received information (Reply). > > Certainly this approach opens a (little) chance that the MN may NOT get the > most up-to-date information. > > What do you think? This should work well enough in most cases. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 17 09:24: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 JAA01174 for ; Fri, 17 Oct 2003 09:24: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 1AAUaQ-0004QW-04 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 09:24:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDO9sC017012 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 09:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUaP-0004QJ-T4 for seamoby-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 09:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01154 for ; Fri, 17 Oct 2003 09:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUaO-0003Kv-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 09:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAUaN-0003Ks-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 09:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUaH-0004PV-8O; Fri, 17 Oct 2003 09: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 1AAUZi-0004NE-L5 for seamoby@optimus.ietf.org; Fri, 17 Oct 2003 09:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01118 for ; Fri, 17 Oct 2003 09:23:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUZg-0003KR-00 for seamoby@ietf.org; Fri, 17 Oct 2003 09:23:24 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AAUZg-0003Jo-00 for seamoby@ietf.org; Fri, 17 Oct 2003 09:23:24 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9HDMf2s025837 for ; Fri, 17 Oct 2003 15:22:43 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9HDKIBl025675 for ; Fri, 17 Oct 2003 15:20:18 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9HDKH2o025672; Fri, 17 Oct 2003 15:20:18 +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 ABB691A864; Fri, 17 Oct 2003 14:46:36 +0200 (CEST) Message-ID: <3F8FEC90.4030303@ccrle.nec.de> Date: Fri, 17 Oct 2003 15:20:16 +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: Henrik Petander , lpetande@tml.hut.fi, seamoby@ietf.org Subject: CARD protocol constants related / was: Re: [Seamoby] CARD Review from Henrik Petander References: <018501c38cef$acd8d630$956015ac@dclkempt40> <3F85FF9C.30505@iprg.nokia.com> <3F8612BC.7090709@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: > you are right. the names for the protocol constants are confusing. > > basically we need to do the following > > 1. We need to rate-limit requests from the MN. > 2. specify retransmission behavior for the MN. > 3. specify retransmission behavior for the Current AR. > 4. specify sending behavior for unsolicited CARD replies > > for (1), we need a protocol constant to say that the MN is not allowed > to send > more than a certain number of requests per second. if it sends more > than that, > the current AR just drops the requests. There shouldnt be an upper > limit on > the number of requests. In the recent draft, we have the following constants specified for that purpose: CARD_RETRANSMISSION_INTERVAL = 1 second CARD_MAX_RETRIES = 3 As far as I remember, this is the mechanism and values you proposed, including the upper limit. This mechanism replaced the previous mechanism, which was based on the more dynamic approach using the rate-limiting flag. Do you now propose to drop the MAX_RETRIES limitation? > > for (2), we need protocol constants. one to say when to retransmit and > one to > say when to give up. The current draft specifies the following: MN_AR_CARD_TIMEOUT = 1 sec MN_AR_CARD_RETRIES = 5 > > for (3), same as (2). The current draft specifies the following: AR_AR_CARD_TIMEOUT = 1 sec AR_AR_CARD_RETRIES = 3 Referring to Henrik's feedback and addressed issue, the proposal was to keep the MN-AR characteristics and to adjust the AR-AR characteristics as follows: AR_AR_CARD_TIMEOUT: 300 ms AR_AR_CARD_RETRIES: 2 There was no feedback yet. Any comments? > > (2) and (3) could share the same protocol constants. If we modify the AR-AR characteristics to counteract the issue Henrik referred to, this cannot be done. > > (4) is already clearly defined. Right. marco > > Vijay > > Henrik Petander wrote: > >> Hi Vijay and all, >> >> Vijay, thanks for the clarification. CARD_MAX_RETRIES is 3 and >> MN_AR_CARD_RETRIES is 5, so MN can try to resend the same query for 5 >> times, but can make new queries (for different L2 addresses) only 3 >> times. >> Did I understand this correctly? >> >> If yes, then this scheme is a little confusing to me and raises some >> questions: Why is the interval called CARD_RETRANSMISSION_INTERVAL, >> if it >> concerns new requests, which are not resends? >> >> Why is there a fixed ceiling on how many new CARD requests MN can send ? >> Shouldn't there at least be a wait period after which MN can set the >> counter to zero? >> >> Thanks, >> >> Henrik >> >> On Thu, 9 Oct 2003, Vijay Devarapalli wrote: >> >> >> >>> hi Henrik, >>> >>> >>> >>>> What is the purpose of CARD_RETRANSMISSION_INTERVAL and >>>> CARD_MAX_RETRIES? >>>> >>>> >>> >>> they are used in rate-limiting MN requests >>> >>> 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. >>> >>> 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 Oct 17 13:06:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10702 for ; Fri, 17 Oct 2003 13:06:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY3B-0007E1-A5 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 13:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HH65mK027767 for seamoby-archive@odin.ietf.org; Fri, 17 Oct 2003 13:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY3B-0007Dm-4z for seamoby-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:06: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 NAA10649 for ; Fri, 17 Oct 2003 13:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAY39-0005it-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 13:06:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAY38-0005iq-00 for seamoby-web-archive@ietf.org; Fri, 17 Oct 2003 13:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY37-0007D0-Ms; Fri, 17 Oct 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY2x-0007C1-Oy for seamoby@optimus.ietf.org; Fri, 17 Oct 2003 13:05: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 NAA10623 for ; Fri, 17 Oct 2003 13:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAY2v-0005iU-00 for seamoby@ietf.org; Fri, 17 Oct 2003 13:05:49 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AAY2v-0005ho-00 for seamoby@ietf.org; Fri, 17 Oct 2003 13:05:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9HH4A328737; Fri, 17 Oct 2003 10:04:10 -0700 X-mProtect: <200310171704> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKaKaWa; Fri, 17 Oct 2003 17:03:19 UTC Message-ID: <3F90214D.200@iprg.nokia.com> Date: Fri, 17 Oct 2003 10:05:17 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco.Liebsch@ccrle.nec.de CC: lpetande@tml.hut.fi, seamoby@ietf.org Subject: Re: CARD protocol constants related / was: Re: [Seamoby] CARD Review from Henrik Petander References: In-Reply-To: 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 hi Marco, >>1. We need to rate-limit requests from the MN. >>2. specify retransmission behavior for the MN. >>3. specify retransmission behavior for the Current AR. >>4. specify sending behavior for unsolicited CARD replies >> >>for (1), we need a protocol constant to say that the MN is not allowed >>to send >>more than a certain number of requests per second. if it sends more >>than that, >>the current AR just drops the requests. There shouldnt be an upper >>limit on >>the number of requests. > > > > In the recent draft, we have the following constants specified for that > purpose: > CARD_RETRANSMISSION_INTERVAL = 1 second > CARD_MAX_RETRIES = 3 > > As far as I remember, this is the mechanism and values you proposed, > including the upper limit. This mechanism replaced the previous mechanism, > which was based on the more dynamic approach using the rate-limiting flag. > Do you now propose to drop the MAX_RETRIES limitation? yes. the CARD_MAX_RETRIES is not needed. also replace CARD_RETRANSMISSION_INTERNAL to CARD_REQUEST_RATE. replace To counteract this problem, 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. To counteract this problem, the MN MUST NOT send more than CARD_REQUEST_RATE requests per second. If the MN sends requests more frequently, the AR SHOULD drop the CARD requests and not process them. in section 7 CARD_REQUEST_RATE 2 I think 2 requests per second is okay. >>for (2), we need protocol constants. one to say when to retransmit and >>one to >>say when to give up. > > > The current draft specifies the following: > MN_AR_CARD_TIMEOUT = 1 sec > MN_AR_CARD_RETRIES = 5 > > >>for (3), same as (2). > > > The current draft specifies the following: > AR_AR_CARD_TIMEOUT = 1 sec > AR_AR_CARD_RETRIES = 3 > > Referring to Henrik's feedback and addressed issue, the proposal was to > keep the MN-AR characteristics and to adjust the AR-AR characteristics > as follows: > AR_AR_CARD_TIMEOUT: 300 ms > AR_AR_CARD_RETRIES: 2 > > There was no feedback yet. > Any comments? this is fine with me. >>(2) and (3) could share the same protocol constants. > > > If we modify the AR-AR characteristics to counteract the issue > Henrik referred to, this cannot be done. okay. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Sun Oct 19 21:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24927 for ; Sun, 19 Oct 2003 21:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOab-0001ZD-CY for seamoby-archive@odin.ietf.org; Sun, 19 Oct 2003 21:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K1C5TU006019 for seamoby-archive@odin.ietf.org; Sun, 19 Oct 2003 21:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOab-0001Z0-7J for seamoby-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 21:12: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 VAA24916 for ; Sun, 19 Oct 2003 21:11:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABOaY-0002BE-00 for seamoby-web-archive@ietf.org; Sun, 19 Oct 2003 21:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABOaY-0002BA-00 for seamoby-web-archive@ietf.org; Sun, 19 Oct 2003 21:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOaW-0001Xv-Mo; Sun, 19 Oct 2003 21:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOZn-0001K2-6O for seamoby@optimus.ietf.org; Sun, 19 Oct 2003 21:11: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 VAA24909 for ; Sun, 19 Oct 2003 21:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABOZk-0002B2-00 for seamoby@ietf.org; Sun, 19 Oct 2003 21:11:12 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1ABOZj-0002Az-00 for seamoby@ietf.org; Sun, 19 Oct 2003 21:11:12 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 141848001B7; Mon, 20 Oct 2003 04:11:11 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9K1BAGn026076; Mon, 20 Oct 2003 04:11:10 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9K1BAO9026072; Mon, 20 Oct 2003 04:11:10 +0300 Date: Mon, 20 Oct 2003 04:11:10 +0300 (EEST) From: Henrik Petander To: Marco Liebsch Cc: Henrik Petander , Seamoby In-Reply-To: <3F86E42F.5070903@ccrle.nec.de> Message-ID: References: <3F86E42F.5070903@ccrle.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Re: CARD: Address length in L2-ID parameter 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 Marco, On Fri, 10 Oct 2003, Marco Liebsch wrote: > "...L2 id suboption should have address length field which MUST be > used at least with with L2 type = 0x00." > > Maybe I misunderstood the issue, but the actual address length can > be calculated from the L2-ID sub-option's Length indicator, which > is always present, isn't it? Yes, but the sub-option is padded to be a multiple of 32 bits long, based on the way I understood 5.1.3. For example a 48-bit MAC address (and the L2 id subotion) would not end on a 32-bit boundary without 8 bits of padding. And if you don't know the length of the address, you can't determine where the padding starts. To correct this there are IMO three alternatives: 1. the boundary restriction needs to be relaxed or 2. the length of the address needs to be specified in the packet format or 3. L2 type specification should be a MUST and type 0x00 should be removed. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 20 11:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29721 for ; Mon, 20 Oct 2003 11:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABbVu-0000Wi-Kp for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 11:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KF06tv002010 for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 11:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABbVt-0000Vp-T5 for seamoby-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 11:00: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 KAA29673 for ; Mon, 20 Oct 2003 10:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABbVr-00017E-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 11:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABbVq-00017B-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 11:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABbVq-0000Ua-F4; Mon, 20 Oct 2003 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABbV4-0000JY-8E for seamoby@optimus.ietf.org; Mon, 20 Oct 2003 10:59: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 KAA29653 for ; Mon, 20 Oct 2003 10:59:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABbV1-00016b-00 for seamoby@ietf.org; Mon, 20 Oct 2003 10:59: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 1ABbV1-00016X-00 for seamoby@ietf.org; Mon, 20 Oct 2003 10:59:11 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Oct 2003 10:59:10 -0400 Message-ID: <012601c3971b$5f8356e0$c96b0f8a@peace> From: "Eunsoo Shim" To: "Henrik Petander" , "Marco Liebsch" Cc: "Seamoby" References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> Subject: Re: [Seamoby] CARD: handling of sequence numbers Date: Mon, 20 Oct 2003 11:03:51 -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: 20 Oct 2003 14:59:10.0662 (UTC) FILETIME=[B7E3F660:01C3971A] 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 > > > In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be > > a conflict, > > right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case > > it is a retransmission. > > But I guess this introcuced more complexity compared to the benefit. > > What do you think? > > Isn't the MN-AR request resend interval the same as the minimum interval > for new requests? So a flag may be the easiest way to allow AR to > distinguish new requests from resends. > If both time intervals are the same, does the AR need to distinguish a resent Request from a new Request for rate limiting? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 20 17:13: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 RAA05605 for ; Mon, 20 Oct 2003 17:13: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 1ABhKu-0006g7-6G for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 17:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KLD8g4025667 for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 17:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhKu-0006fu-20 for seamoby-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 17:13: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 RAA05560 for ; Mon, 20 Oct 2003 17:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABhKr-0000ht-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 17:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABhKr-0000hq-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 17:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhKn-0006bX-Gm; Mon, 20 Oct 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhJx-0006O3-JX for seamoby@optimus.ietf.org; Mon, 20 Oct 2003 17:12:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05530 for ; Mon, 20 Oct 2003 17:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABhJv-0000h9-00 for seamoby@ietf.org; Mon, 20 Oct 2003 17:12:07 -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 1ABhJu-0000h4-00 for seamoby@ietf.org; Mon, 20 Oct 2003 17:12:06 -0400 Message-ID: <000401c3974e$db9368a0$2a6015ac@dclkempt40> From: "James Kempf" To: Date: Sat, 18 Oct 2003 18:08:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CTP Last Call Comments 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've seen no comments on CTP. Here's mine. Unfortunately, this document is not ready to go to the IESG. jak -------------------------------- pg. 5 last paragraph: There's some kind of formatting botch here: "[1].* contexts." etc. pg. 8 second paragaraph: Another formatting botch: "%Notice that the length of the % the context data block", etc. pg 8, generic header diagram. I thought we agreed to remove the generic header diagram? It doesn't apply to all messages and is just confusing. pg. 9 top. An 'A' flag is mentioned, but none appears in the message. I think you mean 'R'. Also, in the description of the 'R' flag, it should indicate what reliable transfer means or point to a section in the document that describes this. Later in the document, we learn that this means partially that an acknowledgement is requested. Anything else? That should be here. If there's nothing else, I would call it "Acknowledged" transfer to avoid confusion with transport reliability, and I would, in fact, make it an A flag. pg. 11 top. Why does this draft say something about proxy address defense? CTP has nothing to do with routing. That should be for the protocol that does local routing repair (i.e. FMIP). If something needs to be said about address defense, mention can be made to the role of the handover protocol in that. pg. 10 middle. The calculation of the authentication token is not easy to follow. It should be broken out of the text body. Also, what secret is referred to in the 2nd line? Either point to the section where it is located or indicate here what it is. In fact, I would not call it a secret since, as we learn later on in the document, it is send over an unsecured channel. I would say that it is "a nounce exchanged between the AR and MN over an unsecured channel that is used for identifying the MN and is valid for a limited duration, on the order of a few hundred milliseconds". pg. 11 middle: What do the initials "PCTD only" mean? We learn in the paragraph afterwards that predictive context transfer requires these. These initials should be referenced in this paragraph. pg. 11 A key is being sent here, but the packet is not protected. Is this wise? Something needs to be said here about why not, or a pointer to a discussion in the security considerations section. This is likely to be a red flag for the Security ADs. If there is no protection on the packet, then I would suggest calling it something other than a shared secret or key, perhaps an "authentication nounce that is difficult to spoof but not designed to be highly secure because the duration of validity is so short (on the order of a few hundred milliseconds)". pg. 12 last paragraph "Sent by nAR to pAR request" -> "Sent by nAR to pAR to request" pg. 15 I'd like the following paragraph inserted right after the section header for Section 6 (Security Considerations); At this time, the threats to IP handover in general and context transfer in particular are incompletely understood, particularly on the MN to AR link, and mechanisms for countering them are not well defined. Part of the experimental task in preparing CTP for eventual standards track will be to better characterize threats to context transfer and design specific mechanisms to counter them. This section provides some general guidelines about security based on discussions among the Design Team and Working Group members. The issue of security came up in the discussion of MIPSHOP chartering, and I want to make sure that the IESG understands that this section is not intended to provide a thorough discussion of CTP security. pg. 18. The referenences are out of date. [CT-REQ] should be dropped, this document has been dropped by the WG. [FMIPv6] and [LLMIP] should be moved to the non-normative references as they are only referred to in the appendix and appendicies are not normative (anyway, this is an experimental doc, so why do we need normative and non-normative references?). RFC2434 reference is not properly formatted. [CTHC] can be removed, there is an example in this document now. If there is no reference to [RFC2401] please remove it, also [RFC2246]. pg. 19. 3rd para in Apx. A. Drop the reference to BETH. The rest of the para is OK. pg. 20 Recent IAB work with Sally Floyd and discussion with lots of people including some ISPs around the issue of congestion for VoIP traffic has identified access networks as precisely the place where congestion *is* likely to occur. Core networks are typically massively overprovisioned and therefore never suffer congestion. So I don't agree with this analysis. I also don't agree that using a congestion controlled TCP or SCTP connection is such a burden. The routers in the access network won't start the connection on the fly, they would have a connection open to all routers in their geographical vicinity and reuse it, as a result, there should be no startup transient. Also, if SCTP is used, there is no issue with latency due to retransmits for reliability. DCCP could also be used, though it is primarily intented for media. Of course, if context is dropped due to congestion the handover optimization will fail, but that is another issue. I believe this section is likely to receive intensive IESG criticism. Something could be said about this issue being for further study. Alternatively (and in my opinion, a better choices) is to remove the section. pg. 20 Please remove the pseudo section headers from Appendix C or use section numbering (e.g. C.1, C.2, etc.). Also: "In addtion, any application-specific...." -> "Any application specific..." pg. 21 "moderately utilized" -> "heavily utilized" pg. 21. The section on MLD state machine interactions is somewhat hard to read (yes, I know I wrote it). I'd suggest the following rewrite: No changes are requried in the MLD state machine. Upon receipt of a CTP Context Data Block for MLD, the state machne takes the following actions: - If the router is in the No Listeners present state on the wireless interface on which the Subnet Prefix field from the Context Data Block is advertised, it transitions into the Listeners Present state for the Subscribed IPv6 Multicast Address field in the Context Data Block. This transition is exactly the same as if the router had received a Report message. - If the router is in the Listeners present state on that interface, it remains in that state but restarts the timer, as if it had received a Report message. If more than one MLD router is on the link, a router receiving an MLD Context Data Block SHOULD send the block to the other routers on the link. The router MAY instead send a proxy MLD Report message on the wireless interface which advertises the Subnet Prefix field from the Context Data Block if wireless bandwidth is not an issue. Since MLD routers do not keep track of which nodes are listening to munticast addresses, only whether a particular multicast address is being listened to, proxying the subscription should cause no difficulty. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 20 21:16:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17127 for ; Mon, 20 Oct 2003 21:16:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl82-0006Xa-99 for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 21:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L1G6ti025136 for seamoby-archive@odin.ietf.org; Mon, 20 Oct 2003 21:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl82-0006X6-4k for seamoby-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 21:16: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 VAA17094 for ; Mon, 20 Oct 2003 21:15:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl7z-0004zw-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 21:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABl7z-0004zs-00 for seamoby-web-archive@ietf.org; Mon, 20 Oct 2003 21:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl7y-0006R1-R0; Mon, 20 Oct 2003 21:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl7J-0006II-6S for seamoby@optimus.ietf.org; Mon, 20 Oct 2003 21:15: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 VAA17083 for ; Mon, 20 Oct 2003 21:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl7G-0004zW-00 for seamoby@ietf.org; Mon, 20 Oct 2003 21:15:18 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1ABl7F-0004zT-00 for seamoby@ietf.org; Mon, 20 Oct 2003 21:15:17 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 6D6128000AF; Tue, 21 Oct 2003 04:15:16 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9L1FGGn030928; Tue, 21 Oct 2003 04:15:16 +0300 Received: from localhost (petander@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9L1FFQO030924; Tue, 21 Oct 2003 04:15:15 +0300 Date: Tue, 21 Oct 2003 04:15:15 +0300 (EEST) From: Henrik Petander To: Eunsoo Shim Cc: Marco Liebsch , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers In-Reply-To: <012601c3971b$5f8356e0$c96b0f8a@peace> Message-ID: References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , On Mon, 20 Oct 2003, Eunsoo Shim wrote: > > > > > > In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be > > > a conflict, > > > right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case > > > it is a retransmission. > > > But I guess this introcuced more complexity compared to the benefit. > > > What do you think? > > > > Isn't the MN-AR request resend interval the same as the minimum interval > > for new requests? So a flag may be the easiest way to allow AR to > > distinguish new requests from resends. > > > If both time intervals are the same, does the AR need to distinguish a > resent Request from a new Request for rate limiting? If it is OK that the AR sets the AR-AR resend timer for both, then there is no need to distinguish them. This is OK with me. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 21 17:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12030 for ; Tue, 21 Oct 2003 17:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4HU-00083R-4O for seamoby-archive@odin.ietf.org; Tue, 21 Oct 2003 17:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LLh8E1030958 for seamoby-archive@odin.ietf.org; Tue, 21 Oct 2003 17:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4HU-00083F-0m for seamoby-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 17:43: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 RAA11956 for ; Tue, 21 Oct 2003 17:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC4HR-00030S-00 for seamoby-web-archive@ietf.org; Tue, 21 Oct 2003 17:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC4HR-00030P-00 for seamoby-web-archive@ietf.org; Tue, 21 Oct 2003 17:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4HM-00081O-VR; Tue, 21 Oct 2003 17:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4Gs-0007u8-00 for seamoby@optimus.ietf.org; Tue, 21 Oct 2003 17:42:30 -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 RAA11918 for ; Tue, 21 Oct 2003 17:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC4Gp-0002zK-00 for seamoby@ietf.org; Tue, 21 Oct 2003 17:42:27 -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 1AC4Go-0002z9-00 for seamoby@ietf.org; Tue, 21 Oct 2003 17:42:26 -0400 Message-ID: <02cd01c3981c$42838e50$0a6015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 21 Oct 2003 14:42:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Review comments from Basavaraj Patel on 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 Forwarding. jak ------------------------------------ My comments are editorial only: Editorial: 1. Can the problem description text in the Introduction be a subsection? The current Into section begins with a reference to a problem statement described in RFC3374. Nit: The open quote "Problem... in Section 1 is not terminated. 2. s/This section provides a protocol overview/This section provides the CT protocol overview. 3. Section 2: (References) "In response to a CT-Activate Request message or to the CT trigger, pAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.4.2" Incorrect reference. "In the second scenario, pAR receives a Context Transfer Request (CT Request) described in Section 2.4.5, message from nAR." Incorrect reference; Should be 2.4.6 Nit: Check all references 4. Section 2: "[1].* contexts, pAR verifies authorization token before transmitting the [2]algorithm [3] When context transfer takes place without the nAR requesting it (scenario one above), nAR requires MN to present its authorization token" I could not make out what this statement says. I am not even sure if the authors can understand it. 5. Section 2: Can you create subsections for scenarios 1 and 2? Would make it easier to reference. 6. s/Additially/Additionally 7. Section 2.3 a. Would be good to describe each field separately. Goes for all subsequent sections where message formats are described. CXT Type - Length - P bit - b. "When the presence vector is in use, the Presentation Vector is interpreted.." What is this Presentation vector? (Typo) c. Last paragraph has % chars 8. Sec 2.4.1 "If an acknowledgement for this message is needed, the MN sets the A flag to 1, " Missing "A" flag in CTAR. 9. Sec 2.4.2 Describe the fields. 10. Is there a need for specifying the status codes used in CTDR and CTAA? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Tue Oct 21 17:45:21 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 RAA12154 for ; Tue, 21 Oct 2003 17:45:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4JL-0008Sn-Ha for seamoby-archive@odin.ietf.org; Tue, 21 Oct 2003 17:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LLj3V9032483 for seamoby-archive@odin.ietf.org; Tue, 21 Oct 2003 17:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4JL-0008Qx-34 for seamoby-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 17:45: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 RAA12131 for ; Tue, 21 Oct 2003 17:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC4JI-00034u-00 for seamoby-web-archive@ietf.org; Tue, 21 Oct 2003 17:45:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC4JH-00034r-00 for seamoby-web-archive@ietf.org; Tue, 21 Oct 2003 17:44:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4JJ-0008Ph-Rp; Tue, 21 Oct 2003 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC4Ic-0008Iw-Nd for seamoby@optimus.ietf.org; Tue, 21 Oct 2003 17:44:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12103 for ; Tue, 21 Oct 2003 17:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC4Ia-00033o-00 for seamoby@ietf.org; Tue, 21 Oct 2003 17:44:16 -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 1AC4IZ-00033l-00 for seamoby@ietf.org; Tue, 21 Oct 2003 17:44:15 -0400 Message-ID: <02d701c3981c$84126490$0a6015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 21 Oct 2003 14:44:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Comments of Antti Tuominen on CTP 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Forwarded. jak --------------------------------------- I-D: draft-ietf-seamoby-ctp-04.txt Review comments --------------- 1. In 2.3 it is specified that length is in 8 octet units. However, if presence vector and data are not present we have 4 octet message. Also context data may not 64bit align (especially when a presence vector is used). So it seems to me that you either have to have 1 octet as the unit (which of course limits length to 255 bytes) or do padding. 2. Also in 2.3 you use presence vector and presentation vector, so I guess s/Presentation Vector/presence vector/. 3. In 2.4.1, what are Type=Auth-Token and Type Len? No description, seem redundant. Same thing in 2.4.3 (also Algorithm) and 2.4.6. Old remnants? 4. Example in Appendix C is wrong. First, you do not "subscribe" to all-nodes. Node never sends MLD Report or Done for all-nodes. Second, you don't put Routing Header in MLD messages, but Router Alert Hop-by-hop option which is just 6 bytes (or 8 padded). In consequence, all time and space overhead calculations are incorrect. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 08:24:04 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 IAA05025 for ; Wed, 22 Oct 2003 08:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI1f-0007z4-Ue for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 08:23:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCNhiE030683 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 08:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI1e-0007yo-CA for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:23: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 IAA05000 for ; Wed, 22 Oct 2003 08:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI1c-0004DS-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 08:23:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI1c-0004DO-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 08:23:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI1Z-0007x7-DA; Wed, 22 Oct 2003 08:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGtW-0001O8-Nh for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 07:11: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 HAA03593 for ; Wed, 22 Oct 2003 07:11:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGtS-0003i0-00 for seamoby@ietf.org; Wed, 22 Oct 2003 07:11:10 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1ACGtQ-0003hr-00 for seamoby@ietf.org; Wed, 22 Oct 2003 07:11:09 -0400 Received: from inwind.it ([193.204.86.191]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h9MBB5N24084 for ; Wed, 22 Oct 2003 13:11:05 +0200 (CEST) Date: Wed, 22 Oct 2003 13:09:33 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3718FE64-0480-11D8-9321-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] Fwd: A quesition for you about CAR discovery 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 Inizio del messaggio inoltrato: > Da: Ivano De Luca > Data: Mer 22 Ott 2003 10:15:37 Europe/Rome > A: "James Kempf" > Oggetto: A quesition for you about CAR discovery > > Hi James, > I'm Ivano from southern of Italy.... > > I read the CARD protocol, but I've a question . > > MN sends a CARD Request to its AR to know the AR's IP from MAC's AP > known during scanning of APs. (cache 's MN is empty) > > Then, CARD Request is captured by its AR (MN's AR 's cache is empty) > that sends a CARD Request to ARs to receive their IP address. > > question : how do MS's AR do to send the CARD Request to ARs if it > doesn't know their IP address ? > > Thanks. > > Best Regards. > > Ivano > > ======================================================== > > "Be liberal in what you accept, and conservative in what you send." > Jon Postel > > ======================================================== "Be liberal in what you accept, and conservative in what you send." Jon Postel _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 10:51:24 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 KAA12843 for ; Wed, 22 Oct 2003 10:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKKG-0001i5-T9 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 10:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEp4J5006569 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 10: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 1ACKKG-0001hs-Py for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 10: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 KAA12826 for ; Wed, 22 Oct 2003 10:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKKE-0006K0-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 10:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACKKD-0006Jx-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 10: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 1ACKKE-0001h8-9e; Wed, 22 Oct 2003 10: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 1ACKK5-0001es-F4 for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 10:50:53 -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 KAA12818 for ; Wed, 22 Oct 2003 10:50:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKK2-0006Jl-00 for seamoby@ietf.org; Wed, 22 Oct 2003 10:50:50 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1ACKK2-0006JC-00 for seamoby@ietf.org; Wed, 22 Oct 2003 10:50:50 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id F11A334858 for ; Wed, 22 Oct 2003 16:50:14 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A2FB73F926 for ; Wed, 22 Oct 2003 16:44:56 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003102216445609686 for ; Wed, 22 Oct 2003 16:44:56 +0200 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 370DA3F88B for ; Wed, 22 Oct 2003 16:30:56 +0200 (CEST) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1ACJzu-00063e-5z for ; Wed, 22 Oct 2003 16:30:02 +0200 Date: Wed, 22 Oct 2003 16:30:02 +0200 From: Julien Bournelle To: seamoby@ietf.org Message-ID: <20031022143002.GC23251@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12819 Subject: [Seamoby] few comments on CTP 04 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, =20 after a quick review, these are my questions/comments concerning ctp-04.. 1. p4. 3 =A7 We call such an event as a Context Transfer Trigger -> We call such en event a Context Transfer Trigger 2. In the second scenario, nAR may itself generates a Context Transfer Request as a response to an internal trigger.=20 The problem is that nAR "must" supply, the MN's previous IP address, the feature contexts to be transferred and a token authorizing the transfer. So, I guess that either we offer a way to the nAR to retrieve this info from MN or the nAR can't generate a Context Transfer as a response to an internal trigger. Do I miss something ? 3. At the last paragraph p5. we have "[1].* contexts ...the [2]algorithm[3]" 4. In =A7 2.3 Context Data Block, it is written: "The Cxt-Type indicates the type of the feature context messages itself (such as QoS Context Request, Qos Context Transfer etc,).." can't it be deduce from CTAR/CTD/CTR ? 5. In =A7 2.4.1 Context Transfer Activate Request=20 While a MN sends a CTAR to pAR, the MN includes the nAR's address and its new IP address (if known). If these addresses are not known, what does MN include ? (his previous IP address or 0.0.0.0/0::0 ?) 6. I can't find "Context Transfer Framework for Seamless Mobility" :-( Hope it helps :-) --=20 julien.bournelle@int-evry.fr _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ----- End forwarded message ----- --=20 julien.bournelle@int-evry.fr _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 10:56: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 KAA13339 for ; Wed, 22 Oct 2003 10:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKP8-00031l-Di for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 10:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEu6Uv011631 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 10:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKP8-00031U-7P for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 10:56: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 KAA13294 for ; Wed, 22 Oct 2003 10:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKP5-0006Qz-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 10:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACKP5-0006Qw-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 10:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKP3-0002wQ-Li; Wed, 22 Oct 2003 10:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKOq-0002tI-Tb for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 10:55: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 KAA13274 for ; Wed, 22 Oct 2003 10:55:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKOo-0006Qn-00 for seamoby@ietf.org; Wed, 22 Oct 2003 10:55:46 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACKOn-0006Py-00 for seamoby@ietf.org; Wed, 22 Oct 2003 10:55:45 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9MEt52s010829 for ; Wed, 22 Oct 2003 16:55:07 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9MEt1Wn010804 for ; Wed, 22 Oct 2003 16:55:01 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9MEt02o010791; Wed, 22 Oct 2003 16:55:01 +0200 (CEST) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7945ED7F96; Wed, 22 Oct 2003 16:20:31 +0200 (CEST) Message-ID: <3F969A43.7070907@ccrle.nec.de> Date: Wed, 22 Oct 2003 16:54:59 +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: Henrik Petander Cc: Eunsoo Shim , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 Now, I think the solution depends on how we agree on another issue, which is related to protocol constants for the retransmissions. Again, according to Henrik's proposal to decrease the AR-AR retransmission interval and max. amount of retransmission on the AR-AR interface fit into one interval for MN-AR retransmission, then we get rid of the need to explicitely mark MN-AR retransmissions because ARs won't have a AR-AR timer set anymore in case of a MN-AR retransmission, right? The proposed values for retransmission timers were as follows: MN_AR_CARD_TIMEOUT: keep 1 sec. MN_AR_CARD_RETRIES: keep 5 AR_AR_CARD_TIMEOUT: 300 ms AR_AR_CARD_RETRIES: 2 We also need to take the max. allowed MN-AR request rate into account, which is in the recent draft set to 1/sec. Vijay proposed 2/sec, which would require to adjust the values for retransmission above appropriately. However, if we set MN-AR request rate to 1/second and the MN-AR timeout to 1 second, what's the differnce then between a retransmission and a new request? So, what do you think? marco Henrik Petander wrote: >On Mon, 20 Oct 2003, Eunsoo Shim wrote: > > > >>>>In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be >>>>a conflict, >>>>right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case >>>>it is a retransmission. >>>>But I guess this introcuced more complexity compared to the benefit. >>>>What do you think? >>>> >>>> >>>Isn't the MN-AR request resend interval the same as the minimum interval >>>for new requests? So a flag may be the easiest way to allow AR to >>>distinguish new requests from resends. >>> >>> >>> >>If both time intervals are the same, does the AR need to distinguish a >>resent Request from a new Request for rate limiting? >> >> > >If it is OK that the AR sets the AR-AR resend timer for both, then there >is no need to distinguish them. This is OK with me. > >Henrik > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 12:17:23 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 MAA16327 for ; Wed, 22 Oct 2003 12:17:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLfU-0006bV-Fz for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGH4VJ025382 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLfU-0006bJ-Ae for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16316 for ; Wed, 22 Oct 2003 12:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLfS-0007MU-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLfS-0007MR-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLfQ-0006aM-Sc; Wed, 22 Oct 2003 12:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLek-0006VT-10 for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 12:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16277 for ; Wed, 22 Oct 2003 12:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLei-0007LO-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:16:16 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACLeh-0007Kr-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:16:15 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9MGFc2s018010 for ; Wed, 22 Oct 2003 18:15:40 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9MGFakR018006 for ; Wed, 22 Oct 2003 18:15:36 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9MGFZ2o018003; Wed, 22 Oct 2003 18:15:36 +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 3105B87B08; Wed, 22 Oct 2003 17:41:06 +0200 (CEST) Message-ID: <3F96AD26.7000704@ccrle.nec.de> Date: Wed, 22 Oct 2003 18:15:34 +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: Henrik Petander Cc: Henrik Petander , Seamoby References: <3F86E42F.5070903@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: CARD: Address length in L2-ID parameter 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 Henrik, Henrik Petander wrote: >Hi Marco, > >On Fri, 10 Oct 2003, Marco Liebsch wrote: > > > >>"...L2 id suboption should have address length field which MUST be >>used at least with with L2 type = 0x00." >> >>Maybe I misunderstood the issue, but the actual address length can >>be calculated from the L2-ID sub-option's Length indicator, which >>is always present, isn't it? >> >> > >Yes, but the sub-option is padded to be a multiple of 32 bits long, based >on the way I understood 5.1.3. For example a 48-bit MAC address (and the >L2 id subotion) would not end on a 32-bit boundary without 8 bits of >padding. And if you don't know the length of the address, you can't >determine where the padding starts. > >To correct this there are IMO three alternatives: 1. the boundary >restriction needs to be relaxed or 2. the length of the address needs to >be specified in the packet format or 3. L2 type specification should be a >MUST and type 0x00 should be removed. > > Thanks for the clarification. Of course, you are right. Referring to the recent issue on the assignment of L2-type values, I must admit that your option 1 or 2 are the candidates I would go for. Since we said that individual sub-options should take care about 32-bit boundary alignment, relaxing this for the L2-ID is not consistent. Hence, it won't be a problem to have another byte after the L2-type field, which indicates the real length of the L2-ID field without padding. However, having 2 length fields in one parameter doesn't look good, but might be the best compromise. What's the opinion of others? Any preferences here? marco >Henrik > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 12:50:23 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 MAA17449 for ; Wed, 22 Oct 2003 12:50:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMBQ-0002cO-KV for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGo4Uk010054 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMBQ-0002c5-CF for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:50: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 MAA17427 for ; Wed, 22 Oct 2003 12:49:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMBO-0007hc-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:50:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMBO-0007hZ-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMBN-0002as-Fx; Wed, 22 Oct 2003 12:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMB1-0002YV-6I for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 12:49: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 MAA17412 for ; Wed, 22 Oct 2003 12:49:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAx-0007h8-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:49:36 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACMAx-0007gw-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:49:35 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9MGn12s019544 for ; Wed, 22 Oct 2003 18:49:04 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9MGmwfe019541 for ; Wed, 22 Oct 2003 18:48:58 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9MGmv2o019538; Wed, 22 Oct 2003 18:48:58 +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 D98EEBA79; Wed, 22 Oct 2003 18:14:27 +0200 (CEST) Message-ID: <3F96B4F8.1070505@ccrle.nec.de> Date: Wed, 22 Oct 2003 18:48:56 +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: Eunsoo Shim Cc: James Kempf , Vijay Devarapalli , Seamoby Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> <01f601c391c3$af2343c0$c96b0f8a@peace> <07b601c391c3$bee27bf0$956015ac@dclkempt40> <023901c391c8$3ab84f30$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: >>>The two sub-options have different formats as well as different >>> >>> >semantics. > > >>>Two separately defined sub-options are simpler in usage and >>>encoding/decoding, I think. >>> >>> >>> >>Can you explain how having two sets of parsing code is simpler than having >>one? >> >> >> > >The Requirements sub-option should contain a list of AVP while the >Preferences sub-option should contain only a list of attribute IDs. That is, >they have different formats. By knowing the type of sub-option from the >sub-option header, the receiver knows what format to be expected. > >Also by putting all the Requirements separately from the Preferences, the >receiver can get the Requirements at once without having to figure out >whether each filter is for Requirements or Preferences. > >An alternative suggested in the mailing list to merge the two sub-options >was putting a empty value for the AVP to indicate the AVP was for >Preferences. To do this, each AVP for Preferences should have the length >field as well which indicates always zero. It is waste of bandwidth. Reading >the length field is waste of the receiver resources (time and power). In the >end, the receiver should logically separate Requirements from Preferences >from the merged filter. So from the viewpoint of implementers, merging the >two sub-options into a single sub-option requires another step to separte >them in the receiver side. > >Logically the two filters are separte to the sender as well as the receiver. >Having them separated physically is clearer for both of the sender and the >receiver. > > >Eunsoo > > > > I agree with Eunsoo here, that also the logical function should be taken into consideration. How to process payload of the sub-option is clear already after processing the sub-option type, whereas when using one sub-option for both functions, individual AVPs need to be checked. In the latter case, the length should not be 0x00 but 0x03 in case of just transmitting Attributes... Furthermore, should we allow then also a "mixed" approach, where this merged sub-option can convey Attribute-Value-Pairs for CAR filtering together with only Attributes for capbility filtering...? I think then ist really starts to get complex without getting any benefit. I propose to keep going for the 2 separate sub-options. However, in case we drop also the AVP Length fields in a Preferences sub-option for bandwidth optimization, we have the same problem as we have for the L2-ID, which is related to "length without padding" and "length with padding". For a solution I propose the following: Just list Attribute values (each has 16 bit). In case (# of attributes) mod 2 = 0, fine, otherwise attach Attribute value 0x00 for padding. Value = 0x00 should then not be used for capabilities. What do you think? marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 12:52:20 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 MAA17518 for ; Wed, 22 Oct 2003 12:52:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMDK-0002ug-6L for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGq2xe011197 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 12: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 1ACMDK-0002uW-3R for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:52: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 MAA17514 for ; Wed, 22 Oct 2003 12:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMDI-0007jq-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMDH-0007jn-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 12:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMDI-0002tp-VK; Wed, 22 Oct 2003 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMCt-0002rm-1m for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 12:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17489 for ; Wed, 22 Oct 2003 12:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMCr-0007jC-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:51:33 -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 1ACMCq-0007j1-00 for seamoby@ietf.org; Wed, 22 Oct 2003 12:51:32 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Oct 2003 12:51:24 -0400 Message-ID: <011701c398bd$68568f50$c96b0f8a@peace> From: "Eunsoo Shim" To: "Marco Liebsch" Cc: "James Kempf" , "Vijay Devarapalli" , "Seamoby" References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> <01f601c391c3$af2343c0$c96b0f8a@peace> <07b601c391c3$bee27bf0$956015ac@dclkempt40> <023901c391c8$3ab84f30$c96b0f8a@peace> <3F96B4F8.1070505@ccrle.nec.de> Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) Date: Wed, 22 Oct 2003 12:56:16 -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: 22 Oct 2003 16:51:24.0932 (UTC) FILETIME=[BAA78440:01C398BC] 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 propose to keep going for the 2 separate sub-options. However, in case > we drop also the > AVP Length fields in a Preferences sub-option for bandwidth > optimization, we have the > same problem as we have for the L2-ID, which is related to "length > without padding" and > "length with padding". For a solution I propose the following: Just list > Attribute values (each > has 16 bit). In case (# of attributes) mod 2 = 0, fine, otherwise attach > Attribute value > 0x00 for padding. Value = 0x00 should then not be used for capabilities. > > What do you think? > I agree to the proposal in the above. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 16:27:23 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 QAA26514 for ; Wed, 22 Oct 2003 16:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPZO-0007ml-W5 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKR2NS029923 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPZO-0007mY-SE for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26506 for ; Wed, 22 Oct 2003 16:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPZM-0002G6-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPZM-0002G3-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPZM-0007kp-RU; Wed, 22 Oct 2003 16: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 1ACPYQ-0007Lr-Sc for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 16:26: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 QAA26473 for ; Wed, 22 Oct 2003 16:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPYO-0002Fu-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:26:01 -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 1ACPYO-0002Fq-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:26:00 -0400 Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Oct 2003 16:26:00 -0400 Message-ID: <022d01c398db$62704310$c96b0f8a@peace> From: "Eunsoo Shim" To: "Marco Liebsch" , "Henrik Petander" Cc: "Seamoby" References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> <3F969A43.7070907@ccrle.nec.de> Subject: Re: [Seamoby] CARD: handling of sequence numbers Date: Wed, 22 Oct 2003 16:30:51 -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: 22 Oct 2003 20:26:00.0862 (UTC) FILETIME=[B54E83E0:01C398DA] 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 My comments are inline. > Now, I think the solution depends on how we agree on another issue, > which is related to protocol constants for the retransmissions. > Again, according to Henrik's proposal to decrease the AR-AR retransmission > interval and max. amount of retransmission on the AR-AR interface fit into > one interval for MN-AR retransmission, then we get rid of the need to > explicitely mark MN-AR retransmissions because ARs won't have a > AR-AR timer set anymore in case of a MN-AR retransmission, right? > > The proposed values for retransmission timers were as follows: > > MN_AR_CARD_TIMEOUT: keep 1 sec. > MN_AR_CARD_RETRIES: keep 5 > AR_AR_CARD_TIMEOUT: 300 ms > AR_AR_CARD_RETRIES: 2 > > We also need to take the max. allowed MN-AR request rate into account, > which is > in the recent draft set to 1/sec. Vijay proposed 2/sec, which would > require to > adjust the values for retransmission above appropriately. Maybe my comment about it is quite late. Anyway I wonder again why it should be 2 seconds instead of 1 second. Could Vijay explain a little bit? Even though I have no base, 2 secounds sounds somewhat long. > > However, if we set MN-AR request rate to 1/second and the MN-AR timeout to > 1 second, what's the differnce then between a retransmission and a new > request? > There is no difference in terms of rate limiting this case. So I don't think we need a marker for retransmitted Requests in the current specification. Eunsoo > So, what do you think? > > marco > > Henrik Petander wrote: > > >On Mon, 20 Oct 2003, Eunsoo Shim wrote: > > > > > > > >>>>In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be > >>>>a conflict, > >>>>right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case > >>>>it is a retransmission. > >>>>But I guess this introcuced more complexity compared to the benefit. > >>>>What do you think? > >>>> > >>>> > >>>Isn't the MN-AR request resend interval the same as the minimum interval > >>>for new requests? So a flag may be the easiest way to allow AR to > >>>distinguish new requests from resends. > >>> > >>> > >>> > >>If both time intervals are the same, does the AR need to distinguish a > >>resent Request from a new Request for rate limiting? > >> > >> > > > >If it is OK that the AR sets the AR-AR resend timer for both, then there > >is no need to distinguish them. This is OK with me. > > > >Henrik > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 16:34:23 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 QAA26878 for ; Wed, 22 Oct 2003 16:34:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPgB-0001NQ-6x for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKY3QG005254 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPgA-0001Mf-Uf for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:34: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 QAA26855 for ; Wed, 22 Oct 2003 16:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPg8-0002KK-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPg8-0002KH-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPg9-0001LN-2j; Wed, 22 Oct 2003 16: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 1ACPfv-0001Gy-Mo for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 16:33: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 QAA26849 for ; Wed, 22 Oct 2003 16:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPft-0002K8-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:33:45 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACPft-0002K3-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:33:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MKWqE28790; Wed, 22 Oct 2003 13:32:52 -0700 X-mProtect: <200310222032> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddORr8n; Wed, 22 Oct 2003 13:32:51 PDT Message-ID: <3F96E9F1.1050405@iprg.nokia.com> Date: Wed, 22 Oct 2003 13:34:57 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eunsoo Shim CC: Marco Liebsch , Henrik Petander , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> 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 Eunsoo Shim wrote: >>The proposed values for retransmission timers were as follows: >> >>MN_AR_CARD_TIMEOUT: keep 1 sec. >>MN_AR_CARD_RETRIES: keep 5 >>AR_AR_CARD_TIMEOUT: 300 ms >>AR_AR_CARD_RETRIES: 2 >> >>We also need to take the max. allowed MN-AR request rate into account, >>which is >>in the recent draft set to 1/sec. Vijay proposed 2/sec, which would >>require to >>adjust the values for retransmission above appropriately. > > > Maybe my comment about it is quite late. Anyway I wonder again why it should > be 2 seconds instead of 1 second. Could Vijay explain a little bit? Even > though I have no base, 2 secounds sounds somewhat long. 2/sec in Marco's text refers to 2 requests per second, which means a mobile node could send CARD requests every 500 ms, but still be assured that the current AR wont drop it. currently the MN shouldnt send more than 1 request per second. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 22 16:48: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 QAA27446 for ; Wed, 22 Oct 2003 16:48: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 1ACPtj-0004zQ-9b for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKm3sV019174 for seamoby-archive@odin.ietf.org; Wed, 22 Oct 2003 16:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPtj-0004zB-5l for seamoby-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:48: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 QAA27434 for ; Wed, 22 Oct 2003 16:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPth-0002Sz-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:48:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPtg-0002Sw-00 for seamoby-web-archive@ietf.org; Wed, 22 Oct 2003 16:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPth-0004yM-1t; Wed, 22 Oct 2003 16: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 1ACPsq-0004k6-Jc for seamoby@optimus.ietf.org; Wed, 22 Oct 2003 16:47: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 QAA27428 for ; Wed, 22 Oct 2003 16:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPso-0002Sn-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:47:06 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACPsn-0002SR-00 for seamoby@ietf.org; Wed, 22 Oct 2003 16:47:05 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MKkDr10647; Wed, 22 Oct 2003 13:46:13 -0700 X-mProtect: <200310222046> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmC6wyb; Wed, 22 Oct 2003 13:46:11 PDT Message-ID: <3F96ED11.3030805@iprg.nokia.com> Date: Wed, 22 Oct 2003 13:48:17 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Liebsch CC: Henrik Petander , Eunsoo Shim , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> 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 Marco Liebsch wrote: > Now, I think the solution depends on how we agree on another issue, > which is related to protocol constants for the retransmissions. > Again, according to Henrik's proposal to decrease the AR-AR retransmission > interval and max. amount of retransmission on the AR-AR interface fit into > one interval for MN-AR retransmission, then we get rid of the need to > explicitely mark MN-AR retransmissions because ARs won't have a > AR-AR timer set anymore in case of a MN-AR retransmission, right? > > The proposed values for retransmission timers were as follows: > > MN_AR_CARD_TIMEOUT: keep 1 sec. > MN_AR_CARD_RETRIES: keep 5 > AR_AR_CARD_TIMEOUT: 300 ms > AR_AR_CARD_RETRIES: 2 > > We also need to take the max. allowed MN-AR request rate into account, > which is > in the recent draft set to 1/sec. Vijay proposed 2/sec, which would > require to > adjust the values for retransmission above appropriately. we are mixing up things here. in retransmissions you send the same request again. the rate limiting mechanism is for limiting the total number of requests the MN can send in a second. it shouldnt be a problem to have MN-AR retransmission timeout to be 1 second and have an upper limit of 2 requests per second for MN-AR CARD requests. they are not related. I will give you an example. a mobile node sends a request. it waits a second for reply. if there is no reply, the mobile node assumes that either the request or the reply was lost and retransmits the request. in another case, the mobile node sends a request. within another 200 ms, something changes (like the MN discovering a new AP with a stronger signal). the mobile node now needs to send out another CARD request for the new AP. the time gap between the two requests would be just 200 seconds. waiting for a second before you can enquire about this new AP is too long. it doesnt matter whether the mobile node got a response to its first request. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 23 05:42: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 FAA10348 for ; Thu, 23 Oct 2003 05:42:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyu-0004rU-M4 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 05:42:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9gC9u018689 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 05:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyu-0004rM-Dv for seamoby-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:42: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 FAA10316 for ; Thu, 23 Oct 2003 05:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbyq-0004Mw-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 05:42:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACbyq-0004Mt-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 05:42:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyj-0004kB-3g; Thu, 23 Oct 2003 05:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyL-0004WL-45 for seamoby@optimus.ietf.org; Thu, 23 Oct 2003 05:41: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 FAA10262 for ; Thu, 23 Oct 2003 05:41:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbyH-0004M2-00 for seamoby@ietf.org; Thu, 23 Oct 2003 05:41:33 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACbyG-0004Lk-00 for seamoby@ietf.org; Thu, 23 Oct 2003 05:41:33 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9N9f12s040484 for ; Thu, 23 Oct 2003 11:41:03 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9N9c5eg040393 for ; Thu, 23 Oct 2003 11:38:05 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9N9c42o040391; Thu, 23 Oct 2003 11:38:05 +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 CB33F131ED; Thu, 23 Oct 2003 11:03:27 +0200 (CEST) Message-ID: <3F97A178.2070001@ccrle.nec.de> Date: Thu, 23 Oct 2003 11:38:00 +0200 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eunsoo Shim Cc: James Kempf , Vijay Devarapalli , Seamoby Subject: Re: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues) References: <3F69DFCF.5050709@ccrle.nec.de> <3F862001.1010705@iprg.nokia.com> <002401c38f35$b8d6a820$c96b0f8a@peace> <3F86F863.1070608@iprg.nokia.com> <045b01c391b2$7506ec20$956015ac@dclkempt40> <013601c391b5$66583230$c96b0f8a@peace> <075201c391c2$2e6a57b0$956015ac@dclkempt40> <01f601c391c3$af2343c0$c96b0f8a@peace> <07b601c391c3$bee27bf0$956015ac@dclkempt40> <023901c391c8$3ab84f30$c96b0f8a@peace> <3F96B4F8.1070505@ccrle.nec.de> <011701c398bd$68568f50$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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 If there are no concerns to the proposed solution until Friday, we'll close this issue then and adjust the text in the draft for the next update. Any comments? marco Eunsoo Shim wrote: >>I propose to keep going for the 2 separate sub-options. However, in case >>we drop also the >>AVP Length fields in a Preferences sub-option for bandwidth >>optimization, we have the >>same problem as we have for the L2-ID, which is related to "length >>without padding" and >>"length with padding". For a solution I propose the following: Just list >>Attribute values (each >>has 16 bit). In case (# of attributes) mod 2 = 0, fine, otherwise attach >>Attribute value >>0x00 for padding. Value = 0x00 should then not be used for capabilities. >> >>What do you think? >> >> >> > >I agree to the proposal in the above. > >Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 23 05:49:24 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 FAA10575 for ; Thu, 23 Oct 2003 05:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACc5Z-0006ds-0h for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 05:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9n4vL025526 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 05:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACc5Y-0006dd-Su for seamoby-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:49: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 FAA10560 for ; Thu, 23 Oct 2003 05:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACc5V-0004T7-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 05:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACc5U-0004T4-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 05:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACc5W-0006cp-Ms; Thu, 23 Oct 2003 05:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACc5R-0006bp-G1 for seamoby@optimus.ietf.org; Thu, 23 Oct 2003 05:48:57 -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 FAA10557 for ; Thu, 23 Oct 2003 05:48:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACc5N-0004T1-00 for seamoby@ietf.org; Thu, 23 Oct 2003 05:48:53 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACc5N-0004SW-00 for seamoby@ietf.org; Thu, 23 Oct 2003 05:48:53 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9N9mL2s040842 for ; Thu, 23 Oct 2003 11:48:23 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9N9mHM4040840 for ; Thu, 23 Oct 2003 11:48:17 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9N9mG2o040834; Thu, 23 Oct 2003 11:48:17 +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 7E431D4122; Thu, 23 Oct 2003 11:13:40 +0200 (CEST) Message-ID: <3F97A3E0.5070100@ccrle.nec.de> Date: Thu, 23 Oct 2003 11:48:16 +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: Henrik Petander , Eunsoo Shim , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 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: > >> Now, I think the solution depends on how we agree on another issue, >> which is related to protocol constants for the retransmissions. >> Again, according to Henrik's proposal to decrease the AR-AR >> retransmission >> interval and max. amount of retransmission on the AR-AR interface fit >> into >> one interval for MN-AR retransmission, then we get rid of the need to >> explicitely mark MN-AR retransmissions because ARs won't have a >> AR-AR timer set anymore in case of a MN-AR retransmission, right? >> >> The proposed values for retransmission timers were as follows: >> >> MN_AR_CARD_TIMEOUT: keep 1 sec. >> MN_AR_CARD_RETRIES: keep 5 >> AR_AR_CARD_TIMEOUT: 300 ms >> AR_AR_CARD_RETRIES: 2 >> >> We also need to take the max. allowed MN-AR request rate into >> account, which is >> in the recent draft set to 1/sec. Vijay proposed 2/sec, which would >> require to >> adjust the values for retransmission above appropriately. > > > we are mixing up things here. in retransmissions you send the > same request again. the rate limiting mechanism is for limiting > the total number of requests the MN can send in a second. > > it shouldnt be a problem to have MN-AR retransmission timeout to > be 1 second and have an upper limit of 2 requests per second for > MN-AR CARD requests. > > they are not related. I will give you an example. a mobile node > sends a request. it waits a second for reply. if there is no > reply, the mobile node assumes that either the request or the > reply was lost and retransmits the request. > > in another case, the mobile node sends a request. within another > 200 ms, something changes (like the MN discovering a new AP with > a stronger signal). the mobile node now needs to send out > another CARD request for the new AP. the time gap between the two > requests would be just 200 seconds. waiting for a second before > you can enquire about this new AP is too long. it doesnt matter > whether the mobile node got a response to its first request. Right, but your example assumes the successful case for sending a quick new request where the reply to the previous request has been received. What if a reply does not appear for some reasons after 500ms and a MN just sends a new request. Then we can run into the timer setting problem, which has been indicated by Henrik, on the current AR again. Or we could just allow the AR to "overwrite" the running timer with the new request in this case and ignore the previous request and associated possibly outstanding signaling messages between ARs. What do you think? marco > > Vijay > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 23 07:59: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 HAA14509 for ; Thu, 23 Oct 2003 07:59: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 1ACe7O-0006lW-K4 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 07:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NBx6Dp026003 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 07:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe7N-0006kx-EO for seamoby-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 07:59: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 HAA14487 for ; Thu, 23 Oct 2003 07:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe7L-00062z-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 07:59:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACe7L-00062w-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 07:59:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe7J-0006jp-Cw; Thu, 23 Oct 2003 07:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe6r-0006dO-5H for seamoby@optimus.ietf.org; Thu, 23 Oct 2003 07:58: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 HAA14471 for ; Thu, 23 Oct 2003 07:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe6p-00062O-00 for seamoby@ietf.org; Thu, 23 Oct 2003 07:58:31 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1ACe6o-000621-00 for seamoby@ietf.org; Thu, 23 Oct 2003 07:58:30 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id h9NBvwTa009158 for ; Thu, 23 Oct 2003 13:57:58 +0200 Message-ID: <01a001c3995d$501d1f80$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Thu, 23 Oct 2003 14:00:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019D_01C3996E.1362CC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Seamoby] New Mobile Technologies Forum 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_019D_01C3996E.1362CC00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The New Mobile Technologies Forum will be taking place in 5 weeks from = the 2nd to the 5th of December 2003 at the Hotel Sofitel Paris Bercy - = France.=20 The Forum includes the IP Based Cellular Networks'03 Conference, the = Deploying IPv6 Networks'03 Conference and the Ultra Wide Band Summit'03. = (http://www.upperside.fr/newmobtech/newmobtech03intro.htm)=20 We remind you that you can benefit from different Team passes. For more details and to register please visit: = http://www.upperside.fr/newmobtech/newmobtech03term.htm ------=_NextPart_000_019D_01C3996E.1362CC00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The = New Mobile=20 Technologies Forum will be taking place in 5 weeks=20 from the 2nd to the 5th of December 2003 at the = Hotel=20 Sofitel Paris Bercy - France.=20
The Forum = includes the IP Based Cellular Networks'03 = Conference,=20 the Deploying = IPv6=20 Networks'03 Conference and the Ultra=20 Wide Band Summit'03. (http://= www.upperside.fr/newmobtech/newmobtech03intro.htm)=20
We remind you that you can = benefit=20 from different Team passes.
For more details and to = register=20 please visit: http://w= ww.upperside.fr/newmobtech/newmobtech03term.htm<= /DIV> ------=_NextPart_000_019D_01C3996E.1362CC00-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 23 09:51:57 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 JAA21288 for ; Thu, 23 Oct 2003 09:51:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfsG-0005RI-2a for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 09:51:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDpaGs020904 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 09:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfsF-0005R5-VO for seamoby-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 09:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21171 for ; Thu, 23 Oct 2003 09:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfsD-0000Dt-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 09:51:33 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ACfsD-0000Be-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 09:51:33 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ACfnz-0000AZ-Kt for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 09:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfnp-0004fF-61; Thu, 23 Oct 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfnJ-0004an-CT for seamoby@optimus.ietf.org; Thu, 23 Oct 2003 09:46:29 -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 JAB20639 for ; Thu, 23 Oct 2003 09:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfnG-00001J-00 for seamoby@ietf.org; Thu, 23 Oct 2003 09:46:26 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1ACfnG-0007np-00 for seamoby@ietf.org; Thu, 23 Oct 2003 09:46:26 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9NDjn2w056642 for ; Thu, 23 Oct 2003 15:45:53 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9NDfH5L056395 for ; Thu, 23 Oct 2003 15:41:17 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9NDfF2o056392; Thu, 23 Oct 2003 15:41:17 +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 F28594CD5D; Thu, 23 Oct 2003 15:06:36 +0200 (CEST) Message-ID: <3F97DA7A.4040801@ccrle.nec.de> Date: Thu, 23 Oct 2003 15:41:14 +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: lpetande@tml.hut.fi Cc: petander@tcs.hut.fi, Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD: Feedback on editorial issues Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Henrik, finally, after addressing the protocol issues of your review first, here my feedback with regard to the editorial issues. >4. ...CARD Reply contains one or more L2 ids and IP addresses" Isn't > this contradictory with the use of context id of L2 IDs from CARD > Request in CARD reply to avoid including L2 ids? Change this to > "may contain". marco: Ok, done. >5.1.1 >The text in 5.1.1 on including suboptions in CARD MN-AR request is >confusing to me. Which suboptions must be present in all messages? Isn't >it valid to send just a MN-AR CARD request to get all CARs and their >capabilities from AR? marco: I tried to make it clear in the text. I guess in 5.1.1 you refer to the description of CARD Request in the Valid Options... I revised the text as follows: "CARD Request: The CARD Request allows entities to request CARD specific information from ARs. To support processing the CARD Request message on the receiver side, further sub-options may be carried, serving as input to the reverse address translation function and/or capability discovery function" >5.1.2 Should maybe have a note that flag combination A= 0 with C=0 is >invalid. marco: Since the A-flag is set in case the MN does NOT want its AR to perform reverse address translation, I think you mean the combination "A=1" (not A=0) and C=0 is invalid, right? If this is correct, I will add this note. >6.3 Second paragraph is repeated from 4.6. Shouldn't this section >analyze the security, whereas section 4.6 should describe the >implementation of the security mechanisms. marco: this section has been revised anyway due to the decision on how we'll handle securing the unsolicited CARD Reply multicast. Please find the revised text here: "6.3 Security Association between AR and MN A malicious node can send bogus CARD Reply messages to MNs by masquerading the AR. So the MN MUST authenticate the CARD Reply messages from the AR. IPsec ESP is the default mechanism for CARD signaling message authentication between an AR and a MN. Also, IPsec ESP is the default method for message encryption. (marco:as we did in 6.2) Authentication of unsolicited CARD Reply messages, which are multicast from an AR towards MNs, is an open issue and the specification of an appropriate mechanism is out of scope of this document." >6.4 CARD Reply DoS: Is this really a relevant threat, since CAR is > authenticated with IPSec ESP? It seems to require compromise of CAR, > so IMO this is out of scope. Only AR-AR CARD Reply is protected with IPSec. Unsolicited MN-AR Reply protection is out of scope. Now, independent of the authentication mechanism, overwhelming a node with CARD Replies requires the receiving entity to perform processing of this message. If rate limitation is out of control, a DoS attack is possible. Hence, we need a rate limiting policy, which is described in section 4. >7. Protocol constants >What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? marco: Clarified in previous mails. But agreement on final values is still pending. Thanks marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 23 14:21: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 OAA10875 for ; Thu, 23 Oct 2003 14:21: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 1ACk56-0007p1-5Y for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 14:21:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NIL8sk030063 for seamoby-archive@odin.ietf.org; Thu, 23 Oct 2003 14:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACk56-0007oo-2A for seamoby-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 14:21: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 OAA10849 for ; Thu, 23 Oct 2003 14:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACk53-000639-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 14:21:05 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ACk53-000634-00 for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 14:21:05 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ACk53-0005LY-LY for seamoby-web-archive@ietf.org; Thu, 23 Oct 2003 14:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACk51-0007nP-Sm; Thu, 23 Oct 2003 14:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACk4e-0007iB-IR for seamoby@optimus.ietf.org; Thu, 23 Oct 2003 14:20: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 OAA10839 for ; Thu, 23 Oct 2003 14:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACk4b-00062d-00 for seamoby@ietf.org; Thu, 23 Oct 2003 14:20:37 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACk4b-00062B-00 for seamoby@ietf.org; Thu, 23 Oct 2003 14:20:37 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9NIJjc32656; Thu, 23 Oct 2003 11:19:45 -0700 X-mProtect: <200310231819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdojKZYh; Thu, 23 Oct 2003 11:19:43 PDT Message-ID: <3F981C42.1000205@iprg.nokia.com> Date: Thu, 23 Oct 2003 11:21:54 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Liebsch CC: Henrik Petander , Eunsoo Shim , Seamoby Subject: Re: [Seamoby] CARD: handling of sequence numbers References: <3F86DA14.9010202@ccrle.nec.de> <3F8D6A2B.1080407@ccrle.nec.de> <012601c3971b$5f8356e0$c96b0f8a@peace> 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 Marco Liebsch wrote: > Right, but your example assumes the successful case for sending a quick > new request where the reply to the previous request has been received. > What if a reply does not appear for some reasons after 500ms > and a MN just sends a new request. in my earlier mail, I said it doesnt matter if there was a reply or not to the earlier request. this is *another* request. > Then we can run into the timer > setting problem, > which has been indicated by Henrik, on the current AR again. no you dont. > Or we could > just > allow the AR to "overwrite" the running timer with the new request in > this case > and ignore the previous request and associated possibly outstanding > signaling > messages between ARs. there is no overwriting timers. there is no one single timer for all requests per mobile node. the way to implement re-transmission is very simple. after you send a request, you put the message in a queue. you initialize a timer, store the timer and the request in a new data structure and add this data structre to the re-transmission queue. when a reply is received, both the request and the timer are removed from the queue. if the timer expires and no reply is received, the request is sent again. the timer is reset. if request2 was sent while request1 is still in the retransmission queue, the timer on request1 is not reset. another timer is created and a new element is added to the re-transmission queue. got it? Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 24 11:06: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 LAA07149 for ; Fri, 24 Oct 2003 11:06: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 1AD3Vy-0005sI-0X for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF696J022575 for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vx-0005rj-Qq for seamoby-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07074 for ; Fri, 24 Oct 2003 11:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vu-0004ur-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vt-0004uh-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vp-0005nk-NB; Fri, 24 Oct 2003 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3V0-0005ha-6H for seamoby@optimus.ietf.org; Fri, 24 Oct 2003 11:05: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 LAA07012 for ; Fri, 24 Oct 2003 11:04:57 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Ux-0004tN-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Uw-0004tE-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:06 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF55I19156 for ; Fri, 24 Oct 2003 18:05:05 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:05:04 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:04 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:04 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Seamoby] few comments on CTP 04 Date: Fri, 24 Oct 2003 18:05:04 +0300 Message-ID: Thread-Topic: [Seamoby] few comments on CTP 04 Thread-Index: AcOYq/+qbg9yfiQTR4CKdOPCz+CNIABWsnEw To: , X-OriginalArrivalTime: 24 Oct 2003 15:05:04.0741 (UTC) FILETIME=[34972150:01C39A40] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Julian, I thought I replied earlier to this, but I guess I did not. > after a quick review, these are my questions/comments concerning > ctp-04.. >=20 > 1. p4. 3 =A7 >=20 > We call such an event as a Context Transfer Trigger >=20 > -> We call such en event a Context Transfer Trigger Actually, it should be: We call such an event a Context Transfer Trigger =20 > 2. In the second scenario, nAR may itself generates a Context Transfer > Request as a response to an internal trigger.=20 >=20 > The problem is that nAR "must" supply, the MN's previous IP address, = the > feature contexts to be transferred and a token authorizing the = transfer. >=20 > So, I guess that either we offer a way to the nAR to retrieve this = info > from MN or the nAR can't generate a Context Transfer as a response to = an > internal trigger. >=20 > Do I miss something ? I've removed the internal trigger part of the text, as you correctly = noted it would not be possible for the nAR to have the address of the previous IP address. > 3. At the last paragraph p5. we have "[1].* contexts ...the = [2]algorithm[3]" Got it. > 4. In =A7 2.3 Context Data Block, it is written: >=20 > "The Cxt-Type indicates the type of the feature context messages = itself > (such as QoS Context Request, Qos Context Transfer etc,).." >=20 > can't it be deduce from CTAR/CTD/CTR ? I think it wise to be explicit here. > 5. In =A7 2.4.1 Context Transfer Activate Request=20 >=20 > While a MN sends a CTAR to pAR, the MN includes the nAR's address and = its new IP address (if known). > If these addresses are not known, what does MN include ? (his previous = IP > address or 0.0.0.0/0::0 ?) The previous IP address. =20 > 6. I can't find "Context Transfer Framework for Seamless Mobility" :-( >=20 > Hope it helps :-) It is expired, we need to remove it from the references. Thanks for the comments, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 24 11:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07171 for ; Fri, 24 Oct 2003 11:06: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 1AD3W2-0005t6-Vd for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF6E4J022621 for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3W2-0005sm-Rl for seamoby-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:06: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 LAA07083 for ; Fri, 24 Oct 2003 11:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vv-0004v0-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vu-0004uk-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vq-0005o0-8Y; Fri, 24 Oct 2003 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3VU-0005kz-0o for seamoby@optimus.ietf.org; Fri, 24 Oct 2003 11:05: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 LAA07048 for ; Fri, 24 Oct 2003 11:05:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VR-0004tv-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VK-0004to-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:30 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF5SI01906 for ; Fri, 24 Oct 2003 18:05:28 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:05:28 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 24 Oct 2003 18:05:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:27 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Seamoby] CTP Last Call Comments Date: Fri, 24 Oct 2003 18:05:27 +0300 Message-ID: Thread-Topic: [Seamoby] CTP Last Call Comments Thread-Index: AcOXTyb8VsBAUFoiT26NN2zyxVgkbgCuU9Xw To: , X-OriginalArrivalTime: 24 Oct 2003 15:05:27.0555 (UTC) FILETIME=[42304530:01C39A40] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, Thanks for the comments. In the future, could you not make page = references, but refence text? It is confusing working with nroff text, as there are no = page numbers ... > I've seen no comments on CTP. Here's mine. Unfortunately, this = document is > not ready to go to the IESG. I'll revise, resubmit before Monday, then we should discuss what to do. > pg. 5 last paragraph: There's some kind of formatting botch here: = "[1].* > contexts." etc. Got it. > pg. 8 second paragaraph: Another formatting botch: "%Notice that the = length > of the % the context data block", etc. Got it. > pg 8, generic header diagram. I thought we agreed to remove the = generic > header diagram? It doesn't apply to all messages and is just = confusing. Got it. > pg. 9 top. An 'A' flag is mentioned, but none appears in the message. = I > think you mean 'R'. Also, in the description of the 'R' flag, it = should > indicate what reliable transfer means or point to a section in the = document > that describes this. Later in the document, we learn that this means > partially that an acknowledgement is requested. Anything else? That = should > be here. If there's nothing else, I would call it "Acknowledged" = transfer to > avoid confusion with transport reliability, and I would, in fact, make = it an > A flag. I made it an 'A' flag with the correct definition under the message = structure. > pg. 11 top. Why does this draft say something about proxy address = defense? > CTP has nothing to do with routing. That should be for the protocol = that > does local routing repair (i.e. FMIP). If something needs to be said = about > address defense, mention can be made to the role of the handover = protocol > in that. Agreed, I've deleted the text. > pg. 10 middle. The calculation of the authentication token is not = easy to > follow. It should be broken out of the text body. Also, what secret is > referred to in the 2nd line? Either point to the section where it is = located > or indicate here what it is. In fact, I would not call it a secret = since, as > we learn later on in the document, it is send over an unsecured = channel. I > would say that it is "a nounce exchanged between the AR and MN over an > unsecured channel that is used for identifying the MN and is valid for = a > limited duration, on the order of a few hundred milliseconds". I hope Charlie can update this text. > pg. 11 middle: What do the initials "PCTD only" mean? We learn in the > paragraph afterwards that predictive context transfer requires these. = These > initials should be referenced in this paragraph. I added this to the terminology section. =20 > pg. 11 A key is being sent here, but the packet is not protected. Is = this > wise? Something needs to be said here about why not, or a pointer to a > discussion in the security considerations section. This is likely to = be a > red flag for the Security ADs. If there is no protection on the = packet, then > I would suggest calling it something other than a shared secret or = key, > perhaps an "authentication nounce that is difficult to spoof but not > designed to be highly secure because the duration of validity is so = short > (on the order of a few hundred milliseconds)". Well, I actually think that this should not be sent unprotected, so I = have added text saying that when the key is present, it MUST be protected. > pg. 12 last paragraph "Sent by nAR to pAR request" -> "Sent by nAR to = pAR to > request" Got it. =20 > pg. 15 I'd like the following paragraph inserted right after the = section > header for Section 6 (Security Considerations); >=20 > At this time, the threats > to IP handover in general and context transfer in > particular are incompletely understood, particularly > on the MN to AR link, and mechanisms > for countering them are not well defined. Part of the > experimental task in preparing CTP for eventual > standards track will be to better characterize threats > to context transfer and design specific mechanisms to > counter them. This section provides some general guidelines about > security based on discussions among the Design Team > and Working Group members. >=20 > The issue of security came up in the discussion of MIPSHOP chartering, = and I > want to make sure that the IESG understands that this section is not > intended to provide a thorough discussion of CTP security. Sounds good to me. =20 > pg. 18. The referenences are out of date. [CT-REQ] should be dropped, = this > document has been dropped by the WG. > [FMIPv6] and [LLMIP] should be moved to the non-normative references = as they > are only referred to in the appendix and appendicies are not normative Done > (anyway, this is an experimental doc, so why do we need normative and > non-normative references?).=20 I've been asked by IESG members to seperate references for INFO docs, = based on the assumption that someone may need to know which references are required to really understand the document. > RFC2434 reference is not properly formatted. > [CTHC] can be removed, there is an example in this document now. If = there is > no reference to [RFC2401] please remove it, also [RFC2246]. done > pg. 19. 3rd para in Apx. A. Drop the reference to BETH. The rest of = the para > is OK. done. > pg. 20 Recent IAB work with Sally Floyd and discussion with lots of = people > including some ISPs around the issue of congestion for VoIP traffic = has > identified access networks as precisely the place where congestion = *is* > likely to occur. Core networks are typically massively overprovisioned = and > therefore never suffer congestion. So I don't agree with this = analysis. I > also don't agree that using a congestion controlled TCP or SCTP = connection > is such a burden. The routers in the access network won't start the > connection on the fly, they would have a connection open to all = routers in > their geographical vicinity and reuse it, as a result, there should be = no > startup transient.=20 James, I agree with your assessment of congestion control to a point, = but what I think we are trying to say is that CTP should not add to the = burden, as the messages should be small. Reuse of existing transport = connections should remove any latency issues. > Also, if SCTP is used, there is no issue with latency due > to retransmits for reliability.=20 SCTP still retransmits upto 4 times. This will cause a problem with latency. What we really want to do is set a timer so that if a message is not recieved within a set amount of time, we can assume that it is lost. =20 > DCCP could also be used, though it is > primarily intented for media. Of course, if context is dropped due to > congestion the handover optimization will fail, but that is another = issue. I > believe this section is likely to receive intensive IESG criticism. > Something could be said about this issue being for further study. > Alternatively (and in my opinion, a better choices) is to remove the > section. I will take your suggestion and delete it. > pg. 20 Please remove the pseudo section headers from Appendix C or use > section numbering (e.g. C.1, C.2, etc.). Done. > Also: "In addtion, any application-specific...." -> "Any application > specific..." > > pg. 21 "moderately utilized" -> "heavily utilized" Done > pg. 21. The section on MLD state machine interactions is somewhat hard = to > read (yes, I know I wrote it). I'd suggest the following rewrite: >=20 > No changes are requried in the MLD state machine. >=20 > Upon receipt of a CTP Context Data Block for MLD, the=20 > state machne takes > the following actions: >=20 > - If the router is in the No Listeners present state=20 > on the wireless > interface on which the Subnet Prefix field from > the Context Data Block is advertised, it=20 > transitions into the > Listeners Present state for the > Subscribed IPv6 Multicast Address field in the Context Data > Block. This transition is exactly > the same as if the router had received a Report message. >=20 > - If the router is in the Listeners present state on=20 > that interface, > it remains in that state but restarts > the timer, as if it had received a Report message. >=20 > If more than one MLD router is on the link, a router=20 > receiving an MLD > Context Data Block SHOULD > send the block to the other routers on the link. The=20 > router MAY instead > send a proxy MLD Report > message on the wireless interface which advertises the=20 > Subnet Prefix > field from the Context Data Block > if wireless bandwidth is not an issue. Since MLD routers=20 > do not keep > track of which nodes are listening to > munticast addresses, only whether a particular multicast=20 > address is > being listened to, proxying the > subscription should cause no difficulty. Done, with typos corrected. thanks, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 24 11:06: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 LAA07169 for ; Fri, 24 Oct 2003 11:06: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 1AD3Vx-0005rt-SH for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF69rl022548 for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vx-0005rb-Lg for seamoby-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07077 for ; Fri, 24 Oct 2003 11:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vu-0004uy-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vt-0004um-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vq-0005o8-Od; Fri, 24 Oct 2003 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3VX-0005lW-91 for seamoby@optimus.ietf.org; Fri, 24 Oct 2003 11:05: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 LAA07057 for ; Fri, 24 Oct 2003 11:05:30 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VU-0004uH-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VT-0004uE-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:39 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF5bI19733 for ; Fri, 24 Oct 2003 18:05:38 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:05:33 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:32 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Seamoby] Review comments from Basavaraj Patel on CTP Date: Fri, 24 Oct 2003 18:05:32 +0300 Message-ID: Thread-Topic: [Seamoby] Review comments from Basavaraj Patel on CTP Thread-Index: AcOYHGmQqAgF3ko3TeepfEeQYtNhdQB8WVAw To: , X-OriginalArrivalTime: 24 Oct 2003 15:05:32.0853 (UTC) FILETIME=[4558AE50:01C39A40] 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 > Editorial: >=20 > 1. Can the problem description text in the Introduction be a > subsection? The current Into section begins with a reference to a > problem statement described in RFC3374.=20 > Nit: The open quote "Problem... in Section 1 is not terminated. Done =20 > 2. s/This section provides a protocol overview/This section provides = the > CT protocol overview. Done > 3. Section 2: (References) > "In response to a CT-Activate Request message or to the CT trigger, = pAR > predictively transmits a Context Transfer Data (CTD) message that > contains feature contexts. This message, described in Section > 2.4.2" > Incorrect reference. >=20 > "In the second scenario, pAR receives a Context Transfer Request = (CT > Request) described in Section 2.4.5, message from nAR." > Incorrect reference; Should be 2.4.6 >=20 > Nit: Check all references Done =20 > 4. Section 2: > "[1].* contexts, pAR verifies authorization token before = transmitting > the [2]algorithm [3] When context transfer takes place without the > nAR requesting it (scenario one above), nAR requires MN to present > its authorization token" > =20 > I could not make out what this statement says. I am not even sure > if the authors can understand it. Done, I've deleted it, based upon reorganizing some of the text > 5. Section 2: > Can you create subsections for scenarios 1 and 2? Would make it > easier to reference. done. > 6. s/Additially/Additionally Done > 7. Section 2.3 > a. Would be good to describe each field separately. Goes for all > subsequent sections where message formats are described. > CXT Type -=20 > Length -=20 > P bit - Will do > b. "When the presence vector is in use, the Presentation Vector is > interpreted.." > What is this Presentation vector? (Typo) fixed > c. Last paragraph has % chars done > 8. Sec 2.4.1 > "If an acknowledgement for this message is needed, the MN sets the > A flag to 1, " > > Missing "A" flag in CTAR. Fixed, it was listed as R =20 > 9. Sec 2.4.2 > Describe the fields. Will do > 10. Is there a need for specifying the status codes used in CTDR and = CTAA?=20 Will do. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Fri Oct 24 11:58: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 LAA07170 for ; Fri, 24 Oct 2003 11:06: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 1AD3Vx-0005s9-Vo for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF69OV022562 for seamoby-archive@odin.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vx-0005rh-QH for seamoby-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07079 for ; Fri, 24 Oct 2003 11:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vu-0004uz-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3Vu-0004ui-00 for seamoby-web-archive@ietf.org; Fri, 24 Oct 2003 11:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vr-0005oJ-8n; Fri, 24 Oct 2003 11:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Vc-0005m7-3c for seamoby@optimus.ietf.org; Fri, 24 Oct 2003 11:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07060 for ; Fri, 24 Oct 2003 11:05:35 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VZ-0004uQ-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:45 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3VY-0004uM-00 for seamoby@ietf.org; Fri, 24 Oct 2003 11:05:44 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF5gI19800 for ; Fri, 24 Oct 2003 18:05:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:05:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 24 Oct 2003 18:05:35 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:05:35 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Seamoby] Comments of Antti Tuominen on CTP draft Date: Fri, 24 Oct 2003 18:05:34 +0300 Message-ID: Thread-Topic: [Seamoby] Comments of Antti Tuominen on CTP draft Thread-Index: AcOYHKICcuhaPqRgQB+YIzwDF+PURwB9umiw To: , X-OriginalArrivalTime: 24 Oct 2003 15:05:35.0074 (UTC) FILETIME=[46AB9420:01C39A40] Content-Transfer-Encoding: quoted-printable Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > Review comments > --------------- >=20 > 1. In 2.3 it is specified that length is in 8 octet units. However, > if presence vector and data are not present we have 4 octet > message. Also context data may not 64bit align (especially when a > presence vector is used). So it seems to me that you either have > to have 1 octet as the unit (which of course limits length to 255 > bytes) or do padding. good point. I've fixed this. > 2. Also in 2.3 you use presence vector and presentation vector, so I > guess s/Presentation Vector/presence vector/. Got it, thanks. > 3. In 2.4.1, what are Type=3DAuth-Token and Type Len? No description, > seem redundant. Same thing in 2.4.3 (also Algorithm) and 2.4.6. > Old remnants? Yes, deleted tye type=3Dx part, and made the reply field a full 64 bits. > 4. Example in Appendix C is wrong. First, you do not "subscribe" to > all-nodes. Node never sends MLD Report or Done for all-nodes. > Second, you don't put Routing Header in MLD messages, but Router > Alert Hop-by-hop option which is just 6 bytes (or 8 padded). In > consequence, all time and space overhead calculations are > incorrect. got it. thanks, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Mon Oct 27 03:58:24 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 DAA01936 for ; Mon, 27 Oct 2003 03:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3CP-0000JJ-9X for seamoby-archive@odin.ietf.org; Mon, 27 Oct 2003 03:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R8w5Yt001187 for seamoby-archive@odin.ietf.org; Mon, 27 Oct 2003 03:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3CO-0000J4-Qx for seamoby-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 03:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01908 for ; Mon, 27 Oct 2003 03:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3CL-0001JW-00 for seamoby-web-archive@ietf.org; Mon, 27 Oct 2003 03:58:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE3CL-0001JS-00 for seamoby-web-archive@ietf.org; Mon, 27 Oct 2003 03:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3CL-0000HB-NB; Mon, 27 Oct 2003 03:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3CA-0000Fz-CY for seamoby@optimus.ietf.org; Mon, 27 Oct 2003 03:57:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01899 for ; Mon, 27 Oct 2003 03:57:39 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3C7-0001JJ-00 for seamoby@ietf.org; Mon, 27 Oct 2003 03:57:47 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AE3C7-0001JE-00 for seamoby@ietf.org; Mon, 27 Oct 2003 03:57:47 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9R8vlI07634 for ; Mon, 27 Oct 2003 10:57:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 Oct 2003 10:57:49 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 10:57:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 10:57:47 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 27 Oct 2003 10:57:46 +0200 Message-ID: Thread-Topic: [Seamoby] Issue: Variable Length Context Blocks for CTP Thread-Index: AcNusxZHMe5hH8CzTE+wBYgknNSOvgttGM/A To: X-OriginalArrivalTime: 27 Oct 2003 08:57:47.0351 (UTC) FILETIME=[64858670:01C39C68] Content-Transfer-Encoding: quoted-printable Subject: [Seamoby] Updated 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I've updated CTP. For those who are anxious to see it, before it is announced, it can be found from here: http://www-nrc.nokia.com/sua/draft-ietf-seamoby-ctp-05.txt thanks, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 29 04:31:16 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 EAA29930 for ; Wed, 29 Oct 2003 04:31:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmfG-0008CF-Mt for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 04:30:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9UsV8031501 for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 04:30:54 -0500 Received: from [218.18.28.94] (helo=seamoby-web-archive) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmfE-0008AQ-K7 for seamoby-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:30:54 -0500 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: SONY D31 =?GB2312?B?vfbK2zUzMDDUqg==?= 17:28:47:719 To: seamoby-web-archive@optimus.ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkppeng@szjkp.com Date: Wed, 29 Oct 2003 17:29:53 +0800 X-Priority: 4 Message-Id:

SONY D31 仅售5300元
带自动跟踪功能 AT

彭 生
电话:13714660163/0755-83659258
E-mail:jkppeng@szjkp.com
http://www.szjkp.com

深圳市金凯鹏电子有限公司



From exim@www1.ietf.org Wed Oct 29 04:51:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00797 for ; Wed, 29 Oct 2003 04:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmyy-0002MT-Dn for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 04:51:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9pGe9009071 for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 04:51:16 -0500 Received: from [218.18.28.94] (helo=seamoby-web-archive) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmyw-0002Lm-U9 for seamoby-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:51:16 -0500 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: SONY D31 =?GB2312?B?vfbK2zUzMDDUqg==?= 17:49:44:646 To: seamoby-web-archive@optimus.ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkppeng@szjkp.com Date: Wed, 29 Oct 2003 17:50:16 +0800 X-Priority: 4 Message-Id:

SONY D31 仅售5300元
带自动跟踪功能 AT

彭 生
电话:13714660163/0755-83659258
E-mail:jkppeng@szjkp.com
http://www.szjkp.com

深圳市金凯鹏电子有限公司



From exim@www1.ietf.org Wed Oct 29 11:34:24 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 LAA17749 for ; Wed, 29 Oct 2003 11:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtGm-0004qR-Ca for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 11:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGY4wb018617 for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 11:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtGm-0004qC-8z for seamoby-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 11:34:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17738 for ; Wed, 29 Oct 2003 11:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtGl-0004Ud-00 for seamoby-web-archive@ietf.org; Wed, 29 Oct 2003 11:34:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEtGk-0004UZ-00 for seamoby-web-archive@ietf.org; Wed, 29 Oct 2003 11:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtGj-0004pX-FR; Wed, 29 Oct 2003 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtG5-0004nC-2B for seamoby@optimus.ietf.org; Wed, 29 Oct 2003 11:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17731 for ; Wed, 29 Oct 2003 11:33:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtG4-0004UP-00 for seamoby@ietf.org; Wed, 29 Oct 2003 11:33:20 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AEtG3-0004UD-00 for seamoby@ietf.org; Wed, 29 Oct 2003 11:33:19 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 18BD033BA6; Wed, 29 Oct 2003 17:23:27 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id C6EC73F46F; Wed, 29 Oct 2003 17:23:17 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003102917231706566 ; Wed, 29 Oct 2003 17:23:17 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 951F83F546; Wed, 29 Oct 2003 17:21:20 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AEt3W-000CgY-Ee; Wed, 29 Oct 2003 17:20:22 +0100 Date: Wed, 29 Oct 2003 17:20:22 +0100 From: Julien Bournelle To: john.loughney@nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] few comments on CTP 04 Message-ID: <20031029162022.GC46942@ipv6-5.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA17732 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > > 5. In =A7 2.4.1 Context Transfer Activate Request=20 > >=20 > > While a MN sends a CTAR to pAR, the MN includes the nAR's address and= its new IP address (if known). > > If these addresses are not known, what does MN include ? (his previou= s IP > > address or 0.0.0.0/0::0 ?) >=20 > The previous IP address. in the definition of CTD message (=A7 2.5.3), the header contains a field previous Co@ and a field new Co@ if it is a predictive CTD. What do we do if this address is not known ? - previous address (already present) - null - add a flag in reserved - others ? thanks, --=20 julien.bournelle@int-evry.fr _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Wed Oct 29 22:16:45 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 WAA22457 for ; Wed, 29 Oct 2003 22:16:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3IO-0005km-Ik for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 22:16:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U3GOFO022110 for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 22:16:24 -0500 Received: from [218.18.28.94] (helo=seamoby-web-archive) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3IN-0005ja-8u for seamoby-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 22:16:23 -0500 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?vsWzydDCtv7K1rHKvMexvrXnxNQyMDAw1KrG8A==?= 11:15:2: To: seamoby-web-archive@optimus.ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkppeng@szjkp.com Date: Thu, 30 Oct 2003 11:15:22 +0800 X-Priority: 4 Message-Id:

九成新二手笔记本电脑2000元起

 COMPAQ 1580DT 2700元
 COMPAQ 1926PII333/64M/12.1/集成MODEM/10M/CD/FD/ 3100元
 COMPAQ 1500CC400M/64M/CD/FD/XIRCOM 56K MODEM -100M网卡/12.1 2300元
 DELL CPI PⅡ266/64M/光软互换/网卡/MODEM/13.3TFT/ 2600元
 IBM 2611 41D Pmmx300M/64M/CD/FD/内置MODEM/10M/12.1TFT/ 2250元
 IBM 380Z PII233/32M/CD/FD/12.1TFT/ 2400元
 IBM 2600 315ED Pmmx166M/32M/CD/33.6K/12.1TFT 1600元
 IBM 380XD Pmmx 233/32M/12.1TFT/56K/10-100M/CD/FD 2150元
 IBM TP600 PII300/64M/13.3TFT/CD/FD/10M/集成MODEM 3300元
 TOSHIBA 2770X DVD PIII650/64M/8XDVD/14.1TFT 5000元
 TOSHIBA 4000CDT PII233/32M/12.1TFT/CD/FD/10网卡 2560元
 TOSHIBA PII266/64M/CD/FD/12.1TFT/联想四合一卡 2700元
 TOSHIBA 300CDT Pmmx166/32M/CD/FD/33.6k/10M//12.1TFT 1600元
 TOSHIBA TECRA8000 PⅡ266/64M/光软互换/三合一卡/13.3TFT 2600元
 TOSHIBA K6II300/64M/12.1TFT/CD/FD/10M网卡/12.1TFT 2300元
 TOSHIBA C300/64M/13.3TFT/CD/FD/56KMODEM/10M网卡 2500元
 TOSHIBA 330CDT Pmmx266/32M/CD/FD/33.6MODEM+10M/12.1TFT 2250元

彭生
电话:0755-83959258
手机:13714660163
E-mail:jkppeng@szjkp.com
http://www.szjkp.com

深圳市金凯鹏电子有限公司



From exim@www1.ietf.org Wed Oct 29 22:33: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 WAA22895 for ; Wed, 29 Oct 2003 22:33:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3Yp-00078G-Ic for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 22:33:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U3XNHs027410 for seamoby-archive@odin.ietf.org; Wed, 29 Oct 2003 22:33:23 -0500 Received: from [218.18.28.94] (helo=seamoby-web-archive) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3Yo-000709-9u for seamoby-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 22:33:23 -0500 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?NS031duz9srbY2lzY2+y+sa3ISEh?= 11:32:13:892 To: seamoby-web-archive@optimus.ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkppeng@szjkp.com Date: Thu, 30 Oct 2003 11:32:21 +0800 X-Priority: 4 Message-Id:

你好:

    我们有工程遗留的CISCO 防火墙出售

防火墙 CISCO PIX-525-UR-BUN 48000元
防火墙 CISCO PIX-520-128-CH 14000元


彭生
Email：jkppeng@szjkp.com
电话：0755-83659258
手机：13510763661
Q Q：241915630

深圳市金凯鹏电子有限公司



From exim@www1.ietf.org Thu Oct 30 03:40: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 DAA13983 for ; Thu, 30 Oct 2003 03:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8Lg-0007J1-69 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 03:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U8e7Zn028069 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 03:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8Le-0007IS-Uy for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 03:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13973 for ; Thu, 30 Oct 2003 03:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF8Lc-0007WB-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 03:40:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF8Lc-0007W8-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 03:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8La-0007HS-Eo; Thu, 30 Oct 2003 03:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8Kb-0007Bz-Bx for seamoby@optimus.ietf.org; Thu, 30 Oct 2003 03:39:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13941 for ; Thu, 30 Oct 2003 03:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF8KY-0007V1-00 for seamoby@ietf.org; Thu, 30 Oct 2003 03:38:58 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1AF8KY-0007Ux-00 for seamoby@ietf.org; Thu, 30 Oct 2003 03:38:58 -0500 Received: from inwind.it ([193.204.86.191]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h9U8cqN24365 for ; Thu, 30 Oct 2003 09:38:52 +0100 (CET) Date: Thu, 30 Oct 2003 09:37:34 +0100 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4F041CF1-0AB4-11D8-A1E4-000A95946ED6@inwind.it> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby is the acronymous of .... 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'm interesting to know which is the meaning of Seamoby....If there is one .... Seamoby is the acronymous of..... Thanx Ivano ======================================================== "Be liberal in what you accept, and conservative in what you send." Jon Postel _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 30 03:41:23 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 DAA14047 for ; Thu, 30 Oct 2003 03:41:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8MY-0007TV-NB for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 03:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U8f2ep028727 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 03:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8MY-0007Sr-CD for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 03:41:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14011 for ; Thu, 30 Oct 2003 03:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF8MV-0007Wq-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 03:40:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF8MV-0007Wl-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 03:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8MW-0007Ot-Ux; Thu, 30 Oct 2003 03:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF8MJ-0007OB-Go for seamoby@optimus.ietf.org; Thu, 30 Oct 2003 03:40:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13999 for ; Thu, 30 Oct 2003 03:40:37 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF8MG-0007Wd-00 for seamoby@ietf.org; Thu, 30 Oct 2003 03:40:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AF8MG-0007Wa-00 for seamoby@ietf.org; Thu, 30 Oct 2003 03:40:44 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9U8eiG12738 for ; Thu, 30 Oct 2003 10:40:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Oct 2003 10:40:42 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 30 Oct 2003 10:40:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Seamoby is the acronymous of .... Date: Thu, 30 Oct 2003 10:40:42 +0200 Message-ID: Thread-Topic: [Seamoby] Seamoby is the acronymous of .... Thread-Index: AcOewXFSKt955wjzQd2e3N9i6WX67QAAAhDw To: , X-OriginalArrivalTime: 30 Oct 2003 08:40:42.0854 (UTC) FILETIME=[811CF060:01C39EC1] 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 Seamoby =3D Seamless Mobility John > -----Original Message----- > From: seamoby-admin@ietf.org=20 > [mailto:seamoby-admin@ietf.org]On Behalf Of > ext Ivano De Luca > Sent: 30 October, 2003 10:38 > To: seamoby@ietf.org > Subject: [Seamoby] Seamoby is the acronymous of .... >=20 >=20 > I'm interesting to know which is the meaning of Seamoby....If=20 > there is=20 > one .... >=20 > Seamoby is the acronymous of..... >=20 >=20 > Thanx >=20 >=20 > Ivano >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > "Be liberal in what you accept, and conservative in what you send." > Jon Postel >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby >=20 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 30 04:28: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 EAA14931 for ; Thu, 30 Oct 2003 04:28:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF96I-0004Eu-DG for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 04:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U9SIrG016290 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 04:28:18 -0500 Received: from [218.18.28.94] (helo=seamoby-web-archive) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF96G-00045z-LT for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 04:28:17 -0500 From: =?GB2312?B?ye7b2srQvfC/rcX0tefX09PQz965q8u+?= Subject: =?GB2312?B?v/G1+DMwMDAw1KohISE1MIW8tcjA69fTz9TKvsb3?= 17:24: To: seamoby-web-archive@optimus.ietf.org Content-Type: text/html;charset="GB2312" Reply-To: jkppeng@szjkp.com Date: Thu, 30 Oct 2003 17:27:15 +0800 X-Priority: 4 Message-Id:

50吋等离子显示器PDP-501Mx,原装日本产
先鋒公司最新推出的50吋寬萤幕等离子顯示器，厚度10cm，可以掛在牆壁上。分辨率为98万像素，重的约42kg(约为同幅面传统彩色显像管重量的三分之一至二分之一)，适合工业应用和装备Hi－end级家庭影院， PDP-501MX 的解析度達到1280（水平）×768（垂直），三原色各有256階，共可表現1677萬色，亮度則有350米燭光（白色峰值），垂直、水平的視角皆大於160度。PDP-501MX不但解析度高，而且還不容易周邊背景光源的影響。此外，PDP-501MX不只可以輸入色差、RGB、同軸Video與S-video等等信號，可以完全對應現行DVD的輸出要求，更可怕的是它還能夠對應未來（2006年將實施）的數位電視系統，其中不論是HDTV或是SDTV，管它是1080i、720p、480p還是480i，無論是Y/B-Y/R-Y、Y/PB/PR還是RGB，本機都可以照吃不誤！當然，它還可以當成電腦顯示器來用（XGA全對應、SXGA壓縮對應）。

原价:66000元
现价:38000元

联系人：彭慧坚
电话：0755-83659258
手机：13714660163
传真：+86 755 83628511
Q Q：241915630
Email：jkppeng@szjkp.com

深圳市金凯鹏电子有限公司



From exim@www1.ietf.org Thu Oct 30 05:39:21 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 FAA16550 for ; Thu, 30 Oct 2003 05:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFACk-0003CM-F4 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 05:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAd2AL012290 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 05:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFACk-0003C9-6M for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:39:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16547 for ; Thu, 30 Oct 2003 05:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFACg-0000zT-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 05:38:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFACg-0000zQ-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 05:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFACi-0003BJ-Rd; Thu, 30 Oct 2003 05:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFACD-0003AC-02 for seamoby@optimus.ietf.org; Thu, 30 Oct 2003 05:38:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16544 for ; Thu, 30 Oct 2003 05:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAC9-0000zN-00 for seamoby@ietf.org; Thu, 30 Oct 2003 05:38:25 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx with esmtp (Exim 4.12) id 1AFAC8-0000zK-00 for seamoby@ietf.org; Thu, 30 Oct 2003 05:38:24 -0500 Received: from inwind.it ([193.204.86.191]) by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h9UAcFN00545 for ; Thu, 30 Oct 2003 11:38:16 +0100 (CET) Date: Thu, 30 Oct 2003 11:36:39 +0100 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ivano De Luca To: seamoby@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Seamoby] AR discoveres ARs 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...a question How can an AR discover the ARs' IP address that are in their range? Broadcast = no, Multicast = ? Other = ? Please answer ...... Thanx Ivano ======================================================== "Be liberal in what you accept, and conservative in what you send." Jon Postel _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From exim@www1.ietf.org Thu Oct 30 11:53:49 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 LAA00342 for ; Thu, 30 Oct 2003 11:53:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFG37-00032B-0x for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 11:53:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UGrTXP011664 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 11:53:29 -0500 Received: from [219.234.29.195] (helo=rr.com) by optimus.ietf.org with smtp (Exim 4.20) id 1AFG35-0002xP-V3 for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 11:53:28 -0500 From: "dfs" Subject: ertert To: seamoby-web-archive@optimus.ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: dsfsd@eel.com Date: Fri, 31 Oct 2003 00:52:41 +0800 X-Priority: 3 X-Mailer: FoxMail 4.2 Message-Id: tertetet From exim@www1.ietf.org Thu Oct 30 14:19:24 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 OAA05458 for ; Thu, 30 Oct 2003 14:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIJz-0007L4-Sa for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 14:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UJJ3XG028204 for seamoby-archive@odin.ietf.org; Thu, 30 Oct 2003 14:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIJz-0007Kp-Nf for seamoby-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 14:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05455 for ; Thu, 30 Oct 2003 14:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIJx-0000Ql-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 14:19:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFIJw-0000Qh-00 for seamoby-web-archive@ietf.org; Thu, 30 Oct 2003 14:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIJx-0007K8-2p; Thu, 30 Oct 2003 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIJk-0007J7-Dn for seamoby@optimus.ietf.org; Thu, 30 Oct 2003 14:18:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05443 for ; Thu, 30 Oct 2003 14:18:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIJh-0000QN-00 for seamoby@ietf.org; Thu, 30 Oct 2003 14:18:45 -0500 Received: from bay1-f60.bay1.hotmail.com ([65.54.245.60] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AFIJh-0000Ps-00 for seamoby@ietf.org; Thu, 30 Oct 2003 14:18:45 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Oct 2003 11:18:14 -0800 Received: from 66.46.217.25 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 30 Oct 2003 19:18:14 GMT X-Originating-IP: [66.46.217.25] X-Originating-Email: [kalatwal@hotmail.com] From: "K S A" To: john.loughney@nokia.com, seamoby@ietf.org Subject: Re: [Seamoby] Updated CTP Date: Thu, 30 Oct 2003 19:18:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2003 19:18:14.0703 (UTC) FILETIME=[90FDE3F0:01C39F1A] 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: , After a cursory examination, I would have to agree with jak's comments. But, I will review it in detail and have a more thoughtful reply by Tuesday. - Kulwinder. >Hi all, > >I've updated CTP. For those who are anxious to see it, before >it is announced, it can be found from here: > >http://www-nrc.nokia.com/sua/draft-ietf-seamoby-ctp-05.txt > >thanks, >John > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby