FW: Request to review Location Privacy document

=20=20Cc:=20heejin.jang@samsung.com= =20 =20=20Sent:=20Saturday,=20No= vember=2003,=202007=205:35=20 =20=20AM =20=20Subject:=20[Mobopts]= =20FW:=20Request=20to=20review=20 =20=20Location=20Privacy=20document =20=20

Hi,

Review=20from=20Heejin= =20Jang.

Thanks=20 =20=20Heejin.

-Rajeev
--=20
http://people.nokia.net/~r= ajeev=20 =20=20

------=20Forwarded=20Message
From:=20ext= =20Heejin=20Jang=20 =20=20<heejin.jang@samsung.com= >
Reply-To:=20 =20=20<heejin.jang@samsung.com= >
Date:=20 =20=20Fri,=202=20Nov=202007=2000:45:46=20-0500
To:=20"Koodl= i=20Rajeev=20(NSN=20-=20US/Palo=20 =20=20Alto)"=20<rajeev.koodli@nokia.com= >
Conversation:=20 =20=20Request=20to=20review=20Location=20Privacy=20document
Sub= ject:=20Re:=20Request=20 =20=20to=20review=20Location=20Privacy=20document

Hi,=20Rajeev.
I=20reviewed=20the=20 =20=20document=20and
review=20results=20are=20in=20the=20attached=20fi= le.

The=20proposed=20 =20=20idea=20looks=20valuable,=20but
there=20is=20ambiguity=20in=20som= e=20description
which=20 =20=20needs=20to=20be=20clarified=20more.

ps>=20Because=20I'm= =20not=20so=20strong=20in=20the=20 =20=20security,
some=20comments=20may=20not=20be=20significant.
-=20 =20=20BR
Heejin.

------=20End=20of=20Forwarded=20Message =20=20

=20=20

_______________________________________________
Mobopts= =20mailing=20 =20=20list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/= mobopts

---------=
---=20Institute=20For=20Infocomm=20Research=20-=20Disclaimer=20----------=
---This=20email=20is=20confidential=20and=20may=20be=20privileged.=20=20I=
f=20you=20are=20not=20the=20intended=20recipient,=20please=20delete=20it=
=20and=20notify=20us=20immediately.=20Please=20do=20not=20copy=20or=20use=
=20it=20for=20any=20purpose,=20or=20disclose=20its=20contents=20to=20any=
=20other=20person.=20Thank=20you.----------------------------------------=
----------------

------=_NextPart_000_0606_01C820AC.1A8B7530-- --===============0853594155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0853594155==-- From mobopts-bounces@irtf.org Tue Nov 06 17:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXIs-0002YJ-S8; Tue, 06 Nov 2007 17:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXIs-0002YD-4j for mobopts@irtf.org; Tue, 06 Nov 2007 17:53:50 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpXIq-0003QB-82 for mobopts@irtf.org; Tue, 06 Nov 2007 17:53:50 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA6MrI0d029476; Wed, 7 Nov 2007 00:53:26 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 00:53:11 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 16:53:07 -0600 Received: from 10.162.253.2 ([10.162.253.2]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Nov 2007 22:53:07 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 06 Nov 2007 14:53:23 -0800 Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 From: Rajeev Koodli To: ext Vijay Devarapalli , , QIU Ying , Fan Zhao Message-ID: Thread-Topic: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 Thread-Index: Acggx9VYE+Y0RIy7EdyI8AAWy5YJpw== In-Reply-To: <472F9911.2050105@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 22:53:07.0442 (UTC) FILETIME=[CC12BD20:01C820C7] X-Nokia-AV: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Vijay, On 11/5/07 3:28 PM, "ext Vijay Devarapalli" wrote: > Hello, > > I reviewed the draft. It still needs a lot of work. > > Section 4.1 > ----------- > Section 4.1 is not making sense to me. The pseudo home address > changes every time return routability is run. It also changes > every time the CoA changes. Why does it have to change so often? > > Isn't one pseudo home address per session with a correspondent > node sufficient? > The pseudo HoA changing at each run of the RR provides some protection against profiling. Change of CoA upon handover, or a new CoA nonce index or a new RFC 3041 style CoA configuration makes a round of RR to be run. The pseudo HoA itself is not inducing new signaling, but a few computational steps. > Shouldn't the following be? > >> privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > privacy keygen token = First (64, HMAC_SHA1(Kcn, (Home Init Cookie | > nonce | 2)) Yes. Noted. > >> When a correspondent node receives a Binding Update with a new >> destination option carrying the pseudo home address, it must first >> compute Kpm as above. > > You probably meant "a destination option carrying a new pseudo home > address". The home address destination option is always present in > the BU. > Actually, there is a new Type number for the Destination Option containing the pseudo HoA, so that the CN can first compute the String and recover the HoA. >> The computation is similar to how it would >> compute Kbm, except that the privacy keygen token is computed with >> the home address set to all zeros. > > Earlier in section 4.1, the computation of privacy keygen token is > shown as > > privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > The home address is not used in this computation. So why is the home > address set to all zeros? > The text above (about HoA being set to zero) must be removed. It is still lingering around from the previous version. >> The correspondent node then >> stores the nonce indices, and Kbm itself. It may also send a normal >> Binding Acknowledgment to the mobile node. > > Wouldn't this defeat the purpose? The CN should include the pseudo > home address in the routing header in the binding ack. What does > "normal Binding Acknowledgment" mean? > "normal" means a regular Back, but you are right it should include the pseudo HoA. >> The privacy management key Kpm can be the same as the binding >> management key Kbm and the mobile node generates the pseudo home >> address as follows: >> >> pseudo home address = Enc(Kpm, home address) >> >> Where Enc(.) is a symmetric key encryption algorithm, for example, >> AES. > > hmm... You would need to pick *an* encryption algorithm and convey > the same to the CN. How would both ends pick the same algorithm > otherwise? Right. > > Section 5 > --------- > I am not sure why section 5 is needed at all. There is absolutely > no need to generate a pseudo home address with the home agent. The > MN can always use ESP in tunnel mode for MIPv6 signaling messages > and hide the home address from the access link. I suggest removing > sections 5.1, 5.2 and 5.3. > You mean in relation to Section 4, this offers no additional benefits? Thanks for the review. -Rajeev -- http://people.nokia.net/~rajeev > Section 5 also does not take into account scenarios where there > might not be a shared key between the MN and the HA. It also does > not account for scenarios where the home agent allocates a home > address for the mobile node as part of MIPv6 bootstrapping. > > I stopped reviewing here. :) > > Vijay > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Nov 06 19:06:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYRe-0002cK-Co; Tue, 06 Nov 2007 19:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYRd-0002cA-6P for mobopts@irtf.org; Tue, 06 Nov 2007 19:06:57 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpYRa-00062R-J9 for mobopts@irtf.org; Tue, 06 Nov 2007 19:06:57 -0500 Received: from [127.0.0.1] ([207.47.15.7]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 16:06:44 -0800 Message-ID: <4731017E.7020602@azairenet.com> Date: Tue, 06 Nov 2007 16:06:22 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 00:06:44.0971 (UTC) FILETIME=[15202BB0:01C820D2] X-Spam-Score: 0.8 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Fan Zhao , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev Koodli wrote: > Hi Vijay, > > > On 11/5/07 3:28 PM, "ext Vijay Devarapalli" > wrote: > >> Hello, >> >> I reviewed the draft. It still needs a lot of work. >> >> Section 4.1 >> ----------- >> Section 4.1 is not making sense to me. The pseudo home address >> changes every time return routability is run. It also changes >> every time the CoA changes. Why does it have to change so often? >> >> Isn't one pseudo home address per session with a correspondent >> node sufficient? >> > > The pseudo HoA changing at each run of the RR provides some protection > against profiling. Change of CoA upon handover, or a new CoA nonce index or > a new RFC 3041 style CoA configuration makes a round of RR to be run. The > pseudo HoA itself is not inducing new signaling, but a few computational > steps. Ok, but I am questioning the need for changing the pseudo home address every time the return routability signaling is done (every 420 seconds). >>> When a correspondent node receives a Binding Update with a new >>> destination option carrying the pseudo home address, it must first >>> compute Kpm as above. >> You probably meant "a destination option carrying a new pseudo home >> address". The home address destination option is always present in >> the BU. >> > Actually, there is a new Type number for the Destination Option containing > the pseudo HoA, so that the CN can first compute the String and recover the > HoA. Ok, got it. You would need add this new destination option to the IANA considerations section. It is empty currently. >>> The privacy management key Kpm can be the same as the binding >>> management key Kbm and the mobile node generates the pseudo home >>> address as follows: >>> >>> pseudo home address = Enc(Kpm, home address) >>> >>> Where Enc(.) is a symmetric key encryption algorithm, for example, >>> AES. >> hmm... You would need to pick *an* encryption algorithm and convey >> the same to the CN. How would both ends pick the same algorithm >> otherwise? > > Right. How is the information about the encryption algorithm conveyed? >> Section 5 >> --------- >> I am not sure why section 5 is needed at all. There is absolutely >> no need to generate a pseudo home address with the home agent. The >> MN can always use ESP in tunnel mode for MIPv6 signaling messages >> and hide the home address from the access link. I suggest removing >> sections 5.1, 5.2 and 5.3. >> > > You mean in relation to Section 4, this offers no additional benefits? More fundamental than that. Why would the mobile node want to use a pseudo home address with its home agent? Vijay > > Thanks for the review. > > -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Nov 07 06:22:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpizV-00089c-0k; Wed, 07 Nov 2007 06:22:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpizS-00087m-1B for mobopts@irtf.org; Wed, 07 Nov 2007 06:22:34 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpizK-0003bZ-3H for mobopts@irtf.org; Wed, 07 Nov 2007 06:22:34 -0500 Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E46D413B6CB; Wed, 7 Nov 2007 19:21:04 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id D4F2E13B665; Wed, 7 Nov 2007 19:21:04 +0800 (SGT) Received: from precision5570 ([192.168.137.163]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 19:21:27 +0800 Message-ID: <0d6f01c82130$2c8d8c80$a389a8c0@precision5570> From: "QIU Ying" To: , "Vijay Devarapalli" References: Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 Date: Wed, 7 Nov 2007 19:20:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 07 Nov 2007 11:21:27.0982 (UTC) FILETIME=[56E16CE0:01C82130] X-Spam-Score: -96.5 (---------------------------------------------------) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Fan Zhao X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, Vijay Thanks for your reviewing this draft. As per your 5 comments on section 5, below is my reply. 1. I am not sure why section 5 is needed at all. R: The target of the solution in section 4 is to hide MN's HoA from eavesdroppers. The solution uses the original RR procedure. So the CN could always bind the real HoA and CoA. It implies that CN can always track the MN movement. Moreover an eavesdropper on path HA-CN can know at least that the MN is outside of home network by capturing the HoTI message. Contrastively, the solution in section 5 tries to hide its real HoA from everyone, even from the CN. 2. There is absolutely no need to generate a pseudo home address with the home agent. The MN can always use ESP in tunnel mode for MIPv6 signaling messages and hide the home address from the access link. R: The pseudo home address is not generated for the home agent. It ensures that the RR procedure can be processed as usual and that not reveal real HoA. 3. Section 5 also does not take into account scenarios where there might not be a shared key between the MN and the HA. R: All of our proposals are focused on IP layer. In this case, all of the session keys have been established and shared already. The process of establishing the session keys on the upper layer, such as IKE, which is beyond our scope. 4. It also does not account for scenarios where the home agent allocates a home address for the mobile node as part of MIPv6 bootstrapping. R: Again, the purpose of these solutions is to protect the location privacy in IP layer. No matter how to allocate the home addresses, either stateful or stateless, the roles of home address in IP layer are the same - to identify the mobile nodes. Therefore, how to allocate home address does not affect the solution. 5. I suggest removing sections 5.1, 5.2 and 5.3. R: As above reasons, the answer is definitely NO :-) Regards and Thanks Qiu Ying ----- Original Message ----- From: "Rajeev Koodli" To: "QIU Ying" ; "Fan Zhao" Sent: Wednesday, November 07, 2007 6:54 AM Subject: FW: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 > > Qiu Ying and Fan, > > I hope you can answer Vijay's questions about Section 5. > > Thanks, > > -Rajeev > -- > http://people.nokia.net/~rajeev > > > > ------ Forwarded Message > From: ext Vijay Devarapalli > Date: Mon, 05 Nov 2007 14:28:33 -0800 > To: , QIU Ying , Fan Zhao > > Subject: [Mobopts] Review of > draft-irtf-mobopts-location-privacy-solutions-06 > > Hello, > > I reviewed the draft. It still needs a lot of work. > > Section 4.1 > ----------- > Section 4.1 is not making sense to me. The pseudo home address > changes every time return routability is run. It also changes > every time the CoA changes. Why does it have to change so often? > > Isn't one pseudo home address per session with a correspondent > node sufficient? > > Shouldn't the following be? > >> privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > privacy keygen token = First (64, HMAC_SHA1(Kcn, (Home Init Cookie | > nonce | 2)) > >> When a correspondent node receives a Binding Update with a new >> destination option carrying the pseudo home address, it must first >> compute Kpm as above. > > You probably meant "a destination option carrying a new pseudo home > address". The home address destination option is always present in > the BU. > >> The computation is similar to how it would >> compute Kbm, except that the privacy keygen token is computed with >> the home address set to all zeros. > > Earlier in section 4.1, the computation of privacy keygen token is > shown as > > privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > The home address is not used in this computation. So why is the home > address set to all zeros? > >> The correspondent node then >> stores the nonce indices, and Kbm itself. It may also send a normal >> Binding Acknowledgment to the mobile node. > > Wouldn't this defeat the purpose? The CN should include the pseudo > home address in the routing header in the binding ack. What does > "normal Binding Acknowledgment" mean? > >> The privacy management key Kpm can be the same as the binding >> management key Kbm and the mobile node generates the pseudo home >> address as follows: >> >> pseudo home address = Enc(Kpm, home address) >> >> Where Enc(.) is a symmetric key encryption algorithm, for example, >> AES. > > hmm... You would need to pick *an* encryption algorithm and convey > the same to the CN. How would both ends pick the same algorithm > otherwise? > > Section 5 > --------- > I am not sure why section 5 is needed at all. There is absolutely > no need to generate a pseudo home address with the home agent. The > MN can always use ESP in tunnel mode for MIPv6 signaling messages > and hide the home address from the access link. I suggest removing > sections 5.1, 5.2 and 5.3. > > Section 5 also does not take into account scenarios where there > might not be a shared key between the MN and the HA. It also does > not account for scenarios where the home agent allocates a home > address for the mobile node as part of MIPv6 bootstrapping. > > I stopped reviewing here. :) > > Vijay > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > > ------ End of Forwarded Message > ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.-------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Nov 07 12:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipp76-0007ZH-V3; Wed, 07 Nov 2007 12:54:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipp76-0007Ym-4N for mobopts@irtf.org; Wed, 07 Nov 2007 12:54:52 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipp74-00029s-A4 for mobopts@irtf.org; Wed, 07 Nov 2007 12:54:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA7Hs9g8011343; Wed, 7 Nov 2007 19:54:25 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 19:54:21 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 11:54:10 -0600 Received: from 10.162.252.93 ([10.162.252.93]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Nov 2007 17:54:10 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 07 Nov 2007 09:54:28 -0800 Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 From: Rajeev Koodli To: ext Vijay Devarapalli Message-ID: Thread-Topic: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06 Thread-Index: AcghZz2qfE89/Y1aEdyI8AAWy5YJpw== In-Reply-To: <4731017E.7020602@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 17:54:10.0983 (UTC) FILETIME=[33860B70:01C82167] X-Nokia-AV: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Fan Zhao , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On 11/6/07 4:06 PM, "ext Vijay Devarapalli" wrote: >> >> The pseudo HoA changing at each run of the RR provides some protection >> against profiling. Change of CoA upon handover, or a new CoA nonce index or >> a new RFC 3041 style CoA configuration makes a round of RR to be run. The >> pseudo HoA itself is not inducing new signaling, but a few computational >> steps. > > Ok, but I am questioning the need for changing the pseudo home > address every time the return routability signaling is done > (every 420 seconds). > Look at it this way: it does not cost signaling-wise; few computational steps and provides protection against profiling. Probably more headache to not compute pseudo HoA for this case alone.. >> Actually, there is a new Type number for the Destination Option containing >> the pseudo HoA, so that the CN can first compute the String and recover the >> HoA. > > Ok, got it. You would need add this new destination option to > the IANA considerations section. It is empty currently. > Yes. > > How is the information about the encryption algorithm conveyed? The default should be specified and assumed. There is no additional signaling imagined for now. > More fundamental than that. Why would the mobile node want to use a > pseudo home address with its home agent? > Let's look at this in the other thread. -Rajeev -- http://people.nokia.net/~rajeev > Vijay > >> >> Thanks for the review. >> >> -Rajeev > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Nov 08 03:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2UD-0004Ei-AJ; Thu, 08 Nov 2007 03:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2UC-0004Ed-SG for mobopts@irtf.org; Thu, 08 Nov 2007 03:11:36 -0500 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq2U8-0004e0-Fz for mobopts@irtf.org; Thu, 08 Nov 2007 03:11:36 -0500 Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 92EE963287; Thu, 8 Nov 2007 09:11:30 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07782-01-3; Thu, 8 Nov 2007 09:11:30 +0100 (CET) Received: from [192.168.178.22] (e178132168.adsl.alicedsl.de [85.178.132.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 999D33C00125; Thu, 8 Nov 2007 09:11:29 +0100 (CET) Message-ID: <4732C4AB.8090407@informatik.haw-hamburg.de> Date: Thu, 08 Nov 2007 09:11:23 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "mobopts@irtf.org" , multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Mobopts] ID Update: Multicast Mobility in MIPv6 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear all, we just updated the problem statement ID: "Multicast Mobility in MIPv6: Problem Statement and Brief Survey" Abstract In this document we discuss current mobility extensions to IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. The principal approaches to the multicast mobility problems are outlined subsequently. In addition to providing a comprehensive exploration of the mobile multicast problem and solution space, this document attempts to outline a conceptual roadmap for initial steps in standardization for the use of future mobile multicast protocol designers. It's already on the ID directory: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-02 This version includes new secions on document scope and future steps,=20 extensions on L2 aspects, many editorial changes and accounts for the=20 large number of feedbacks and reviews we have received at and after the=20 Chicago meeting. The document convergence process appears pretty matured ... we will be=20 very happy to receive your comments and work towards finalization. Best regards, thomas --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Nov 12 04:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVH7-0006Ge-1E; Mon, 12 Nov 2007 04:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVH6-0006EM-AC for mobopts@irtf.org; Mon, 12 Nov 2007 04:08:08 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrVH3-0001LC-PA for mobopts@irtf.org; Mon, 12 Nov 2007 04:08:08 -0500 Received: by nz-out-0506.google.com with SMTP id f1so3074732nzc for ; Mon, 12 Nov 2007 01:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=1TpDqS0sBhx1v/gR6eTjoS6Xo/Fy4sBwiQ//xlvtL7A=; b=SiZJix70Zl/qDpzoVPycbLWWC+LOi8fzCs+gcKHzSm3ES8AFh4LruMOHzW8DgjNdfWJD3pW2df2GZC0fLg/2kJ93FlGOU/06JdD2F3wrEu9m1oPvnd2bgmh2muyZzrFe8FiKntl8PXVGgAeeaDhRiUHv7APLMvEpAkbI5Kbc8mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sWjTaErScCiRjTWvtQ/6NUmR24NO0I+JB983hQ+VROfwZOO4mftDTfibQt8h8iI9ZLoz+7g9Ifnm+UqK26FnCA1mla7WRPhxm8eH6ZYD8Tlt30H+lbZAdSpYYW4sbQP/k5TSwD6NvgW42IuIn58SJrpkI9nmtA2Sl6lMFkOJAY8= Received: by 10.142.80.7 with SMTP id d7mr360708wfb.1194858484767; Mon, 12 Nov 2007 01:08:04 -0800 (PST) Received: by 10.143.166.2 with HTTP; Mon, 12 Nov 2007 01:08:04 -0800 (PST) Message-ID: <1d38a3350711120108i2ca7303aked6af82209aa0161@mail.gmail.com> Date: Mon, 12 Nov 2007 17:08:04 +0800 From: "Hui Deng" To: multimob@ietf.org, mobopts@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Mobopts] Two related drafts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello, all Please help to review our two drafts, and appreciate your comments, Many thanks Title : Problem Statement and Requirement: Mobile Multicast Author(s) : H. Deng, et al. Filename : draft-deng-multimob-ps-mobilemulticast-00.txt Pages : 14 Date : 2007-11-8 This document discusses the problem and requirement of multicast solution in the mobile networks. One current issue in mobile multicast solution has been raised and requirements of mobile IPTV on multicast mobility will also be summarized especially for some mechanisms such as the tunneling, service capability and security discussion which is basis of supporting the mobile IPTV applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-deng-multimob-ps-mobilemulticast-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast tunneling optimization for Mobile IPv6 Author(s) : P. Yang, et al. Filename : draft-yang-multimob-mip6-mc-tunnel-opt-00.txt Pages : 13 Date : 2007-11-8 This document provides the solution to optimize the multicast tunneling in mobile IPv6. This solution will not break the basic bi- directional tunneling multicast solution of MIPv6. A new Mobile Multicast Agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one Home Agent and one Mobile Multicast Agent for single multicast stream. A new notification message is created for the communication between home agent and mobile multicast agent. There is no modification on mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yang-multimob-mip6-mc-tunnel-opt-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Nov 12 13:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreD8-0003v3-HX; Mon, 12 Nov 2007 13:40:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreD6-0003qW-SX for mobopts@irtf.org; Mon, 12 Nov 2007 13:40:36 -0500 Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IreD4-000884-2d for mobopts@irtf.org; Mon, 12 Nov 2007 13:40:36 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id lACIeWlT020269 for ; Tue, 13 Nov 2007 03:40:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lACIeXN18993 for ; Tue, 13 Nov 2007 03:40:33 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id lACIeW024412 for ; Tue, 13 Nov 2007 03:40:32 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 02:40:31 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 5C79E2605C67; Tue, 13 Nov 2007 02:39:14 +0800 (SGT) From: Chan-Wah Ng To: mobopts@irtf.org Content-Type: multipart/mixed; boundary="=-yQNX0u7qLfdNDSikf69X" Organization: Panasonic Singapore Labs Date: Tue, 13 Nov 2007 02:39:13 +0800 Message-Id: <1194892753.7207.11.camel@ncc1701e> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-OriginalArrivalTime: 12 Nov 2007 18:40:32.0501 (UTC) FILETIME=[8180C250:01C8255B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Mobopts] [Fwd: I-D Action:draft-ng-mobopts-multihoming-00.txt] X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org --=-yQNX0u7qLfdNDSikf69X Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, I have a submitted a draft on Multihoming and MIPv6 Route Optimization (see forwarded I-D announcement below). This is an ongoing research work on my part, and I thought I might as well document the work as an I-D for the IRTF community. Appreciate any comments/suggestions on the work, and in particular, if there are any interest in further exploring this area from the Mobopts RG. /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ng-mobopts-multihoming-00.txt Date: Mon, 12 Nov 2007 00:50:01 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On Mobile IPv6 Optimization and Multihoming Author(s) : C. Ng, K. Aso Filename : draft-ng-mobopts-multihoming-00.txt Pages : 8 Date : 2007-11-12 This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-mobopts-multihoming-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ng-mobopts-multihoming-00.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-ng-mobopts-multihoming-00.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-yQNX0u7qLfdNDSikf69X Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTEyMDA0NTM3Lkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW1vYm9wdHMtbXVsdGlob21pbmctMDAudHh0Cg== --=-yQNX0u7qLfdNDSikf69X Content-Type: Message/External-body; name="draft-ng-mobopts-multihoming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA3LTExLTEyMDA0NTM3Lkkt RFxAaWV0Zi5vcmc+Cgo= --=-yQNX0u7qLfdNDSikf69X Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --=-yQNX0u7qLfdNDSikf69X-- From mobopts-bounces@irtf.org Thu Nov 15 11:44:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishp3-00089g-9V; Thu, 15 Nov 2007 11:44:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishp1-00085R-5y for mobopts@irtf.org; Thu, 15 Nov 2007 11:44:07 -0500 Received: from mail2.is.haw-hamburg.de ([141.22.192.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ishox-0004aL-R4 for mobopts@irtf.org; Thu, 15 Nov 2007 11:44:07 -0500 Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.is.haw-hamburg.de (Postfix) with ESMTP id D2A6558E08; Thu, 15 Nov 2007 17:44:01 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01606-01-7; Thu, 15 Nov 2007 17:44:01 +0100 (CET) Received: from [192.168.178.22] (e178149127.adsl.alicedsl.de [85.178.149.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 657863C00223; Thu, 15 Nov 2007 17:44:00 +0100 (CET) Message-ID: <473C774E.60704@informatik.haw-hamburg.de> Date: Thu, 15 Nov 2007 17:43:58 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Romdhani, Imed" References: <735F04A99D358E468A16EDB64FC04555051E95B9@EVS1.napier-mail.napier.ac.uk> In-Reply-To: <735F04A99D358E468A16EDB64FC04555051E95B9@EVS1.napier-mail.napier.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: multimob@ietf.org, "mobopts@irtf.org" Subject: [Mobopts] Re: [multimob] ID Update: Multicast Mobility in MIPv6 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Imed, thanks for your comments, please see inline: Romdhani, Imed wrote: > First, I have to congratulate you on the excellence of your new Multica= st Mobility draft. The new version is well organised and very comprehensi= ve. >=20 Many thanks :-) > I have just finished reading it! The unique comment that comes to my mi= nd is that you have introduced in a separate sub-section (5.2.2) some sol= utions to address problems of MLD tardy leave notification in wireless li= nks and fast multicast packet forwarding prior to handover, but you misse= d to highlight in depth these problems in Section 2.2.=20 >=20 Yes, you are right: this is a lapse, we will add this. > Other membership problem aspects may deserve to be highlighted. In othe= r words, adjusting the MLD Query interval should not be just limited to a= ddress tardy leave and backup forwarding issues, but also to solve the pr= ocessing overhead caused to an MN that is already member of a multicast g= roup and who may not be in move. I do believe that the HA or MLD proxy ag= ent has to implement listener node table (you stated this in your draft) = and slow down sending MLD Query message to MNs that have already joined a= multicast group in order to save their battery power and isolate the neg= ative side effect join/leave activity caused by fixed members who may be = attached to the HA or MLD proxy agent. In fact, any attempt from a local = member to leave multicast groups or exclude some multicast sources that m= ay be on interest to an MN that is away, will cause new MLD Query message= s to be flooded to the MN in order to defend his membership (i.e. case of= bi-directional subscription). If the HA /MLD proxy is mobile multicast aware, it can prevent the MN from such unn= ecessary overhead. Different solutions have been proposed in the literatu= re review, which we summarised in the attached paper "Adaptive Multicast = Membership Management for Mobile Multicast Receivers". >=20 Paper: http://dx.doi.org/10.1109/WIMOB.2006.1696354 Yes, you point to the general restrictability of MLD Queries on=20 Point-to-Point links. This equally applies, when the MN receives=20 multicast data via a bi-directional tunnel with the HA. These MLD debates we mention only briefly, because they are somewhat=20 obvious at the one hand, and like a "red rag" for the multicast=20 community on the other. As far as I know, the number of suggested MLD=20 changes / subtypes for all kinds of special cases are countless. More importantly: Bi-directional tunneling is a minimal,=20 mobility-agnostic workaround. Efforts on multicast mobility should=20 concentrate on devising better solutions, preferably free of encapsulatio= n. Btw: In your paper you propose solutions, which avoid multicast=20 deployment in end system domains with the help of MLD proxies. Our perspective (and believe ;)) is quite on the opposite site: o End system domains rather do show multicast deployment - the=20 deployment (and scaling) problem lies in the core. A good discussion of=20 this perspective you can find in the sigcomm06 paper of Ratnasamy et=20 al.: "Revisiting IP Multicast" http://sigcomm06.stanford.edu/discussion-beta/showpaper.php?paper_id=3D2 o The benefit of multicast deployment in end system domains is much=20 larger due to layer 2 multipoint distribution than in the core. This is=20 even more relevant in wireless domains, and thus highly desirable to=20 achieve within the mobility regime. > Finally, as part of the Future Steps, it may be interesting to cover th= e mobility impact on upper TCP/IP layers (transport, session, etc.). Prob= ably related multicast protocols need to be enhanced and adapted to handl= e mobile devices. >=20 Well, there is no TCP with multicast and the application layer is quite=20 manyfold. In general, we tried to discuss the effects, i.e., loss, delay=20 and jitter as apparent on the (stateless) transport layer and its=20 effects on the widespread, sensitive applications such as voice or video. There could be issues with reliability extensions, SRM, MRT etc., we=20 believe. However, this is probably beyond the scope of this document, it=20 bears the danger of doubling its length ;) Do you agree? Best regards, thomas > -----Original Message----- > From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20 > Sent: 08 November 2007 08:11 > To: mobopts@irtf.org; multimob@ietf.org > Subject: [multimob] ID Update: Multicast Mobility in MIPv6 >=20 > Dear all, >=20 > we just updated the problem statement ID: >=20 > "Multicast Mobility in MIPv6: Problem Statement and Brief Survey" >=20 > Abstract >=20 > In this document we discuss current mobility extensions to IP layer > multicast solutions. Problems arising from mobile group communicati= on > in general, in the case of multicast listener mobility and for mobi= le > Any Source Multicast as well as Source Specific Multicast senders a= re > documented. Characteristic aspects of multicast routing and > deployment issues for fixed IPv6 networks are summarized. The > principal approaches to the multicast mobility problems are outline= d > subsequently. In addition to providing a comprehensive exploration = of > the mobile multicast problem and solution space, this document > attempts to outline a conceptual roadmap for initial steps in > standardization for the use of future mobile multicast protocol > designers. >=20 > It's already on the ID directory: >=20 > http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-02 >=20 >=20 > This version includes new secions on document scope and future steps,=20 > extensions on L2 aspects, many editorial changes and accounts for the=20 > large number of feedbacks and reviews we have received at and after the= =20 > Chicago meeting. >=20 > The document convergence process appears pretty matured ... we will be=20 > very happy to receive your comments and work towards finalization. >=20 > Best regards, >=20 > thomas >=20 --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Nov 15 16:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ismdi-00087t-Fe; Thu, 15 Nov 2007 16:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ismdh-00087i-9T for mobopts@irtf.org; Thu, 15 Nov 2007 16:52:45 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ismdd-00088m-L7 for mobopts@irtf.org; Thu, 15 Nov 2007 16:52:45 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAFLqYIn018407 for ; Thu, 15 Nov 2007 23:52:39 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 23:52:35 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 15:52:33 -0600 Received: from 10.241.58.139 ([10.241.58.139]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Nov 2007 21:52:32 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 15 Nov 2007 13:53:02 -0800 From: Rajeev Koodli To: "mobopts@irtf.org" Message-ID: Thread-Topic: Presenting at IETF70 (Vancouver) Thread-Index: Acgn0eTHI25rOpPFEdyRLQAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 21:52:33.0439 (UTC) FILETIME=[D3C1A2F0:01C827D1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Mobopts] Presenting at IETF70 (Vancouver) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org All, We are meeting on Monday (12/3) morning 9.00 - 11.30. Please let me know if you would like to present your work at the meeting. Provide me with: Title, Requested time, and A URL to your document. We will discuss multicast and mobility during the last one hour of the meeting. Thanks, -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Nov 15 22:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IssBJ-0004aL-0H; Thu, 15 Nov 2007 22:47:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IssBI-0004XJ-6E for mobopts@irtf.org; Thu, 15 Nov 2007 22:47:48 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IssBF-0004K4-Jp for mobopts@irtf.org; Thu, 15 Nov 2007 22:47:48 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAG3lhD4017778; Fri, 16 Nov 2007 12:47:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAG3liP24153; Fri, 16 Nov 2007 12:47:44 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id lAG3lg021491; Fri, 16 Nov 2007 12:47:42 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 11:47:40 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 08EA9263CC9B; Fri, 16 Nov 2007 11:46:24 +0800 (SGT) Subject: Re: [Mobopts] Presenting at IETF70 (Vancouver) From: Chan-Wah Ng To: Rajeev Koodli In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Labs Date: Fri, 16 Nov 2007 11:46:24 +0800 Message-Id: <1195184784.6540.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-OriginalArrivalTime: 16 Nov 2007 03:47:40.0665 (UTC) FILETIME=[6FDA4E90:01C82803] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello, Rajeev, If the RG timing allows it, I'll love to have a 5-10 mins slot for my multihoming work. Title: On Mobile IPv6 Optimization and Multihoming http://www.ietf.org/internet-drafts/draft-ng-mobopts-multihoming-00.txt /rgds /cwng On Thu, 2007-11-15 at 13:53 -0800, Rajeev Koodli wrote: > All, > > We are meeting on Monday (12/3) morning 9.00 - 11.30. > > Please let me know if you would like to present your work at the meeting. > Provide me with: > > Title, > Requested time, and > A URL to your document. > > We will discuss multicast and mobility during the last one hour of the > meeting. > > Thanks, > > -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Nov 16 07:01:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsztW-0000ye-Po; Fri, 16 Nov 2007 07:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsztU-0000xa-Mu for mobopts@irtf.org; Fri, 16 Nov 2007 07:01:56 -0500 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsztQ-00066G-8o for mobopts@irtf.org; Fri, 16 Nov 2007 07:01:56 -0500 Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 99D0362DB2; Fri, 16 Nov 2007 13:01:47 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31937-01-4; Fri, 16 Nov 2007 13:01:47 +0100 (CET) Received: from [192.168.178.22] (e178150017.adsl.alicedsl.de [85.178.150.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 2340C3C001B1; Fri, 16 Nov 2007 13:01:45 +0100 (CET) Message-ID: <473D86A7.1010703@informatik.haw-hamburg.de> Date: Fri, 16 Nov 2007 13:01:43 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350711120108i2ca7303aked6af82209aa0161@mail.gmail.com> In-Reply-To: <1d38a3350711120108i2ca7303aked6af82209aa0161@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: multimob@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: Comments on draft "Problem Statement and Requirement: Mobile Multicast" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Hui, I've just gone through your draft and have some comments / remarks: At first, I find it quite valuable to have a detailed description /=20 discussion on Mobile IPTV over Multicast deployment issues. If we=20 believe this to be a larger business / likely deployment case, we should=20 look at it in detail. So your draft is a good starting point. The title is misleading, though. I'd like to suggest putting Mobile IPTV=20 into the title, e.g., "Problem Statement and Deployment Requirements:=20 Mobile IPTV over Multicast". In the document you are mentioning "Video service need much bandwidth"=20 and the threat of network component overload. It would be helpful to=20 present numbers ... if you consider some mobile phone with a display of=20 QCIF size and an efficient codec, bandwidth can actually drop down=20 drastically (well below 100 kbit/s) ... larger resolutions (requiring=20 higher frame rates) and less efficient codecs increase bandwidth=20 consumption nonlinearly (typically some power of 2-5). In general, the dependence of the service on end user devices needs=20 consideration, I believe. In section 2.2 (6) you mention the differences in video packet relevance=20 (I/P/B-Frames) and state "It is recommended to provide better guarantee=20 for important packets." - this is actually a strong requirement, if you=20 ask for network support. It means that forwarding components have to=20 inspect the RTP extension profile/payload. I know that this is an old=20 discussion in the QoS community ... but do we actually know of any=20 operator providing such complex, high-level service? What one can do, of course, is to allow for Diffserv packet labeling at=20 the content source. This would require appropriate service contracts=20 between the content providers and the network operators. In section 2.2 (7) you state "the mobile multicast should provide some=20 machenism to ensure the synchronization of mobile IPTV streams" - what=20 do you mean by that? Typically, synchronization at the signaling level is provided by RTP ...=20 and realized by buffers for RTP and play-out (as this is a streaming=20 scenario). Similarly in section 2.3 you stress "a precise time reference is needed=20 in the multicast mobile network" for synchronization purposes. Normally,=20 the synchronization problem is between source and receiver / conference=20 parties. If the IPTV source is a foreign one, i.e., not located at the=20 mobile network operator, an operator-based temporal synchronization does=20 not solve the problem. Typically, NTP timestamps are provided by RTCP=20 ... so it appears rather as an issue of RTCP presence ... which is not=20 fully trivial, e.g., feedback in unidirectional broadcast networks like=20 DVB-H. Best regards, thomas Hui Deng wrote: > Hello, all >=20 > Please help to review our two drafts, and appreciate your comments, > Many thanks >=20 >=20 > Title : Problem Statement and Requirement: Mobile Multicast > Author(s) : H. Deng, et al. > Filename : draft-deng-multimob-ps-mobilemulticast-00.txt > Pages : 14 > Date : 2007-11-8 >=20 > This document discusses the problem and requirement of multicast > solution in the mobile networks. One current issue in mobile > multicast solution has been raised and requirements of mobile IPTV on > multicast mobility will also be summarized especially for some > mechanisms such as the tunneling, service capability and security > discussion which is basis of supporting the mobile IPTV applications. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-deng-multimob-ps-mobilemultic= ast-00.txt >=20 >=20 --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Nov 19 05:07:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Xo-0003Rk-RO; Mon, 19 Nov 2007 05:07:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Xo-0003RH-1O for mobopts@irtf.org; Mon, 19 Nov 2007 05:07:56 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu3Xm-0007Kc-Bk for mobopts@irtf.org; Mon, 19 Nov 2007 05:07:56 -0500 Received: by rv-out-0910.google.com with SMTP id c27so1348832rvf for ; Mon, 19 Nov 2007 02:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=pLx0Jmfa8ndybMprH/ELUbshn7nM1F2UaDH5Rnm0Odc=; b=ZgHmCJMmGr7OJ4mrvipmpGLTzRUG9RGUDamwe641UlUXd2oQ8HO26RrGr2xhYFGVUguWUAhcNOG2N1pEh9OgJ/SK2XTkKsiqNi1ERBYyeyyBQuuPExIXH1tizZCiNnqC64VKegYSm8Xvpv0WR53jnLA2h2wOtqXohI9HHyY8EHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nkyeziQy8tq2aLYGa/6y26TD/utE7J1TpswUiDJAyRW0ta/zcL2+4ObbQZnMCp905pXIxVhbmiIYxBrLVZO77whdi/N/MB2cG5gKcGL9FU2Yt2eZt+t9GwN6a37N+RV1i3Pblq0I7Dy/ugheNaBkrGOHjQY9+CCuycxsc3yUQr0= Received: by 10.141.69.1 with SMTP id w1mr1940630rvk.1195466873643; Mon, 19 Nov 2007 02:07:53 -0800 (PST) Received: by 10.140.177.17 with HTTP; Mon, 19 Nov 2007 02:07:53 -0800 (PST) Message-ID: <1d38a3350711190207s6fb3d5d7tfd5cc0decdce9bc@mail.gmail.com> Date: Mon, 19 Nov 2007 18:07:53 +0800 From: "Hui Deng" To: mobopts , "netlmm@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Mobopts] Call for paper: IEEE ICC 2008 Workshop on IP Mobility Management and Architecture X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org We are sorry if you received multiple copies of this. IPMMA 2008 2008 Workshop on IP Mobility Management and Architecture May 19/23, 2008, Beijing, China (To be held with IEEE ICC 2008, May 19-23, 2008) Sponsored by China Mobile Webpage: http://www.ieee-icc.org/2008/ Webpage: http://www.mobilehub.com.cn/yjy/ieee/index.htm Important Dates: Submission Deadline: Dec. 20, 2007 Acceptance notification: Jan 31 2008 Camera ready: Feb 28 2008 Program Co-Chairs Bill Huang China Mobile Ziqiang Hou Institue of Acoustics, CAS Sajal Das The Univ. Texas at Arlington Program Committees: Thierry Ernst INRIA Wing C. Lau The Chinese Univ. of Hong Kong Bing Wei China Mobile Min Liu Institute of Computing Technology, CAS Ying Qiu Institute for Infocomm Research Ryuji Wakikawa KEIO University Peng Yang Hitachi Yong Cui Tsinghua University Xiaobing Guo Lenovo Publicity Chair Hui Deng China Mobile With recently, various kinds of IP mobility management solutions have been widely adopted by many wireless communication standard bodies such as Wimax forum, 3GPP, 3GPP2 etc. Most adopted solutions are point to point connection which is similar to traditional circuit-switched architecture. Handover among heterogeneous networks with different wireless links is standardized by different incompatible mobility management technologies. Designing next generation IP mobility management and architecture on the scenarios, such as next generation wireless communication evolution, ad hoc subscriber grouping, and peer to peer Internet network architecture seems to be a timely request and will influence all kinds of operator's network architectures. Many technologies are under development. "IP mobility management and architecture" welcomes original submission which emphasizing the general aspects, soliciting authors to provide very high quality contributions. Topics of interest are (but not limited to): 1) IP mobility management for structured P2P network; 2) Heterogeneous network handover; 3) IP mobility management for mobile Ad hoc network; 4) Network based local mobility management; 5) Network mobility; 6) EAP based handover key management in wireless IP network; 7) Multiple interface and multi-homing in the mobility management environment. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Nov 19 15:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDLQ-00082T-HG; Mon, 19 Nov 2007 15:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDLP-00082A-P6 for mobopts@irtf.org; Mon, 19 Nov 2007 15:35:47 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDLM-0002Ws-Rx for mobopts@irtf.org; Mon, 19 Nov 2007 15:35:47 -0500 Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id lAJKZhB1022526; Mon, 19 Nov 2007 15:35:43 -0500 (EST) Message-ID: <4741F3A0.20505@research.telcordia.com> Date: Mon, 19 Nov 2007 15:35:44 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Marco Liebsch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: "mobopts@irtf.org" Subject: [Mobopts] Re: Comments on draft-irtf-mobopts-mpa-framework-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Marco, Appreciate your review and useful feedback and comments on draft-irtf-mobopts-mpa-framework-00.txt. Please see inline for the answers to your questions and comments. We have taken care of many of the comments in the revised version (draft-irtf-mobopts-mpa-framework-01.txt) of the draft that we submitted recently. I am sending it to the MOBOPTS mailing list for further discussion. Regards Ashutosh Marco Liebsch wrote: > Hi Ashutosh, > > please find attached some quick and initial comments, which you > may consider as general comments and some editorial comments. > > Maybe some of my general comments are due to misunderstanding > or because I did not dig into this work beforehand. I could > not look at all thinks in detail so far, but maybe you find > some comments useful for the discussion. > > See you in Vancouver, > > marco ************************************************************************** Comments to Media-Independent Pre-Authentication Framework for Inter-Domain Handover Optimization, draft-irtf-mobopts-mpa-framework-00.txt General: ======== 2. Inter-domain Handover 3rd paragraph, last sentence: "...change its L3 identifier depending upon..." I don't think the *identifier* changes here, but the *locator*. At least for Mobile IP-like protocols. I guess the same is valid for SIP, where name@realm is the ID, whereas its registered IP address serves as locator. => Identifier changed to locator in the respective places Figure 1: Figure should look simpler. You use many specific functional components in the drawing without explaining them in the text. I propose to reduce them and keep most relevant ones for this general description. This could be the AAAH and the AAAF (or AAAV). AA is not important here to get the point (?). The few key components should be summarized in the text of section 2. Most of these components come back later in Figure 2 anyhow (AA, etc.) => Added the descriptions of AAAv, AAAH, AA, AR etc. briefly to this section to describe the components of Figure 1. 6.3 Basic Communication FLow Comment to Step 3: "...by executing the binding update operation..." In Mobile IP(v6) sending a binding update is usually triggered by reception of an on-link router advertisement or agent advertisement and subsequent configuration of a routable IP address at the interface. These will not be advertised on the established tunnel by default (and the tunnel is set up only 'after' the address has been configured, right?) => This is a good point. In MIPv6, binding update is dependent on receipt of on-link router advertisement. Thus, the mobile needs to detect the on-link router advertisement from the NAR tunneled through the transient tunnel before the proactive binding update could be sent out from the mobile. We have added a mechanism to send the RA tunneled through the transient tunnel, so that the mobile can send the proactive binding update based on the receipt of the router advertisement. Also the mobile must be modified to distinguish 'local' IP address configuration and 'remote' IP address configuration. This requires modification of hosts and protocols for MM, Address configuration. Is all this supported by an MPA-enabled MN? If modification of Mobile IP is required, it's not really agnostic/independent to the mobility management protocol, which I understand is one of the design goals. However, for a framework is should be ok as it is. => There is no need to change the mobility protocols, as such. Thus, modification of Mobile IP is not required either. But the host may need some modification, so that it can interact properly with the mobility protocols, such as Mobile IP or SIP while performing the required optimization functions. End host may need additional software to interact with mobility protocols and perform other related MPA related functions. 7.4 Address resolution I would not say DAD is part of address resolution but address configuration. I see this rather located in 7.3. But DAD for stateless address configuration is not considered, is it? As long as there is no tunnel to the target subnet in the CTN, it's difficult to perform DAD with the NDP. => DAD part has been moved to Section 7.3. Clarified few steps with respect to DAD operation for stateless auto-configuration. 7.7.2 Preventing packet loss for multiple interfaces Why is pre-authentication through the previous interface required here? The new interface can be powered and attached while the previous one maintains the session? That's one advantage of multi-mode terminals. Or did I misunderstand something here? => As mentioned elsewhere in the document, applicability of MPA is more compelling for single interface case. However, in case of multiple interface case, use of previous interface to perform certain MPA related operations is desirable for scenarios, such as 1) Saving battery power 2) In case of non-overlapping access or sudden disconnection 3. In case the carrier does not support simultaneous use of multiple interfaces. Authentication and attach to CDMA network via WLAN seems difficult, as techno/System specific IDs (e.g. IMEI, IMSI) are used and temporary IDs will be assigned (TMSI). But I must admit, that this of course depends on how efficient an AA and CA can be integrated with a CDMA-based target network and how powerful the protocol interface between MN and AA/CA is. => In case of multi access networks, for some types of target access networks, not all the steps of MPA could be possible. It could just perform pre-authentication vs. combination of pre-authentication and preconfiguration, or all the steps mentioned in Section 6. In a typical WiFi-CDMA handoff operation, some of the PPP context can be set up ahead of time by using WiFi interface. general comment: tunneling data between two ARs belonging to different domains can imply quite some delay in case such packets traverse always the top gateway router of the domain. I am wondering if the proactive tunnel brings always the expected performance gain compared to MM-tailored solutions. => MPA uses a transient tunnel between NAR and the mobile in PoA. It is true that, in case of inter-domain handoff, these entities could be far-off logically. Thus, the signaling and data during pre-authentication period will take a longer route, and thus, may be subjected to longer one-way-delay. Thus, it is a tradeoff between larger packet loss or larger one-way-packet delay for a transient period, when the mobile is preparing to handoff. summary: Very good work! Lot of things have been considered, such as different means for address acquisition, etc. Individual protocol components and needs have been evaluated thoroughly. To make an MPA framework for handover working in a particular system, I expect major modifications to existing components, such as address configuration, MM, local routing table management on MNs. => Since MPA framework is supposed to provide helper techniques to optimize the existing mobility management protocols, certain changes/modifications are needed on the mobile and router based on what part of MPA procedures are used inter-domain handoff. Editorial: ========== 1.1 Performance Requirements last paragraph repeats what's aid already above already (ITU delay bounds). Looks redundant and can be merged. =>Merged 2. Inter-domain Handover 4th paragraph: "...will be sujected..." -> "...will be subjected..." (?) => changed 3. Existing work on Fast Handover Minor comment on the first paragraph: MM protocols don't suffer from handover delay, rather applications and performance do. MM works even with large handover latency. => rephrased "...propose a scheme reduces the delay..." -> "...propose a scheme that/which reduces the delay..." => Fixed 4. Applicability of MPA first paragraph mentions the 'CTN'. You should introduce abbreviations first before using them. Just write Candidate Target Network (CTN). Later you explain it anyhow in section 5. => Description of CTN added 6.1 Overview "...CTN as well as a execute tunnel..." -> "...CTN as well as execute a tunnel..." "...before attaching to the the target..." -> "...before attaching to the target..." => typos fixed 6.2 Functional Elements "...in one more network devices..." -> "...in one or more network devices..." => Fixed 6.3 [page 20] last sentense CH -> CN => Fixed _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Nov 20 20:54:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuenF-0008Ib-GS; Tue, 20 Nov 2007 20:54:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuenE-0008IO-Aq for mobopts@irtf.org; Tue, 20 Nov 2007 20:54:20 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuenB-0003iT-JN for mobopts@irtf.org; Tue, 20 Nov 2007 20:54:20 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAL1rjbh013634; Wed, 21 Nov 2007 03:54:06 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 03:53:40 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 19:53:36 -0600 Received: from 10.241.59.200 ([10.241.59.200]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Nov 2007 01:53:36 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 20 Nov 2007 17:53:41 -0800 From: Rajeev Koodli To: ext Aaron Falk Message-ID: Thread-Topic: IRSG review of draft-irtf-mobopts-l2-abstractions-04.txt completed Thread-Index: Acgr4VcplZXhtJfUEdy2twAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 01:53:36.0425 (UTC) FILETIME=[546EE990:01C82BE1] X-Nokia-AV: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: irsg@isi.edu, "mobopts@irtf.org" Subject: [Mobopts] IRSG review of draft-irtf-mobopts-l2-abstractions-04.txt completed X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Aaron, This note is to formally request you to advance the MobOpts RG ID "Unified L2 Abstractions for L3-Driven fast Handover" [1] to IESG for their "no circumvention" review prior to its publication as an Experimental RFC. The detailed IRSG review (of version 03) and subsequent acceptance (of version 04) by John Levine are available at http://www1.ietf.org/mail-archive/web/mobopts/current/msg00873.html The above review and the IRSG poll input are documented at the tracker http://www3.tools.ietf.org/group/irtf/trac (which is currently down for me to provide the exact ticket #) Since this document represents the consensus of the MobOpts RG, I request that the following IESG note (taken from [2]) be included: "This document is not an IETF Internet Standard. It represents the consensus of the MobOpts Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF in the future." The IRSG poll provided input [3] which could be incorporated as RFC Editor notes. Thanks, -Rajeev -- http://people.nokia.net/~rajeev [1]: http://tools.ietf.org/id/draft-irtf-mobopts-l2-abstractions-04.txt [2]: http://www.irtf.org/chairfiles/draft-irtf-rfcs-01.html#iesg-notes [3]: > > Vote: Ready to publish > > Short Review: > > The document is very easy to read and understand. I have worked in this > area (though more focused on L3-L4 interaction than L3-L2) and I think it > is a useful and needed contribution. > > The diagrams are clear and the appendices provide useful supporting > material. > > The "Architectural Considerations" section is a good idea for a document > like this, and building off the IAB document was also a great idea. > > I didn't quite buy the logic on number 5, and suggest a different explanation > instead of: >> [5] Proposals must demonstrate that effective congestion control is >> maintained. >> >> Since this mechanism is coupled to the IP layer, and not >> directly to the transport layer, the proposed mechanism does >> not directly affect congestion control. > > I think it would be more correct to say: > Since the proposed inter-layer communications are local within a host, > and not across a network, they don't directly raise congestion control > concerns. The response of individual protocols to these notifications > should ensure that effective congestion control is maintained, but those > instantiations are outside the scope of this document. > > Grammar/Spelling: > > "utilize other layer's control" -> > "utilize other layers' control" ? _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Nov 20 23:18:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuh2Y-0000Aa-77; Tue, 20 Nov 2007 23:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuh2X-0000AU-3L for mobopts@irtf.org; Tue, 20 Nov 2007 23:18:17 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuh2S-0007N7-W6 for mobopts@irtf.org; Tue, 20 Nov 2007 23:18:17 -0500 Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id lAL4HrO5028990; Tue, 20 Nov 2007 23:17:54 -0500 (EST) Message-ID: <4743B172.3090301@research.telcordia.com> Date: Tue, 20 Nov 2007 23:17:54 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Mobopts] Updated draft-irtf-mobopts-mpa-framework document X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear All, We have submitted a revised version of the draft titled "A Framework of Media-Independent Pre-Authentication (MPA) for Inter-domain Handover Optimization". This revised version has addressed the comments and suggestions from Christian Vogt and Marco Liebsch that have been sent to the mailing list for discussion. Online version of the revised draft can be found at the following URL. http://www.ietf.org/internet-drafts/draft-irtf-mobopts-mpa-framework-01.txt We would like to solicit any further comments and suggestions on the revised version of the draft. Regards Ashutosh Dutta _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Nov 21 12:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusyI-00080c-GB; Wed, 21 Nov 2007 12:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurQm-0002Hi-14 for mobopts@irtf.org; Wed, 21 Nov 2007 10:24:00 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurQh-0008JB-N8 for mobopts@irtf.org; Wed, 21 Nov 2007 10:24:00 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IurQh-0001nN-3N; Wed, 21 Nov 2007 10:23:55 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C65B930-D392-442B-BB0A-7F98DB3A4E06@bbn.com> Content-Transfer-Encoding: 7bit From: Aaron Falk Date: Wed, 21 Nov 2007 10:23:52 -0500 To: RFC Editor X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.8 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-Mailman-Approved-At: Wed, 21 Nov 2007 12:02:39 -0500 Cc: Internet Research Steering Group , mobopts@irtf.org Subject: [Mobopts] Request to publish draft-irtf-mobopts-l2-abstractions-04 as an IRTF RFC X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear RFC Editor- Please publish draft-irtf-mobopts-l2-abstractions-04 as an Experimental IRTF-stream RFC. The IRSG has reviewed this document and approved it for publication. Please include Rajeev Koodli on all correspondence relating to publication of this document. Details of the review process follow below. Also, please make the two small edits are requested below. Regards, --Aaron Falk IRTF Chair Begin forwarded message: > From: Rajeev Koodli > Date: November 20, 2007 8:53:41 PM EST > To: ext Aaron Falk > Cc: , "mobopts@irtf.org" > Subject: IRSG review of draft-irtf-mobopts-l2-abstractions-04.txt > completed > > > Hi Aaron, > > This note is to formally request you to advance the MobOpts RG ID > "Unified > L2 Abstractions for L3-Driven fast Handover" [1] to IESG for their "no > circumvention" review prior to its publication as an Experimental RFC. > > The detailed IRSG review (of version 03) and subsequent acceptance (of > version 04) by John Levine are available at > > http://www1.ietf.org/mail-archive/web/mobopts/current/msg00873.html > > The above review and the IRSG poll input are documented at the tracker > http://www3.tools.ietf.org/group/irtf/trac (which is currently down > for me > to provide the exact ticket #) > > Since this document represents the consensus of the MobOpts RG, I > request > that the following IESG note (taken from [2]) be included: > > "This document is not an IETF Internet Standard. It represents > the consensus of the MobOpts Research Group of the Internet Research > Task Force. It may be considered for standardization by the > IETF in the future." > > The IRSG poll provided input [3] which could be incorporated as RFC > Editor > notes. > > Thanks, > > -Rajeev > -- > http://people.nokia.net/~rajeev > > > > > [1]: http://tools.ietf.org/id/draft-irtf-mobopts-l2- > abstractions-04.txt > > [2]: http://www.irtf.org/chairfiles/draft-irtf-rfcs-01.html#iesg-notes > > [3]: >> >> Vote: Ready to publish >> >> Short Review: >> >> The document is very easy to read and understand. I have worked >> in this >> area (though more focused on L3-L4 interaction than L3-L2) and I >> think it >> is a useful and needed contribution. >> >> The diagrams are clear and the appendices provide useful supporting >> material. >> >> The "Architectural Considerations" section is a good idea for a >> document >> like this, and building off the IAB document was also a great idea. >> >> I didn't quite buy the logic on number 5, and suggest a different >> explanation >> instead of: >>> [5] Proposals must demonstrate that effective congestion >>> control is >>> maintained. >>> >>> Since this mechanism is coupled to the IP layer, and not >>> directly to the transport layer, the proposed mechanism does >>> not directly affect congestion control. >> >> I think it would be more correct to say: >> Since the proposed inter-layer communications are local within a >> host, >> and not across a network, they don't directly raise congestion >> control >> concerns. The response of individual protocols to these >> notifications >> should ensure that effective congestion control is maintained, but >> those >> instantiations are outside the scope of this document. >> >> Grammar/Spelling: >> >> "utilize other layer's control" -> >> "utilize other layers' control" ? > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Nov 28 14:12:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSL8-0005gh-TD; Wed, 28 Nov 2007 14:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSL8-0005ga-2b for mobopts@irtf.org; Wed, 28 Nov 2007 14:12:54 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSL6-0003TG-6g for mobopts@irtf.org; Wed, 28 Nov 2007 14:12:54 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lASJCSCY011348 for ; Wed, 28 Nov 2007 21:12:50 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 21:12:33 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 13:12:31 -0600 Received: from 10.241.59.91 ([10.241.59.91]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Nov 2007 19:12:31 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 28 Nov 2007 11:12:48 -0800 From: Rajeev Koodli To: "mobopts@irtf.org" Message-ID: Thread-Topic: Vancouver meeting agenda Thread-Index: Acgx8qnC6DhTfJ3lEdykiQAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 19:12:31.0710 (UTC) FILETIME=[A00CCFE0:01C831F2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mobopts] Vancouver meeting agenda X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, The agenda is on-line now. In the first hour and half, we will go over the RG documents and their recent reviews. We will also have presentations on couple of new topics. In this meeting, we will have an hour dedicated to discussing multicast and mobility. Specifically, the RG has been asked to discuss and recommend what might need IETF consideration. In order to have a fruitful meeting on this topic, we need the presenters and the members to adhere to the time we have. And, please remember that the objective here is to identify the problems, if any, that may require potential IETF work. All the presenters: please send me your slides no later than Saturday, noon. Thanks, -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Nov 28 14:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSbV-0008RL-Gm; Wed, 28 Nov 2007 14:29:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSbU-0008RA-Hy for mobopts@irtf.org; Wed, 28 Nov 2007 14:29:48 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSbT-0007DO-UL for mobopts@irtf.org; Wed, 28 Nov 2007 14:29:48 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lASJTRft032018 for ; Wed, 28 Nov 2007 21:29:46 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 21:29:28 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 13:29:24 -0600 Received: from 10.241.59.91 ([10.241.59.91]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Nov 2007 19:29:23 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 28 Nov 2007 11:29:40 -0800 Subject: Re: [Mobopts] Vancouver meeting agenda From: Rajeev Koodli To: Rajeev Koodli , "mobopts@irtf.org" Message-ID: Thread-Topic: [Mobopts] Vancouver meeting agenda Thread-Index: Acgx8qnC6DhTfJ3lEdykiQAWy5YJpwAAlsxu In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 19:29:24.0182 (UTC) FILETIME=[FB87C760:01C831F4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On 11/28/07 11:12 AM, "ext Rajeev Koodli" wrote: > The agenda is on-line now. http://www3.ietf.org/proceedings/07dec/agenda/MobOpts.txt > All the presenters: please send me your slides no later than Saturday, noon. > Also, please do not switch to your laptops (unless there is an unavoidable technical difficulty) during the meeting. -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts