From exim@www1.ietf.org  Tue Jul  1 00:11:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00714
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 00:11:42 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h614BDa01814
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 00:11:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XCU3-0000TB-Dq
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 00:11: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 AAA00670
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 00:11:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XCU0-0006sY-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 00:11:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XCTu-0006sV-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 00:11:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XCTv-0000Sm-Ex; Tue, 01 Jul 2003 00:11:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XCT4-0000S9-GF
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 00:10: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 AAA00618
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 00:10:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XCT1-0006rn-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 00:10:07 -0400
Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XCSr-0006rd-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 00:09:57 -0400
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59)
	id <N843YV36>; Tue, 1 Jul 2003 00:08:55 -0400
Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BB83@ftmail.lab.flarion.com>
From: Soliman Hesham <H.Soliman@flarion.com>
To: "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        "John Loughney (NRC/Helsinki)" <john.loughney@nokia.com>
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Issue 12: Inclusion of MN's nCoA in CTAR or CTD
Date: Tue, 1 Jul 2003 00:08:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>



 > Soliman Hesham wrote:
 > 
 > > The MN's identifier should not be tied to its
 > > IP address or, as you correctly point out, its
 > > MAC address. If the MN needs to be identified,
 > > then a more abstract identifier should be used.
 > > For example, a NAI, IMSI, TMSI, FQDN (?) ...etc.
 > 
 > I don't think this is true.  I think that the means
 > by which the identification is carried out, should
 > be the same as the means used for the original
 > purpose of the particular protocol.  For instance,
 > if a security association is based on IP address,
 > then the identification ought to be by IP address.
 > If PAR knows the mobile node by its MAC address,
 > then that would be useful.  I think since we're in
 > the IETF, the IP address will be very handy.

=> Not sure what the last sentence means. But I
agree that the identifier depends on the context.
However, since every thing changes when you move
(IP address, MAC address potentially), these addresses
cannot be used in the general sense as identifiers.
E.g. what would you use to re-authenticate with AAA?

 > 
 > > Neither the IP address nor the MAC address are
 > > useful as generic identifiers.
 > 
 > All we have to do is identify the mobile node for
 > the purpose of context transfer, not for generic
 > purposes.  

=> Agreed. One concrete case is AAA. We certainly
need a more abstract identifier for that.

But I don't understand why this protocol needs
to pick an identifier anyway. Each context could
carry its own identifier if you want things to be
very generic.


Hesham

In fact, the word "identify" is tricky
 > enough.  Surely you won't suggest that every context
 > tranfer requires an identity verification with some
 > certificate authority...?
 > 
 > Regarding the question:
 > 
 > > Do we need to have a stable Session ID of some sort that is used?
 > 
 > I sincerely hope this approach is not taken.  It amounts
 > to excess baggage and almost a license for bloat (if not
 > a mandate for bloat).
 > 
 > Also, please remember that contexts come and go, but the
 > mobile node stays "the same".  Would you need a session
 > ID per context?  Yecch!  What, exactly, is the session?
 > 
 > Regards,
 > Charlie P.
 > 
 > 
 > 
 > >  > Hi James,
 > >  >
 > >  > > Issue 12 questions including the MN's nCoA in CTAR or CTD.
 > >  > If MN has not yet
 > >  > > completed DAD, then the address is not confirmed and it
 > >  > may not be if there
 > >  > > is a conflict (note however that exactly how to quickly
 > >  > confirm a nCoA is
 > >  > > currently a topic of heavy discussion on the MIP list, RFC
 > >  > 2462 DAD may not
 > >  > > be done). There seems to be an assumption built in that
 > >  > predictive handover
 > >  > > is occuring, and the MN will know its CoA prior to moving
 > >  > to the new link
 > >  > > or, if not predictive, then immediately on coming on link.
 > >  > >
 > >  > > Was this intended as an identifier for the MN on the new
 > >  > link? If so,
 > >  > > wouldn't a more stable identifier be the MN's link 
 > layer address?
 > >  > >
 > >  > > And what is the purpoe of old CoA?
 > >  >
 > >  > Thinking about this a bit more - this is a tricky issue.
 > >  > link layer address
 > >  > may not be good, in the case of vertical handovers.  Also,
 > >  > what to do with
 > >  > IPv4 & possibly NATed addresses?
 > >  >
 > >  > Do we need to have a stable Session ID of some sort 
 > that is used?
 > >  >
 > >  > John
 > >  >
 > >  > _______________________________________________
 > >  > 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  Tue Jul  1 13:48:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08182
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:00 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIXkL05528
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:33:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vxxk-0008E0-PQ
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:28:44 -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 OAA10138
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:28: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 19Vxx1-0007fR-KT; Fri, 27 Jun 2003 14:27:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuSO-0002P9-RZ
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:44:08 -0400
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22550
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 07:36:54 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5RBas909236
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 14:36:54 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T63161ac0c1ac158f24078@esvir04nok.ntc.nokia.com>;
 Fri, 27 Jun 2003 14:36:54 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:36:52 +0300
Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:36:51 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:36:51 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jun 2003 14:36:50 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EFBB@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] CT Design Reviews from Review Board
Thread-Index: AcM0nsDnLosgyNSAQ0S5Icl//SCWHQIAXxTw
To: <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
X-OriginalArrivalTime: 27 Jun 2003 11:36:51.0646 (UTC) FILETIME=[66F7DDE0:01C33CA0]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] Issue10: Support for ESP
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

My text proposed for issue 3 should solve Issue10: Support for ESP.

John

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08321
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:07 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIRpw28646
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:27:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxsH-0005cp-Sh
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:06 -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 OAA09465
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:23:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxrU-00052X-Sx; Fri, 27 Jun 2003 14:22:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuSQ-0002NW-NR
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:44:10 -0400
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22519
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 07:34:04 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5RBY4906151
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 14:34:04 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6316182a48ac158f24078@esvir04nok.ntc.nokia.com> for <seamoby@ietf.org>;
 Fri, 27 Jun 2003 14:34:04 +0300
Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:34:03 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:34:03 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jun 2003 14:34:02 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EFBA@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Candidate for New WG Draft
Thread-Index: AcM8g1WF8r6/1Q4JSrmn6SKuMzkRKAAHJWIQ
To: <seamoby@ietf.org>
X-OriginalArrivalTime: 27 Jun 2003 11:34:03.0454 (UTC) FILETIME=[02B7CDE0:01C33CA0]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] Issue3: Specifying IPsec between 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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

In order to close this issue, I have added the following text.

John

6.1. IPsec Considerations

Access Routers MUST implement IPsec ESP [ESP] in transport mode with =
non-null encryption and authentication algorithms to provide per-packet =
authentication, integrity protection and confidentiality, and MUST =
implement the replay protection mechanisms of IPsec. In those scenarios =
where IP layer protection is needed, ESP in tunnel mode SHOULD be used. =
Non-null encryption should be used when using IPSec ESP.=09


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08623
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:33 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIXlZ05566
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:33:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy2d-0001Rg-6N
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:33:47 -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 OAA10961
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:33:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy26-0001AK-Up; Fri, 27 Jun 2003 14:33:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vvct-0006ZJ-Cu
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 11:59:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05420
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 11:59:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Vvcs-00049T-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 11:59:02 -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 19Vvch-00049G-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 11:58:51 -0400
Message-ID: <00c201c33cc4$3eeef490$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <john.loughney@nokia.com>, <charliep@iprg.nokia.com>
Cc: <seamoby@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB32063658EFB7@esebe023.ntc.nokia.com>
Subject: Re: [Seamoby] Issue 2: CTAR Response Needed
Date: Fri, 27 Jun 2003 08:53:26 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

OK.

Do you think it might make sense to put a flag in CTAR so the MN can say
whether or not it wants to receive a reply? I believe there is such in  BU
for MIP.  That way, if only header compression were being done, the flag
could be off, whereas if something like QoS were done that needed a reply,
the flag could be on.

            jak

----- Original Message ----- 
From: <john.loughney@nokia.com>
To: <kempf@docomolabs-usa.com>; <charliep@iprg.nokia.com>
Cc: <seamoby@ietf.org>
Sent: Friday, June 27, 2003 4:00 AM
Subject: RE: [Seamoby] Issue 2: CTAR Response Needed


> Hi all,
>
> I am adding this message to CTP.  My assumption is that this is purely an
informative message, which can be disregarded by the MN if the MN has other
information.
>
> br,
> John
>
> 2.4.2 Context Transfer Activate Acknowledge (CTAA) Message
>
> This is an informative message sent nAR to the MN to acknowledge a CTAR
message. Acknowledgement is optional, since the MN may have already moved
and may not receive the reply. This message may include a list of FPT
(feature profile types) that were not transferred successfully.
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Message Type           |reserve|       Length          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |             Mobile Node's Previous IP Address                 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                   Previous Router IP Address                  |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Type=Auth-Token| Type Len      |        Replay                 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                    MN Authorization Token                     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                Failed Context Type (if present)               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |            Next Failed Context Type (if present)              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                           ........                            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The message data for CTAR is the Mobile Node's Previous IP Address,
Previous Router's IP address, MN Authorization Token, followed by a list of
context types that were not successfully transferred.  If no context types
are specified, then all contexts for the mobile node are considered
successfully transferred.
>
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08590
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:32 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIOCC22903
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:24:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxtL-0005wQ-49
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:24:11 -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 OAA09466
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:23:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxrP-0004ne-G3; Fri, 27 Jun 2003 14:22:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuO0-0002P9-M3
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:39: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 KAA29255
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 10:19:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Vu4F-0002vA-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 10:19:11 -0400
Received: from herculanum.int-evry.fr ([157.159.11.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Vu44-0002uq-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 10:19:00 -0400
Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20])
	by herculanum.int-evry.fr (Postfix) with ESMTP
	id 93E4733B26; Fri, 27 Jun 2003 16:18:09 +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 A09D73F414; Fri, 27 Jun 2003 16:30:50 +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 M2003062716180927772
 ; Fri, 27 Jun 2003 16:18:09 +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 6AEBA3F414; Fri, 27 Jun 2003 16:30:50 +0200 (CEST)
Received: from jb by ipv6-5.int-evry.fr with local (Exim id 19Vu1r-000B3R-00; Fri, 27 Jun 2003 16:16:43 +0200
Date: Fri, 27 Jun 2003 16:16:43 +0200
From: Julien Bournelle <Julien.Bournelle@int-evry.fr>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Issue 2: CTAR Response Needed
Message-ID: <20030627141643.GP39327@ipv6-5.int-evry.fr>
References: <030d01c33c25$eaba72d0$636015ac@dclkempt40> <3EFB649F.6B278E5@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EFB649F.6B278E5@iprg.nokia.com>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>


Hi,

please see my comment inline,

On Thu, Jun 26, 2003 at 02:24:48PM -0700, Charles E. Perkins wrote:
> - For security, I think that the answer is still
>   not clear, and it might depend on the reason why
>   the security context could not be transferred.
>   But I did not feel comfortable saying that we
>   should automatically inform prospective security
>   clients that their credentials are invalid.

If we think of IPsec SA, I think that there are some cases where it
could be necessay to give information to the MN before the handover.
Let consider this scenario:

  MN ------------ pAR
		   |
		   |
		  nAR

If MN shares an IPsec SA with pAR and wants to perform an handover with
nAR, it may be possible to send the IPsec SA information from pAR to
nAR. However some collision may occur (e.g. SPI). In this case, the nAR
could give to the MN via pAR the new SPI to use.


> 
> Perhaps the right answer is that, once a context is
> clearly identified as needed a CTAR response, at that
> time we could create the protocol message.  Then, it
> would be a matter for the feature profile to specify
> whether the particular context type needed to allow
> for CTAR response or not.
> 
> If that time arrives, then someone will have to make
> the further determination about whether only negative
> responses are needed, or whether responses are needed
> even for positive results.

I'm ok but does this mean that in this case we have only a binary
response ? Maybe some context would benefit of the ability to embed
configuration data for MN.



-- 
julien.bournelle@int-evry.fr

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08833
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:48 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIdpg18180
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:39:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy8V-0004j4-2x
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:39:51 -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 OAA11926
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:39:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy7y-0004Jq-Ds; Fri, 27 Jun 2003 14:39:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxOw-0003X8-UV
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 13:52:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08539
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 13:52:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VxOu-0004uh-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 13:52:44 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VxOj-0004uV-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 13:52:33 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21277;
	Fri, 27 Jun 2003 10:51:53 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5RHpqA06850;
	Fri, 27 Jun 2003 10:51:52 -0700
X-mProtect: <200306271751> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdhsr4EY; Fri, 27 Jun 2003 10:51:50 PDT
Message-ID: <3EFC8436.55F35DCA@iprg.nokia.com>
Date: Fri, 27 Jun 2003 10:51:51 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jukka MJ Manner <jmanner@cs.Helsinki.FI>
CC: James Kempf <kempf@docomolabs-usa.com>,
        Seamoby Working Group <seamoby@ietf.org>
Subject: Re: [Seamoby] Candidate for New WG Draft
References: <Pine.LNX.4.44.0306270826220.19697-100000@mannersaari.cs.Helsinki.FI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Jukka,

there was a draft on AAA state relocation.

draft-forsberg-seamoby-aaa-relocate-00.txt

Let me know if you are interested but cannot find it.

Regards,

-Rajeev


Jukka MJ Manner wrote:

> Hi,
>
> I have tried for the last years to figure out how
> seamless/smooth/fast/[your favorite term here] handovers with QoS support
> can in real life be accomplished. I personally have come to the conclusion
> that although QoS and mobility management mechanisms seem to be somewhat
> in order, a CT framework would be the "final blow" in the whole system.
> More specifically, being able to do CT for IPSec and AAA is THE key, well,
> to me at least.
>
> Thus, I would like to see a WG guide on how you do IPSec and AAA CT, and
> how you couple that with the applications using the security mechanisms,
> for example, RSVP and a given mobility management mechanism.
>
> To go to the point, finaly, I would like the see the mentioned Seamoby
> "user guide" for CT, but it should also include the mentioned two
> additional use cases. I know that Seamoby is trying to close the work, but
> I think it might still be a good idea to try to write such an
> informational document.
>
> My 2 cents,
> Jukka
>
> On Thu, 26 Jun 2003, James Kempf wrote:
>
> > Jukka
> >
> > > I haven't reviewed the draft yet, but it might be a good idea to have in
> > > Seamoby something like the DCCP User Guide draft. Something that tells
> > > more than RFC3374.
> >
> > I took a very quick look at draft-ietf-dccp-user-guide-00.txt and I could
> > see some benefit in a similar document for CTP, though, since the intent is
> > to take CTP to experimental (unlike DCCP) I don't think such a document is
> > needed right now. Remember, the intent of the header compression CT draft is
> > to provide a concrete example of real value that would come out of CT, since
> > some people (and in particular some IESG members and some members of the
> > Seamoby CT review board) are skeptical. A User's Guide assumes that people
> > already see the value of the protocol, and is primarily about how to use it.
> >
> > What do other people think?
> >
> > >Still, the document should talk about more than one use
> > > case, though.
> > >
> >
> > I'm not quite sure I understand. Are you proposing that specifications for
> > multiple different kinds of contexts should be included into one draft? If
> > yes, this sounds a bit impractical to me. If I am, say, interested in
> > implementing context transfer for header compression, why should I have to
> > wade through a document that describes context transfer for AAA, and IPsec,
> > and... Small, focussed specifications tend to do better in IETF, and they
> > are also easier to review and achieve concensus on approval. Although we
> > want the header compression CT document as a concrete example, it will also
> > serve as the (experimental) reference specification for implementing a
> > header compression context and will be used for that purpose.
> >
> >             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 Jul  1 13:48:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08846
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:49 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RINgk21997
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxsI-0005cq-N5
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:06 -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 OAA09467
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:23:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxrY-00057B-9M; Fri, 27 Jun 2003 14:22:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuSL-0002P9-40
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:44:05 -0400
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23357
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 07:56:58 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5RBuw929748
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 14:56:58 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T63162d1daaac158f23077@esvir03nok.nokia.com>;
 Fri, 27 Jun 2003 14:56:57 +0300
Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:56:57 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:56:57 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jun 2003 14:56:56 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EFBC@esebe023.ntc.nokia.com>
Thread-Topic: question to Pekka S. on CTP
Thread-Index: AcM0xxvILyTFjP6fTumw2wWA1/3YAAH3BM4w
To: <pekkas@netcore.fi>
Cc: <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
X-OriginalArrivalTime: 27 Jun 2003 11:56:57.0523 (UTC) FILETIME=[35BA1830:01C33CA3]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] RE: question to Pekka S. 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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Assigned Issue17: Clarifying text needed on deployment restrictions=20

John

> -----Original Message-----
> From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: 17 June, 2003 14:18
> To: Loughney John (NRC/Helsinki)
> Cc: kempf@docomolabs-usa.com; seamoby@ietf.org
> Subject: Re: question to Pekka S. on CTP
>=20
>=20
> Hi,
>=20
> On Tue, 17 Jun 2003 john.loughney@nokia.com wrote:
> > Before I dig into your comments, I have a quick question to you.
> > You have the following substantial comments:
> >=20
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > substantial
> > -----------
> >=20
> >  - first thought: "state is evil, distributed state is even=20
> more evil."  I=20
> > think it must be *very* clear exactly what state should be=20
> transferred and=20
> > what are the real benefits of that related to the time it=20
> would take to=20
> > re-establish the state -- and whether the state transfers=20
> can be made to=20
> > work ok.  Otherwise you can just wait pushback from IESG/IAB.. :-)
> >=20
> >  - spell out deployment restrictions of nAR + pAR for=20
> sharing security=20
> > associations; e.g. same ISP's network?  does MN/nAR/pAR=20
> somehow have to=20
> > discover whether CT makes sense (e.g. when MN moves to some=20
> really foreign=20
> > network, no use even trying to do CT's)?
> >=20
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > I agree that the text needs to be improved, but how high of=20
> a barrier
> > do you see that is needed to be achieved.  One thing that was missed
> > in the last update is to classify this as experimental.  I=20
> think part
> > of the point of going experimental was to allow some deployment
> > & experiments to get a better handle on your concerns above.  Do you
> > think this is reasonable?
>=20
> I think experimental (compared to standards track) may be a very good=20
> choice here, and very reasonable.
>=20
> But regardless of that, I think it's important (and I think you'll
> probably agree) to at least try to paint some picture about deployment
> restrictions very early (in abstract, special section or=20
> introduction), so
> people don't have too many fantastic notions about the=20
> applicability (and=20
> when starting to read the document, think like "what are these guys=20
> doing?  you can't solve the generic problem with this".
>=20
> So, personally I think it might be a good idea to focus first *with
> sufficiently verbose text early on* on the "context transfer=20
> inside one
> ISP" -problem, and see whether it gives you sufficient=20
> sufficient benefits
> and the protocol can be deployed.
>=20
> The next phase, to be done later (prior to going to PS, at=20
> the latest),
> could be figuring how how to establish security associations=20
> in context
> transfers between ISP's, and how to enhance the context=20
> transfer triggers.
>=20
> An alternative method, of course, might be to try to work on=20
> -- at least
> in some fashion -- the inter-ISP cases right now too, to get better
> experimental data (when CTP gets implemented and piloted) on that for
> later, to see how well the current protocol works in this=20
> scenario (might
> save redesigning later on if inter-ISP context transfers or=20
> other stuff
> required for real deployments are deemed necessary).
>=20
> I see two paths, but I can't really say which is the best.  Both have=20
> their tradeoffs.
>=20
> Hope this helps..
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
>=20
>=20

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08848
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:50 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RITo000725
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:29:50 -0400
Received: from [132.151.1.176] (helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxyW-00007F-NQ
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:29:32 -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 OAA10344
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:29:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxxV-0008Ca-Jh; Fri, 27 Jun 2003 14:28:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VvRr-000691-Jz
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 11:47: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 LAA04861
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 11:47:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VvRq-00040J-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 11:47:38 -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 19VvRf-00040E-00
	for seamoby@ietf.org; Fri, 27 Jun 2003 11:47:27 -0400
Message-ID: <007001c33cc2$a4696b40$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>
Cc: "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0306270826220.19697-100000@mannersaari.cs.Helsinki.FI>
Subject: Re: [Seamoby] Candidate for New WG Draft
Date: Fri, 27 Jun 2003 08:41:57 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Jukka,

Pat and I really want to get the current set of work items completed and
shut the WG down. Seamoby has been running now for 3 years (if you count the
time from the initial BOF) and has accomplished very little. The IESG is not
happy with this, and we are getting pressure to close quickly. If we do not
finish with our current set of topics soon, the IESG may decide to close
Seamoby down anyway without having completed the remaning topics.

Given that, I can't see expanding the charter at this point to take on a
whole new area of doing complete specification for all contexts needed to do
seamless handover. Some of these topics are very controversial (security and
QoS context transfer, for example). We could easy spend another 3 years
arguing about them, and arguing with others in IETF and the IESG who don't
believe context transfer should be used for these purposes.

I agree that there are lots of interesting and important research topics
that need to be tied down before seamless mobility can really be done
interoperabily. After Seamoby has completed its charter items, we can hold
another BOF and recharter, or talk to Vern and the IESG about starting an
IRTF group to look into the problem. But we really need to finish the
charter within six months, or risk losing any of the work that's been
completed already.

What do other people think about this?

            jak

----- Original Message ----- 
From: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Seamoby Working Group" <seamoby@ietf.org>
Sent: Thursday, June 26, 2003 10:34 PM
Subject: Re: [Seamoby] Candidate for New WG Draft


>
> Hi,
>
> I have tried for the last years to figure out how
> seamless/smooth/fast/[your favorite term here] handovers with QoS support
> can in real life be accomplished. I personally have come to the conclusion
> that although QoS and mobility management mechanisms seem to be somewhat
> in order, a CT framework would be the "final blow" in the whole system.
> More specifically, being able to do CT for IPSec and AAA is THE key, well,
> to me at least.
>
> Thus, I would like to see a WG guide on how you do IPSec and AAA CT, and
> how you couple that with the applications using the security mechanisms,
> for example, RSVP and a given mobility management mechanism.
>
> To go to the point, finaly, I would like the see the mentioned Seamoby
> "user guide" for CT, but it should also include the mentioned two
> additional use cases. I know that Seamoby is trying to close the work, but
> I think it might still be a good idea to try to write such an
> informational document.
>
> My 2 cents,
> Jukka
>
> On Thu, 26 Jun 2003, James Kempf wrote:
>
> > Jukka
> >
> > > I haven't reviewed the draft yet, but it might be a good idea to have
in
> > > Seamoby something like the DCCP User Guide draft. Something that tells
> > > more than RFC3374.
> >
> > I took a very quick look at draft-ietf-dccp-user-guide-00.txt and I
could
> > see some benefit in a similar document for CTP, though, since the intent
is
> > to take CTP to experimental (unlike DCCP) I don't think such a document
is
> > needed right now. Remember, the intent of the header compression CT
draft is
> > to provide a concrete example of real value that would come out of CT,
since
> > some people (and in particular some IESG members and some members of the
> > Seamoby CT review board) are skeptical. A User's Guide assumes that
people
> > already see the value of the protocol, and is primarily about how to use
it.
> >
> > What do other people think?
> >
> > >Still, the document should talk about more than one use
> > > case, though.
> > >
> >
> > I'm not quite sure I understand. Are you proposing that specifications
for
> > multiple different kinds of contexts should be included into one draft?
If
> > yes, this sounds a bit impractical to me. If I am, say, interested in
> > implementing context transfer for header compression, why should I have
to
> > wade through a document that describes context transfer for AAA, and
IPsec,
> > and... Small, focussed specifications tend to do better in IETF, and
they
> > are also easier to review and achieve concensus on approval. Although we
> > want the header compression CT document as a concrete example, it will
also
> > serve as the (experimental) reference specification for implementing a
> > header compression context and will be used for that purpose.
> >
> >             jak
> >
> >
>
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08856
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:51 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIVkh02840
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:31:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vxxl-0008Fw-Ds
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:28:45 -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 OAA10158
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:28: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 19Vxx7-0007o9-Hg; Fri, 27 Jun 2003 14:28:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuYc-0002P9-Fj
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:50:49 -0400
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20392
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 04:18:08 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5R7YKa20643
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 10:34:25 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T63153cad0cac158f21083@esvir01nok.ntc.nokia.com>;
 Fri, 27 Jun 2003 10:34:20 +0300
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 10:34:19 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 10:34:18 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] Candidate for New WG Draft
Date: Fri, 27 Jun 2003 10:34:18 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EFA9@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Candidate for New WG Draft
Thread-Index: AcM8cHd9s+DxCW4+Riu5s8PgrSdcVgADcLwQ
To: <charliep@iprg.nokia.com>, <jmanner@cs.Helsinki.FI>
Cc: <seamoby@ietf.org>
X-OriginalArrivalTime: 27 Jun 2003 07:34:18.0784 (UTC) FILETIME=[84C95A00:01C33C7E]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Charlie & Jukka,

I see the need for this, too.  I think that there is interest in
finishing the existing Seamoby work, though.  One solution is
to have an individual draft working on QoS Context transfers,
with discussion on the Seamoby / NSIS mailing lists.  Not=20
everything needs to be a WG draft, as long as there are people
interested in the subject.  However, this would be a good=20
thing to discuss in Vienna & get buy-in from the WG chairs
and ADs.

John

> -----Original Message-----
> From: ext Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: 27 June, 2003 08:46
> To: Jukka MJ Manner
> Cc: Seamoby Working Group
> Subject: Re: [Seamoby] Candidate for New WG Draft
>=20
>=20
>=20
> Hello Jukka,
>=20
> I agree with you that QoS context transfer is a crucial piece.
> In fact, in a way the QoS support was one of my main
> motivating factors for working on this problem.  I'm happy
> to say that we have achieved a certain degree of success
> with our prototype.
>=20
> However, it may be procedurally impossible to publish a document
> towards that goal within seamoby.  I would definitely support
> putting this work item on the charter, but it seems to me that the
> goal of the authority structures surrounding seamoby is to shut
> down the working group, for whatever reason (I do not understand).
>=20
> Maybe the work should proceed in another working group exactly
> like seamoby, but with more enthusiastic IESG support.  I'm not sure
> how to engender that result, though.
>=20
> Regards,
> Charlie P.
>=20
>=20
>=20
> Jukka MJ Manner wrote:
>=20
> >Hi,
> >
> >I have tried for the last years to figure out how
> >seamless/smooth/fast/[your favorite term here] handovers=20
> with QoS support
> >can in real life be accomplished. I personally have come to=20
> the conclusion
> >that although QoS and mobility management mechanisms seem to=20
> be somewhat
> >in order, a CT framework would be the "final blow" in the=20
> whole system.
> >More specifically, being able to do CT for IPSec and AAA is=20
> THE key, well,
> >to me at least.
> >
> >Thus, I would like to see a WG guide on how you do IPSec and=20
> AAA CT, and=20
> >how you couple that with the applications using the security=20
> mechanisms,=20
> >for example, RSVP and a given mobility management mechanism.
> >
> >To go to the point, finaly, I would like the see the=20
> mentioned Seamoby
> >"user guide" for CT, but it should also include the mentioned two
> >additional use cases. I know that Seamoby is trying to close=20
> the work, but
> >I think it might still be a good idea to try to write such an
> >informational document.
> >
> >My 2 cents,
> >Jukka
> >
> >On Thu, 26 Jun 2003, James Kempf wrote:
> >
> > =20
> >
> >>Jukka
> >>
> >>   =20
> >>
> >>>I haven't reviewed the draft yet, but it might be a good=20
> idea to have in
> >>>Seamoby something like the DCCP User Guide draft.=20
> Something that tells
> >>>more than RFC3374.
> >>>     =20
> >>>
> >>I took a very quick look at=20
> draft-ietf-dccp-user-guide-00.txt and I could
> >>see some benefit in a similar document for CTP, though,=20
> since the intent is
> >>to take CTP to experimental (unlike DCCP) I don't think=20
> such a document is
> >>needed right now. Remember, the intent of the header=20
> compression CT draft is
> >>to provide a concrete example of real value that would come=20
> out of CT, since
> >>some people (and in particular some IESG members and some=20
> members of the
> >>Seamoby CT review board) are skeptical. A User's Guide=20
> assumes that people
> >>already see the value of the protocol, and is primarily=20
> about how to use it.
> >>
> >>What do other people think?
> >>
> >>   =20
> >>
> >>>Still, the document should talk about more than one use
> >>>case, though.
> >>>
> >>>     =20
> >>>
> >>I'm not quite sure I understand. Are you proposing that=20
> specifications for
> >>multiple different kinds of contexts should be included=20
> into one draft? If
> >>yes, this sounds a bit impractical to me. If I am, say,=20
> interested in
> >>implementing context transfer for header compression, why=20
> should I have to
> >>wade through a document that describes context transfer for=20
> AAA, and IPsec,
> >>and... Small, focussed specifications tend to do better in=20
> IETF, and they
> >>are also easier to review and achieve concensus on=20
> approval. Although we
> >>want the header compression CT document as a concrete=20
> example, it will also
> >>serve as the (experimental) reference specification for=20
> implementing a
> >>header compression context and will be used for that purpose.
> >>
> >>            jak
> >>
> >>
> >>   =20
> >>
> >
> >
> >_______________________________________________
> >Seamoby mailing list
> >Seamoby@ietf.org
> >https://www1.ietf.org/mailman/listinfo/seamoby
> > =20
> >
>=20
>=20
>=20
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>=20

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 13:48:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08862
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:51 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIeWK19982
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:40:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy9A-0005CD-9k
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:40:32 -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 OAA12046
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:40: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 19Vy8f-0004uc-Pl; Fri, 27 Jun 2003 14:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Vy5U-00039Z-Tk
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 14:36:44 -0400
Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11467
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 14:36:43 -0400 (EDT)
Message-ID: <009801c33cda$4d3d35a0$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <john.loughney@nokia.com>, <charliep@iprg.nokia.com>,
        <jmanner@cs.Helsinki.FI>
Cc: <seamoby@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB32063658EFA9@esebe023.ntc.nokia.com>
Subject: Re: [Seamoby] Candidate for New WG Draft
Date: Fri, 27 Jun 2003 11:31:17 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

John,

If this has some relation to NSIS, would you see a problem with having an
(experimental) QoS context transfer draft in NSIS? Provided the WG agrees,
of course. This would be an alternative to a strictly individual draft,
which is also OK but might be less interesting to the NSIS folks.

The original idea was that Seamboy would not get into defining feature
contexts, and that they would be done by the relevant WGs, but, for tactical
reasons, we need at least one.

            jak

----- Original Message ----- 
From: <john.loughney@nokia.com>
To: <charliep@iprg.nokia.com>; <jmanner@cs.Helsinki.FI>
Cc: <seamoby@ietf.org>
Sent: Friday, June 27, 2003 12:34 AM
Subject: RE: [Seamoby] Candidate for New WG Draft


> Charlie & Jukka,
>
> I see the need for this, too.  I think that there is interest in
> finishing the existing Seamoby work, though.  One solution is
> to have an individual draft working on QoS Context transfers,
> with discussion on the Seamoby / NSIS mailing lists.  Not
> everything needs to be a WG draft, as long as there are people
> interested in the subject.  However, this would be a good
> thing to discuss in Vienna & get buy-in from the WG chairs
> and ADs.
>
> John
>
> > -----Original Message-----
> > From: ext Charlie Perkins [mailto:charliep@iprg.nokia.com]
> > Sent: 27 June, 2003 08:46
> > To: Jukka MJ Manner
> > Cc: Seamoby Working Group
> > Subject: Re: [Seamoby] Candidate for New WG Draft
> >
> >
> >
> > Hello Jukka,
> >
> > I agree with you that QoS context transfer is a crucial piece.
> > In fact, in a way the QoS support was one of my main
> > motivating factors for working on this problem.  I'm happy
> > to say that we have achieved a certain degree of success
> > with our prototype.
> >
> > However, it may be procedurally impossible to publish a document
> > towards that goal within seamoby.  I would definitely support
> > putting this work item on the charter, but it seems to me that the
> > goal of the authority structures surrounding seamoby is to shut
> > down the working group, for whatever reason (I do not understand).
> >
> > Maybe the work should proceed in another working group exactly
> > like seamoby, but with more enthusiastic IESG support.  I'm not sure
> > how to engender that result, though.
> >
> > Regards,
> > Charlie P.
> >
> >
> >
> > Jukka MJ Manner wrote:
> >
> > >Hi,
> > >
> > >I have tried for the last years to figure out how
> > >seamless/smooth/fast/[your favorite term here] handovers
> > with QoS support
> > >can in real life be accomplished. I personally have come to
> > the conclusion
> > >that although QoS and mobility management mechanisms seem to
> > be somewhat
> > >in order, a CT framework would be the "final blow" in the
> > whole system.
> > >More specifically, being able to do CT for IPSec and AAA is
> > THE key, well,
> > >to me at least.
> > >
> > >Thus, I would like to see a WG guide on how you do IPSec and
> > AAA CT, and
> > >how you couple that with the applications using the security
> > mechanisms,
> > >for example, RSVP and a given mobility management mechanism.
> > >
> > >To go to the point, finaly, I would like the see the
> > mentioned Seamoby
> > >"user guide" for CT, but it should also include the mentioned two
> > >additional use cases. I know that Seamoby is trying to close
> > the work, but
> > >I think it might still be a good idea to try to write such an
> > >informational document.
> > >
> > >My 2 cents,
> > >Jukka
> > >
> > >On Thu, 26 Jun 2003, James Kempf wrote:
> > >
> > >
> > >
> > >>Jukka
> > >>
> > >>
> > >>
> > >>>I haven't reviewed the draft yet, but it might be a good
> > idea to have in
> > >>>Seamoby something like the DCCP User Guide draft.
> > Something that tells
> > >>>more than RFC3374.
> > >>>
> > >>>
> > >>I took a very quick look at
> > draft-ietf-dccp-user-guide-00.txt and I could
> > >>see some benefit in a similar document for CTP, though,
> > since the intent is
> > >>to take CTP to experimental (unlike DCCP) I don't think
> > such a document is
> > >>needed right now. Remember, the intent of the header
> > compression CT draft is
> > >>to provide a concrete example of real value that would come
> > out of CT, since
> > >>some people (and in particular some IESG members and some
> > members of the
> > >>Seamoby CT review board) are skeptical. A User's Guide
> > assumes that people
> > >>already see the value of the protocol, and is primarily
> > about how to use it.
> > >>
> > >>What do other people think?
> > >>
> > >>
> > >>
> > >>>Still, the document should talk about more than one use
> > >>>case, though.
> > >>>
> > >>>
> > >>>
> > >>I'm not quite sure I understand. Are you proposing that
> > specifications for
> > >>multiple different kinds of contexts should be included
> > into one draft? If
> > >>yes, this sounds a bit impractical to me. If I am, say,
> > interested in
> > >>implementing context transfer for header compression, why
> > should I have to
> > >>wade through a document that describes context transfer for
> > AAA, and IPsec,
> > >>and... Small, focussed specifications tend to do better in
> > IETF, and they
> > >>are also easier to review and achieve concensus on
> > approval. Although we
> > >>want the header compression CT document as a concrete
> > example, it will also
> > >>serve as the (experimental) reference specification for
> > implementing a
> > >>header compression context and will be used for that purpose.
> > >>
> > >>            jak
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 14:33:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08647
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:34 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RIORL23243
	for seamoby-archive@odin.ietf.org; Fri, 27 Jun 2003 14:24:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxsI-0005d5-T5
	for seamoby-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:07 -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 OAA09468
	for <seamoby-web-archive@ietf.org>; Fri, 27 Jun 2003 14:23:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VxrX-000571-Mg; Fri, 27 Jun 2003 14:22:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VuRv-0002NW-Bq
	for seamoby@optimus.ietf.org; Fri, 27 Jun 2003 10:43:39 -0400
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22618
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 07:46:31 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5RB03901976
	for <seamoby@ietf.org>; Fri, 27 Jun 2003 14:00:03 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6315f90542ac158f24078@esvir04nok.ntc.nokia.com>;
 Fri, 27 Jun 2003 14:00:03 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:00:03 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 27 Jun 2003 14:00:02 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] Issue 2: CTAR Response Needed
Date: Fri, 27 Jun 2003 14:00:01 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EFB7@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Issue 2: CTAR Response Needed
Thread-Index: AcM8MgFZCPv8cGYOQdaHQQygfsN7kgAaRYBw
To: <kempf@docomolabs-usa.com>, <charliep@iprg.nokia.com>
Cc: <seamoby@ietf.org>
X-OriginalArrivalTime: 27 Jun 2003 11:00:02.0692 (UTC) FILETIME=[42543C40:01C33C9B]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

I am adding this message to CTP.  My assumption is that this is purely =
an informative message, which can be disregarded by the MN if the MN has =
other information.

br,
John

2.4.2 Context Transfer Activate Acknowledge (CTAA) Message

This is an informative message sent nAR to the MN to acknowledge a CTAR =
message. Acknowledgement is optional, since the MN may have already =
moved and may not receive the reply. This message may include a list of =
FPT (feature profile types) that were not transferred successfully.=20

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Message Type           |reserve|       Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Mobile Node's Previous IP Address                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Previous Router IP Address                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3DAuth-Token| Type Len      |        Replay                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    MN Authorization Token                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Failed Context Type (if present)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Next Failed Context Type (if present)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ........                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The message data for CTAR is the Mobile Node's Previous IP Address, =
Previous Router's IP address, MN Authorization Token, followed by a list =
of context types that were not successfully transferred.  If no context =
types are specified, then all contexts for the mobile node are =
considered successfully transferred.

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 15:13: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 PAA12723
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 15:13: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 19XQYb-0002eS-Rp
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 15:12:59 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61JCn5j010138
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 15:12:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XQYb-0002dQ-My
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 15:12:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12578
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 15:12:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XQYY-0007FN-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 15:12:46 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XQYV-0007FA-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 15:12:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XQXz-0002VC-Mj; Tue, 01 Jul 2003 15:12:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XQWy-0002S4-BD
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 15:11: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 PAA12337
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 15:11:00 -0400 (EDT)
From: Basavaraj.Patil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XQWq-0007ED-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 15:11:00 -0400
Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XQWo-0007Du-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 15:10:58 -0400
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h61JAs127696
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 14:10:54 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T632a9c5f05ac12f254079@davir01nok.americas.nokia.com>;
 Tue, 1 Jul 2003 14:10:53 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 1 Jul 2003 14:10:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 1 Jul 2003 14:10:32 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB35E@daebe007.americas.nokia.com>
Thread-Topic: Bar BoF announcement for IRTF WG l3m
Thread-Index: AcNABHC9TYYvFDPvRDe2eNnybQR/uA==
To: <mobile-ip@sunroof.eng.sun.com>, <seamoby@ietf.org>
Cc: <vern@icir.org>
X-OriginalArrivalTime: 01 Jul 2003 19:10:33.0356 (UTC) FILETIME=[72062CC0:01C34004]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] Bar BoF announcement for IRTF WG l3m
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Hello,

At the previous NSIIM BoF we also discussed the idea of starting an
IRTF WG dealing with IP mobility (specifically the Mobile IP protocol
variety). The intent is to develop a set of tools that can be used for
measuring the performance of the various types of optimization
proposals for Mobile IP protocols. In addition the WG would develop
simulation models that can be used to better understand the
performance gains of schemes such as Fast HO, Hierarchical mobility
and implications of schemes for optimizing address assignment,
frequency of router advertisements etc.=20

We would like to have a Bar BoF at IETF57 to discuss the interest and
details of this work further. The proposal is as follows:
What: IP Mobility work in IRTF Bar BoF
When: Monday at 10 PM
Where: Its a bar Bof :) (TBA)

Further details about the BoF will be sent to the Mobile IP and
Seamoby lists.=20

-Chairs

--------------------------------------------

The current charter is as follows:

Name of WG : l3m=20

        The "Layer 3 Mobility" (l3m) RG is an open IRTF group.  It =
studies
        performance and architectural tradeoffs of optimizations and
        evolutionary changes to IP mobility. Even though the focus
        is on layer 3 mobility, knowledge of lower layers may be used
        if appropriate.

        The L3M RG addresses questions of an evolutionary nature.
        In particular, radically new architectures (e.g., based on the
        separation of identity and location) are outside the scope.

        The objective of the group is to enable the formation of a
        research community around the topic of internet Mobility similar
        to the TCP research community. That is, the objective is not =
only
        to carry out and publish results of analysis and simulations
        of different proposals, but to do so in such a fashion that
        allows a more direct comparison ("apples to apples") than is
        now possible. In order to accomplish this, the L3M group will
        strive to arrive at some common scenarios, parameters, tools
        and methodologies.

	The research group will also examine algorithms for automatic
	configuration of access routers with information of use to
	Mobile Nodes during fast handover.

	The Seamoby Working group is developing an Experimental
	protocol to distribute such information between routers and
	between the router and Mobile Node (Candidate Access Router
	Discovery, CARD),  but the actual algorithms for determining
	whether a particular access point, seen by a Mobile Node and
	reported to the access router, is within range of a handover
	from the router is not in scope. Neither is determining whether
	a particular access point is authorized to provide service and
	therefore a candidate for handover. These topics will be
	material for the research group. The goal of the research is to
	characterize the currently proposed approaches (learning based
	or server based) and any other approaches, and determine under
	which conditions a particular algorithm is a superior solution.
	These results will be returned to the IETF if and when
	standardization of CARD is requested.





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 16:15: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 QAA15111
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 16:15:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWu-00066M-SY
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 16:15:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61KF8vo023447
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 16:15:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWu-000666-PP
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 16:15: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 QAA15103
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 16:15:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWs-0000KR-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:15:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWs-0000KN-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:15:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWn-000651-Mi; Tue, 01 Jul 2003 16:15:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWe-00064O-AH
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 16:14: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 QAA15096
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 16:14:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWc-0000K7-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:14:50 -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 19XRWb-0000K2-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:14:50 -0400
Message-ID: <022901c3400c$ae633bb0$6b6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 11:16:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Editorial Issue] Standards Language
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This draft is meant to be an experimental RFC. Therefore, it should not use
standards language (MUST/SHALL, etc.).

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 16:39: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 QAA15632
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 16:39:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRuD-0006nx-2m
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 16:39:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61KdD5o026154
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 16:39:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRuC-0006nl-TP
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 16:39: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 QAA15622
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 16:39:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRuA-0000UP-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:39:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRuA-0000UM-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:39:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRu0-0006mU-S6; Tue, 01 Jul 2003 16: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 19XRth-0006lt-Ax
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 16:38: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 QAA15615
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 16:38:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRtf-0000UD-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:38:39 -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 19XRte-0000UA-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:38:38 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 1 Jul 2003 16:38:27 -0400
Message-ID: <024701c34010$f2da8f10$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <022b01c3400c$b0802840$6b6015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Tue, 1 Jul 2003 16:40:03 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 01 Jul 2003 20:38:27.0457 (UTC) FILETIME=[B9A21F10:01C34010]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

James,

The advantage of the R flag is that the MN does not have to know the rate
limit of the access router but can be alarmed when it approaches the rate
limit. The rate limit can depend on the bandwidth of the link, the
processing capacity of the access router, etc. The R flag does not require
predefined rate to be specified in the protocol. Now the rate limit is fully
open to the configuration. I think this flexibility is an advantage of the R
flag compared to the fixed inter-message interval method.

Dropping packets above the rate limit will be performed by the access
router. But if the MN does not know the rate limit, it will retransmit its
request. This retransmission will be just waste of rf bandwidth which we
like to save. So for the well-behaving MNs, it is good to give them an alarm
so that they don't do retransmission.

Eunsoo


----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 2:29 PM
Subject: [Seamoby] [CARD Techical Issue] Rate limiting flag


> Last paragraph in in introduction to Section 4 says that the R flag is
used
> by the router to indicate to the MN to reduce sending rate of messages. As
> far as I know, this type of rate limiting is not done in any other IETF
> protocol (but I may be missing it).
>
> Typically, there are two ways that IETF protocols rate limit that I am
> familiar with:
>
>     - by specifying a constant intermessage time which clients are
required
> to abide by
>     - by having the server (router in this case) drop packets selectively
> when traffic gets too heavy
>
> The former works for well-behaved hosts, the latter reduces the impact of
> DoS attackes.
>
> Is there something about CARD that recommends this approach rather than a
> standard IETF protocol approach?
>
>             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 Jul  1 16:40: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 QAA15658
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 16:40:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRv0-0006qD-K8
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 16:40:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Ke21Y026287
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 16:40:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRv0-0006pu-CP
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 16:40: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 QAA15651
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 16:39:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRuy-0000Ud-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:40:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRux-0000Ua-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:39:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRuz-0006p8-7b; Tue, 01 Jul 2003 16:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRuF-0006o7-Gp
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 16:39: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 QAA15626
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 16:39:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRuD-0000UV-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:39: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 19XRuC-0000US-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:39:13 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 1 Jul 2003 16:39:13 -0400
Message-ID: <024e01c34011$0e0f6ee0$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <022901c3400c$ae633bb0$6b6015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language
Date: Tue, 1 Jul 2003 16:40:49 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 01 Jul 2003 20:39:13.0098 (UTC) FILETIME=[D4D662A0:01C34010]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Even though the protocol is not a standard, wouldn't it make the protocol
clearer?

Eunsoo

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 2:16 PM
Subject: [Seamoby] [CARD Editorial Issue] Standards Language


> This draft is meant to be an experimental RFC. Therefore, it should not
use
> standards language (MUST/SHALL, etc.).
>
>             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 Jul  1 17:04: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 QAA15112
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 16:15:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWu-00066b-Vz
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 16:15:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61KF8Qc023463
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 16:15:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWu-00066L-Rw
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 16:15: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 QAA15106
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 16:15:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWt-0000KU-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:15:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWs-0000KO-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 16:15:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWo-000659-5R; Tue, 01 Jul 2003 16:15:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XRWi-00064W-Jk
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 16:14:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15099
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 16:14:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XRWg-0000KF-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:14:54 -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 19XRWf-0000KB-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 16:14:54 -0400
Message-ID: <022b01c3400c$b0802840$6b6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 11:29:22 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Techical Issue] Rate limiting flag
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Last paragraph in in introduction to Section 4 says that the R flag is used
by the router to indicate to the MN to reduce sending rate of messages. As
far as I know, this type of rate limiting is not done in any other IETF
protocol (but I may be missing it).

Typically, there are two ways that IETF protocols rate limit that I am
familiar with:

    - by specifying a constant intermessage time which clients are required
to abide by
    - by having the server (router in this case) drop packets selectively
when traffic gets too heavy

The former works for well-behaved hosts, the latter reduces the impact of
DoS attackes.

Is there something about CARD that recommends this approach rather than a
standard IETF protocol approach?

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 17:07: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 RAA16453
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 17:07: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 19XSKy-0007e9-Mm
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 17:06:53 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61L6qQC029387
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 17:06:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XSKy-0007du-Io
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 17:06:52 -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 RAA16445
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 17:06:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XSK8-0007cj-2s; Tue, 01 Jul 2003 17:06:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XSK4-0007cK-Q0
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 17:05:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16417
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 17:05:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XSK2-0000k7-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 17:05:54 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XSK1-0000jz-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 17:05:53 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00337;
	Tue, 1 Jul 2003 14:05:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h61L5I319386;
	Tue, 1 Jul 2003 14:05:18 -0700
X-mProtect: <200307012105> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdOX8GvM; Tue, 01 Jul 2003 14:05:16 PDT
Message-ID: <3F01F79A.4010100@iprg.nokia.com>
Date: Tue, 01 Jul 2003 14:05:30 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language
References: <022901c3400c$ae633bb0$6b6015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Jim,

I am sure this is not right.

A protocol specification within the IETF needs to use RFC 2119
language even if it's an individual contribution, not on the standards
track, designated as Experimental, whatever.

It's a property of protocol metalanguage, not state of standardization.

Regards,
Charlie P.


James Kempf wrote:

>This draft is meant to be an experimental RFC. Therefore, it should not use
>standards language (MUST/SHALL, etc.).
>
>            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 Jul  1 18:08:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18461
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 18:08:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XTIO-000256-Fg
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 18:08:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61M8Gap007996
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 18:08:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XTIO-00024t-Cl
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 18:08: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 SAA18401
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 18:08:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XTIL-0001Kt-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 18:08:13 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XTIK-0001Kq-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 18:08:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XTI8-00024C-Dm; Tue, 01 Jul 2003 18:08:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XTHg-0001xW-1D
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 18:07: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 SAA18331
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 18:07:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XTHd-0001KT-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 18:07:29 -0400
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XTHb-0001KI-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 18:07:27 -0400
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h61M7QT6011710
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 15:07:26 -0700 (MST)
Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3])
	by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h61M7OxE025869
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 17:07:25 -0500
Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <N89LJ6DN>; Tue, 1 Jul 2003 17:07:24 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A211@IL27EXM10.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'Eunsoo Shim'" <eunsoo@nec-labs.com>,
        James Kempf
	 <kempf@docomolabs-usa.com>, seamoby@ietf.org
Subject: RE: [Seamoby] [CARD Editorial Issue] Standards Language
Date: Tue, 1 Jul 2003 17:07:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain;
	charset="iso-8859-1"
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Well, this is not the first time though. I have seen 
several experimental RFC(s) that used standard language.
For example, look at RFC 2716. BTW, we are willing 
change if required. What others' think?
Regards,
Ajoy 


> -----Original Message-----
> From: Eunsoo Shim [mailto:eunsoo@nec-labs.com]
> Sent: Tuesday, July 01, 2003 3:41 PM
> To: James Kempf; seamoby@ietf.org
> Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language
> 
> 
> Even though the protocol is not a standard, wouldn't it make 
> the protocol
> clearer?
> 
> Eunsoo
> 
> ----- Original Message -----
> From: "James Kempf" <kempf@docomolabs-usa.com>
> To: <seamoby@ietf.org>
> Sent: Tuesday, July 01, 2003 2:16 PM
> Subject: [Seamoby] [CARD Editorial Issue] Standards Language
> 
> 
> > This draft is meant to be an experimental RFC. Therefore, 
> it should not
> use
> > standards language (MUST/SHALL, etc.).
> >
> >             jak
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 19:39:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20658
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:39: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 19XUiO-0004Z5-52
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:39:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61NdCl9017548
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19:39:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUiO-0004Yx-12
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19:39: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 TAA20650
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:39:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUiM-0002HW-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:39:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUiL-0002HT-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:39:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUiE-0004YG-75; Tue, 01 Jul 2003 19:39:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUhT-0004WY-KF
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:38: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 TAA20639
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:38:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUhR-0002Gk-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:38:13 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUhQ-0002GY-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:38:13 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09238;
	Tue, 1 Jul 2003 16:37:42 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h61NbfW17842;
	Tue, 1 Jul 2003 16:37:41 -0700
X-mProtect: <200307012337> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd2CXoN3; Tue, 01 Jul 2003 16:37:39 PDT
Message-ID: <3F021B51.8080901@iprg.nokia.com>
Date: Tue, 01 Jul 2003 16:37:53 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language
References: <022901c3400c$ae633bb0$6b6015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello again Jim,

While I believe that a _protocol specification_ should use the
capitalized language, I do _not_ believe that language is at
all appropriate for a requirements document.  So, I cringe
a bit when I read a sentence like "A protocol satisfying the
requirement in this section MUST have a security feature".
It seems quite out of place for me.

And, again, it doesn't matter whether the requirements
document is standards track or not.

The same considerations appy even more strongly in the
context of a problem statement, in my opinion.

Regards,
Charlie P.



James Kempf wrote:

>This draft is meant to be an experimental RFC. Therefore, it should not use
>standards language (MUST/SHALL, etc.).
>
>            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 Jul  1 19:49: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 TAA21061
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUrw-0004vh-19
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn3mn018920
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUrv-0004v3-Q7
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20980
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:48:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrt-0002QT-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrs-0002QN-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19: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 19XUrt-0004r2-Lq; Tue, 01 Jul 2003 19: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 19XUr1-0004p8-MN
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20948
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUqz-0002PN-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:05 -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 19XUqy-0002PB-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:04 -0400
Message-ID: <009b01c3402a$78e20bb0$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 14:32:57 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Section 4.5 describes a negotiation between the MN and AR to determine
whether CARD is piggybacked on FMIPv6. This negotation seems complex and
unnecessary. For simplicity, I think we should do one or the other. Though I
favor piggybacking because it simplifies the entire handover across both
protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
handover more complex. Since the DT and WG don't seem to agree, I believe we
should drop FMIPv6 piggy backing.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 19:49: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 TAA21063
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUrw-0004wO-70
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn4g6018980
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUrw-0004vv-35
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20985
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUru-0002QX-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrs-0002QU-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19: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 19XUru-0004s6-3v; Tue, 01 Jul 2003 19: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 19XUr2-0004pD-99
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20951
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr0-0002PL-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:06 -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 19XUqy-0002PA-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:04 -0400
Message-ID: <009a01c3402a$78c69470$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 14:22:34 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Editorial Issue] Terminological Consistency
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The CARD draft needs a walk through for terminological consistency. For
example, Section 4.3.1 uses the term CARD table and CAR table for the table
of candidate access routers.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 19:49: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 TAA21103
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUrw-0004xi-QU
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn4Hu019068
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUrw-0004xM-ME
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20991
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUru-0002Qb-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrt-0002QY-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19: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 19XUru-0004sq-Ik; Tue, 01 Jul 2003 19: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 19XUr2-0004pI-Vw
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20954
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr1-0002PQ-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqy-0002PC-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:04 -0400
Message-ID: <009c01c3402a$78fd82f0$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 14:46:29 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Technical Issue]Static v.s. dynamic attributes
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Section 5.1.4 specifies a flag to indicate whether an attribute is static or
dynamic. How about using a lifetime of zero to indicate this? No real
lifetime is going to be advertised as zero, and this allows the AVP code to
take up a byte, and the lifetime field is always there, making the message
easier to process.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 19:49: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 TAA21108
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUry-0004z3-LZ
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn6Ws019141
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUry-0004yS-Fl
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20999
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrv-0002Qp-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUru-0002Qm-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUrv-0004uK-EX; Tue, 01 Jul 2003 19: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 19XUr3-0004pS-63
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20960
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr1-0002Pe-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqz-0002PG-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:05 -0400
Message-ID: <009e01c3402a$79361f20$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 14:58:34 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Editorial Issue] Excessive Appendix Size
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The appendix in the CARD draft is almost as large as the draft itself. How
about performing an appendectomy :-) and separating the appendix out into a
separate draft? I think it would be easier for readers, and especially the
IESG, to process.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 19:49: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 TAA21109
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUry-0004z2-LS
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn6dC019137
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUry-0004yJ-Ek
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA21006
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrw-0002R0-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrv-0002Qx-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUrw-0004wg-ID; Tue, 01 Jul 2003 19: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 19XUrB-0004pm-Nw
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20968
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr9-0002Ps-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqw-0002P4-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:03 -0400
Message-ID: <009701c3402a$78060390$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>, <seamoby@ietf.org>
References: <022901c3400c$ae633bb0$6b6015ac@dclkempt40> <024e01c34011$0e0f6ee0$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language
Date: Tue, 1 Jul 2003 13:43: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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I had an experimental draft returned to me by the IESG several years ago
because it contained excessive standards track language. I would prefer not
to have to go through another round of editing due to IESG comments (if that
is at all possible).

            jak

----- Original Message ----- 
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 1:40 PM
Subject: Re: [Seamoby] [CARD Editorial Issue] Standards Language


> Even though the protocol is not a standard, wouldn't it make the protocol
> clearer?
>
> Eunsoo
>
> ----- Original Message -----
> From: "James Kempf" <kempf@docomolabs-usa.com>
> To: <seamoby@ietf.org>
> Sent: Tuesday, July 01, 2003 2:16 PM
> Subject: [Seamoby] [CARD Editorial Issue] Standards Language
>
>
> > This draft is meant to be an experimental RFC. Therefore, it should not
> use
> > standards language (MUST/SHALL, etc.).
> >
> >             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 Jul  1 19: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 TAA21604
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19: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 19XV1b-0006D9-1v
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:59:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nx3fQ023869
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XV1a-0006Cu-VA
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19:59: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 TAA21573
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:58:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XV1Z-0002hu-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:59:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XV1Y-0002hr-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:59:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XV1Z-000694-I2; Tue, 01 Jul 2003 19: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 19XV1J-00067r-VN
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:58:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21552
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:58:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XV1I-0002h5-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:58:44 -0400
Received: from mail.bstormnetworks.com ([209.11.156.50] helo=bsn-mail-01.bstormnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XV1H-0002fh-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:58:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 1 Jul 2003 16:58:25 -0700
Message-ID: <40301581B2962B448690A023EF16DFE1DC5040@bsn-mail-01.bstormnetworks.com>
Thread-Topic: CAPWAP BOF
Thread-Index: AcNALKkV/3tW7WYyQtqKnFPdK6zMjQ==
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: <seamoby@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] CAPWAP BOF
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

FYI

PatC
----
BOF NAME & ACRONYM: Control And Provisioning of Wireless Access Points
                    (capwap)
AREA:               OPS
BOF CHAIR(S):       Dorothy Stanley (dstanley@agere.com)
                    James Kempf (kempf@docomolabs-usa.com)


MAILING LIST:
List:               lwapp@frascone.com
Subscribe:          lwapp-request@frascone.com
Body:               subscribe in Subject line
Archive:            http://mail.frascone.com/pipermail/public/lwapp/


AGENDA:
    Intro and Agenda Bashing (5 min)
    LWAPP (Pat Calhoun) (10 min)
    SNMP (Marcus Brunner) (10 min)
    Accesss Point Discovery (Inderpreet Singh) (10 min).
    Security and Certificate Provisioning (David Molnar) (10 min)
    Discussion (40 min)
    Summary and Next Steps (10 min)


FULL DESCRIPTION:

Conventional IETF wisdom has it that wireless access points for
non-provisioned wireless media are no more than simple Layer 2 bridges
that transparently forward packets between the wired and wireless
links. While this is indeed their primary function, in reality, higher
layer functions have been gradually migrating into such access points.
An example is network access server functionality. Managing this
functionality, its interaction between access points, and between
access points and access routers has become increasingly difficult.
Because some of the functions involve exchange of Layer 2 information,
IETF has traditionally maintained that it is "Not Our Problem". On the
other hand, because many of the functions either use or provide
services with a Layer 3 component, the relevant Layer 2 standardization
bodies (such as IEEE for 802.11) have been reluctant to step forward
and own the problem either.=20

Recently, next generation 802.11 network infrastructure (also referred
to as WLAN switches) have seen significant interest in the market.
Several companies, both startups and incumbents in the WLAN space, have
announced, or are shipping products. Most of these products have a
similar architecture which simplifies the access points, but does not
remove the problem of managing the interaction with the IP network.
Given the interest in the market for such products, there is no doubt
that standardizing the interface between the AP and the controller (or
WLAN switch) would benefit the Internet community. Would defining a new
Layer 2 independent protocol to manage wireless access points both
dynamically and statically help? Can existing IETF solutions contribute,
and, if so, is there any Layer 2 independent work that IETF might do to
adapt those solutions to the problem space?

Wireless access points also have additional security needs that are
ill met by regarding them as simple Layer 2 bridges. Because such
access points are easy to deploy by design, security provisioning is
difficult to achieve. How does the network provider's router verify
that a particular access point is authorized to be on the network?
Wireless access points are also being called upon to provide
increasingly more complex security for hosts, approaching that
provided by the highly provisioned wireless media in cellular
networks. Can the implementation of these functions be simplified by
centralizing the intelligence and distributing the RF interfaces?

In this BOF, we will discuss these issues and attempt to come to some
conclusions about what IETF might or might not do to help address the
problem.

READING LIST:

Lightweight Access Point Protocol

http://www.airespace.com/ftp/draft-calhoun-seamoby-lwapp-03.txt


Proposed Solutions:
TBD

Proposed WG Charter:
TBD



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 20:39: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 TAA21106
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUry-0004yT-FA
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn6bd019112
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUry-0004xv-AQ
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA21000
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrv-0002Qu-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUru-0002Qr-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XUrv-0004v5-UK; Tue, 01 Jul 2003 19: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 19XUrB-0004pc-Gp
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20963
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr9-0002Pq-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqz-0002PH-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:05 -0400
Message-ID: <009f01c3402a$7957b0e0$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 15:20:15 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Editorial Issue] IANA Considerations Section
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In general, ICMP messages do not have options. Messages that are part of
Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.

In this case, there is no need for IETF concensus to assign suboption types
to a new ICMP message. They can just be assigned in the draft.

If you want to have the option types come out of the ND space, then the IANA
considerations should say that.

Also, IETF concensus is not needed to assign a new port number. IANA can do
that.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 20:39: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 TAA21104
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUry-0004y9-B3
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn68v019095
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUry-0004xt-0y
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20998
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrv-0002Qf-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrt-0002Qc-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19: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 19XUrv-0004ta-0m; Tue, 01 Jul 2003 19: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 19XUr3-0004pN-3W
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20956
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUr1-0002PW-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqy-0002PF-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:04 -0400
Message-ID: <009d01c3402a$79177390$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Tue, 1 Jul 2003 14:56:22 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Section 4.2.2 mentions that unsolicited broadcast is possible, why not
multicast? For IPv4, this would require a multicast address,  but for IPv6
it could be done to the All Nodes Multicast address on the link. There is no
broadcast in IPv6, so multicast will be required in that case anyway.

The draft also contains no guidelines about unsolicited. What is the default
intermessage time on broadcast/multicast? What about the port number and
TTL?

Also, I'm not clear about why an unsolicited message needs to be marked. How
would a MN utilize the U flag? How would processing of a solicited v.s.
unsolicited message differ?



            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  1 20:39: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 TAA21065
	for <seamoby-archive@odin.ietf.org>; Tue, 1 Jul 2003 19:49: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 19XUrw-0004wX-8P
	for seamoby-archive@odin.ietf.org; Tue, 01 Jul 2003 19:49:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h61Nn4aM018994
	for seamoby-archive@odin.ietf.org; Tue, 1 Jul 2003 19: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 19XUrw-0004vy-38
	for seamoby-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 19: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 TAA20984
	for <seamoby-web-archive@ietf.org>; Tue, 1 Jul 2003 19:49:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUru-0002QQ-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19:49:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUrs-0002QM-00
	for seamoby-web-archive@ietf.org; Tue, 01 Jul 2003 19: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 19XUrt-0004qc-8X; Tue, 01 Jul 2003 19: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 19XUqz-0004p3-Km
	for seamoby@optimus.ietf.org; Tue, 01 Jul 2003 19:48: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 TAA20945
	for <seamoby@ietf.org>; Tue, 1 Jul 2003 19:48:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XUqx-0002P9-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48: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 19XUqx-0002P5-00
	for seamoby@ietf.org; Tue, 01 Jul 2003 19:48:03 -0400
Message-ID: <009801c3402a$78217ad0$ab6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>, <seamoby@ietf.org>
References: <022b01c3400c$b0802840$6b6015ac@dclkempt40> <024701c34010$f2da8f10$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Tue, 1 Jul 2003 13:47:28 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

What about other nodes on the link? The rate limit is not simply for one
node, but for all. That's why protocols such as RFC 2461 or RFC 260 have
fixed default but configurable limits for the intermessage time. A rate
limit flag allows a host to hog up to the limit before the router starts
dropping.

So it needs two limitiing mechanisms, one on the host (the intermessage
time) and one on the router (selective dropping when the rate increases too
high). The latter doesn't involve the host.

            jak

----- Original Message ----- 
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 1:40 PM
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag


> James,
>
> The advantage of the R flag is that the MN does not have to know the rate
> limit of the access router but can be alarmed when it approaches the rate
> limit. The rate limit can depend on the bandwidth of the link, the
> processing capacity of the access router, etc. The R flag does not require
> predefined rate to be specified in the protocol. Now the rate limit is
fully
> open to the configuration. I think this flexibility is an advantage of the
R
> flag compared to the fixed inter-message interval method.
>
> Dropping packets above the rate limit will be performed by the access
> router. But if the MN does not know the rate limit, it will retransmit its
> request. This retransmission will be just waste of rf bandwidth which we
> like to save. So for the well-behaving MNs, it is good to give them an
alarm
> so that they don't do retransmission.
>
> Eunsoo
>
>
> ----- Original Message -----
> From: "James Kempf" <kempf@docomolabs-usa.com>
> To: <seamoby@ietf.org>
> Sent: Tuesday, July 01, 2003 2:29 PM
> Subject: [Seamoby] [CARD Techical Issue] Rate limiting flag
>
>
> > Last paragraph in in introduction to Section 4 says that the R flag is
> used
> > by the router to indicate to the MN to reduce sending rate of messages.
As
> > far as I know, this type of rate limiting is not done in any other IETF
> > protocol (but I may be missing it).
> >
> > Typically, there are two ways that IETF protocols rate limit that I am
> > familiar with:
> >
> >     - by specifying a constant intermessage time which clients are
> required
> > to abide by
> >     - by having the server (router in this case) drop packets
selectively
> > when traffic gets too heavy
> >
> > The former works for well-behaved hosts, the latter reduces the impact
of
> > DoS attackes.
> >
> > Is there something about CARD that recommends this approach rather than
a
> > standard IETF protocol approach?
> >
> >             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  Wed Jul  2 01:59: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 BAA28811
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 01:59: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 19Xadz-0007Ee-BA
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 01:59:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h625x3rJ027808
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 01:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xadz-0007ER-7W
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 01:59:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28799
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 01:59:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xadv-00069V-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 01:59:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xadv-00069S-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 01:58:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xadw-0007Dl-Vs; Wed, 02 Jul 2003 01: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 19Xad1-0007Cu-HZ
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 01:58: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 BAA28794
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 01:58:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xacy-00067Z-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 01:58:00 -0400
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xacx-00067K-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 01:57:59 -0400
Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173])
  (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA)
  by mail.cs.helsinki.fi with esmtp; Wed, 02 Jul 2003 08:57:59 +0300
Date: Wed, 2 Jul 2003 08:57:58 +0300 (EEST)
From: Jukka MJ Manner <jmanner@cs.Helsinki.FI>
To: Seamoby Working Group <seamoby@ietf.org>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
In-Reply-To: <022b01c3400c$b0802840$6b6015ac@dclkempt40>
Message-ID: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi James,

just a quick example of the use of flag bits: ECN-bits with TCP.

Jukka

On Tue, 1 Jul 2003, James Kempf wrote:

> Last paragraph in in introduction to Section 4 says that the R flag is used
> by the router to indicate to the MN to reduce sending rate of messages. As
> far as I know, this type of rate limiting is not done in any other IETF
> protocol (but I may be missing it).
> 
> Typically, there are two ways that IETF protocols rate limit that I am
> familiar with:
> 
>     - by specifying a constant intermessage time which clients are required
> to abide by
>     - by having the server (router in this case) drop packets selectively
> when traffic gets too heavy
> 
> The former works for well-behaved hosts, the latter reduces the impact of
> DoS attackes.
> 
> Is there something about CARD that recommends this approach rather than a
> standard IETF protocol approach?
> 
>             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  Wed Jul  2 06:45:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01182
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 06:45:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xf6m-0001hp-Nt
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 06:45:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Aj42Q006551
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 06: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 19Xf6m-0001ha-JY
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:45: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 GAA01160
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 06:44:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xf6i-0000wX-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 06:45:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xf6h-0000wU-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 06: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 19Xf6j-0001gk-Fx; Wed, 02 Jul 2003 06: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 19Xf6U-0001fv-Ks
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 06:44:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01144
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 06:44:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xf6Q-0000wC-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 06:44:42 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xf6P-0000vh-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 06:44:41 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h62Ai9VI032720;
	Wed, 2 Jul 2003 12:44:09 +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 5A0E48D362; Wed,  2 Jul 2003 12:27:38 +0200 (CEST)
Message-ID: <3F02B778.60607@ccrle.nec.de>
Date: Wed, 02 Jul 2003 12:44:08 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
References: <009b01c3402a$78e20bb0$ab6015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



James,

it's not a complex negotiation using specific protocol messages,
its discovery by means of setting a flag to indicate to
communication peers the sender's capability to convey CARD signaling
with the FMIP protocol sequence between MN and AR. Now, this indication
is needed for MNs and ARs to learn about whether or not CARD message
options can be appended to RtSolPr and PrRtAdv messages.

Performing CARD, the MN knows already in advance if subsequent 
CARD signaling messages can be appended to FMIP signaling, so, no
explicit discovery of piggybacking capability is required.

To keep FMIP operation in mind when designing the CARD protocol
was advice from the beginning. Now, to not restrict CARD to
FMIP was also discussed here, which is a reasonable design goal.
Why not keeping this flexible and use CARD with FMIP if supported,
otherwise use CARD protocol operation stand-alone by means of
appending the CARD signaling to the specified CARD main header.
Btw., latter approach should be the default operation.

marco
 



James Kempf wrote:

>Section 4.5 describes a negotiation between the MN and AR to determine
>whether CARD is piggybacked on FMIPv6. This negotation seems complex and
>unnecessary. For simplicity, I think we should do one or the other. Though I
>favor piggybacking because it simplifies the entire handover across both
>protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
>handover more complex. Since the DT and WG don't seem to agree, I believe we
>should drop FMIPv6 piggy backing.
>
>            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  Wed Jul  2 06: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 GAA03255
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 06: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 19XfIN-0002xN-AA
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 06:57:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Av3f6011356
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 06: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 19XfIN-0002x1-6X
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06: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 GAA03114
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 06:57:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XfII-0001AY-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 06:56:58 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XfII-0001AV-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 06:56:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XfIK-0002vB-Jt; Wed, 02 Jul 2003 06:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XfHU-0002mE-Gp
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 06:56: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 GAA02814
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 06:56:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XfHQ-00018k-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 06:56:04 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XfHP-00017t-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 06:56:03 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h62AtVVI033531;
	Wed, 2 Jul 2003 12:55:31 +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 C2499AE263; Wed,  2 Jul 2003 12:39:00 +0200 (CEST)
Message-ID: <3F02BA23.70507@ccrle.nec.de>
Date: Wed, 02 Jul 2003 12:55:31 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Editorial Issue] IANA Considerations Section
References: <009f01c3402a$7957b0e0$ab6015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


James Kempf wrote:

>In general, ICMP messages do not have options. Messages that are part of
>Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.
>  
>
Fast-MIPv6 messages are ICMP-style as well, and they carry options.

>In this case, there is no need for IETF concensus to assign suboption types
>to a new ICMP message. They can just be assigned in the draft.
>  
>
This is right assuming the case to keep CARD protocol operation 
stand-alone. In case of carrying
CARD protocol messages as options with the Fast-MIPv6 RtSolPr ot PrRtAdv 
respectively,
there should not be a conflict in options' types.

>If you want to have the option types come out of the ND space, then the IANA
>considerations should say that.
>  
>
That's another issue: In case we allow other protocols to carry CARD 
specific options, as currently
discussed for Fast-MIPv6, actually we could allow some ND protocol 
messages to carry them as well,
like the Router Solicitation and Advertisement. This is to be discussed now.
If this should be supported, we can take this over to the IANA section.

>Also, IETF concensus is not needed to assign a new port number. IANA can do
>that.
>
Ok, we can change this in the draft.

marco

>
>            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  Wed Jul  2 09:13: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 JAA15189
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:13: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 19XhQ3-00006m-48
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:13:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62DD7TT000409
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:13:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XhQ3-00006W-1B
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:13: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 JAA15174
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:13:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhQ1-0005SU-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:13:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhQ0-0005SR-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:13:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XhPx-000067-1I; Wed, 02 Jul 2003 09: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 19XhPp-00005o-Nu
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:12: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 JAA15170
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:12:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhPo-0005SI-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:12:52 -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 19XhPn-0005SF-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:12:51 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 2 Jul 2003 09:12:51 -0400
Message-ID: <001f01c3409b$dd98e800$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <009c01c3402a$78fd82f0$ab6015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Technical Issue]Static v.s. dynamic attributes
Date: Wed, 2 Jul 2003 09:14:27 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 02 Jul 2003 13:12:51.0285 (UTC) FILETIME=[A40BC850:01C3409B]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Initially 32 bits were assigned for the lifetime field in the AVP format.
But we realized that many attributes would be static and the 32 bits would
be waste of bandwidth for those attributes. If the CARD reply contains 10
static attributes, the waste becomes 320 bits.
So, for bandwidth efficiency, we made the lifetime field as optional. Since
the value format depends on each attribute type, having the lifetime field
as a part of the value field does not seem to add much complexity to the
implementation.

Anyway there is tradeoff between bandwidth efficiency and additional
complexity of the implementation. What do others think?

Eunsoo

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 5:46 PM
Subject: [Seamoby] [CARD Technical Issue]Static v.s. dynamic attributes


> Section 5.1.4 specifies a flag to indicate whether an attribute is static
or
> dynamic. How about using a lifetime of zero to indicate this? No real
> lifetime is going to be advertised as zero, and this allows the AVP code
to
> take up a byte, and the lifetime field is always there, making the message
> easier to process.
>
>             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  Wed Jul  2 09:24: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 JAA16236
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:24: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 19Xhad-0000VA-2r
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:24:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62DO34p001927
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:24:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xhad-0000V0-0C
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:24: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 JAA16168
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:23:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xhab-0005sS-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:24:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xhaa-0005sP-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:24:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xhaa-0000UJ-Jn; Wed, 02 Jul 2003 09: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 19XhaN-0000U0-Gw
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:23: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 JAA16149
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:23:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhaL-0005s6-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:23: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 19XhaL-0005s2-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:23:45 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 2 Jul 2003 09:23:44 -0400
Message-ID: <002601c3409d$632f6740$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <009d01c3402a$79177390$ab6015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
Date: Wed, 2 Jul 2003 09:25:21 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 02 Jul 2003 13:23:44.0959 (UTC) FILETIME=[29AA84F0:01C3409D]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> Section 4.2.2 mentions that unsolicited broadcast is possible, why not
> multicast? For IPv4, this would require a multicast address,  but for IPv6
> it could be done to the All Nodes Multicast address on the link. There is
no
> broadcast in IPv6, so multicast will be required in that case anyway.
>
[eunsoo] Multicast is fine with me.

> The draft also contains no guidelines about unsolicited. What is the
default
> intermessage time on broadcast/multicast? What about the port number and
> TTL?
>
[eunsoo] Since it is the AR that sends the unsolicited CARD replies, the
transmission rate will depend on the configuration. We tried to avoid
recommending an arbitrary number as default values without base.

The same port number as the solicited CARD reply is used for the unsolicted
CARD reply.

What do you think would be the proper TTL for the unsolicited CARD reply? I
thought TTL 1 should be fine between MN-AR.

> Also, I'm not clear about why an unsolicited message needs to be marked.
How
> would a MN utilize the U flag? How would processing of a solicited v.s.
> unsolicited message differ?
>
>

For solicited CARD replies, the receiver needs to match the reply to the
request by the sequence number. For unsolicited replies, there is no
matching request and thus the receiver should be able to distinguish the
unsolicted replies from the solicited ones.

Eunsoo


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 09:26: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 JAA16558
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:26: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 19XhcZ-0000gu-7r
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:26:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62DQ3kX002650
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:26:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XhcZ-0000gf-3n
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:26: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 JAA16500
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:25:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhcX-0005zn-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:26:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhcW-0005zk-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:26:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XhcX-0000dy-Cy; Wed, 02 Jul 2003 09: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 19XhbY-0000Zh-88
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:25:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16365
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:24:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhbW-0005wN-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:24:58 -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 19XhbV-0005wK-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:24:58 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 2 Jul 2003 09:24:57 -0400
Message-ID: <002f01c3409d$8e514600$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <009a01c3402a$78c69470$ab6015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Editorial Issue] Terminological Consistency
Date: Wed, 2 Jul 2003 09:26:33 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 02 Jul 2003 13:24:57.0318 (UTC) FILETIME=[54CBA060:01C3409D]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks for pointing out the problem.
Please let us walk through the draft again.

Eunsoo

----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Sent: Tuesday, July 01, 2003 5:22 PM
Subject: [Seamoby] [CARD Editorial Issue] Terminological Consistency


> The CARD draft needs a walk through for terminological consistency. For
> example, Section 4.3.1 uses the term CARD table and CAR table for the
table
> of candidate access routers.
>
>             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  Wed Jul  2 09:48: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 JAA18734
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:48: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 19Xhxu-0001un-30
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:48:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Dm68v007353
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:48:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xhxt-0001uW-Ti
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:48: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 JAA18653
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:48:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xhxr-0006sO-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:48:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xhxq-0006sL-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:48:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xhxo-0001tU-UP; Wed, 02 Jul 2003 09:48:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XhxT-0001t6-7k
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:47: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 JAA18602
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:47:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhxR-0006rE-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:47:37 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XhxQ-0006q2-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:47:36 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h62Dl2VI047366;
	Wed, 2 Jul 2003 15:47: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 67560B3B49; Wed,  2 Jul 2003 15:30:30 +0200 (CEST)
Message-ID: <3F02E256.2060509@ccrle.nec.de>
Date: Wed, 02 Jul 2003 15:47:02 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <eunsoo@nec-labs.com>
Cc: James Kempf <kempf@docomolabs-usa.com>, seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Technical Issue]Static v.s. dynamic attributes
References: <009c01c3402a$78fd82f0$ab6015ac@dclkempt40> <001f01c3409b$dd98e800$ca6b0f8a@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree that gain in dropping the lifetime field when describing
static capability parameters is significant and worth looking at
a specific flag to optimize the message and avoid redundancy.
I don't think that setting and processing of the "S"-flag (static)
in capability AVPs introduces additional complexity, neither
in the protocol description, nor from implementation point of view.

marco 

Eunsoo Shim wrote:

>Initially 32 bits were assigned for the lifetime field in the AVP format.
>But we realized that many attributes would be static and the 32 bits would
>be waste of bandwidth for those attributes. If the CARD reply contains 10
>static attributes, the waste becomes 320 bits.
>So, for bandwidth efficiency, we made the lifetime field as optional. Since
>the value format depends on each attribute type, having the lifetime field
>as a part of the value field does not seem to add much complexity to the
>implementation.
>
>Anyway there is tradeoff between bandwidth efficiency and additional
>complexity of the implementation. What do others think?
>
>Eunsoo
>
>----- Original Message -----
>From: "James Kempf" <kempf@docomolabs-usa.com>
>To: <seamoby@ietf.org>
>Sent: Tuesday, July 01, 2003 5:46 PM
>Subject: [Seamoby] [CARD Technical Issue]Static v.s. dynamic attributes
>
>
>  
>
>>Section 5.1.4 specifies a flag to indicate whether an attribute is static
>>    
>>
>or
>  
>
>>dynamic. How about using a lifetime of zero to indicate this? No real
>>lifetime is going to be advertised as zero, and this allows the AVP code
>>    
>>
>to
>  
>
>>take up a byte, and the lifetime field is always there, making the message
>>easier to process.
>>
>>            jak
>>
>>
>>_______________________________________________
>>Seamoby mailing list
>>Seamoby@ietf.org
>>https://www1.ietf.org/mailman/listinfo/seamoby
>>
>>    
>>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>




_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 09:52: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 JAA19092
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:52: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 19Xi1j-0002As-2k
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:52:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Dq3ak008352
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:52:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xi1i-0002Ad-SJ
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09: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 JAA19064
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:51:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi1g-00072V-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:52:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi1g-00072S-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:52:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xi1h-00029x-LI; Wed, 02 Jul 2003 09:52:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xi0n-00029S-QQ
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:51:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19002
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:51:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi0l-00070m-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:51:04 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi0k-0006zD-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:51:03 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h62DoTVI047654;
	Wed, 2 Jul 2003 15:50: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 7F0FAB3FF8; Wed,  2 Jul 2003 15:33:57 +0200 (CEST)
Message-ID: <3F02E325.1030901@ccrle.nec.de>
Date: Wed, 02 Jul 2003 15:50:29 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Editorial Issue] Terminological Consistency
References: <009a01c3402a$78c69470$ab6015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks for the hint. Should be consistently "CAR table".

marco

James Kempf wrote:

>The CARD draft needs a walk through for terminological consistency. For
>example, Section 4.3.1 uses the term CARD table and CAR table for the table
>of candidate access routers.
>
>            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  Wed Jul  2 09:57: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 JAA19803
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:57: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 19Xi6Y-0002dP-Vb
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:57:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Dv2H9010121
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09: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 19Xi6Y-0002dA-Si
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:57: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 JAA19716
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:56:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi6W-0007G3-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:57:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi6W-0007G0-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09: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 19Xi6X-0002cP-NV; Wed, 02 Jul 2003 09: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 19Xi5e-0002X6-4F
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09: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 JAA19546
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:56:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi5b-0007DE-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:56:03 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi5Z-0007Co-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:56:01 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h62Dtwj1003763
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 06:55:58 -0700 (MST)
Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h62DtujL027392
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 08:55:56 -0500
Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <N9TP89TG>; Wed, 2 Jul 2003 08:55:56 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD604F@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'James Kempf'" <kempf@docomolabs-usa.com>, seamoby@ietf.org
Subject: RE: [Seamoby] Candidate for New WG Draft
Date: Wed, 2 Jul 2003 08:55:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain;
	charset="iso-8859-1"
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi James,

I may support a QoS CT draft. I generally think with QoS you may get 
bigger audience. Not a great percentage of population understands
the intricates of the HC protocols, plus that HC CT involves the most
challenging problems of all contexts in CT, so it might scare too many
people off, but it is up to you guys. Personally trying to design a CTP,
I was facing the toughest issues when thinking about HC.

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, June 24, 2003 1:18 PM
To: seamoby@ietf.org
Subject: [Seamoby] Candidate for New WG Draft


Folks,

As a compliment to the CT draft, Pat and I think it would be sensible to
have a draft that describes how CT could be used for a particular context.
In the past, Seamoby has not focussed on this, since our position has been
it is up to other WGs that have responsibility for the particular feature to
do the design work for that feature, but we keep getting the question "give
me a concrete example of what CT would be used *for*?" We'd rather not
include this in the base CT draft, because then people would think that it
is required to implement that particular context when implementing the
transfer protocol. So, since transfer of header compression context is the
candidate easiest for people unfamiliar with CT to understand, we'd like to
recommend that the WG consider the following draft for WG draft status:

    http://www.geocities.com/kempf42/draft-koodli-seamoby-hc-relocate-02.txt

This is a draft that was originally submitted two years ago and expired. It
defines a way to transfer ROHC header context between access routers. The
original draft defined its own CT protocol. In this update, Manish Tiwari
has agreed to act as editor and has modified the protocol to use the Seamoby
CT protocol defined in draft-ietf-seamoby-ctp-02.txt.

The draft was submitted to the drafts editor yesterday, but after the 00
deadline. It isn't clear whether the drafts editor will consider it a 00
draft (since the original expired), in which case, the draft won't be
accepted until after IETF 57, or a continuation of the original, in which
case, the draft will show up in the drafts directory prior to IETF 57. In
any case, we'd like to encourage people to read the draft and comment on the
mailing list. Manish will discuss mailing list comments at IETF 57 and we'll
see whether the WG thinks the draft is a good candidate for WG draft status.
If we do decide to accept it, Pat and I (with Allison's help) will recruit
some reviewers from the ROHC list to make sure the header compression
details are correct.

Please give the draft a good read and comment to the list. Thanx.

            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  Wed Jul  2 09:59: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 JAA20078
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 09:59: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 19Xi8W-0002zR-9H
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 09:59:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Dx4hc011487
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 09:59:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xi8W-0002zC-4e
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:59: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 JAA19989
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 09:58:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi8S-0007OK-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:59:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi8S-0007OH-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 09:59:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xi8S-0002yM-Hv; Wed, 02 Jul 2003 09: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 19Xi8C-0002wX-4Q
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 09:58:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19913
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 09:58:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi89-0007M8-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:58:41 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xi87-0007Le-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 09:58:39 -0400
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h62DwRNg028358
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 06:58:27 -0700 (MST)
Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
	by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h62DwPxE014018
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 08:58:25 -0500
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <N9T7DD14>; Wed, 2 Jul 2003 08:58:25 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD6050@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Charlie Perkins'" <charliep@iprg.nokia.com>,
        Jukka MJ Manner
	 <jmanner@cs.Helsinki.FI>
Cc: Seamoby Working Group <seamoby@ietf.org>
Subject: RE: [Seamoby] Candidate for New WG Draft
Date: Wed, 2 Jul 2003 08:58:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Well, I wrote my previous email not going through the thread,
but I am glad there are others feeling the same way.

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Friday, June 27, 2003 12:46 AM
To: Jukka MJ Manner
Cc: Seamoby Working Group
Subject: Re: [Seamoby] Candidate for New WG Draft



Hello Jukka,

I agree with you that QoS context transfer is a crucial piece.
In fact, in a way the QoS support was one of my main
motivating factors for working on this problem.  I'm happy
to say that we have achieved a certain degree of success
with our prototype.

However, it may be procedurally impossible to publish a document
towards that goal within seamoby.  I would definitely support
putting this work item on the charter, but it seems to me that the
goal of the authority structures surrounding seamoby is to shut
down the working group, for whatever reason (I do not understand).

Maybe the work should proceed in another working group exactly
like seamoby, but with more enthusiastic IESG support.  I'm not sure
how to engender that result, though.

Regards,
Charlie P.



Jukka MJ Manner wrote:

>Hi,
>
>I have tried for the last years to figure out how
>seamless/smooth/fast/[your favorite term here] handovers with QoS support
>can in real life be accomplished. I personally have come to the conclusion
>that although QoS and mobility management mechanisms seem to be somewhat
>in order, a CT framework would be the "final blow" in the whole system.
>More specifically, being able to do CT for IPSec and AAA is THE key, well,
>to me at least.
>
>Thus, I would like to see a WG guide on how you do IPSec and AAA CT, and 
>how you couple that with the applications using the security mechanisms, 
>for example, RSVP and a given mobility management mechanism.
>
>To go to the point, finaly, I would like the see the mentioned Seamoby
>"user guide" for CT, but it should also include the mentioned two
>additional use cases. I know that Seamoby is trying to close the work, but
>I think it might still be a good idea to try to write such an
>informational document.
>
>My 2 cents,
>Jukka
>
>On Thu, 26 Jun 2003, James Kempf wrote:
>
>  
>
>>Jukka
>>
>>    
>>
>>>I haven't reviewed the draft yet, but it might be a good idea to have in
>>>Seamoby something like the DCCP User Guide draft. Something that tells
>>>more than RFC3374.
>>>      
>>>
>>I took a very quick look at draft-ietf-dccp-user-guide-00.txt and I could
>>see some benefit in a similar document for CTP, though, since the intent is
>>to take CTP to experimental (unlike DCCP) I don't think such a document is
>>needed right now. Remember, the intent of the header compression CT draft is
>>to provide a concrete example of real value that would come out of CT, since
>>some people (and in particular some IESG members and some members of the
>>Seamoby CT review board) are skeptical. A User's Guide assumes that people
>>already see the value of the protocol, and is primarily about how to use it.
>>
>>What do other people think?
>>
>>    
>>
>>>Still, the document should talk about more than one use
>>>case, though.
>>>
>>>      
>>>
>>I'm not quite sure I understand. Are you proposing that specifications for
>>multiple different kinds of contexts should be included into one draft? If
>>yes, this sounds a bit impractical to me. If I am, say, interested in
>>implementing context transfer for header compression, why should I have to
>>wade through a document that describes context transfer for AAA, and IPsec,
>>and... Small, focussed specifications tend to do better in IETF, and they
>>are also easier to review and achieve concensus on approval. Although we
>>want the header compression CT document as a concrete example, it will also
>>serve as the (experimental) reference specification for implementing a
>>header compression context and will be used for that purpose.
>>
>>            jak
>>
>>
>>    
>>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 11:38: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 LAA27170
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 11:38: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 19XjgK-0007dd-1t
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 11:38:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Fc4Tf029355
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 11:38:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XjgJ-0007dO-Ns
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:38: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 LAA27136
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 11:38:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XjgI-0002OY-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:38:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XjgI-0002OV-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:38:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XjgG-0007cR-Ss; Wed, 02 Jul 2003 11:38:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XjgE-0007bR-Fa
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 11:37:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27132
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 11:37:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XjgD-0002OP-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:37:57 -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 19XjgC-0002OM-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:37:56 -0400
Message-ID: <007a01c340af$27144480$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Wed, 2 Jul 2003 08:32:30 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>
> just a quick example of the use of flag bits: ECN-bits with TCP.
>

Ok, so it sounds as if there is a precedent. But I'm wondering if the case
here is the same. Wouldn't a host-based mechanism, in which the host is
required to limit the intermessage time, be simpler?

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 11:52: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 LAA28180
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 11:52: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 19Xjtr-00010F-Ve
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 11:52:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Fq3sM003849
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 11:52:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xjtr-000100-Sa
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:52: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 LAA28103
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 11:52:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjtq-0002k3-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:52:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjtq-0002k0-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:52:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xjtq-0000z5-5o; Wed, 02 Jul 2003 11: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 19Xjt3-0000y1-Hk
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 11:51:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28098
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 11:51:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjt2-0002jP-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:51:12 -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 19Xjt1-0002jM-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:51:11 -0400
Message-ID: <00c501c340b1$02328440$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
Cc: <seamoby@ietf.org>
References: <009b01c3402a$78e20bb0$ab6015ac@dclkempt40> <3F02B778.60607@ccrle.nec.de>
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
Date: Wed, 2 Jul 2003 08:45:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Marco,

What I specifically had in mind by "complex" was this.

Suppose CARD was defined to just work with FMIP. Then there would be no need
for setting the flag and sending an initial CARD Request/CARD Reply to
determine if piggybacking was supported. The MN would simply use FMIP, and
if the AR didn't return anything, it would know that the AR is not CARD
capable. This is very simple.

Now, suppose that piggybacking was not supported. The MN sends CARD Request
and if it gets a CARD Reply it knows that CARD is supported, it can use the
CARD protocol. This is also very simple (though more complex than the FMIP
case because there are two protocols instead of one).

With the current design, the MN must negotiate and choose which to use.
Perhaps "complex" was too strong a word, but it is an extra bit of protocol
that could be simplified.


            jak

PS: I still believe that interoperability with FMIP is desirable, but I
think its more important now to simplify things to reduce the chances of the
draft getting caught in the IESG's lint filter. I would like to see this
draft sail through the IESG.

----- Original Message ----- 
From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: <seamoby@ietf.org>
Sent: Wednesday, July 02, 2003 3:44 AM
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking


>
>
> James,
>
> it's not a complex negotiation using specific protocol messages,
> its discovery by means of setting a flag to indicate to
> communication peers the sender's capability to convey CARD signaling
> with the FMIP protocol sequence between MN and AR. Now, this indication
> is needed for MNs and ARs to learn about whether or not CARD message
> options can be appended to RtSolPr and PrRtAdv messages.
>
> Performing CARD, the MN knows already in advance if subsequent
> CARD signaling messages can be appended to FMIP signaling, so, no
> explicit discovery of piggybacking capability is required.
>
> To keep FMIP operation in mind when designing the CARD protocol
> was advice from the beginning. Now, to not restrict CARD to
> FMIP was also discussed here, which is a reasonable design goal.
> Why not keeping this flexible and use CARD with FMIP if supported,
> otherwise use CARD protocol operation stand-alone by means of
> appending the CARD signaling to the specified CARD main header.
> Btw., latter approach should be the default operation.
>
> marco
>
>
>
>
> James Kempf wrote:
>
> >Section 4.5 describes a negotiation between the MN and AR to determine
> >whether CARD is piggybacked on FMIPv6. This negotation seems complex and
> >unnecessary. For simplicity, I think we should do one or the other.
Though I
> >favor piggybacking because it simplifies the entire handover across both
> >protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
> >handover more complex. Since the DT and WG don't seem to agree, I believe
we
> >should drop FMIPv6 piggy backing.
> >
> >            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  Wed Jul  2 11:58: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 LAA28478
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 11:58: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 19Xjze-0001bi-SP
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 11:58:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Fw2hB006172
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 11:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xjze-0001bT-Nl
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:58: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 LAA28443
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 11:57:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjzd-0002sO-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:58:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjzd-0002sL-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 11:58:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xjzd-0001a2-An; Wed, 02 Jul 2003 11:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xjyi-0001Yx-Fs
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 11:57: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 LAA28403
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 11:57:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xjyh-0002rD-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:57: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 19Xjyg-0002r9-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 11:57:02 -0400
Message-ID: <00cf01c340b1$d2cdaf30$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
Cc: <seamoby@ietf.org>
References: <009f01c3402a$7957b0e0$ab6015ac@dclkempt40> <3F02BA23.70507@ccrle.nec.de>
Subject: Re: [Seamoby] [CARD Editorial Issue] IANA Considerations Section
Date: Wed, 2 Jul 2003 08:51:37 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> >In general, ICMP messages do not have options. Messages that are part of
> >Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.
> >
> >
> Fast-MIPv6 messages are ICMP-style as well, and they carry options.
>

Please show me in RFC 2463 where general ICMP messages are allowed to carry
options.

RFC 2461 does define options for the specific case of neighbor discovery
ICMP messages, in Section 4.6. And, I believe the RtSolPr/PrRtAdv messages
are intended to be a subset of those messages.

> >In this case, there is no need for IETF concensus to assign suboption
types
> >to a new ICMP message. They can just be assigned in the draft.
> >
> >
> This is right assuming the case to keep CARD protocol operation
> stand-alone. In case of carrying
> CARD protocol messages as options with the Fast-MIPv6 RtSolPr ot PrRtAdv
> respectively,
> there should not be a conflict in options' types.
>

So does RFC 2461 say that IETF concensus is required to assign option
numbers for ND options?

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 12:04: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 MAA28838
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 12:04: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 19Xk5U-0002YB-Gm
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 12:04:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62G44Bc009797
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 12:04:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xk5U-0002Xw-Cn
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:04: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 MAA28810
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 12:04:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xk5T-00031G-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 12:04:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xk5S-00031C-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 12:04:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xk5R-0002W7-1G; Wed, 02 Jul 2003 12:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xk4f-0002Sd-KJ
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 12:03:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28773
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 12:03:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xk4e-0002zy-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 12:03:12 -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 19Xk4a-0002zS-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 12:03:11 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 2 Jul 2003 12:02:39 -0400
Message-ID: <009801c340b3$9594b3a0$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>,
        "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI> <007a01c340af$27144480$636015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Wed, 2 Jul 2003 12:04:14 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 02 Jul 2003 16:02:39.0136 (UTC) FILETIME=[5C7A7A00:01C340B3]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

James,

As said earlier, the bit makes the protocol flexible without major
additional complexity.
The value of flexibility is worth adding the one-bit flag, I think.
Also I guess the MNs would be need CARD information near handoff in most
cases.
That is, the CARD message traffic would be bursty to individual MN. Setting
a large inter-message time may not be desirable. Also allowing a too short
inter-message time is not desirable, either. So the inter-message time
should be configurable. Then the MN should be informed about the vale which
could be different at different ARs. This brings additional complexity,
which the R flag can make unnecessary.
So I think there are significant advantages with the R flag.

Eunsoo


> > just a quick example of the use of flag bits: ECN-bits with TCP.
> >
>
> Ok, so it sounds as if there is a precedent. But I'm wondering if the case
> here is the same. Wouldn't a host-based mechanism, in which the host is
> required to limit the intermessage time, be simpler?
>
>             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  Wed Jul  2 12:10: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 MAA29066
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 12:10: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 19XkBH-000370-G9
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 12:10:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62GA3gU011956
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 12:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XkBH-00036l-Cr
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:10: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 MAA29052
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 12:09:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XkBG-00037o-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 12:10:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XkBF-00037l-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 12:10:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XkBF-000365-NN; Wed, 02 Jul 2003 12:10:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XkAY-000356-1I
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 12:09: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 MAA29023
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 12:09:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XkAW-000372-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 12:09:16 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XkAW-00036Z-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 12:09:16 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h62G8hVI058781;
	Wed, 2 Jul 2003 18:08:43 +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 193D4134BD; Wed,  2 Jul 2003 17:52:10 +0200 (CEST)
Message-ID: <3F03038A.9080400@ccrle.nec.de>
Date: Wed, 02 Jul 2003 18:08:42 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
References: <009b01c3402a$78e20bb0$ab6015ac@dclkempt40> <3F02B778.60607@ccrle.nec.de> <00c501c340b1$02328440$636015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

James,

I see, but I am not sure if a "try-and-error" mechanism for discovery is
much better, in particular since this procedure needs to be performed
with each AR the MN attaches to, right?
This is simpler with the current mechanism, since the MN knows in advance
if it will suceed with performing CARD via FMIP or not with its next AR.
If not, then the MN can use the stand-alone CARD mechanism. In your example
it should be distinguished between "piggybacking capable" and "CARD capable"
nodes. Only the first support can be identified with the P-flag.

marco



James Kempf wrote:

>Marco,
>
>What I specifically had in mind by "complex" was this.
>
>Suppose CARD was defined to just work with FMIP. Then there would be no need
>for setting the flag and sending an initial CARD Request/CARD Reply to
>determine if piggybacking was supported. The MN would simply use FMIP, and
>if the AR didn't return anything, it would know that the AR is not CARD
>capable. This is very simple.
>
>Now, suppose that piggybacking was not supported. The MN sends CARD Request
>and if it gets a CARD Reply it knows that CARD is supported, it can use the
>CARD protocol. This is also very simple (though more complex than the FMIP
>case because there are two protocols instead of one).
>
>With the current design, the MN must negotiate and choose which to use.
>Perhaps "complex" was too strong a word, but it is an extra bit of protocol
>that could be simplified.
>
>
>            jak
>
>PS: I still believe that interoperability with FMIP is desirable, but I
>think its more important now to simplify things to reduce the chances of the
>draft getting caught in the IESG's lint filter. I would like to see this
>draft sail through the IESG.
>
>----- Original Message ----- 
>From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
>To: "James Kempf" <kempf@docomolabs-usa.com>
>Cc: <seamoby@ietf.org>
>Sent: Wednesday, July 02, 2003 3:44 AM
>Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
>
>
>  
>
>>James,
>>
>>it's not a complex negotiation using specific protocol messages,
>>its discovery by means of setting a flag to indicate to
>>communication peers the sender's capability to convey CARD signaling
>>with the FMIP protocol sequence between MN and AR. Now, this indication
>>is needed for MNs and ARs to learn about whether or not CARD message
>>options can be appended to RtSolPr and PrRtAdv messages.
>>
>>Performing CARD, the MN knows already in advance if subsequent
>>CARD signaling messages can be appended to FMIP signaling, so, no
>>explicit discovery of piggybacking capability is required.
>>
>>To keep FMIP operation in mind when designing the CARD protocol
>>was advice from the beginning. Now, to not restrict CARD to
>>FMIP was also discussed here, which is a reasonable design goal.
>>Why not keeping this flexible and use CARD with FMIP if supported,
>>otherwise use CARD protocol operation stand-alone by means of
>>appending the CARD signaling to the specified CARD main header.
>>Btw., latter approach should be the default operation.
>>
>>marco
>>
>>
>>
>>
>>James Kempf wrote:
>>
>>    
>>
>>>Section 4.5 describes a negotiation between the MN and AR to determine
>>>whether CARD is piggybacked on FMIPv6. This negotation seems complex and
>>>unnecessary. For simplicity, I think we should do one or the other.
>>>      
>>>
>Though I
>  
>
>>>favor piggybacking because it simplifies the entire handover across both
>>>protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
>>>handover more complex. Since the DT and WG don't seem to agree, I believe
>>>      
>>>
>we
>  
>
>>>should drop FMIPv6 piggy backing.
>>>
>>>           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  Wed Jul  2 16:54: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 QAA16690
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 16:54: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 19XocI-0005Wr-T3
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 16:54:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KsE77021249
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 16:54:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XocI-0005We-Po
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:54: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 QAA16592
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 16:54:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XocE-0000GV-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 16:54:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XocD-0000GM-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 16:54:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xoc5-0005WG-80; Wed, 02 Jul 2003 16: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 19XfC9-0001wK-KQ
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 06:50:37 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01413;
	Wed, 2 Jul 2003 06:50:32 -0400 (EDT)
Message-Id: <200307021050.GAA01413@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, 02 Jul 2003 06:50:32 -0400
Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-protocol-02.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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF.

	Title		: Candidate Access Router Discovery
	Author(s)	: M. Liebsch et al.
	Filename	: draft-ietf-seamoby-card-protocol-02.txt
	Pages		: 49
	Date		: 2003-7-1
	
To enable seamless IP-layer handover of a mobile node (MN) from one
access router (AR) to another, the MN is required to discover the
identities of candidate ARs (CARs) for handover, along with their
capabilities, prior to the initiation of the IP-layer handover. The
act of discovery of CARs has two aspects to it: Identifying the IP
addresses of the CARs and finding the capabilities of those CARs.
This process is called 'candidate access router discovery' (CARD).
At the time of IP-layer handover, that CAR, whose capabilities is a
good match to the preferences of the MN, may be chosen as the target
AR for handover. The protocol described in this document allows a
mobile node to perform CARD.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-seamoby-card-protocol-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-seamoby-card-protocol-02.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-7-1133540.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-card-protocol-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-card-protocol-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-7-1133540.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 Jul  2 18:00: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 SAA21942
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 18:00: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 19Xpe3-0008RK-N6
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 18:00:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62M075J032442
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 18:00:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xpe3-0008RB-Jm
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 18:00: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 SAA21886
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 18:00:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xpdy-0002Jw-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18:00:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xpdy-0002Jt-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18: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 19Xpdx-0008QF-Tl; Wed, 02 Jul 2003 18:00:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xpd2-0008P4-Q7
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 17:59: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 RAA21768
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 17:58:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xpcy-0002HK-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 17:59:00 -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 19Xpcx-0002HF-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 17:58:59 -0400
Message-ID: <02de01c340e4$659e2510$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>, <seamoby@ietf.org>
References: <009d01c3402a$79177390$ab6015ac@dclkempt40> <002601c3409d$632f6740$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
Date: Wed, 2 Jul 2003 14:53:39 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> > The draft also contains no guidelines about unsolicited. What is the
> default
> > intermessage time on broadcast/multicast? What about the port number and
> > TTL?
> >
> [eunsoo] Since it is the AR that sends the unsolicited CARD replies, the
> transmission rate will depend on the configuration. We tried to avoid
> recommending an arbitrary number as default values without base.
>

A default rate must be specified. The IESG will insist on this. See RFC 2608
for an example.

> The same port number as the solicited CARD reply is used for the
unsolicted
> CARD reply.
>

OK.

> What do you think would be the proper TTL for the unsolicited CARD reply?
I
> thought TTL 1 should be fine between MN-AR.
>

If you make it 255, then the reply must have come from a node on the same
link. This is a cheap way to prevent an offlink attacker from sending bogus
CARD replies. RFC 2461 uses this technique. The node should reject the
message if the TTL is not 255.

> > Also, I'm not clear about why an unsolicited message needs to be marked.
> How
> > would a MN utilize the U flag? How would processing of a solicited v.s.
> > unsolicited message differ?
> >
> >
>
> For solicited CARD replies, the receiver needs to match the reply to the
> request by the sequence number. For unsolicited replies, there is no
> matching request and thus the receiver should be able to distinguish the
> unsolicted replies from the solicited ones.
>

How are replay attacks prevented in the multicast case?

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 18:12: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 SAA24223
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 18:12: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 19Xppd-00016Y-B8
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 18:12:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MC5Zl004240
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 18: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 19Xppd-00016J-7h
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 18: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 SAA24124
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 18:11:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XppY-0002n2-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18:12:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XppX-0002mx-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18:11:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xppa-00012x-DH; Wed, 02 Jul 2003 18:12:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xpp8-00011h-32
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 18:11:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24049
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 18:11:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xpp3-0002ld-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 18:11:29 -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 19Xpp2-0002lR-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 18:11:28 -0400
Message-ID: <030f01c340e6$216aa9c0$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>,
        "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI> <007a01c340af$27144480$636015ac@dclkempt40> <009801c340b3$9594b3a0$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Wed, 2 Jul 2003 15:06:04 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> As said earlier, the bit makes the protocol flexible without major
> additional complexity.
> The value of flexibility is worth adding the one-bit flag, I think.
> Also I guess the MNs would be need CARD information near handoff in most
> cases.
> That is, the CARD message traffic would be bursty to individual MN.
Setting
> a large inter-message time may not be desirable. Also allowing a too short
> inter-message time is not desirable, either. So the inter-message time
> should be configurable. Then the MN should be informed about the vale
which
> could be different at different ARs. This brings additional complexity,
> which the R flag can make unnecessary.
> So I think there are significant advantages with the R flag.
>

I'm not arguing whether the inter-message time should be configurable, just
that a default should be included and that it should be configurable.

The problem here is that protocols which operate on the local link, like RFC
2461, typically have explicit intermessage times, whereas end to end
protocols such as TCP (with ECN) do have explicit rate control. This
protocol is more like the former.

I don't see that a rate flag makes the protocol any more or less flexible
than having an explicit intermessage time enforced by the host, if the
intermessage time is configurable. In either case, the protocol depends on
the host to enforce the rate control.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 18:17: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 SAA25327
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 18:17: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 19XpuR-0001UK-I9
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 18:17:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MH3BX005714
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 18:17:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XpuR-0001U5-Eq
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 18:17:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25231
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 18:16:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XpuM-00034O-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18:16:58 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19XpuL-00034L-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 18:16:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19XpuO-0001TW-Uj; Wed, 02 Jul 2003 18: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 19XpuF-0001TG-KL
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 18:16: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 SAA25195
	for <seamoby@ietf.org>; Wed, 2 Jul 2003 18:16:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19XpuA-00033k-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 18:16: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 19Xpu9-00033g-00
	for seamoby@ietf.org; Wed, 02 Jul 2003 18:16:45 -0400
Message-ID: <031501c340e6$ded9b050$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
Cc: <seamoby@ietf.org>
References: <009b01c3402a$78e20bb0$ab6015ac@dclkempt40> <3F02B778.60607@ccrle.nec.de> <00c501c340b1$02328440$636015ac@dclkempt40> <3F03038A.9080400@ccrle.nec.de>
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking
Date: Wed, 2 Jul 2003 15:11:21 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I see, but I am not sure if a "try-and-error" mechanism for discovery is
> much better, in particular since this procedure needs to be performed
> with each AR the MN attaches to, right?
> This is simpler with the current mechanism, since the MN knows in advance
> if it will suceed with performing CARD via FMIP or not with its next AR.
> If not, then the MN can use the stand-alone CARD mechanism. In your
example
> it should be distinguished between "piggybacking capable" and "CARD
capable"
> nodes. Only the first support can be identified with the P-flag.
>

OK, I think I see your point.

We've decided not to allow piggybacking in CTP, though it might be useful
later. It would be good if we could at least have *some* consistency between
the two protocols (after all, they are coming out of the same WG).

I still think it would be good to leave it out, for simplicity. Maybe we
could put a statement in saying "Whether or not to piggyback CARD on other
protocols should be allowed is a research question open for experiment." I
think there will be some amount of experimentation and consolidation when we
finish with CARD, to establish good interoperability with other protocols.
This is not likely to be the only place where better interoperability is
required.

            jak





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  2 20:31:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06074
	for <seamoby-archive@odin.ietf.org>; Wed, 2 Jul 2003 20:31:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xs09-0005vY-AC
	for seamoby-archive@odin.ietf.org; Wed, 02 Jul 2003 20:31:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h630V5cl022778
	for seamoby-archive@odin.ietf.org; Wed, 2 Jul 2003 20:31:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xs09-0005vH-5p
	for seamoby-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 20:31: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 UAA06010
	for <seamoby-web-archive@ietf.org>; Wed, 2 Jul 2003 20:31:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xs07-0007Gi-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 20:31:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Xs06-0007Gf-00
	for seamoby-web-archive@ietf.org; Wed, 02 Jul 2003 20:31:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xs06-0005uX-Et; Wed, 02 Jul 2003 20:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Xpoe-0000uK-Pt
	for seamoby@optimus.ietf.org; Wed, 02 Jul 2003 18:11:04 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23898;
	Wed, 2 Jul 2003 18:10:58 -0400 (EDT)
Message-Id: <200307022210.SAA23898@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, 02 Jul 2003 18:10:57 -0400
Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-03.txt
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=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-03.txt
	Pages		: 19
	Date		: 2003-7-2
	
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-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-seamoby-ctp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-seamoby-ctp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-7-2181828.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-ctp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-ctp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-7-2181828.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul  3 10:19:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13072
	for <seamoby-archive@odin.ietf.org>; Thu, 3 Jul 2003 10:19:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y4vU-0005cr-9V
	for seamoby-archive@odin.ietf.org; Thu, 03 Jul 2003 10:19:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h63EJ8oV021621
	for seamoby-archive@odin.ietf.org; Thu, 3 Jul 2003 10: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 19Y4vU-0005ce-5N
	for seamoby-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:19: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 KAA13044
	for <seamoby-web-archive@ietf.org>; Thu, 3 Jul 2003 10:19:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y4vR-0006zR-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 10:19:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y4vR-0006zO-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 10: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 19Y4vN-0005bx-2r; Thu, 03 Jul 2003 10: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 19Y4vL-0005bj-Rd
	for seamoby@optimus.ietf.org; Thu, 03 Jul 2003 10:18: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 KAA13022
	for <seamoby@ietf.org>; Thu, 3 Jul 2003 10:18:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y4vJ-0006zF-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 10:18: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 19Y4vI-0006zB-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 10:18:57 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 3 Jul 2003 10:18:54 -0400
Message-ID: <003401c3416e$41eec180$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>,
        "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI> <007a01c340af$27144480$636015ac@dclkempt40> <009801c340b3$9594b3a0$ca6b0f8a@peace> <030f01c340e6$216aa9c0$636015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Thu, 3 Jul 2003 10:20:29 -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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 03 Jul 2003 14:18:54.0337 (UTC) FILETIME=[089F4710:01C3416E]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> > As said earlier, the bit makes the protocol flexible without major
> > additional complexity.
> > The value of flexibility is worth adding the one-bit flag, I think.
> > Also I guess the MNs would be need CARD information near handoff in most
> > cases.
> > That is, the CARD message traffic would be bursty to individual MN.
> Setting
> > a large inter-message time may not be desirable. Also allowing a too
short
> > inter-message time is not desirable, either. So the inter-message time
> > should be configurable. Then the MN should be informed about the vale
> which
> > could be different at different ARs. This brings additional complexity,
> > which the R flag can make unnecessary.
> > So I think there are significant advantages with the R flag.
> >
>
> I'm not arguing whether the inter-message time should be configurable,
just
> that a default should be included and that it should be configurable.
>
Well, we could recommend a default value that is configurable. But we
wondered what would be the base in picking a certain number as the default
value.

> The problem here is that protocols which operate on the local link, like
RFC
> 2461, typically have explicit intermessage times, whereas end to end
> protocols such as TCP (with ECN) do have explicit rate control. This
> protocol is more like the former.
>
Well, even though we are more concerned about MN-AR interaction, the rate
limiting should be applied to AR-AR interaction as well. The R flag will
work for both cases.

> I don't see that a rate flag makes the protocol any more or less flexible
> than having an explicit intermessage time enforced by the host, if the
> intermessage time is configurable. In either case, the protocol depends on
> the host to enforce the rate control.

I am repeating my self. If the inter-message interval is configurable, the
MN should be informed about it. To do this, the AR should send a message to
each MN, probably by periodic broadcast/multicast, or add additional fields
to the CARD reply. Again more rf bandwidth usage in addition to more
processing! The R flag removes this need. Isn't the R flag more flexible and
simpler?

Please let me ask a different question. What is the problem with the R flag
you can see?

Eunsoo


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul  3 10:32: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 KAA13498
	for <seamoby-archive@odin.ietf.org>; Thu, 3 Jul 2003 10:32: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 19Y580-0006EV-GR
	for seamoby-archive@odin.ietf.org; Thu, 03 Jul 2003 10:32:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h63EW4hj023955
	for seamoby-archive@odin.ietf.org; Thu, 3 Jul 2003 10:32:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y580-0006EI-CJ
	for seamoby-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:32: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 KAA13483
	for <seamoby-web-archive@ietf.org>; Thu, 3 Jul 2003 10:32:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y57y-0007CA-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 10:32:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y57x-0007C7-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 10:32:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y57w-0006Bq-Mo; Thu, 03 Jul 2003 10:32:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y57k-0006BA-6M
	for seamoby@optimus.ietf.org; Thu, 03 Jul 2003 10:31: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 KAA13466
	for <seamoby@ietf.org>; Thu, 3 Jul 2003 10:31:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y57h-0007BT-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 10:31: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 19Y57h-0007BQ-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 10:31:45 -0400
Received: from peace ([138.15.107.202]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 3 Jul 2003 10:31:44 -0400
Message-ID: <004901c34170$0d0f6080$ca6b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "James Kempf" <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <009d01c3402a$79177390$ab6015ac@dclkempt40> <002601c3409d$632f6740$ca6b0f8a@peace> <02de01c340e4$659e2510$636015ac@dclkempt40>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
Date: Thu, 3 Jul 2003 10:33: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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 03 Jul 2003 14:31:44.0674 (UTC) FILETIME=[D3C76020:01C3416F]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> > > The draft also contains no guidelines about unsolicited. What is the
> > default
> > > intermessage time on broadcast/multicast? What about the port number
and
> > > TTL?
> > >
> > [eunsoo] Since it is the AR that sends the unsolicited CARD replies, the
> > transmission rate will depend on the configuration. We tried to avoid
> > recommending an arbitrary number as default values without base.
> >
>
> A default rate must be specified. The IESG will insist on this. See RFC
2608
> for an example.
>
[eunsoo] If the IESG insist on setting the default value, we can set the
default maximum transmission rate of the unsolicited replies. Since
unsolicited replies would not involve time-sensitive operation, it should be
fine. A simple guess is "maximum once per second" like the router
advertisement. What do you think?

> > The same port number as the solicited CARD reply is used for the
> unsolicted
> > CARD reply.
> >
>
> OK.
>
> > What do you think would be the proper TTL for the unsolicited CARD
reply?
> I
> > thought TTL 1 should be fine between MN-AR.
> >
>
> If you make it 255, then the reply must have come from a node on the same
> link. This is a cheap way to prevent an offlink attacker from sending
bogus
> CARD replies. RFC 2461 uses this technique. The node should reject the
> message if the TTL is not 255.
>
[eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How
about AR-AR?

> > > Also, I'm not clear about why an unsolicited message needs to be
marked.
> > How
> > > would a MN utilize the U flag? How would processing of a solicited
v.s.
> > > unsolicited message differ?
> > >
> > >
> >
> > For solicited CARD replies, the receiver needs to match the reply to the
> > request by the sequence number. For unsolicited replies, there is no
> > matching request and thus the receiver should be able to distinguish the
> > unsolicted replies from the solicited ones.
> >
>
> How are replay attacks prevented in the multicast case?
>
[eunsoo] The unsolicited replies should have incremented sequence values and
thus the receiver will be able to differentiate newer messages from older
messages. Certainly the sequence number is generated by the sender and thus
the receiver does not match it to any of its requests. This is not
explicitly mentioned in the current draft. Thanks for the good point. I
think we can add it into the next revision.

Eunsoo


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul  3 11:31: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 LAA16527
	for <seamoby-archive@odin.ietf.org>; Thu, 3 Jul 2003 11:31:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y63A-0001TZ-2h
	for seamoby-archive@odin.ietf.org; Thu, 03 Jul 2003 11:31:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FV8PP005673
	for seamoby-archive@odin.ietf.org; Thu, 3 Jul 2003 11:31:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y639-0001TQ-V0
	for seamoby-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:31: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 LAA16371
	for <seamoby-web-archive@ietf.org>; Thu, 3 Jul 2003 11:31:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y638-0000Hq-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 11:31:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y637-0000Hl-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 11:31:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y634-0001QB-Pq; Thu, 03 Jul 2003 11:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y62D-0001Ck-26
	for seamoby@optimus.ietf.org; Thu, 03 Jul 2003 11:30: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 LAA15989
	for <seamoby@ietf.org>; Thu, 3 Jul 2003 11:30:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y62C-0000El-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 11:30:08 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y62B-0000Ef-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 11:30:07 -0400
Message-ID: <00e401c34177$e63e44a0$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>,
        "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307020852210.13571-100000@mannersaari.cs.Helsinki.FI> <007a01c340af$27144480$636015ac@dclkempt40> <009801c340b3$9594b3a0$ca6b0f8a@peace> <030f01c340e6$216aa9c0$636015ac@dclkempt40> <003401c3416e$41eec180$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Techical Issue] Rate limiting flag
Date: Thu, 3 Jul 2003 08:29:30 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Well, we could recommend a default value that is configurable. But we
> wondered what would be the base in picking a certain number as the default
> value.
>

Best to check what other protocols do. See RFC 2461 and RFC 2608 for
protocols that have a similar need.

> > The problem here is that protocols which operate on the local link, like
> RFC
> > 2461, typically have explicit intermessage times, whereas end to end
> > protocols such as TCP (with ECN) do have explicit rate control. This
> > protocol is more like the former.
> >
> Well, even though we are more concerned about MN-AR interaction, the rate
> limiting should be applied to AR-AR interaction as well. The R flag will
> work for both cases.
>

OK, then keep the rate flag in, but be sure to mention why it is there:
messages can go over multihop links, rate flag helps with congestion
control. The difference is important. The default but configurable sending
rate helps with the load on the router, the flag helps with congestion
control (like the TCP ECN bits).

> > I don't see that a rate flag makes the protocol any more or less
flexible
> > than having an explicit intermessage time enforced by the host, if the
> > intermessage time is configurable. In either case, the protocol depends
on
> > the host to enforce the rate control.
>
> I am repeating my self. If the inter-message interval is configurable, the
> MN should be informed about it. To do this, the AR should send a message
to
> each MN, probably by periodic broadcast/multicast, or add additional
fields
> to the CARD reply. Again more rf bandwidth usage in addition to more
> processing! The R flag removes this need. Isn't the R flag more flexible
and
> simpler?
>
> Please let me ask a different question. What is the problem with the R
flag
> you can see?
>

The problem I see, in addition to the distinction articulated above, is that
other protocols with a similar function don't work this way. So, this is an
item that is likely to catch the IESG's attention as a reason to return the
document to us. It is not a deep design or architectural issue. A flag could
be used for rate control as well as congestion control, it just isn't
typically so used in IETF protocols. We can argue about it for weeks (we've
already gone over a week), but it is something that is likely to delay the
progress of the draft IMHO.

If the flag is in and the IESG returns the document to Seamoby because of
it, you are going to get an email from me with "I told you so!" in large,
upper case letters. :-)

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul  3 12:25:52 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 MAA21739
	for <seamoby-archive@odin.ietf.org>; Thu, 3 Jul 2003 12:25:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y6th-0006Ln-4c
	for seamoby-archive@odin.ietf.org; Thu, 03 Jul 2003 12:25:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h63GPPl4024405
	for seamoby-archive@odin.ietf.org; Thu, 3 Jul 2003 12:25:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y6tg-0006LY-WE
	for seamoby-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 12:25: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 MAA21685
	for <seamoby-web-archive@ietf.org>; Thu, 3 Jul 2003 12:25:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y6tf-00022f-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 12:25:23 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y6te-00022c-00
	for seamoby-web-archive@ietf.org; Thu, 03 Jul 2003 12:25:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y6tJ-0006Ke-U9; Thu, 03 Jul 2003 12:25:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Y6sP-0006Hm-Q0
	for seamoby@optimus.ietf.org; Thu, 03 Jul 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 MAA21521
	for <seamoby@ietf.org>; Thu, 3 Jul 2003 12:24:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Y6sO-0001ww-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 12:24:04 -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 19Y6sN-0001ws-00
	for seamoby@ietf.org; Thu, 03 Jul 2003 12:24:03 -0400
Message-ID: <015501c3417f$72340650$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Eunsoo Shim" <eunsoo@nec-labs.com>, <seamoby@ietf.org>
References: <009d01c3402a$79177390$ab6015ac@dclkempt40> <002601c3409d$632f6740$ca6b0f8a@peace> <02de01c340e4$659e2510$636015ac@dclkempt40> <004901c34170$0d0f6080$ca6b0f8a@peace>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
Date: Thu, 3 Jul 2003 09:23:32 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> > A default rate must be specified. The IESG will insist on this. See RFC
> 2608
> > for an example.
> >
> [eunsoo] If the IESG insist on setting the default value, we can set the
> default maximum transmission rate of the unsolicited replies. Since
> unsolicited replies would not involve time-sensitive operation, it should
be
> fine. A simple guess is "maximum once per second" like the router
> advertisement. What do you think?
>

Here are what some other protocols do.

1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value and
MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is 16
seconds.

2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways) suggests 12
hours for unsolicited DA advertisements. This is clearly too long for CARD,
since nodes can hand over at any time.

3) OSPF has a default route flooding period of about 20 min. This also seems
a bit long.

4) As a general observation, protocols that do excessive advertisement tend
to increase the base network load, reducing bandwidth for traffic, something
to be especially avoided on wireless networks. Novell's SAP for example was
infamous for this, and I am told that Apple Rendezvous can also if not
properly configured.

The question one must ask is if the MNs can solicit, what is the purpose of
the unsolicited message?  As an alternative, to reduce traffic from per MN
solicitations? If so, then having the message multicast more frequently than
the approximate lingering time of the MNs on the link won't end up saving
anything.

With this in mind, I'd suggest a default mean of 5 min, configurable to half
the approximate mean lingering time of mobile nodes on the link. The router
then randomly generates a time between 1 sec. and the mean for the actual
time (to avoid synchronization). An interesting experiment would be to look
at some data on 802.11 networks, like for example, the IETF network, and
find out long nodes do linger. YMMV of course, but it would give some more
realistic bounds.

Here are some other considerations:

1) If any of the CARD information changes, the router should multicast
immediately. The router should start by randomizing the initial message
between, say, 1 and 3 seconds in order to avoid clashes with other routers
on the link. And it should continue sending for, say 20 seconds, randomizing
the intermessage time, in case any of the messages are dropped. The draft
should recommend keeping dynamic attribute changes to a minimum, as this
would cause excessive advertisement. Perhaps a minimum change interval of 5
min.

2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:

   Unsolicited Router Advertisements are not strictly periodic: the
   interval between subsequent transmissions is randomized to reduce the
   probability of synchronization with the advertisements from other
   routers on the same link [SYNC].

The WG may want to consider requiring this of unsolicited CARD messages as
well.

3) Another way to avoid the clashing adverts problem is to have only one
router on the link do the advertisement. The WG may also want to consider
recommending that the protocol accommodate configuration such that one
router can be configured as the sole CARD multicast source. Or was the
protocol intended to accommodate different CARD information on routers
sharing the same link? It might be possible (but clearly undesirable from a
complexity standpoint) to have one set of access points in one geographical
area configured with one router and another with another but both routers on
the same subnet, and the possible CARs be different, since the possible
topological moves from the different geographical areas could be different.
The MIP group is grappling with this issue for movement detection, no
solution yet.

> > > The same port number as the solicited CARD reply is used for the
> > unsolicted
> > > CARD reply.
> > >
> >
> > OK.
> >
> > > What do you think would be the proper TTL for the unsolicited CARD
> reply?
> > I
> > > thought TTL 1 should be fine between MN-AR.
> > >
> >
> > If you make it 255, then the reply must have come from a node on the
same
> > link. This is a cheap way to prevent an offlink attacker from sending
> bogus
> > CARD replies. RFC 2461 uses this technique. The node should reject the
> > message if the TTL is not 255.
> >
> [eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How
> about AR-AR?
>

The check won't work in that case because there could be multiple hops
between the two. The two ARs should be using ESP to authenticate anyway.

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul  4 02:59: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 CAA18518
	for <seamoby-archive@odin.ietf.org>; Fri, 4 Jul 2003 02:59:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YKXC-0002XD-1l
	for seamoby-archive@odin.ietf.org; Fri, 04 Jul 2003 02:59:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h646x5eD009737
	for seamoby-archive@odin.ietf.org; Fri, 4 Jul 2003 02: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 19YKXB-0002Wy-Q5
	for seamoby-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 02: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 CAA18472
	for <seamoby-web-archive@ietf.org>; Fri, 4 Jul 2003 02:59:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YKX7-0002pt-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 02:59:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19YKX7-0002pq-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 02:59:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YKX8-0002TY-Vz; Fri, 04 Jul 2003 02: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 19YKWs-0002TC-Ge
	for seamoby@optimus.ietf.org; Fri, 04 Jul 2003 02:58:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18469
	for <seamoby@ietf.org>; Fri, 4 Jul 2003 02:58:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YKWo-0002pm-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 02:58:42 -0400
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19YKWn-0002pj-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 02:58:41 -0400
Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173])
  (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA)
  by mail.cs.helsinki.fi with esmtp; Fri, 04 Jul 2003 09:58:41 +0300
Date: Fri, 4 Jul 2003 09:58:41 +0300 (EEST)
From: Jukka MJ Manner <jmanner@cs.Helsinki.FI>
To: Seamoby Working Group <seamoby@ietf.org>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
In-Reply-To: <015501c3417f$72340650$636015ac@dclkempt40>
Message-ID: <Pine.LNX.4.44.0307040952380.25996-100000@mannersaari.cs.Helsinki.FI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

I can't help but argue about the default value. There are so many
scenarios and network types that could make use of CARD that it would be
impossible to give a default value. In the worst case, with a WLAN
network, a user might only spend a few seconds within the cover area of
one AP, while in the IETF, most people are sitting down while the
connectivity is on, which implies a lingering time of minutes or even
hours...

I would go for a section that discusses shortly the transmission interval,
and could give some example values in different scenarios, but no
single standardized default.

My 2 cents,
Jukka

On Thu, 3 Jul 2003, James Kempf wrote:

> > > A default rate must be specified. The IESG will insist on this. See RFC
> > 2608
> > > for an example.
> > >
> > [eunsoo] If the IESG insist on setting the default value, we can set the
> > default maximum transmission rate of the unsolicited replies. Since
> > unsolicited replies would not involve time-sensitive operation, it should
> be
> > fine. A simple guess is "maximum once per second" like the router
> > advertisement. What do you think?
> >
> 
> Here are what some other protocols do.
> 
> 1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value and
> MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
> MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is 16
> seconds.
> 
> 2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways) suggests 12
> hours for unsolicited DA advertisements. This is clearly too long for CARD,
> since nodes can hand over at any time.
> 
> 3) OSPF has a default route flooding period of about 20 min. This also seems
> a bit long.
> 
> 4) As a general observation, protocols that do excessive advertisement tend
> to increase the base network load, reducing bandwidth for traffic, something
> to be especially avoided on wireless networks. Novell's SAP for example was
> infamous for this, and I am told that Apple Rendezvous can also if not
> properly configured.
> 
> The question one must ask is if the MNs can solicit, what is the purpose of
> the unsolicited message?  As an alternative, to reduce traffic from per MN
> solicitations? If so, then having the message multicast more frequently than
> the approximate lingering time of the MNs on the link won't end up saving
> anything.
> 
> With this in mind, I'd suggest a default mean of 5 min, configurable to half
> the approximate mean lingering time of mobile nodes on the link. The router
> then randomly generates a time between 1 sec. and the mean for the actual
> time (to avoid synchronization). An interesting experiment would be to look
> at some data on 802.11 networks, like for example, the IETF network, and
> find out long nodes do linger. YMMV of course, but it would give some more
> realistic bounds.
> 
> Here are some other considerations:
> 
> 1) If any of the CARD information changes, the router should multicast
> immediately. The router should start by randomizing the initial message
> between, say, 1 and 3 seconds in order to avoid clashes with other routers
> on the link. And it should continue sending for, say 20 seconds, randomizing
> the intermessage time, in case any of the messages are dropped. The draft
> should recommend keeping dynamic attribute changes to a minimum, as this
> would cause excessive advertisement. Perhaps a minimum change interval of 5
> min.
> 
> 2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:
> 
>    Unsolicited Router Advertisements are not strictly periodic: the
>    interval between subsequent transmissions is randomized to reduce the
>    probability of synchronization with the advertisements from other
>    routers on the same link [SYNC].
> 
> The WG may want to consider requiring this of unsolicited CARD messages as
> well.
> 
> 3) Another way to avoid the clashing adverts problem is to have only one
> router on the link do the advertisement. The WG may also want to consider
> recommending that the protocol accommodate configuration such that one
> router can be configured as the sole CARD multicast source. Or was the
> protocol intended to accommodate different CARD information on routers
> sharing the same link? It might be possible (but clearly undesirable from a
> complexity standpoint) to have one set of access points in one geographical
> area configured with one router and another with another but both routers on
> the same subnet, and the possible CARs be different, since the possible
> topological moves from the different geographical areas could be different.
> The MIP group is grappling with this issue for movement detection, no
> solution yet.
> 
> > > > The same port number as the solicited CARD reply is used for the
> > > unsolicted
> > > > CARD reply.
> > > >
> > >
> > > OK.
> > >
> > > > What do you think would be the proper TTL for the unsolicited CARD
> > reply?
> > > I
> > > > thought TTL 1 should be fine between MN-AR.
> > > >
> > >
> > > If you make it 255, then the reply must have come from a node on the
> same
> > > link. This is a cheap way to prevent an offlink attacker from sending
> > bogus
> > > CARD replies. RFC 2461 uses this technique. The node should reject the
> > > message if the TTL is not 255.
> > >
> > [eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How
> > about AR-AR?
> >
> 
> The check won't work in that case because there could be multiple hops
> between the two. The two ARs should be using ESP to authenticate anyway.
> 
>             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  Fri Jul  4 14:07: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 OAA03481
	for <seamoby-archive@odin.ietf.org>; Fri, 4 Jul 2003 14:07:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YUxf-0001um-0A
	for seamoby-archive@odin.ietf.org; Fri, 04 Jul 2003 14:07:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h64I76mp007360
	for seamoby-archive@odin.ietf.org; Fri, 4 Jul 2003 14: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 19YUxe-0001ud-RZ
	for seamoby-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:07: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 OAA03448
	for <seamoby-web-archive@ietf.org>; Fri, 4 Jul 2003 14:07:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YUxc-0000ca-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 14:07:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19YUxb-0000cX-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 14: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 19YUxY-0001tG-L2; Fri, 04 Jul 2003 14:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YUx6-0001oC-B0
	for seamoby@optimus.ietf.org; Fri, 04 Jul 2003 14:06: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 OAA03403
	for <seamoby@ietf.org>; Fri, 4 Jul 2003 14:06:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YUx3-0000bz-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 14:06:29 -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 19YUx2-0000bw-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 14:06:29 -0400
Message-ID: <004d01c34256$b3c81200$826015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>,
        "Seamoby Working Group" <seamoby@ietf.org>
References: <Pine.LNX.4.44.0307040952380.25996-100000@mannersaari.cs.Helsinki.FI>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
Date: Fri, 4 Jul 2003 11:04:24 -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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Jukka,

How is this any different than the default value for router discovery in RFC
2461? There are so many different kinds of wired links too: ATM, Ethernet,
token ring, PPP, etc.

            jak

----- Original Message ----- 
From: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>
To: "Seamoby Working Group" <seamoby@ietf.org>
Sent: Thursday, July 03, 2003 11:58 PM
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD


>
> Hi,
>
> I can't help but argue about the default value. There are so many
> scenarios and network types that could make use of CARD that it would be
> impossible to give a default value. In the worst case, with a WLAN
> network, a user might only spend a few seconds within the cover area of
> one AP, while in the IETF, most people are sitting down while the
> connectivity is on, which implies a lingering time of minutes or even
> hours...
>
> I would go for a section that discusses shortly the transmission interval,
> and could give some example values in different scenarios, but no
> single standardized default.
>
> My 2 cents,
> Jukka
>
> On Thu, 3 Jul 2003, James Kempf wrote:
>
> > > > A default rate must be specified. The IESG will insist on this. See
RFC
> > > 2608
> > > > for an example.
> > > >
> > > [eunsoo] If the IESG insist on setting the default value, we can set
the
> > > default maximum transmission rate of the unsolicited replies. Since
> > > unsolicited replies would not involve time-sensitive operation, it
should
> > be
> > > fine. A simple guess is "maximum once per second" like the router
> > > advertisement. What do you think?
> > >
> >
> > Here are what some other protocols do.
> >
> > 1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value
and
> > MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
> > MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is
16
> > seconds.
> >
> > 2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways)
suggests 12
> > hours for unsolicited DA advertisements. This is clearly too long for
CARD,
> > since nodes can hand over at any time.
> >
> > 3) OSPF has a default route flooding period of about 20 min. This also
seems
> > a bit long.
> >
> > 4) As a general observation, protocols that do excessive advertisement
tend
> > to increase the base network load, reducing bandwidth for traffic,
something
> > to be especially avoided on wireless networks. Novell's SAP for example
was
> > infamous for this, and I am told that Apple Rendezvous can also if not
> > properly configured.
> >
> > The question one must ask is if the MNs can solicit, what is the purpose
of
> > the unsolicited message?  As an alternative, to reduce traffic from per
MN
> > solicitations? If so, then having the message multicast more frequently
than
> > the approximate lingering time of the MNs on the link won't end up
saving
> > anything.
> >
> > With this in mind, I'd suggest a default mean of 5 min, configurable to
half
> > the approximate mean lingering time of mobile nodes on the link. The
router
> > then randomly generates a time between 1 sec. and the mean for the
actual
> > time (to avoid synchronization). An interesting experiment would be to
look
> > at some data on 802.11 networks, like for example, the IETF network, and
> > find out long nodes do linger. YMMV of course, but it would give some
more
> > realistic bounds.
> >
> > Here are some other considerations:
> >
> > 1) If any of the CARD information changes, the router should multicast
> > immediately. The router should start by randomizing the initial message
> > between, say, 1 and 3 seconds in order to avoid clashes with other
routers
> > on the link. And it should continue sending for, say 20 seconds,
randomizing
> > the intermessage time, in case any of the messages are dropped. The
draft
> > should recommend keeping dynamic attribute changes to a minimum, as this
> > would cause excessive advertisement. Perhaps a minimum change interval
of 5
> > min.
> >
> > 2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:
> >
> >    Unsolicited Router Advertisements are not strictly periodic: the
> >    interval between subsequent transmissions is randomized to reduce the
> >    probability of synchronization with the advertisements from other
> >    routers on the same link [SYNC].
> >
> > The WG may want to consider requiring this of unsolicited CARD messages
as
> > well.
> >
> > 3) Another way to avoid the clashing adverts problem is to have only one
> > router on the link do the advertisement. The WG may also want to
consider
> > recommending that the protocol accommodate configuration such that one
> > router can be configured as the sole CARD multicast source. Or was the
> > protocol intended to accommodate different CARD information on routers
> > sharing the same link? It might be possible (but clearly undesirable
from a
> > complexity standpoint) to have one set of access points in one
geographical
> > area configured with one router and another with another but both
routers on
> > the same subnet, and the possible CARs be different, since the possible
> > topological moves from the different geographical areas could be
different.
> > The MIP group is grappling with this issue for movement detection, no
> > solution yet.
> >
> > > > > The same port number as the solicited CARD reply is used for the
> > > > unsolicted
> > > > > CARD reply.
> > > > >
> > > >
> > > > OK.
> > > >
> > > > > What do you think would be the proper TTL for the unsolicited CARD
> > > reply?
> > > > I
> > > > > thought TTL 1 should be fine between MN-AR.
> > > > >
> > > >
> > > > If you make it 255, then the reply must have come from a node on the
> > same
> > > > link. This is a cheap way to prevent an offlink attacker from
sending
> > > bogus
> > > > CARD replies. RFC 2461 uses this technique. The node should reject
the
> > > > message if the TTL is not 255.
> > > >
> > > [eunsoo] Thanks for the info. 255 must be the right value for MN-AR.
How
> > > about AR-AR?
> > >
> >
> > The check won't work in that case because there could be multiple hops
> > between the two. The two ARs should be using ESP to authenticate anyway.
> >
> >             jak
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul  4 14:28: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 OAA03974
	for <seamoby-archive@odin.ietf.org>; Fri, 4 Jul 2003 14:28: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 19YVHv-0004HD-Q9
	for seamoby-archive@odin.ietf.org; Fri, 04 Jul 2003 14:28:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h64IS3iT016433
	for seamoby-archive@odin.ietf.org; Fri, 4 Jul 2003 14:28:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YVHv-0004Gy-MW
	for seamoby-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:28:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03960
	for <seamoby-web-archive@ietf.org>; Fri, 4 Jul 2003 14:28:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YVHt-0000pE-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 14:28:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19YVHs-0000pB-00
	for seamoby-web-archive@ietf.org; Fri, 04 Jul 2003 14:28:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YVHt-0004GH-Fw; Fri, 04 Jul 2003 14:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19YVHf-0004Fg-1l
	for seamoby@optimus.ietf.org; Fri, 04 Jul 2003 14:27: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 OAA03957
	for <seamoby@ietf.org>; Fri, 4 Jul 2003 14:27:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19YVHc-0000p6-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 14:27:44 -0400
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19YVHb-0000p3-00
	for seamoby@ietf.org; Fri, 04 Jul 2003 14:27:43 -0400
Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13])
  (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA)
  by mail.cs.helsinki.fi with esmtp; Fri, 04 Jul 2003 21:27:43 +0300
Date: Fri, 4 Jul 2003 21:27:42 +0300 (EEST)
From: Jukka MJ Manner <jmanner@cs.Helsinki.FI>
To: James Kempf <kempf@docomolabs-usa.com>
cc: Seamoby Working Group <seamoby@ietf.org>
Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
In-Reply-To: <004d01c34256$b3c81200$826015ac@dclkempt40>
Message-ID: <Pine.LNX.4.44.0307042126170.22500-100000@melkinpaasi.cs.Helsinki.FI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Well,I guess it is not much different when you think about it...:)

Cheers,
Jukka

On Fri, 4 Jul 2003, James Kempf wrote:

> Jukka,
> 
> How is this any different than the default value for router discovery in RFC
> 2461? There are so many different kinds of wired links too: ATM, Ethernet,
> token ring, PPP, etc.
> 
>             jak
> 
> ----- Original Message ----- 
> From: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>
> To: "Seamoby Working Group" <seamoby@ietf.org>
> Sent: Thursday, July 03, 2003 11:58 PM
> Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
> 
> 
> >
> > Hi,
> >
> > I can't help but argue about the default value. There are so many
> > scenarios and network types that could make use of CARD that it would be
> > impossible to give a default value. In the worst case, with a WLAN
> > network, a user might only spend a few seconds within the cover area of
> > one AP, while in the IETF, most people are sitting down while the
> > connectivity is on, which implies a lingering time of minutes or even
> > hours...
> >
> > I would go for a section that discusses shortly the transmission interval,
> > and could give some example values in different scenarios, but no
> > single standardized default.
> >
> > My 2 cents,
> > Jukka
> >
> > On Thu, 3 Jul 2003, James Kempf wrote:
> >
> > > > > A default rate must be specified. The IESG will insist on this. See
> RFC
> > > > 2608
> > > > > for an example.
> > > > >
> > > > [eunsoo] If the IESG insist on setting the default value, we can set
> the
> > > > default maximum transmission rate of the unsolicited replies. Since
> > > > unsolicited replies would not involve time-sensitive operation, it
> should
> > > be
> > > > fine. A simple guess is "maximum once per second" like the router
> > > > advertisement. What do you think?
> > > >
> > >
> > > Here are what some other protocols do.
> > >
> > > 1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value
> and
> > > MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
> > > MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is
> 16
> > > seconds.
> > >
> > > 2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways)
> suggests 12
> > > hours for unsolicited DA advertisements. This is clearly too long for
> CARD,
> > > since nodes can hand over at any time.
> > >
> > > 3) OSPF has a default route flooding period of about 20 min. This also
> seems
> > > a bit long.
> > >
> > > 4) As a general observation, protocols that do excessive advertisement
> tend
> > > to increase the base network load, reducing bandwidth for traffic,
> something
> > > to be especially avoided on wireless networks. Novell's SAP for example
> was
> > > infamous for this, and I am told that Apple Rendezvous can also if not
> > > properly configured.
> > >
> > > The question one must ask is if the MNs can solicit, what is the purpose
> of
> > > the unsolicited message?  As an alternative, to reduce traffic from per
> MN
> > > solicitations? If so, then having the message multicast more frequently
> than
> > > the approximate lingering time of the MNs on the link won't end up
> saving
> > > anything.
> > >
> > > With this in mind, I'd suggest a default mean of 5 min, configurable to
> half
> > > the approximate mean lingering time of mobile nodes on the link. The
> router
> > > then randomly generates a time between 1 sec. and the mean for the
> actual
> > > time (to avoid synchronization). An interesting experiment would be to
> look
> > > at some data on 802.11 networks, like for example, the IETF network, and
> > > find out long nodes do linger. YMMV of course, but it would give some
> more
> > > realistic bounds.
> > >
> > > Here are some other considerations:
> > >
> > > 1) If any of the CARD information changes, the router should multicast
> > > immediately. The router should start by randomizing the initial message
> > > between, say, 1 and 3 seconds in order to avoid clashes with other
> routers
> > > on the link. And it should continue sending for, say 20 seconds,
> randomizing
> > > the intermessage time, in case any of the messages are dropped. The
> draft
> > > should recommend keeping dynamic attribute changes to a minimum, as this
> > > would cause excessive advertisement. Perhaps a minimum change interval
> of 5
> > > min.
> > >
> > > 2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:
> > >
> > >    Unsolicited Router Advertisements are not strictly periodic: the
> > >    interval between subsequent transmissions is randomized to reduce the
> > >    probability of synchronization with the advertisements from other
> > >    routers on the same link [SYNC].
> > >
> > > The WG may want to consider requiring this of unsolicited CARD messages
> as
> > > well.
> > >
> > > 3) Another way to avoid the clashing adverts problem is to have only one
> > > router on the link do the advertisement. The WG may also want to
> consider
> > > recommending that the protocol accommodate configuration such that one
> > > router can be configured as the sole CARD multicast source. Or was the
> > > protocol intended to accommodate different CARD information on routers
> > > sharing the same link? It might be possible (but clearly undesirable
> from a
> > > complexity standpoint) to have one set of access points in one
> geographical
> > > area configured with one router and another with another but both
> routers on
> > > the same subnet, and the possible CARs be different, since the possible
> > > topological moves from the different geographical areas could be
> different.
> > > The MIP group is grappling with this issue for movement detection, no
> > > solution yet.
> > >
> > > > > > The same port number as the solicited CARD reply is used for the
> > > > > unsolicted
> > > > > > CARD reply.
> > > > > >
> > > > >
> > > > > OK.
> > > > >
> > > > > > What do you think would be the proper TTL for the unsolicited CARD
> > > > reply?
> > > > > I
> > > > > > thought TTL 1 should be fine between MN-AR.
> > > > > >
> > > > >
> > > > > If you make it 255, then the reply must have come from a node on the
> > > same
> > > > > link. This is a cheap way to prevent an offlink attacker from
> sending
> > > > bogus
> > > > > CARD replies. RFC 2461 uses this technique. The node should reject
> the
> > > > > message if the TTL is not 255.
> > > > >
> > > > [eunsoo] Thanks for the info. 255 must be the right value for MN-AR.
> How
> > > > about AR-AR?
> > > >
> > >
> > > The check won't work in that case because there could be multiple hops
> > > between the two. The two ARs should be using ESP to authenticate anyway.
> > >
> > >             jak
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
> 


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sun Jul  6 17:24: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 RAA22888
	for <seamoby-archive@odin.ietf.org>; Sun, 6 Jul 2003 17:24: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 19ZGzP-0002rY-JB
	for seamoby-archive@odin.ietf.org; Sun, 06 Jul 2003 17:24:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h66LO7hG010998
	for seamoby-archive@odin.ietf.org; Sun, 6 Jul 2003 17:24:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ZGzP-0002rJ-Ea
	for seamoby-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 17:24: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 RAA22871
	for <seamoby-web-archive@ietf.org>; Sun, 6 Jul 2003 17:24:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZGzN-0004nn-00
	for seamoby-web-archive@ietf.org; Sun, 06 Jul 2003 17:24:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZGzM-0004nj-00
	for seamoby-web-archive@ietf.org; Sun, 06 Jul 2003 17:24:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ZGzJ-0002qd-4P; Sun, 06 Jul 2003 17: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 19ZGyk-0002qI-Kc
	for seamoby@optimus.ietf.org; Sun, 06 Jul 2003 17:23: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 RAA22866
	for <seamoby@ietf.org>; Sun, 6 Jul 2003 17:23:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZGyh-0004nY-00
	for seamoby@ietf.org; Sun, 06 Jul 2003 17:23:23 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZGyh-0004nG-00
	for seamoby@ietf.org; Sun, 06 Jul 2003 17:23:23 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h66LMqVI099593;
	Sun, 6 Jul 2003 23:22:52 +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 CEEF34CA8A; Sun,  6 Jul 2003 23:05:38 +0200 (CEST)
Message-ID: <3F089328.1090006@ccrle.nec.de>
Date: Sun, 06 Jul 2003 23:22:48 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD protocol issue tracker
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi all,

an issue tracker has been set up for the CARD protocol issues.

Many thanks to Steven Bellovin for setting up an account for
us very quickly!

The issues tracker can be found here...

https://roundup.machshav.com/seamoby/index

... and will be updated regularly. Current issues have already
been incorporated into the tool's database.

marco








_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul  8 12:59: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 MAA00620
	for <seamoby-archive@odin.ietf.org>; Tue, 8 Jul 2003 12:59:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Zvo7-0005yt-Vr
	for seamoby-archive@odin.ietf.org; Tue, 08 Jul 2003 12:59:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h68GxBRY022991
	for seamoby-archive@odin.ietf.org; Tue, 8 Jul 2003 12:59:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Zvo7-0005yk-Rr
	for seamoby-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 12:59: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 MAA00580
	for <seamoby-web-archive@ietf.org>; Tue, 8 Jul 2003 12:59:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Zvo6-0003aZ-00
	for seamoby-web-archive@ietf.org; Tue, 08 Jul 2003 12:59:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Zvo5-0003aV-00
	for seamoby-web-archive@ietf.org; Tue, 08 Jul 2003 12:59:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Zvnx-0005xs-7y; Tue, 08 Jul 2003 12: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 19ZvnT-0005xE-Bl
	for seamoby@optimus.ietf.org; Tue, 08 Jul 2003 12:58:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00566
	for <seamoby@ietf.org>; Tue, 8 Jul 2003 12:58:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZvnR-0003a4-00
	for seamoby@ietf.org; Tue, 08 Jul 2003 12:58:29 -0400
Received: from [131.227.74.4] (helo=phoebe.eim.surrey.ac.uk ident=exim)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ZvnQ-0003a0-00
	for seamoby@ietf.org; Tue, 08 Jul 2003 12:58:29 -0400
Received: from ccsrmclt03.ee.surrey.ac.uk
	([131.227.86.163] helo=eim.surrey.ac.uk ident=ees2mg)
	by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 19ZvnG-0004TT-00
	for seamoby@ietf.org; Tue, 08 Jul 2003 17:58:18 +0100
Message-ID: <3F0AF82A.7AC9BD1@eim.surrey.ac.uk>
Date: Tue, 08 Jul 2003 17:58:18 +0100
From: Michael Georgiades <m.georgiades@eim.surrey.ac.uk>
Organization: University of Surrey
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17.7.x i686)
X-Accept-Language: en, el
MIME-Version: 1.0
To: seamoby <seamoby@ietf.org>
Content-Type: multipart/alternative;
 boundary="------------5ECC7573DDF60791CA9316F9"
X-Spam-Status: No, hits=-103.2 required=5.5
	tests=BAYES_10,HTML_20_30,USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
X-Scanner: exiscan *19ZvnG-0004TT-00*Gyv.u9/nokc* (SECM, UniS)
Subject: [Seamoby] Context Transfer Extension to Cellular-IP v01
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>


--------------5ECC7573DDF60791CA9316F9
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

Hi all,

The Internet draft below, proposes a Context Transfer Extension to
Cellular-IP.

        Title           : Context Transfer Extension to Cellular-IP
        Author(s)       : M. Georgiades et al.
        Filename        : draft-georgiades-seamoby-ctecip-01.txt
        Pages           : 13
        Date            : 2003-7-1

This Internet draft enhances cellular-IP mobility protocol with a
Context Transfer mechanism aiming to further optimise the handoff
operation in mobile networks. Within a cellular-IP domain, during the
handoff from one cellular-IP base station to another, cellular-IP
packets could be  used to initiate and transfer authorised context
from the previous cellular-IP base station via the cellular-IP
gateway to the new cellular-IP base station. This draft presents how
the context transfer extension introduced could facilitate in
reducing latency and packet loss by avoiding the signalling required
between the mobile node and the new base station  in  re-establishing
the desired state information.

URL:
http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctecip-01.txt

--
Michael Georgiades
Research Fellow
Centre for Communication Systems Research
University of Surrey
Guildford, Surrey, GU2 7XH

Tel: +44 (0) 1483 683605
Fax: +44 (0) 1483 686011
www.ee.surrey.ac.uk/ccsr



--------------5ECC7573DDF60791CA9316F9
Content-Type: text/html; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Hi all,
<p>The Internet draft below, proposes a Context Transfer Extension to
<br>Cellular-IP.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: Context Transfer Extension to Cellular-IP
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: M. Georgiades et al.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: draft-georgiades-seamoby-ctecip-01.txt
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 13
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 2003-7-1
<br>&nbsp;
<br>This Internet draft enhances cellular-IP mobility protocol with a
<br>Context Transfer mechanism aiming to further optimise the handoff
<br>operation in mobile networks. Within a cellular-IP domain, during the
<br>handoff from one cellular-IP base station to another, cellular-IP
<br>packets could be&nbsp; used to initiate and transfer authorised context
<br>from the previous cellular-IP base station via the cellular-IP
<br>gateway to the new cellular-IP base station. This draft presents how
<br>the context transfer extension introduced could facilitate in
<br>reducing latency and packet loss by avoiding the signalling required
<br>between the mobile node and the new base station&nbsp; in&nbsp; re-establishing
<br>the desired state information.
<p>URL:
<br><a href="http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctecip-01.txt">http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctecip-01.txt</a>
<pre>--&nbsp;
Michael Georgiades
Research Fellow
Centre for Communication Systems Research
University of Surrey
Guildford, Surrey, GU2 7XH

Tel: +44 (0) 1483 683605
Fax: +44 (0) 1483 686011
www.ee.surrey.ac.uk/ccsr</pre>
&nbsp;
</body>
</html>

--------------5ECC7573DDF60791CA9316F9--


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 02:02: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 CAA25828
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 02:02: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 19a81m-0000xq-Br
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 02:02:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h696267J003706
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 02:02:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19a81m-0000xh-1e
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 02:02: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 CAA25275
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 02:02:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19a81i-0003oT-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 02:02:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19a81h-0003oQ-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 02:02:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19a81i-0000xK-J0; Wed, 09 Jul 2003 02:02:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19a81a-0000wl-Ps
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 02: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 CAA25078
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 02:01:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19a81X-0003oM-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 02:01:51 -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 19a81V-0003oJ-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 02:01:49 -0400
Message-ID: <00ac01c345df$9c6082a0$876015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Wed, 9 Jul 2003 08:01:57 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00A9_01C345F0.5E961EB0"
Subject: [Seamoby] CARD Review from Vijay
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C345F0.5E961EB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Review of CARD from Vijay Deverapali is attached. Vijay is on the Seamoby
Review Board.

            jak

------=_NextPart_000_00A9_01C345F0.5E961EB0
Content-Type: text/plain;
	name="card_review.txt"
Content-Disposition: attachment;
	filename="card_review.txt"
Content-Transfer-Encoding: 7bit


>    3.1 Reverse Address Translation
> 
>    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.

how does this fit in with the ProxyRtrSolict and ProxyRtrAdvert
in FMIPv6? FMIPv6 already does Reverse Address Translation through 
these two messages.


>    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 reverse address
>    translation.

in this case, is Router Solicitation and Router Advertisement
used for reverse address transaltion? what is need for CARD
messages here?


>    3.2 Discovery of CAR Capabilities
> 
>    Information about capabilities of CARs can assist the MN in making
>    optimized handover decisions. This capability information serves as
>    input to the target AR selection algorithm. Some of the capability
>    parameters of CARs can be static, while some others can change with
>    time.

s/while some others/while others/

 
>    Definition of capabilities is out of scope of the CARD protocol
>    design. Encoding rules for capabilities and the format of a
>    capability container for capability transport are specified in
>    section 5.

s/the CARD protocol design/this document/

 
>    There are two approaches for MNs to acquire address and capability
>    information of CARs. One is that the MN sends an explicit request to
>    its current AR and the current AR provides address and capability
>    information to the MN. The other is that the current AR either
>    periodically transmits address and capability information of CARs to
>    the MNs over download channels, or link-layer mechanisms trigger
>    unsolicited transmission of CARs' address and capability
>    information.

what is this L2 trigger which makes the AR send out unsolicited
information. the way I see it, unsolicited information is 
typically sent using a timer or when there is a significant 
change in the capability information.


>    The CARD protocol is used to allow MNs resolving the L2 ID of one or
>    more APs, which are candidates the MN may initiate a handover to, to
>    the IP address of the associated CARs, as well as to discover these
>    CARs' capabilities.  Furthermore, the protocol allows populating
>    ARs' CAR tables (section 4.1) with the capabilities of CARs.
> 
>    For this, the CARD protocol makes use of a CARD Request and CARD
>    Reply protocol message handshake between a MN and its current AR,
>    and between a MN's current AR and individual CARs respectively. CARD
>    Request and CARD Reply messages are used on the interface between a
>    MN and its current AR to allow MNs retrieving CARs' address and
>    capability parameter specific information from the network. To allow
>    ARs populating and maintaining their local CAR table with capability
>    parameter information of CARs, a CARD Request and CARD Reply
>    protocol message handshake is also used on the interface between a
>    MN's current AR and CARs to allow updating ARs' CAR table entries
>    with CARs' capability information.

reword the first two paragraphs. too verbose and repetitive.

    The CARD protocol is used to allow MNs resolving the L2 ID of one or
    more APs, which are candidates the MN may initiate a handover to, to
    the IP address of the associated CARs, as well as to discover these
    CARs' capabilities. Furthermore, the protocol allows each AR to
    maintain the capability information of other CARs. For this, the 
    CARD protocol makes use of a CARD Request and CARD Reply protocol 
    message, defined in Section 5.1.2.


>    An access point's L2 ID, a CAR's IP address and associated
>    capability information is carried as CARD protocol message parameter
>    with a CARD Request or a CARD Reply message respectively. 

took a long time to figure out what the sentence says. I guess
you wanted to say a CARD Request and CARD Reply contain AP's
L2 ID and the IP address of a CAR respectively. Optionally 
these messages can also contain capability information.


>    The CARD protocol enables the MN's current AR to exchange
>    capabilities with CARs and to subsequently convey appropriate
>    capabilities to the connected MNs. 

this sentence repeats what was said earlier. delete.


>    The unsolicited CARD Reply SHALL be broadcast from ARs to all the
>    connected MNs. 

for IPv6, is all-nodes multicast address used?

 
>    The CARD protocol also enables a MN to optionally indicate its
>    preferences on capabilities of interest to its current AR, which
>    allows the MN's current AR performing optional capability pre-
>    filtering for optimization purposes. Appending the optional
>    Preferences message parameter for a CARD Request message, which is
>    sent to the MN's current AR, the MN can indicate a list of
>    capability attributes, which are of interest to the MN, to its
>    current AR. The AR now returns only these capabilities of interest
>    to the requesting MN. The format of this optional Preferences
>    message parameter is described in section 5.1.3.2.

reword

     The CARD protocol also enables a MN to indicate its preferences
     on capabilities of interest to its current AR, by including the 
     Preferences message parameter in the CARD Request message. The 
     current AR MAY use this information to filter the list of CARs 
     and include only those CARS which satisfy the MR's preferences. 
     The format for the Preferences message parameter is described 
     in section 5.1.3.2.


>    Optionally, the MN can provide its current AR with a list of
>    capability attribute-value pairs, indicating not only the capability
>    parameters (attributes) as required for capability pre-filtering,
>    but also a specific value for a particular capability. This allows
>    the MN's current AR performing CAR pre-filtering and to send only
>    address and capability information of CARs, whose capability values
>    meet the requirements of the MN, back to the requesting MN. The
>    format of this optional Requirements message parameter is described
>    in section 5.1.3.3.

I dont see a need to have both Preferences and Requirements
message parameter. especially when both are optional messages.
I recommend having only one.

 
>    As an example, using the optional Preferences message parameter, a
>    MN may indicate to its current AR that it is interested only in
>    IEEE802.11 interface specific capability parameters, since this is
>    the only interface the MN has implemented. Hence, the MN's current
>    AR sends back only CARs' IEEE802.11 specific capabilities.
>    Similarly, using the optional Requirements message parameter, a MN
>    MAY indicate to its current AR that it is only interested in CARs
>    that can satisfy a given QoS constraint. Here, a MN sends the
>    respective QoS attribute with the QoS constraint value to its
>    current AR using the optional Requirements message parameter. The
>    QoS constraint is denoted as an attribute-value pair and
>    encapsulated with the Requirements message parameter, which is
>    appended to the MN-originated CARD Request message. Based on the
>    received optional list of attributes in the Preferences parameter or
>    a list of attribute-value pairs in the Requirements message
>    parameter, the MN's current AR MAY use these parameters for deciding
>    the content of the solicited CARD Reply message, which is to be sent
>    back to the MN. Alternatively, in case no optimization with regard
>    to capability or CAR pre-filtering is performed by the MN's current
>    AR, the current AR MAY choose to silently ignore the optional
>    Requirements and Preferences message parameter as received in the
>    CARD Request message.

both could be done using just the Requirements message parameter.


>    ID to the IP address of the associated CAR or, in case the MN has
>    not attached one or more L2 ID message parameters, 

s/one or more/any/

> it just reads out
>    all CARs' IP address information using the reverse address
>    translation information (L2 ID to IP address mapping) from its local
>    CAR table. In case one or more capability entries have expired in
>    the current AR's CAR table, the current AR then directly contacts
>    the CAR and performs capability discovery with it by performing an
>    AR-AR CARD Request (3) and AR-AR CARD Reply (4) protocol message
>    handshake to retrieve individual CARs' capability information. The
>    current AR then updates capability entries in its local CAR table
>    and passes on the IP address of the CAR(s) and associated
>    capabilities to the MN using the MN-AR CARD Reply message (5).

lets say, the MN is interested only reverse address translation
and not in capability information. how does the MN indicate this
to the access router? I think supporting this is essential. 


>    Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
>    during link layer scanning, sometimes a MN might send frequent MN-AR
>    CARD Requests, thereby overwhelming its current AR with CARD Request
>    signaling messages. To counteract this problem, the AR SHOULD set
>    the R-flag (rate limiting) of a subsequent CARD Reply message for
>    flow-control purposes (section 5.1.2.2), thereby requesting the MN
>    to reduce the generation rate of MN-AR CARD Requests. Upon receipt
>    of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
>    reduce the rate of generation of MN-AR CARD Requests. The exact
>    implementation of a rate-limiting algorithm should be decided by the
>    implementers.

whats the need for an R flag? its not required, IMO.

I recommend the following

The MN MUST send only one CARD Request per CARD_RETRANSMISSION_INTERVAL
and not more than CARD_MAX_RETRIES.

add to the constants section

CARD_RETRANSMISSION_INTERVAL  1 second
CARD_MAX_RETRIES              3

if the MN sends requests more frequently, the AR just drops them.

the above is a well known rate-limiting technique used by a
large number of protocols. we should stick to this.


>    ARs SHALL also keep and maintain individual CARs' capabilities in
>    the local CAR table, taking the associated capability lifetime into
>    account. If the lifetime of an individual capability entry has
>    expired, the respective capability is to be discovered and to be
>    updated when requested from a connected MN. The ARs' CAR table may
>    be implemented differently by the different implementations, hence
>    additional details are not provided here.

why is this a MUST? SHALL means MUST. SHOULD is enough. I 
might be designing a system where all Access Router have
the same capabilities and all I need is an L2 ID to IP 
address mapping.


>    To initiate CARD, a MN sends a CARD Request to its current AR,
>    requesting it to resolve the L2 ID of nearby access points to the IP
>    address of associated CARs, and also to obtain capability parameters
>    associated with these CARs. In case the requesting MN want its
>    current AR to resolve specific L2 IDs, the MN-AR CARD Request SHOULD
>    contain the CARD protocol specific L2 ID message parameters,


delete the following. redundant.

>    carrying the L2 ID of respective access points, for which reverse
>    address translation to associated CARs' IP address as well as CARs'
>    capability information is being requested. 


delete the following. already mentioned earlier.

> 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). 


also delete the following sentence. we are describing the MN's
operation in this section.

> The MN's current AR MAY use the Preferences and Requirement
>    message parameter to decide about a sub-set of the CAR(s) that can
>    satisfy the MN's need.
> 


>    4.2.2 Current Access Router Operation
> 
>    Upon receipt of the requesting MN's MN-AR CARD-Request, containing

s/the requesting MN's/a/

>    one or multiple L2 ID message parameters, the connected AR SHALL
>    resolve the requested APs' L2 ID to the IP address of the associated
>    CAR(s). In case no L2 ID parameter has been sent with the MN-AR CARD
>    Request message, the MN's current AR retrieves all CARs' IP address
>    and capability information from its local CAR table. Optionally,
>    when allowed by local policies and supported by respective ARs, the
>    AR MAY retrieve a subset of capabilities or CARs, satisfying the
>    optionally appended Preferences and Requirement message parameter,
>    from its local CAR table. CARs' address information along with
>    associated capabilities are then delivered to the MN using the MN-AR
>    CARD Reply message, 


delete the following.

> having the Address message parameters and
>    appropriate Capability Container parameters appended. 


> The CARs' IP
>    address as well as the capabilities SHALL be encoded according to
>    the format for CARD protocol message parameters as defined in
>    section 5.1.3 of this document. The capabilities are encoded as
>    attribute-value pairs, which are to be encapsulated in a Capability
>    Container message parameter according to the format defined in
>    section 5.1.3.4. The responding current AR shall copy the sequence
>    number received in the MN-AR CARD Request to the MN-AR CARD Reply.

there was no mention of the sequence number in Section 4.2.1.


>    Request. The MN's current AR SHALL use the IPsec ESP for
>    authenticating the AR-AR CARD Request. The IPsec ESP MAY be also
>    used for encrypting the capability information.

this is not how you specify IPsec requirements. replace the above 
sentence with

    The MN's current AR SHOULD use IPsec for authenticating the
    AR-AR CARD Request. If the capability information needs to be
    encrypted ESP MUST be used.

question, a broadcast unsolicited CARD Reply message cannot
be protected by IPsec. how is the SA created?


> 
>    Upon receipt of the AR-AR CARD Reply, which has been sent by the CAR
>    in response to the previously sent request, 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. The lifetime of individual capabilities is to be set
>    according to the lifetime indicated for each capability received.
>    The value of the table entries' timeout shall depend upon the nature
>    of individual capabilities. Then the AR MUST send the MN-AR CARD
>    Reply to the Mobile Node.

s/Then the AR MUST send/Then the AR sends/


>    4.3.2 Candidate Access Router Operation
> 
>    Upon receipt of a AR-AR CARD Request, a CAR shall extract the
>    capabilities of the MN's current AR from the payload of the received
>    message. The CAR SHALL buffer the received capabilities in its CAR
>    table and set the timer for individual capabilities appropriately.
>    The value of the table entries' timeout depends upon the nature of
>    capabilities received. The CAR then MUST respond with the AR-AR CARD

s/CAR then MUST respond/CAR then responds/

>    Reply message. The CAR MUST include the same sequence number
>    received in AR-AR CARD Request message to the AR-AR CARD Reply
>    message. The AR-AR CARD Reply shall include the CAR's capabilities
>    as list of attribute-value pairs in the Capability Container message
>    parameter. The CAR SHALL use IPsec ESP for authentication or
>    optionally encryption of the AR-AR CARD Reply message.

the same as before. replace last sentence with

   The CAR SHOULD use IPsec for authenticating the AR-AR CARD Reply
   message. If the capability information needs to be encrypted
   ESP MUST be used.


> 
>    4.4 CARD Signaling Failure Recovery
> 
>    For a variety of reasons, the packets carrying CARD protocol
>    signaling may be dropped. In this section we consider mechanisms for
>    recovery from the CARD signaling failures. Broadly the CARD
>    signaling failures can be categorized in MN-AR signaling failures
>    and AR-AR signaling failures.
> 
> 
>    4.4.1 MN-AR Signaling Failure
> 
>    It is likely that either a CARD Request or CARD Reply may be dropped
>    due to poor radio link conditions. 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 AR 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. The MN shall retry the MN-AR CARD Request for
>    a pre-configured number of times (MN_AR_CARD_RETRIES) before
>    declaring the protocol message exchange aborted. The MN SHALL
>    silently discard any duplicate MN-AR CARD Reply messages received
>    from its current AR.
> 
> 
>    4.4.2 AR-AR Signaling Failure
> 
>    It is likely that a AR-AR CARD Request or AR-AR CARD Reply may be
>    dropped due to congestion at the intermediate routers or poor link
>    conditions. The MN's current AR SHALL 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 SHALL start a timer
>    (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the
>    given sequence number. The current AR SHALL 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 SHALL
>    declare the outstanding AR-AR CARD Request as lost and then resends
>    the same message to the CAR. The current AR SHALL retry the AR-AR
>    CARD Request message for a pre-configured number of times
>    (AR_AR_CARD_RETRIES) before declaring the protocol message exchange
>    as aborted. The current AR SHALL silently discard any duplicate AR-
>    AR CARD Reply received from the CAR.
> 


replace entire section 4.4 with the following

4.4 Retransmission of CARD messages

   In the event of a CARD Request or a Reply message getting dropped, 
   the MN and the AR SHOULD retransmit the Request message. A CARD
   Request message is retransmitted if there is not reply for 
   CARD_REQUEST_TIMEOUT seconds. CARD Request messages MUST not be 
   sent more than MAX_CARD_RETRIES times.


since both MN and AR follow the same procedure, I dont see a point
in describing the same twice.


>    4.6 CARD Protocol Security
> 
>    The MN-AR and AR-AR messages SHALL be protected using IPsec ESP

s/SHALL be protected using IPsec ESP/MUST be protected using IPsec.


>    IP Fields:
> 
>          Source Address:
>                         An IP address assigned to the sending
>                         interface.
> 
>          Destination Address:
>                         An IP address assigned to the receiving
>                         interface.

are link local addresses okay? if you want IPsec protection, 
shouldnt global addresses be used? link local addresses on
both the old link and the new link would be same. OTOH,
if unsolicited CARD Reply messages are sent 


> 
>          Hop Limit:     255
> 
>          Encapsulating Security Payload (ESP) Header:
>                         The sender SHOULD include the Encapsulating
>                         Security Payload (ESP) Header, based on the
>                         previously established Security Association
>                         between the sender and the receiver.

there is no need to mention ESP header. you are describing
CARD Header Format here.



>    Valid Options:
> 
>          CARD Request: The CARD Request allows entities to request CARD
>                        specific information from ARs. To process the
>                        CARD Request message on the receiver side,
>                        further sub-options must be carried, serving as
>                        input to the reverse address translation
>                        function and/or capability discovery function.

would it be better if the description goes to section 5.1.2.1.


> 
>          CARD Reply:   The CARD Reply carries parameters, previously
>                        requested with a CARD Request, back to the
>                        sender of the CARD Request. In case of
>                        unsolicited address information and capabilities
>                        are to be sent to a node, the sender uses the
>                        CARD Reply without getting an explicit CARD
>                        Request before. Further sub-options will be
>                        associated with the CARD Reply message.


the same as above. the description should be in 5.1.2.2.


>    5.1.2.1 CARD Request Option
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |    Length     |P|         Reserved            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                        Sequence Number                        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Sub-Options
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -  -  -
> 
>    Fields:
> 
>       Type:    T.B.A
> 
>       Length:  The length of the option in units of octets, including
>                the type and length fields as well as sub-options.
> 
>       Flags:   P-flag:  Indicates CARD protocol message piggybacking
>                         capability of the CARD Request message sender.
>                         A description for proper use of this flag can
>                         be found in section 4.5 of this document.
> 
>                Reserved bits MUST be initialized with 0.
> 
>       Sequence Number:
>                Allows correlating requests with replies.
> 
> 
>    Valid Sub-Options:
> 
>       - L2 ID sub-option
>       - Preferences sub-option
>       - Requirements sub-option


mention alignment requirement of 4n.



>     5.1.2.2 CARD Reply Option
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |    Length     |P|U|R|       Reserved          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Sequence Number                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Sub-Options
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
> 
> 
>    Fields:
> 
>       Type:    T.B.A
> 
>       Length:  The length of the option in units of octets, including
>                the type and length fields as well as sub-options.
> 
>       Flags:   P-flag:  Indicates CARD protocol message piggybacking
>                         capability of the CARD Request message sender.
>                         A description for proper use of this flag can
>                         be found in section 4.5 of this document.
> 
>                U-flag:  Indicates an unsolicited CARD Reply.
>                         A description for proper use of this flag can
>                         be found in section 4 of this document.
> 
>                R-flag:  Indicates exceeding CARD Request rate
>                         limitation. A description for proper use of
>                         this flag can be found in section 4 of this
>                         document.

the R-flag is a bad idea.


> 
>                Reserved bits MUST be initialized with 0.
> 
>       Sequence Number:
>                Allows correlating requests with replies.
> 
> 
>    Valid Sub-Options:
> 
>       - L2 ID sub-option
>       - Capability Container sub-option
>       - Address sub-option


if unsolicited CARD reply is broadcast, the destination address
(for IPv6) becomes all-nodes multicast address. I think this
should be mentioned here. also please mention alignment 
requirement of 4n.


> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Sub-Option Type|Sub-Option Len |   Context-ID  |M|  L2-Type    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      L2 ID . . .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
> 
> 
>    Sub-Option Type:
>                   T.B.A
> 
>    Sub-Option Length:
>                   Length of the Sub-Option (including type and length
>                   fields as well as L2 type indicator) in units of 8
>                   octets. 
> 
>    Context-ID:    Identifies associated L2 ID, IP address and
>                   capability information, when coming with separated
>                   sub-options.

what is a Context-ID? it is mentioned for the first time here. it
was not used in the protocol description earlier.


> 
>    M-flag:        This flag indicates that the Context-ID of this
>                   particular L2 ID sub-option has been modified by the
>                   MN's current AR and set to the same value as a
>                   preceding L2 ID received in the same CARD Request
>                   message. This adjustment appears in case this L2 ID's
>                   associated access point is served by the same CAR as
>                   a preceding access point's L2 ID, hence, the same
>                   Capability Container and Address sub-option,
>                   describing a CAR's IP address and associated
>                   capabilities, is valid for this particular L2 ID.

I couldnt figure out what is being said here.


>    L2 type:       Indicates the interface type (optional)
>                   (Ethernet, IEEE802.11b, ...).
> 
>                   If the L2 type indicator is not used, this field MUST
>                   be set to 0.

needs to alloted IANA types. this is not mentioned in the IANA
considerations. (rthis)


> 
>    5.1.3.2 Preferences Sub-Option

> 
>    5.1.3.3 Requirements Sub-Option


I feel these two should be combined.



> 
>    5.1.3.4 Capability Container Sub-Option
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Sub-Option Type|Sub-Option Len |   Context-ID  |P|  Reserved   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |           AVPs
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
> 
> 
>    Sub-Option Type:
>                   T.B.A
> 
>    Sub-Option Length:
>                   Length of the Sub-Option (including type and length
>                   fields as well as AVPs) in units of 8 octets. 
> 
>    Context-ID:    Identifies L2 ID, IP address and capability triples,
>                   coming with separate sub-options.

I still cant figure out the Context-ID.


> 
>    Flags:         P-flag: Indicates piggybacking capability of a CAR.
>                   This flag allows a MN already after a CARD process to
>                   know about a selected new AR's piggybacking
>                   capability.

piggybacking capability for a sub-option? if the Capability
Container Sub-Option is always used with either the CARD
Request or CARD Reply options, why do you need piggybacking
for this sub-option? 

is it for piggybacking the sub-option on any ICMP message?
for example is it for piggybacking this sub-option on the 
Link-layer Address Option (section 6.5.3 of 
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-06.txt)?



>    5.1.3.5 Address Sub-Option
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Sub-Option Type|Sub-Option Len |  Context-ID   | Address Type  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |            Address . . .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
> 
> 
>    Sub-Option Type:
>                   T.B.A
> 
>    Sub-Option Length:
>                   Length of the Sub-Option (including type and length
>                   fields) in units of octets. 
> 
>    Context-ID:    Identifies L2 ID, IP address and capability triples,
>                   coming with separate sub-options.
> 
>    Address Type:  Indicates the type of the address.
> 
>                               0x01  IPv4
>                               0x02  IPv6

if IPv6 address is present, then this sub-option requires an
alignment requirement of 8n+4.



>    5.1.4 Capability AVP encoding rule
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        AVP Code       |S| Res |          AVP Length           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |             Attribute Lifetime  (present if S = 0)            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              Data . . .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
> 

>    Flags:         S-flag (Static)   1: identifies a static attribute,
>                                        lifetime field is not present.
>                                        Data will follow immediately
>                                        after the AVP Length field.
>                               
>                                     0: identifies a dynamic attribute,
>                                        lifetime field indicates the
>                                        attribute's lifetime.
> 
>                   Reserved (Res) flags MUST be set to 0.
> 
>    Lifetime:      Specifies the lifetime of the encoded capability
>                   in seconds. This field is only present if the encoded
>                   capability has a lifetime associated and the S-bit
>                   has not been set.


why complicate things? let the lifetime field be there always.
if the lifetime is set to infinity, then it means it is a
static attribute. if the lifetime is set to a valid value,
then it means the attribute is a dynamic attribute.


> 
>    5.2 CARD Messages for the inter-Access Router Protocol Operation
> 
>    5.2.1 Protocol Transport
> 
>    For the CARD protocol operation on the network side between a MN's
>    current AR and CARs, UDP [9] is used as transport for CARD protocol
>    messages. The associated UDP port for the CARD protocol operation is
>    T.B.A.

why not ICMP between the Access Routers? when a router receives a
CARD Request message, it needs separate processing in both ICMP
and UDP modules. 


> 
>          Description                Type              Interface
>              |                       |               /         \
>              |                       |            MN-AR       AR-AR
>      ---------------------------------------------------------------
>          L2 ID                     T.B.A            x
>          Preferences               T.B.A            x           x

I dont remember reading any where in the text where the Preferences
sub-option is used between Access Routers? did I miss it?

------=_NextPart_000_00A9_01C345F0.5E961EB0--


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 06:58: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 GAA27228
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 06:58:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeM-0002Lp-Vg
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h69AwEB4009033
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeM-0002Lc-SK
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 06:58: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 GAA27146
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 06:58:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCeI-0005s4-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCeH-0005rY-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeD-0002Eh-Ts; Wed, 09 Jul 2003 06:58:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCFN-0008GQ-QS
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 06:32: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 GAA26708
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 06:32:21 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCFJ-0005jO-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 06:32:21 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCFJ-0005jL-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 06:32:21 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69AWLa28668
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 13:32:21 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6353abf400ac158f25f35@esvir05nok.ntc.nokia.com>;
 Wed, 9 Jul 2003 13:32:20 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 13:32:19 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 13:32:18 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] CT: [New Editorial Issue] Need a Contributors Section
Date: Wed, 9 Jul 2003 13:32:18 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F0E0@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] CT: [New Editorial Issue] Need a Contributors Section
Thread-Index: AcM/YZACiQXhx2LfQt+B/y/Tc6S/FgGo8ijg
To: <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
X-OriginalArrivalTime: 09 Jul 2003 10:32:18.0928 (UTC) FILETIME=[5F9AFF00:01C34605]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Assigned issue 25 - and accepted.

John

> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: 01 July, 2003 02:36
> To: seamoby@ietf.org
> Subject: [Seamoby] CT: [New Editorial Issue] Need a=20
> Contributors Section
>=20
>=20
> The Seamoby Review Board was explicitly solicited for and=20
> provided detailed
> commentary on the CT draft.  As such, the contribution of the=20
> review board
> members should receive a larger acknowledgement (as should=20
> that for anybody
> else who took the time to read through the whole draft and=20
> write up a list
> of detailed comments). Therefore, the names of the Review=20
> Board members
> should be included in a Contributors section. The following=20
> describes this
> section (from draft-rfc-editor-rfc2223bis-06.txt):
>=20
>            An RFC may include a Contributors section, listing those
>            contributors who deserve significant credit for=20
> the document
>            contents.  The Contributors section is intended to=20
> provide a
>            level of recognition greater than an acknowledgment and
>            nearly equal to listing on the front page.  The choice of
>            either, both, or none of Contributor and Acknowledgment
>            sections in a particular RFC depends upon the circumstance.
>=20
> Contributors to the CT review were Basavaraj Patil, Pekka=20
> Savola, and Atti
> Tuominen. Note that we are also attempting to get the names=20
> of the Review
> Board on the Seamoby Web page, but the change is currently on=20
> hold pending
> AD review.
>=20
>             jak
>=20
>=20
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>=20

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 06:58:47 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 GAA27243
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 06:58:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeT-0002ME-Kr
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h69AwLYR009056
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeT-0002Lz-Hb
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 06:58:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27153
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 06:58:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCeP-0005sJ-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:17 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCeO-0005rZ-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCeG-0002H9-Fi; Wed, 09 Jul 2003 06:58:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aCYf-0001nL-Ul
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 06:52: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 GAA26984
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 06:52:17 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCYb-0005o8-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 06:52:17 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aCYa-0005o0-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 06:52:17 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69AqGk05455
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 13:52:17 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6353be3560ac158f23076@esvir03nok.nokia.com>;
 Wed, 9 Jul 2003 13:52:16 +0300
Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 13:52:15 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 13:52:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C34608.28124C7D"
Subject: RE: [Seamoby] Context Transfer Extension to Cellular-IP v01
Date: Wed, 9 Jul 2003 13:52:14 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F0E3@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Context Transfer Extension to Cellular-IP v01
Thread-Index: AcNFcod4/ztHIR62QMCB6OJUIU/pNQAlUGDQ
To: <m.georgiades@eim.surrey.ac.uk>, <seamoby@ietf.org>
X-OriginalArrivalTime: 09 Jul 2003 10:52:15.0163 (UTC) FILETIME=[289DF8B0:01C34608]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C34608.28124C7D
Content-Type: text/plain;
	charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Michael,
=20
I gave the draft a quick read, I have no substantial comments at the =
moment,
but I did notice some formatting bugs & also I suggest that you =
normalize
the terminology with the terminology in the Terminalogy draft.
=20
One question, as this seems to be an extention to Cellular IP and not
really related to CTP that we are working on in Seamoby, I am not sure
the relevance of this draft.  I will remind you that we are trying to go
dormant after this meeting in Vienna.
=20
thanks,
John


Hi all,=20

The Internet draft below, proposes a Context Transfer Extension to=20
Cellular-IP.=20


        Title           : Context Transfer Extension to Cellular-IP=20
        Author(s)       : M. Georgiades et al.=20
        Filename        : draft-georgiades-seamoby-ctecip-01.txt=20
        Pages           : 13=20
        Date            : 2003-7-1=20
 =20
This Internet draft enhances cellular-IP mobility protocol with a=20
Context Transfer mechanism aiming to further optimise the handoff=20
operation in mobile networks. Within a cellular-IP domain, during the=20
handoff from one cellular-IP base station to another, cellular-IP=20
packets could be  used to initiate and transfer authorised context=20
from the previous cellular-IP base station via the cellular-IP=20
gateway to the new cellular-IP base station. This draft presents how=20
the context transfer extension introduced could facilitate in=20
reducing latency and packet loss by avoiding the signalling required=20
between the mobile node and the new base station  in  re-establishing=20
the desired state information.=20


URL:=20
http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctecip-01.tx=
t=20

--=20

Michael Georgiades

Research Fellow

Centre for Communication Systems Research

University of Surrey

Guildford, Surrey, GU2 7XH



Tel: +44 (0) 1483 683605

Fax: +44 (0) 1483 686011

www.ee.surrey.ac.uk/ccsr
 =20


------_=_NextPart_001_01C34608.28124C7D
Content-Type: text/html;
	charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-15">


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 vLink=3D#ff0000 aLink=3D#000088 link=3D#0000ff =
bgColor=3D#ffffff>
<DIV><SPAN class=3D693344910-09072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Michael,</FONT></SPAN></DIV>
<DIV><SPAN class=3D693344910-09072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D693344910-09072003><FONT face=3DArial color=3D#0000ff =
size=3D2>I gave=20
the draft a quick read, I have no substantial comments at the=20
moment,</FONT></SPAN></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN =
class=3D693344910-09072003><FONT=20
face=3DArial color=3D#0000ff>but I did notice some formatting bugs &amp; =
also I=20
suggest that you normalize</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D693344910-09072003>the=20
terminology with the terminology in the Terminalogy =
draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D693344910-09072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D693344910-09072003>One=20
question, as this seems to be an extention to Cellular IP and=20
not</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D693344910-09072003>really=20
related to CTP that we are working on in Seamoby, I am not=20
sure</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D693344910-09072003>the=20
relevance of this draft.&nbsp; I will remind you that we are trying to=20
go</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D693344910-09072003>dormant after this meeting in=20
Vienna.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D693344910-09072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D693344910-09072003>thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D693344910-09072003>John</SPAN></FONT><FONT face=3DTahoma><FONT=20
size=3D2><BR></DIV></FONT></FONT>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">Hi=20
  all,=20
  <P>The Internet draft below, proposes a Context Transfer Extension to=20
  <BR>Cellular-IP.=20
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Context=20
  Transfer Extension to Cellular-IP=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : M. Georgiades et al.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  draft-georgiades-seamoby-ctecip-01.txt=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 13 =

  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:=20
  2003-7-1 <BR>&nbsp; <BR>This Internet draft enhances cellular-IP =
mobility=20
  protocol with a <BR>Context Transfer mechanism aiming to further =
optimise the=20
  handoff <BR>operation in mobile networks. Within a cellular-IP domain, =
during=20
  the <BR>handoff from one cellular-IP base station to another, =
cellular-IP=20
  <BR>packets could be&nbsp; used to initiate and transfer authorised =
context=20
  <BR>from the previous cellular-IP base station via the cellular-IP =
<BR>gateway=20
  to the new cellular-IP base station. This draft presents how <BR>the =
context=20
  transfer extension introduced could facilitate in <BR>reducing latency =
and=20
  packet loss by avoiding the signalling required <BR>between the mobile =
node=20
  and the new base station&nbsp; in&nbsp; re-establishing <BR>the =
desired state=20
  information.=20
  <P>URL: <BR><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctec=
ip-01.txt">http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-c=
tecip-01.txt</A>=20
<PRE>--&nbsp;
Michael Georgiades
Research Fellow
Centre for Communication Systems Research
University of Surrey
Guildford, Surrey, GU2 7XH

Tel: +44 (0) 1483 683605
Fax: +44 (0) 1483 686011
www.ee.surrey.ac.uk/ccsr</PRE>&nbsp; </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C34608.28124C7D--

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 11:13: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 LAA04411
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 11:13:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGd9-000187-SG
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDFIb004339
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGd9-00017u-Ow
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04145
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 11:13:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aGd8-0007Gx-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:14 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aGd8-0007GP-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGcv-0000uk-Kz; Wed, 09 Jul 2003 11: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 19aDGs-0007Cu-Uz
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 07:38: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 HAA28019
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 07:38:01 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aDGs-00067U-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 07:38:02 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aDGr-00067R-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 07:38:01 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h69Bbxa22499
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 14:37:59 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6353e80ac7ac158f25f35@esvir05nok.ntc.nokia.com> for <seamoby@ietf.org>;
 Wed, 9 Jul 2003 14:37:58 +0300
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 14:37:57 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 9 Jul 2003 14:37:51 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3460E.86A0D674"
Subject: RE: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-02.txt
Date: Wed, 9 Jul 2003 14:37:49 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F0EB@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-02.txt
Thread-Index: AcMu0w3iL3yh9TkVSC2UWe4CjRDjKAXO2WtQ
To: <m.georgiades@eim.surrey.ac.uk>, <seamoby@ietf.org>
Cc: <C.Politis@eim.surrey.ac.uk>
X-OriginalArrivalTime: 09 Jul 2003 11:37:51.0718 (UTC) FILETIME=[87BB2060:01C3460E]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3460E.86A0D674
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Mike,
=20
Sorry, somehow this message seemed to have been lost.  I've assigned =
this to issue 26 & get the corrections in the next update.
=20
thanks,
John

-----Original Message-----
From: ext Michael Georgiades [mailto:m.georgiades@eim.surrey.ac.uk]
Sent: 03 June, 2003 19:31
To: seamoby
Cc: Christos Politis
Subject: Re: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-02.txt


Hi all,=20

I have attached a review of the ctp-02 draft.=20
I have made some comments and questions marked with "M.Georgiades" and =
made some minor corrections (Please ignore if incorrect).=20


Best regards,=20


Mike=20


Internet-Drafts@ietf.org wrote:=20


A New Internet-Draft is available from the on-line Internet-Drafts =
directories.=20
This draft is a work item of the Context Transfer, Handoff Candidate =
Discovery, and Dormant Mode Host Alerting Working Group of the IETF.=20

        Title           : Context Transfer Protocol=20
        Author(s)       : J. Loughney et al.=20
        Filename        : draft-ietf-seamoby-ctp-02.txt=20
        Pages           : 21=20
        Date            : 2003-5-30=20
 =20
=20

--=20

Michael Georgiades

Research Fellow

Centre for Communication Systems Research

University of Surrey

Guildford, Surrey, GU2 7XH



Tel: +44 (0) 1483 683605

Fax: +44 (0) 1483 686011

www.ee.surrey.ac.uk/ccsr
 =20


------_=_NextPart_001_01C3460E.86A0D674
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 vLink=3D#ff0000 aLink=3D#000088 link=3D#0000ff =
bgColor=3D#ffffff>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Mike,</FONT></SPAN></DIV>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry,=20
somehow this message seemed to have been lost.&nbsp; I've assigned this =
to issue=20
26 &amp; get the corrections in the next update.</FONT></SPAN></DIV>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =

size=3D2>thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D898173711-09072003><FONT face=3DArial color=3D#0000ff =

size=3D2>John</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext Michael =
Georgiades=20
  [mailto:m.georgiades@eim.surrey.ac.uk]<BR><B>Sent:</B> 03 June, 2003=20
  19:31<BR><B>To:</B> seamoby<BR><B>Cc:</B> Christos =
Politis<BR><B>Subject:</B>=20
  Re: [Seamoby] I-D =
ACTION:draft-ietf-seamoby-ctp-02.txt<BR><BR></FONT></DIV>Hi=20
  all,=20
  <P>I have attached a review of the ctp-02 draft. <BR>I have made some =
comments=20
  and questions marked with "M.Georgiades" and made some minor =
corrections=20
  (Please ignore if incorrect).=20
  <P>Best regards,=20
  <P>Mike=20
  <P>Internet-Drafts@ietf.org wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">A New Internet-Draft is available from the =
on-line=20
    Internet-Drafts directories. <BR>This draft is a work item of the =
Context=20
    Transfer, Handoff Candidate Discovery, and Dormant Mode Host =
Alerting=20
    Working Group of the IETF.=20
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Context=20
    Transfer Protocol <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Loughney et al.=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
    draft-ietf-seamoby-ctp-02.txt =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
21=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =

    2003-5-30 <BR>&nbsp; <BR>&nbsp;</P></BLOCKQUOTE><PRE>--&nbsp;
Michael Georgiades
Research Fellow
Centre for Communication Systems Research
University of Surrey
Guildford, Surrey, GU2 7XH

Tel: +44 (0) 1483 683605
Fax: +44 (0) 1483 686011
www.ee.surrey.ac.uk/ccsr</PRE>&nbsp; </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3460E.86A0D674--

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 11:13:59 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 LAA04664
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 11:13:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdN-0001Ph-3k
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:31 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDTgH005427
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdM-0001PS-LA
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13: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 LAA04208
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 11:13:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aGdK-0007IL-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:27 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aGdK-0007HD-00
	for seamoby-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdA-00018d-Gp; Wed, 09 Jul 2003 11:13:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aEtl-0008Sr-Mg
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 09: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 JAA00119
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 09:22:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aEtk-0006eF-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 09:22:16 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aEti-0006e6-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 09:22:15 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h69DLVVI018505;
	Wed, 9 Jul 2003 15:21:31 +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 C11A7A1D78; Wed,  9 Jul 2003 15:03:51 +0200 (CEST)
Message-ID: <3F0C16DB.6010901@ccrle.nec.de>
Date: Wed, 09 Jul 2003 15:21:31 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] CARD Review from Vijay
References: <00ac01c345df$9c6082a0$876015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Many thanks to Vijay for the review and comments.
Issues and comments according to this review have been incorporated into
the issue tracker and comprise issue 9 -34. Overlaping issues have not been
incorporated again.

marco



James Kempf wrote:

>Review of CARD from Vijay Deverapali is attached. Vijay is on the Seamoby
>Review Board.
>
>            jak
>  
>
>  
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul  9 11:14:19 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 LAA05009
	for <seamoby-archive@odin.ietf.org>; Wed, 9 Jul 2003 11:14:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdj-0001bw-Mb
	for seamoby-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:51 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDpuU006188
	for seamoby-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdj-0001bj-IP
	for seamoby-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13:51 -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 LAA04482
	for <seamoby-web-archive@ietf.org>; Wed, 9 Jul 2003 11:13:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aGdF-0001DT-46; Wed, 09 Jul 2003 11:13:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aFcD-0004ax-9y
	for seamoby@optimus.ietf.org; Wed, 09 Jul 2003 10:08:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01588
	for <seamoby@ietf.org>; Wed, 9 Jul 2003 10:08:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aFcB-0006qB-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 10:08:11 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aFcA-0006pv-00
	for seamoby@ietf.org; Wed, 09 Jul 2003 10:08:10 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h69E7UVI021653;
	Wed, 9 Jul 2003 16:07:35 +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 DA68AAC9D1; Wed,  9 Jul 2003 15:49:50 +0200 (CEST)
Message-ID: <3F0C21A2.8040308@ccrle.nec.de>
Date: Wed, 09 Jul 2003 16:07:30 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>
Cc: James Kempf <kempf@docomolabs-usa.com>
Content-Type: multipart/related;
 boundary="------------070101050802010209060606"
Subject: [Seamoby] CARD issue 7: separate appendix from the CARD protocol speciifcation
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>


--------------070101050802010209060606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

With regard to the protocol extension for dynamic maintenance
of reverse address translation info in CAR tables, as described
in the current draft's appendix, what about shortening the two
proposals for an optional backend protocol solution and to just
describe the basics in the appendix, e.g. what's added from
protocol point of view. Discussion on related security
associations, etc. could be in a separate document,
which provides more details.

Advantage of keeping an overview of the extensions in 
the core document is to get an idea about possible solutions for
backend protocol operation. Maybe this is feasible in particular
since the CARD protocol will be experimental.

In case the appendix will go into a separate document, what
about the "application scenarios" ? I think this is reasonable to
have them in the core spec. Comments?

marco 


 

-----------
was: [CARD editorial issue]: Excessive appendix size

The appendix in the CARD draft is almost as large as the draft itself. How
about performing an appendectomy :-) and separating the appendix out into a
separate draft? I think it would be easier for readers, and especially the
IESG, to process.

            jak



--------------070101050802010209060606--


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 04:54: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 EAA23155
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 04:54: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 19aXBm-0004E3-2x
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 04:54:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8s6nH016242
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 04:54:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aXBl-0004Dt-Vu
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 04:54: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 EAA23145
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 04:54:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXBj-0000jq-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 04:54:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXBi-0000jm-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 04: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 19aXBh-0004DE-1x; Thu, 10 Jul 2003 04: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 19aXBE-0004Ci-9y
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 04:53: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 EAA23134
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 04:53:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXBB-0000jY-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 04:53:29 -0400
Received: from phoebe.eim.surrey.ac.uk ([131.227.74.4] ident=exim)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXBA-0000jV-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 04:53:28 -0400
Received: from ccsrmclt03.ee.surrey.ac.uk
	([131.227.86.163] helo=eim.surrey.ac.uk ident=ees2mg)
	by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 19aXAV-00078p-00; Thu, 10 Jul 2003 09:52:47 +0100
Message-ID: <3F0D295F.D58D4D74@eim.surrey.ac.uk>
Date: Thu, 10 Jul 2003 09:52:47 +0100
From: Michael Georgiades <m.georgiades@eim.surrey.ac.uk>
Organization: University of Surrey
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17.7.x i686)
X-Accept-Language: en, el
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: seamoby <seamoby@ietf.org>
Subject: RE: [Seamoby] Context Transfer Extension to Cellular-IP v01
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-105.4 required=5.5
	tests=BAYES_01,USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
X-Scanner: exiscan *19aXAV-00078p-00*6huKNihuX4A* (SECM, UniS)
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi John,

Thanks for your comments about the draft. I will make this corrections
on the
next update.

By submitting this draft we are not by any means undermining the work of
the 
Context Transfer Team. In this draft we are demonstrating how the
handover 
protocol could be modified to transfer the state information which is
especially 
suitable in cases where the mobility protocol makes use of a central
entity 
(Using cellular-IP as an example).

We believe that when such a mobility protocol is used it may be more
appropriate
to utilise the existing message exchange rather than to have a
specialised 
Context Transfer protocol. 

Cheers,

Mike


>Hi Michael,
 
>I gave the draft a quick read, I have no substantial comments at the moment,
>but I did notice some formatting bugs & also I suggest that you normalize
>the terminology with the terminology in the Terminalogy draft.
 
>One question, as this seems to be an extention to Cellular IP and not
>really related to CTP that we are working on in Seamoby, I am not sure
>the relevance of this draft.  I will remind you that we are trying to go
>dormant after this meeting in Vienna.
 
>thanks,
>John

        Hi all, 

        The Internet draft below, proposes a Context Transfer Extension
to 
        Cellular-IP. 

                Title           : Context Transfer Extension to
Cellular-IP 
                Author(s)       : M. Georgiades et al. 
                Filename        : draft-georgiades-seamoby-ctecip-01.txt 
                Pages           : 13 
                Date            : 2003-7-1 
          
        This Internet draft enhances cellular-IP mobility protocol with
a 
        Context Transfer mechanism aiming to further optimise the
handoff 
        operation in mobile networks. Within a cellular-IP domain,
during the 
        handoff from one cellular-IP base station to another,
cellular-IP 
        packets could be  used to initiate and transfer authorised
context 
        from the previous cellular-IP base station via the cellular-IP 
        gateway to the new cellular-IP base station. This draft presents
how 
        the context transfer extension introduced could facilitate in 
        reducing latency and packet loss by avoiding the signalling
required 
        between the mobile node and the new base station  in 
re-establishing 
        the desired state information. 

        URL: 
       
http://www.ietf.org/internet-drafts/draft-georgiades-seamoby-ctecip-01.txt 

        -- 
        Michael Georgiades
        Research Fellow
        Centre for Communication Systems Research
        University of Surrey
        Guildford, Surrey, GU2 7XH

        Tel: +44 (0) 1483 683605
        Fax: +44 (0) 1483 686011
        www.ee.surrey.ac.uk/ccsr

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 06: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 GAA26174
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 06: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 19aZ0z-0003oV-Oi
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 06:51:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AAp52X014653
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 06:51:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aZ0z-0003oG-Ka
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 06:51:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26151
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 06:50:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aZ0v-0001bF-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 06:51:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aZ0u-0001bC-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 06: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 19aZ0v-0003nb-In; Thu, 10 Jul 2003 06: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 19aZ0M-0003gl-Qo
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 06:50: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 GAA26146
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 06:50:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aZ0I-0001b2-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 06:50:22 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aZ0H-0001az-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 06:50:21 -0400
Message-ID: <021501c346d1$166a72d0$636015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Thu, 10 Jul 2003 12:50:31 +0200
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 Henrick 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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello all,

Jak and Pat asked me to review the CARD protocol draft based on my
experience in implementing MIPv6. I hope this review will
help in improving the I-D.

Regards,

Henrik Petander

--------------------------------------------------------------------

Comments on the protocol
========================

Choice of transport
-------------------

MN-AR and AR-AR protocols are in the draft carried over ICMP and UDP.
The reason for the separate transports seems to be the piggybacking
defined in section 4.5. However, piggybacking appears does not appear to
be necessary (see comments on section 4.5 for details).  Without
piggybacking it would be simpler to run both MN-AR and AR-AR protocols
over UDP and use the same message formats.


Removal of per-session state from ARs
-------------------------------------

The responsiblity for resends for MN initiated sessions is both in
the MN and the current AR. Since the weakest link in the protocol from a
reliability POV is probably the air interface, the AR-AR resending in
the MN initiated sessions is probably not worth the extra complexity.

Removing it would simplify AR a lot, since it would not need to maintain
any state for CARD in addition to the CAR table. An AR without
per-session state would be less vulnerable to DoS attacks and would also
scale better.

(The preferences and requirements should then be appended also to the
current AR - CAR messages, if the current AR lacks knowledge of the
capabilities of CARs.)

4. CARD PROTOCOL OPERATION
--------------------------

Is there a specific reason to use the rate limiting flag instead of
normal ICMP rate limiting ?

Anyways, the rate limiting mechanism, which MN uses after getting a
reply with R-bit set, should be defined. There exist a number of
already defined mechanisms for dealing with resending intervals and
rate limiting. Why not use one of them?



4.1 Data structures
-------------------

Should there be a recommendation for MN to cache the information about
CARs ?  MN needs a CAR table with cached answers from CARD
replies to avoid asking the same information repeatedly, and for being
able to react to movement as quickly as possible.


4.2.2 Current access router operation
-------------------------------------

If you use IPSec ESP for protecting CARD between MN and AR, you cannot
send multicast CARD replies. IPSec security associations are between
two hosts.

You need to protect the CARD replies in some other way (for example
with signatures as proposed in the CARD problem statement draft), or
always send them as unicast packets.

4.3.1 Current access router operation
-------------------------------------

Is it necessary to include the capabilities of current AR in
AR-AR CARD request message?

If the data in a current AR for a CAR is not up to date, it still does
not mean that the data for the current AR is not up to date in the
CAR. Including the AR-AR CARD reply automatically in the CARD request
creates unnecessary load in both routers when they authenticate /
encrypt extra data.

This optimization also adds extra complexity to the protocol, and it is
not clear to me whether it is worth it.

4.4. CARD Signaling Failure Recovery
------------------------------------

The draft does not define what an AR sends to MN, when it cannot
resolve a L2 address into an IP address. This should be specified
clearly.

4.4.2 AR-AR signaling failure
-----------------------------

What does the CAR send to current AR, if it does not have an interface
/ AP attached to it with the queried L2 id? This should be
defined.

4.5 Piggybacking
----------------

In appendix B.2, there is a note that it may not be necessary to use
FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
since the CARD messages convey all the necessary information. This
seems to make the piggybacking of CARD on top of the PrRt messages
irrevelant. Is there some reason to do it, which is just missing from
the text?

If not, this section should be removed and the messages should be
carried on top of UDP as in AR-AR case.


4.6 CARD protocol security
---------------------------

You should move everything about IPSec ESP here and indicate clearly
how it should be used. Now the text about its use is scattered around
section 4. Perhaps the security section should be renamed "Protection
of CARD messages" to make a clear distinction between the
implementation of the protection versus the analysis in section 6.

The section should say that 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. Definition of the SPD entries
would also be nice.

5. Protocol messages
--------------------

Is 8 bits enough for the CARD option length field? This translates to
255 octets, which seems limiting to me, especially since the
capabilities have not been defined. Also the AVP encoding rules in
5.1.4 have a 16-bit length field, which conlicts with the fact that
they still need to fit within the options with 8-bit length fields.

AR - AR message format in 5.2.2 includes a length field which is
redundant with UDP's length field and should be removed.

7. Protocol constants
----------------------

Where are their values defined?


Editorial comments
==================

General
--------

The term SHALL was used in the section 4 for use of IPSec
ESP. However, in sections 5 and 6 the word SHOULD was used
instead. The use of "SHALL" was new to me so I checked its meaning
from RFC 2119. According to the RFC its use is: "MUST   This word, or
the terms "REQUIRED" or "SHALL", mean that the definition is an
absolute requirement of the specification."

This should be fixed.  If capabilities such as pricing information are
transferred between ARs and MNs, I would opt for use of SHALL/MUST for
the authentication requirement. Also the card requirements draft uses
the word MUST for authentication and SHOULD for encryption.

4.3.2 Candidate Access Router Operation
---------------------------------------

Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
optionally encryption of the AR-AR CARD Reply message."

Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
do not provide integrity protection and should not be used without
an authentication & integrity protection algorithm.

4.4.1 MN-AR Signaling Failure
-----------------------------

"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
   CARD Request message with the given sequence number."

Shouldn't it be the MN, which starts the timer instead of AR?


5.1.1 CARD Main Header Format
-----------------------------

"Encapsulating Security Payload (ESP) Header:
The sender SHOULD include the Encapsulating
Security Payload (ESP) Header, based on the
          previously established Security Association
          between the sender and the receiver."

Shouldn't this SHOULD be MUST intead?

5.2.1 Protocol Transport
------------------------

"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
     be used [10]."

Again, SHOULD vs. MUST/SHALL.

6.1 Assumptions
---------------
Second paragraph, last sentence:

"The appendices of this draft describe procedures for discovering the
identities of the geographically ARs and APs and relevant security
considerations."

There seems to be a word missing after "geographically". Adjacent?

6.2 Security Association between AR and AR
-------------------------------------------

"To prevent the information from being compromised, the CARD REPLY
   messages between ARs SHOULD be authenticated. The messages also MAY
   be encrypted for privacy of the information."

Again SHOULD vs. MUST/SHALL.

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 SHOULD authenticate the CARD REPLY
messages from the AR."

Again SHOULD vs. MUST/SHALL.

6.4 DoS Attack
--------------

Should it be mentioned here that authenticating CARD requests is
needed to allow ARs to protect themselves against CARD request
flooding with spoofed addresses?

(Authenticating the requests makes DoS less likely as the attacker's
identity is revealed and her account can be disabled, etc.)

The meaning of the second paragraph is not clear to me. How can an
attacker masquerade as an AR, if all entities in the protocol are
authenticated? It seems to me that this would be possible only if an
AR is compromised. Should the protocol be secure also against
compromised routers?  This should be specified in the assumptions
section.


Appendix A.
----------

The appendixes form quite a large part of the draft. A.1 and A.2
should be either integrated into the main draft as optional parts or
be separated into their own drafts.

A.1.4.1 Security Associations

More details are needed on how IPSec ESP is used.

A.2

What does pAR send to current AR to verify that it had or did not have
state for MN?


A.2.4

"should" vs MUST be protected with IPSec ESP.

Appendix B.
----------

B.1 should be removed, since it is not needed for implementation of the
protocol. The draft is self explanatory enough to be used with
IEEE 802.11 WLANs without this appendix.

B.2 raises the question, whether there is a need for an "architecture"
draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
be used together.





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 10:55:38 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 KAA05711
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 10:55:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19acpF-0006ki-9l
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 10:55:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AEtDRE025950
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 10:55:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19acpF-0006kT-5f
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 10:55:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05701
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 10:55:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19acpC-0003ba-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 10:55:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19acpC-0003bX-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 10:55:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19acp2-0006jj-Sw; Thu, 10 Jul 2003 10:55:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19acot-0006jO-0h
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 10:54: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 KAA05691
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 10:54:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19acoq-0003bN-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 10:54:48 -0400
Received: from herculanum.int-evry.fr ([157.159.11.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 19acop-0003bJ-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 10:54:48 -0400
Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20])
	by herculanum.int-evry.fr (Postfix) with ESMTP id A06B833F9C
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 16:54:16 +0200 (CEST)
Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19])
	by spartebis.int-evry.fr (Postfix) with SMTP id EE9F83F423
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 17:11:39 +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 M2003071016541606276
 for <seamoby@ietf.org>; Thu, 10 Jul 2003 16:54:16 +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 C17803F422
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 17:11:39 +0200 (CEST)
Received: from jb by ipv6-5.int-evry.fr with local (Exim id 19acoO-000PI6-Gs
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 16:54:20 +0200
Date: Thu, 10 Jul 2003 16:54:20 +0200
From: Julien Bournelle <Julien.Bournelle@int-evry.fr>
To: seamoby@ietf.org
Message-ID: <20030710145420.GU263@ipv6-5.int-evry.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Seamoby] CTP - Context Data block Length
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi all,

 The Context Data Block header doesn't have a length field. 
As such, I don't see how the implementation can point to the next block.

Do I miss something ?

bye,

-- 
julien.bournelle@int-evry.fr

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 12:45: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 MAA11445
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 12:45: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 19aeXb-0000cr-WB
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 12:45:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGj79L002401
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 12:45:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aeXb-0000ce-S7
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 12:45:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11436
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 12:45:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeXa-0004zf-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 12:45:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeXZ-0004zc-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 12:45:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aeXV-0000bg-IA; Thu, 10 Jul 2003 12: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 19aeWf-0000Xk-BC
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 12:44: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 MAA11371
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 12:44:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeWd-0004yO-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 12:44:07 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeWc-0004wB-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 12:44:06 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6AGhNVI066405;
	Thu, 10 Jul 2003 18:43: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 B368077BDE; Thu, 10 Jul 2003 18:25:33 +0200 (CEST)
Message-ID: <3F0D97AD.7060001@ccrle.nec.de>
Date: Thu, 10 Jul 2003 18:43:25 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>, vijayd@iprg.nokia.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD issue#9: Reverse address translation - CARD vs. FMIPv6
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Vijay and all,

according to your review, issue#9 addresses the following:  

"section 3.1 Reverse address translation:
How does this fit in with the ProxyRtrSolict and ProxyRtrAdvert
in FMIPv6? FMIPv6 already does Reverse Address Translation
through these two messages."

[marco]: According to my knowledge, FMIPv6 considers only one 
L2 ID to be included in the RtSolPr message, which is the 
identifier of the handover target AP and to be resolved to
the IP address of the associated AR. Now, what CARD adds is
to allow a MN sending "multiple" L2 IDs to its current AR and
to retrieve associated CARs' IP address as well as capability
info. This allows performing discovery of CARs with the
RtSolPr/PrRtAdv protosol sequence, whereas standard FMIPv6
RtSolPr/PrRtAdv protosol sequence considers only target AP/AR
address to be conveyed, as far as I can see from the draft.

Could this be a motivation to allow CARD protocol 
piggybacking with FMIPv6?

marco



 

 



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 12:52: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 MAA11904
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 12:52: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 19aeeK-0001MJ-QC
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 12:52:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGq4bF005217
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 12:52:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aeeK-0001M4-LR
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 12:52: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 MAA11875
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 12:51:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeeI-00057g-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 12:52:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aeeH-00057d-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 12:52:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aeeI-0001KQ-3j; Thu, 10 Jul 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 19aedi-0001Jf-W8
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 12:51:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11843
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 12:51:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aedh-00056z-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 12:51:25 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aedg-00056B-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 12:51:24 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6AGorVI066800;
	Thu, 10 Jul 2003 18:50:53 +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 5E6315A297; Thu, 10 Jul 2003 18:33:03 +0200 (CEST)
Message-ID: <3F0D996F.90403@ccrle.nec.de>
Date: Thu, 10 Jul 2003 18:50:55 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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: vijayd@iprg.nokia.com, Seamoby <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD  issue#10:Performing CARD with CARs directly via available IP
 connectivity
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Issue#10 raised by Vijay:

section 3.1:
"...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 reverse address translation."

[Vijay]"In this case, is Router Solicitation and Router Advertisement
used for reverse address translation? What is needed for CARD
messages here?"
 
[marco]I think this is more an editorial issue and I agree to 
your comment. Text should rather address the capability discovery
function here and could be as follows:
"...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 to perform capability discovery."

What do you think?

marco



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 10 13:02: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 NAA12452
	for <seamoby-archive@odin.ietf.org>; Thu, 10 Jul 2003 13:02: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 19aenz-0002No-Ka
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 13:02:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AH23bO009154
	for seamoby-archive@odin.ietf.org; Thu, 10 Jul 2003 13: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 19aenz-0002NZ-G2
	for seamoby-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 13:02: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 NAA12424
	for <seamoby-web-archive@ietf.org>; Thu, 10 Jul 2003 13:01:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aenx-0005Dm-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 13:02:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aenx-0005Dj-00
	for seamoby-web-archive@ietf.org; Thu, 10 Jul 2003 13:02:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aenx-0002Mu-0F; Thu, 10 Jul 2003 13:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aenN-0002MC-H8
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 13:01: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 NAA12399
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 13:01:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aenL-0005DK-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 13:01:23 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aenK-0005Cm-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 13:01:22 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6AH0pVI067671;
	Thu, 10 Jul 2003 19:00:51 +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 7468CB6259; Thu, 10 Jul 2003 18:43:01 +0200 (CEST)
Message-ID: <3F0D9BC5.1040809@ccrle.nec.de>
Date: Thu, 10 Jul 2003 19:00:53 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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: vijayd@iprg.nokia.com, Seamoby <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Issue#18: Requesting ARs to perform ONLY reverse address translation
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

issue#18 raised by Vijay on "section 4: CARD protocol operation":

[Vijay]"lets say, the MN is interested only in reverse address
translation and not in capability information. How does the
MN indicate this to the access router? I think supporting
this is essential."

[marco]I agree to this and solutions could be very different
(set a flag or append appropriate Preferences sub-option[indicate NO ATTRIBUTES], ...).

Maybe a flag is most appropriate for this indication to avoid
superfluous protocol overhead, what do you think?

marco




_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 02:18: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 CAA17370
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 02:18: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 19arEN-0000l7-71
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:18:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B6I7Yg002913
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:18:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arEM-0000ku-TI
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 02:18: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 CAA17320
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 02:18:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arEJ-0002c7-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:18:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19arEI-0002c4-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:18:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arEI-0000kD-SY; Fri, 11 Jul 2003 02:18:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arDO-0000iH-MJ
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 02:17: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 CAA17195
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 02:17:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arDK-0002bi-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:17:03 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arDK-0002bd-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:17:02 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA28705;
	Thu, 10 Jul 2003 23:16:29 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6B6GS614572;
	Thu, 10 Jul 2003 23:16:28 -0700
X-mProtect: <200307110616> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (10.241.55.254, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdwdlqsc; Thu, 10 Jul 2003 23:16:26 PDT
Message-ID: <3F0E563A.2080403@iprg.nokia.com>
Date: Thu, 10 Jul 2003 23:16:26 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
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: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Seamoby <seamoby@ietf.org>
References: <3F0D996F.90403@ccrle.nec.de>
In-Reply-To: <3F0D996F.90403@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: CARD  issue#10:Performing CARD with CARs directly via available
 IP connectivity
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

this is fine.

Vijay

Marco Liebsch wrote:

> Issue#10 raised by Vijay:
> 
> section 3.1:
> "...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 reverse address translation."
> 
> [Vijay]"In this case, is Router Solicitation and Router Advertisement
> used for reverse address translation? What is needed for CARD
> messages here?"
> 
> [marco]I think this is more an editorial issue and I agree to your 
> comment. Text should rather address the capability discovery
> function here and could be as follows:
> "...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 to perform capability discovery."
> 
> What do you think?
> 
> marco
> 
> 


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 02:23: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 CAA17683
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 02:23: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 19arJB-0001CF-Ax
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:23:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B6N5Fi004474
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:23:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arJ9-0001A5-Gs
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 02:23:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17656
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 02:22:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arJ5-0002dC-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:23:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19arJ5-0002d9-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:22:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arJ7-00019O-Tr; Fri, 11 Jul 2003 02: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 19arIH-00017b-Li
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 02: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 CAA17650
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 02:22:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arIE-0002cu-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:22:06 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arID-0002cr-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:22:05 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA28973;
	Thu, 10 Jul 2003 23:21:35 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6B6LYs20435;
	Thu, 10 Jul 2003 23:21:34 -0700
X-mProtect: <200307110621> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (10.241.55.254, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdBjkyda; Thu, 10 Jul 2003 23:21:32 PDT
Message-ID: <3F0E576D.4040401@iprg.nokia.com>
Date: Thu, 10 Jul 2003 23:21:33 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
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: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Seamoby <seamoby@ietf.org>
References: <3F0D9BC5.1040809@ccrle.nec.de>
In-Reply-To: <3F0D9BC5.1040809@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: Issue#18: Requesting ARs to perform ONLY reverse address translation
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

for CARD to stand alone as a protocol, it does make sense to
include a flag in the CARD Request so that the MN can explicity
ask the current AR for reverse address translation alone. I
very much would like to see this feature.

but then we have a problem. if a MN uses a CARD Request just for
reverse address translation, then the CARD request does exactly
what the ProxyRtrSolicitation does. ofcourse you can include
more than one L2 ID in the CARD request, whereas you can include
only one L2 ID in ProxyRtrSolicitation.

maybe this is okay. I am not sure. do others have an opinion on
this?

Vijay

Marco Liebsch wrote:

> issue#18 raised by Vijay on "section 4: CARD protocol operation":
> 
> [Vijay]"lets say, the MN is interested only in reverse address
> translation and not in capability information. How does the
> MN indicate this to the access router? I think supporting
> this is essential."
> 
> [marco]I agree to this and solutions could be very different
> (set a flag or append appropriate Preferences sub-option[indicate NO 
> ATTRIBUTES], ...).
> 
> Maybe a flag is most appropriate for this indication to avoid
> superfluous protocol overhead, what do you think?
> 
> marco
> 
> 
> 


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 02:25: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 CAA17752
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 02:25: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 19arL5-0001LU-Uj
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:25:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B6P3oQ005050
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 02:25:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arL5-0001JN-5Y
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 02:25: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 CAA17714
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 02:24:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arL1-0002e8-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:24:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19arL1-0002e5-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 02:24:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arL3-0001Ih-HH; Fri, 11 Jul 2003 02:25:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19arKx-0001I4-R4
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 02:24:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17711
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 02:24:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arKu-0002dz-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:24:52 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19arKt-0002du-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 02:24:51 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA29070;
	Thu, 10 Jul 2003 23:24:21 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6B6OKd22769;
	Thu, 10 Jul 2003 23:24:20 -0700
X-mProtect: <200307110624> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (10.241.55.254, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpddDPAoj; Thu, 10 Jul 2003 23:24:17 PDT
Message-ID: <3F0E5812.3020103@iprg.nokia.com>
Date: Thu, 10 Jul 2003 23:24:18 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
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: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Seamoby <seamoby@ietf.org>
References: <3F0D97AD.7060001@ccrle.nec.de>
In-Reply-To: <3F0D97AD.7060001@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: CARD issue#9: Reverse address translation - CARD vs. FMIPv6
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I guess issue 9 and 10 are related. I have replied to your
mail on issue 10.

Vijay

Marco Liebsch wrote:

> Hi Vijay and all,
> 
> according to your review, issue#9 addresses the following: 
> "section 3.1 Reverse address translation:
> How does this fit in with the ProxyRtrSolict and ProxyRtrAdvert
> in FMIPv6? FMIPv6 already does Reverse Address Translation
> through these two messages."
> 
> [marco]: According to my knowledge, FMIPv6 considers only one L2 ID to 
> be included in the RtSolPr message, which is the identifier of the 
> handover target AP and to be resolved to
> the IP address of the associated AR. Now, what CARD adds is
> to allow a MN sending "multiple" L2 IDs to its current AR and
> to retrieve associated CARs' IP address as well as capability
> info. This allows performing discovery of CARs with the
> RtSolPr/PrRtAdv protosol sequence, whereas standard FMIPv6
> RtSolPr/PrRtAdv protosol sequence considers only target AP/AR
> address to be conveyed, as far as I can see from the draft.
> 
> Could this be a motivation to allow CARD protocol piggybacking with FMIPv6?
> 
> marco
> 
> 
> 
> 
> 
> 
> 
> 


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 06:54: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 GAA24426
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 06:54: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 19avXR-00065r-Bg
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 06:54:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BAs50J023419
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 06:54:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19avXR-00065e-8h
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 06:54: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 GAA24405
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 06:53:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avXN-0004Z6-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 06:54:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19avXM-0004Z2-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 06:54:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19avXN-00064u-E7; Fri, 11 Jul 2003 06: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 19avWp-00062b-3B
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 06:53:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24379
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 06:53:21 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avWk-0004Yl-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 06:53:22 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avWj-0004Yh-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 06:53:22 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6BArLk02523
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 13:53:21 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T635e0bead7ac158f24076@esvir04nok.ntc.nokia.com> for <seamoby@ietf.org>;
 Fri, 11 Jul 2003 13:53:21 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 11 Jul 2003 13:53:21 +0300
Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 11 Jul 2003 13:53:21 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 11 Jul 2003 13:53:20 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Jul 2003 13:53:19 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F129@esebe023.ntc.nokia.com>
Thread-Topic: Context Transfer Protocol
Thread-Index: AcM8q9Pm9zygLpM0R1OamfGKUYdEQwKzC1WwAAidHkA=
To: <seamoby@ietf.org>
Cc: <lassi.hippelainen@nokia.com>
X-OriginalArrivalTime: 11 Jul 2003 10:53:20.0568 (UTC) FILETIME=[A46D7B80:01C3479A]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] FW: Context Transfer Protocol - IPv6???
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

got this comment on CTP.

John

-----Original Message-----
From: Hippelainen Lassi (NET/Helsinki)=20
Sent: 11 July, 2003 10:06
To: Loughney John (NRC/Helsinki)
Subject: RE: Context Transfer Protocol - IPv6???


Hi John,

I was trying to catch up my e-mail after the summer vacation, and found =
this doc in the pile. I have one serious point to raise: where is IPv6? =
Current packet formats do not mention the size of the IP addresses, but =
they seem to assume 32 bits...

The easiest way to handle both IP versions would be to use the reserve =
bits after Message Type. The cleanest way is to copy the four bits that =
are used in the IP header. That means that all IP addresses in a message =
must use the same IP version, but we are not supporting mixed handovers =
between IP versions, are we? And if ARs can forward IPv6 packets to the =
mobile, they themselves have IPv6 addresses as well.

Unfortunately two of the reserve bits have been used for the 'C' and 'R' =
flags. But I cannot find any use for the 'C' flag, and the single use =
for the 'R' flag can be worked around by using two different Message =
Types, one for CTD with response required, other for CTD without it. So =
the bits could be cleared to make room for IP version.

The other alternative is to add to each address a field that defines its =
version, but that would be extremely ugly, because nothing would fit on =
a 32 bit boundary without massive waste of bits...

-- Lassi

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 06: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 GAA24554
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 06: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 19avcE-0006kl-4a
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 06:59:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BAx2ok025953
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 06: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 19avcE-0006kW-0w
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 06:59: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 GAA24526
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 06:58:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avc9-0004bf-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 06:58:57 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19avc9-0004bc-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 06:58:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19avcC-0006jj-PV; Fri, 11 Jul 2003 06: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 19avby-0006jK-6I
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 06:58:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24520
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 06:58:40 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avbu-0004bO-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 06:58:42 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19avbt-0004bL-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 06:58:41 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6BAwea07876
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 13:58:40 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T635e10bedeac158f21084@esvir01nok.ntc.nokia.com>;
 Fri, 11 Jul 2003 13:58:38 +0300
Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 11 Jul 2003 13:58:40 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 11 Jul 2003 13:58:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] CTP - Context Data block Length
Date: Fri, 11 Jul 2003 13:58:38 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F12A@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] CTP - Context Data block Length
Thread-Index: AcNG80leNsrusyqyQyKZCsPyKrswzgAqBWRw
To: <Julien.Bournelle@int-evry.fr>, <seamoby@ietf.org>
X-OriginalArrivalTime: 11 Jul 2003 10:58:39.0247 (UTC) FILETIME=[626009F0:01C3479B]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Assigned issue 28.

> -----Original Message-----
> From: ext Julien Bournelle [mailto:Julien.Bournelle@int-evry.fr]
> Sent: 10 July, 2003 17:54
> To: seamoby@ietf.org
> Subject: [Seamoby] CTP - Context Data block Length
>=20
>=20
> Hi all,
>=20
>  The Context Data Block header doesn't have a length field.=20
> As such, I don't see how the implementation can point to the=20
> next block.
>=20
> Do I miss something ?
>=20
> bye,
>=20
> --=20
> julien.bournelle@int-evry.fr
>=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  Fri Jul 11 08:09: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 IAA26740
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 08:09:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19awi3-0004C0-Fs
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 08:09:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BC97hf016116
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 08:09:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19awi3-0004Br-8p
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 08:09: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 IAA26734
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 08:09:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19awi2-0005Ad-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 08:09:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19awi1-0005Aa-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 08:09:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19awhy-0004B7-0K; Fri, 11 Jul 2003 08:09:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19awhg-0004Ao-0L
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 08:08:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26726
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 08:08:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19awhe-0005AV-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 08:08:43 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19awhd-0005A8-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 08:08:42 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6BC86VI097058
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 14:08:06 +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 7D8E95837A
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 13:50:08 +0200 (CEST)
Message-ID: <3F0EA8A9.5060308@ccrle.nec.de>
Date: Fri, 11 Jul 2003 14:08:09 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD issue#4 - CARD protocol piggybacking / Henrik's comment
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Henrik and all,

I am incorporating your comments into the issue list. I have an immediate
feedback on your comment related to issue#4.

You indicated the following:
"In appendix B.2, there is a note that it may not be
necessary to use FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD
messages are exchanged, since the CARD messages convey all
the necessary information. This seems to make the
piggybacking of CARD on top of the PrRt messages irrevelant.
Is there some reason to do it, which is just missing from
the text? If not, this section should be removed and the messages
should be carried on top of UDP as in AR-AR case."

[marco]: From the current protocol operation of FMIPv6, this might be true.
But since the FMIPv6 protocol design has not been finalized, this
has been added into the CARD draft as a note. Too keep it flexible
and to be prepared for changes in FMIPv6 protocol spec, we took
"appending" CARD messages to FMIPv6 messages into account,
not "replacing" them.
 
What do you think?

marco
 



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 11 08:29: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 IAA27223
	for <seamoby-archive@odin.ietf.org>; Fri, 11 Jul 2003 08:29:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ax1R-0005aQ-FA
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 08:29:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BCT9Lf021468
	for seamoby-archive@odin.ietf.org; Fri, 11 Jul 2003 08:29:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ax1R-0005a6-7I
	for seamoby-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 08:29: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 IAA27215
	for <seamoby-web-archive@ietf.org>; Fri, 11 Jul 2003 08:29:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ax1P-0005HM-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 08:29:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ax1P-0005HJ-00
	for seamoby-web-archive@ietf.org; Fri, 11 Jul 2003 08:29:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ax1J-0005ZA-E1; Fri, 11 Jul 2003 08:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ax0q-0005Yr-If
	for seamoby@optimus.ietf.org; Fri, 11 Jul 2003 08:28: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 IAA27210
	for <seamoby@ietf.org>; Fri, 11 Jul 2003 08:28:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ax0p-0005HB-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 08:28:31 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ax0o-0005Gp-00
	for seamoby@ietf.org; Fri, 11 Jul 2003 08:28:30 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6BCRkVI099210;
	Fri, 11 Jul 2003 14:27:52 +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 8055F7A06C; Fri, 11 Jul 2003 14:09:48 +0200 (CEST)
Message-ID: <3F0EAD45.9040903@ccrle.nec.de>
Date: Fri, 11 Jul 2003 14:27:49 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] CARD review from Henrick Petander
References: <021501c346d1$166a72d0$636015ac@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Henrik,

thanks for the review and the valuable comments on technical as well as on
some important editorial issues.

marco
 

James Kempf wrote:

>Hello all,
>
>Jak and Pat asked me to review the CARD protocol draft based on my
>experience in implementing MIPv6. I hope this review will
>help in improving the I-D.
>
>Regards,
>
>Henrik Petander
>
>--------------------------------------------------------------------
>  
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sun Jul 13 08:17: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 IAA15881
	for <seamoby-archive@odin.ietf.org>; Sun, 13 Jul 2003 08:17:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bfmt-0004yL-Hv
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 08:17:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DCH72c019109
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 08:17:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bfmt-0004y8-Es
	for seamoby-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 08:17: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 IAA15857
	for <seamoby-web-archive@ietf.org>; Sun, 13 Jul 2003 08:17:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19bfms-00037T-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 08:17:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19bfmr-00037P-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 08:17:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bfmo-0004xl-23; Sun, 13 Jul 2003 08:17:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19aXYZ-0005sa-RC
	for seamoby@optimus.ietf.org; Thu, 10 Jul 2003 05:17: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 FAA23429
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 05:17:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXYW-0000oj-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 05:17:36 -0400
Received: from smtp-2.hut.fi ([130.233.228.92] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 19aXYV-0000og-00
	for seamoby@ietf.org; Thu, 10 Jul 2003 05:17:35 -0400
Received: from tml.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132])
	by smtp-2.hut.fi (8.12.9/8.12.9) with ESMTP id h6A9HXiP012127
	for <seamoby@ietf.org>; Thu, 10 Jul 2003 12:17:33 +0300
Message-ID: <3F0D315E.7010006@tml.hut.fi>
Date: Thu, 10 Jul 2003 12:26:54 +0300
From: Henrik Petander <lpetande@tml.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: seamoby@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi)
X-DCC-HUTCC-Metrics: smtp-2.hut.fi 1165; Body=1 Fuz1=1 Fuz2=1
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello all,

Jak and Pat asked me to review the CARD protocol draft based on my
experience in implementing MIPv6. I hope this review will
help in improving the I-D.

Regards,

Henrik Petander

--------------------------------------------------------------------

Comments on the protocol
========================

Choice of transport
-------------------

MN-AR and AR-AR protocols are in the draft carried over ICMP and UDP.
The reason for the separate transports seems to be the piggybacking
defined in section 4.5. However, piggybacking appears does not appear to
be necessary (see comments on section 4.5 for details).  Without
piggybacking it would be simpler to run both MN-AR and AR-AR protocols
over UDP and use the same message formats.


Removal of per-session state from ARs
-------------------------------------

The responsiblity for resends for MN initiated sessions is both in
the MN and the current AR. Since the weakest link in the protocol from a
reliability POV is probably the air interface, the AR-AR resending in
the MN initiated sessions is probably not worth the extra complexity.

Removing it would simplify AR a lot, since it would not need to maintain
any state for CARD in addition to the CAR table. An AR without 
per-session state would be less vulnerable to DoS attacks and would also
scale better.

(The preferences and requirements should then be appended also to the
current AR - CAR messages, if the current AR lacks knowledge of the
capabilities of CARs.)

4. CARD PROTOCOL OPERATION
--------------------------

Is there a specific reason to use the rate limiting flag instead of
normal ICMP rate limiting ?

Anyways, the rate limiting mechanism, which MN uses after getting a
reply with R-bit set, should be defined. There exist a number of
already defined mechanisms for dealing with resending intervals and
rate limiting. Why not use one of them?



4.1 Data structures
-------------------

Should there be a recommendation for MN to cache the information about
CARs ?  MN needs a CAR table with cached answers from CARD
replies to avoid asking the same information repeatedly, and for being
able to react to movement as quickly as possible.


4.2.2 Current access router operation
-------------------------------------

If you use IPSec ESP for protecting CARD between MN and AR, you cannot
send multicast CARD replies. IPSec security associations are between
two hosts.

You need to protect the CARD replies in some other way (for example
with signatures as proposed in the CARD problem statement draft), or
always send them as unicast packets.

4.3.1 Current access router operation
-------------------------------------

Is it necessary to include the capabilities of current AR in
AR-AR CARD request message?

If the data in a current AR for a CAR is not up to date, it still does
not mean that the data for the current AR is not up to date in the
CAR. Including the AR-AR CARD reply automatically in the CARD request
creates unnecessary load in both routers when they authenticate /
encrypt extra data.

This optimization also adds extra complexity to the protocol, and it is
not clear to me whether it is worth it.

4.4. CARD Signaling Failure Recovery
------------------------------------

The draft does not define what an AR sends to MN, when it cannot
resolve a L2 address into an IP address. This should be specified
clearly.

4.4.2 AR-AR signaling failure
-----------------------------

What does the CAR send to current AR, if it does not have an interface
/ AP attached to it with the queried L2 id? This should be
defined.

4.5 Piggybacking
----------------

In appendix B.2, there is a note that it may not be necessary to use
FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
since the CARD messages convey all the necessary information. This
seems to make the piggybacking of CARD on top of the PrRt messages
irrevelant. Is there some reason to do it, which is just missing from
the text?

If not, this section should be removed and the messages should be
carried on top of UDP as in AR-AR case.


4.6 CARD protocol security
---------------------------

You should move everything about IPSec ESP here and indicate clearly
how it should be used. Now the text about its use is scattered around
section 4. Perhaps the security section should be renamed "Protection
of CARD messages" to make a clear distinction between the
implementation of the protection versus the analysis in section 6.

The section should say that 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. Definition of the SPD entries
would also be nice.

5. Protocol messages
--------------------

Is 8 bits enough for the CARD option length field? This translates to
255 octets, which seems limiting to me, especially since the
capabilities have not been defined. Also the AVP encoding rules in
5.1.4 have a 16-bit length field, which conlicts with the fact that
they still need to fit within the options with 8-bit length fields.

AR - AR message format in 5.2.2 includes a length field which is
redundant with UDP's length field and should be removed.

7. Protocol constants
----------------------

Where are their values defined?


Editorial comments
==================

General
--------

The term SHALL was used in the section 4 for use of IPSec
ESP. However, in sections 5 and 6 the word SHOULD was used
instead. The use of "SHALL" was new to me so I checked its meaning
from RFC 2119. According to the RFC its use is: "MUST   This word, or
the terms "REQUIRED" or "SHALL", mean that the definition is an
absolute requirement of the specification."

This should be fixed.  If capabilities such as pricing information are
transferred between ARs and MNs, I would opt for use of SHALL/MUST for
the authentication requirement. Also the card requirements draft uses
the word MUST for authentication and SHOULD for encryption.

4.3.2 Candidate Access Router Operation
---------------------------------------

Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
optionally encryption of the AR-AR CARD Reply message."

Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
do not provide integrity protection and should not be used without
an authentication & integrity protection algorithm.

4.4.1 MN-AR Signaling Failure
-----------------------------

"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
  CARD Request message with the given sequence number."

Shouldn't it be the MN, which starts the timer instead of AR?


5.1.1 CARD Main Header Format
-----------------------------

"Encapsulating Security Payload (ESP) Header:
	The sender SHOULD include the Encapsulating
	Security Payload (ESP) Header, based on the
         previously established Security Association
         between the sender and the receiver."

Shouldn't this SHOULD be MUST intead?

5.2.1 Protocol Transport
------------------------

"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
    be used [10]."

Again, SHOULD vs. MUST/SHALL.

6.1 Assumptions
---------------
Second paragraph, last sentence:

"The appendices of this draft describe procedures for discovering the
identities of the geographically ARs and APs and relevant security
considerations."

There seems to be a word missing after "geographically". Adjacent?

6.2 Security Association between AR and AR
-------------------------------------------

"To prevent the information from being compromised, the CARD REPLY
  messages between ARs SHOULD be authenticated. The messages also MAY
  be encrypted for privacy of the information."

Again SHOULD vs. MUST/SHALL.

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 SHOULD authenticate the CARD REPLY
messages from the AR."

Again SHOULD vs. MUST/SHALL.

6.4 DoS Attack
--------------

Should it be mentioned here that authenticating CARD requests is
needed to allow ARs to protect themselves against CARD request
flooding with spoofed addresses?

(Authenticating the requests makes DoS less likely as the attacker's
identity is revealed and her account can be disabled, etc.)

The meaning of the second paragraph is not clear to me. How can an
attacker masquerade as an AR, if all entities in the protocol are
authenticated? It seems to me that this would be possible only if an
AR is compromised. Should the protocol be secure also against
compromised routers?  This should be specified in the assumptions
section.


Appendix A.
----------

The appendixes form quite a large part of the draft. A.1 and A.2
should be either integrated into the main draft as optional parts or
be separated into their own drafts.

A.1.4.1 Security Associations

More details are needed on how IPSec ESP is used.

A.2

What does pAR send to current AR to verify that it had or did not have
state for MN?


A.2.4

"should" vs MUST be protected with IPSec ESP.

Appendix B.
----------

B.1 should be removed, since it is not needed for implementation of the
protocol. The draft is self explanatory enough to be used with
IEEE 802.11 WLANs without this appendix.

B.2 raises the question, whether there is a need for an "architecture"
draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
be used together.



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sun Jul 13 14:21: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 OAA01676
	for <seamoby-archive@odin.ietf.org>; Sun, 13 Jul 2003 14:21: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 19blT6-0007qf-Vp
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 14:21:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DIL4ie030163
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 14:21:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19blT6-0007qQ-Qj
	for seamoby-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 14:21: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 OAA01669
	for <seamoby-web-archive@ietf.org>; Sun, 13 Jul 2003 14:21:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19blT4-0006dP-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 14:21:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19blT3-0006dM-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 14:21:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19blT4-0007pj-46; Sun, 13 Jul 2003 14:21:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19blSD-0007os-As
	for seamoby@optimus.ietf.org; Sun, 13 Jul 2003 14: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 OAA01664
	for <seamoby@ietf.org>; Sun, 13 Jul 2003 14:20:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19blSA-0006dI-00
	for seamoby@ietf.org; Sun, 13 Jul 2003 14:20:06 -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 19blSA-0006dF-00
	for seamoby@ietf.org; Sun, 13 Jul 2003 14:20:06 -0400
Message-ID: <020601c3496b$69701fb0$7f6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Sun, 13 Jul 2003 20:20:10 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] ITEF 57 Agenda
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Here's the agenda. It's also posted on the IETF 57 Web page.

            jak

----------------------
Context Transfer, Handoff Candidate Discovery, 
and Dormant Mode Host Alerting WG (seamoby)

Thursday, July 17 at 1530-1730
===============================

CHAIRS:	Pat R. Calhoun <pcalhoun@airespace.com> 
	James Kempf <kempf@docomolabs-usa.com> 

AGENDA:

Intro and Agenda Bashing (5 min) - chairs

Draft Status (5 min) - chairs
    draft-ietf-seamoby-mobility-terminology-04.txt
    draft-ietf-seamoby-card-protocol-01.txt
    draft-ietf-seamoby-ctp-02.txt
    <other drafts>

Issues with CTP (30 min) - John Loughney

Issues with CAR (30 min) - Marco Liebsch and Ajoy Sing

ROHC Header Compression CT draft (20 min) - Manish Tiwari
    draft-koodli-seamoby-hc-relocate-02.txt

Next Steps (10 min) - chairs




_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sun Jul 13 18:18: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 SAA08024
	for <seamoby-archive@odin.ietf.org>; Sun, 13 Jul 2003 18:18: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 19bpAT-0006E9-Dm
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 18:18:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DMI57k023933
	for seamoby-archive@odin.ietf.org; Sun, 13 Jul 2003 18:18:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bpAT-0006Dw-AY
	for seamoby-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 18:18: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 SAA07996
	for <seamoby-web-archive@ietf.org>; Sun, 13 Jul 2003 18:18:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19bpAQ-0007aQ-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 18:18:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19bpAP-0007aN-00
	for seamoby-web-archive@ietf.org; Sun, 13 Jul 2003 18:18:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bpAO-0006DG-Mw; Sun, 13 Jul 2003 18:18:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19bp9o-0006Cv-FZ
	for seamoby@optimus.ietf.org; Sun, 13 Jul 2003 18:17:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07927
	for <seamoby@ietf.org>; Sun, 13 Jul 2003 18:17:19 -0400 (EDT)
From: Basavaraj.Patil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19bp9l-0007aH-00
	for seamoby@ietf.org; Sun, 13 Jul 2003 18:17:21 -0400
Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19bp9k-0007aE-00
	for seamoby@ietf.org; Sun, 13 Jul 2003 18:17:20 -0400
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6DMHHG11394
	for <seamoby@ietf.org>; Sun, 13 Jul 2003 17:17:17 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T636913a7cbac12f257cf0@davir04nok.americas.nokia.com>;
 Sun, 13 Jul 2003 17:17:38 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Sun, 13 Jul 2003 15:16:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 13 Jul 2003 17:16:15 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB404@daebe007.americas.nokia.com>
Thread-Topic: Bar BoF announcement for IRTF WG l3m
Thread-Index: AcNABHC9TYYvFDPvRDe2eNnybQR/uAJh8cnw
To: <mobile-ip@sunroof.eng.sun.com>, <seamoby@ietf.org>
Cc: <vern@icir.org>
X-OriginalArrivalTime: 13 Jul 2003 22:16:15.0743 (UTC) FILETIME=[605C80F0:01C3498C]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] RE: [mobile-ip] Bar BoF announcement for IRTF WG l3m - Meeting location
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


We will meet at the IETF registration desk tomorrow (July 14th)
at 10 PM and find either a meeting room or a bar for the bar-bof.

-Basavaraj

>=20
> Hello,
>=20
> At the previous NSIIM BoF we also discussed the idea of starting an
> IRTF WG dealing with IP mobility (specifically the Mobile IP protocol
> variety). The intent is to develop a set of tools that can be used for
> measuring the performance of the various types of optimization
> proposals for Mobile IP protocols. In addition the WG would develop
> simulation models that can be used to better understand the
> performance gains of schemes such as Fast HO, Hierarchical mobility
> and implications of schemes for optimizing address assignment,
> frequency of router advertisements etc.=20
>=20
> We would like to have a Bar BoF at IETF57 to discuss the interest and
> details of this work further. The proposal is as follows:
> What: IP Mobility work in IRTF Bar BoF
> When: Monday at 10 PM
> Where: Its a bar Bof :) (TBA)
>=20
> Further details about the BoF will be sent to the Mobile IP and
> Seamoby lists.=20
>=20
> -Chairs
>=20
> --------------------------------------------
>=20
> The current charter is as follows:
>=20
> Name of WG : l3m=20
>=20
>         The "Layer 3 Mobility" (l3m) RG is an open IRTF=20
> group.  It studies
>         performance and architectural tradeoffs of optimizations and
>         evolutionary changes to IP mobility. Even though the focus
>         is on layer 3 mobility, knowledge of lower layers may be used
>         if appropriate.
>=20
>         The L3M RG addresses questions of an evolutionary nature.
>         In particular, radically new architectures (e.g., based on the
>         separation of identity and location) are outside the scope.
>=20
>         The objective of the group is to enable the formation of a
>         research community around the topic of internet=20
> Mobility similar
>         to the TCP research community. That is, the objective=20
> is not only
>         to carry out and publish results of analysis and simulations
>         of different proposals, but to do so in such a fashion that
>         allows a more direct comparison ("apples to apples") than is
>         now possible. In order to accomplish this, the L3M group will
>         strive to arrive at some common scenarios, parameters, tools
>         and methodologies.
>=20
> 	The research group will also examine algorithms for automatic
> 	configuration of access routers with information of use to
> 	Mobile Nodes during fast handover.
>=20
> 	The Seamoby Working group is developing an Experimental
> 	protocol to distribute such information between routers and
> 	between the router and Mobile Node (Candidate Access Router
> 	Discovery, CARD),  but the actual algorithms for determining
> 	whether a particular access point, seen by a Mobile Node and
> 	reported to the access router, is within range of a handover
> 	from the router is not in scope. Neither is determining whether
> 	a particular access point is authorized to provide service and
> 	therefore a candidate for handover. These topics will be
> 	material for the research group. The goal of the research is to
> 	characterize the currently proposed approaches (learning based
> 	or server based) and any other approaches, and determine under
> 	which conditions a particular algorithm is a superior solution.
> 	These results will be returned to the IETF if and when
> 	standardization of CARD is requested.
>=20
>=20
>=20
>=20
>=20
>=20

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 14 13:31: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 NAA07128
	for <seamoby-archive@odin.ietf.org>; Mon, 14 Jul 2003 13:31: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 19c7AH-0003Qe-On
	for seamoby-archive@odin.ietf.org; Mon, 14 Jul 2003 13:31:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHV5LI013176
	for seamoby-archive@odin.ietf.org; Mon, 14 Jul 2003 13:31:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19c7AH-0003QR-LX
	for seamoby-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:31: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 NAA07083
	for <seamoby-web-archive@ietf.org>; Mon, 14 Jul 2003 13:31:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19c7AF-0003fD-00
	for seamoby-web-archive@ietf.org; Mon, 14 Jul 2003 13:31:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19c7AE-0003f9-00
	for seamoby-web-archive@ietf.org; Mon, 14 Jul 2003 13:31:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19c7AC-0003PW-RF; Mon, 14 Jul 2003 13:31:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19c79e-0003Om-5h
	for seamoby@optimus.ietf.org; Mon, 14 Jul 2003 13:30: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 NAA07012
	for <seamoby@ietf.org>; Mon, 14 Jul 2003 13:30:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19c79c-0003e1-00
	for seamoby@ietf.org; Mon, 14 Jul 2003 13:30:24 -0400
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx with esmtp (Exim 4.12)
	id 19c79a-0003dy-00
	for seamoby@ietf.org; Mon, 14 Jul 2003 13:30:23 -0400
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6EHULgq007139
	for <seamoby@ietf.org>; Mon, 14 Jul 2003 10:30:22 -0700 (MST)
Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2])
	by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h6EHUKDp019345
	for <seamoby@ietf.org>; Mon, 14 Jul 2003 12:30:20 -0500
Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <3X86YKZP>; Mon, 14 Jul 2003 12:30:20 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A22A@IL27EXM10.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'Henrik Petander'" <lpetande@tml.hut.fi>, seamoby@ietf.org
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Mon, 14 Jul 2003 12:30:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hello Henrik,
Thanks for your review comments. I would like to 
reply to one of your questions/comments. Please 
see my inline reply. 
regards,
ajoy 

4.3.1 Current access router operation
-------------------------------------

Is it necessary to include the capabilities of current AR in
AR-AR CARD request message?

AJOY-> Yes. it helps please see my reply below. 

If the data in a current AR for a CAR is not up to date, it still does
not mean that the data for the current AR is not up to date in the
CAR. 

AJOY-> I agree. 

Including the AR-AR CARD reply automatically in the CARD request
creates unnecessary load in both routers when they authenticate /
encrypt extra data.

AJOY-> Well, it helps to reduce the number of messages processed 
by CAR in the long run. Processing extra new messages may be 
more expensive than adding some additional processing overhead in 
the existing messages.  

This optimization also adds extra complexity to the protocol, and it is
not clear to me whether it is worth it.

AJOY-> I am not clear how it will complicate the implementation of CARD protocol. 


 





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 14 14:57: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 OAA14584
	for <seamoby-archive@odin.ietf.org>; Mon, 14 Jul 2003 14:57: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 19c8VW-0002Hh-EY
	for seamoby-archive@odin.ietf.org; Mon, 14 Jul 2003 14:57:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIv6iK008777
	for seamoby-archive@odin.ietf.org; Mon, 14 Jul 2003 14:57:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19c8VV-0002GH-QO
	for seamoby-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:57:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14510
	for <seamoby-web-archive@ietf.org>; Mon, 14 Jul 2003 14:57:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19c8VS-0005X0-00
	for seamoby-web-archive@ietf.org; Mon, 14 Jul 2003 14:57:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19c8VS-0005Wx-00
	for seamoby-web-archive@ietf.org; Mon, 14 Jul 2003 14:57:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19c8VR-0002Ea-Dt; Mon, 14 Jul 2003 14: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 19c8Us-0002Dl-VZ
	for seamoby@optimus.ietf.org; Mon, 14 Jul 2003 14:56:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14453
	for <seamoby@ietf.org>; Mon, 14 Jul 2003 14:56:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19c8Uq-0005Vb-00
	for seamoby@ietf.org; Mon, 14 Jul 2003 14:56:24 -0400
Received: from bay2-f94.bay2.hotmail.com ([65.54.247.94] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19c8Up-0005Uo-00
	for seamoby@ietf.org; Mon, 14 Jul 2003 14:56:23 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jul 2003 11:55:51 -0700
Received: from 63.78.179.4 by by2fd.bay2.hotmail.msn.com with HTTP;
	Mon, 14 Jul 2003 18:55:50 GMT
X-Originating-IP: [63.78.179.4]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: lpetande@tml.hut.fi, seamoby@ietf.org
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Mon, 14 Jul 2003 18:55:50 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F941fDc5DYge2Q0000aafd@hotmail.com>
X-OriginalArrivalTime: 14 Jul 2003 18:55:51.0801 (UTC) FILETIME=[8BF24E90:01C34A39]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi Henrik,

Clarification on your comment on per-session state: It is not clear to us 
why AR-AR resending requires any additional MN-specific state in AR. For 
AR-AR interface, in each AR there would be one outgoing queue of queries and 
one incoming queue of replies. Replies will be matched to requests and 
retransmissions will be done if needed. An implementation specific window 
(>= 1) could be defined for this similar to ARQ. Do you agree with this or 
we are missing something from your comment.

Hemant


>
>Removal of per-session state from ARs
>-------------------------------------
>
>The responsiblity for resends for MN initiated sessions is both in
>the MN and the current AR. Since the weakest link in the protocol from a
>reliability POV is probably the air interface, the AR-AR resending in
>the MN initiated sessions is probably not worth the extra complexity.
>
>Removing it would simplify AR a lot, since it would not need to maintain
>any state for CARD in addition to the CAR table. An AR without per-session 
>state would be less vulnerable to DoS attacks and would also
>scale better.
>
>(The preferences and requirements should then be appended also to the
>current AR - CAR messages, if the current AR lacks knowledge of the
>capabilities of CARs.)
>
>4. CARD PROTOCOL OPERATION
>--------------------------
>
>Is there a specific reason to use the rate limiting flag instead of
>normal ICMP rate limiting ?
>
>Anyways, the rate limiting mechanism, which MN uses after getting a
>reply with R-bit set, should be defined. There exist a number of
>already defined mechanisms for dealing with resending intervals and
>rate limiting. Why not use one of them?
>
>
>
>4.1 Data structures
>-------------------
>
>Should there be a recommendation for MN to cache the information about
>CARs ?  MN needs a CAR table with cached answers from CARD
>replies to avoid asking the same information repeatedly, and for being
>able to react to movement as quickly as possible.
>
>
>4.2.2 Current access router operation
>-------------------------------------
>
>If you use IPSec ESP for protecting CARD between MN and AR, you cannot
>send multicast CARD replies. IPSec security associations are between
>two hosts.
>
>You need to protect the CARD replies in some other way (for example
>with signatures as proposed in the CARD problem statement draft), or
>always send them as unicast packets.
>
>4.3.1 Current access router operation
>-------------------------------------
>
>Is it necessary to include the capabilities of current AR in
>AR-AR CARD request message?
>
>If the data in a current AR for a CAR is not up to date, it still does
>not mean that the data for the current AR is not up to date in the
>CAR. Including the AR-AR CARD reply automatically in the CARD request
>creates unnecessary load in both routers when they authenticate /
>encrypt extra data.
>
>This optimization also adds extra complexity to the protocol, and it is
>not clear to me whether it is worth it.
>
>4.4. CARD Signaling Failure Recovery
>------------------------------------
>
>The draft does not define what an AR sends to MN, when it cannot
>resolve a L2 address into an IP address. This should be specified
>clearly.
>
>4.4.2 AR-AR signaling failure
>-----------------------------
>
>What does the CAR send to current AR, if it does not have an interface
>/ AP attached to it with the queried L2 id? This should be
>defined.
>
>4.5 Piggybacking
>----------------
>
>In appendix B.2, there is a note that it may not be necessary to use
>FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
>since the CARD messages convey all the necessary information. This
>seems to make the piggybacking of CARD on top of the PrRt messages
>irrevelant. Is there some reason to do it, which is just missing from
>the text?
>
>If not, this section should be removed and the messages should be
>carried on top of UDP as in AR-AR case.
>
>
>4.6 CARD protocol security
>---------------------------
>
>You should move everything about IPSec ESP here and indicate clearly
>how it should be used. Now the text about its use is scattered around
>section 4. Perhaps the security section should be renamed "Protection
>of CARD messages" to make a clear distinction between the
>implementation of the protection versus the analysis in section 6.
>
>The section should say that 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. Definition of the SPD entries
>would also be nice.
>
>5. Protocol messages
>--------------------
>
>Is 8 bits enough for the CARD option length field? This translates to
>255 octets, which seems limiting to me, especially since the
>capabilities have not been defined. Also the AVP encoding rules in
>5.1.4 have a 16-bit length field, which conlicts with the fact that
>they still need to fit within the options with 8-bit length fields.
>
>AR - AR message format in 5.2.2 includes a length field which is
>redundant with UDP's length field and should be removed.
>
>7. Protocol constants
>----------------------
>
>Where are their values defined?
>
>
>Editorial comments
>==================
>
>General
>--------
>
>The term SHALL was used in the section 4 for use of IPSec
>ESP. However, in sections 5 and 6 the word SHOULD was used
>instead. The use of "SHALL" was new to me so I checked its meaning
>from RFC 2119. According to the RFC its use is: "MUST   This word, or
>the terms "REQUIRED" or "SHALL", mean that the definition is an
>absolute requirement of the specification."
>
>This should be fixed.  If capabilities such as pricing information are
>transferred between ARs and MNs, I would opt for use of SHALL/MUST for
>the authentication requirement. Also the card requirements draft uses
>the word MUST for authentication and SHOULD for encryption.
>
>4.3.2 Candidate Access Router Operation
>---------------------------------------
>
>Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
>optionally encryption of the AR-AR CARD Reply message."
>
>Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
>do not provide integrity protection and should not be used without
>an authentication & integrity protection algorithm.
>
>4.4.1 MN-AR Signaling Failure
>-----------------------------
>
>"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
>  CARD Request message with the given sequence number."
>
>Shouldn't it be the MN, which starts the timer instead of AR?
>
>
>5.1.1 CARD Main Header Format
>-----------------------------
>
>"Encapsulating Security Payload (ESP) Header:
>	The sender SHOULD include the Encapsulating
>	Security Payload (ESP) Header, based on the
>         previously established Security Association
>         between the sender and the receiver."
>
>Shouldn't this SHOULD be MUST intead?
>
>5.2.1 Protocol Transport
>------------------------
>
>"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
>    be used [10]."
>
>Again, SHOULD vs. MUST/SHALL.
>
>6.1 Assumptions
>---------------
>Second paragraph, last sentence:
>
>"The appendices of this draft describe procedures for discovering the
>identities of the geographically ARs and APs and relevant security
>considerations."
>
>There seems to be a word missing after "geographically". Adjacent?
>
>6.2 Security Association between AR and AR
>-------------------------------------------
>
>"To prevent the information from being compromised, the CARD REPLY
>  messages between ARs SHOULD be authenticated. The messages also MAY
>  be encrypted for privacy of the information."
>
>Again SHOULD vs. MUST/SHALL.
>
>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 SHOULD authenticate the CARD REPLY
>messages from the AR."
>
>Again SHOULD vs. MUST/SHALL.
>
>6.4 DoS Attack
>--------------
>
>Should it be mentioned here that authenticating CARD requests is
>needed to allow ARs to protect themselves against CARD request
>flooding with spoofed addresses?
>
>(Authenticating the requests makes DoS less likely as the attacker's
>identity is revealed and her account can be disabled, etc.)
>
>The meaning of the second paragraph is not clear to me. How can an
>attacker masquerade as an AR, if all entities in the protocol are
>authenticated? It seems to me that this would be possible only if an
>AR is compromised. Should the protocol be secure also against
>compromised routers?  This should be specified in the assumptions
>section.
>
>
>Appendix A.
>----------
>
>The appendixes form quite a large part of the draft. A.1 and A.2
>should be either integrated into the main draft as optional parts or
>be separated into their own drafts.
>
>A.1.4.1 Security Associations
>
>More details are needed on how IPSec ESP is used.
>
>A.2
>
>What does pAR send to current AR to verify that it had or did not have
>state for MN?
>
>
>A.2.4
>
>"should" vs MUST be protected with IPSec ESP.
>
>Appendix B.
>----------
>
>B.1 should be removed, since it is not needed for implementation of the
>protocol. The draft is self explanatory enough to be used with
>IEEE 802.11 WLANs without this appendix.
>
>B.2 raises the question, whether there is a need for an "architecture"
>draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
>be used together.
>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul 15 14:14: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 OAA28356
	for <seamoby-archive@odin.ietf.org>; Tue, 15 Jul 2003 14:14:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cUJc-0002zi-6l
	for seamoby-archive@odin.ietf.org; Tue, 15 Jul 2003 14:14:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FIEGbi011506
	for seamoby-archive@odin.ietf.org; Tue, 15 Jul 2003 14:14:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cUJc-0002zV-1m
	for seamoby-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 14:14: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 OAA28348
	for <seamoby-web-archive@ietf.org>; Tue, 15 Jul 2003 14:14:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cUJY-0004Ik-00
	for seamoby-web-archive@ietf.org; Tue, 15 Jul 2003 14:14:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cUJS-0004Gf-00
	for seamoby-web-archive@ietf.org; Tue, 15 Jul 2003 14:14:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cUJN-0002yq-Ad; Tue, 15 Jul 2003 14:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cUIU-0002yX-8n
	for seamoby@optimus.ietf.org; Tue, 15 Jul 2003 14:13: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 OAA28338
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 14:13:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cUIR-0004Ga-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 14:13:03 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cUIG-0004GT-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 14:12:53 -0400
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h6FICJKf025052
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 11:12:19 -0700 (MST)
Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6FIC6H1023385
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 13:12:07 -0500
Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <3RHHZH8M>; Tue, 15 Jul 2003 13:12:18 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A234@IL27EXM10.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'Henrik Petander'" <lpetande@morphine.tml.hut.fi>,
        Singh Ajoy-ASINGH1
	 <ASINGH1@motorola.com>
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Tue, 15 Jul 2003 13:12:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>



-----Original Message-----
From: Henrik Petander [mailto:lpetande@morphine.tml.hut.fi]
Sent: Tuesday, July 15, 2003 5:36 AM
To: Singh Ajoy-ASINGH1
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt


Hello Ajoy,

On Mon, 14 Jul 2003, Singh Ajoy-ASINGH1 wrote:
>
> AJOY-> Well, it helps to reduce the number of messages processed
> by CAR in the long run. Processing extra new messages may be
> more expensive than adding some additional processing overhead in
> the existing messages.
>
> This optimization also adds extra complexity to the protocol, and it is
> not clear to me whether it is worth it.
>
> AJOY-> I am not clear how it will complicate the implementation of CARD
protocol.

Not much, but it still changes the simple request-reply nature to optimize
the protocol. I am not sure whether this optimization is generally useful.
The usefulness depends on the amount of MNs, MN mobility patterns and the
lifetimes of the capabilities. I agree that in some situations this could
reduce the load on the ARs, so I am fine with the MAY for this.

AJOY-> Ok, we will make this a MAY. 

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul 16 07:27: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 HAA25888
	for <seamoby-archive@odin.ietf.org>; Wed, 16 Jul 2003 07:27:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckRE-0003RZ-Lo
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 07:27:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBRCfu013220
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 07:27:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckRE-0003Qz-Fq
	for seamoby-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:27: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 HAA25849
	for <seamoby-web-archive@ietf.org>; Wed, 16 Jul 2003 07:27:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ckRD-00064K-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 07:27:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ckR7-00064G-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 07:27:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckR4-0003Or-Ip; Wed, 16 Jul 2003 07: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 19cNBd-0006MG-PD
	for seamoby@optimus.ietf.org; Tue, 15 Jul 2003 06:37: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 GAA13296
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 06:37:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cNBU-0000Uu-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 06:37:24 -0400
Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cNB4-0000Uh-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 06:36:59 -0400
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA25714
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 13:36:39 +0300
X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to <lpetande@morphine.tml.hut.fi> using -f
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma025710; Tue, 15 Jul 03 13:36:19 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (Postfix) with ESMTP
	id 9385D18C20F; Tue, 15 Jul 2003 13:36:19 +0300 (EEST)
Received: from tml.hut.fi (localhost [127.0.0.1])
	by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h6FAaJF5011631;
	Tue, 15 Jul 2003 13:36:19 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h6FAaFxk011628;
	Tue, 15 Jul 2003 13:36:19 +0300 (EEST)
Date: Tue, 15 Jul 2003 13:36:15 +0300 (EEST)
From: Henrik Petander <lpetande@morphine.tml.hut.fi>
To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B1221A22A@IL27EXM10.cig.mot.com>
Message-ID: <Pine.GSO.4.44.0307151317360.11439-100000@morphine.tml.hut.fi>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hello Ajoy,

On Mon, 14 Jul 2003, Singh Ajoy-ASINGH1 wrote:
>
> AJOY-> Well, it helps to reduce the number of messages processed
> by CAR in the long run. Processing extra new messages may be
> more expensive than adding some additional processing overhead in
> the existing messages.
>
> This optimization also adds extra complexity to the protocol, and it is
> not clear to me whether it is worth it.
>
> AJOY-> I am not clear how it will complicate the implementation of CARD protocol.

Not much, but it still changes the simple request-reply nature to optimize
the protocol. I am not sure whether this optimization is generally useful.
The usefulness depends on the amount of MNs, MN mobility patterns and the
lifetimes of the capabilities. I agree that in some situations this could
reduce the load on the ARs, so I am fine with the MAY for this.

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul 16 07:27: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 HAA25900
	for <seamoby-archive@odin.ietf.org>; Wed, 16 Jul 2003 07:27:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckRF-0003Ru-B1
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 07:27:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBRDr2013253
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 07:27:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckRE-0003R0-Gi
	for seamoby-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:27: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 HAA25851
	for <seamoby-web-archive@ietf.org>; Wed, 16 Jul 2003 07:27:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ckRD-00064N-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 07:27:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ckR7-00064H-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 07:27:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ckR4-0003OR-4Z; Wed, 16 Jul 2003 07: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 19cMsO-00057c-13
	for seamoby@optimus.ietf.org; Tue, 15 Jul 2003 06:17: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 GAA12459
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 06:17:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cMsF-0000M7-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 06:17:31 -0400
Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cMrp-0000Le-00
	for seamoby@ietf.org; Tue, 15 Jul 2003 06:17:05 -0400
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA25108
	for <seamoby@ietf.org>; Tue, 15 Jul 2003 13:16:31 +0300
X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to <lpetande@morphine.tml.hut.fi> using -f
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma025100; Tue, 15 Jul 03 13:16:26 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (Postfix) with ESMTP
	id 7B2E918C1D8; Tue, 15 Jul 2003 13:16:17 +0300 (EEST)
Received: from tml.hut.fi (localhost [127.0.0.1])
	by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h6FAGHF5011581;
	Tue, 15 Jul 2003 13:16:17 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h6FAGHAr011578;
	Tue, 15 Jul 2003 13:16:17 +0300 (EEST)
Date: Tue, 15 Jul 2003 13:16:17 +0300 (EEST)
From: Henrik Petander <lpetande@morphine.tml.hut.fi>
To: Hemant Chaskar <hchaskar@hotmail.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
In-Reply-To: <BAY2-F941fDc5DYge2Q0000aafd@hotmail.com>
Message-ID: <Pine.GSO.4.44.0307151247420.11439-100000@morphine.tml.hut.fi>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi Hemant,

On Mon, 14 Jul 2003, Hemant Chaskar wrote:

> Hi Henrik,
>
> Clarification on your comment on per-session state: It is not clear to us
> why AR-AR resending requires any additional MN-specific state in AR. For
> AR-AR interface, in each AR there would be one outgoing queue of queries and
> one incoming queue of replies. Replies will be matched to requests and
> retransmissions will be done if needed. An implementation specific window
> (>= 1) could be defined for this similar to ARQ. Do you agree with this or
> we are missing something from your comment.

Let me clarify my view of the per-session state and the tradeoffs of using
it. The queue is one way of implementing the per-session state, since you
add a new entry to the outgoing queue every time you get a request from
MN.  You need to manage the queue and specify maximum size for it. When
the queue becomes full you need to drop some requests, causing MNs to do
resending. If there is no per-session state, this is not a problem.

IMO removal of the per-session state in AR would make the protocol simpler
and would reduce its requirements for the memory capacity of the router
without compromising its reliability and probably with no real negative
effect on its performance.  Making the protocol lighter for the AR seems
to me worth MN doing resending in case of problems in the access network,
which should be rare. Reducing the state in AR would further reduce the
probability of problems ;-)

Henrik

>
> Hemant
>
>
> >
> >Removal of per-session state from ARs
> >-------------------------------------
> >
> >The responsiblity for resends for MN initiated sessions is both in
> >the MN and the current AR. Since the weakest link in the protocol from a
> >reliability POV is probably the air interface, the AR-AR resending in
> >the MN initiated sessions is probably not worth the extra complexity.
> >
> >Removing it would simplify AR a lot, since it would not need to maintain
> >any state for CARD in addition to the CAR table. An AR without per-session
> >state would be less vulnerable to DoS attacks and would also
> >scale better.
> >
> >(The preferences and requirements should then be appended also to the
> >current AR - CAR messages, if the current AR lacks knowledge of the
> >capabilities of CARs.)
> >
> >4. CARD PROTOCOL OPERATION
> >--------------------------
> >
> >Is there a specific reason to use the rate limiting flag instead of
> >normal ICMP rate limiting ?
> >
> >Anyways, the rate limiting mechanism, which MN uses after getting a
> >reply with R-bit set, should be defined. There exist a number of
> >already defined mechanisms for dealing with resending intervals and
> >rate limiting. Why not use one of them?
> >
> >
> >
> >4.1 Data structures
> >-------------------
> >
> >Should there be a recommendation for MN to cache the information about
> >CARs ?  MN needs a CAR table with cached answers from CARD
> >replies to avoid asking the same information repeatedly, and for being
> >able to react to movement as quickly as possible.
> >
> >
> >4.2.2 Current access router operation
> >-------------------------------------
> >
> >If you use IPSec ESP for protecting CARD between MN and AR, you cannot
> >send multicast CARD replies. IPSec security associations are between
> >two hosts.
> >
> >You need to protect the CARD replies in some other way (for example
> >with signatures as proposed in the CARD problem statement draft), or
> >always send them as unicast packets.
> >
> >4.3.1 Current access router operation
> >-------------------------------------
> >
> >Is it necessary to include the capabilities of current AR in
> >AR-AR CARD request message?
> >
> >If the data in a current AR for a CAR is not up to date, it still does
> >not mean that the data for the current AR is not up to date in the
> >CAR. Including the AR-AR CARD reply automatically in the CARD request
> >creates unnecessary load in both routers when they authenticate /
> >encrypt extra data.
> >
> >This optimization also adds extra complexity to the protocol, and it is
> >not clear to me whether it is worth it.
> >
> >4.4. CARD Signaling Failure Recovery
> >------------------------------------
> >
> >The draft does not define what an AR sends to MN, when it cannot
> >resolve a L2 address into an IP address. This should be specified
> >clearly.
> >
> >4.4.2 AR-AR signaling failure
> >-----------------------------
> >
> >What does the CAR send to current AR, if it does not have an interface
> >/ AP attached to it with the queried L2 id? This should be
> >defined.
> >
> >4.5 Piggybacking
> >----------------
> >
> >In appendix B.2, there is a note that it may not be necessary to use
> >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> >since the CARD messages convey all the necessary information. This
> >seems to make the piggybacking of CARD on top of the PrRt messages
> >irrevelant. Is there some reason to do it, which is just missing from
> >the text?
> >
> >If not, this section should be removed and the messages should be
> >carried on top of UDP as in AR-AR case.
> >
> >
> >4.6 CARD protocol security
> >---------------------------
> >
> >You should move everything about IPSec ESP here and indicate clearly
> >how it should be used. Now the text about its use is scattered around
> >section 4. Perhaps the security section should be renamed "Protection
> >of CARD messages" to make a clear distinction between the
> >implementation of the protection versus the analysis in section 6.
> >
> >The section should say that 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. Definition of the SPD entries
> >would also be nice.
> >
> >5. Protocol messages
> >--------------------
> >
> >Is 8 bits enough for the CARD option length field? This translates to
> >255 octets, which seems limiting to me, especially since the
> >capabilities have not been defined. Also the AVP encoding rules in
> >5.1.4 have a 16-bit length field, which conlicts with the fact that
> >they still need to fit within the options with 8-bit length fields.
> >
> >AR - AR message format in 5.2.2 includes a length field which is
> >redundant with UDP's length field and should be removed.
> >
> >7. Protocol constants
> >----------------------
> >
> >Where are their values defined?
> >
> >
> >Editorial comments
> >==================
> >
> >General
> >--------
> >
> >The term SHALL was used in the section 4 for use of IPSec
> >ESP. However, in sections 5 and 6 the word SHOULD was used
> >instead. The use of "SHALL" was new to me so I checked its meaning
> >from RFC 2119. According to the RFC its use is: "MUST   This word, or
> >the terms "REQUIRED" or "SHALL", mean that the definition is an
> >absolute requirement of the specification."
> >
> >This should be fixed.  If capabilities such as pricing information are
> >transferred between ARs and MNs, I would opt for use of SHALL/MUST for
> >the authentication requirement. Also the card requirements draft uses
> >the word MUST for authentication and SHOULD for encryption.
> >
> >4.3.2 Candidate Access Router Operation
> >---------------------------------------
> >
> >Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
> >optionally encryption of the AR-AR CARD Reply message."
> >
> >Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
> >do not provide integrity protection and should not be used without
> >an authentication & integrity protection algorithm.
> >
> >4.4.1 MN-AR Signaling Failure
> >-----------------------------
> >
> >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
> >  CARD Request message with the given sequence number."
> >
> >Shouldn't it be the MN, which starts the timer instead of AR?
> >
> >
> >5.1.1 CARD Main Header Format
> >-----------------------------
> >
> >"Encapsulating Security Payload (ESP) Header:
> >	The sender SHOULD include the Encapsulating
> >	Security Payload (ESP) Header, based on the
> >         previously established Security Association
> >         between the sender and the receiver."
> >
> >Shouldn't this SHOULD be MUST intead?
> >
> >5.2.1 Protocol Transport
> >------------------------
> >
> >"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
> >    be used [10]."
> >
> >Again, SHOULD vs. MUST/SHALL.
> >
> >6.1 Assumptions
> >---------------
> >Second paragraph, last sentence:
> >
> >"The appendices of this draft describe procedures for discovering the
> >identities of the geographically ARs and APs and relevant security
> >considerations."
> >
> >There seems to be a word missing after "geographically". Adjacent?
> >
> >6.2 Security Association between AR and AR
> >-------------------------------------------
> >
> >"To prevent the information from being compromised, the CARD REPLY
> >  messages between ARs SHOULD be authenticated. The messages also MAY
> >  be encrypted for privacy of the information."
> >
> >Again SHOULD vs. MUST/SHALL.
> >
> >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 SHOULD authenticate the CARD REPLY
> >messages from the AR."
> >
> >Again SHOULD vs. MUST/SHALL.
> >
> >6.4 DoS Attack
> >--------------
> >
> >Should it be mentioned here that authenticating CARD requests is
> >needed to allow ARs to protect themselves against CARD request
> >flooding with spoofed addresses?
> >
> >(Authenticating the requests makes DoS less likely as the attacker's
> >identity is revealed and her account can be disabled, etc.)
> >
> >The meaning of the second paragraph is not clear to me. How can an
> >attacker masquerade as an AR, if all entities in the protocol are
> >authenticated? It seems to me that this would be possible only if an
> >AR is compromised. Should the protocol be secure also against
> >compromised routers?  This should be specified in the assumptions
> >section.
> >
> >
> >Appendix A.
> >----------
> >
> >The appendixes form quite a large part of the draft. A.1 and A.2
> >should be either integrated into the main draft as optional parts or
> >be separated into their own drafts.
> >
> >A.1.4.1 Security Associations
> >
> >More details are needed on how IPSec ESP is used.
> >
> >A.2
> >
> >What does pAR send to current AR to verify that it had or did not have
> >state for MN?
> >
> >
> >A.2.4
> >
> >"should" vs MUST be protected with IPSec ESP.
> >
> >Appendix B.
> >----------
> >
> >B.1 should be removed, since it is not needed for implementation of the
> >protocol. The draft is self explanatory enough to be used with
> >IEEE 802.11 WLANs without this appendix.
> >
> >B.2 raises the question, whether there is a need for an "architecture"
> >draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
> >be used together.
> >
> >
> >
> >_______________________________________________
> >Seamoby mailing list
> >Seamoby@ietf.org
> >https://www1.ietf.org/mailman/listinfo/seamoby
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul 16 12:41:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08127
	for <seamoby-archive@odin.ietf.org>; Wed, 16 Jul 2003 12:41:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cpL4-0006OM-TE
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 12:41:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GGfAkP024564
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 12:41:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cpL4-0006O6-0x
	for seamoby-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 12:41: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 MAA08112
	for <seamoby-web-archive@ietf.org>; Wed, 16 Jul 2003 12:41:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cpL1-00013K-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 12:41:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cpKw-00013H-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 12:41:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cpKw-0006NO-2P; Wed, 16 Jul 2003 12:41:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cpKO-0006N5-Oy
	for seamoby@optimus.ietf.org; Wed, 16 Jul 2003 12:40: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 MAA08103
	for <seamoby@ietf.org>; Wed, 16 Jul 2003 12:40:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cpKN-00013A-00
	for seamoby@ietf.org; Wed, 16 Jul 2003 12:40:27 -0400
Received: from bay2-f110.bay2.hotmail.com ([65.54.247.110] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cpKC-00012q-00
	for seamoby@ietf.org; Wed, 16 Jul 2003 12:40:16 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 16 Jul 2003 09:39:19 -0700
Received: from 63.78.179.4 by by2fd.bay2.hotmail.msn.com with HTTP;
	Wed, 16 Jul 2003 16:39:19 GMT
X-Originating-IP: [63.78.179.4]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: lpetande@morphine.tml.hut.fi
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Wed, 16 Jul 2003 16:39:19 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F110u2tIDjodYE00012185@hotmail.com>
X-OriginalArrivalTime: 16 Jul 2003 16:39:19.0992 (UTC) FILETIME=[CE12F380:01C34BB8]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi Henrik,

OK, now I get your point. How about the middle ground solution. AR SHOULD 
implement retransmissions. This will not impact interoperability as target 
AR does not need knowledge of whether source AR implements retransmissions 
or not. We can make retranmission MUST for MN. Please let us know.

Hemant


>From: Henrik Petander <lpetande@morphine.tml.hut.fi>
>To: Hemant Chaskar <hchaskar@hotmail.com>
>CC: seamoby@ietf.org
>Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
>Date: Tue, 15 Jul 2003 13:16:17 +0300 (EEST)
>
>Hi Hemant,
>
>On Mon, 14 Jul 2003, Hemant Chaskar wrote:
>
> > Hi Henrik,
> >
> > Clarification on your comment on per-session state: It is not clear to 
>us
> > why AR-AR resending requires any additional MN-specific state in AR. For
> > AR-AR interface, in each AR there would be one outgoing queue of queries 
>and
> > one incoming queue of replies. Replies will be matched to requests and
> > retransmissions will be done if needed. An implementation specific 
>window
> > (>= 1) could be defined for this similar to ARQ. Do you agree with this 
>or
> > we are missing something from your comment.
>
>Let me clarify my view of the per-session state and the tradeoffs of using
>it. The queue is one way of implementing the per-session state, since you
>add a new entry to the outgoing queue every time you get a request from
>MN.  You need to manage the queue and specify maximum size for it. When
>the queue becomes full you need to drop some requests, causing MNs to do
>resending. If there is no per-session state, this is not a problem.
>
>IMO removal of the per-session state in AR would make the protocol simpler
>and would reduce its requirements for the memory capacity of the router
>without compromising its reliability and probably with no real negative
>effect on its performance.  Making the protocol lighter for the AR seems
>to me worth MN doing resending in case of problems in the access network,
>which should be rare. Reducing the state in AR would further reduce the
>probability of problems ;-)
>
>Henrik
>
> >
> > Hemant
> >
> >
> > >
> > >Removal of per-session state from ARs
> > >-------------------------------------
> > >
> > >The responsiblity for resends for MN initiated sessions is both in
> > >the MN and the current AR. Since the weakest link in the protocol from 
>a
> > >reliability POV is probably the air interface, the AR-AR resending in
> > >the MN initiated sessions is probably not worth the extra complexity.
> > >
> > >Removing it would simplify AR a lot, since it would not need to 
>maintain
> > >any state for CARD in addition to the CAR table. An AR without 
>per-session
> > >state would be less vulnerable to DoS attacks and would also
> > >scale better.
> > >
> > >(The preferences and requirements should then be appended also to the
> > >current AR - CAR messages, if the current AR lacks knowledge of the
> > >capabilities of CARs.)
> > >
> > >4. CARD PROTOCOL OPERATION
> > >--------------------------
> > >
> > >Is there a specific reason to use the rate limiting flag instead of
> > >normal ICMP rate limiting ?
> > >
> > >Anyways, the rate limiting mechanism, which MN uses after getting a
> > >reply with R-bit set, should be defined. There exist a number of
> > >already defined mechanisms for dealing with resending intervals and
> > >rate limiting. Why not use one of them?
> > >
> > >
> > >
> > >4.1 Data structures
> > >-------------------
> > >
> > >Should there be a recommendation for MN to cache the information about
> > >CARs ?  MN needs a CAR table with cached answers from CARD
> > >replies to avoid asking the same information repeatedly, and for being
> > >able to react to movement as quickly as possible.
> > >
> > >
> > >4.2.2 Current access router operation
> > >-------------------------------------
> > >
> > >If you use IPSec ESP for protecting CARD between MN and AR, you cannot
> > >send multicast CARD replies. IPSec security associations are between
> > >two hosts.
> > >
> > >You need to protect the CARD replies in some other way (for example
> > >with signatures as proposed in the CARD problem statement draft), or
> > >always send them as unicast packets.
> > >
> > >4.3.1 Current access router operation
> > >-------------------------------------
> > >
> > >Is it necessary to include the capabilities of current AR in
> > >AR-AR CARD request message?
> > >
> > >If the data in a current AR for a CAR is not up to date, it still does
> > >not mean that the data for the current AR is not up to date in the
> > >CAR. Including the AR-AR CARD reply automatically in the CARD request
> > >creates unnecessary load in both routers when they authenticate /
> > >encrypt extra data.
> > >
> > >This optimization also adds extra complexity to the protocol, and it is
> > >not clear to me whether it is worth it.
> > >
> > >4.4. CARD Signaling Failure Recovery
> > >------------------------------------
> > >
> > >The draft does not define what an AR sends to MN, when it cannot
> > >resolve a L2 address into an IP address. This should be specified
> > >clearly.
> > >
> > >4.4.2 AR-AR signaling failure
> > >-----------------------------
> > >
> > >What does the CAR send to current AR, if it does not have an interface
> > >/ AP attached to it with the queried L2 id? This should be
> > >defined.
> > >
> > >4.5 Piggybacking
> > >----------------
> > >
> > >In appendix B.2, there is a note that it may not be necessary to use
> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> > >since the CARD messages convey all the necessary information. This
> > >seems to make the piggybacking of CARD on top of the PrRt messages
> > >irrevelant. Is there some reason to do it, which is just missing from
> > >the text?
> > >
> > >If not, this section should be removed and the messages should be
> > >carried on top of UDP as in AR-AR case.
> > >
> > >
> > >4.6 CARD protocol security
> > >---------------------------
> > >
> > >You should move everything about IPSec ESP here and indicate clearly
> > >how it should be used. Now the text about its use is scattered around
> > >section 4. Perhaps the security section should be renamed "Protection
> > >of CARD messages" to make a clear distinction between the
> > >implementation of the protection versus the analysis in section 6.
> > >
> > >The section should say that 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. Definition of the SPD entries
> > >would also be nice.
> > >
> > >5. Protocol messages
> > >--------------------
> > >
> > >Is 8 bits enough for the CARD option length field? This translates to
> > >255 octets, which seems limiting to me, especially since the
> > >capabilities have not been defined. Also the AVP encoding rules in
> > >5.1.4 have a 16-bit length field, which conlicts with the fact that
> > >they still need to fit within the options with 8-bit length fields.
> > >
> > >AR - AR message format in 5.2.2 includes a length field which is
> > >redundant with UDP's length field and should be removed.
> > >
> > >7. Protocol constants
> > >----------------------
> > >
> > >Where are their values defined?
> > >
> > >
> > >Editorial comments
> > >==================
> > >
> > >General
> > >--------
> > >
> > >The term SHALL was used in the section 4 for use of IPSec
> > >ESP. However, in sections 5 and 6 the word SHOULD was used
> > >instead. The use of "SHALL" was new to me so I checked its meaning
> > >from RFC 2119. According to the RFC its use is: "MUST   This word, or
> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
> > >absolute requirement of the specification."
> > >
> > >This should be fixed.  If capabilities such as pricing information are
> > >transferred between ARs and MNs, I would opt for use of SHALL/MUST for
> > >the authentication requirement. Also the card requirements draft uses
> > >the word MUST for authentication and SHOULD for encryption.
> > >
> > >4.3.2 Candidate Access Router Operation
> > >---------------------------------------
> > >
> > >Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
> > >optionally encryption of the AR-AR CARD Reply message."
> > >
> > >Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
> > >do not provide integrity protection and should not be used without
> > >an authentication & integrity protection algorithm.
> > >
> > >4.4.1 MN-AR Signaling Failure
> > >-----------------------------
> > >
> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
> > >  CARD Request message with the given sequence number."
> > >
> > >Shouldn't it be the MN, which starts the timer instead of AR?
> > >
> > >
> > >5.1.1 CARD Main Header Format
> > >-----------------------------
> > >
> > >"Encapsulating Security Payload (ESP) Header:
> > >	The sender SHOULD include the Encapsulating
> > >	Security Payload (ESP) Header, based on the
> > >         previously established Security Association
> > >         between the sender and the receiver."
> > >
> > >Shouldn't this SHOULD be MUST intead?
> > >
> > >5.2.1 Protocol Transport
> > >------------------------
> > >
> > >"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
> > >    be used [10]."
> > >
> > >Again, SHOULD vs. MUST/SHALL.
> > >
> > >6.1 Assumptions
> > >---------------
> > >Second paragraph, last sentence:
> > >
> > >"The appendices of this draft describe procedures for discovering the
> > >identities of the geographically ARs and APs and relevant security
> > >considerations."
> > >
> > >There seems to be a word missing after "geographically". Adjacent?
> > >
> > >6.2 Security Association between AR and AR
> > >-------------------------------------------
> > >
> > >"To prevent the information from being compromised, the CARD REPLY
> > >  messages between ARs SHOULD be authenticated. The messages also MAY
> > >  be encrypted for privacy of the information."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >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 SHOULD authenticate the CARD REPLY
> > >messages from the AR."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >6.4 DoS Attack
> > >--------------
> > >
> > >Should it be mentioned here that authenticating CARD requests is
> > >needed to allow ARs to protect themselves against CARD request
> > >flooding with spoofed addresses?
> > >
> > >(Authenticating the requests makes DoS less likely as the attacker's
> > >identity is revealed and her account can be disabled, etc.)
> > >
> > >The meaning of the second paragraph is not clear to me. How can an
> > >attacker masquerade as an AR, if all entities in the protocol are
> > >authenticated? It seems to me that this would be possible only if an
> > >AR is compromised. Should the protocol be secure also against
> > >compromised routers?  This should be specified in the assumptions
> > >section.
> > >
> > >
> > >Appendix A.
> > >----------
> > >
> > >The appendixes form quite a large part of the draft. A.1 and A.2
> > >should be either integrated into the main draft as optional parts or
> > >be separated into their own drafts.
> > >
> > >A.1.4.1 Security Associations
> > >
> > >More details are needed on how IPSec ESP is used.
> > >
> > >A.2
> > >
> > >What does pAR send to current AR to verify that it had or did not have
> > >state for MN?
> > >
> > >
> > >A.2.4
> > >
> > >"should" vs MUST be protected with IPSec ESP.
> > >
> > >Appendix B.
> > >----------
> > >
> > >B.1 should be removed, since it is not needed for implementation of the
> > >protocol. The draft is self explanatory enough to be used with
> > >IEEE 802.11 WLANs without this appendix.
> > >
> > >B.2 raises the question, whether there is a need for an "architecture"
> > >draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
> > >be used together.
> > >
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
>
>		----------------------------------
>		Henrik Petander
>		Helsinki University of Technology,
>		GO/Core Project
>		Henrik.Petander@hut.fi
>		Office: +358 (0)9 451 5846
>		GSM: +358 (0)40 741 5248
>		----------------------------------
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Wed Jul 16 13:50:50 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 NAA10310
	for <seamoby-archive@odin.ietf.org>; Wed, 16 Jul 2003 13:50:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cqQ4-0001j8-9k
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 13:50:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHoODU006634
	for seamoby-archive@odin.ietf.org; Wed, 16 Jul 2003 13:50:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cqQ3-0001iv-GW
	for seamoby-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 13:50: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 NAA10289
	for <seamoby-web-archive@ietf.org>; Wed, 16 Jul 2003 13:50:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cqQ1-0001dU-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 13:50:21 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cqPv-0001dR-00
	for seamoby-web-archive@ietf.org; Wed, 16 Jul 2003 13:50:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19cqPh-0001gD-Vc; Wed, 16 Jul 2003 13: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 19cqOs-0001Va-H7
	for seamoby@optimus.ietf.org; Wed, 16 Jul 2003 13:49: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 NAA10228
	for <seamoby@ietf.org>; Wed, 16 Jul 2003 13:49:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19cqOq-0001ct-00
	for seamoby@ietf.org; Wed, 16 Jul 2003 13:49:08 -0400
Received: from bay8-dav48.bay8.hotmail.com ([64.4.26.20] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19cqOf-0001c4-00
	for seamoby@ietf.org; Wed, 16 Jul 2003 13:48:57 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 16 Jul 2003 10:47:49 -0700
Received: from 81.160.64.232 by bay8-dav48.bay8.hotmail.com with DAV;
	Wed, 16 Jul 2003 17:47:49 +0000
X-Originating-IP: [81.160.64.232]
X-Originating-Email: [eunsooyo@hotmail.com]
From: "Eunsoo Shim" <eunsooyo@hotmail.com>
To: "Henrik Petander" <lpetande@morphine.tml.hut.fi>,
        "Hemant Chaskar" <hchaskar@hotmail.com>
Cc: <seamoby@ietf.org>
References: <Pine.GSO.4.44.0307151247420.11439-100000@morphine.tml.hut.fi>
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Wed, 16 Jul 2003 13:52: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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <BAY8-DAV48D5euwdUTa000115fe@hotmail.com>
X-OriginalArrivalTime: 16 Jul 2003 17:47:49.0853 (UTC) FILETIME=[5FBDF8D0:01C34BC2]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, Henrik,

I think it is preferable to reduce any traffic on the air from the MN. So if
the retransmission by AR can reduce the over-the-air traffic, the cost can
be worthwhile unless it is too big. I am not sure maintaining a state per
request to check reply is too much complex in this case.

Eunsoo

----- Original Message -----
From: "Henrik Petander" <lpetande@morphine.tml.hut.fi>
To: "Hemant Chaskar" <hchaskar@hotmail.com>
Cc: <seamoby@ietf.org>
Sent: Tuesday, July 15, 2003 6:16 AM
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt


> Hi Hemant,
>
> On Mon, 14 Jul 2003, Hemant Chaskar wrote:
>
> > Hi Henrik,
> >
> > Clarification on your comment on per-session state: It is not clear to
us
> > why AR-AR resending requires any additional MN-specific state in AR. For
> > AR-AR interface, in each AR there would be one outgoing queue of queries
and
> > one incoming queue of replies. Replies will be matched to requests and
> > retransmissions will be done if needed. An implementation specific
window
> > (>= 1) could be defined for this similar to ARQ. Do you agree with this
or
> > we are missing something from your comment.
>
> Let me clarify my view of the per-session state and the tradeoffs of using
> it. The queue is one way of implementing the per-session state, since you
> add a new entry to the outgoing queue every time you get a request from
> MN.  You need to manage the queue and specify maximum size for it. When
> the queue becomes full you need to drop some requests, causing MNs to do
> resending. If there is no per-session state, this is not a problem.
>
> IMO removal of the per-session state in AR would make the protocol simpler
> and would reduce its requirements for the memory capacity of the router
> without compromising its reliability and probably with no real negative
> effect on its performance.  Making the protocol lighter for the AR seems
> to me worth MN doing resending in case of problems in the access network,
> which should be rare. Reducing the state in AR would further reduce the
> probability of problems ;-)
>
> Henrik
>
> >
> > Hemant
> >
> >
> > >
> > >Removal of per-session state from ARs
> > >-------------------------------------
> > >
> > >The responsiblity for resends for MN initiated sessions is both in
> > >the MN and the current AR. Since the weakest link in the protocol from
a
> > >reliability POV is probably the air interface, the AR-AR resending in
> > >the MN initiated sessions is probably not worth the extra complexity.
> > >
> > >Removing it would simplify AR a lot, since it would not need to
maintain
> > >any state for CARD in addition to the CAR table. An AR without
per-session
> > >state would be less vulnerable to DoS attacks and would also
> > >scale better.
> > >
> > >(The preferences and requirements should then be appended also to the
> > >current AR - CAR messages, if the current AR lacks knowledge of the
> > >capabilities of CARs.)
> > >
> > >4. CARD PROTOCOL OPERATION
> > >--------------------------
> > >
> > >Is there a specific reason to use the rate limiting flag instead of
> > >normal ICMP rate limiting ?
> > >
> > >Anyways, the rate limiting mechanism, which MN uses after getting a
> > >reply with R-bit set, should be defined. There exist a number of
> > >already defined mechanisms for dealing with resending intervals and
> > >rate limiting. Why not use one of them?
> > >
> > >
> > >
> > >4.1 Data structures
> > >-------------------
> > >
> > >Should there be a recommendation for MN to cache the information about
> > >CARs ?  MN needs a CAR table with cached answers from CARD
> > >replies to avoid asking the same information repeatedly, and for being
> > >able to react to movement as quickly as possible.
> > >
> > >
> > >4.2.2 Current access router operation
> > >-------------------------------------
> > >
> > >If you use IPSec ESP for protecting CARD between MN and AR, you cannot
> > >send multicast CARD replies. IPSec security associations are between
> > >two hosts.
> > >
> > >You need to protect the CARD replies in some other way (for example
> > >with signatures as proposed in the CARD problem statement draft), or
> > >always send them as unicast packets.
> > >
> > >4.3.1 Current access router operation
> > >-------------------------------------
> > >
> > >Is it necessary to include the capabilities of current AR in
> > >AR-AR CARD request message?
> > >
> > >If the data in a current AR for a CAR is not up to date, it still does
> > >not mean that the data for the current AR is not up to date in the
> > >CAR. Including the AR-AR CARD reply automatically in the CARD request
> > >creates unnecessary load in both routers when they authenticate /
> > >encrypt extra data.
> > >
> > >This optimization also adds extra complexity to the protocol, and it is
> > >not clear to me whether it is worth it.
> > >
> > >4.4. CARD Signaling Failure Recovery
> > >------------------------------------
> > >
> > >The draft does not define what an AR sends to MN, when it cannot
> > >resolve a L2 address into an IP address. This should be specified
> > >clearly.
> > >
> > >4.4.2 AR-AR signaling failure
> > >-----------------------------
> > >
> > >What does the CAR send to current AR, if it does not have an interface
> > >/ AP attached to it with the queried L2 id? This should be
> > >defined.
> > >
> > >4.5 Piggybacking
> > >----------------
> > >
> > >In appendix B.2, there is a note that it may not be necessary to use
> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> > >since the CARD messages convey all the necessary information. This
> > >seems to make the piggybacking of CARD on top of the PrRt messages
> > >irrevelant. Is there some reason to do it, which is just missing from
> > >the text?
> > >
> > >If not, this section should be removed and the messages should be
> > >carried on top of UDP as in AR-AR case.
> > >
> > >
> > >4.6 CARD protocol security
> > >---------------------------
> > >
> > >You should move everything about IPSec ESP here and indicate clearly
> > >how it should be used. Now the text about its use is scattered around
> > >section 4. Perhaps the security section should be renamed "Protection
> > >of CARD messages" to make a clear distinction between the
> > >implementation of the protection versus the analysis in section 6.
> > >
> > >The section should say that 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. Definition of the SPD entries
> > >would also be nice.
> > >
> > >5. Protocol messages
> > >--------------------
> > >
> > >Is 8 bits enough for the CARD option length field? This translates to
> > >255 octets, which seems limiting to me, especially since the
> > >capabilities have not been defined. Also the AVP encoding rules in
> > >5.1.4 have a 16-bit length field, which conlicts with the fact that
> > >they still need to fit within the options with 8-bit length fields.
> > >
> > >AR - AR message format in 5.2.2 includes a length field which is
> > >redundant with UDP's length field and should be removed.
> > >
> > >7. Protocol constants
> > >----------------------
> > >
> > >Where are their values defined?
> > >
> > >
> > >Editorial comments
> > >==================
> > >
> > >General
> > >--------
> > >
> > >The term SHALL was used in the section 4 for use of IPSec
> > >ESP. However, in sections 5 and 6 the word SHOULD was used
> > >instead. The use of "SHALL" was new to me so I checked its meaning
> > >from RFC 2119. According to the RFC its use is: "MUST   This word, or
> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
> > >absolute requirement of the specification."
> > >
> > >This should be fixed.  If capabilities such as pricing information are
> > >transferred between ARs and MNs, I would opt for use of SHALL/MUST for
> > >the authentication requirement. Also the card requirements draft uses
> > >the word MUST for authentication and SHOULD for encryption.
> > >
> > >4.3.2 Candidate Access Router Operation
> > >---------------------------------------
> > >
> > >Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
> > >optionally encryption of the AR-AR CARD Reply message."
> > >
> > >Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
> > >do not provide integrity protection and should not be used without
> > >an authentication & integrity protection algorithm.
> > >
> > >4.4.1 MN-AR Signaling Failure
> > >-----------------------------
> > >
> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
> > >  CARD Request message with the given sequence number."
> > >
> > >Shouldn't it be the MN, which starts the timer instead of AR?
> > >
> > >
> > >5.1.1 CARD Main Header Format
> > >-----------------------------
> > >
> > >"Encapsulating Security Payload (ESP) Header:
> > > The sender SHOULD include the Encapsulating
> > > Security Payload (ESP) Header, based on the
> > >         previously established Security Association
> > >         between the sender and the receiver."
> > >
> > >Shouldn't this SHOULD be MUST intead?
> > >
> > >5.2.1 Protocol Transport
> > >------------------------
> > >
> > >"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
> > >    be used [10]."
> > >
> > >Again, SHOULD vs. MUST/SHALL.
> > >
> > >6.1 Assumptions
> > >---------------
> > >Second paragraph, last sentence:
> > >
> > >"The appendices of this draft describe procedures for discovering the
> > >identities of the geographically ARs and APs and relevant security
> > >considerations."
> > >
> > >There seems to be a word missing after "geographically". Adjacent?
> > >
> > >6.2 Security Association between AR and AR
> > >-------------------------------------------
> > >
> > >"To prevent the information from being compromised, the CARD REPLY
> > >  messages between ARs SHOULD be authenticated. The messages also MAY
> > >  be encrypted for privacy of the information."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >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 SHOULD authenticate the CARD REPLY
> > >messages from the AR."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >6.4 DoS Attack
> > >--------------
> > >
> > >Should it be mentioned here that authenticating CARD requests is
> > >needed to allow ARs to protect themselves against CARD request
> > >flooding with spoofed addresses?
> > >
> > >(Authenticating the requests makes DoS less likely as the attacker's
> > >identity is revealed and her account can be disabled, etc.)
> > >
> > >The meaning of the second paragraph is not clear to me. How can an
> > >attacker masquerade as an AR, if all entities in the protocol are
> > >authenticated? It seems to me that this would be possible only if an
> > >AR is compromised. Should the protocol be secure also against
> > >compromised routers?  This should be specified in the assumptions
> > >section.
> > >
> > >
> > >Appendix A.
> > >----------
> > >
> > >The appendixes form quite a large part of the draft. A.1 and A.2
> > >should be either integrated into the main draft as optional parts or
> > >be separated into their own drafts.
> > >
> > >A.1.4.1 Security Associations
> > >
> > >More details are needed on how IPSec ESP is used.
> > >
> > >A.2
> > >
> > >What does pAR send to current AR to verify that it had or did not have
> > >state for MN?
> > >
> > >
> > >A.2.4
> > >
> > >"should" vs MUST be protected with IPSec ESP.
> > >
> > >Appendix B.
> > >----------
> > >
> > >B.1 should be removed, since it is not needed for implementation of the
> > >protocol. The draft is self explanatory enough to be used with
> > >IEEE 802.11 WLANs without this appendix.
> > >
> > >B.2 raises the question, whether there is a need for an "architecture"
> > >draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
> > >be used together.
> > >
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
>
> ----------------------------------
> Henrik Petander
> Helsinki University of Technology,
> GO/Core Project
> Henrik.Petander@hut.fi
> Office: +358 (0)9 451 5846
> GSM: +358 (0)40 741 5248
> ----------------------------------
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 01:45:52 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 BAA03391
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 01:45:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d1Zy-000847-V3
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 01:45:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H5jMwQ030997
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 01:45:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d1Zy-00083s-Qy
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 01:45: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 BAA03388
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 01:45:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d1Zv-0000zw-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 01:45:19 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d1Zq-0000zn-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 01:45:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d1Zc-00083D-QY; Thu, 17 Jul 2003 01:45:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d1ZV-00082w-0K
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 01:44: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 BAA03346
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 01:44:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d1ZQ-0000zL-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 01:44:48 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d1ZD-0000wy-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 01:44:36 -0400
Message-ID: <009201c34c26$5fe27250$566015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Thu, 17 Jul 2003 07:43:37 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Issue 1:Standards Track Language
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

In advance of today's meeting, I sent email to the IESG asking them about
this issue, and Harald responded that they have recently changed the policy
so that RFC 2119 is OK for Experimental if the authors think this is
appropriate.

I think we can declare this issue closed.

            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 02:19: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 CAA16767
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 02:19: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 19d267-0002gr-0T
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:18:35 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6IYKt010335
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:18:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d266-0002gc-Sv
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:18:34 -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 CAA16708
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 02:18: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 19d25a-0002a3-M8; Thu, 17 Jul 2003 02:18:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d25J-0002YV-9z
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 02:17:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16585
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 02:17:40 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d25F-0001Ml-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:17:41 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d254-0001M7-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:17:30 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H6EsB18540
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 09:14:54 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T637bf32336ac158f21083@esvir01nok.ntc.nokia.com>;
 Thu, 17 Jul 2003 09:14:54 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 09:14:54 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 09:14:53 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Jul 2003 09:14:52 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB3206360C1FFD@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Issue 1:Standards Track Language
Thread-Index: AcNMJuktK2rneCqUSvirqVfp1r2/ZAAAnmjQ
To: <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
X-OriginalArrivalTime: 17 Jul 2003 06:14:53.0468 (UTC) FILETIME=[BCB2D5C0:01C34C2A]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] CTP Issue17: Clarifying text needed on deployment restrictions
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

I've marked this as possible reject, the text is as follows:

Small clarification may be in order, but as this is=20
experimental, discussing 'ct within one ISP' isn't really=20
applicable.

But regardless of that, I think it's important (and I think=20
you'll probably agree) to at least try to paint some=20
picture about deployment restrictions very early (in=20
abstract, special section or introduction), so people don't=20
have too many fantastic notions about the applicability=20
(and when starting to read the document, think like "what=20
are these guys doing?  you can't solve the generic problem=20
with this".

So, personally I think it might be a good idea to focus=20
first *with sufficiently verbose text early on* on=20
the "context transfer inside one ISP" -problem, and see=20
whether it gives you sufficient sufficient benefits
and the protocol can be deployed.


John

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 02:22:59 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 CAA17167
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 02:22:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d29x-0003Di-HP
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:22:33 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6MXAF012372
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:22:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d29x-0003DF-3i
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:22: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 CAA17115
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 02:22: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 19d29S-0002zB-DY; Thu, 17 Jul 2003 02:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d28x-0002xA-QM
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 02:21:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17033
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 02:21: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 19d28u-0001PK-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:21:28 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d28h-0001O0-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:21:15 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H6J1k06393
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 09:19:01 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T637bf6e851ac158f24077@esvir04nok.ntc.nokia.com>;
 Thu, 17 Jul 2003 09:19:01 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 09:19:01 +0300
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 09:19:00 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 09:19:00 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Jul 2003 09:18:59 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658F1A5@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] Issue 1:Standards Track Language
Thread-Index: AcNMJuktK2rneCqUSvirqVfp1r2/ZAABEOpQ
To: <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
X-OriginalArrivalTime: 17 Jul 2003 06:19:00.0334 (UTC) FILETIME=[4FD798E0:01C34C2B]
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] CTP Issue20: How to identify MN's with private addresses
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

I've marked this as a possible reject, the text is as follows:

msg31 Author: jloughney Date: 2003-07-17.06:17:41=20
I think for experimental, we sould focus on the optimistic=20
cases.  This issue needs to be resolved before becoming a=20
standards track doc.

=20
msg21 Author: jloughney Date: 2003-06-27.12:17:46=20
Section 2.4
   a. "The Mobile Node, for which context transfer protocol=20
operations are undertaken, is always identified by its=20
previous IP access address." - Is uniqueness of the address=20
at the previous AR guaranteed? For example in the case of=20
Mobile IPv4, MNs which have private addresses may use the=20
FA advertised CoA and reverse tunnel to the HA. In that=20
case there could be multiple MNs with the same IP address
(HoA). The FA is able to differentiate=20
=20
John

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 02:23:58 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 CAA17249
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 02:23:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2At-0003YR-SM
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:23:31 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6NVUD013659
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:23:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2At-0003YE-NP
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:23: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 CAA17223
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 02:23: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 19d2AP-0003KA-9A; Thu, 17 Jul 2003 02: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 19d2AE-0003JK-S7
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 02:22: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 CAA17161
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 02:22:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2AB-0001Qh-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:22:47 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2A0-0001Qc-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:22:36 -0400
Message-ID: <00c301c34c2b$d49e1360$566015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <john.loughney@nokia.com>, <seamoby@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB3206360C1FFD@esebe023.ntc.nokia.com>
Date: Thu, 17 Jul 2003 08:22:41 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: CTP Issue17: Clarifying text needed on deployment restrictions
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Agree.

            jak

----- Original Message ----- 
From: <john.loughney@nokia.com>
To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Thursday, July 17, 2003 8:14 AM
Subject: CTP Issue17: Clarifying text needed on deployment restrictions 


> Hi all,
> 
> I've marked this as possible reject, the text is as follows:
> 
> Small clarification may be in order, but as this is 
> experimental, discussing 'ct within one ISP' isn't really 
> applicable.
> 
> But regardless of that, I think it's important (and I think 
> you'll probably agree) to at least try to paint some 
> picture about deployment restrictions very early (in 
> abstract, special section or introduction), so people don't 
> have too many fantastic notions about the applicability 
> (and when starting to read the document, think like "what 
> are these guys doing?  you can't solve the generic problem 
> with this".
> 
> So, personally I think it might be a good idea to focus 
> first *with sufficiently verbose text early on* on 
> the "context transfer inside one ISP" -problem, and see 
> whether it gives you sufficient sufficient benefits
> and the protocol can be deployed.
> 
> 
> John
> 
> 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 02:35: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 CAA17814
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 02:35:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2M9-0004Hx-Is
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:35:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6Z91J016479
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 02:35:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2M9-0004Hi-6r
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:35: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 CAA17787
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 02:35:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2M5-0001f7-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 02:35:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2Lz-0001f4-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 02:34:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2M2-0004Ge-3c; Thu, 17 Jul 2003 02:35:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d2LJ-0004FM-BB
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 02:34: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 CAA17727
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 02:34:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2LF-0001eC-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:34:13 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d2L4-0001e9-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 02:34:02 -0400
Message-ID: <00e601c34c2d$6e0beb20$566015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <john.loughney@nokia.com>, <seamoby@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB32063658F1A5@esebe023.ntc.nokia.com>
Date: Thu, 17 Jul 2003 08:34:07 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: CTP Issue20: How to identify MN's with private addresses
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Agree.

        jak

----- Original Message ----- 
From: <john.loughney@nokia.com>
To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Thursday, July 17, 2003 8:18 AM
Subject: CTP Issue20: How to identify MN's with private addresses


> Hi all,
> 
> I've marked this as a possible reject, the text is as follows:
> 
> msg31 Author: jloughney Date: 2003-07-17.06:17:41 
> I think for experimental, we sould focus on the optimistic 
> cases.  This issue needs to be resolved before becoming a 
> standards track doc.
> 
>  
> msg21 Author: jloughney Date: 2003-06-27.12:17:46 
> Section 2.4
>    a. "The Mobile Node, for which context transfer protocol 
> operations are undertaken, is always identified by its 
> previous IP access address." - Is uniqueness of the address 
> at the previous AR guaranteed? For example in the case of 
> Mobile IPv4, MNs which have private addresses may use the 
> FA advertised CoA and reverse tunnel to the HA. In that 
> case there could be multiple MNs with the same IP address
> (HoA). The FA is able to differentiate 
>  
> John
> 
> 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 03:40:02 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20640
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 03:40:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d3MV-0000tv-1f
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 03:39:35 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7dYt7003459
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 03:39:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d3MU-0000tg-2x
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:39:34 -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 DAA20634
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 03: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 19d3Lx-0000l8-Pt; Thu, 17 Jul 2003 03:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d3LX-0000kL-Ns
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 03:38: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 DAA20593
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 03:38:32 -0400 (EDT)
From: Dirk.Trossen@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d3LV-0002NK-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 03:38:33 -0400
Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d3LK-0002Lk-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 03:38:22 -0400
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6H7Zf113247
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 02:35:41 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T637a85a4fdac12f254079@davir01nok.americas.nokia.com>;
 Thu, 17 Jul 2003 02:35:41 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 17 Jul 2003 02:35:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Date: Thu, 17 Jul 2003 03:35:29 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB012460011CC750@bsebe001.americas.nokia.com>
Thread-Topic: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
Thread-Index: AcNLwtFTsU6x7fe2QGuz8dcxIdLRgAAcjOAw
To: <eunsooyo@hotmail.com>, <lpetande@morphine.tml.hut.fi>,
        <hchaskar@hotmail.com>
Cc: <seamoby@ietf.org>
X-OriginalArrivalTime: 17 Jul 2003 07:35:30.0696 (UTC) FILETIME=[FFE94080:01C34C35]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi Henrik,

I must strongly agree with Eunsoo here. The reason to tranfer the =
retransmission functionality to the AR is a matter of failure handling =
and air bandwidth reduction. If we draw a picture like
MN - cAR - nAR
it does not make sense to me that if there is a failure between cAR and =
nAR, why the retransmission has to go all the way from MN via cAR again =
to nAR?? More concretely, if we let the MN handle retransmissions, we =
reduce the AR's complexity rather insignificantly but in parallel we buy =
in higher air bandwidth usage through the MN (although the information =
has already been received at the current AR) plus we let an entity do =
retransmission which has higher transmission failures anyway (i.e., on =
the air interface). That does not seem worth to me. =20

However, Hemant's proposal of MAY for the AR implementing =
retransmission, could be one way to go in order to remove the issue, =
even though I would prefer a SHOULD in this place.

Dirk

>-----Original Message-----
>From: ext Eunsoo Shim [mailto:eunsooyo@hotmail.com]
>Sent: Wednesday, July 16, 2003 1:52 PM
>To: Henrik Petander; Hemant Chaskar
>Cc: seamoby@ietf.org
>Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
>
>
>Hi, Henrik,
>
>I think it is preferable to reduce any traffic on the air from=20
>the MN. So if
>the retransmission by AR can reduce the over-the-air traffic,=20
>the cost can
>be worthwhile unless it is too big. I am not sure maintaining=20
>a state per
>request to check reply is too much complex in this case.
>
>Eunsoo
>
>----- Original Message -----
>From: "Henrik Petander" <lpetande@morphine.tml.hut.fi>
>To: "Hemant Chaskar" <hchaskar@hotmail.com>
>Cc: <seamoby@ietf.org>
>Sent: Tuesday, July 15, 2003 6:16 AM
>Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
>
>
>> Hi Hemant,
>>
>> On Mon, 14 Jul 2003, Hemant Chaskar wrote:
>>
>> > Hi Henrik,
>> >
>> > Clarification on your comment on per-session state: It is=20
>not clear to
>us
>> > why AR-AR resending requires any additional MN-specific=20
>state in AR. For
>> > AR-AR interface, in each AR there would be one outgoing=20
>queue of queries
>and
>> > one incoming queue of replies. Replies will be matched to=20
>requests and
>> > retransmissions will be done if needed. An implementation specific
>window
>> > (>=3D 1) could be defined for this similar to ARQ. Do you=20
>agree with this
>or
>> > we are missing something from your comment.
>>
>> Let me clarify my view of the per-session state and the=20
>tradeoffs of using
>> it. The queue is one way of implementing the per-session=20
>state, since you
>> add a new entry to the outgoing queue every time you get a=20
>request from
>> MN.  You need to manage the queue and specify maximum size=20
>for it. When
>> the queue becomes full you need to drop some requests,=20
>causing MNs to do
>> resending. If there is no per-session state, this is not a problem.
>>
>> IMO removal of the per-session state in AR would make the=20
>protocol simpler
>> and would reduce its requirements for the memory capacity of=20
>the router
>> without compromising its reliability and probably with no=20
>real negative
>> effect on its performance.  Making the protocol lighter for=20
>the AR seems
>> to me worth MN doing resending in case of problems in the=20
>access network,
>> which should be rare. Reducing the state in AR would further=20
>reduce the
>> probability of problems ;-)
>>
>> Henrik
>>
>> >
>> > Hemant
>> >
>> >
>> > >
>> > >Removal of per-session state from ARs
>> > >-------------------------------------
>> > >
>> > >The responsiblity for resends for MN initiated sessions is both in
>> > >the MN and the current AR. Since the weakest link in the=20
>protocol from
>a
>> > >reliability POV is probably the air interface, the AR-AR=20
>resending in
>> > >the MN initiated sessions is probably not worth the extra=20
>complexity.
>> > >
>> > >Removing it would simplify AR a lot, since it would not need to
>maintain
>> > >any state for CARD in addition to the CAR table. An AR without
>per-session
>> > >state would be less vulnerable to DoS attacks and would also
>> > >scale better.
>> > >
>> > >(The preferences and requirements should then be appended=20
>also to the
>> > >current AR - CAR messages, if the current AR lacks=20
>knowledge of the
>> > >capabilities of CARs.)
>> > >
>> > >4. CARD PROTOCOL OPERATION
>> > >--------------------------
>> > >
>> > >Is there a specific reason to use the rate limiting flag=20
>instead of
>> > >normal ICMP rate limiting ?
>> > >
>> > >Anyways, the rate limiting mechanism, which MN uses after=20
>getting a
>> > >reply with R-bit set, should be defined. There exist a number of
>> > >already defined mechanisms for dealing with resending=20
>intervals and
>> > >rate limiting. Why not use one of them?
>> > >
>> > >
>> > >
>> > >4.1 Data structures
>> > >-------------------
>> > >
>> > >Should there be a recommendation for MN to cache the=20
>information about
>> > >CARs ?  MN needs a CAR table with cached answers from CARD
>> > >replies to avoid asking the same information repeatedly,=20
>and for being
>> > >able to react to movement as quickly as possible.
>> > >
>> > >
>> > >4.2.2 Current access router operation
>> > >-------------------------------------
>> > >
>> > >If you use IPSec ESP for protecting CARD between MN and=20
>AR, you cannot
>> > >send multicast CARD replies. IPSec security associations=20
>are between
>> > >two hosts.
>> > >
>> > >You need to protect the CARD replies in some other way=20
>(for example
>> > >with signatures as proposed in the CARD problem statement=20
>draft), or
>> > >always send them as unicast packets.
>> > >
>> > >4.3.1 Current access router operation
>> > >-------------------------------------
>> > >
>> > >Is it necessary to include the capabilities of current AR in
>> > >AR-AR CARD request message?
>> > >
>> > >If the data in a current AR for a CAR is not up to date,=20
>it still does
>> > >not mean that the data for the current AR is not up to date in the
>> > >CAR. Including the AR-AR CARD reply automatically in the=20
>CARD request
>> > >creates unnecessary load in both routers when they authenticate /
>> > >encrypt extra data.
>> > >
>> > >This optimization also adds extra complexity to the=20
>protocol, and it is
>> > >not clear to me whether it is worth it.
>> > >
>> > >4.4. CARD Signaling Failure Recovery
>> > >------------------------------------
>> > >
>> > >The draft does not define what an AR sends to MN, when it cannot
>> > >resolve a L2 address into an IP address. This should be specified
>> > >clearly.
>> > >
>> > >4.4.2 AR-AR signaling failure
>> > >-----------------------------
>> > >
>> > >What does the CAR send to current AR, if it does not have=20
>an interface
>> > >/ AP attached to it with the queried L2 id? This should be
>> > >defined.
>> > >
>> > >4.5 Piggybacking
>> > >----------------
>> > >
>> > >In appendix B.2, there is a note that it may not be=20
>necessary to use
>> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
>> > >since the CARD messages convey all the necessary information. This
>> > >seems to make the piggybacking of CARD on top of the PrRt messages
>> > >irrevelant. Is there some reason to do it, which is just=20
>missing from
>> > >the text?
>> > >
>> > >If not, this section should be removed and the messages should be
>> > >carried on top of UDP as in AR-AR case.
>> > >
>> > >
>> > >4.6 CARD protocol security
>> > >---------------------------
>> > >
>> > >You should move everything about IPSec ESP here and=20
>indicate clearly
>> > >how it should be used. Now the text about its use is=20
>scattered around
>> > >section 4. Perhaps the security section should be renamed=20
>"Protection
>> > >of CARD messages" to make a clear distinction between the
>> > >implementation of the protection versus the analysis in section 6.
>> > >
>> > >The section should say that IPSec ESP MUST be used with a non-null
>> > >integrity protection and origin authentication algorithm=20
>and SHOULD be
>> > >used with a non-null encryption algorithm for protecting the
>> > >confidentiality of the CARD information. Definition of=20
>the SPD entries
>> > >would also be nice.
>> > >
>> > >5. Protocol messages
>> > >--------------------
>> > >
>> > >Is 8 bits enough for the CARD option length field? This=20
>translates to
>> > >255 octets, which seems limiting to me, especially since the
>> > >capabilities have not been defined. Also the AVP encoding rules in
>> > >5.1.4 have a 16-bit length field, which conlicts with the=20
>fact that
>> > >they still need to fit within the options with 8-bit=20
>length fields.
>> > >
>> > >AR - AR message format in 5.2.2 includes a length field which is
>> > >redundant with UDP's length field and should be removed.
>> > >
>> > >7. Protocol constants
>> > >----------------------
>> > >
>> > >Where are their values defined?
>> > >
>> > >
>> > >Editorial comments
>> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > >
>> > >General
>> > >--------
>> > >
>> > >The term SHALL was used in the section 4 for use of IPSec
>> > >ESP. However, in sections 5 and 6 the word SHOULD was used
>> > >instead. The use of "SHALL" was new to me so I checked its meaning
>> > >from RFC 2119. According to the RFC its use is: "MUST  =20
>This word, or
>> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
>> > >absolute requirement of the specification."
>> > >
>> > >This should be fixed.  If capabilities such as pricing=20
>information are
>> > >transferred between ARs and MNs, I would opt for use of=20
>SHALL/MUST for
>> > >the authentication requirement. Also the card=20
>requirements draft uses
>> > >the word MUST for authentication and SHOULD for encryption.
>> > >
>> > >4.3.2 Candidate Access Router Operation
>> > >---------------------------------------
>> > >
>> > >Last sentence: "The CAR SHALL use IPsec ESP for=20
>authentication _or_
>> > >optionally encryption of the AR-AR CARD Reply message."
>> > >
>> > >Shouldn't the "or" be "and" instead? The encryption=20
>algorithms for ESP
>> > >do not provide integrity protection and should not be used without
>> > >an authentication & integrity protection algorithm.
>> > >
>> > >4.4.1 MN-AR Signaling Failure
>> > >-----------------------------
>> > >
>> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after=20
>sending a MN-AR
>> > >  CARD Request message with the given sequence number."
>> > >
>> > >Shouldn't it be the MN, which starts the timer instead of AR?
>> > >
>> > >
>> > >5.1.1 CARD Main Header Format
>> > >-----------------------------
>> > >
>> > >"Encapsulating Security Payload (ESP) Header:
>> > > The sender SHOULD include the Encapsulating
>> > > Security Payload (ESP) Header, based on the
>> > >         previously established Security Association
>> > >         between the sender and the receiver."
>> > >
>> > >Shouldn't this SHOULD be MUST intead?
>> > >
>> > >5.2.1 Protocol Transport
>> > >------------------------
>> > >
>> > >"To authenticate protocol messages between ARs, the IPsec=20
>ESP SHOULD
>> > >    be used [10]."
>> > >
>> > >Again, SHOULD vs. MUST/SHALL.
>> > >
>> > >6.1 Assumptions
>> > >---------------
>> > >Second paragraph, last sentence:
>> > >
>> > >"The appendices of this draft describe procedures for=20
>discovering the
>> > >identities of the geographically ARs and APs and relevant security
>> > >considerations."
>> > >
>> > >There seems to be a word missing after "geographically". Adjacent?
>> > >
>> > >6.2 Security Association between AR and AR
>> > >-------------------------------------------
>> > >
>> > >"To prevent the information from being compromised, the CARD REPLY
>> > >  messages between ARs SHOULD be authenticated. The=20
>messages also MAY
>> > >  be encrypted for privacy of the information."
>> > >
>> > >Again SHOULD vs. MUST/SHALL.
>> > >
>> > >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 SHOULD authenticate the CARD REPLY
>> > >messages from the AR."
>> > >
>> > >Again SHOULD vs. MUST/SHALL.
>> > >
>> > >6.4 DoS Attack
>> > >--------------
>> > >
>> > >Should it be mentioned here that authenticating CARD requests is
>> > >needed to allow ARs to protect themselves against CARD request
>> > >flooding with spoofed addresses?
>> > >
>> > >(Authenticating the requests makes DoS less likely as the=20
>attacker's
>> > >identity is revealed and her account can be disabled, etc.)
>> > >
>> > >The meaning of the second paragraph is not clear to me. How can an
>> > >attacker masquerade as an AR, if all entities in the protocol are
>> > >authenticated? It seems to me that this would be possible=20
>only if an
>> > >AR is compromised. Should the protocol be secure also against
>> > >compromised routers?  This should be specified in the assumptions
>> > >section.
>> > >
>> > >
>> > >Appendix A.
>> > >----------
>> > >
>> > >The appendixes form quite a large part of the draft. A.1 and A.2
>> > >should be either integrated into the main draft as=20
>optional parts or
>> > >be separated into their own drafts.
>> > >
>> > >A.1.4.1 Security Associations
>> > >
>> > >More details are needed on how IPSec ESP is used.
>> > >
>> > >A.2
>> > >
>> > >What does pAR send to current AR to verify that it had or=20
>did not have
>> > >state for MN?
>> > >
>> > >
>> > >A.2.4
>> > >
>> > >"should" vs MUST be protected with IPSec ESP.
>> > >
>> > >Appendix B.
>> > >----------
>> > >
>> > >B.1 should be removed, since it is not needed for=20
>implementation of the
>> > >protocol. The draft is self explanatory enough to be used with
>> > >IEEE 802.11 WLANs without this appendix.
>> > >
>> > >B.2 raises the question, whether there is a need for an=20
>"architecture"
>> > >draft instead, which describes how CARD and FMIPv6 or=20
>CARD and CTP can
>> > >be used together.
>> > >
>> > >
>> > >
>> > >_______________________________________________
>> > >Seamoby mailing list
>> > >Seamoby@ietf.org
>> > >https://www1.ietf.org/mailman/listinfo/seamoby
>> >
>> > _________________________________________________________________
>> > Protect your PC - get McAfee.com VirusScan Online
>> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>> >
>>
>> ----------------------------------
>> Henrik Petander
>> Helsinki University of Technology,
>> GO/Core Project
>> Henrik.Petander@hut.fi
>> Office: +358 (0)9 451 5846
>> GSM: +358 (0)40 741 5248
>> ----------------------------------
>>
>>
>> _______________________________________________
>> 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  Thu Jul 17 04:40:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23146
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 04:40: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 19d4JA-0005ag-Qr
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 04:40:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8eCCv021483
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 04:40:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d4J9-0005aQ-II
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:40: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 EAA23129
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 04:40:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d4J6-0003HE-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 04:40:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d4J0-0003HB-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 04:40:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d4J1-0005Zc-11; Thu, 17 Jul 2003 04:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d4Ih-0005Yj-2S
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 04:39: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 EAA23119
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 04:39:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d4Ie-0003Gw-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 04:39:40 -0400
Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d4IT-0003G6-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 04:39:29 -0400
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id LAA02586
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 11:37:52 +0300
X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to <lpetande@morphine.tml.hut.fi> using -f
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma002572; Thu, 17 Jul 03 11:37:30 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (Postfix) with ESMTP
	id 4444818C1D5; Thu, 17 Jul 2003 11:37:30 +0300 (EEST)
Received: from tml.hut.fi (localhost [127.0.0.1])
	by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h6H8bTF5019654;
	Thu, 17 Jul 2003 11:37:29 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h6H8bTT0019651;
	Thu, 17 Jul 2003 11:37:29 +0300 (EEST)
Date: Thu, 17 Jul 2003 11:37:29 +0300 (EEST)
From: Henrik Petander <lpetande@morphine.tml.hut.fi>
To: Dirk.Trossen@nokia.com
Cc: eunsooyo@hotmail.com, <hchaskar@hotmail.com>, <seamoby@ietf.org>
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
In-Reply-To: <DC504E9C3384054C8506D3E6BB012460011CC750@bsebe001.americas.nokia.com>
Message-ID: <Pine.GSO.4.44.0307171047280.19430-100000@morphine.tml.hut.fi>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi Dirk,

On Thu, 17 Jul 2003 Dirk.Trossen@nokia.com wrote:

> Hi Henrik,
>
> I must strongly agree with Eunsoo here. The reason to tranfer the
> retransmission functionality to the AR is a matter of failure handling
> and air bandwidth reduction.

I will clarify further my view on this. The main source for protocol
failures should in properly designed networks be the air interface.
Failure of the wired part of the access network should be a rare
occurrence and the over the air bandwidth reduction achieved with AR doing
resending should therefore be marginal. In the end this is a tradeoff
between a IMO marginal optimization and reducing the complexity of the
protocol. It would make sense to me to simplify the protocol by removing
the per-session state in AR and having the resending responsibility solely
in MN.

>
> However, Hemant's proposal of MAY for the AR implementing
> retransmission, could be one way to go in order to remove the issue,
> even though I would prefer a SHOULD in this place.

MAY would fit well with the other optional features which benefit from the
per-session state in AR, i.e. filtering of capabilities. I would prefer
either MAY or removing the feature.

Henrik

>
> Dirk
>
> >-----Original Message-----
> >From: ext Eunsoo Shim [mailto:eunsooyo@hotmail.com]
> >Sent: Wednesday, July 16, 2003 1:52 PM
> >To: Henrik Petander; Hemant Chaskar
> >Cc: seamoby@ietf.org
> >Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
> >
> >
> >Hi, Henrik,
> >
> >I think it is preferable to reduce any traffic on the air from
> >the MN. So if
> >the retransmission by AR can reduce the over-the-air traffic,
> >the cost can
> >be worthwhile unless it is too big. I am not sure maintaining
> >a state per
> >request to check reply is too much complex in this case.
> >
> >Eunsoo
> >
> >----- Original Message -----
> >From: "Henrik Petander" <lpetande@morphine.tml.hut.fi>
> >To: "Hemant Chaskar" <hchaskar@hotmail.com>
> >Cc: <seamoby@ietf.org>
> >Sent: Tuesday, July 15, 2003 6:16 AM
> >Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
> >
> >
> >> Hi Hemant,
> >>
> >> On Mon, 14 Jul 2003, Hemant Chaskar wrote:
> >>
> >> > Hi Henrik,
> >> >
> >> > Clarification on your comment on per-session state: It is
> >not clear to
> >us
> >> > why AR-AR resending requires any additional MN-specific
> >state in AR. For
> >> > AR-AR interface, in each AR there would be one outgoing
> >queue of queries
> >and
> >> > one incoming queue of replies. Replies will be matched to
> >requests and
> >> > retransmissions will be done if needed. An implementation specific
> >window
> >> > (>= 1) could be defined for this similar to ARQ. Do you
> >agree with this
> >or
> >> > we are missing something from your comment.
> >>
> >> Let me clarify my view of the per-session state and the
> >tradeoffs of using
> >> it. The queue is one way of implementing the per-session
> >state, since you
> >> add a new entry to the outgoing queue every time you get a
> >request from
> >> MN.  You need to manage the queue and specify maximum size
> >for it. When
> >> the queue becomes full you need to drop some requests,
> >causing MNs to do
> >> resending. If there is no per-session state, this is not a problem.
> >>
> >> IMO removal of the per-session state in AR would make the
> >protocol simpler
> >> and would reduce its requirements for the memory capacity of
> >the router
> >> without compromising its reliability and probably with no
> >real negative
> >> effect on its performance.  Making the protocol lighter for
> >the AR seems
> >> to me worth MN doing resending in case of problems in the
> >access network,
> >> which should be rare. Reducing the state in AR would further
> >reduce the
> >> probability of problems ;-)
> >>
> >> Henrik
> >>
> >> >
> >> > Hemant
> >> >
> >> >
> >> > >
> >> > >Removal of per-session state from ARs
> >> > >-------------------------------------
> >> > >
> >> > >The responsiblity for resends for MN initiated sessions is both in
> >> > >the MN and the current AR. Since the weakest link in the
> >protocol from
> >a
> >> > >reliability POV is probably the air interface, the AR-AR
> >resending in
> >> > >the MN initiated sessions is probably not worth the extra
> >complexity.
> >> > >
> >> > >Removing it would simplify AR a lot, since it would not need to
> >maintain
> >> > >any state for CARD in addition to the CAR table. An AR without
> >per-session
> >> > >state would be less vulnerable to DoS attacks and would also
> >> > >scale better.
> >> > >
> >> > >(The preferences and requirements should then be appended
> >also to the
> >> > >current AR - CAR messages, if the current AR lacks
> >knowledge of the
> >> > >capabilities of CARs.)
> >> > >
> >> > >4. CARD PROTOCOL OPERATION
> >> > >--------------------------
> >> > >
> >> > >Is there a specific reason to use the rate limiting flag
> >instead of
> >> > >normal ICMP rate limiting ?
> >> > >
> >> > >Anyways, the rate limiting mechanism, which MN uses after
> >getting a
> >> > >reply with R-bit set, should be defined. There exist a number of
> >> > >already defined mechanisms for dealing with resending
> >intervals and
> >> > >rate limiting. Why not use one of them?
> >> > >
> >> > >
> >> > >
> >> > >4.1 Data structures
> >> > >-------------------
> >> > >
> >> > >Should there be a recommendation for MN to cache the
> >information about
> >> > >CARs ?  MN needs a CAR table with cached answers from CARD
> >> > >replies to avoid asking the same information repeatedly,
> >and for being
> >> > >able to react to movement as quickly as possible.
> >> > >
> >> > >
> >> > >4.2.2 Current access router operation
> >> > >-------------------------------------
> >> > >
> >> > >If you use IPSec ESP for protecting CARD between MN and
> >AR, you cannot
> >> > >send multicast CARD replies. IPSec security associations
> >are between
> >> > >two hosts.
> >> > >
> >> > >You need to protect the CARD replies in some other way
> >(for example
> >> > >with signatures as proposed in the CARD problem statement
> >draft), or
> >> > >always send them as unicast packets.
> >> > >
> >> > >4.3.1 Current access router operation
> >> > >-------------------------------------
> >> > >
> >> > >Is it necessary to include the capabilities of current AR in
> >> > >AR-AR CARD request message?
> >> > >
> >> > >If the data in a current AR for a CAR is not up to date,
> >it still does
> >> > >not mean that the data for the current AR is not up to date in the
> >> > >CAR. Including the AR-AR CARD reply automatically in the
> >CARD request
> >> > >creates unnecessary load in both routers when they authenticate /
> >> > >encrypt extra data.
> >> > >
> >> > >This optimization also adds extra complexity to the
> >protocol, and it is
> >> > >not clear to me whether it is worth it.
> >> > >
> >> > >4.4. CARD Signaling Failure Recovery
> >> > >------------------------------------
> >> > >
> >> > >The draft does not define what an AR sends to MN, when it cannot
> >> > >resolve a L2 address into an IP address. This should be specified
> >> > >clearly.
> >> > >
> >> > >4.4.2 AR-AR signaling failure
> >> > >-----------------------------
> >> > >
> >> > >What does the CAR send to current AR, if it does not have
> >an interface
> >> > >/ AP attached to it with the queried L2 id? This should be
> >> > >defined.
> >> > >
> >> > >4.5 Piggybacking
> >> > >----------------
> >> > >
> >> > >In appendix B.2, there is a note that it may not be
> >necessary to use
> >> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> >> > >since the CARD messages convey all the necessary information. This
> >> > >seems to make the piggybacking of CARD on top of the PrRt messages
> >> > >irrevelant. Is there some reason to do it, which is just
> >missing from
> >> > >the text?
> >> > >
> >> > >If not, this section should be removed and the messages should be
> >> > >carried on top of UDP as in AR-AR case.
> >> > >
> >> > >
> >> > >4.6 CARD protocol security
> >> > >---------------------------
> >> > >
> >> > >You should move everything about IPSec ESP here and
> >indicate clearly
> >> > >how it should be used. Now the text about its use is
> >scattered around
> >> > >section 4. Perhaps the security section should be renamed
> >"Protection
> >> > >of CARD messages" to make a clear distinction between the
> >> > >implementation of the protection versus the analysis in section 6.
> >> > >
> >> > >The section should say that 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. Definition of
> >the SPD entries
> >> > >would also be nice.
> >> > >
> >> > >5. Protocol messages
> >> > >--------------------
> >> > >
> >> > >Is 8 bits enough for the CARD option length field? This
> >translates to
> >> > >255 octets, which seems limiting to me, especially since the
> >> > >capabilities have not been defined. Also the AVP encoding rules in
> >> > >5.1.4 have a 16-bit length field, which conlicts with the
> >fact that
> >> > >they still need to fit within the options with 8-bit
> >length fields.
> >> > >
> >> > >AR - AR message format in 5.2.2 includes a length field which is
> >> > >redundant with UDP's length field and should be removed.
> >> > >
> >> > >7. Protocol constants
> >> > >----------------------
> >> > >
> >> > >Where are their values defined?
> >> > >
> >> > >
> >> > >Editorial comments
> >> > >==================
> >> > >
> >> > >General
> >> > >--------
> >> > >
> >> > >The term SHALL was used in the section 4 for use of IPSec
> >> > >ESP. However, in sections 5 and 6 the word SHOULD was used
> >> > >instead. The use of "SHALL" was new to me so I checked its meaning
> >> > >from RFC 2119. According to the RFC its use is: "MUST
> >This word, or
> >> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
> >> > >absolute requirement of the specification."
> >> > >
> >> > >This should be fixed.  If capabilities such as pricing
> >information are
> >> > >transferred between ARs and MNs, I would opt for use of
> >SHALL/MUST for
> >> > >the authentication requirement. Also the card
> >requirements draft uses
> >> > >the word MUST for authentication and SHOULD for encryption.
> >> > >
> >> > >4.3.2 Candidate Access Router Operation
> >> > >---------------------------------------
> >> > >
> >> > >Last sentence: "The CAR SHALL use IPsec ESP for
> >authentication _or_
> >> > >optionally encryption of the AR-AR CARD Reply message."
> >> > >
> >> > >Shouldn't the "or" be "and" instead? The encryption
> >algorithms for ESP
> >> > >do not provide integrity protection and should not be used without
> >> > >an authentication & integrity protection algorithm.
> >> > >
> >> > >4.4.1 MN-AR Signaling Failure
> >> > >-----------------------------
> >> > >
> >> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after
> >sending a MN-AR
> >> > >  CARD Request message with the given sequence number."
> >> > >
> >> > >Shouldn't it be the MN, which starts the timer instead of AR?
> >> > >
> >> > >
> >> > >5.1.1 CARD Main Header Format
> >> > >-----------------------------
> >> > >
> >> > >"Encapsulating Security Payload (ESP) Header:
> >> > > The sender SHOULD include the Encapsulating
> >> > > Security Payload (ESP) Header, based on the
> >> > >         previously established Security Association
> >> > >         between the sender and the receiver."
> >> > >
> >> > >Shouldn't this SHOULD be MUST intead?
> >> > >
> >> > >5.2.1 Protocol Transport
> >> > >------------------------
> >> > >
> >> > >"To authenticate protocol messages between ARs, the IPsec
> >ESP SHOULD
> >> > >    be used [10]."
> >> > >
> >> > >Again, SHOULD vs. MUST/SHALL.
> >> > >
> >> > >6.1 Assumptions
> >> > >---------------
> >> > >Second paragraph, last sentence:
> >> > >
> >> > >"The appendices of this draft describe procedures for
> >discovering the
> >> > >identities of the geographically ARs and APs and relevant security
> >> > >considerations."
> >> > >
> >> > >There seems to be a word missing after "geographically". Adjacent?
> >> > >
> >> > >6.2 Security Association between AR and AR
> >> > >-------------------------------------------
> >> > >
> >> > >"To prevent the information from being compromised, the CARD REPLY
> >> > >  messages between ARs SHOULD be authenticated. The
> >messages also MAY
> >> > >  be encrypted for privacy of the information."
> >> > >
> >> > >Again SHOULD vs. MUST/SHALL.
> >> > >
> >> > >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 SHOULD authenticate the CARD REPLY
> >> > >messages from the AR."
> >> > >
> >> > >Again SHOULD vs. MUST/SHALL.
> >> > >
> >> > >6.4 DoS Attack
> >> > >--------------
> >> > >
> >> > >Should it be mentioned here that authenticating CARD requests is
> >> > >needed to allow ARs to protect themselves against CARD request
> >> > >flooding with spoofed addresses?
> >> > >
> >> > >(Authenticating the requests makes DoS less likely as the
> >attacker's
> >> > >identity is revealed and her account can be disabled, etc.)
> >> > >
> >> > >The meaning of the second paragraph is not clear to me. How can an
> >> > >attacker masquerade as an AR, if all entities in the protocol are
> >> > >authenticated? It seems to me that this would be possible
> >only if an
> >> > >AR is compromised. Should the protocol be secure also against
> >> > >compromised routers?  This should be specified in the assumptions
> >> > >section.
> >> > >
> >> > >
> >> > >Appendix A.
> >> > >----------
> >> > >
> >> > >The appendixes form quite a large part of the draft. A.1 and A.2
> >> > >should be either integrated into the main draft as
> >optional parts or
> >> > >be separated into their own drafts.
> >> > >
> >> > >A.1.4.1 Security Associations
> >> > >
> >> > >More details are needed on how IPSec ESP is used.
> >> > >
> >> > >A.2
> >> > >
> >> > >What does pAR send to current AR to verify that it had or
> >did not have
> >> > >state for MN?
> >> > >
> >> > >
> >> > >A.2.4
> >> > >
> >> > >"should" vs MUST be protected with IPSec ESP.
> >> > >
> >> > >Appendix B.
> >> > >----------
> >> > >
> >> > >B.1 should be removed, since it is not needed for
> >implementation of the
> >> > >protocol. The draft is self explanatory enough to be used with
> >> > >IEEE 802.11 WLANs without this appendix.
> >> > >
> >> > >B.2 raises the question, whether there is a need for an
> >"architecture"
> >> > >draft instead, which describes how CARD and FMIPv6 or
> >CARD and CTP can
> >> > >be used together.
> >> > >
> >> > >
> >> > >
> >> > >_______________________________________________
> >> > >Seamoby mailing list
> >> > >Seamoby@ietf.org
> >> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >> >
> >> > _________________________________________________________________
> >> > Protect your PC - get McAfee.com VirusScan Online
> >> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >> >
> >>
> >> ----------------------------------
> >> Henrik Petander
> >> Helsinki University of Technology,
> >> GO/Core Project
> >> Henrik.Petander@hut.fi
> >> Office: +358 (0)9 451 5846
> >> GSM: +358 (0)40 741 5248
> >> ----------------------------------
> >>
> >>
> >> _______________________________________________
> >> 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
>

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 07:58:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01999
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 07:58: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 19d7Ok-00042V-KR
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 07:58:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HBwAx1015526
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 07:58:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d7Ok-00042L-GK
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 07:58: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 HAA01974
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 07:58:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d7Oj-0005Um-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 07:58:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19d7Od-0005Uj-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 07:58:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d7Ob-00040x-3q; Thu, 17 Jul 2003 07:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19d7Hh-0003hK-1P
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 07: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 HAA01744
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 07:50:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d7Hg-0005QH-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 07:50:52 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19d7HU-0005PD-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 07:50:40 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6HBmUVI043214;
	Thu, 17 Jul 2003 13:48:30 +0200 (CEST)
Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30)
	id 43D42B83BF; Thu, 17 Jul 2003 13:29:35 +0200 (CEST)
Cc: eunsooyo@hotmail.com, hchaskar@hotmail.com, seamoby@ietf.org,
        Dirk.Trossen@nokia.com
X-Accept-Language: de, en
X-Priority: 3 (Normal)
X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45
references: <Pine.GSO.4.44.0307171047280.19430-100000@morphine.tml.hut.fi>
From: "Marco Liebsch" <liebsch@ccrle.nec.de>
MIME-Version: 1.0
subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
To: "Henrik Petander" <lpetande@morphine.tml.hut.fi>
content-type: text/plain; charset="iso-8859-1"
date:  Thu, 17 Jul 2003 13:29:35 +0200
content-transfer-encoding: 7bit
Message-Id: <20030717112935.43D42B83BF@venus.office>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I also agree to make it MAY and would not like to see it out of the
document. It's experimental and might be implementaed to study whether
or not there is any benefit. However, with regard to the argument
to implement inter-AR signaling failure recovery to not rely on 
MN-AR recovery via air-link and mainly save scarce radio bandwidth,
this works only in case the inter-AR
timeout is much less than the MN-AR timeout, right?

marco


> Hi Dirk,
> 
> On Thu, 17 Jul 2003 Dirk.Trossen@nokia.com wrote:
> 
> > Hi Henrik,
> >
> > I must strongly agree with Eunsoo here. The reason to tranfer the
> > retransmission functionality to the AR is a matter of failure handling
> > and air bandwidth reduction.
> 
> I will clarify further my view on this. The main source for protocol
> failures should in properly designed networks be the air interface.
> Failure of the wired part of the access network should be a rare
> occurrence and the over the air bandwidth reduction achieved with AR doing
> resending should therefore be marginal. In the end this is a tradeoff
> between a IMO marginal optimization and reducing the complexity of the
> protocol. It would make sense to me to simplify the protocol by removing
> the per-session state in AR and having the resending responsibility solely
> in MN.
> 
> >
> > However, Hemant's proposal of MAY for the AR implementing
> > retransmission, could be one way to go in order to remove the issue,
> > even though I would prefer a SHOULD in this place.
> 
> MAY would fit well with the other optional features which benefit from the
> per-session state in AR, i.e. filtering of capabilities. I would prefer
> either MAY or removing the feature.
> 
> Henrik
> 
> >
> > Dirk
> >
> > >-----Original Message-----
> > >From: ext Eunsoo Shim [mailto:eunsooyo@hotmail.com]
> > >Sent: Wednesday, July 16, 2003 1:52 PM
> > >To: Henrik Petander; Hemant Chaskar
> > >Cc: seamoby@ietf.org
> > >Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
> > >
> > >
> > >Hi, Henrik,
> > >
> > >I think it is preferable to reduce any traffic on the air from
> > >the MN. So if
> > >the retransmission by AR can reduce the over-the-air traffic,
> > >the cost can
> > >be worthwhile unless it is too big. I am not sure maintaining
> > >a state per
> > >request to check reply is too much complex in this case.
> > >
> > >Eunsoo
> > >
> > >----- Original Message -----
> > >From: "Henrik Petander" <lpetande@morphine.tml.hut.fi>
> > >To: "Hemant Chaskar" <hchaskar@hotmail.com>
> > >Cc: <seamoby@ietf.org>
> > >Sent: Tuesday, July 15, 2003 6:16 AM
> > >Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
> > >
> > >
> > >> Hi Hemant,
> > >>
> > >> On Mon, 14 Jul 2003, Hemant Chaskar wrote:
> > >>
> > >> > Hi Henrik,
> > >> >
> > >> > Clarification on your comment on per-session state: It is
> > >not clear to
> > >us
> > >> > why AR-AR resending requires any additional MN-specific
> > >state in AR. For
> > >> > AR-AR interface, in each AR there would be one outgoing
> > >queue of queries
> > >and
> > >> > one incoming queue of replies. Replies will be matched to
> > >requests and
> > >> > retransmissions will be done if needed. An implementation specific
> > >window
> > >> > (>= 1) could be defined for this similar to ARQ. Do you
> > >agree with this
> > >or
> > >> > we are missing something from your comment.
> > >>
> > >> Let me clarify my view of the per-session state and the
> > >tradeoffs of using
> > >> it. The queue is one way of implementing the per-session
> > >state, since you
> > >> add a new entry to the outgoing queue every time you get a
> > >request from
> > >> MN.  You need to manage the queue and specify maximum size
> > >for it. When
> > >> the queue becomes full you need to drop some requests,
> > >causing MNs to do
> > >> resending. If there is no per-session state, this is not a problem.
> > >>
> > >> IMO removal of the per-session state in AR would make the
> > >protocol simpler
> > >> and would reduce its requirements for the memory capacity of
> > >the router
> > >> without compromising its reliability and probably with no
> > >real negative
> > >> effect on its performance.  Making the protocol lighter for
> > >the AR seems
> > >> to me worth MN doing resending in case of problems in the
> > >access network,
> > >> which should be rare. Reducing the state in AR would further
> > >reduce the
> > >> probability of problems ;-)
> > >>
> > >> Henrik
> > >>
> > >> >
> > >> > Hemant
> > >> >
> > >> >
> > >> > >
> > >> > >Removal of per-session state from ARs
> > >> > >-------------------------------------
> > >> > >
> > >> > >The responsiblity for resends for MN initiated sessions is both in
> > >> > >the MN and the current AR. Since the weakest link in the
> > >protocol from
> > >a
> > >> > >reliability POV is probably the air interface, the AR-AR
> > >resending in
> > >> > >the MN initiated sessions is probably not worth the extra
> > >complexity.
> > >> > >
> > >> > >Removing it would simplify AR a lot, since it would not need to
> > >maintain
> > >> > >any state for CARD in addition to the CAR table. An AR without
> > >per-session
> > >> > >state would be less vulnerable to DoS attacks and would also
> > >> > >scale better.
> > >> > >
> > >> > >(The preferences and requirements should then be appended
> > >also to the
> > >> > >current AR - CAR messages, if the current AR lacks
> > >knowledge of the
> > >> > >capabilities of CARs.)
> > >> > >
> > >> > >4. CARD PROTOCOL OPERATION
> > >> > >--------------------------
> > >> > >
> > >> > >Is there a specific reason to use the rate limiting flag
> > >instead of
> > >> > >normal ICMP rate limiting ?
> > >> > >
> > >> > >Anyways, the rate limiting mechanism, which MN uses after
> > >getting a
> > >> > >reply with R-bit set, should be defined. There exist a number of
> > >> > >already defined mechanisms for dealing with resending
> > >intervals and
> > >> > >rate limiting. Why not use one of them?
> > >> > >
> > >> > >
> > >> > >
> > >> > >4.1 Data structures
> > >> > >-------------------
> > >> > >
> > >> > >Should there be a recommendation for MN to cache the
> > >information about
> > >> > >CARs ?  MN needs a CAR table with cached answers from CARD
> > >> > >replies to avoid asking the same information repeatedly,
> > >and for being
> > >> > >able to react to movement as quickly as possible.
> > >> > >
> > >> > >
> > >> > >4.2.2 Current access router operation
> > >> > >-------------------------------------
> > >> > >
> > >> > >If you use IPSec ESP for protecting CARD between MN and
> > >AR, you cannot
> > >> > >send multicast CARD replies. IPSec security associations
> > >are between
> > >> > >two hosts.
> > >> > >
> > >> > >You need to protect the CARD replies in some other way
> > >(for example
> > >> > >with signatures as proposed in the CARD problem statement
> > >draft), or
> > >> > >always send them as unicast packets.
> > >> > >
> > >> > >4.3.1 Current access router operation
> > >> > >-------------------------------------
> > >> > >
> > >> > >Is it necessary to include the capabilities of current AR in
> > >> > >AR-AR CARD request message?
> > >> > >
> > >> > >If the data in a current AR for a CAR is not up to date,
> > >it still does
> > >> > >not mean that the data for the current AR is not up to date in the
> > >> > >CAR. Including the AR-AR CARD reply automatically in the
> > >CARD request
> > >> > >creates unnecessary load in both routers when they authenticate /
> > >> > >encrypt extra data.
> > >> > >
> > >> > >This optimization also adds extra complexity to the
> > >protocol, and it is
> > >> > >not clear to me whether it is worth it.
> > >> > >
> > >> > >4.4. CARD Signaling Failure Recovery
> > >> > >------------------------------------
> > >> > >
> > >> > >The draft does not define what an AR sends to MN, when it cannot
> > >> > >resolve a L2 address into an IP address. This should be specified
> > >> > >clearly.
> > >> > >
> > >> > >4.4.2 AR-AR signaling failure
> > >> > >-----------------------------
> > >> > >
> > >> > >What does the CAR send to current AR, if it does not have
> > >an interface
> > >> > >/ AP attached to it with the queried L2 id? This should be
> > >> > >defined.
> > >> > >
> > >> > >4.5 Piggybacking
> > >> > >----------------
> > >> > >
> > >> > >In appendix B.2, there is a note that it may not be
> > >necessary to use
> > >> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> > >> > >since the CARD messages convey all the necessary information. This
> > >> > >seems to make the piggybacking of CARD on top of the PrRt messages
> > >> > >irrevelant. Is there some reason to do it, which is just
> > >missing from
> > >> > >the text?
> > >> > >
> > >> > >If not, this section should be removed and the messages should be
> > >> > >carried on top of UDP as in AR-AR case.
> > >> > >
> > >> > >
> > >> > >4.6 CARD protocol security
> > >> > >---------------------------
> > >> > >
> > >> > >You should move everything about IPSec ESP here and
> > >indicate clearly
> > >> > >how it should be used. Now the text about its use is
> > >scattered around
> > >> > >section 4. Perhaps the security section should be renamed
> > >"Protection
> > >> > >of CARD messages" to make a clear distinction between the
> > >> > >implementation of the protection versus the analysis in section 6.
> > >> > >
> > >> > >The section should say that 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. Definition of
> > >the SPD entries
> > >> > >would also be nice.
> > >> > >
> > >> > >5. Protocol messages
> > >> > >--------------------
> > >> > >
> > >> > >Is 8 bits enough for the CARD option length field? This
> > >translates to
> > >> > >255 octets, which seems limiting to me, especially since the
> > >> > >capabilities have not been defined. Also the AVP encoding rules in
> > >> > >5.1.4 have a 16-bit length field, which conlicts with the
> > >fact that
> > >> > >they still need to fit within the options with 8-bit
> > >length fields.
> > >> > >
> > >> > >AR - AR message format in 5.2.2 includes a length field which is
> > >> > >redundant with UDP's length field and should be removed.
> > >> > >
> > >> > >7. Protocol constants
> > >> > >----------------------
> > >> > >
> > >> > >Where are their values defined?
> > >> > >
> > >> > >
> > >> > >Editorial comments
> > >> > >==================
> > >> > >
> > >> > >General
> > >> > >--------
> > >> > >
> > >> > >The term SHALL was used in the section 4 for use of IPSec
> > >> > >ESP. However, in sections 5 and 6 the word SHOULD was used
> > >> > >instead. The use of "SHALL" was new to me so I checked its meaning
> > >> > >from RFC 2119. According to the RFC its use is: "MUST
> > >This word, or
> > >> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
> > >> > >absolute requirement of the specification."
> > >> > >
> > >> > >This should be fixed.  If capabilities such as pricing
> > >information are
> > >> > >transferred between ARs and MNs, I would opt for use of
> > >SHALL/MUST for
> > >> > >the authentication requirement. Also the card
> > >requirements draft uses
> > >> > >the word MUST for authentication and SHOULD for encryption.
> > >> > >
> > >> > >4.3.2 Candidate Access Router Operation
> > >> > >---------------------------------------
> > >> > >
> > >> > >Last sentence: "The CAR SHALL use IPsec ESP for
> > >authentication _or_
> > >> > >optionally encryption of the AR-AR CARD Reply message."
> > >> > >
> > >> > >Shouldn't the "or" be "and" instead? The encryption
> > >algorithms for ESP
> > >> > >do not provide integrity protection and should not be used without
> > >> > >an authentication & integrity protection algorithm.
> > >> > >
> > >> > >4.4.1 MN-AR Signaling Failure
> > >> > >-----------------------------
> > >> > >
> > >> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after
> > >sending a MN-AR
> > >> > >  CARD Request message with the given sequence number."
> > >> > >
> > >> > >Shouldn't it be the MN, which starts the timer instead of AR?
> > >> > >
> > >> > >
> > >> > >5.1.1 CARD Main Header Format
> > >> > >-----------------------------
> > >> > >
> > >> > >"Encapsulating Security Payload (ESP) Header:
> > >> > > The sender SHOULD include the Encapsulating
> > >> > > Security Payload (ESP) Header, based on the
> > >> > >         previously established Security Association
> > >> > >         between the sender and the receiver."
> > >> > >
> > >> > >Shouldn't this SHOULD be MUST intead?
> > >> > >
> > >> > >5.2.1 Protocol Transport
> > >> > >------------------------
> > >> > >
> > >> > >"To authenticate protocol messages between ARs, the IPsec
> > >ESP SHOULD
> > >> > >    be used [10]."
> > >> > >
> > >> > >Again, SHOULD vs. MUST/SHALL.
> > >> > >
> > >> > >6.1 Assumptions
> > >> > >---------------
> > >> > >Second paragraph, last sentence:
> > >> > >
> > >> > >"The appendices of this draft describe procedures for
> > >discovering the
> > >> > >identities of the geographically ARs and APs and relevant security
> > >> > >considerations."
> > >> > >
> > >> > >There seems to be a word missing after "geographically". Adjacent?
> > >> > >
> > >> > >6.2 Security Association between AR and AR
> > >> > >-------------------------------------------
> > >> > >
> > >> > >"To prevent the information from being compromised, the CARD REPLY
> > >> > >  messages between ARs SHOULD be authenticated. The
> > >messages also MAY
> > >> > >  be encrypted for privacy of the information."
> > >> > >
> > >> > >Again SHOULD vs. MUST/SHALL.
> > >> > >
> > >> > >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 SHOULD authenticate the CARD REPLY
> > >> > >messages from the AR."
> > >> > >
> > >> > >Again SHOULD vs. MUST/SHALL.
> > >> > >
> > >> > >6.4 DoS Attack
> > >> > >--------------
> > >> > >
> > >> > >Should it be mentioned here that authenticating CARD requests is
> > >> > >needed to allow ARs to protect themselves against CARD request
> > >> > >flooding with spoofed addresses?
> > >> > >
> > >> > >(Authenticating the requests makes DoS less likely as the
> > >attacker's
> > >> > >identity is revealed and her account can be disabled, etc.)
> > >> > >
> > >> > >The meaning of the second paragraph is not clear to me. How can an
> > >> > >attacker masquerade as an AR, if all entities in the protocol are
> > >> > >authenticated? It seems to me that this would be possible
> > >only if an
> > >> > >AR is compromised. Should the protocol be secure also against
> > >> > >compromised routers?  This should be specified in the assumptions
> > >> > >section.
> > >> > >
> > >> > >
> > >> > >Appendix A.
> > >> > >----------
> > >> > >
> > >> > >The appendixes form quite a large part of the draft. A.1 and A.2
> > >> > >should be either integrated into the main draft as
> > >optional parts or
> > >> > >be separated into their own drafts.
> > >> > >
> > >> > >A.1.4.1 Security Associations
> > >> > >
> > >> > >More details are needed on how IPSec ESP is used.
> > >> > >
> > >> > >A.2
> > >> > >
> > >> > >What does pAR send to current AR to verify that it had or
> > >did not have
> > >> > >state for MN?
> > >> > >
> > >> > >
> > >> > >A.2.4
> > >> > >
> > >> > >"should" vs MUST be protected with IPSec ESP.
> > >> > >
> > >> > >Appendix B.
> > >> > >----------
> > >> > >
> > >> > >B.1 should be removed, since it is not needed for
> > >implementation of the
> > >> > >protocol. The draft is self explanatory enough to be used with
> > >> > >IEEE 802.11 WLANs without this appendix.
> > >> > >
> > >> > >B.2 raises the question, whether there is a need for an
> > >"architecture"
> > >> > >draft instead, which describes how CARD and FMIPv6 or
> > >CARD and CTP can
> > >> > >be used together.
> > >> > >
> > >> > >
> > >> > >
> > >> > >_______________________________________________
> > >> > >Seamoby mailing list
> > >> > >Seamoby@ietf.org
> > >> > >https://www1.ietf.org/mailman/listinfo/seamoby
> > >> >
> > >> > _________________________________________________________________
> > >> > Protect your PC - get McAfee.com VirusScan Online
> > >> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > >> >
> > >>
> > >> ----------------------------------
> > >> Henrik Petander
> > >> Helsinki University of Technology,
> > >> GO/Core Project
> > >> Henrik.Petander@hut.fi
> > >> Office: +358 (0)9 451 5846
> > >> GSM: +358 (0)40 741 5248
> > >> ----------------------------------
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> >
> 
> 		----------------------------------
> 		Henrik Petander
> 		Helsinki University of Technology,
> 		GO/Core Project
> 		Henrik.Petander@hut.fi
> 		Office: +358 (0)9 451 5846
> 		GSM: +358 (0)40 741 5248
> 		----------------------------------
> 
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> 
-- 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 11:09:00 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 LAA10971
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 11:09:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dAN0-0007G5-LT
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 11:08:35 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HF8Y1D027897
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 11:08:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dAN0-0007Fs-II
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 11:08:34 -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 LAA10926
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 11:08: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 19dAMT-00079v-D6; Thu, 17 Jul 2003 11:08:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dAME-00077Q-O4
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 11:07:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10889
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 11:07:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dAMC-00074A-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 11:07:44 -0400
Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dAM1-00072p-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 11:07:33 -0400
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id SAA15243
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 18:04:53 +0300
X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to <lpetande@morphine.tml.hut.fi> using -f
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma015218; Thu, 17 Jul 03 18:04:45 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (Postfix) with ESMTP
	id 98EFE18C1D5; Thu, 17 Jul 2003 18:04:41 +0300 (EEST)
Received: from tml.hut.fi (localhost [127.0.0.1])
	by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h6HF4fF5020996;
	Thu, 17 Jul 2003 18:04:41 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h6HF4bU0020993;
	Thu, 17 Jul 2003 18:04:37 +0300 (EEST)
Date: Thu, 17 Jul 2003 18:04:37 +0300 (EEST)
From: Henrik Petander <lpetande@morphine.tml.hut.fi>
To: Marco Liebsch <liebsch@ccrle.nec.de>
Cc: eunsooyo@hotmail.com, <hchaskar@hotmail.com>, <seamoby@ietf.org>,
        <Dirk.Trossen@nokia.com>
Subject: RE: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt
In-Reply-To: <20030717112935.43D42B83BF@venus.office>
Message-ID: <Pine.GSO.4.44.0307171800480.20980-100000@morphine.tml.hut.fi>
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

On Thu, 17 Jul 2003, Marco Liebsch wrote:

> I also agree to make it MAY and would not like to see it out of the
> document. It's experimental and might be implementaed to study whether
> or not there is any benefit.

Yes, I agree with this argument, since the draft is going to experimental
RFC status.

> However, with regard to the argument
> to implement inter-AR signaling failure recovery to not rely on
> MN-AR recovery via air-link and mainly save scarce radio bandwidth,
> this works only in case the inter-AR
> timeout is much less than the MN-AR timeout, right?

Yes, the inter AR timeout should be smaller than the MN - AR timeout. You
should also decide whether to declare the signaling as a failure to MN.

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 14:07:00 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 OAA15895
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 14:07:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dD9G-0008FA-5U
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:06:34 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HI6YBq031682
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:06:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dD9G-0008Ev-2o
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:06:34 -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 OAA15878
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 14: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 19dD8k-00087u-EF; Thu, 17 Jul 2003 14: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 19dD8N-00087F-4a
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 14:05: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 OAA15832
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 14:05:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dD8K-0000Lz-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:05: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 19dD89-0000LW-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:05:26 -0400
Message-ID: <042d01c34c8d$dd9d9e60$566015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Date: Thu, 17 Jul 2003 20:04:26 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Minutes and Presentations from IETF 57
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

..are at http://www.geocities.com/kempf42/seamoby-57.zip

            jak

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 14:23: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 OAA16611
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 14:23:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDPJ-0000xw-76
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:23:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HIN9NS003706
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:23:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDPJ-0000xh-38
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:23: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 OAA16581
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 14:23:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDPG-0000T7-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 14:23:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDPB-0000T4-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 14:23:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDPB-0000ux-Up; Thu, 17 Jul 2003 14: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 19dDOz-0000si-E2
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 14:22:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16576
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 14:22:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDOx-0000T0-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:22:47 -0400
Received: from mail.bstormnetworks.com ([209.11.156.50] helo=bsn-mail-01.bstormnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDOm-0000RQ-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:22:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Jul 2003 11:18:31 -0700
Message-ID: <40301581B2962B448690A023EF16DFE1DC5236@bsn-mail-01.bstormnetworks.com>
Thread-Topic: slides please
Thread-Index: AcNMj9NxZ1kIFraZRaSrQMCwVVXVeA==
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: <seamoby@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] slides please
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

anyone with slides, send them my way.

PatC

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 17 14: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 OAA17538
	for <seamoby-archive@odin.ietf.org>; Thu, 17 Jul 2003 14:51:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDqP-0002Th-KM
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:51:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HIp9Lr009520
	for seamoby-archive@odin.ietf.org; Thu, 17 Jul 2003 14:51:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDqO-0002RQ-4O
	for seamoby-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:51: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 OAA17528
	for <seamoby-web-archive@ietf.org>; Thu, 17 Jul 2003 14:51:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDqL-0000fW-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 14:51:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDqF-0000fT-00
	for seamoby-web-archive@ietf.org; Thu, 17 Jul 2003 14:50:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dDqH-0002Ql-AN; Thu, 17 Jul 2003 14: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 19dDpU-0002QE-Vr
	for seamoby@optimus.ietf.org; Thu, 17 Jul 2003 14:50:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17522
	for <seamoby@ietf.org>; Thu, 17 Jul 2003 14:50:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dDpP-0000fF-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:50: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 19dDpE-0000fB-00
	for seamoby@ietf.org; Thu, 17 Jul 2003 14:49:56 -0400
Message-ID: <04a301c34c94$3ad95be0$566015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: <seamoby@ietf.org>
Cc: <mankin@psg.com>
Date: Thu, 17 Jul 2003 20:49:59 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_049E_01C34CA4.FCF81490"
Subject: [Seamoby] Semaoby Meeting Summary
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_049E_01C34CA4.FCF81490
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The IESG is requesting a summary of WG meetings for their own use and as a
record for the WG. Attached is the summary for the meeting at IETF 57.

            jak

------=_NextPart_000_049E_01C34CA4.FCF81490
Content-Type: text/plain;
	name="iesg-summary.txt"
Content-Disposition: attachment;
	filename="iesg-summary.txt"
Content-Transfer-Encoding: quoted-printable

IETF 57 Seamoby Meeting Summary=0A=
=0A=
Decisions=0A=
---------=0A=
=0A=
D1: Drop draft-ietf-seamoby-ct-reqs-05.txt, =
draft-ietf-seamoby-cardiscovery-issues-04.txt, =
draft-ietf-seamoby-card-requirements-02.txt as WG drafts.=0A=
=0A=
D2: Add WG chairs notice to draft-ietf-seamoby-card-protocol-02.txt =
concerning complexity and the need for experimentation.=0A=
=0A=
D3: Complete WG last call for draft-ietf-seamoby-ctp-03.txt and =
draft-ietf-seamoby-card-protocol-02.txt by mid-October and submit to =
IESG for consideration of publication as Experimental.=0A=
=0A=
D4: Design decisions on draft-ietf-seamoby-card-protocol-02.txt, to be =
confirmed on the list. See meeting minutes for details.=0A=
=0A=
Action Items=0A=
------------=0A=
=0A=
A1: Resolve remaining issues for draft-ietf-seamoby-card-protocol-02.txt =
on the list, incorporate into a new version of the draft, and release to =
the drafts editor.=0A=
    Owners: Marco Liebsch and Ajoy Singh=0A=
    Target Date: End of September=0A=
=0A=
A2: Resolve remaining issues for draft-ietf-seamoby-ctp-03.txt on the =
list, incorporate into a new version of the draft, and release to the =
the drafts editor.=0A=
    Owner: John Loughny=0A=
    Target Date: End of September=0A=
=0A=
A3: Work with ROHC chair to resolve any outstanding technical issues =
with draft-koodli-hc-relocate-02.txt, issue new version of draft for =
consideration as WG draft.=0A=
    Owner: Rajeev Koodli and Manish Tiwari=0A=
    Target Date: End of September=0A=
=0A=
A3: Issue WG Last Call and send draft-ietf-seamoby-ctp-03.txt and =
draft-ietf-seamoby-card-protocol-02.txt to IESG.=0A=
    Owners: Chairs=0A=
    Target Date: Middle of October=0A=
=0A=
A4: Discuss and reach concensus on whether to make =
draft-koodli-hc-relocate-02.txt a WG draft, and on content.=0A=
    Owners: Chairs=0A=
    Target Date: Middle of October=0A=
=0A=
Charter Milestone Review=0A=
------------------------=0A=
=0A=
C1: Drop the following milestones:=0A=
=0A=
    Sep 01    Candidate Mode Host Alerting Protocol Protocols are =
submitted, with accompanying comparison against requirements.  =0A=
    Oct 01    Submit Handoff Discovery Requirements I-D to IESG for =
consideration as Informational  =0A=
=0A=
=0A=
C2: Modify the following milestones:=0A=
=0A=
    Feb 02    Inter Access Point Context Transfer Protocol to IESG for =
consideration as a Proposed Standard =0A=
=0A=
    change to:=0A=
    =0A=
    Oct 03    Context Transfer Protocol submitted to the IESG for =
consideration of publication as Experimental=0A=
 =0A=
    Feb 02    Handoff Discovery Protocol to IESG for consideration as a =
Proposed Standard =0A=
=0A=
    change to:=0A=
=0A=
    Oct 03    Candidate Access Router Discovery protocol submitted to =
the IESG for consideration of publication as Experimental =0A=
=0A=
Charter Review=0A=
--------------=0A=
=0A=
R1: The charter is considerably out of date, but it is questionable if =
it is worthwhile to update it considering this was the last WG meeting.=0A=
=0A=

------=_NextPart_000_049E_01C34CA4.FCF81490--


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 02:22:47 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 CAA18537
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 02:22:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOdI-0003Jx-9N
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 02:22:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I6MKl7012747
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 02:22:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOdH-0003JW-Cq
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 02:22: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 CAA18521
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 02:22:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOdD-0005H7-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 02:22:15 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOd7-0005Gv-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 02:22:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOd0-0003I7-53; Fri, 18 Jul 2003 02:22:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOcM-0003G7-DC
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 02:21: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 CAA18475
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 02:21:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOcI-0005GQ-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 02:21:18 -0400
Received: from mail.bstormnetworks.com ([209.11.156.50] helo=bsn-mail-01.bstormnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOc8-0005Fv-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 02:21:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Jul 2003 23:21:00 -0700
Message-ID: <40301581B2962B448690A023EF16DFE1DC5241@bsn-mail-01.bstormnetworks.com>
Thread-Topic: (virtual) hum on CARD open issues
Thread-Index: AcNMcKH6bH0CWEU0QD+b491xUdGoaQAg/BvU
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: <seamoby@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] Opinions on unresolved CARD issues
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Below are the issues that we were unable to get some resolution at the =
meeting in Vienna. Please send your comments on the following two =
issues:

1. Issue #23: Protection of broadcast unsolicited CARD reply messages. A =
broadcast unsolicted CARD reply message cannot be protected with IPSec, =
so how are the SAs established? Similar problem to Router =
Advertisements. If we leave broadcast/multicast to be determined (see =
issue #6) then this does not need to be solved right now. There is no WG =
consensus at this time - we need to take this to the list. comments =
please.

2. Issue #40: 8 bit CARD option length not enough. The proposal is to =
extend the length of the field to 16 bit. There is no consensus, and =
this needs to be taken to the list. comments?

Thanks,

Pat & James


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 03:12: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 CAA18538
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 02:22:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOdI-0003Jw-9C
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 02:22:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I6MKW0012748
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 02:22:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOdH-0003JR-7T
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 02:22: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 CAA18518
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 02:22:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOdD-0005HA-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 02:22:15 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOd7-0005Gw-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 02:22:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dOcz-0003Hz-HL; Fri, 18 Jul 2003 02: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 19dOcH-0003Fx-AK
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 02:21: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 CAA18457
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 02:21:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOcD-0005GJ-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 02:21:13 -0400
Received: from mail.bstormnetworks.com ([209.11.156.50] helo=bsn-mail-01.bstormnetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dOc2-0005Fv-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 02:21:02 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Jul 2003 23:19:34 -0700
Message-ID: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com>
Thread-Topic: (virtual) hum on CARD open issues
Thread-Index: AcNMcKH6bH0CWEU0QD+b491xUdGoaQAg4F/W
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: <seamoby@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [Seamoby] (virtual) hum on CARD open 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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Following today's meeeting in Vienna, we've been able to get consensus =
on most issues. However, we need to get consensus on the mailing list. =
Please send your opinion to both myself and James on each of the issues =
below (in a single e-mail, please), and I will tabulate the responses =
and send a resume to the list.

1. Issue #2: R-flag for CARD Request rate limiting. What to do about =
potential Dos issues? WG consensus is to Keep the R-flag approach. =
Meeting consensus is to add clarifying text to section 4.2 (4.3?)

2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? =
Meeting consensus is to keep the current text for CARD protocol =
operation with FMIPv6.

3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The =
editor recommends the use of ICMP to make it consistent with the mobile =
interface. Potential downsides: ICMP has potential security =
implications. ICMP message types on binding is also very implementation =
specific. Also, securing ICMP would require that all ICMP packets be =
secured. Meeting consensus is to keep UDP.

4. Issue #5: Static vs. dynamic capability attributes. The editor =
recommends that we keep the S-bit and use the 32-bit lifetime only when =
really required for dynamic capabilities. This saves bandwidth, but does =
complicate processing. Meeting consensus is to keep S-bit.

5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. =
Proposal by the editor is to use broadcast for IPv4 and multicast for =
IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links =
can generate heavy traffic. James Kempf proposes that we drop this for =
now as we enter experimental. Alternative proposal is to mimic router =
advertisements, send when changes occur and send when new mobile shows =
up. Meeting consensus is to add a statement in the document that we =
considered multicast and leave it for future.=20

6. Issue #12: Link Layer triggers for unsolicited CARD reply. Proposal =
is to remove the text that deals with layer 2 triggers. Meeting =
consensus is to remove text.

7. Issue #7. Preferences/Requirements sub-option. We should only use one =
of the two methods. Meeting consensus is to keep both the sub-option and =
the preference.

8. Issue #18. Requesting ARs to perform ONLY reverse address =
translation. This is an essential feature for the MN to indicate reverse =
translation. Ultimately, this could become obsolete since the Proxy =
message does this too. Meeting consensus is to specify a R-flag in the =
CARD request message.

9. Issue #25: Addressing of unicast CARD protocol messages. Should we =
use global or link local addresses? Meeting consensus is that since =
MN-AR is always on a single hop, use keep link local addresses.

10. Issue #36: Removal of per-session state from ARs. Meeting consensus =
is to keep signalling failure recovery on AR-AR interface, but make it =
optional (MAY).=20

11. Issue #39: Further detail of signalling failure recovery required. =
Meeting consensus is that if the MN is not able to resolve an L2 ID, put =
an error code or some flag.

12. Issue #17: Separate appendix from the CARD protocol specification. =
The appendix is very large which describes many options. James Kempf =
believes that the appendix really needs to be shortened down to 2 pages, =
describing the two solutions - these are items that need to be resolved =
during the experimental phase. Meeting consensus is to take the appendix =
to 2 pages.


Thanks,

Pat & James

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 09:58:38 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 JAA00449
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 09:58:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dVkR-0007KH-03
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 09:58:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IDwATk028155
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 09:58:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dVkQ-0007K2-ND
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 09:58: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 JAA00417
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 09:58:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dVkO-000197-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 09:58:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dVkJ-000194-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 09:58:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dVkI-0007Id-Hy; Fri, 18 Jul 2003 09:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dVji-0007Hl-Cy
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 09:57: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 JAA00396
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 09:57:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dVjf-00018m-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 09:57:23 -0400
Received: from [133.11.236.3] (helo=saffron.mlab.t.u-tokyo.ac.jp)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dVjU-00018I-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 09:57:12 -0400
Received: from saffron.mlab.t.u-tokyo.ac.jp (unknown [127.0.0.1])
	by localhost (Postfix) with ESMTP id A3B652CE9DA
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 22:56:20 +0900 (JST)
Received: from MORI-T40.mlab.t.u-tokyo.ac.jp (unknown [133.11.236.3])
	by saffron.mlab.t.u-tokyo.ac.jp (Postfix) with ESMTP id 56A3B2CE9DC
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 22:56:18 +0900 (JST)
Message-Id: <5.1.1.9.2.20030718225604.04364968@localhost>
X-Sender: mori@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4
Date: Fri, 18 Jul 2003 22:56:06 +0900
To: seamoby@ietf.org
From: Hiroyuki Morikawa <mori@mlab.t.u-tokyo.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] MobiCom 2003 Call for Posters, Demos, and Exhibits
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


ACM MobiCom 2003, the Ninth Annual International Conference on Mobile
Computing and Networking, will be held September 14-19, 2003, in
beautiful, sunny San Diego, California.  MobiCom is the premier
international forum focusing on all areas of mobile computing and
mobile and wireless networking at the link layer and above.  Technical
paper submission and selection for MobiCom 2003 is now complete, but
it is not too late to present your work at the conference.  MobiCom
2003 solicits posters for the Student Poster Session, as well as
research demonstrations and product or service exhibits that showcase
the state-of-the-art in mobile computing and networking systems.

STUDENT POSTER SESSION

MobiCom 2003 solicits student posters that present recent and on-going
research by students on mobile computing and mobile and wireless
networking topics.  Presenting a poster at MobiCom is a great chance
for students to obtain interesting and valuable feedback on their
on-going work from a knowledgeable crowd at the conference.

Poster proposals should be a maximum of 2 pages in length.  Although
posters don't need to describe completed work, the work should be
advanced beyond the initial stages.  The primary author of all poster
submissions must be a student.  Poster abstracts will not be published
in the conference Proceedings but will be published on the web before
the conference.  Poster submissions will be reviewed.  Authors of
accepted papers at the conference must not submit a poster of the work
presented in that paper.

For more information on the MobiCom 2003 Student Poster Session and
for detailed submission instructions, please see the Student Poster
Session web page at

    http://www.sigmobile.org/mobicom/2003/posters.html

The deadline for submitting a student poster is July 31, 2003.
We will select approximately 20 of the most interesting and
thought-provoking posters by August 18, 2003 and notify the contact
author of each poster then.  For questions about the MobiCom 2003
Student Poster Session or the poster submission and review process,
please contact the Student Poster Session Co-Chairs Nigel Davies
<nigel@comp.lancs.ac.uk> and James Kempf <kempf@docomolabs-usa.com>.

DEMOS AND EXHIBITS

If you are implementing a ground-breaking system in your research that
you would like to demonstrate for your peers, please submit a proposal
of no more than 3 pages to the Research Demo Chair, David Maltz
<dmaltz+demo@cs.cmu.edu>, by July 25, 2003.

Demo proposals should include a description of the demo, the equipment
to be used, the demo layout and space required to set up the demo, and
possible interactions (interoperability or interference) with other
proposed demonstrations.  The basic facilities available will be those
typical of a hotel meeting room: power, table space, and poster
easels.  100Base-T and 802.11 network connections may be arranged if
required.  For more information on submitting MobiCom 2003 demos,
please see the Demos and Exhibits web page

    http://www.sigmobile.org/mobicom/2003/demos.html

We are also planning an Expo at MobiCom 2003 featuring exhibits of the
latest mobile computing products and services.  If you are interested
in exhibiting your product or service at MobiCom 2003, please see the
Demos and Exhibits page of the MobiCom 2003 website for more
information.  Please also check our Corporate Supporters page for
information on how to support the conference and receive a free Expo
booth, web promotion, and complimentary registration for the
conference.


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 12:07: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 MAA04587
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 12:07:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dXlK-00040Z-3g
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 12:07:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IG7E7L015400
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 12:07:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dXlK-00040H-0Q
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 12:07: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 MAA04567
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 12:07:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dXlI-0001sE-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 12:07:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dXlD-0001sB-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 12:07:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dXl7-0003uU-9J; Fri, 18 Jul 2003 12: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 19dXkV-0003r9-82
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 12:06: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 MAA04554
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 12:06:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dXkU-0001ru-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 12:06:22 -0400
Received: from bay2-f111.bay2.hotmail.com ([65.54.247.111] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dXkI-0001ro-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 12:06:11 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 18 Jul 2003 09:05:18 -0700
Received: from 65.211.103.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Fri, 18 Jul 2003 16:05:17 GMT
X-Originating-IP: [65.211.103.2]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: pcalhoun@airespace.com, seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Fri, 18 Jul 2003 16:05:17 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F111Ef8CNJHdWO00019316@hotmail.com>
X-OriginalArrivalTime: 18 Jul 2003 16:05:18.0071 (UTC) FILETIME=[61D20870:01C34D46]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

My consensus vote inline - Hemant

>From: "Pat R. Calhoun" <pcalhoun@airespace.com>
>To: <seamoby@ietf.org>
>Subject: [Seamoby] (virtual) hum on CARD open issues
>Date: Thu, 17 Jul 2003 23:19:34 -0700
>
>Following today's meeeting in Vienna, we've been able to get consensus on 
>most issues. However, we need to get consensus on the mailing list. Please 
>send your opinion to both myself and James on each of the issues below (in 
>a single e-mail, please), and I will tabulate the responses and send a 
>resume to the list.
>
>1. Issue #2: R-flag for CARD Request rate limiting. What to do about 
>potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting 
>consensus is to add clarifying text to section 4.2 (4.3?)

Agree.

>
>2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting 
>consensus is to keep the current text for CARD protocol operation with 
>FMIPv6.

Agree.

>
>3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor 
>recommends the use of ICMP to make it consistent with the mobile interface. 
>Potential downsides: ICMP has potential security implications. ICMP message 
>types on binding is also very implementation specific. Also, securing ICMP 
>would require that all ICMP packets be secured. Meeting consensus is to 
>keep UDP.

Agree.

>
>4. Issue #5: Static vs. dynamic capability attributes. The editor 
>recommends that we keep the S-bit and use the 32-bit lifetime only when 
>really required for dynamic capabilities. This saves bandwidth, but does 
>complicate processing. Meeting consensus is to keep S-bit.

Agree.

>
>5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal 
>by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an 
>unsolicited CARD reply unicast. Broadcast on wireless links can generate 
>heavy traffic. James Kempf proposes that we drop this for now as we enter 
>experimental. Alternative proposal is to mimic router advertisements, send 
>when changes occur and send when new mobile shows up. Meeting consensus is 
>to add a statement in the document that we considered multicast and leave 
>it for future.

Neutral.

>
>6. Issue #12: Link Layer triggers for unsolicited CARD reply. Proposal is 
>to remove the text that deals with layer 2 triggers. Meeting consensus is 
>to remove text.

Agree.

>
>7. Issue #7. Preferences/Requirements sub-option. We should only use one of 
>the two methods. Meeting consensus is to keep both the sub-option and the 
>preference.

Agree.

>
>8. Issue #18. Requesting ARs to perform ONLY reverse address translation. 
>This is an essential feature for the MN to indicate reverse translation. 
>Ultimately, this could become obsolete since the Proxy message does this 
>too. Meeting consensus is to specify a R-flag in the CARD request message.

Neutral.

>
>9. Issue #25: Addressing of unicast CARD protocol messages. Should we use 
>global or link local addresses? Meeting consensus is that since MN-AR is 
>always on a single hop, use keep link local addresses.

Neutral.

>
>10. Issue #36: Removal of per-session state from ARs. Meeting consensus is 
>to keep signalling failure recovery on AR-AR interface, but make it 
>optional (MAY).

Agree.

>
>11. Issue #39: Further detail of signalling failure recovery required. 
>Meeting consensus is that if the MN is not able to resolve an L2 ID, put an 
>error code or some flag.

Agree.

>
>12. Issue #17: Separate appendix from the CARD protocol specification. The 
>appendix is very large which describes many options. James Kempf believes 
>that the appendix really needs to be shortened down to 2 pages, describing 
>the two solutions - these are items that need to be resolved during the 
>experimental phase. Meeting consensus is to take the appendix to 2 pages.

Agree.

>
>
>Thanks,
>
>Pat & James
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 14:16: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 OAA07163
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 14:16:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dZlV-00088t-JV
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 14:15:33 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IIFX84031293
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 14:15:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dZlV-00088e-GF
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 14:15: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 OAA07131
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 14:15:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dZkz-000866-9t; Fri, 18 Jul 2003 14:15:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dZkM-00083d-8I
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 14:14: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 OAA07094
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 14:14:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dZkJ-0002Q1-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 14:14:19 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dZk9-0002Ox-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 14:14:09 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA17594;
	Fri, 18 Jul 2003 11:11:42 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6IIBfL03970;
	Fri, 18 Jul 2003 11:11:41 -0700
X-mProtect: <200307181811> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd7kaE7i; Fri, 18 Jul 2003 11:11:39 PDT
Message-ID: <3F18385C.F1CBAD88@iprg.nokia.com>
Date: Fri, 18 Jul 2003 11:11:40 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com
CC: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

"Pat R. Calhoun" wrote:
> 
> Following today's meeeting in Vienna, we've been able to get consensus on most issues. However, we need to get consensus on the mailing list. Please send your opinion to both myself and James on each of the issues below (in a single e-mail, please), and I will tabulate the responses and send a resume to the list.
> 
> 1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)

this is wrong, IMHO. rate limiting is a well known mechanism.
introducing a new flag is not a bright idea. the MN has to
send one request per second upto a maximum of 3 requests. or
it can exponentially backoff. if the MN sends requests more
frequent than this, they are dropped by the AR. I even sent
some text for this, when I reviewed the CARD protocol.

> 
> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.
> 
> 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.

2 and 3 dont go togetheer. defining CARD messages as ICMP 
options lets you piggyback these options on FMIPv6 messages.
I am not sure how you can achieve piggybacking if the MN-AR
signaling becomes UDP. ICMP was the right choice between
the MN and the AR.

from a recent discussion on the IPsec mailing list, it
looks like we might get the ICMP type as an IPsec selector.
then you would be able to distinguish between different
ICMP messages. ofcourse I dont when it might be 
standardized.

> 
> 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit.

unbelievable. the CARD protocol is already complicated (IMO).
the emphasis should be on reducing the complexity. just use 
a value of infinity for the lifetime field to indicate a 
static capability. any other value for the lifetime indicates 
dynamic capability. I think for the CARD protocol, emphasis
should be on making it a simpler protocol than saving 4 bytes
over the air. :)

if you are concerned about an overhead of 4 bytes, make the 
lifetime field 2 bytes. a 2 byte lifetime field gives you
65536 seconds which should be enough. do you need a 4 byte
lifetime field?

> 
> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links can generate heavy traffic. James Kempf proposes that we drop this for now as we enter experimental. Alternative proposal is to mimic router advertisements, send when changes occur and send when new mobile shows up. Meeting consensus is to add a statement in the document that we considered multicast and leave it for future.

I am not sure I understood. is the unsolicited CARD Reply
message being dropped from the spec, because it cant be
protected?

> 
> 7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

I believe combining these two will go a long way in 
simplifying the CARD protocol. I looked up the meeting
minutes, which said there were no comments on this at
all. I strongly suggest combining the two.

>
> 8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the Proxy message does this too. Meeting consensus is to specify a R-flag in the CARD request message.

great. I like this.

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 15:31: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 PAA10764
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 15:31: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 19dawf-00027s-9Q
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 15:31:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IJV9nB008168
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 15:31:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dawf-00027f-5N
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 15:31: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 PAA10726
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 15:31:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dawd-0002x7-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 15:31:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19dawY-0002x4-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 15:31:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dawX-00026t-Is; Fri, 18 Jul 2003 15:31:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19dawI-00026E-4j
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 15:30:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10668
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 15:30:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19dawG-0002wp-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 15:30:44 -0400
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx with esmtp (Exim 4.12)
	id 19daw5-0002wi-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 15:30:33 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6IJUBBC022420
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 12:30:11 -0700 (MST)
Received: from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h6IJU9F7020792
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 14:30:09 -0500
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <3RHGWP2M>; Fri, 18 Jul 2003 14:30:09 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'Vijay Devarapalli'" <vijayd@iprg.nokia.com>,
        "Pat R. Calhoun"
	 <pcalhoun@airespace.com>, kempf@docomolabs-usa.com
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] (virtual) hum on CARD open issues
Date: Fri, 18 Jul 2003 14:30:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hello Vijay,
Please find my inline comments.
regards,
ajoy

-----Original Message-----
From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]
Sent: Friday, July 18, 2003 1:12 PM
To: Pat R. Calhoun; kempf@docomolabs-usa.com
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


"Pat R. Calhoun" wrote:
> 
> Following today's meeeting in Vienna, we've been able to get consensus on most issues. However, we need to get consensus on the mailing list. Please send your opinion to both myself and James on each of the issues below (in a single e-mail, please), and I will tabulate the responses and send a resume to the list.
> 
> 1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)

this is wrong, IMHO. rate limiting is a well known mechanism.
introducing a new flag is not a bright idea.

ajoy-> Why it is a bad idea?  Well, I am neutral in this 
issue but I am not convinced why using R bit is worse than 
your proposed solution. 

 the MN has to
send one request per second upto a maximum of 3 requests. or
it can exponentially backoff. if the MN sends requests more
frequent than this, they are dropped by the AR. I even sent
some text for this, when I reviewed the CARD protocol.

> 
> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.
> 
> 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.

2 and 3 dont go togetheer. defining CARD messages as ICMP 
options lets you piggyback these options on FMIPv6 messages.
I am not sure how you can achieve piggybacking if the MN-AR
signaling becomes UDP. ICMP was the right choice between
the MN and the AR.


AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP for 
MN-AR and UDP for AR-AR interface. Others' please correct me.
BTW, why are you in favor of 
using ICMP for AR-AR interface? 

from a recent discussion on the IPsec mailing list, it
looks like we might get the ICMP type as an IPsec selector.
then you would be able to distinguish between different
ICMP messages. ofcourse I dont when it might be 
standardized.


> 
> 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit.

unbelievable. the CARD protocol is already complicated (IMO).
the emphasis should be on reducing the complexity. just use 
a value of infinity for the lifetime field to indicate a 
static capability. any other value for the lifetime indicates 
dynamic capability. I think for the CARD protocol, emphasis
should be on making it a simpler protocol than saving 4 bytes
over the air. :)

if you are concerned about an overhead of 4 bytes, make the 
lifetime field 2 bytes. a 2 byte lifetime field gives you
65536 seconds which should be enough. do you need a 4 byte
lifetime field?

AJOY-> I disagree here. Saving even 2 bytes per capability is 
huge saving for bandwidth constraint network. I am not sure 
processing one flag will make CARD protocol any more complicated.
Btw, in cellular standard I have seen even more complicated 
procedure for saving 4 bits per frame. Please note that 
the CARD protocol is being proposed as an experimental 
protocol so we will have opportunity to make such 
changes in future if required. 

> 
> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links can generate heavy traffic. James Kempf proposes that we drop this for now as we enter experimental. Alternative proposal is to mimic router advertisements, send when changes occur and send when new mobile shows up. Meeting consensus is to add a statement in the document that we considered multicast and leave it for future.

I am not sure I understood. is the unsolicited CARD Reply
message being dropped from the spec, because it cant be
protected?

> 
> 7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

I believe combining these two will go a long way in 
simplifying the CARD protocol. I looked up the meeting
minutes, which said there were no comments on this at
all. I strongly suggest combining the two.

>
> 8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the Proxy message does this too. Meeting consensus is to specify a R-flag in the CARD request message.

great. I like this.

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 Jul 18 18:44: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 SAA16962
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 18:44: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 19ddxR-0008K4-15
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 18:44:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IMi9J0031988
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 18:44:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ddxQ-0008Jq-UM
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 18:44: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 SAA16950
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 18:44:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddxN-0004Cl-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 18:44:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddxH-0004Ce-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 18:43:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ddxJ-0008IS-A1; Fri, 18 Jul 2003 18: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 19ddx8-0008IC-Fl
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 18: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 SAA16943
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 18:43:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddx5-0004CY-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 18:43:47 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddwu-0004CF-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 18:43:36 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05248;
	Fri, 18 Jul 2003 15:42:18 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6IMgH008742;
	Fri, 18 Jul 2003 15:42:17 -0700
X-mProtect: <200307182242> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdV67qWe; Fri, 18 Jul 2003 15:42:15 PDT
Message-ID: <3F1877C8.94611F09@iprg.nokia.com>
Date: Fri, 18 Jul 2003 15:42:16 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com> <3F18385C.F1CBAD88@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Vijay Devarapalli wrote:
> 

> > 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.
> >
> > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.
> 
> 2 and 3 dont go togetheer. defining CARD messages as ICMP
> options lets you piggyback these options on FMIPv6 messages.
> I am not sure how you can achieve piggybacking if the MN-AR
> signaling becomes UDP. ICMP was the right choice between
> the MN and the AR.
> 
> from a recent discussion on the IPsec mailing list, it
> looks like we might get the ICMP type as an IPsec selector.
> then you would be able to distinguish between different
> ICMP messages. ofcourse I dont when it might be
> standardized.

Pat, Jim,

I misunderstood (3) to mean use UDP both for MN-AR and 
AR-AR CARD signaling.

but I still disagree with concensus for (3) though. I 
mentioned a couple of reasons in my reply to Ajoy.

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Fri Jul 18 18:44:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16977
	for <seamoby-archive@odin.ietf.org>; Fri, 18 Jul 2003 18:44:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ddxS-0008KN-CX
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 18:44:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IMiA39032005
	for seamoby-archive@odin.ietf.org; Fri, 18 Jul 2003 18:44:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ddxQ-0008Jr-Sg
	for seamoby-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 18:44: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 SAA16949
	for <seamoby-web-archive@ietf.org>; Fri, 18 Jul 2003 18:44:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddxN-0004Cj-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 18:44:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddxH-0004Cf-00
	for seamoby-web-archive@ietf.org; Fri, 18 Jul 2003 18:43:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ddxJ-0008Ia-MO; Fri, 18 Jul 2003 18: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 19ddx8-0008ID-Ic
	for seamoby@optimus.ietf.org; Fri, 18 Jul 2003 18: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 SAA16942
	for <seamoby@ietf.org>; Fri, 18 Jul 2003 18:43:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddx5-0004CX-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 18:43:47 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ddwu-0004Bc-00
	for seamoby@ietf.org; Fri, 18 Jul 2003 18:43:36 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05147;
	Fri, 18 Jul 2003 15:39:14 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6IMdDp06908;
	Fri, 18 Jul 2003 15:39:13 -0700
X-mProtect: <200307182239> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd8BHteT; Fri, 18 Jul 2003 15:39:11 PDT
Message-ID: <3F187710.BDC73048@iprg.nokia.com>
Date: Fri, 18 Jul 2003 15:39:12 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
CC: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Singh Ajoy-ASINGH1 wrote:
> 
> > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)
> 
> this is wrong, IMHO. rate limiting is a well known mechanism.
> introducing a new flag is not a bright idea.
> 
> ajoy-> Why it is a bad idea?  Well, I am neutral in this
> issue but I am not convinced why using R bit is worse than
> your proposed solution.

simple. rate-limiting is implemented in a wide variety of
protocols (infact for any message that creates state at
the receiving node). nothing new here. you dont need a new
mechanism for this.

> > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.
> 
> 2 and 3 dont go togetheer. defining CARD messages as ICMP
> options lets you piggyback these options on FMIPv6 messages.
> I am not sure how you can achieve piggybacking if the MN-AR
> signaling becomes UDP. ICMP was the right choice between
> the MN and the AR.
> 
> AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP for
> MN-AR and UDP for AR-AR interface. Others' please correct me.

oops... I misunderstood. I thought the concensus at the 
meeting was to use UDP for both.

> BTW, why are you in favor of
> using ICMP for AR-AR interface?

otherwise you need seperate code for processing an ICMP
CARD Request (from the MN) and UDP CARD Request (from 
the PAR). also, if it is an ICMP message, I can piggyback
CARD messages on HI/HACK messages of FMIPv6.


> unbelievable. the CARD protocol is already complicated (IMO).
> the emphasis should be on reducing the complexity. just use
> a value of infinity for the lifetime field to indicate a
> static capability. any other value for the lifetime indicates
> dynamic capability. I think for the CARD protocol, emphasis
> should be on making it a simpler protocol than saving 4 bytes
> over the air. :)
> 
> if you are concerned about an overhead of 4 bytes, make the
> lifetime field 2 bytes. a 2 byte lifetime field gives you
> 65536 seconds which should be enough. do you need a 4 byte
> lifetime field?
> 
> AJOY-> I disagree here. Saving even 2 bytes per capability is
> huge saving for bandwidth constraint network. I am not sure
> processing one flag will make CARD protocol any more complicated.
> Btw, in cellular standard I have seen even more complicated
> procedure for saving 4 bits per frame. Please note that
> the CARD protocol is being proposed as an experimental
> protocol so we will have opportunity to make such
> changes in future if required.

but in the current form not many people are going to use 
it. it might remain forever as an experimental, untouched,
ignored, just another RFC.... that is something we should 
avoid. I want a protocol that I can use. :)

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 09:01:47 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 JAA26338
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 09:01:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eaI4-0003p5-D9
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 09:01:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LD1KSg014694
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 09:01:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eaI4-0003ov-8g
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 09:01:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26334
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 09:01:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eaI2-0002fc-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 09:01:18 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19eaHx-0002fX-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 09:01:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eaHk-0003mi-NA; Mon, 21 Jul 2003 09:01:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eaHL-0003m5-Qh
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 09:00: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 JAA26296
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 09:00:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eaHK-0002fQ-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 09:00:34 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eaH9-0002eM-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 09:00:23 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6LCwTVI082585;
	Mon, 21 Jul 2003 14:58:32 +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 C9867B63F6; Mon, 21 Jul 2003 14:38:54 +0200 (CEST)
Message-ID: <3F1BE374.6070409@ccrle.nec.de>
Date: Mon, 21 Jul 2003 14:58:28 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <vijayd@iprg.nokia.com>
Cc: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com> <3F187710.BDC73048@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Vijay,

please see below for comments.
marco

Vijay Devarapalli wrote:

>Singh Ajoy-ASINGH1 wrote:
>  
>
>>>1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)
>>>      
>>>
>>this is wrong, IMHO. rate limiting is a well known mechanism.
>>introducing a new flag is not a bright idea.
>>
>>ajoy-> Why it is a bad idea?  Well, I am neutral in this
>>issue but I am not convinced why using R bit is worse than
>>your proposed solution.
>>    
>>
>
>simple. rate-limiting is implemented in a wide variety of
>protocols (infact for any message that creates state at
>the receiving node). nothing new here. you dont need a new
>mechanism for this.
>  
>
I see your point. However, I don't see a reason why the flag as 
flow-control indicator
should not work. Maybe there is also a benefit from implementation point 
of view on
the MN. In case of having a flag, MN is notified when exceeding the 
request rate. Of course,
AR has to maintain a per-MN state. Furthermore, rules have to be 
specified for MNs
on how to behave when CARD Reply indicates exceeding rate. But from 
implementation point
of view, this does not look very complicated on the MN side. However, 
having a
"n-requests allowed per second"-rule on the MN, this needs to be 
controlled and
implemented on the MN side, which looks like requiring a bit more effort

Alternative proposal was to indicate a maximum rate for a particular AR 
in the
first CARD Reply. This keeps individual request rates flexible and avoids
defining static numbers.

>  
>
>>>3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.
>>>      
>>>
>>2 and 3 dont go togetheer. defining CARD messages as ICMP
>>options lets you piggyback these options on FMIPv6 messages.
>>I am not sure how you can achieve piggybacking if the MN-AR
>>signaling becomes UDP. ICMP was the right choice between
>>the MN and the AR.
>>
>>AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP for
>>MN-AR and UDP for AR-AR interface. Others' please correct me.
>>    
>>
>
>oops... I misunderstood. I thought the concensus at the 
>meeting was to use UDP for both.
>
>  
>
>>BTW, why are you in favor of
>>using ICMP for AR-AR interface?
>>    
>>
>
>otherwise you need seperate code for processing an ICMP
>CARD Request (from the MN) and UDP CARD Request (from 
>the PAR). also, if it is an ICMP message, I can piggyback
>CARD messages on HI/HACK messages of FMIPv6.
>
>
>  
>
>>unbelievable. the CARD protocol is already complicated (IMO).
>>the emphasis should be on reducing the complexity. just use
>>a value of infinity for the lifetime field to indicate a
>>static capability. any other value for the lifetime indicates
>>dynamic capability. I think for the CARD protocol, emphasis
>>should be on making it a simpler protocol than saving 4 bytes
>>over the air. :)
>>
>>if you are concerned about an overhead of 4 bytes, make the
>>lifetime field 2 bytes. a 2 byte lifetime field gives you
>>65536 seconds which should be enough. do you need a 4 byte
>>lifetime field?
>>
>>AJOY-> I disagree here. Saving even 2 bytes per capability is
>>huge saving for bandwidth constraint network. I am not sure
>>processing one flag will make CARD protocol any more complicated.
>>Btw, in cellular standard I have seen even more complicated
>>procedure for saving 4 bits per frame. Please note that
>>the CARD protocol is being proposed as an experimental
>>protocol so we will have opportunity to make such
>>changes in future if required.
>>    
>>
>
>but in the current form not many people are going to use 
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should 
>avoid. I want a protocol that I can use. :)
>  
>
 From complexity and implementation point of view, I don't really 
understand why
the proposed mechanism makes the protocol complex? I don't see
any difference between having a check on the lifetime (==0x00000000?) 
and in case it's
zero assume the capability to be static, and having a check on a 
specific flag (flag == 1?),
indicating a static capability, hence, no lifetime field is present but 
"value" descriptor
follows immediately.
But if there are any further argumements and concerns, we can again 
think about it.

Any other comments?

marco

>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 Jul 21 11:43:38 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 LAA01237
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 11:43:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ecoi-0001bW-QO
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 11:43:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LFhCi0006162
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 11:43:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ecoi-0001bJ-NB
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 11:43: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 LAA01211
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 11:43:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ecoh-0003vV-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 11:43:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ecob-0003vS-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 11: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 19ecoX-0001Zw-Uw; Mon, 21 Jul 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 19ecnu-0001ZI-QN
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 11:42: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 LAA01169
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 11:42:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ecnt-0003ur-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 11:42:21 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ecni-0003uJ-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 11:42:11 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6LFfAVI094208;
	Mon, 21 Jul 2003 17:41:11 +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 AE19F6C315; Mon, 21 Jul 2003 17:21:34 +0200 (CEST)
Message-ID: <3F1C0995.3000507@ccrle.nec.de>
Date: Mon, 21 Jul 2003 17:41:09 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <vijayd@iprg.nokia.com>
Cc: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com> <3F187710.BDC73048@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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Vijay,

please find another comment below.

marco

Vijay Devarapalli wrote:

>Singh Ajoy-ASINGH1 wrote:
>  
>
>>>1. Issue #2: R-flag for CARD Request rate limiting. What to do about potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting consensus is to add clarifying text to section 4.2 (4.3?)
>>>      
>>>
>>this is wrong, IMHO. rate limiting is a well known mechanism.
>>introducing a new flag is not a bright idea.
>>
>>ajoy-> Why it is a bad idea?  Well, I am neutral in this
>>issue but I am not convinced why using R bit is worse than
>>your proposed solution.
>>    
>>
>
>simple. rate-limiting is implemented in a wide variety of
>protocols (infact for any message that creates state at
>the receiving node). nothing new here. you dont need a new
>mechanism for this.
>
>  
>
>>>3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The editor recommends the use of ICMP to make it consistent with the mobile interface. Potential downsides: ICMP has potential security implications. ICMP message types on binding is also very implementation specific. Also, securing ICMP would require that all ICMP packets be secured. Meeting consensus is to keep UDP.
>>>      
>>>
>>2 and 3 dont go togetheer. defining CARD messages as ICMP
>>options lets you piggyback these options on FMIPv6 messages.
>>I am not sure how you can achieve piggybacking if the MN-AR
>>signaling becomes UDP. ICMP was the right choice between
>>the MN and the AR.
>>
>>AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP for
>>MN-AR and UDP for AR-AR interface. Others' please correct me.
>>    
>>
>
>oops... I misunderstood. I thought the concensus at the 
>meeting was to use UDP for both.
>
>  
>
>>BTW, why are you in favor of
>>using ICMP for AR-AR interface?
>>    
>>
>
>otherwise you need seperate code for processing an ICMP
>CARD Request (from the MN) and UDP CARD Request (from 
>the PAR). also, if it is an ICMP message, I can piggyback
>CARD messages on HI/HACK messages of FMIPv6.
>  
>
I see the point and that's why we addressed this issue during the meeting.
According to some feedback (also before the meeting), not everybody sees
a problem with changing transport characteristics between MN-AR
and inter-AR interfaces.
Also not sure if piggybacking of CARD messages with HI/HACK
makes sense, since inter-AR CARD is in most cases required before
FastMIPv6 HI/HACK is performed. And HI/HACK is performed only with
the selected target AR. Of course, current AR could use this sequence
to update its own and target AR's CAR table entries, but I guess this
would make the "one time inter-AR CARD piggybacking, another time
stand-alone inter-AR CARD"-thing much more complicated.
What do you think?




>
>  
>
>>unbelievable. the CARD protocol is already complicated (IMO).
>>the emphasis should be on reducing the complexity. just use
>>a value of infinity for the lifetime field to indicate a
>>static capability. any other value for the lifetime indicates
>>dynamic capability. I think for the CARD protocol, emphasis
>>should be on making it a simpler protocol than saving 4 bytes
>>over the air. :)
>>
>>if you are concerned about an overhead of 4 bytes, make the
>>lifetime field 2 bytes. a 2 byte lifetime field gives you
>>65536 seconds which should be enough. do you need a 4 byte
>>lifetime field?
>>
>>AJOY-> I disagree here. Saving even 2 bytes per capability is
>>huge saving for bandwidth constraint network. I am not sure
>>processing one flag will make CARD protocol any more complicated.
>>Btw, in cellular standard I have seen even more complicated
>>procedure for saving 4 bits per frame. Please note that
>>the CARD protocol is being proposed as an experimental
>>protocol so we will have opportunity to make such
>>changes in future if required.
>>    
>>
>
>but in the current form not many people are going to use 
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should 
>avoid. I want a protocol that I can use. :)
>
>Vijay
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 12:15:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02283
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 12:15:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edJe-00039t-FS
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:15:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGFAkV012138
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:15:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edJe-00039h-9M
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:15: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 MAA02261
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 12:15:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edJc-0004CY-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:15:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edJX-0004CV-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:15:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edJV-00038x-PV; Mon, 21 Jul 2003 12:15:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edIX-00037k-Q8
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 12:14: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 MAA02236
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 12:13:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edIV-0004BI-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:13:59 -0400
Received: from bay2-f152.bay2.hotmail.com ([65.54.247.152] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edIK-0004AN-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:13:48 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 21 Jul 2003 09:12:57 -0700
Received: from 65.211.103.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Mon, 21 Jul 2003 16:12:56 GMT
X-Originating-IP: [65.211.103.2]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: vijayd@iprg.nokia.com, ASINGH1@motorola.com
Cc: pcalhoun@airespace.com, kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 16:12:56 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com>
X-OriginalArrivalTime: 21 Jul 2003 16:12:57.0306 (UTC) FILETIME=[F2C8FBA0:01C34FA2]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Dear Vijay,

Could you provide a text to be included in the draft on rate limiting. We 
can include it in the draft after discussing it over mailing list. It 
probably wont suffice to say that rate limiting is in lot of protocols and 
hence not needed here. Different protocols use different rate limiting. E.g. 
TCP uses rate limiting, but it wont be appropriate for CARD.

If you are proposing to limit the rate by simply enforcing limit on 
aggregate rate of requests, I can easily argue that it is ineffective. So 
the question is: Wheater WG wants per MN rate limiting? If so, does it have 
to be using R flag or using limit on per-MN rate of request? And then, you 
can refer us to protocol that uses that type of rate limiting and we will 
simply refer to it - will save lot of writing.

Hemant


>From: Vijay Devarapalli <vijayd@iprg.nokia.com>
>To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
>CC: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,    
>     seamoby@ietf.org
>Subject: Re: [Seamoby] (virtual) hum on CARD open issues
>Date: Fri, 18 Jul 2003 15:39:12 -0700
>
>Singh Ajoy-ASINGH1 wrote:
> >
> > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about 
>potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting 
>consensus is to add clarifying text to section 4.2 (4.3?)
> >
> > this is wrong, IMHO. rate limiting is a well known mechanism.
> > introducing a new flag is not a bright idea.
> >
> > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > issue but I am not convinced why using R bit is worse than
> > your proposed solution.
>
>simple. rate-limiting is implemented in a wide variety of
>protocols (infact for any message that creates state at
>the receiving node). nothing new here. you dont need a new
>mechanism for this.
>
> > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The 
>editor recommends the use of ICMP to make it consistent with the mobile 
>interface. Potential downsides: ICMP has potential security implications. 
>ICMP message types on binding is also very implementation specific. Also, 
>securing ICMP would require that all ICMP packets be secured. Meeting 
>consensus is to keep UDP.
> >
> > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > options lets you piggyback these options on FMIPv6 messages.
> > I am not sure how you can achieve piggybacking if the MN-AR
> > signaling becomes UDP. ICMP was the right choice between
> > the MN and the AR.
> >
> > AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP 
>for
> > MN-AR and UDP for AR-AR interface. Others' please correct me.
>
>oops... I misunderstood. I thought the concensus at the
>meeting was to use UDP for both.
>
> > BTW, why are you in favor of
> > using ICMP for AR-AR interface?
>
>otherwise you need seperate code for processing an ICMP
>CARD Request (from the MN) and UDP CARD Request (from
>the PAR). also, if it is an ICMP message, I can piggyback
>CARD messages on HI/HACK messages of FMIPv6.
>
>
> > unbelievable. the CARD protocol is already complicated (IMO).
> > the emphasis should be on reducing the complexity. just use
> > a value of infinity for the lifetime field to indicate a
> > static capability. any other value for the lifetime indicates
> > dynamic capability. I think for the CARD protocol, emphasis
> > should be on making it a simpler protocol than saving 4 bytes
> > over the air. :)
> >
> > if you are concerned about an overhead of 4 bytes, make the
> > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > 65536 seconds which should be enough. do you need a 4 byte
> > lifetime field?
> >
> > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > huge saving for bandwidth constraint network. I am not sure
> > processing one flag will make CARD protocol any more complicated.
> > Btw, in cellular standard I have seen even more complicated
> > procedure for saving 4 bits per frame. Please note that
> > the CARD protocol is being proposed as an experimental
> > protocol so we will have opportunity to make such
> > changes in future if required.
>
>but in the current form not many people are going to use
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should
>avoid. I want a protocol that I can use. :)
>
>Vijay
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 12:18:38 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 MAA02357
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 12:18: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 19edMV-0003Je-Ua
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:18:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGI7jB012741
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:18:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edMV-0003JQ-7n
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:18: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 MAA02327
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 12:17:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edLV-0004E2-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:17:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edLQ-0004Dz-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:17:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edLR-0003En-0e; Mon, 21 Jul 2003 12:17:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edKZ-0003CQ-Hu
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 12:16:07 -0400
Received: from mailer.nec-labs.com (mailer.ccrl.nj.nec.com [138.15.108.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02306
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 12:15:58 -0400 (EDT)
Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 21 Jul 2003 12:05:39 -0400
Message-ID: <00d401c34fa2$91c61540$c96b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>,
        "Vijay Devarapalli" <vijayd@iprg.nokia.com>
Cc: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, <kempf@docomolabs-usa.com>,
        <seamoby@ietf.org>
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com> <3F187710.BDC73048@iprg.nokia.com> <3F1BE374.6070409@ccrle.nec.de>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 12:10:14 -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.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 21 Jul 2003 16:05:39.0025 (UTC) FILETIME=[ED8C9C10:01C34FA1]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, Marco and Vijay,

My comments are inline.

-----

> Hi Vijay,
>
> please see below for comments.
> marco
>
> Vijay Devarapalli wrote:
>
> >Singh Ajoy-ASINGH1 wrote:
> >
> >
> >>>1. Issue #2: R-flag for CARD Request rate limiting. What to do about
potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting
consensus is to add clarifying text to section 4.2 (4.3?)
> >>>
> >>>
> >>this is wrong, IMHO. rate limiting is a well known mechanism.
> >>introducing a new flag is not a bright idea.
> >>
> >>ajoy-> Why it is a bad idea?  Well, I am neutral in this
> >>issue but I am not convinced why using R bit is worse than
> >>your proposed solution.
> >>
> >>
> >
> >simple. rate-limiting is implemented in a wide variety of
> >protocols (infact for any message that creates state at
> >the receiving node). nothing new here. you dont need a new
> >mechanism for this.
> >
> >

[eunsoo] Already it was pointed out that the ECN bit of TCP (RFC 3168) was
another example of this kind of flag. So using a flag is not a very new
invention.

We considered specifying a fixed minimum inter-message interval but we did
not like it because of inflexibility. As the MN roams around, it will
encounter ARs with different requrements and thus a fixed value may not
work. So we looked for a dynamic mechanism. One way is having the AR send
the rate information to all the MNs. It is not good in terms of bandwidth
efficiency.

What mechanism are you suggesting, Vijay?

> I see your point. However, I don't see a reason why the flag as
> flow-control indicator
> should not work. Maybe there is also a benefit from implementation point
> of view on
> the MN. In case of having a flag, MN is notified when exceeding the
> request rate. Of course,
> AR has to maintain a per-MN state. Furthermore, rules have to be
> specified for MNs
> on how to behave when CARD Reply indicates exceeding rate. But from
> implementation point
> of view, this does not look very complicated on the MN side. However,
> having a
> "n-requests allowed per second"-rule on the MN, this needs to be
> controlled and
> implemented on the MN side, which looks like requiring a bit more effort
>
> Alternative proposal was to indicate a maximum rate for a particular AR
> in the
> first CARD Reply. This keeps individual request rates flexible and avoids
> defining static numbers.
>
> >
> >
> >>>3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
editor recommends the use of ICMP to make it consistent with the mobile
interface. Potential downsides: ICMP has potential security implications.
ICMP message types on binding is also very implementation specific. Also,
securing ICMP would require that all ICMP packets be secured. Meeting
consensus is to keep UDP.
> >>>
> >>>
> >>2 and 3 dont go togetheer. defining CARD messages as ICMP
> >>options lets you piggyback these options on FMIPv6 messages.
> >>I am not sure how you can achieve piggybacking if the MN-AR
> >>signaling becomes UDP. ICMP was the right choice between
> >>the MN and the AR.
> >>
> >>AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP
for
> >>MN-AR and UDP for AR-AR interface. Others' please correct me.
> >>
> >>
> >
> >oops... I misunderstood. I thought the concensus at the
> >meeting was to use UDP for both.
> >
> >
> >
> >>BTW, why are you in favor of
> >>using ICMP for AR-AR interface?
> >>
> >>
> >
> >otherwise you need seperate code for processing an ICMP
> >CARD Request (from the MN) and UDP CARD Request (from
> >the PAR). also, if it is an ICMP message, I can piggyback
> >CARD messages on HI/HACK messages of FMIPv6.
> >
> >
[eunsoo] There was discussion about this in the meeting. It was pointed out
that it was difficult to protect ICMP messages using IP Sec and thus people
preferred keeing UDP for AR-AR communication. BTW, piggybacking is a good
point. A new IRTF effort started to integrate many mobility management
related protocols such as FMIP, CT and CARD. A good way of integration
should be found.

> >
> >
> >>unbelievable. the CARD protocol is already complicated (IMO).
> >>the emphasis should be on reducing the complexity. just use
> >>a value of infinity for the lifetime field to indicate a
> >>static capability. any other value for the lifetime indicates
> >>dynamic capability. I think for the CARD protocol, emphasis
> >>should be on making it a simpler protocol than saving 4 bytes
> >>over the air. :)
> >>
> >>if you are concerned about an overhead of 4 bytes, make the
> >>lifetime field 2 bytes. a 2 byte lifetime field gives you
> >>65536 seconds which should be enough. do you need a 4 byte
> >>lifetime field?
> >>
> >>AJOY-> I disagree here. Saving even 2 bytes per capability is
> >>huge saving for bandwidth constraint network. I am not sure
> >>processing one flag will make CARD protocol any more complicated.
> >>Btw, in cellular standard I have seen even more complicated
> >>procedure for saving 4 bits per frame. Please note that
> >>the CARD protocol is being proposed as an experimental
> >>protocol so we will have opportunity to make such
> >>changes in future if required.
> >>
> >>
> >
> >but in the current form not many people are going to use
> >it. it might remain forever as an experimental, untouched,
> >ignored, just another RFC.... that is something we should
> >avoid. I want a protocol that I can use. :)
> >
> >
>  From complexity and implementation point of view, I don't really
> understand why
> the proposed mechanism makes the protocol complex? I don't see
> any difference between having a check on the lifetime (==0x00000000?)
> and in case it's
> zero assume the capability to be static, and having a check on a
> specific flag (flag == 1?),
> indicating a static capability, hence, no lifetime field is present but
> "value" descriptor
> follows immediately.

[eunsoo] I don't understand either that the bit is more complex than the
null lifetime. Also the bandwidth overhead of sending null lifetime value
can be significant when multiple (or many) static attributes are contained
in the CARD Reply. Bandwidth efficiency for the air interface is always a
very important requirement. As you know, people are talking about IP head
compression which is much more complex than using a bit to save bandwidth.

Regards,

Eunsoo


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 12:34:52 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 MAA02898
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 12:34:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edcJ-0003lV-DQ
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:34:27 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGYRxR014473
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:34:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edXy-0003cs-Pc
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:34: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 MAA02652
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 12:26:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edUH-0004LE-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:26:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edUB-0004LB-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12: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 19edU9-0003UY-Cl; Mon, 21 Jul 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 19edTC-0003TH-MX
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 12:25:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02574
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 12:24:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edSY-0004JV-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:24:22 -0400
Received: from bay2-f77.bay2.hotmail.com ([65.54.247.77] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edSO-0004Il-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:24:12 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 21 Jul 2003 09:22:55 -0700
Received: from 65.211.103.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Mon, 21 Jul 2003 16:22:55 GMT
X-Originating-IP: [65.211.103.2]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: vijayd@iprg.nokia.com, pcalhoun@airespace.com, kempf@docomolabs-usa.com
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 16:22:55 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F77jIL2jpWkfb80000bc56@hotmail.com>
X-OriginalArrivalTime: 21 Jul 2003 16:22:55.0740 (UTC) FILETIME=[577AC3C0:01C34FA4]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi Vijay,

---------------------------------------------------snip------------------------------------------------------

>unbelievable. the CARD protocol is already complicated (IMO).
>the emphasis should be on reducing the complexity. just use
>a value of infinity for the lifetime field to indicate a
>static capability. any other value for the lifetime indicates
>dynamic capability. I think for the CARD protocol, emphasis
>should be on making it a simpler protocol than saving 4 bytes
>over the air. :)
>
>if you are concerned about an overhead of 4 bytes, make the
>lifetime field 2 bytes. a 2 byte lifetime field gives you
>65536 seconds which should be enough. do you need a 4 byte
>lifetime field?

--------------------------------------------------------------------------------------------------------------------------------

I am netural to this issue. However, IMO reduction of complexity as claimed 
above is mostly unfounded argument. The complexity impact is mostly 
negligible. It wont take much out of the protocol implementation that is 
already so complex as you said.

So let us toss a coin and decide on what to do ;-) and move ahead.

Hemant

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 12:48: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 MAA03293
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 12:48: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 19edpt-0004HS-WC
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:48:30 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGmTdB016453
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:48:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edpt-0004HI-QG
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:48: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 MAA03158
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 12:45:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edmg-0004S4-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:45:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edma-0004S1-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:45:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edmX-000473-Dm; Mon, 21 Jul 2003 12: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 19edlz-00046X-9t
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 12:44:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03130
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 12:44:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edlx-0004RU-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:44:25 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edlm-0004RF-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:44:14 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA20041;
	Mon, 21 Jul 2003 09:43:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6LGhcq12960;
	Mon, 21 Jul 2003 09:43:38 -0700
X-mProtect: <200307211643> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdyb9W6l; Mon, 21 Jul 2003 09:37:26 PDT
Message-ID: <3F1C16C6.330CDA85@iprg.nokia.com>
Date: Mon, 21 Jul 2003 09:37:26 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Hemant Chaskar <hchaskar@hotmail.com>
CC: ASINGH1@motorola.com, pcalhoun@airespace.com, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I already provided the text when I reviewed the CARD protocol.

  The MN MUST send only one CARD Request per 
  CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES. 
  If the MN sends requests more frequently, the AR SHOULD drop the
  CARD requests and not process them.

and add to the constants section

  CARD_RETRANSMISSION_INTERVAL  1 second
  CARD_MAX_RETRIES              3

this is similar to ICMP rate limiting.

TCP rate limiting is different, not applicable here. in general
in any protocol where there is a request and a reply (and no
more messages), ICMP rate limiting is best suited. you dont have
to "source-quench" the Mobile Node. :)

Vijay

Hemant Chaskar wrote:
> 
> Dear Vijay,
> 
> Could you provide a text to be included in the draft on rate limiting. We
> can include it in the draft after discussing it over mailing list. It
> probably wont suffice to say that rate limiting is in lot of protocols and
> hence not needed here. Different protocols use different rate limiting. E.g.
> TCP uses rate limiting, but it wont be appropriate for CARD.
> 
> If you are proposing to limit the rate by simply enforcing limit on
> aggregate rate of requests, I can easily argue that it is ineffective. So
> the question is: Wheater WG wants per MN rate limiting? If so, does it have
> to be using R flag or using limit on per-MN rate of request? And then, you
> can refer us to protocol that uses that type of rate limiting and we will
> simply refer to it - will save lot of writing.
> 
> Hemant
> 
> >From: Vijay Devarapalli <vijayd@iprg.nokia.com>
> >To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
> >CC: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
> >     seamoby@ietf.org
> >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> >Date: Fri, 18 Jul 2003 15:39:12 -0700
> >
> >Singh Ajoy-ASINGH1 wrote:
> > >
> > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about
> >potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting
> >consensus is to add clarifying text to section 4.2 (4.3?)
> > >
> > > this is wrong, IMHO. rate limiting is a well known mechanism.
> > > introducing a new flag is not a bright idea.
> > >
> > > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > > issue but I am not convinced why using R bit is worse than
> > > your proposed solution.
> >
> >simple. rate-limiting is implemented in a wide variety of
> >protocols (infact for any message that creates state at
> >the receiving node). nothing new here. you dont need a new
> >mechanism for this.
> >
> > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
> >editor recommends the use of ICMP to make it consistent with the mobile
> >interface. Potential downsides: ICMP has potential security implications.
> >ICMP message types on binding is also very implementation specific. Also,
> >securing ICMP would require that all ICMP packets be secured. Meeting
> >consensus is to keep UDP.
> > >
> > > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > > options lets you piggyback these options on FMIPv6 messages.
> > > I am not sure how you can achieve piggybacking if the MN-AR
> > > signaling becomes UDP. ICMP was the right choice between
> > > the MN and the AR.
> > >
> > > AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP
> >for
> > > MN-AR and UDP for AR-AR interface. Others' please correct me.
> >
> >oops... I misunderstood. I thought the concensus at the
> >meeting was to use UDP for both.
> >
> > > BTW, why are you in favor of
> > > using ICMP for AR-AR interface?
> >
> >otherwise you need seperate code for processing an ICMP
> >CARD Request (from the MN) and UDP CARD Request (from
> >the PAR). also, if it is an ICMP message, I can piggyback
> >CARD messages on HI/HACK messages of FMIPv6.
> >
> >
> > > unbelievable. the CARD protocol is already complicated (IMO).
> > > the emphasis should be on reducing the complexity. just use
> > > a value of infinity for the lifetime field to indicate a
> > > static capability. any other value for the lifetime indicates
> > > dynamic capability. I think for the CARD protocol, emphasis
> > > should be on making it a simpler protocol than saving 4 bytes
> > > over the air. :)
> > >
> > > if you are concerned about an overhead of 4 bytes, make the
> > > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > > 65536 seconds which should be enough. do you need a 4 byte
> > > lifetime field?
> > >
> > > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > > huge saving for bandwidth constraint network. I am not sure
> > > processing one flag will make CARD protocol any more complicated.
> > > Btw, in cellular standard I have seen even more complicated
> > > procedure for saving 4 bits per frame. Please note that
> > > the CARD protocol is being proposed as an experimental
> > > protocol so we will have opportunity to make such
> > > changes in future if required.
> >
> >but in the current form not many people are going to use
> >it. it might remain forever as an experimental, untouched,
> >ignored, just another RFC.... that is something we should
> >avoid. I want a protocol that I can use. :)
> >
> >Vijay
> >
> >_______________________________________________
> >Seamoby mailing list
> >Seamoby@ietf.org
> >https://www1.ietf.org/mailman/listinfo/seamoby
> 
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 12:58: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 MAA03534
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 12:58:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edyx-0004aI-HX
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:57:51 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LGvp0k017619
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 12:57:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edyX-0004a1-0T
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 12:57: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 MAA03399
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 12:54:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19edvJ-0004Wn-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:54:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19edvE-0004Wk-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 12:54:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19edvE-0004PR-VW; Mon, 21 Jul 2003 12:54:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eduS-0004Oo-HV
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 12:53: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 MAA03378
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 12:53:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eduQ-0004W7-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:53:10 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eduF-0004Vi-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 12:53:00 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA22633;
	Mon, 21 Jul 2003 09:52:24 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6LGqN413712;
	Mon, 21 Jul 2003 09:52:23 -0700
X-mProtect: <200307211652> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdKIbdB7; Mon, 21 Jul 2003 09:49:02 PDT
Message-ID: <3F1C197E.7A057B67@iprg.nokia.com>
Date: Mon, 21 Jul 2003 09:49:02 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com> <3F187710.BDC73048@iprg.nokia.com> <3F1BE374.6070409@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Marco Liebsch wrote:
> 

> I see your point. However, I don't see a reason why the flag as
> flow-control indicator
> should not work. Maybe there is also a benefit from implementation point
> of view on
> the MN. In case of having a flag, MN is notified when exceeding the
> request rate. Of course,
> AR has to maintain a per-MN state. Furthermore, rules have to be
> specified for MNs
> on how to behave when CARD Reply indicates exceeding rate. But from
> implementation point
> of view, this does not look very complicated on the MN side. However,
> having a
> "n-requests allowed per second"-rule on the MN, this needs to be
> controlled and
> implemented on the MN side, which looks like requiring a bit more effort
> 
> Alternative proposal was to indicate a maximum rate for a particular AR
> in the
> first CARD Reply. This keeps individual request rates flexible and avoids
> defining static numbers.

see my reply to Hemant.

>  From complexity and implementation point of view, I don't really
> understand why
> the proposed mechanism makes the protocol complex? I don't see
> any difference between having a check on the lifetime (==0x00000000?)
> and in case it's
> zero assume the capability to be static, and having a check on a
> specific flag (flag == 1?),
> indicating a static capability, hence, no lifetime field is present but
> "value" descriptor
> follows immediately.
> But if there are any further argumements and concerns, we can again
> think about it.

:) a new flag means extra fields in the data structure, 
extra code to check the flag, set the flag... you 
already have the lifetime field. and you would be anyway
checking the value of the lifetime field everytime you 
receive a capability parameter. I would generally avoid 
introducing additional flags.

and this comment

>but in the current form not many people are going to use 
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should 
>avoid. I want a protocol that I can use. :)

was a specific reply to Ajoy's

>>Btw, in cellular standard I have seen even more complicated
>>procedure for saving 4 bits per frame

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 13:39: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 NAA04847
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 13:39: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 19eecu-0006Im-KA
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 13:39:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LHd8kU024223
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 13:39:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eecu-0006Ic-FR
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 13:39: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 NAA04818
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 13:39:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eecs-0004tV-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 13:39:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19eecm-0004tS-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 13:39:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eecn-0006GL-Fj; Mon, 21 Jul 2003 13:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eec7-0006Fq-R8
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 13:38: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 NAA04808
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 13:38:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eec5-0004tE-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 13:38:17 -0400
Received: from bay2-f32.bay2.hotmail.com ([65.54.247.32] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19eebu-0004t6-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 13:38:07 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 21 Jul 2003 10:37:16 -0700
Received: from 65.211.103.2 by by2fd.bay2.hotmail.msn.com with HTTP;
	Mon, 21 Jul 2003 17:37:15 GMT
X-Originating-IP: [65.211.103.2]
X-Originating-Email: [hchaskar@hotmail.com]
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: vijayd@IPRG.nokia.com
Cc: ASINGH1@motorola.com, pcalhoun@airespace.com, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 17:37:15 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY2-F32mAzZnPVbDI800008ead@hotmail.com>
X-OriginalArrivalTime: 21 Jul 2003 17:37:16.0192 (UTC) FILETIME=[BA1DBA00:01C34FAE]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hi all,

Does WG agree to text provided by Vijay? Pat, James could you do consensus 
call on this text.

Hemant

>From: Vijay Devarapalli <vijayd@IPRG.nokia.com>
>To: Hemant Chaskar <hchaskar@hotmail.com>
>CC: ASINGH1@motorola.com, pcalhoun@airespace.com, kempf@docomolabs-usa.com, 
>        seamoby@ietf.org
>Subject: Re: [Seamoby] (virtual) hum on CARD open issues
>Date: Mon, 21 Jul 2003 09:37:26 -0700
>
>
>I already provided the text when I reviewed the CARD protocol.
>
>   The MN MUST send only one CARD Request per
>   CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES.
>   If the MN sends requests more frequently, the AR SHOULD drop the
>   CARD requests and not process them.
>
>and add to the constants section
>
>   CARD_RETRANSMISSION_INTERVAL  1 second
>   CARD_MAX_RETRIES              3
>
>this is similar to ICMP rate limiting.
>
>TCP rate limiting is different, not applicable here. in general
>in any protocol where there is a request and a reply (and no
>more messages), ICMP rate limiting is best suited. you dont have
>to "source-quench" the Mobile Node. :)
>
>Vijay
>
>Hemant Chaskar wrote:
> >
> > Dear Vijay,
> >
> > Could you provide a text to be included in the draft on rate limiting. 
>We
> > can include it in the draft after discussing it over mailing list. It
> > probably wont suffice to say that rate limiting is in lot of protocols 
>and
> > hence not needed here. Different protocols use different rate limiting. 
>E.g.
> > TCP uses rate limiting, but it wont be appropriate for CARD.
> >
> > If you are proposing to limit the rate by simply enforcing limit on
> > aggregate rate of requests, I can easily argue that it is ineffective. 
>So
> > the question is: Wheater WG wants per MN rate limiting? If so, does it 
>have
> > to be using R flag or using limit on per-MN rate of request? And then, 
>you
> > can refer us to protocol that uses that type of rate limiting and we 
>will
> > simply refer to it - will save lot of writing.
> >
> > Hemant
> >
> > >From: Vijay Devarapalli <vijayd@iprg.nokia.com>
> > >To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
> > >CC: "Pat R. Calhoun" <pcalhoun@airespace.com>, 
>kempf@docomolabs-usa.com,
> > >     seamoby@ietf.org
> > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> > >Date: Fri, 18 Jul 2003 15:39:12 -0700
> > >
> > >Singh Ajoy-ASINGH1 wrote:
> > > >
> > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do 
>about
> > >potential Dos issues? WG consensus is to Keep the R-flag approach. 
>Meeting
> > >consensus is to add clarifying text to section 4.2 (4.3?)
> > > >
> > > > this is wrong, IMHO. rate limiting is a well known mechanism.
> > > > introducing a new flag is not a bright idea.
> > > >
> > > > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > > > issue but I am not convinced why using R bit is worse than
> > > > your proposed solution.
> > >
> > >simple. rate-limiting is implemented in a wide variety of
> > >protocols (infact for any message that creates state at
> > >the receiving node). nothing new here. you dont need a new
> > >mechanism for this.
> > >
> > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. 
>The
> > >editor recommends the use of ICMP to make it consistent with the mobile
> > >interface. Potential downsides: ICMP has potential security 
>implications.
> > >ICMP message types on binding is also very implementation specific. 
>Also,
> > >securing ICMP would require that all ICMP packets be secured. Meeting
> > >consensus is to keep UDP.
> > > >
> > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > > > options lets you piggyback these options on FMIPv6 messages.
> > > > I am not sure how you can achieve piggybacking if the MN-AR
> > > > signaling becomes UDP. ICMP was the right choice between
> > > > the MN and the AR.
> > > >
> > > > AJOY-> Well I did not attend IETF meeting, but I guess this means 
>ICMP
> > >for
> > > > MN-AR and UDP for AR-AR interface. Others' please correct me.
> > >
> > >oops... I misunderstood. I thought the concensus at the
> > >meeting was to use UDP for both.
> > >
> > > > BTW, why are you in favor of
> > > > using ICMP for AR-AR interface?
> > >
> > >otherwise you need seperate code for processing an ICMP
> > >CARD Request (from the MN) and UDP CARD Request (from
> > >the PAR). also, if it is an ICMP message, I can piggyback
> > >CARD messages on HI/HACK messages of FMIPv6.
> > >
> > >
> > > > unbelievable. the CARD protocol is already complicated (IMO).
> > > > the emphasis should be on reducing the complexity. just use
> > > > a value of infinity for the lifetime field to indicate a
> > > > static capability. any other value for the lifetime indicates
> > > > dynamic capability. I think for the CARD protocol, emphasis
> > > > should be on making it a simpler protocol than saving 4 bytes
> > > > over the air. :)
> > > >
> > > > if you are concerned about an overhead of 4 bytes, make the
> > > > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > > > 65536 seconds which should be enough. do you need a 4 byte
> > > > lifetime field?
> > > >
> > > > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > > > huge saving for bandwidth constraint network. I am not sure
> > > > processing one flag will make CARD protocol any more complicated.
> > > > Btw, in cellular standard I have seen even more complicated
> > > > procedure for saving 4 bits per frame. Please note that
> > > > the CARD protocol is being proposed as an experimental
> > > > protocol so we will have opportunity to make such
> > > > changes in future if required.
> > >
> > >but in the current form not many people are going to use
> > >it. it might remain forever as an experimental, untouched,
> > >ignored, just another RFC.... that is something we should
> > >avoid. I want a protocol that I can use. :)
> > >
> > >Vijay
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 14:01:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05408
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 14:01:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eeyJ-0006oX-Sf
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 14:01:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LI1FDP026187
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 14:01:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eeyJ-0006oI-PV
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:01: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 OAA05400
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 14:01:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eeyH-00051C-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 14:01:13 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19eeyB-000519-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 14:01:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eey6-0006nZ-3K; Mon, 21 Jul 2003 14:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eexb-0006n0-Nt
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 14:00:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05386
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 14:00:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eexZ-00050v-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 14:00:29 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eexO-00050p-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 14:00:18 -0400
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h6LI03Y7014325
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 11:00:03 -0700 (MST)
Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2])
	by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h6LI01Dp023593
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 13:00:01 -0500
Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2)
	id <3X8681W0>; Mon, 21 Jul 2003 13:00:01 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B1221A24A@IL27EXM10.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'Vijay Devarapalli'" <vijayd@iprg.nokia.com>,
        Singh Ajoy-ASINGH1
	 <ASINGH1@motorola.com>
Cc: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 12:59:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

Hello Vijay,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] 
Sent: Friday, July 18, 2003 5:39 PM
To: Singh Ajoy-ASINGH1
Cc: Pat R. Calhoun; kempf@docomolabs-usa.com; seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


Singh Ajoy-ASINGH1 wrote:
> 
> > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about 
> > potential Dos issues? WG consensus is to Keep the R-flag approach. 
> > Meeting consensus is to add clarifying text to section 4.2 (4.3?)
> 
> this is wrong, IMHO. rate limiting is a well known mechanism. 
> introducing a new flag is not a bright idea.
> 
> ajoy-> Why it is a bad idea?  Well, I am neutral in this
> issue but I am not convinced why using R bit is worse than your 
> proposed solution.

simple. rate-limiting is implemented in a wide variety of protocols (infact for any message that creates state at the receiving node). nothing new here. you dont need a new mechanism for this.

> > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The 
> > editor recommends the use of ICMP to make it consistent with the 
> > mobile interface. Potential downsides: ICMP has potential security 
> > implications. ICMP message types on binding is also very 
> > implementation specific. Also, securing ICMP would require that all 
> > ICMP packets be secured. Meeting consensus is to keep UDP.
> 
> 2 and 3 dont go togetheer. defining CARD messages as ICMP options lets 
> you piggyback these options on FMIPv6 messages. I am not sure how you 
> can achieve piggybacking if the MN-AR signaling becomes UDP. ICMP was 
> the right choice between the MN and the AR.
> 
> AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP 
> AJOY-> for
> MN-AR and UDP for AR-AR interface. Others' please correct me.

oops... I misunderstood. I thought the concensus at the 
meeting was to use UDP for both.

> BTW, why are you in favor of
> using ICMP for AR-AR interface?

otherwise you need seperate code for processing an ICMP
CARD Request (from the MN) and UDP CARD Request (from 
the PAR). 

AJOY->  I guess you can still keep 
CARD AVP parsing code same. But I do admit some additional code will 
be required to support two different transport protocols. 
But does this justify ICMP as an AR-AR transport 
Protocol? As far as I know ICMP was not designed for transport
Protocol so why are you changing this? Well, what other's think?  

also, if it is an ICMP message, I can piggyback
CARD messages on HI/HACK messages of FMIPv6.

AJOY-> Sometime. But timing of CARD Request/CARD Reply may not coincide with that 
of HI/HACK.


> unbelievable. the CARD protocol is already complicated (IMO). the 
> emphasis should be on reducing the complexity. just use a value of 
> infinity for the lifetime field to indicate a static capability. any 
> other value for the lifetime indicates dynamic capability. I think for 
> the CARD protocol, emphasis should be on making it a simpler protocol 
> than saving 4 bytes over the air. :)
> 
> if you are concerned about an overhead of 4 bytes, make the lifetime 
> field 2 bytes. a 2 byte lifetime field gives you 65536 seconds which 
> should be enough. do you need a 4 byte lifetime field?
> 
> AJOY-> I disagree here. Saving even 2 bytes per capability is
> huge saving for bandwidth constraint network. I am not sure processing 
> one flag will make CARD protocol any more complicated. Btw, in 
> cellular standard I have seen even more complicated procedure for 
> saving 4 bits per frame. Please note that the CARD protocol is being 
> proposed as an experimental protocol so we will have opportunity to 
> make such changes in future if required.

but in the current form not many people are going to use 
it. it might remain forever as an experimental, untouched, 
ignored, just another RFC.... that is something we should 
avoid. I want a protocol that I can use. :)

AJOY-> I am really not convinced that complexity of processing one additional 
flag outweighs the saving. But what other's think? 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 14:40:59 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 OAA06506
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 14:40:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19efaL-0000Z6-NC
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 14:40:33 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIeXZu002165
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 14:40:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19efaK-0000Yq-P6
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:40:32 -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 OAA06493
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 14:40: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 19efZp-0000W7-Pu; Mon, 21 Jul 2003 14:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19efZm-0000VZ-DK
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 14:39:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06480
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 14:39:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19efZj-0005KO-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 14:39:55 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19efZY-0005K0-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 14:39:45 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06858;
	Mon, 21 Jul 2003 11:38:15 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6LIcEm31268;
	Mon, 21 Jul 2003 11:38:14 -0700
X-mProtect: <200307211838> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd1Y5o5d; Mon, 21 Jul 2003 11:38:11 PDT
Message-ID: <3F1C3313.E4A69900@iprg.nokia.com>
Date: Mon, 21 Jul 2003 11:38:11 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
CC: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <35DBB8B7AC89D4118E98009027B1009B1221A24A@IL27EXM10.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Singh Ajoy-ASINGH1 wrote:
> 
> otherwise you need seperate code for processing an ICMP
> CARD Request (from the MN) and UDP CARD Request (from
> the PAR).
> 
> AJOY->  I guess you can still keep
> CARD AVP parsing code same. But I do admit some additional code will
> be required to support two different transport protocols.
> But does this justify ICMP as an AR-AR transport
> Protocol? As far as I know ICMP was not designed for transport
> Protocol so why are you changing this? Well, what other's think?
> 
> also, if it is an ICMP message, I can piggyback
> CARD messages on HI/HACK messages of FMIPv6.
> 
> AJOY-> Sometime. But timing of CARD Request/CARD Reply may not coincide with that
> of HI/HACK.

allright. I am fine with what you say.

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 16:37: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 QAA10133
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 16:37: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 19ehPA-00054g-RN
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 16:37:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LKb8MT019489
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 16:37:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ehPA-00054G-M7
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 16:37: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 QAA10124
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 16:37:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ehP8-0006A6-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 16:37:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ehP3-0006A3-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 16:37:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ehP2-00050e-Gm; Mon, 21 Jul 2003 16:37:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ehOj-000500-Al
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 16:36:41 -0400
Received: from mailer.nec-labs.com (mailer.ccrl.nj.nec.com [138.15.108.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10088
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 16:36:36 -0400 (EDT)
Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 21 Jul 2003 16:25:41 -0400
Message-ID: <014601c34fc6$e4e18650$c96b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
        "Hemant Chaskar" <hchaskar@hotmail.com>
Cc: <ASINGH1@motorola.com>, <pcalhoun@airespace.com>,
        <kempf@docomolabs-usa.com>, <seamoby@ietf.org>
References: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com> <3F1C16C6.330CDA85@iprg.nokia.com>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 16:30:15 -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.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 21 Jul 2003 20:25:41.0409 (UTC) FILETIME=[414B7910:01C34FC6]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Vijay,

Please see my comments below.

>
> I already provided the text when I reviewed the CARD protocol.
>
>   The MN MUST send only one CARD Request per
>   CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES.
>   If the MN sends requests more frequently, the AR SHOULD drop the
>   CARD requests and not process them.
>
> and add to the constants section
>
>   CARD_RETRANSMISSION_INTERVAL  1 second
>   CARD_MAX_RETRIES              3
>
> this is similar to ICMP rate limiting.
>
> TCP rate limiting is different, not applicable here. in general
> in any protocol where there is a request and a reply (and no
> more messages), ICMP rate limiting is best suited. you dont have
> to "source-quench" the Mobile Node. :)
>

What's going to happen if the AR should deal with a large number of MNs?
Also what if the network operator wants to use a different value for the
inter-message interval limit? How does the MN know the value?

You might think "source-quench" is significant additional complexity but
actually the AR must calculate the message rate of each MN to do policing
(that is, dropping messages over the rate limit) and thus doing
"source-quench" adds little additional complexity.

Eunsoo



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 17:22: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 RAA11269
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 17:22:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ei6t-0007Sn-P3
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 17:22:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LLMJVp028683
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 17:22:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ei6t-0007SY-Lq
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 17:22: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 RAA11260
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 17:22:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ei6q-0006Sc-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 17:22:16 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ei6l-0006SZ-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 17:22:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ei6b-0007Py-O1; Mon, 21 Jul 2003 17: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 19ei66-0007PU-Ff
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 17:21: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 RAA11228
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 17:21:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ei64-0006S5-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 17:21:28 -0400
Received: from letters.cs.ucsb.edu ([128.111.41.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ei5t-0006Rp-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 17:21:17 -0400
Received: from cs.ucsb.edu (vail [128.111.52.30])
	by letters.cs.ucsb.edu (8.11.7+Sun/8.11.6) with ESMTP id h6LLKdS24193;
	Mon, 21 Jul 2003 14:20:39 -0700 (PDT)
Message-ID: <3F1C5912.2090903@cs.ucsb.edu>
Date: Mon, 21 Jul 2003 14:20:18 -0700
From: Robert Chalmers <robertc@cs.ucsb.edu>
Organization: UCSB Computer Science
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030620
X-Accept-Language: en
MIME-Version: 1.0
To: "Pat R. Calhoun" <pcalhoun@airespace.com>, kempf@docomolabs-usa.com
CC: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com>
In-Reply-To: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com>
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Pat R. Calhoun wrote:

> 1. Issue #2: R-flag for CARD Request rate limiting. What to do about
> potential Dos issues? WG consensus is to Keep the R-flag approach.
> Meeting consensus is to add clarifying text to section 4.2 (4.3?)
> 
Disagree. R-flag seems like an odd design for rate-limiting. Are we 
expecting MN's to be constantly querying their AR's for the latest news, 
or will they make one or two requests prior to handover. Resending will 
be due to losses, and normal rate-limiting techniques work well in this 
environment (especially if AR isn't even receiving the messages due to 
congestion on the wireless link - no reply - no R-bit).

> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6?
> Meeting consensus is to keep the current text for CARD protocol
> operation with FMIPv6.
> 
Agree. Since this is an experimental draft, leaving the capability to 
piggy-back is fine. However, the draft shouldn't waste too much text on 
the issue.

> 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
> editor recommends the use of ICMP to make it consistent with the
> mobile interface. Potential downsides: ICMP has potential security
> implications. ICMP message types on binding is also very
> implementation specific. Also, securing ICMP would require that all
> ICMP packets be secured. Meeting consensus is to keep UDP.
> 
Agree. I've never felt that inter-AR protocols should use ICMP.

> 4. Issue #5: Static vs. dynamic capability attributes. The editor
> recommends that we keep the S-bit and use the 32-bit lifetime only
> when really required for dynamic capabilities. This saves bandwidth,
> but does complicate processing. Meeting consensus is to keep S-bit.
> 
Disagree. This is a bit nit-picky for an experimental draft. I'd like to 
see the protocol simplified as much as possible. People can experiment 
with it and determine whether saving a few bytes here or there would 
make a real difference.

> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast.
> Proposal by the editor is to use broadcast for IPv4 and multicast for
> IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless
> links can generate heavy traffic. James Kempf proposes that we drop
> this for now as we enter experimental. Alternative proposal is to
> mimic router advertisements, send when changes occur and send when
> new mobile shows up. Meeting consensus is to add a statement in the
> document that we considered multicast and leave it for future.
> 
Agree. Although, I'm not sure what the statement accomplishes.

> 6. Issue #12: Link Layer triggers for unsolicited CARD reply.
> Proposal is to remove the text that deals with layer 2 triggers.
> Meeting consensus is to remove text.
> 
Agree.

> 7. Issue #7. Preferences/Requirements sub-option. We should only use
> one of the two methods. Meeting consensus is to keep both the
> sub-option and the preference.
> 
Disagree. It seems like these options could be combined. Simpllify the 
protocol going into experimental so that people are willing to implement 
it and experiment. If the separation is truly necessary, it should 
become clear then.

> 8. Issue #18. Requesting ARs to perform ONLY reverse address
> translation. This is an essential feature for the MN to indicate
> reverse translation. Ultimately, this could become obsolete since the
> Proxy message does this too. Meeting consensus is to specify a R-flag
> in the CARD request message.
> 
Agree with a slight twist. The basic thing here is the reverse-address 
translation (whether or not FMIPv6 may overlap). So, the flag should 
indicate whether the MN would like the extra cabalities returned in the 
message in addition to the address info (a C-flag). Just a side note: 
beware of using R-flag hear for one purpose and using another R-flag in 
the reply for rate-limiting. It could be confusing.

> 9. Issue #25: Addressing of unicast CARD protocol messages. Should we
> use global or link local addresses? Meeting consensus is that since
> MN-AR is always on a single hop, use keep link local addresses.
>
Agree.

> 10. Issue #36: Removal of per-session state from ARs. Meeting
> consensus is to keep signalling failure recovery on AR-AR interface,
> but make it optional (MAY).
> 
Agree.

> 11. Issue #39: Further detail of signalling failure recovery
> required. Meeting consensus is that if the MN is not able to resolve
> an L2 ID, put an error code or some flag.
> 
Not sure what this means. If MN is unable to do something, who is it 
telling? Is this supposed to say if the AR can't resolve then tell the 
MN. If so, I definitely agree.

> 12. Issue #17: Separate appendix from the CARD protocol
> specification. The appendix is very large which describes many
> options. James Kempf believes that the appendix really needs to be
> shortened down to 2 pages, describing the two solutions - these are
> items that need to be resolved during the experimental phase. Meeting
> consensus is to take the appendix to 2 pages.
> 
Agree. Although I would probably prefer to see them as separate drafts. 
Two pages won't tell you much. What exactly is the purpose of the 
appendix then? Just to hint at the solutions?

bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 19:29:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14810
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 19:29: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 19ek5h-00037D-LI
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 19:29:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LNTDBL011969
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 19:29:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ek5h-00036y-Dw
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 19:29:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14807
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 19:29:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ek5f-00072S-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 19:29:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ek5a-00072P-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 19:29:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ek5V-00035p-6o; Mon, 21 Jul 2003 19:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ek4z-00035Q-I1
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 19:28: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 TAA14789
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 19:28:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ek4x-000724-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 19:28:27 -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 19ek4d-000720-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 19:28:07 -0400
Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 21 Jul 2003 19:27:32 -0400
Message-ID: <001901c34fe0$4d2f4d00$c96b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "Robert Chalmers" <robertc@cs.ucsb.edu>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, <kempf@docomolabs-usa.com>
Cc: <seamoby@ietf.org>
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com> <3F1C5912.2090903@cs.ucsb.edu>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Mon, 21 Jul 2003 19:32:08 -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: 21 Jul 2003 23:27:32.0246 (UTC) FILETIME=[A8A91360:01C34FDF]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, Bob,



Please see my inline comments below.


> > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about
> > potential Dos issues? WG consensus is to Keep the R-flag approach.
> > Meeting consensus is to add clarifying text to section 4.2 (4.3?)
> >
> Disagree. R-flag seems like an odd design for rate-limiting. Are we
> expecting MN's to be constantly querying their AR's for the latest news,
> or will they make one or two requests prior to handover. Resending will
> be due to losses, and normal rate-limiting techniques work well in this
> environment (especially if AR isn't even receiving the messages due to
> congestion on the wireless link - no reply - no R-bit).
>

[eunsoo] First of all, the R flag or the rate limiting was not introduced
for congestion control. It was introduced to defend the AR against the DOS
attack. The R flag is to notifiy the non-malicious MN about future message
dropping.

We don't like the fixed rate limit because the admin might want to set
different rate limits for different ARs. Then the question is how to inform
the MNs about it. A solution is to inform every MN. Another solution is the
R bit, which is to inform only the MNs that exceed the rate limit. By adding
the rate limit information with the R flag, the MN is informed that the
current AR has a different rate limit from the value the MN uses by default.



BTW, what is the normal rate-limiting technique you propose?


> > 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6?
> > Meeting consensus is to keep the current text for CARD protocol
> > operation with FMIPv6.
> >
> Agree. Since this is an experimental draft, leaving the capability to
> piggy-back is fine. However, the draft shouldn't waste too much text on
> the issue.
>
> > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
> > editor recommends the use of ICMP to make it consistent with the
> > mobile interface. Potential downsides: ICMP has potential security
> > implications. ICMP message types on binding is also very
> > implementation specific. Also, securing ICMP would require that all
> > ICMP packets be secured. Meeting consensus is to keep UDP.
> >
> Agree. I've never felt that inter-AR protocols should use ICMP.
>
> > 4. Issue #5: Static vs. dynamic capability attributes. The editor
> > recommends that we keep the S-bit and use the 32-bit lifetime only
> > when really required for dynamic capabilities. This saves bandwidth,
> > but does complicate processing. Meeting consensus is to keep S-bit.
> >
> Disagree. This is a bit nit-picky for an experimental draft. I'd like to
> see the protocol simplified as much as possible. People can experiment
> with it and determine whether saving a few bytes here or there would
> make a real difference.
>



[Eunsoo] Saving air interface bandwidth is very important. I don't think
people argue about it. Please notice that people work on header compression
to save a few bytes here and there. The S-bit is much simpler than the
header compression but can save a lot more bandwidth.


> > 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast.
> > Proposal by the editor is to use broadcast for IPv4 and multicast for
> > IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless
> > links can generate heavy traffic. James Kempf proposes that we drop
> > this for now as we enter experimental. Alternative proposal is to
> > mimic router advertisements, send when changes occur and send when
> > new mobile shows up. Meeting consensus is to add a statement in the
> > document that we considered multicast and leave it for future.
> >
> Agree. Although, I'm not sure what the statement accomplishes.
>
> > 6. Issue #12: Link Layer triggers for unsolicited CARD reply.
> > Proposal is to remove the text that deals with layer 2 triggers.
> > Meeting consensus is to remove text.
> >
> Agree.
>
> > 7. Issue #7. Preferences/Requirements sub-option. We should only use
> > one of the two methods. Meeting consensus is to keep both the
> > sub-option and the preference.
> >
> Disagree. It seems like these options could be combined. Simpllify the
> protocol going into experimental so that people are willing to implement
> it and experiment. If the separation is truly necessary, it should
> become clear then.
>

[Eunsoo] Please notice that you are proposing introduction of a flag to
combing the two sub-options, which you claim introduces complexity.

I am neutral about this issue. But I don't think having two separate
sub-options make the protocol a bit more complex.


> > 8. Issue #18. Requesting ARs to perform ONLY reverse address
> > translation. This is an essential feature for the MN to indicate
> > reverse translation. Ultimately, this could become obsolete since the
> > Proxy message does this too. Meeting consensus is to specify a R-flag
> > in the CARD request message.
> >
> Agree with a slight twist. The basic thing here is the reverse-address
> translation (whether or not FMIPv6 may overlap). So, the flag should
> indicate whether the MN would like the extra cabalities returned in the
> message in addition to the address info (a C-flag). Just a side note:
> beware of using R-flag hear for one purpose and using another R-flag in
> the reply for rate-limiting. It could be confusing.
>
> > 9. Issue #25: Addressing of unicast CARD protocol messages. Should we
> > use global or link local addresses? Meeting consensus is that since
> > MN-AR is always on a single hop, use keep link local addresses.
> >
> Agree.
>
> > 10. Issue #36: Removal of per-session state from ARs. Meeting
> > consensus is to keep signalling failure recovery on AR-AR interface,
> > but make it optional (MAY).
> >
> Agree.
>
> > 11. Issue #39: Further detail of signalling failure recovery
> > required. Meeting consensus is that if the MN is not able to resolve
> > an L2 ID, put an error code or some flag.
> >
> Not sure what this means. If MN is unable to do something, who is it
> telling? Is this supposed to say if the AR can't resolve then tell the
> MN. If so, I definitely agree.
>

[Eunsoo] Your understanding is right.


> > 12. Issue #17: Separate appendix from the CARD protocol
> > specification. The appendix is very large which describes many
> > options. James Kempf believes that the appendix really needs to be
> > shortened down to 2 pages, describing the two solutions - these are
> > items that need to be resolved during the experimental phase. Meeting
> > consensus is to take the appendix to 2 pages.
> >
> Agree. Although I would probably prefer to see them as separate drafts.
> Two pages won't tell you much. What exactly is the purpose of the
> appendix then? Just to hint at the solutions?
>


Eunsoo


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 21 20:48: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 UAA16204
	for <seamoby-archive@odin.ietf.org>; Mon, 21 Jul 2003 20:48:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19elK5-0005oB-GO
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 20:48:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M0m9di022321
	for seamoby-archive@odin.ietf.org; Mon, 21 Jul 2003 20:48:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19elK5-0005nw-CV
	for seamoby-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 20:48: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 UAA16201
	for <seamoby-web-archive@ietf.org>; Mon, 21 Jul 2003 20:48:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19elK3-0007db-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 20:48:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19elJx-0007dY-00
	for seamoby-web-archive@ietf.org; Mon, 21 Jul 2003 20:48:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19elJw-0005nH-Ui; Mon, 21 Jul 2003 20:48:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19elJP-0005mY-FR
	for seamoby@optimus.ietf.org; Mon, 21 Jul 2003 20:47:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16197
	for <seamoby@ietf.org>; Mon, 21 Jul 2003 20:47:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19elJN-0007dJ-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 20:47:25 -0400
Received: from letters.cs.ucsb.edu ([128.111.41.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 19elJC-0007dD-00
	for seamoby@ietf.org; Mon, 21 Jul 2003 20:47:14 -0400
Received: from cs.ucsb.edu (vail [128.111.52.30])
	by letters.cs.ucsb.edu (8.11.7+Sun/8.11.6) with ESMTP id h6M0knS09470;
	Mon, 21 Jul 2003 17:46:49 -0700 (PDT)
Message-ID: <3F1C8963.9010409@cs.ucsb.edu>
Date: Mon, 21 Jul 2003 17:46:27 -0700
From: Robert Chalmers <robertc@cs.ucsb.edu>
Organization: UCSB Computer Science
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030620
X-Accept-Language: en
MIME-Version: 1.0
To: Eunsoo Shim <eunsoo@nec-labs.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com> <3F1C5912.2090903@cs.ucsb.edu> <001901c34fe0$4d2f4d00$c96b0f8a@peace>
In-Reply-To: <001901c34fe0$4d2f4d00$c96b0f8a@peace>
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eunsoo,

>>> 1. Issue #2: R-flag for CARD Request rate limiting. What to do 
>>> about potential Dos issues? WG consensus is to Keep the R-flag 
>>> approach. Meeting consensus is to add clarifying text to section 
>>> 4.2 (4.3?)
>>> 
>> 
>> Disagree. R-flag seems like an odd design for rate-limiting. Are we
>>  expecting MN's to be constantly querying their AR's for the latest
>>  news, or will they make one or two requests prior to handover. 
>> Resending will be due to losses, and normal rate-limiting 
>> techniques work well in this environment (especially if AR isn't 
>> even receiving the messages due to congestion on the wireless link 
>> - no reply - no R-bit).
>> 
> 
> 
> [eunsoo] First of all, the R flag or the rate limiting was not 
> introduced for congestion control. It was introduced to defend the AR
>  against the DOS attack. The R flag is to notifiy the non-malicious
> MN about future message dropping.
> 
This makes no sense to me. The R-flag protects the AR from Dos attacks
by telling non-attacking mobiles to slow down? It's pretty clear that an
attacking mobile is going to ignore the R-bit anyways. So, all you end
up doing is degrading service to those mobiles not causing the problem,
and opening up bandwidth for the attacker.

According to the draft:

    Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
    during link layer scanning, sometimes a MN might send frequent MN-AR
    CARD Requests, thereby overwhelming its current AR with CARD Request
    signaling messages. To counteract this problem, the AR SHOULD set
    the R-flag (rate limiting) of a subsequent CARD Reply message for
    flow-control purposes (section 5.1.2.2), thereby requesting the MN
    to reduce the generation rate of MN-AR CARD Requests. Upon receipt
    of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
    reduce the rate of generation of MN-AR CARD Requests. The exact
    implementation of a rate-limiting algorithm should be decided by the
    implementers.

This sounds more like a "congestion control" feature to me.

> We don't like the fixed rate limit because the admin might want to 
> set different rate limits for different ARs. Then the question is how
>  to inform the MNs about it. A solution is to inform every MN.
> Another solution is the R bit, which is to inform only the MNs that
> exceed the rate limit. By adding the rate limit information with the
> R flag, the MN is informed that the current AR has a different rate
> limit from the value the MN uses by default.
> 
It just seems better to develop guidelines by which MN's behave
"properly". For instance, they should hold off on immediately resolving
each new AP in an effort to batch the requests and limit the rate of
signalling. I understand your desire for the AR to have some control
over what a "good" rate is, but the R-bit seems to me to be too reactive
for this; "Wow partner, you'd better throw on the breaks there!" Can the
MN later try to push this limit (a la TCP)? Rather, have the AR include
a sub-option on the first reply to a MN with the preferred maximum rate,
and let the MN maintain that rate. My 2 cents.

> BTW, what is the normal rate-limiting technique you propose?
> 
Vijay has already answered this a number of times.


>>> 4. Issue #5: Static vs. dynamic capability attributes. The editor
>>>  recommends that we keep the S-bit and use the 32-bit lifetime 
>>> only when really required for dynamic capabilities. This saves 
>>> bandwidth, but does complicate processing. Meeting consensus is 
>>> to keep S-bit.
>>> 
>> 
>> Disagree. This is a bit nit-picky for an experimental draft. I'd 
>> like to see the protocol simplified as much as possible. People can
>>  experiment with it and determine whether saving a few bytes here
>> or there would make a real difference.
>> 
> [Eunsoo] Saving air interface bandwidth is very important. I don't 
> think people argue about it. Please notice that people work on header
>  compression to save a few bytes here and there. The S-bit is much 
> simpler than the header compression but can save a lot more 
> bandwidth.
> 
Another option is to separate the sub-options so that the type
explicitly determines whether a lifetime is present or not. This is
probably not much better. In general, I don't care too much about this
one, but as an implementor I always question the need for variable
structures to represent packets. If so, then the variable values are
usually left to the end of the packet, not smack dab in the middle of it.

As side note, it seems odd to use the same capabilities structure (with
the variable lifetime) for preferences and requirements since these 
shouldn't contain lifetimes. Should they? That's what originally 
prompted the previous suggestion.

>>> 7. Issue #7. Preferences/Requirements sub-option. We should only 
>>> use one of the two methods. Meeting consensus is to keep both the
>>>  sub-option and the preference.
>>> 
>> 
>> Disagree. It seems like these options could be combined. Simpllify 
>> the protocol going into experimental so that people are willing to 
>> implement it and experiment. If the separation is truly necessary, 
>> it should become clear then.
>> 
> 
> 
> [Eunsoo] Please notice that you are proposing introduction of a flag 
> to combing the two sub-options, which you claim introduces 
> complexity.
> 
Not at all. If you look at the structure of the sub-option, Preferences
do not have a value in the AVP format while requirements do. So, any
(Requirement|Preference) without a specific value can be considered as a
wildcard for pre-filtering. No need for a flag.

But Eunsoo, please don't be purposefully combative. Flags do not
introduce undo complexity by themselves. In the previous instance, I was
primarily concerned that the flag indicates the existence of an extra
field in the middle of the message structure which then changes the
offsets of subsequent fields.

> I am neutral about this issue. But I don't think having two separate
>  sub-options make the protocol a bit more complex.
> 
As a side note, why does it specify in Section 5.1.1 that the
Preferences sub-option is "used only in case of performing
         optional capability pre-filtering". It really has no impact on
pre-filtering, does it? My understanding is that it simply states which
capabilities should be returned in the reply message.

ttyl,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul 22 11:11: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 LAA16833
	for <seamoby-archive@odin.ietf.org>; Tue, 22 Jul 2003 11:11:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eynM-0002sB-EH
	for seamoby-archive@odin.ietf.org; Tue, 22 Jul 2003 11:11:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MFBGS7011039
	for seamoby-archive@odin.ietf.org; Tue, 22 Jul 2003 11:11:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eynM-0002ry-A7
	for seamoby-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 11:11: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 LAA16810
	for <seamoby-web-archive@ietf.org>; Tue, 22 Jul 2003 11:11:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eynJ-0005KK-00
	for seamoby-web-archive@ietf.org; Tue, 22 Jul 2003 11:11:13 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19eynE-0005KE-00
	for seamoby-web-archive@ietf.org; Tue, 22 Jul 2003 11:11:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eyn8-0002rJ-DJ; Tue, 22 Jul 2003 11:11:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19eymX-0002qm-Gv
	for seamoby@optimus.ietf.org; Tue, 22 Jul 2003 11:10: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 LAA16793
	for <seamoby@ietf.org>; Tue, 22 Jul 2003 11:10:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19eymU-0005JY-00
	for seamoby@ietf.org; Tue, 22 Jul 2003 11:10:22 -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 19eymA-0005JF-00
	for seamoby@ietf.org; Tue, 22 Jul 2003 11:10:02 -0400
Received: from peace ([138.15.107.201]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 22 Jul 2003 11:09:26 -0400
Message-ID: <000801c35063$e35ea180$c96b0f8a@peace>
From: "Eunsoo Shim" <eunsoo@nec-labs.com>
To: "Robert Chalmers" <robertc@cs.ucsb.edu>
Cc: <seamoby@ietf.org>
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com> <3F1C5912.2090903@cs.ucsb.edu> <001901c34fe0$4d2f4d00$c96b0f8a@peace> <3F1C8963.9010409@cs.ucsb.edu>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Tue, 22 Jul 2003 11:14:04 -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 Jul 2003 15:09:26.0742 (UTC) FILETIME=[3DECCF60:01C35063]
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, Bob,



>>> 1. Issue #2: R-flag for CARD Request rate limiting. What to do
> >>> about potential Dos issues? WG consensus is to Keep the R-flag
> >>> approach. Meeting consensus is to add clarifying text to section
> >>> 4.2 (4.3?)
> >>>
> >>
> >> Disagree. R-flag seems like an odd design for rate-limiting. Are we
> >>  expecting MN's to be constantly querying their AR's for the latest
> >>  news, or will they make one or two requests prior to handover.
> >> Resending will be due to losses, and normal rate-limiting
> >> techniques work well in this environment (especially if AR isn't
> >> even receiving the messages due to congestion on the wireless link
> >> - no reply - no R-bit).
> >>
> >
> >
> > [eunsoo] First of all, the R flag or the rate limiting was not
> > introduced for congestion control. It was introduced to defend the AR
> >  against the DOS attack. The R flag is to notifiy the non-malicious
> > MN about future message dropping.
> >
> This makes no sense to me. The R-flag protects the AR from Dos attacks
> by telling non-attacking mobiles to slow down? It's pretty clear that an
> attacking mobile is going to ignore the R-bit anyways. So, all you end
> up doing is degrading service to those mobiles not causing the problem,
> and opening up bandwidth for the attacker.
>

[Eunsoo] Please let me explain a little bit further. The AR will drop
messages above the rate limit. It protects the AR from the DOS attack. It is
fine as long as all the MNs know the rate limit set by the AR. So the
question is how the MN gets to know the rate limit which can be different
for different ARs. The R flag is an idea that the AR will inform the non
malicious MN of the fact that the MN reached the rate limit. If the AR
attaches the rate limit value with the R bit, the MN will know that the rate
limit of the AR is different from what the MN uses. Certainly the malicious
attacker will ignore the R flag or whatever information from the AR. As said
earlier, the AR will protect itself by dropping messages. So the R bit was
introduced to protect innocent MNs in a dynamic fashion in the case of rate
limiting.


> According to the draft:
>
>     Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
>     during link layer scanning, sometimes a MN might send frequent MN-AR
>     CARD Requests, thereby overwhelming its current AR with CARD Request
>     signaling messages. To counteract this problem, the AR SHOULD set
>     the R-flag (rate limiting) of a subsequent CARD Reply message for
>     flow-control purposes (section 5.1.2.2), thereby requesting the MN
>     to reduce the generation rate of MN-AR CARD Requests. Upon receipt
>     of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
>     reduce the rate of generation of MN-AR CARD Requests. The exact
>     implementation of a rate-limiting algorithm should be decided by the
>     implementers.
>
> This sounds more like a "congestion control" feature to me.
>

[Eunsoo] I think dealing with the DOS attack has some common aspects with
congestion control. But it seems the draft should be clearer about the
purpose of the rate limiting and its mechanism.


> > We don't like the fixed rate limit because the admin might want to
> > set different rate limits for different ARs. Then the question is how
> >  to inform the MNs about it. A solution is to inform every MN.
> > Another solution is the R bit, which is to inform only the MNs that
> > exceed the rate limit. By adding the rate limit information with the
> > R flag, the MN is informed that the current AR has a different rate
> > limit from the value the MN uses by default.
> >
> It just seems better to develop guidelines by which MN's behave
> "properly". For instance, they should hold off on immediately resolving
> each new AP in an effort to batch the requests and limit the rate of
> signalling. I understand your desire for the AR to have some control
> over what a "good" rate is, but the R-bit seems to me to be too reactive
> for this; "Wow partner, you'd better throw on the breaks there!" Can the
> MN later try to push this limit (a la TCP)? Rather, have the AR include
> a sub-option on the first reply to a MN with the preferred maximum rate,
> and let the MN maintain that rate. My 2 cents.
>

[Eunsoo] The rate limit is set by the AR. The MN can do nothing about it. We
don't envision that the AR will change the rate limit dynamically in
response to any request from the MN. It will be configured by the admin.

The last part is the idea that was proposed as one of the mechanisms by the
design team in the meeting. Certainly it works. We just need to make sure
the MN receive the reply containing the information. Actually this is the
same for the reply containing the R bit. Well, unless the MN does not
retransmit the request with the same sequence number, the AR does not know
whether the MN lost the reply. If the MN gave up retransmitting the request,
the AR never knows that the reply was lost. We need to resolve this problem.

Anyway if the reply containing the R bit includes the rate limit
information, the two mechanisms are almost the same. The R bit can be
replaced by the rate limit information. Then the difference becomes just
whether all the MNs will be informed of the rate limit or only the MN
reaching the rate limit will be informed. The latter can save air interface
bandwidth because probably most MNs won't reach the rate limit. I'd like to
hear WG opinion about these two choices.


> > BTW, what is the normal rate-limiting technique you propose?
> >
> Vijay has already answered this a number of times.
>
>
> >>> 4. Issue #5: Static vs. dynamic capability attributes. The editor
> >>>  recommends that we keep the S-bit and use the 32-bit lifetime
> >>> only when really required for dynamic capabilities. This saves
> >>> bandwidth, but does complicate processing. Meeting consensus is
> >>> to keep S-bit.
> >>>
> >>
> >> Disagree. This is a bit nit-picky for an experimental draft. I'd
> >> like to see the protocol simplified as much as possible. People can
> >>  experiment with it and determine whether saving a few bytes here
> >> or there would make a real difference.
> >>
> > [Eunsoo] Saving air interface bandwidth is very important. I don't
> > think people argue about it. Please notice that people work on header
> >  compression to save a few bytes here and there. The S-bit is much
> > simpler than the header compression but can save a lot more
> > bandwidth.
> >
> Another option is to separate the sub-options so that the type
> explicitly determines whether a lifetime is present or not. This is
> probably not much better. In general, I don't care too much about this
> one, but as an implementor I always question the need for variable
> structures to represent packets. If so, then the variable values are
> usually left to the end of the packet, not smack dab in the middle of it.
>

[Eunsoo] Well, having two types of AVP is currently done by the S bit.
Categorizing the attribute IDs for static attributes and dynamic attributes
is the same thing as having a flag. Unfortunately the value field of the AVP
is generally variable size. So pushing the lifetime field to the end does
not help the situation very much in terms of data structure. I understand
having a variable structure is not the best thing. But if we don't do this,
some people may come up with CARD Compression protocol.^^


> As side note, it seems odd to use the same capabilities structure (with
> the variable lifetime) for preferences and requirements since these
> shouldn't contain lifetimes. Should they? That's what originally
> prompted the previous suggestion.
>

 [eunsoo] The preferences sub-option contains only the list of attribute IDs
and the requirements sub-option contains the list of AVPs. So they are quite
different. Is this not clear in the draft?


> >>> 7. Issue #7. Preferences/Requirements sub-option. We should only
> >>> use one of the two methods. Meeting consensus is to keep both the
> >>>  sub-option and the preference.
> >>>
> >>
> >> Disagree. It seems like these options could be combined. Simpllify
> >> the protocol going into experimental so that people are willing to
> >> implement it and experiment. If the separation is truly necessary,
> >> it should become clear then.
> >>
> >
> >
> > [Eunsoo] Please notice that you are proposing introduction of a flag
> > to combing the two sub-options, which you claim introduces
> > complexity.
> >
> Not at all. If you look at the structure of the sub-option, Preferences
> do not have a value in the AVP format while requirements do. So, any
> (Requirement|Preference) without a specific value can be considered as a
> wildcard for pre-filtering. No need for a flag.
>

[Eunsoo] Hmm, when we thought about it, we thought we would add a flag in
the sub-option header. Are you proposing putting just attribute ID values in
the combined Requirement/Preference sub-option? So if the whole sub-option
is used as Preferences, it contains a list of attribute IDs and if the whole
sub-option is used as Requirements, it contains a list of AVPs. Is my
understanding right? If you are suggesting it, then the sub-option should
have a flag indicating the usage. Otherwise the receiver cannot decode the
sub-option.


> But Eunsoo, please don't be purposefully combative. Flags do not
> introduce undo complexity by themselves. In the previous instance, I was
> primarily concerned that the flag indicates the existence of an extra
> field in the middle of the message structure which then changes the
> offsets of subsequent fields.



[Eunsoo] Bob, I am not purposefully combative. I am just delivering my
technical thought in response to your comments.


>
> > I am neutral about this issue. But I don't think having two separate
> >  sub-options make the protocol a bit more complex.
> >
> As a side note, why does it specify in Section 5.1.1 that the
> Preferences sub-option is "used only in case of performing
>          optional capability pre-filtering". It really has no impact on
> pre-filtering, does it? My understanding is that it simply states which
> capabilities should be returned in the reply message.



[Eunsoo] Pre-filtering means what you said, that is, the AR returns only the
capabilities requested in the Preferences sub-option rather than all the
capability information. Do you think "pre-filtering" in the draft is not
clear enough? If then, how can we make it clearer?



Eunsoo




_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul 22 13:23:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20105
	for <seamoby-archive@odin.ietf.org>; Tue, 22 Jul 2003 13:23:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19f0r7-0007vh-Gh
	for seamoby-archive@odin.ietf.org; Tue, 22 Jul 2003 13:23:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHNHbs030475
	for seamoby-archive@odin.ietf.org; Tue, 22 Jul 2003 13:23:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19f0r6-0007vS-L8
	for seamoby-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 13:23: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 NAA20102
	for <seamoby-web-archive@ietf.org>; Tue, 22 Jul 2003 13:23:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19f0qz-00065h-00
	for seamoby-web-archive@ietf.org; Tue, 22 Jul 2003 13:23:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19f0qu-00065e-00
	for seamoby-web-archive@ietf.org; Tue, 22 Jul 2003 13:23:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19f0qr-0007um-0Q; Tue, 22 Jul 2003 13:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19f0pv-0007rD-7s
	for seamoby@optimus.ietf.org; Tue, 22 Jul 2003 13:22: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 NAA20088
	for <seamoby@ietf.org>; Tue, 22 Jul 2003 13:21:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19f0pP-00065O-00
	for seamoby@ietf.org; Tue, 22 Jul 2003 13:21:31 -0400
Received: from letters.cs.ucsb.edu ([128.111.41.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 19f0pE-00065F-00
	for seamoby@ietf.org; Tue, 22 Jul 2003 13:21:20 -0400
Received: from cs.ucsb.edu (vail [128.111.52.30])
	by letters.cs.ucsb.edu (8.11.7+Sun/8.11.6) with ESMTP id h6MHKPS08678;
	Tue, 22 Jul 2003 10:20:25 -0700 (PDT)
Message-ID: <3F1D7241.2020906@cs.ucsb.edu>
Date: Tue, 22 Jul 2003 10:20:01 -0700
From: Robert Chalmers <robertc@cs.ucsb.edu>
Organization: UCSB Computer Science
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030620
X-Accept-Language: en
MIME-Version: 1.0
To: Eunsoo Shim <eunsoo@nec-labs.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <40301581B2962B448690A023EF16DFE1DC5240@bsn-mail-01.bstormnetworks.com> <3F1C5912.2090903@cs.ucsb.edu> <001901c34fe0$4d2f4d00$c96b0f8a@peace> <3F1C8963.9010409@cs.ucsb.edu> <000801c35063$e35ea180$c96b0f8a@peace>
In-Reply-To: <000801c35063$e35ea180$c96b0f8a@peace>
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eunsoo,

>>>>1. Issue #2: R-flag for CARD Request rate limiting. What to do
>>>>
>>>>>about potential Dos issues? WG consensus is to Keep the R-flag
>>>>>approach. Meeting consensus is to add clarifying text to section
>>>>>4.2 (4.3?)
>>>>>
>>>>
>>>>Disagree. R-flag seems like an odd design for rate-limiting. Are we
>>>> expecting MN's to be constantly querying their AR's for the latest
>>>> news, or will they make one or two requests prior to handover.
>>>>Resending will be due to losses, and normal rate-limiting
>>>>techniques work well in this environment (especially if AR isn't
>>>>even receiving the messages due to congestion on the wireless link
>>>>- no reply - no R-bit).
>>>>
>>>
>>>
>>>[eunsoo] First of all, the R flag or the rate limiting was not
>>>introduced for congestion control. It was introduced to defend the AR
>>> against the DOS attack. The R flag is to notifiy the non-malicious
>>>MN about future message dropping.
>>>
>>
>>This makes no sense to me. The R-flag protects the AR from Dos attacks
>>by telling non-attacking mobiles to slow down? It's pretty clear that an
>>attacking mobile is going to ignore the R-bit anyways. So, all you end
>>up doing is degrading service to those mobiles not causing the problem,
>>and opening up bandwidth for the attacker.
>>
> 
> 
> [Eunsoo] Please let me explain a little bit further. The AR will drop
> messages above the rate limit. It protects the AR from the DOS attack. It is
> fine as long as all the MNs know the rate limit set by the AR. So the
> question is how the MN gets to know the rate limit which can be different
> for different ARs. The R flag is an idea that the AR will inform the non
> malicious MN of the fact that the MN reached the rate limit. If the AR
> attaches the rate limit value with the R bit, the MN will know that the rate
> limit of the AR is different from what the MN uses. Certainly the malicious
> attacker will ignore the R flag or whatever information from the AR. As said
> earlier, the AR will protect itself by dropping messages. So the R bit was
> introduced to protect innocent MNs in a dynamic fashion in the case of rate
> limiting.
> 
> 
> 
>>According to the draft:
>>
>>    Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
>>    during link layer scanning, sometimes a MN might send frequent MN-AR
>>    CARD Requests, thereby overwhelming its current AR with CARD Request
>>    signaling messages. To counteract this problem, the AR SHOULD set
>>    the R-flag (rate limiting) of a subsequent CARD Reply message for
>>    flow-control purposes (section 5.1.2.2), thereby requesting the MN
>>    to reduce the generation rate of MN-AR CARD Requests. Upon receipt
>>    of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
>>    reduce the rate of generation of MN-AR CARD Requests. The exact
>>    implementation of a rate-limiting algorithm should be decided by the
>>    implementers.
>>
>>This sounds more like a "congestion control" feature to me.
>>
> 
> 
> [Eunsoo] I think dealing with the DOS attack has some common aspects with
> congestion control. But it seems the draft should be clearer about the
> purpose of the rate limiting and its mechanism.
> 
Yes, I think this would be good.

>>>We don't like the fixed rate limit because the admin might want to
>>>set different rate limits for different ARs. Then the question is how
>>> to inform the MNs about it. A solution is to inform every MN.
>>>Another solution is the R bit, which is to inform only the MNs that
>>>exceed the rate limit. By adding the rate limit information with the
>>>R flag, the MN is informed that the current AR has a different rate
>>>limit from the value the MN uses by default.
>>>
>>
>>It just seems better to develop guidelines by which MN's behave
>>"properly". For instance, they should hold off on immediately resolving
>>each new AP in an effort to batch the requests and limit the rate of
>>signalling. I understand your desire for the AR to have some control
>>over what a "good" rate is, but the R-bit seems to me to be too reactive
>>for this; "Wow partner, you'd better throw on the breaks there!" Can the
>>MN later try to push this limit (a la TCP)? Rather, have the AR include
>>a sub-option on the first reply to a MN with the preferred maximum rate,
>>and let the MN maintain that rate. My 2 cents.
>>
> 
> 
> [Eunsoo] The rate limit is set by the AR. The MN can do nothing about it. We
> don't envision that the AR will change the rate limit dynamically in
> response to any request from the MN. It will be configured by the admin.
> 
> The last part is the idea that was proposed as one of the mechanisms by the
> design team in the meeting. Certainly it works. We just need to make sure
> the MN receive the reply containing the information. Actually this is the
> same for the reply containing the R bit. Well, unless the MN does not
> retransmit the request with the same sequence number, the AR does not know
> whether the MN lost the reply. If the MN gave up retransmitting the request,
> the AR never knows that the reply was lost. We need to resolve this problem.
> 
> Anyway if the reply containing the R bit includes the rate limit
> information, the two mechanisms are almost the same. The R bit can be
> replaced by the rate limit information. Then the difference becomes just
> whether all the MNs will be informed of the rate limit or only the MN
> reaching the rate limit will be informed. The latter can save air interface
> bandwidth because probably most MNs won't reach the rate limit. I'd like to
> hear WG opinion about these two choices.
>
Even if it's reactive rather than proactive, I think adding the actual 
expected rate is much more useful for both the AR and the MN than simply 
indicating that the MN is "overclocked". Otherwise, the MN may not 
backoff fast enough, or possibly too fast. For example, the MN may be 
exceeding the AR's rate by just one packet per period. What should his 
response be to the R-bit, halve his rate? That would be too extreme. But 
if he's pushing twice as much as the AR expects, just dropping his rate 
linearly will not converge very quickly. This also complicates the 
design of the MN quite a bit, having to constantly adjust his rate.


>>>BTW, what is the normal rate-limiting technique you propose?
>>>
>>
>>Vijay has already answered this a number of times.
>>
>>
>>
>>>>>4. Issue #5: Static vs. dynamic capability attributes. The editor
>>>>> recommends that we keep the S-bit and use the 32-bit lifetime
>>>>>only when really required for dynamic capabilities. This saves
>>>>>bandwidth, but does complicate processing. Meeting consensus is
>>>>>to keep S-bit.
>>>>>
>>>>
>>>>Disagree. This is a bit nit-picky for an experimental draft. I'd
>>>>like to see the protocol simplified as much as possible. People can
>>>> experiment with it and determine whether saving a few bytes here
>>>>or there would make a real difference.
>>>>
>>>
>>>[Eunsoo] Saving air interface bandwidth is very important. I don't
>>>think people argue about it. Please notice that people work on header
>>> compression to save a few bytes here and there. The S-bit is much
>>>simpler than the header compression but can save a lot more
>>>bandwidth.
>>>
>>
>>Another option is to separate the sub-options so that the type
>>explicitly determines whether a lifetime is present or not. This is
>>probably not much better. In general, I don't care too much about this
>>one, but as an implementor I always question the need for variable
>>structures to represent packets. If so, then the variable values are
>>usually left to the end of the packet, not smack dab in the middle of it.
> 
> [Eunsoo] Well, having two types of AVP is currently done by the S bit.
> Categorizing the attribute IDs for static attributes and dynamic attributes
> is the same thing as having a flag. Unfortunately the value field of the AVP
> is generally variable size. So pushing the lifetime field to the end does
> not help the situation very much in terms of data structure. I understand
> having a variable structure is not the best thing. But if we don't do this,
> some people may come up with CARD Compression protocol.^^
>
This is an experimental protocol for G*d sakes. There's time to optimize 
in later drafts if this moves forward towards a standard. Again, I think 
that this is a bit nit-picky at this stage, but oh well.

>>As side note, it seems odd to use the same capabilities structure (with
>>the variable lifetime) for preferences and requirements since these
>>shouldn't contain lifetimes. Should they? That's what originally
>>prompted the previous suggestion.
>>
>  [eunsoo] The preferences sub-option contains only the list of attribute IDs
> and the requirements sub-option contains the list of AVPs. So they are quite
> different. Is this not clear in the draft?
> 
Section 5.1.3.2 says:

    AVPs MUST be encoded according to the AVP encoding rule described in
    section 5.1.4. Only ATTRIBUTES (AVP Code) need to be set. The VALUE
    indicator (Data) will not be processed and can be omitted. The 'AVP
    Length' field is to be set appropriately.

Section 5.1.4 is the same AVP section describing Requirements. So they 
have the same structure. The above indicates that Preferences simply 
have an empty Data field. This is what I'm referring to in the next issue.

Anyway, this wasn't the point of the original comment. Rather, the AVP 
encoding in Section 5.1.4 includes the lifetime field and a flag 
indicating whether that field is present. However, a missing lifetime 
field is supposed to indicate a static lifetime. Do Preferences and 
Requirements have a "static" lifetime. I'd say they have no lifetime at 
all. So, it seems odd that I have to set some bit, and skip a field to 
express that! I know this is a bit nit-picky, but I can see it being 
confusing for implementors.

I'd recommend either having a separate structure without the S-bit and 
lifetime fields for Preferences/Requirements, or change the S-bit to a 
more generic L-bit that is set when the lifetime field is present (for 
whatever reason). It's also more consistent to have something set when 
something is included, not the other way around.

>>>>>7. Issue #7. Preferences/Requirements sub-option. We should only
>>>>>use one of the two methods. Meeting consensus is to keep both the
>>>>> sub-option and the preference.
>>>>
>>>>Disagree. It seems like these options could be combined. Simpllify
>>>>the protocol going into experimental so that people are willing to
>>>>implement it and experiment. If the separation is truly necessary,
>>>>it should become clear then.
>>>
>>>[Eunsoo] Please notice that you are proposing introduction of a flag
>>>to combing the two sub-options, which you claim introduces
>>>complexity.
>>>
>>
>>Not at all. If you look at the structure of the sub-option, Preferences
>>do not have a value in the AVP format while requirements do. So, any
>>(Requirement|Preference) without a specific value can be considered as a
>>wildcard for pre-filtering. No need for a flag.
>>
> 
> [Eunsoo] Hmm, when we thought about it, we thought we would add a flag in
> the sub-option header. Are you proposing putting just attribute ID values in
> the combined Requirement/Preference sub-option? So if the whole sub-option
> is used as Preferences, it contains a list of attribute IDs and if the whole
> sub-option is used as Requirements, it contains a list of AVPs. Is my
> understanding right? If you are suggesting it, then the sub-option should
> have a flag indicating the usage. Otherwise the receiver cannot decode the
> sub-option.
>
No, I don't think it has to be that complicated. As a MN, I include a 
single "Requirement" sub-option with a list of the capabilities that I'm 
interested in. Each capability is encoded as an AVP. If I have a 
particular constraint on a given requirement, then there will be a Data 
field present in the AVP. Otherwise, the AVP will simply be the 
attribute that I'm interested in.

 From the AR's perspective, parsing the single "Requirement" sub-option 
is also straightforward. Everything listed should be returned to the MN 
if a matching capability exists. Anything listed that has a Data value 
should be considered when selecting appropriate CARs. This is almost 
exactly the way it is explained in Section 4:

    Optionally, the MN can provide its current AR with a list of
    capability attribute-value pairs, indicating not only the capability
    parameters (attributes) as required for capability pre-filtering,
    but also a specific value for a particular capability. This allows
    the MN's current AR performing CAR pre-filtering and to send only
    address and capability information of CARs, whose capability values
    meet the requirements of the MN, back to the requesting MN. The
    format of this optional Requirements message parameter is described
    in section 5.1.3.3.

>>But Eunsoo, please don't be purposefully combative. Flags do not
>>introduce undo complexity by themselves. In the previous instance, I was
>>primarily concerned that the flag indicates the existence of an extra
>>field in the middle of the message structure which then changes the
>>offsets of subsequent fields.
> 
> [Eunsoo] Bob, I am not purposefully combative. I am just delivering my
> technical thought in response to your comments.
> 
>>>I am neutral about this issue. But I don't think having two separate
>>> sub-options make the protocol a bit more complex.
>>>
>>
>>As a side note, why does it specify in Section 5.1.1 that the
>>Preferences sub-option is "used only in case of performing
>>         optional capability pre-filtering". It really has no impact on
>>pre-filtering, does it? My understanding is that it simply states which
>>capabilities should be returned in the reply message.
> 
> [Eunsoo] Pre-filtering means what you said, that is, the AR returns only the
> capabilities requested in the Preferences sub-option rather than all the
> capability information. Do you think "pre-filtering" in the draft is not
> clear enough? If then, how can we make it clearer?
> 
This was a mis-understanding on my part. In the past, we had use 
pre-filtering to refer to the precess of choosing a set of CARS at the 
AR. I see now that you are using it to indicate filtering of the 
returned capabilities.

ttyl,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 24 08:12:18 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 IAA03437
	for <seamoby-archive@odin.ietf.org>; Thu, 24 Jul 2003 08:12:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fewp-0007y0-DR
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 08:11:51 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OCBpOj030620
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 08:11:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fewp-0007xn-Ad
	for seamoby-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 08:11: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 IAA03422
	for <seamoby-web-archive@ietf.org>; Thu, 24 Jul 2003 08:11:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19fewo-0005YU-00
	for seamoby-web-archive@ietf.org; Thu, 24 Jul 2003 08:11:50 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19fewi-0005YP-00
	for seamoby-web-archive@ietf.org; Thu, 24 Jul 2003 08:11:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19few0-0007vQ-RJ; Thu, 24 Jul 2003 08:11:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fev7-0007uU-8U
	for seamoby@optimus.ietf.org; Thu, 24 Jul 2003 08:10: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 IAA03368
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 08:10:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19fev6-0005Xf-00
	for seamoby@ietf.org; Thu, 24 Jul 2003 08:10:04 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19feuv-0005W4-00
	for seamoby@ietf.org; Thu, 24 Jul 2003 08:09:53 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6OC7KVI047461
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 14:07:23 +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 1B9439866E
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 13:47:18 +0200 (CEST)
Message-ID: <3F1FCBF8.6000301@ccrle.nec.de>
Date: Thu, 24 Jul 2003 14:07:20 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD issue#29: more text on use of "Context-ID" and "M-flag"required
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi all,

going through the remaining open issues, there are some
important ones, which have not been discussed during the
meeting in Vienna. Here is one: 

There was a comment that more text w.r.t use of Context-ID
and the M-flag is required. The proposal is to briefly describe
the mechanism again and to solicit comments. After having agreed 
on a mechanism, more text will be added to the document.
Please find a desciption/example of the proposed mechanism below:

Since the L2 ID, a CAR's IP address and associated capabilities come
with separate sub-options in a CARD Request/Reply message,
association is indicated using a Context-ID.
Example:

MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR
in a CARD Request for resolution:

CARD Request (MN->AR)
L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1
L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2

Now, first assume both L2_IDs (APs) connect to 2 different
CARs, hence, associated IP address and capability container
is identified with the respective Context-ID :

CARD Reply (AR->MN)
IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
IP address of CAR(2) comes with capability container(2), both carry Context-ID=2.

Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR:
IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
L2_ID(2) comes back with "Context-ID=1", "M-flag=1".

M-flag avoids to send IP address and capability container of the same CAR
back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed
to Context-ID=1, M-flag indicates that Context-ID has been modified by the
AR and that associated CAR IP address and associated capability container
is the same as for a previously received IP-address/capability
container pair, here indicated with Context-ID=1.

Comments?

marco





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 24 10:07:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07383
	for <seamoby-archive@odin.ietf.org>; Thu, 24 Jul 2003 10:07:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fgkY-0006tn-My
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 10:07:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OE7IP9026513
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 10:07:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fgkY-0006tY-Ho
	for seamoby-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 10:07:18 -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 KAA07322
	for <seamoby-web-archive@ietf.org>; Thu, 24 Jul 2003 10:07:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fgjK-0006gt-4x; Thu, 24 Jul 2003 10: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 19fgij-0006fG-Rb
	for seamoby@optimus.ietf.org; Thu, 24 Jul 2003 10:05: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 KAA07052
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 10:05:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19fgih-0006Fg-00
	for seamoby@ietf.org; Thu, 24 Jul 2003 10:05:23 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19fgiW-0006Ex-00
	for seamoby@ietf.org; Thu, 24 Jul 2003 10:05:12 -0400
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6OE4aVI055282
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 16:04: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 AAE4710FE7
	for <seamoby@ietf.org>; Thu, 24 Jul 2003 15:44:32 +0200 (CEST)
Message-ID: <3F1FE773.7090703@ccrle.nec.de>
Date: Thu, 24 Jul 2003 16:04:35 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
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 <seamoby@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CARD issue#30: L2 type indicators to be assigned by IANA
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

One of the comments to the L2 ID sub-option was that
"L2-type" identifiers need to be assigned by IANA.
Now, I assume that in case we ask IANA for type
identifiers, we need to give also a list of interface
types. This lists needs then to be extended later for
future technologies...
I am not sure if this is really required for the
experimental protocol. Take into account that using
the L2-type identifier has been indicated to be
optional.

Comments?

marco 



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Thu Jul 24 14:45:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20944
	for <seamoby-archive@odin.ietf.org>; Thu, 24 Jul 2003 14: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 19fl5W-0005Zr-O0
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 14:45:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIjE5B021435
	for seamoby-archive@odin.ietf.org; Thu, 24 Jul 2003 14:45:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fl5W-0005Ze-LD
	for seamoby-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 14:45: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 OAA20934
	for <seamoby-web-archive@ietf.org>; Thu, 24 Jul 2003 14:45:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19fl5T-0000pC-00
	for seamoby-web-archive@ietf.org; Thu, 24 Jul 2003 14:45:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19fl5M-0000p9-00
	for seamoby-web-archive@ietf.org; Thu, 24 Jul 2003 14:45:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19fl4L-0005Xl-4x; Thu, 24 Jul 2003 14: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 19fktH-000556-3F
	for seamoby@optimus.ietf.org; Thu, 24 Jul 2003 14:32: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 OAA20308;
	Thu, 24 Jul 2003 14:32:29 -0400 (EDT)
Message-Id: <200307241832.OAA20308@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: Thu, 24 Jul 2003 14:32:29 -0400
Subject: [Seamoby] I-D ACTION:draft-satish-l2-mobilereq-01.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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: L2 considerations for optimized IP mobility
	Author(s)	: S. Jamadagni
	Filename	: draft-satish-l2-mobilereq-01.txt
	Pages		: 8
	Date		: 2003-7-24
	
IP mobility protocols have traditionally been designed to be
independent of any L2 considerations.  A critical factor in achieving
good performance for IP mobility protocols is its closeness to an L2
handover. Handover occurs when a Mobile Node moves from one radio
access Point to another. If the new radio access point is associated
with a new subnet, the routing reachability change will have to reflect
at the access routers. Better synchronization between L2 handover and
L3 handover are still more important when supporting fast handoff
between two wireless domains. This draft discusses the L2 handover
steps and the possible coupling of L2 and L3 layers to support optimize
layer 3 handover. This draft also explores the location information as
a possible L2 trigger to support optimized L3 handover. Also an L2
trigger message format is defined which can be handled at L3
independent of other protocol considerations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-satish-l2-mobilereq-01.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-satish-l2-mobilereq-01.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-satish-l2-mobilereq-01.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-7-24122502.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-satish-l2-mobilereq-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-satish-l2-mobilereq-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-7-24122502.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sat Jul 26 15:03: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 PAA15234
	for <seamoby-archive@odin.ietf.org>; Sat, 26 Jul 2003 15:03: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 19gUJg-0001Cy-2t
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:03:00 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6QJ2qID004633
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:02:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUJf-0001Cb-VD
	for seamoby-web-archive@optimus.ietf.org; Sat, 26 Jul 2003 15:02: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 PAA15172
	for <seamoby-web-archive@ietf.org>; Sat, 26 Jul 2003 15:02:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJc-0004Jo-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:48 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJb-0004Jf-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUIs-0000z1-6S; Sat, 26 Jul 2003 15:02:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUIX-0000yP-FU
	for seamoby@optimus.ietf.org; Sat, 26 Jul 2003 15:01: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 PAA15135
	for <seamoby@ietf.org>; Sat, 26 Jul 2003 15:01:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUIU-0004Iy-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01:38 -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 19gUIT-0004Iu-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01:37 -0400
Message-ID: <016e01c353a8$59b08e60$2a6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Hemant Chaskar" <hchaskar@hotmail.com>, <vijayd@iprg.nokia.com>
Cc: <ASINGH1@motorola.com>, <pcalhoun@airespace.com>, <seamoby@ietf.org>
References: <BAY2-F32mAzZnPVbDI800008ead@hotmail.com>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Sat, 26 Jul 2003 14:55:11 +0200
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree.

            jak

----- Original Message ----- 
From: "Hemant Chaskar" <hchaskar@hotmail.com>
To: <vijayd@IPRG.nokia.com>
Cc: <ASINGH1@motorola.com>; <pcalhoun@airespace.com>;
<kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Monday, July 21, 2003 7:37 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


> Hi all,
>
> Does WG agree to text provided by Vijay? Pat, James could you do consensus
> call on this text.
>
> Hemant
>
> >From: Vijay Devarapalli <vijayd@IPRG.nokia.com>
> >To: Hemant Chaskar <hchaskar@hotmail.com>
> >CC: ASINGH1@motorola.com, pcalhoun@airespace.com,
kempf@docomolabs-usa.com,
> >        seamoby@ietf.org
> >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> >Date: Mon, 21 Jul 2003 09:37:26 -0700
> >
> >
> >I already provided the text when I reviewed the CARD protocol.
> >
> >   The MN MUST send only one CARD Request per
> >   CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES.
> >   If the MN sends requests more frequently, the AR SHOULD drop the
> >   CARD requests and not process them.
> >
> >and add to the constants section
> >
> >   CARD_RETRANSMISSION_INTERVAL  1 second
> >   CARD_MAX_RETRIES              3
> >
> >this is similar to ICMP rate limiting.
> >
> >TCP rate limiting is different, not applicable here. in general
> >in any protocol where there is a request and a reply (and no
> >more messages), ICMP rate limiting is best suited. you dont have
> >to "source-quench" the Mobile Node. :)
> >
> >Vijay
> >
> >Hemant Chaskar wrote:
> > >
> > > Dear Vijay,
> > >
> > > Could you provide a text to be included in the draft on rate limiting.
> >We
> > > can include it in the draft after discussing it over mailing list. It
> > > probably wont suffice to say that rate limiting is in lot of protocols
> >and
> > > hence not needed here. Different protocols use different rate
limiting.
> >E.g.
> > > TCP uses rate limiting, but it wont be appropriate for CARD.
> > >
> > > If you are proposing to limit the rate by simply enforcing limit on
> > > aggregate rate of requests, I can easily argue that it is ineffective.
> >So
> > > the question is: Wheater WG wants per MN rate limiting? If so, does it
> >have
> > > to be using R flag or using limit on per-MN rate of request? And then,
> >you
> > > can refer us to protocol that uses that type of rate limiting and we
> >will
> > > simply refer to it - will save lot of writing.
> > >
> > > Hemant
> > >
> > > >From: Vijay Devarapalli <vijayd@iprg.nokia.com>
> > > >To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
> > > >CC: "Pat R. Calhoun" <pcalhoun@airespace.com>,
> >kempf@docomolabs-usa.com,
> > > >     seamoby@ietf.org
> > > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> > > >Date: Fri, 18 Jul 2003 15:39:12 -0700
> > > >
> > > >Singh Ajoy-ASINGH1 wrote:
> > > > >
> > > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do
> >about
> > > >potential Dos issues? WG consensus is to Keep the R-flag approach.
> >Meeting
> > > >consensus is to add clarifying text to section 4.2 (4.3?)
> > > > >
> > > > > this is wrong, IMHO. rate limiting is a well known mechanism.
> > > > > introducing a new flag is not a bright idea.
> > > > >
> > > > > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > > > > issue but I am not convinced why using R bit is worse than
> > > > > your proposed solution.
> > > >
> > > >simple. rate-limiting is implemented in a wide variety of
> > > >protocols (infact for any message that creates state at
> > > >the receiving node). nothing new here. you dont need a new
> > > >mechanism for this.
> > > >
> > > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP.
> >The
> > > >editor recommends the use of ICMP to make it consistent with the
mobile
> > > >interface. Potential downsides: ICMP has potential security
> >implications.
> > > >ICMP message types on binding is also very implementation specific.
> >Also,
> > > >securing ICMP would require that all ICMP packets be secured. Meeting
> > > >consensus is to keep UDP.
> > > > >
> > > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > > > > options lets you piggyback these options on FMIPv6 messages.
> > > > > I am not sure how you can achieve piggybacking if the MN-AR
> > > > > signaling becomes UDP. ICMP was the right choice between
> > > > > the MN and the AR.
> > > > >
> > > > > AJOY-> Well I did not attend IETF meeting, but I guess this means
> >ICMP
> > > >for
> > > > > MN-AR and UDP for AR-AR interface. Others' please correct me.
> > > >
> > > >oops... I misunderstood. I thought the concensus at the
> > > >meeting was to use UDP for both.
> > > >
> > > > > BTW, why are you in favor of
> > > > > using ICMP for AR-AR interface?
> > > >
> > > >otherwise you need seperate code for processing an ICMP
> > > >CARD Request (from the MN) and UDP CARD Request (from
> > > >the PAR). also, if it is an ICMP message, I can piggyback
> > > >CARD messages on HI/HACK messages of FMIPv6.
> > > >
> > > >
> > > > > unbelievable. the CARD protocol is already complicated (IMO).
> > > > > the emphasis should be on reducing the complexity. just use
> > > > > a value of infinity for the lifetime field to indicate a
> > > > > static capability. any other value for the lifetime indicates
> > > > > dynamic capability. I think for the CARD protocol, emphasis
> > > > > should be on making it a simpler protocol than saving 4 bytes
> > > > > over the air. :)
> > > > >
> > > > > if you are concerned about an overhead of 4 bytes, make the
> > > > > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > > > > 65536 seconds which should be enough. do you need a 4 byte
> > > > > lifetime field?
> > > > >
> > > > > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > > > > huge saving for bandwidth constraint network. I am not sure
> > > > > processing one flag will make CARD protocol any more complicated.
> > > > > Btw, in cellular standard I have seen even more complicated
> > > > > procedure for saving 4 bits per frame. Please note that
> > > > > the CARD protocol is being proposed as an experimental
> > > > > protocol so we will have opportunity to make such
> > > > > changes in future if required.
> > > >
> > > >but in the current form not many people are going to use
> > > >it. it might remain forever as an experimental, untouched,
> > > >ignored, just another RFC.... that is something we should
> > > >avoid. I want a protocol that I can use. :)
> > > >
> > > >Vijay
> > > >
> > > >_______________________________________________
> > > >Seamoby mailing list
> > > >Seamoby@ietf.org
> > > >https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > > _________________________________________________________________
> > > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > > http://join.msn.com/?page=features/featuredemail
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sat Jul 26 15:03: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 PAA15264
	for <seamoby-archive@odin.ietf.org>; Sat, 26 Jul 2003 15:03: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 19gUJg-0001Cn-1a
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:03:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6QJ2qEs004626
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:02:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUJf-0001CW-SJ
	for seamoby-web-archive@optimus.ietf.org; Sat, 26 Jul 2003 15:02: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 PAA15168
	for <seamoby-web-archive@ietf.org>; Sat, 26 Jul 2003 15:02:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJc-0004Jr-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:48 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJb-0004Jg-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUIr-0000yt-Ph; Sat, 26 Jul 2003 15:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUIM-0000yH-0F
	for seamoby@optimus.ietf.org; Sat, 26 Jul 2003 15:01: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 PAA15132
	for <seamoby@ietf.org>; Sat, 26 Jul 2003 15:01:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUIJ-0004Io-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01: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 19gUII-0004Il-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01:26 -0400
Message-ID: <016c01c353a8$509f63a0$2a6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
        "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
Cc: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>,
        "Pat R. Calhoun" <pcalhoun@airespace.com>, <seamoby@ietf.org>
References: <35DBB8B7AC89D4118E98009027B1009B1221A245@IL27EXM10.cig.mot.com> <3F187710.BDC73048@iprg.nokia.com> <3F1BE374.6070409@ccrle.nec.de> <3F1C197E.7A057B67@iprg.nokia.com>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Sat, 26 Jul 2003 14:50:21 +0200
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree with Vijay on the flag. If the design says that a well behaved
mobile should rate limit sends, and also that a router should rate limit
replies to prevent a DoS attack, there should be no need for the flag.

W.r.t. the interrouter protocol, if the two routers MUST have an IPsec SA,
any DoS packets will get dropped in the IPsec filtering, unless, of course,
the other router is compromised (and then the network operator has a lot
more problems than CARD).

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
Cc: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>; "Pat R. Calhoun"
<pcalhoun@airespace.com>; <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Monday, July 21, 2003 6:49 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


> Marco Liebsch wrote:
> >
>
> > I see your point. However, I don't see a reason why the flag as
> > flow-control indicator
> > should not work. Maybe there is also a benefit from implementation point
> > of view on
> > the MN. In case of having a flag, MN is notified when exceeding the
> > request rate. Of course,
> > AR has to maintain a per-MN state. Furthermore, rules have to be
> > specified for MNs
> > on how to behave when CARD Reply indicates exceeding rate. But from
> > implementation point
> > of view, this does not look very complicated on the MN side. However,
> > having a
> > "n-requests allowed per second"-rule on the MN, this needs to be
> > controlled and
> > implemented on the MN side, which looks like requiring a bit more effort
> >
> > Alternative proposal was to indicate a maximum rate for a particular AR
> > in the
> > first CARD Reply. This keeps individual request rates flexible and
avoids
> > defining static numbers.
>
> see my reply to Hemant.
>
> >  From complexity and implementation point of view, I don't really
> > understand why
> > the proposed mechanism makes the protocol complex? I don't see
> > any difference between having a check on the lifetime (==0x00000000?)
> > and in case it's
> > zero assume the capability to be static, and having a check on a
> > specific flag (flag == 1?),
> > indicating a static capability, hence, no lifetime field is present but
> > "value" descriptor
> > follows immediately.
> > But if there are any further argumements and concerns, we can again
> > think about it.
>
> :) a new flag means extra fields in the data structure,
> extra code to check the flag, set the flag... you
> already have the lifetime field. and you would be anyway
> checking the value of the lifetime field everytime you
> receive a capability parameter. I would generally avoid
> introducing additional flags.
>
> and this comment
>
> >but in the current form not many people are going to use
> >it. it might remain forever as an experimental, untouched,
> >ignored, just another RFC.... that is something we should
> >avoid. I want a protocol that I can use. :)
>
> was a specific reply to Ajoy's
>
> >>Btw, in cellular standard I have seen even more complicated
> >>procedure for saving 4 bits per frame
>
> 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  Sat Jul 26 15:49:03 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 PAA15235
	for <seamoby-archive@odin.ietf.org>; Sat, 26 Jul 2003 15:03: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 19gUJg-0001DD-6i
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:03:00 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6QJ2q6q004653
	for seamoby-archive@odin.ietf.org; Sat, 26 Jul 2003 15:02:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUJg-0001Cx-31
	for seamoby-web-archive@optimus.ietf.org; Sat, 26 Jul 2003 15:02: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 PAA15171
	for <seamoby-web-archive@ietf.org>; Sat, 26 Jul 2003 15:02:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJc-0004Ju-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:48 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUJb-0004Ji-00
	for seamoby-web-archive@ietf.org; Sat, 26 Jul 2003 15:02:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUIr-0000yk-Bl; Sat, 26 Jul 2003 15:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gUI8-0000xN-Lu
	for seamoby@optimus.ietf.org; Sat, 26 Jul 2003 15:01: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 PAA15127
	for <seamoby@ietf.org>; Sat, 26 Jul 2003 15:01:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUI5-0004Ie-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01:13 -0400
Received: from key1.docomolabs-usa.com
	([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser)
	by ietf-mx with esmtp (Exim 4.12)
	id 19gUI4-0004Ib-00
	for seamoby@ietf.org; Sat, 26 Jul 2003 15:01:13 -0400
Message-ID: <016b01c353a8$4c8595a0$2a6015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
        "Hemant Chaskar" <hchaskar@hotmail.com>
Cc: <ASINGH1@motorola.com>, <pcalhoun@airespace.com>, <seamoby@ietf.org>
References: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com> <3F1C16C6.330CDA85@iprg.nokia.com>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Sat, 26 Jul 2003 14:46:05 +0200
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Vijay,

I think the router needs to rate limit too, don't you think? To prevent a
DoS attack?

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
To: "Hemant Chaskar" <hchaskar@hotmail.com>
Cc: <ASINGH1@motorola.com>; <pcalhoun@airespace.com>;
<kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Monday, July 21, 2003 6:37 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


>
> I already provided the text when I reviewed the CARD protocol.
>
>   The MN MUST send only one CARD Request per
>   CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES.
>   If the MN sends requests more frequently, the AR SHOULD drop the
>   CARD requests and not process them.
>
> and add to the constants section
>
>   CARD_RETRANSMISSION_INTERVAL  1 second
>   CARD_MAX_RETRIES              3
>
> this is similar to ICMP rate limiting.
>
> TCP rate limiting is different, not applicable here. in general
> in any protocol where there is a request and a reply (and no
> more messages), ICMP rate limiting is best suited. you dont have
> to "source-quench" the Mobile Node. :)
>
> Vijay
>
> Hemant Chaskar wrote:
> >
> > Dear Vijay,
> >
> > Could you provide a text to be included in the draft on rate limiting.
We
> > can include it in the draft after discussing it over mailing list. It
> > probably wont suffice to say that rate limiting is in lot of protocols
and
> > hence not needed here. Different protocols use different rate limiting.
E.g.
> > TCP uses rate limiting, but it wont be appropriate for CARD.
> >
> > If you are proposing to limit the rate by simply enforcing limit on
> > aggregate rate of requests, I can easily argue that it is ineffective.
So
> > the question is: Wheater WG wants per MN rate limiting? If so, does it
have
> > to be using R flag or using limit on per-MN rate of request? And then,
you
> > can refer us to protocol that uses that type of rate limiting and we
will
> > simply refer to it - will save lot of writing.
> >
> > Hemant
> >
> > >From: Vijay Devarapalli <vijayd@iprg.nokia.com>
> > >To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
> > >CC: "Pat R. Calhoun" <pcalhoun@airespace.com>,
kempf@docomolabs-usa.com,
> > >     seamoby@ietf.org
> > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> > >Date: Fri, 18 Jul 2003 15:39:12 -0700
> > >
> > >Singh Ajoy-ASINGH1 wrote:
> > > >
> > > > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do
about
> > >potential Dos issues? WG consensus is to Keep the R-flag approach.
Meeting
> > >consensus is to add clarifying text to section 4.2 (4.3?)
> > > >
> > > > this is wrong, IMHO. rate limiting is a well known mechanism.
> > > > introducing a new flag is not a bright idea.
> > > >
> > > > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > > > issue but I am not convinced why using R bit is worse than
> > > > your proposed solution.
> > >
> > >simple. rate-limiting is implemented in a wide variety of
> > >protocols (infact for any message that creates state at
> > >the receiving node). nothing new here. you dont need a new
> > >mechanism for this.
> > >
> > > > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP.
The
> > >editor recommends the use of ICMP to make it consistent with the mobile
> > >interface. Potential downsides: ICMP has potential security
implications.
> > >ICMP message types on binding is also very implementation specific.
Also,
> > >securing ICMP would require that all ICMP packets be secured. Meeting
> > >consensus is to keep UDP.
> > > >
> > > > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > > > options lets you piggyback these options on FMIPv6 messages.
> > > > I am not sure how you can achieve piggybacking if the MN-AR
> > > > signaling becomes UDP. ICMP was the right choice between
> > > > the MN and the AR.
> > > >
> > > > AJOY-> Well I did not attend IETF meeting, but I guess this means
ICMP
> > >for
> > > > MN-AR and UDP for AR-AR interface. Others' please correct me.
> > >
> > >oops... I misunderstood. I thought the concensus at the
> > >meeting was to use UDP for both.
> > >
> > > > BTW, why are you in favor of
> > > > using ICMP for AR-AR interface?
> > >
> > >otherwise you need seperate code for processing an ICMP
> > >CARD Request (from the MN) and UDP CARD Request (from
> > >the PAR). also, if it is an ICMP message, I can piggyback
> > >CARD messages on HI/HACK messages of FMIPv6.
> > >
> > >
> > > > unbelievable. the CARD protocol is already complicated (IMO).
> > > > the emphasis should be on reducing the complexity. just use
> > > > a value of infinity for the lifetime field to indicate a
> > > > static capability. any other value for the lifetime indicates
> > > > dynamic capability. I think for the CARD protocol, emphasis
> > > > should be on making it a simpler protocol than saving 4 bytes
> > > > over the air. :)
> > > >
> > > > if you are concerned about an overhead of 4 bytes, make the
> > > > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > > > 65536 seconds which should be enough. do you need a 4 byte
> > > > lifetime field?
> > > >
> > > > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > > > huge saving for bandwidth constraint network. I am not sure
> > > > processing one flag will make CARD protocol any more complicated.
> > > > Btw, in cellular standard I have seen even more complicated
> > > > procedure for saving 4 bits per frame. Please note that
> > > > the CARD protocol is being proposed as an experimental
> > > > protocol so we will have opportunity to make such
> > > > changes in future if required.
> > >
> > >but in the current form not many people are going to use
> > >it. it might remain forever as an experimental, untouched,
> > >ignored, just another RFC.... that is something we should
> > >avoid. I want a protocol that I can use. :)
> > >
> > >Vijay
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Sun Jul 27 02:47: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 CAA09749
	for <seamoby-archive@odin.ietf.org>; Sun, 27 Jul 2003 02:47: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 19gfJN-0000ur-Gy
	for seamoby-archive@odin.ietf.org; Sun, 27 Jul 2003 02:47:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6R6lH3m003513
	for seamoby-archive@odin.ietf.org; Sun, 27 Jul 2003 02:47:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gfJM-0000ua-J2
	for seamoby-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 02:47: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 CAA09710
	for <seamoby-web-archive@ietf.org>; Sun, 27 Jul 2003 02:47:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gfJI-0001UM-00
	for seamoby-web-archive@ietf.org; Sun, 27 Jul 2003 02:47:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19gfJH-0001UJ-00
	for seamoby-web-archive@ietf.org; Sun, 27 Jul 2003 02:47:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gfJ8-0000t0-AS; Sun, 27 Jul 2003 02:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19gfIS-0000s1-59
	for seamoby@optimus.ietf.org; Sun, 27 Jul 2003 02:46:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09701
	for <seamoby@ietf.org>; Sun, 27 Jul 2003 02:46:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19gfIO-0001U1-00
	for seamoby@ietf.org; Sun, 27 Jul 2003 02:46: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 19gfIN-0001Ty-00
	for seamoby@ietf.org; Sun, 27 Jul 2003 02:46:15 -0400
Message-ID: <000101c3540a$cc2615c0$116015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>, "Seamoby" <seamoby@ietf.org>
References: <3F1FE773.7090703@ccrle.nec.de>
Subject: Re: [Seamoby] CARD issue#30: L2 type indicators to be assigned by IANA
Date: Sat, 26 Jul 2003 21:53:20 +0200
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Experimental protocols also may request IANA assignments. W.r.t. whether an
L2 identifier is needed or not, I would suggest checking to see if there is
one already that can be reused, and, if not, put in a request for one.

            jak

----- Original Message ----- 
From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
To: "Seamoby" <seamoby@ietf.org>
Sent: Thursday, July 24, 2003 4:04 PM
Subject: [Seamoby] CARD issue#30: L2 type indicators to be assigned by IANA


> One of the comments to the L2 ID sub-option was that
> "L2-type" identifiers need to be assigned by IANA.
> Now, I assume that in case we ask IANA for type
> identifiers, we need to give also a list of interface
> types. This lists needs then to be extended later for
> future technologies...
> I am not sure if this is really required for the
> experimental protocol. Take into account that using
> the L2-type identifier has been indicated to be
> optional.
>
> Comments?
>
> marco
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 28 12:59: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 MAA12370
	for <seamoby-archive@odin.ietf.org>; Mon, 28 Jul 2003 12:59:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hBL9-0006W3-1T
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 12:59:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SGxFNO025041
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 12:59:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hBL8-0006Vo-Tm
	for seamoby-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 12: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 MAA12331
	for <seamoby-web-archive@ietf.org>; Mon, 28 Jul 2003 12:59:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hBL7-0005hc-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 12:59:13 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19hBL6-0005hY-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 12:59:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hBKu-0006V8-MX; Mon, 28 Jul 2003 12: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 19hBKd-0006Uk-Ul
	for seamoby@optimus.ietf.org; Mon, 28 Jul 2003 12:58: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 MAA12315
	for <seamoby@ietf.org>; Mon, 28 Jul 2003 12:58:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hBKc-0005hR-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 12:58:42 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hBKb-0005hI-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 12:58:41 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00912;
	Mon, 28 Jul 2003 09:58:10 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6SGwAo19323;
	Mon, 28 Jul 2003 09:58:10 -0700
X-mProtect: <200307281658> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdkduA9k; Mon, 28 Jul 2003 09:58:09 PDT
Message-ID: <3F255621.F8CBFB02@iprg.nokia.com>
Date: Mon, 28 Jul 2003 09:58:09 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
References: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com> <3F1C16C6.330CDA85@iprg.nokia.com> <016b01c353a8$4c8595a0$2a6015ac@dclkempt40>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

James Kempf wrote:
> 
> Hi Vijay,
> 
> I think the router needs to rate limit too, don't you think? To prevent a
> DoS attack?


I am not too worried about rate-limiting AR-AR signaling
since the signaling has to be authenticated by IPsec. also
the ARs dont have to process requests from arbitrary access
routers.

Vijay

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 28 15:14:48 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 PAA17485
	for <seamoby-archive@odin.ietf.org>; Mon, 28 Jul 2003 15:14:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDRs-0003ji-Sr
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 15:14:21 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJEKSM014360
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 15:14:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDRs-0003jX-Nt
	for seamoby-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:14:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17439
	for <seamoby-web-archive@ietf.org>; Mon, 28 Jul 2003 15:14:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDRr-0006sO-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 15:14:19 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDRq-0006sL-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 15:14:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDRZ-0003ik-8Q; Mon, 28 Jul 2003 15:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDRC-0003iI-DP
	for seamoby@optimus.ietf.org; Mon, 28 Jul 2003 15:13: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 PAA17378
	for <seamoby@ietf.org>; Mon, 28 Jul 2003 15:13:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDRB-0006sI-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 15:13:37 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDR9-0006s0-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 15:13:36 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA28313;
	Mon, 28 Jul 2003 12:13:04 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6SJD3h01707;
	Mon, 28 Jul 2003 12:13:03 -0700
X-mProtect: <200307281913> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQYxp0O; Mon, 28 Jul 2003 12:13:01 PDT
Message-ID: <3F2575BD.BE68E5D2@iprg.nokia.com>
Date: Mon, 28 Jul 2003 12:13:01 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Seamoby <seamoby@ietf.org>
Subject: Re: [Seamoby] CARD issue#29: more text on use of "Context-ID" and 
 "M-flag"required
References: <3F1FCBF8.6000301@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I am against using this mechanism. why not just include
the L2_ID suboption in the CARD reply too? ofcourse it
would increase the number of bytes in the CARD reply,
but I think it helps in reducing the overall complexity
of the CARD protocol.

Vijay

Marco Liebsch wrote:
> 
> Hi all,
> 
> going through the remaining open issues, there are some
> important ones, which have not been discussed during the
> meeting in Vienna. Here is one:
> 
> There was a comment that more text w.r.t use of Context-ID
> and the M-flag is required. The proposal is to briefly describe
> the mechanism again and to solicit comments. After having agreed
> on a mechanism, more text will be added to the document.
> Please find a desciption/example of the proposed mechanism below:
> 
> Since the L2 ID, a CAR's IP address and associated capabilities come
> with separate sub-options in a CARD Request/Reply message,
> association is indicated using a Context-ID.
> Example:
> 
> MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR
> in a CARD Request for resolution:
> 
> CARD Request (MN->AR)
> L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1
> L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2
> 
> Now, first assume both L2_IDs (APs) connect to 2 different
> CARs, hence, associated IP address and capability container
> is identified with the respective Context-ID :
> 
> CARD Reply (AR->MN)
> IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
> IP address of CAR(2) comes with capability container(2), both carry Context-ID=2.
> 
> Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR:
> IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
> L2_ID(2) comes back with "Context-ID=1", "M-flag=1".
> 
> M-flag avoids to send IP address and capability container of the same CAR
> back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed
> to Context-ID=1, M-flag indicates that Context-ID has been modified by the
> AR and that associated CAR IP address and associated capability container
> is the same as for a previously received IP-address/capability
> container pair, here indicated with Context-ID=1.
> 
> Comments?
> 
> marco
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Mon Jul 28 15:23:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17849
	for <seamoby-archive@odin.ietf.org>; Mon, 28 Jul 2003 15:23: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 19hDaS-0003zx-DD
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 15:23:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJNCkw015363
	for seamoby-archive@odin.ietf.org; Mon, 28 Jul 2003 15:23:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDaS-0003zi-90
	for seamoby-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:23: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 PAA17846
	for <seamoby-web-archive@ietf.org>; Mon, 28 Jul 2003 15:23:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDaR-0006wC-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 15:23:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDaQ-0006w9-00
	for seamoby-web-archive@ietf.org; Mon, 28 Jul 2003 15:23:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDaG-0003wp-RS; Mon, 28 Jul 2003 15:23:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hDZQ-0003ud-9W
	for seamoby@optimus.ietf.org; Mon, 28 Jul 2003 15:22: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 PAA17804
	for <seamoby@ietf.org>; Mon, 28 Jul 2003 15:22:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDZP-0006ux-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 15:22:07 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hDZN-0006un-00
	for seamoby@ietf.org; Mon, 28 Jul 2003 15:22:06 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA29564;
	Mon, 28 Jul 2003 12:21:35 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6SJLYk16401;
	Mon, 28 Jul 2003 12:21:34 -0700
X-mProtect: <200307281921> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdTxI2wU; Mon, 28 Jul 2003 12:21:32 PDT
Message-ID: <3F2577BD.EC02A19D@iprg.nokia.com>
Date: Mon, 28 Jul 2003 12:21:33 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
CC: Seamoby <seamoby@ietf.org>
Subject: Re: [Seamoby] CARD issue#30: L2 type indicators to be assigned by IANA
References: <3F1FE773.7090703@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I dont see any other option. IANA assignment is needed.
otherwise how can the AR and the MN agree to the same
type values for different types of interfaces?

> 
> One of the comments to the L2 ID sub-option was that
> "L2-type" identifiers need to be assigned by IANA.
> Now, I assume that in case we ask IANA for type
> identifiers, we need to give also a list of interface
> types. This lists needs then to be extended later for
> future technologies...

this means there is a fundamental problem. maybe you
should remove the L2 type field from the L2_ID suboption.
it is considered optional already. the Sub-Option Len
can indicate the length of the L2 ID field.

> I am not sure if this is really required for the
> experimental protocol. Take into account that using
> the L2-type identifier has been indicated to be
> optional.
> 
> Comments?
> 
> marco
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby



From exim@www1.ietf.org  Tue Jul 29 04:53: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 EAA16017
	for <seamoby-archive@odin.ietf.org>; Tue, 29 Jul 2003 04:53:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hQEN-0002zP-Lf
	for seamoby-archive@odin.ietf.org; Tue, 29 Jul 2003 04:53:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T8rFh6011486
	for seamoby-archive@odin.ietf.org; Tue, 29 Jul 2003 04:53:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hQEN-0002zB-H7
	for seamoby-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 04:53: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 EAA16005
	for <seamoby-web-archive@ietf.org>; Tue, 29 Jul 2003 04:53:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hQEJ-0003ao-00
	for seamoby-web-archive@ietf.org; Tue, 29 Jul 2003 04:53:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19hQEI-0003al-00
	for seamoby-web-archive@ietf.org; Tue, 29 Jul 2003 04:53:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hQE9-0002wo-1c; Tue, 29 Jul 2003 04:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19hQDP-0002uf-IU
	for seamoby@optimus.ietf.org; Tue, 29 Jul 2003 04:52: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 EAA15984
	for <seamoby@ietf.org>; Tue, 29 Jul 2003 04:52:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19hQDM-0003aQ-00
	for seamoby@ietf.org; Tue, 29 Jul 2003 04:52:12 -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 19hQDL-0003aM-00
	for seamoby@ietf.org; Tue, 29 Jul 2003 04:52:11 -0400
Message-ID: <013a01c355ae$bb7df350$036015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
Cc: <seamoby@ietf.org>
References: <BAY2-F152bC8wSA1Xvp0001ee9b@hotmail.com> <3F1C16C6.330CDA85@iprg.nokia.com> <016b01c353a8$4c8595a0$2a6015ac@dclkempt40> <3F255621.F8CBFB02@iprg.nokia.com>
Subject: Re: [Seamoby] (virtual) hum on CARD open issues
Date: Tue, 29 Jul 2003 10:52:21 +0200
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: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer,
	Handoff Candidate Discovery,
	and Dormant Mode Host Alerting  <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>,
	<mailto:seamoby-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I meant that the router needs to rate limit the mobile's traffic. That is,
if it starts getting too many CARD requests, it starts selectively dropping.
Sorry.

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: <seamoby@ietf.org>
Sent: Monday, July 28, 2003 6:58 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


> James Kempf wrote:
> >
> > Hi Vijay,
> >
> > I think the router needs to rate limit too, don't you think? To prevent
a
> > DoS attack?
>
>
> I am not too worried about rate-limiting AR-AR signaling
> since the signaling has to be authenticated by IPsec. also
> the ARs dont have to process requests from arbitrary access
> routers.
>
> Vijay
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby