From mip4-bounces@ietf.org Tue May 01 02:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Him7B-0007f2-36; Tue, 01 May 2007 02:45:33 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Him7A-0007eu-0q for mip4-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 02:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Him76-0007ef-9Z for mip4@ietf.org; Tue, 01 May 2007 02:45:28 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Him75-0007zA-Rx for mip4@ietf.org; Tue, 01 May 2007 02:45:28 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l416jHk27147; Tue, 1 May 2007 06:45:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt Date: Tue, 1 May 2007 01:45:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt Thread-Index: AceGO3CwNHxrEBK1S7GNnwWX3lfMQgC32FjQAI4MQdAAGkE8IA== From: "Jayshree Bharatia" To: "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: McCann Peter-A001034 , "Kent Leung \(kleung\)" , "Chowdhury, Kuntal" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Thanks Vijay. I will submit the draft shortly... -----Original Message----- From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 Sent: Monday, April 30, 2007 1:12 PM To: Bharatia, Jayshree (RICH1:2H10) Cc: Kent Leung (kleung); Chowdhury, Kuntal; mip4@ietf.org; McCann Peter-A001034 Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt Looks good to me. Thanks Vijay=20 > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortel.com] > Sent: Friday, April 27, 2007 3:27 PM > To: Vijay Devarapalli > Cc: Kent Leung (kleung); Chowdhury, Kuntal; mip4@ietf.org;=20 > McCann Peter-A001034 > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt >=20 > Vijay, >=20 > I have made the following changes per your comments: >=20 > Section 1 (Introduction) > From > This document defines a new extension that can be used to carry=20 > configuration parameters during Mobile IPv4 registration. >=20 > To > This document defines a new extension that can be used to carry=20 > configuration parameters from the Foreign Agent and/or Home Agent=20 > during Mobile IPv4 registration. This configuration parameters include > DHCP option (Parameter > Request List) defined in RFC2132. >=20 > Section 5 (Security Considerations) > From > There is no confidentiality provided by the extension. The=20 > extension is > transferred unencrypted, and if sensitive information is sent for host > configuration purposes, it may need to be protected by other means. >=20 > To > There is no confidentiality provided for this extension. The > information > carried > in the Configuration Options Exchange Extension is from the=20 > Home Network > and/or > Foreign Network and is transferred unencrypted. If sensitive=20 > information > is sent > for host configuration purposes, it may need to be protected by other > means > outside the scope of this document. >=20 > Let me know if this is acceptable. >=20 > Thanks, > Jayshree >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: Tuesday, April 24, 2007 1:40 AM > To: mip4@ietf.org; McCann Peter-A001034 > Cc: Kent Leung (kleung); Chowdhury, Kuntal; Bharatia, Jayshree > (RICH1:2H10) > Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt >=20 >=20 > Hello, >=20 > I went through the revised document. Most of my comments during the WG > last call have been addressed. Thanks. >=20 > A couple of minor comments. >=20 > We need to add some text in the Introduction section to say that this=20 > document describes a mechanism to configure a mobile node with=20 > information from both the home link and foreign link. It also needs to > say that this document just defines a new MIPv4 configuration options=20 > exchange extensions and this extension is used to carry the DHCP and=20 > BOOTP options defined in RFC 2132. With the current text in the=20 > Introduction section, it is not clear what the document is about until > you get to section 3. :) >=20 > In the Security Considerations section, perhaps rephrase >=20 > > There is no confidentiality provided by the extension. The > extension > > is transferred unencrypted, and if sensitive information is sent > for > > host configuration purposes, it may need to be protected by other > > means. >=20 > as >=20 > There is no confidentiality provided for this extension. The > information carried in the extension is from the home network and > is transferred unencrypted. If sensitive information is sent for > host configuration purposes, it may need to be protected by other > means outside the scope of this document. >=20 > Vijay >=20 > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. This draft is a work item of the Mobility for IPv4=20 > > Working Group of > the IETF. > >=20 > > Title : Mobile IPv4 Extension for Configuration > Options Exchange > > Author(s) : J. Bharatia, et al. > > Filename : draft-ietf-mip4-gen-ext-01.txt > > Pages : 13 > > Date : 2007-2-26 > > =09 > > This document describes the mechanism for providing the host > > configuration information during Mobile IP registration. One or > more > > Configuration Options Exchange Extensions may be included in the > > registration message to provide the Mobile Node the configuration > > parameters needed for network service (e.g. DNS). > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-01.txt > >=20 > > 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 >=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce >=20 > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-ietf-mip4-gen-ext-01.txt". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mip4-gen-ext-01.txt". > > =09 > > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 01 15:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiyMX-0006ZT-Kj; Tue, 01 May 2007 15:50:13 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HiyMN-0006Pe-Iv for mip4-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiyMN-0006PW-4Z; Tue, 01 May 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiyML-0006vh-T0; Tue, 01 May 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D4DC732960; Tue, 1 May 2007 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HiyML-0001KL-Ou; Tue, 01 May 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 May 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, at al. Filename : draft-ietf-mip4-dsmipv4-02.txt Pages : 23 Date : 2007-5-1 This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.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-ietf-mip4-dsmipv4-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-mip4-dsmipv4-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: <2007-5-1144251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dsmipv4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dsmipv4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-1144251.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue May 01 18:50: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 1Hj1BL-0003L2-KR; Tue, 01 May 2007 18:50:51 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hj1B6-0002Yn-Rn for mip4-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 18:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1B6-0002WF-8Z; Tue, 01 May 2007 18:50:36 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hj1B4-0004Sx-Q2; Tue, 01 May 2007 18:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B3A9E17619; Tue, 1 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hj1AY-0002Qf-Fi; Tue, 01 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for Configuration Options Exchange Author(s) : J. Bharatia, et al. Filename : draft-ietf-mip4-gen-ext-02.txt Pages : 13 Date : 2007-5-1 This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-02.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-ietf-mip4-gen-ext-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-mip4-gen-ext-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: <2007-5-1151428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-gen-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-gen-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-1151428.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed May 02 11:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGfU-0006eH-FO; Wed, 02 May 2007 11:23:00 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HjGfT-0006eC-6x for mip4-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 11:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGfS-0006dz-Tb for mip4@ietf.org; Wed, 02 May 2007 11:22:58 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjGfS-0007iW-HY for mip4@ietf.org; Wed, 02 May 2007 11:22:58 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1178119377!8900648!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14537 invoked from network); 2 May 2007 15:22:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 2 May 2007 15:22:57 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l42FMuEa003346 for ; Wed, 2 May 2007 08:22:56 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l42FMt8r026393 for ; Wed, 2 May 2007 10:22:55 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l42FMscR026376 for ; Wed, 2 May 2007 10:22:54 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt Date: Wed, 2 May 2007 11:22:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt Thread-Index: AceMQzSmzfymCVNmTVWTaTIqgrkitgAiR1vA References: From: "McCann Peter-A001034" To: "Jayshree Bharatia" , "Chowdhury, Kuntal" , "Avi Lior" , "Kent Leung \(kleung\)" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Jayshree, Thanks for turning around the edit. Unfortunately, I don't think we are quite done yet: I think the IANA=20 considerations are a bit skimpy. You should mention all the new registries=20 that this document creates, including the Entity Type field and the Sub-Type field. Right now the only thing there is the assignment of the Extension value. You may also want to mention that the "OpCode" space is borrowed completely from DHCP. Please insert the two new registries in the IANA considerations and resubmit. When that is done I will forward the document to the IESG. -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 > This draft is a work item of the Mobility for IPv4 Working Group of > the IETF.=20 >=20 > Title : Mobile IPv4 Extension for Configuration Options Exchange > Author(s) : J. Bharatia, et al. > Filename : draft-ietf-mip4-gen-ext-02.txt > Pages : 13 > Date : 2007-5-1 >=20 > This document describes the mechanism for providing the host > configuration information during Mobile IP registration. One or > more Configuration Options Exchange Extensions may be included in > the registration message to provide the Mobile Node the > configuration parameters needed for network service (e.g. DNS). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-02.txt >=20 > 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. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-mip4-gen-ext-02.txt". =20 >=20 > 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 =20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-gen-ext-02.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 02 11:55: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 1HjHBL-0000PI-54; Wed, 02 May 2007 11:55:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HjHBJ-0000LZ-Mh for mip4-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 11:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHBJ-0000KD-CM for mip4@ietf.org; Wed, 02 May 2007 11:55:53 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjHBH-00052e-0V for mip4@ietf.org; Wed, 02 May 2007 11:55:53 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l42Ftig07088; Wed, 2 May 2007 15:55:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt Date: Wed, 2 May 2007 10:55:39 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt Thread-Index: AceMQzSmzfymCVNmTVWTaTIqgrkitgAiR1vAAAFsqOA= From: "Jayshree Bharatia" To: "McCann Peter-A001034" , "Chowdhury, Kuntal" , "Avi Lior" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, Thanks for this information. I will update the document for this and submit it shortly. Regards, Jayshree -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Wednesday, May 02, 2007 10:23 AM To: Bharatia, Jayshree (RICH1:2H10); Chowdhury, Kuntal; Avi Lior; Kent Leung (kleung) Cc: mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-02.txt Jayshree, Thanks for turning around the edit. Unfortunately, I don't think we are quite done yet: I think the IANA=20 considerations are a bit skimpy. You should mention all the new registries=20 that this document creates, including the Entity Type field and the Sub-Type field. Right now the only thing there is the assignment of the Extension value. You may also want to mention that the "OpCode" space is borrowed completely from DHCP. Please insert the two new registries in the IANA considerations and resubmit. When that is done I will forward the document to the IESG. -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the Mobility for IPv4=20 > Working Group of the IETF. >=20 > Title : Mobile IPv4 Extension for Configuration Options Exchange > Author(s) : J. Bharatia, et al. > Filename : draft-ietf-mip4-gen-ext-02.txt > Pages : 13 > Date : 2007-5-1 >=20 > This document describes the mechanism for providing the host > configuration information during Mobile IP registration. One or > more Configuration Options Exchange Extensions may be included in > the registration message to provide the Mobile Node the > configuration parameters needed for network service (e.g. DNS). >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then "get > draft-ietf-mip4-gen-ext-02.txt". =20 >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-gen-ext-02.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 02 15:56: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 1HjKwZ-0007I2-BG; Wed, 02 May 2007 15:56:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HjKwS-0007Cx-Md for mip4-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 15:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKwL-00076z-7C for mip4@ietf.org; Wed, 02 May 2007 15:56:41 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjKwK-0006wa-Pj for mip4@ietf.org; Wed, 02 May 2007 15:56:41 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1178135799!8628379!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10714 invoked from network); 2 May 2007 19:56:39 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 2 May 2007 19:56:39 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l42JudBA017336 for ; Wed, 2 May 2007 12:56:39 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l42JudWQ018773 for ; Wed, 2 May 2007 14:56:39 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l42JucQn018765 for ; Wed, 2 May 2007 14:56:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 May 2007 15:56:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call for draft-ietf-mip4-radius-requirements-02.txt Thread-Index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQ== From: "McCann Peter-A001034" To: , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Henrik Levkowetz Subject: [Mip4] Working Group Last Call for draft-ietf-mip4-radius-requirements-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This message announces a 2 week working group last call on: "Mobile IPv4 RADIUS Requirements" draft-ietf-mip4-radius-requirements-02.txt.=20 The last call will end at 24:00 UTC on Wednesday, May 16th.=20 "Mobile IPv4 RADIUS Requirements" lists a set of goals and assumptions to lay the groundwork for future RADIUS extensions in support of Mobile IPv4. A URL for this internet draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 02.txt Please respond to this working group last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like =20 "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." If you have comments, please use a line similar to the one above, and supplement this with your comments. =20 =20 * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your=20 comments - =20 "I don't support the advancement of this document to the IESG with a request for publication as an Informational RFC, for the following reasons:" ... Please direct all replies to the Mobile IPv4 mailing list, mip4@ietf.org. -Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 03 15:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjhRl-0000XD-Uh; Thu, 03 May 2007 15:58:37 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HeeEQ-0000Wr-3o for mip4-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 17:31:58 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HeeEP-0000Wj-Qg for mip4@ietf.org; Thu, 19 Apr 2007 17:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeDq-0008Ta-IW for mip4@ietf.org; Thu, 19 Apr 2007 17:31:22 -0400 Received: from mxi.ltu.se ([130.240.42.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeDq-0006qO-1k for mip4@ietf.org; Thu, 19 Apr 2007 17:31:22 -0400 Received: from EMMA.personal.adp.ltu.se (rachel.personal.adp.ltu.se [130.240.150.5]) by mxi.ltu.se (8.13.1/8.13.1) with ESMTP id l3JLVL64010698 for ; Thu, 19 Apr 2007 23:31:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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, 19 Apr 2007 23:31:21 +0200 Message-ID: <7FE216529E1FE248A760B58F6B82A810D21E4F@EMMA.personal.adp.ltu.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE LCN ON-MOVE 2007 Thread-Index: Acdk3K5s5dWmWWOVSgOD5PTvFqS+VgcXfiNQAAARYxAAAA5CYABjf0yAAAAboHAAAB2c0A== From: =?iso-8859-1?Q?Christer_=C5hlund?= To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-TMDA-Confirmed: Thu, 19 Apr 2007 17:31:57 -0400 X-Mailman-Approved-At: Thu, 03 May 2007 15:58:36 -0400 Subject: [Mip4] IEEE LCN ON-MOVE 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Please accept our apologies if you receive multiple copies of this CFP] ---------------------------------------------------- CALL FOR PAPERS IEEE LCN ON-MOVE 2007 Workshop On User MObility and VEhicular Networks = http://www.ieee-lcn-onmove.org/ Dublin, Ireland; October 15-18, 2007. ---------------------------------------------------- To be held in conjuction with IEEE LCN http://www.ieeelcn.org/ ------------------------------------------------------------- IMPRTANT DATES: * Paper registration deadline: April 23, 2007 * Paper submission deadline: April 30, 2007 * Notification of acceptance: June 25, 2007 * Camera-ready paper due: July 23, 2007 * Author registration by: July 23, 2007 SCOPE: Users are becoming increasingly mobile and this requires solutions to = manage network connectivity in different situations and places both in = urban and rural areas. We are interested in visionary, experimental, systems-related and work = in-progress papers in the area of mobility management including = protocols enabling mobility, heterogeneous network access, vehicular = networks, security and applications. These are the areas of interest for the workshop: Vehicular networks -------------------------------- Mobility issues in DSRC Gateway access and selection Inter-vehicle communication (V2V) Vehicle to infrastructure communication (V2I) Network availability User Mobility -------------------------- Mobile IP issues SIP related issues Transport layer mobility Cross layer design for mobility Policy-based management of mobility Service discovery Heterogeneity ------------------------ Managing vertical handover Multihoming Performance metrics Access network selection QoS provisioning in heterogeneous networks Network operation and = maintenance Security ------------------- AAA mobility support Specific demands in mobile environments Trust and privacy for mobile users Applications -------------------------- Multimedia for mobile users Media support for mobile users and vehicles Scalable applications = Service deployment issues Quality of Experience Guidance applications Workshop chairs ------------------------------ Christer =C5hlund, Lule=E5 University of Technology, Sweden Soumaya = Cherkaoui, Sherbrooke University, Canada Poster and Demo session chairs ------------------------------------------------- Satoko Itaya, ATR Adaptive Communications Research Laboratories, Japan = Salil Kanhere, University Of New South Wales, Australia A complete list of program committee can be found at: http://www.ieee-lcn-onmove.org/committee.html Paper submissiom and publication --------------------------------------------------------- Authors are invited to submit papers for presentation at the workshop. = Papers (no more than 8 camera-ready pages, 10 pt font in IEEE = transactions format) should present novel perspectives within the = general scope of the workshop (see below). Only original papers that = have not been published or submitted for publication elsewhere can be = submitted. All submission instructions can be found here:=20 http://www.ieee-lcn-onmove.org/submission.html Accepted papers will be published in the Proceedings of IEEE LCN and on = IEEE Xplore. Poster papers are an opportunity to present initial results and obtain = feedback on on-going research. We also welcome submissions for = demonstrations that showcase original research, practical = implementations and realistic applications of user mobility and = vehicular networks. Poster/demo papers must be restricted to 2 = camera-ready pages. Christer AAhlund -------=20 _______________________________________________ Tccc mailing list Tccc@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/tccc -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 03 15:59: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 1HjhSo-00011G-D5; Thu, 03 May 2007 15:59:42 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HfteE-0004MO-1u for mip4-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 04:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfteD-0004MF-Ip; Mon, 23 Apr 2007 04:11:45 -0400 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfteC-0000vk-2D; Mon, 23 Apr 2007 04:11:45 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.14.0/8.14.0) with ESMTP id l3N89rDk013324; Mon, 23 Apr 2007 10:09:53 +0200 Received: from [127.0.0.1] (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l3N89q723149 ; Mon, 23 Apr 2007 10:09:52 +0200 (MEST) Message-ID: <462C69EC.8030800@inria.fr> Date: Mon, 23 Apr 2007 10:10:20 +0200 From: Nathalie MITTON User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.13) Gecko/20060414 X-Accept-Language: fr, en MIME-Version: 1.0 To: arp@cines.fr, disc-announce@listes.epfl.ch, ActiveNets_Wire@ittc.ukans.edu, aaa-wg@merit.edu, announce@tcos.org, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, commsoft@ieee.org, comswtc@comsoc.org, conf@colmar.uha.fr, distbj@distributedcoalition.org, ecoop-info@ecoop.org, multicomm@comsoc.org, netnomics@listserver.tue.nl, reres@laas.fr, RHDM@lip6.fr, tcgn@ieee.org, wg2@wireless-world-research.org, wg3@wireless-world-research.org, mip6@ietf.org, mip4@ietf.org, mobisys@acm.org, pilc@ietf.org, announce@tcos.org, tccc@cs.columbia.edu, tci-announce@computer.org, MOBICOM@acm.org, wg7_3@cs.umass.edu, ifip-tc6@informatik.rwth-aachen.de, itc@i-teletraffic.org, KUVS-L@listserv.uni-heidelberg.de, types@cis.upenn.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Mon, 23 Apr 2007 10:09:53 +0200 (CEST) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Thu, 03 May 2007 15:59:41 -0400 Cc: Subject: [Mip4] ACM SANET - Call for papers - May 14th X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [ Our apologies for possible duplicates of this message ] ====================================================================== CALL FOR PAPERS SANET 2007 First ACM Workshop on Sensor Actor Networks http://www.lifl.fr/POPS/SANET2007 Montreal, Canada, Sept. 10, 2007 Organized and run in conjunction with ACM MobiCom 2007 http://www.sigmobile.org/mobicom/2007/ ====================================================================== Purpose The advent of nano-technology and advances in communications has made it technologically feasible and economically viable to develop low-power devices that integrate general-purpose computing with multi-purpose sensing and wireless communications capabilities. It is expected that sensor networks will have a significant impact on a wide array of applications ranging from military, to scientific, to industrial, to health-care, to domestic, to environmental, establishing ubiquitous wireless sensor networks that will pervade society redefining the way in which we live and work. Recently, in an attempt to integrate sensor networks in the fabric of human activities it has been recognized that it would be beneficial to augment sensor networks by either actuators or actors. Actuators are simple devices programmed to take immediate, one-shot, action in response to sensory input. Actors are more sophisticated entities that, in addition to actuating can provide a meaningful, long-term, interaction with the environment. This long-term interaction presupposes intelligent coordination with both the sensory data but also with anticipated changes in the environment. The resulting augmented version of sensor networks is commonly referred to as Sensor Actor Networks (SANET). SANET 2007 has for stated goal to be a high-profile workshop that brings together state-of-the-art contributions on the design, specification, and implementation of architectures and protocols for current and future applications of SANETs. Topics of Interest Topics of interest include, but are not limited to: * Autonomous sensor networks * Emergent behavior in SANET * Modeling and simulation of SANET * Autonomic and self-organizing coordination and communication * Sensor-actor and actor-actor coordination * Energy-efficient and real-time communication protocols * Distributed control in sensor-actor networks * Communication protocols for swarms of mobile actors * Biologically inspired communication * Ecological systems * Architectures and topology control * Localization in SANET * Probabilistic integration in SANET * SANET control and management * SANET security and robustness * SANET architectural and operational models * Applications and prototypes Paper Submission Submit a full paper of about 8 pages (ACM single-space, double-column format), including figures and references, using 10 font size, and number each page. Accepted papers will be published by published by ACM Press and distributed at the workshop; copies of the Proceedings will also be available for sale from ACM after the workshop. Papers must be submitted electronically through the EDAS system Important Dates Manuscript Submission: May 14, 2007, 11:59 GMT Acceptance Notification: June 18, 2007 Final Manuscript Due: July 13, 2007 Program Co-Chairs Silvia Giordano, SUPSI, Swittzerland Stephan Olariu, Old Dominion University, USA David Simplot-Ryl, University of Lille, INRIA, France Program Committee see web site. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 03 16:00:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjhTL-0001LC-O8; Thu, 03 May 2007 16:00:15 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HfthI-00058v-So for mip4-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 04:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfthI-00058n-Iv; Mon, 23 Apr 2007 04:14:56 -0400 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfthH-00018j-5G; Mon, 23 Apr 2007 04:14:56 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.14.0/8.14.0) with ESMTP id l3N87ojn012890; Mon, 23 Apr 2007 10:07:50 +0200 Received: from [127.0.0.1] (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l3N87W723064 ; Mon, 23 Apr 2007 10:07:32 +0200 (MEST) Message-ID: <462C6960.3090309@inria.fr> Date: Mon, 23 Apr 2007 10:08:00 +0200 From: Nathalie MITTON User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.13) Gecko/20060414 X-Accept-Language: fr, en MIME-Version: 1.0 To: mycolleagues@grid.lrg.ufsc.br, asr.rescom@cines.fr, arp@cines.fr, disc-announce@listes.epfl.ch, ActiveNets_Wire@ittc.ukans.edu, aaa-wg@merit.edu, announce@tcos.org, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, commsoft@ieee.org, comswtc@comsoc.org, conf@colmar.uha.fr, distbj@distributedcoalition.org, ecoop-info@ecoop.org, multicomm@comsoc.org, netnomics@listserver.tue.nl, reres@laas.fr, RHDM@lip6.fr, tcgn@ieee.org, wg2@wireless-world-research.org, wg3@wireless-world-research.org, mip6@ietf.org, mip4@ietf.org, mobisys@acm.org, pilc@ietf.org, announce@tcos.org, tccc@cs.columbia.edu, tci-announce@computer.org, MOBICOM@acm.org, wg7_3@cs.umass.edu, ifip-tc6@informatik.rwth-aachen.de, itc@i-teletraffic.org, KUVS-L@listserv.uni-heidelberg.de, types@cis.upenn.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Mon, 23 Apr 2007 10:07:53 +0200 (CEST) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Thu, 03 May 2007 16:00:14 -0400 Cc: Subject: [Mip4] [MASS 2007] Call for Workshops' Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- ***** CALL FOR WORKSHOPS PAPERS **** IEEE MASS 2007 WORKSHOPS http://cnd.iit.cnr.it/mass2007/workshops.html Pisa, October 8 & 12, 2007 Sponsored by IEEE, IEEE Computer Society, IEEE Technical Committee on Distributed Processing, and IEEE Technical Committee on Simulation in-cooperation with ACM SIGMOBILE ---------------------------------------------------------------------- The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2007) will host 10 workshops on technical subjects related to mobile and wireless ad hoc networking and its applications (see the list below). For more information about the workshops and the paper submission procedures, see http://cnd.iit.cnr.it/mass2007/workshops.html ********* MASS 2007 Workshops *********** ----------------------- Monday, October 8, 2007 ----------------------- PARIS: 1st International Workshop on Protocols and Algorithms for Reliable and Data Intensive Sensor Networks Papers due: April 30, 2007 WSNS: 3rd IEEE International Workshop on Wireless and Sensor Networks Security Papers due: April 30, 2007 MeshTech: 1st IEEE International Workshop on Enabling Technologies and Standards for Wireless Mesh Networking Papers due: May 15, 2007 MHWMN 2007: 3rd IEEE International Workshop on Heterogeneous Multi-Hop Wireless and Mobile Networks Papers due: May 15, 2007 BIONETWORKS 2007: A Workshop on Socially and Biologically Inspired Wired and Wireless Networks Papers due: April 30, 2007 MPPS: 1st International Workshop on Multilateral/Multiuser Privacy in Pervasive Systems Papers due: May 15, 2007 ------------------------ Friday, October 12, 2007 ------------------------ MASS-GHS: 1st International Workshop on Mobile Ad hoc and Sensor Systems for Global and Homeland Security Papers due: May 15, 2007 SensorFusion'07: Second International Workshop on Information Fusion and Dissemination in Wireless Sensor Networks Papers due: May 15, 2007 LOCAN 2007: The Third International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks Papers due: April 30, 2007 MoVeNet 2007: The First International Workshop on Mobile Vehicular Networks Papers due: May 7, 2007 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun May 06 10:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki3b-0007Wn-R1; Sun, 06 May 2007 10:49:51 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hki3b-0007WT-4X for mip4-confirm+ok@megatron.ietf.org; Sun, 06 May 2007 10:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki3a-0007WL-R5; Sun, 06 May 2007 10:49:50 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hki3Z-00074C-EN; Sun, 06 May 2007 10:49:50 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l46EotQS017156; Sun, 6 May 2007 09:50:55 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 09:49:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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, 6 May 2007 10:47:10 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542DF8@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mipshop] Multicast Mobility mailing list Thread-Index: AceFcvIMCPI2dJgsQFK5TTi0G+B0qwAVRh+xAolYmEA= References: From: "Suresh Krishnan \(QB/EMC\)" To: "Rajeev Koodli" , , , , , , X-OriginalArrivalTime: 06 May 2007 14:49:48.0656 (UTC) FILETIME=[CB712700:01C78FED] X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Mip4] RE: [Mipshop] Multicast Mobility mailing list X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Rajeev, Sorry for the late reply. I am on vacation and checking mail very = irregularly. Thanks for the offer to take up the problem work in = mobopts. I was not sure whether the solution space falls within the = purview of mobopts. =20 Thanks Suresh ________________________________ From: Rajeev Koodli [mailto:rajeev.koodli@nokia.com] Sent: Mon 23/04/2007 12:54 PM To: Suresh Krishnan (QB/EMC); mipshop@ietf.org; nemo@ietf.org; = monami6@ietf.org; mobopts@ietf.org; mip4@ietf.org; netlmm@ietf.org Subject: Re: [Mipshop] Multicast Mobility mailing list Hi Suresh, Good to see interest on this topic. As you may be aware, MobOpts has been looking into this topic for a = while now. draft-schmidt-mobopts-mmcastv6-ps-02.txt is a good document illustrating the problems and existing approaches to solving them, with about 50 references. This is adopted as the RG document. I think we will have interesting work to do starting with the problem description (with possibly more than one work item). It would be good to have the interests channeled together for maximum benefit. MobOpts has also been successful in handing over relatively mature = topics to IETF WGs when it makes sense. This is also something we can investigate = on this topic. Regards, -Rajeev On 4/22/07 11:45 PM, "ext Suresh Krishnan (QB/EMC)" wrote: > Hi Folks, >=20 > We wanted to inform you that we have created a new mailing list in = order > to discuss the interactions occuring between mobility and multicast. = We > invite anyone interested in contributing to the work to subscribe and > collaborate. To register visit the list page at: >=20 > https://www1.ietf.org/mailman/listinfo/multimob >=20 > Several of you have expressed interest in this work and some documents > already exist without a home working group. >=20 > The primary problem that we foresee being discussed in the mailing = list > is issues with Multicast listener (receiver) mobility for multicast > routing. There are several other associated problems like sender > mobility, which can also be discussed. >=20 > Thanks > Suresh and Behcet > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 07 03:37:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxmQ-0004PV-Fv; Mon, 07 May 2007 03:37:10 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HkxmP-0004PP-Io for mip4-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 03:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxmM-0004PC-8M for mip4@ietf.org; Mon, 07 May 2007 03:37:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkxmL-00010o-Rf for mip4@ietf.org; Mon, 07 May 2007 03:37:06 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l477b4eI014031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 May 2007 00:37:05 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l477b44X018642 for ; Mon, 7 May 2007 00:37:04 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 00:37:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7907A.81C2042F" Date: Mon, 7 May 2007 00:36:56 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF44E3CFE@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-tsirtsis-mip4-flowmove-01.txt thread-index: AceOha5LsiK260bFTCKRoAM4sk3EZQB9Lt1A From: "Tsirtsis, George" To: X-OriginalArrivalTime: 07 May 2007 07:37:04.0439 (UTC) FILETIME=[81F9CC70:01C7907A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-mip4-flowmove-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7907A.81C2042F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, May 04, 2007 8:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-tsirtsis-mip4-flowmove-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Flow Movement for Mobile IPv4 Author(s) : G. Tsirtsis, et al. Filename : draft-tsirtsis-mip4-flowmove-01.txt Pages : 29 Date : 2007-5-4 =09 Mobile IPv4 allows Mobile Nodes (MN) to create mobility bindings between their Home Address (HoA) and their current Care-of Address (CoA) in a Home Agent (HA) so that the HA can redirect traffic for the MN to its current location. This draft extends MIPv4 so that the binding granularity is on a per flow basis. Extensions are defined to allow the registration of multiple CoAs and the definition of individual flows. Individual flows can then be pointed to the registered CoAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsirtsis-mip4-flowmove-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-tsirtsis-mip4-flowmove-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-tsirtsis-mip4-flowmove-01.txt". =09 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_001_01C7907A.81C2042F Content-Type: application/octet-stream; name="ATT5156166.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT5156166.TXT Content-Disposition: attachment; filename="ATT5156166.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy01LTQxNDExNTguSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdHNpcnRzaXMtbWlwNC1mbG93 bW92ZS0wMS50eHQNCg== ------_=_NextPart_001_01C7907A.81C2042F Content-Type: application/octet-stream; name="draft-tsirtsis-mip4-flowmove-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-tsirtsis-mip4-flowmove-01.URL Content-Disposition: attachment; filename="draft-tsirtsis-mip4-flowmove-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10c2lydHNpcy1taXA0LWZsb3dtb3ZlLTAxLnR4dA0K ------_=_NextPart_001_01C7907A.81C2042F Content-Type: text/plain; name="ATT5156167.txt" Content-Transfer-Encoding: base64 Content-Description: ATT5156167.txt Content-Disposition: attachment; filename="ATT5156167.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C7907A.81C2042F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------_=_NextPart_001_01C7907A.81C2042F-- From mip4-bounces@ietf.org Mon May 07 18:50: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 1HlC2l-00071K-1n; Mon, 07 May 2007 18:50:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlC2O-0006I3-0r for mip4-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 18:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlC2N-0006HB-13; Mon, 07 May 2007 18:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlC2M-0007ku-JG; Mon, 07 May 2007 18:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 91E8317608; Mon, 7 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlC1q-0001sc-Ab; Mon, 07 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 07 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-06.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Fast Handovers Author(s) : R. Koodli, C. Perkins Filename : draft-ietf-mip4-fmipv4-06.txt Pages : 26 Date : 2007-5-7 This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-06.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-ietf-mip4-fmipv4-06.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-mip4-fmipv4-06.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: <2007-5-7155931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-fmipv4-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-fmipv4-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-7155931.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue May 08 06:37: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 1HlN4t-0007SE-RQ; Tue, 08 May 2007 06:37:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlN4s-0007QU-NO for mip4-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 06:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlN4s-0007QJ-Dm for mip4@ietf.org; Tue, 08 May 2007 06:37:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlN4s-0005zQ-1t for mip4@ietf.org; Tue, 08 May 2007 06:37:54 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l48AbqhA022304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 May 2007 03:37:53 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l48AbpZu024979 for ; Tue, 8 May 2007 03:37:52 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 03:37:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7915C.EDD16938" Date: Tue, 8 May 2007 03:37:49 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt thread-index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5w From: "Tsirtsis, George" To: X-OriginalArrivalTime: 08 May 2007 10:37:52.0225 (UTC) FILETIME=[EE2C5510:01C7915C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7915C.EDD16938 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, The following draft extends draft-yegani-gre-key-extension-02.txt for a slightly different use of GRE-keys in PMIPv4.=20 Let me know if you have any comments. Best Regards George=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, May 07, 2007 11:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : GRE-based L2 Tunneling with PMIPv4 Author(s) : G. Tsirtsis, V. Park Filename : draft-tsirtsis-l2gre-pmipv4-00.txt Pages : 15 Date : 2007-5-7 =09 This specification introduces mechanisms for creating a GRE-based L2 Tunnel with PMIPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-tsirtsis-l2gre-pmipv4-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-tsirtsis-l2gre-pmipv4-00.txt". =09 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_001_01C7915C.EDD16938 Content-Type: application/octet-stream; name="draft-tsirtsis-l2gre-pmipv4-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-tsirtsis-l2gre-pmipv4-00.URL Content-Disposition: attachment; filename="draft-tsirtsis-l2gre-pmipv4-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10c2lydHNpcy1sMmdyZS1wbWlwdjQtMDAudHh0DQo= ------_=_NextPart_001_01C7915C.EDD16938 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------_=_NextPart_001_01C7915C.EDD16938-- From mip4-bounces@ietf.org Tue May 08 13:27:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlTSi-0005Zc-5J; Tue, 08 May 2007 13:26:56 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlTSg-0005ZW-MF for mip4-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 13:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlTSg-0005ZO-Ca; Tue, 08 May 2007 13:26:54 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HlTSf-00022l-SL; Tue, 08 May 2007 13:26:54 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1178645212!2391194!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15394 invoked from network); 8 May 2007 17:26:52 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-153.messagelabs.com with SMTP; 8 May 2007 17:26:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l48HQpX2015805; Tue, 8 May 2007 10:26:52 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l48HQpaV015559; Tue, 8 May 2007 12:26:51 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l48HQoVg015545; Tue, 8 May 2007 12:26:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2007 13:26:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to advance draft-ietf-mip4-fmipv4-06.txt to Experimental RFC thread-index: AceRlg6oJSQbSbQGTcqxgBDc7Ww41g== From: "McCann Peter-A001034" To: "IESG Secretary" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Mobile IPv4 Mailing List , mip4-ads@tools.ietf.org Subject: [Mip4] Request to advance draft-ietf-mip4-fmipv4-06.txt to Experimental RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a request to advance draft-ietf-mip4-fmipv4-06.txt, "Mobile IPv4 Fast Handovers", to Experimental RFC. The draft has completed last call and all outstanding issues have been addressed. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Pete McCann is the document shepherd. Yes, I have personally=20 reviewed the document and it is ready for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document went through last call back in September of 2005 and has been discussed actively. We feel the document has obtained sufficient review, and I have no concerns about the depth or breadth of the reviews. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. No concerns. All issues have been addressed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is solid WG consensus behind the document. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No appeals have been threatened. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The document has been checked for nits. No nits found by the automated checker and no nits found by proofreading. The draft does not have any serious dependencies on other working groups so the review done by MIP4 probably suffices. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. Yes, references are split. All normative references are published RFCs. As this draft is intended for Experimental status, there are no downward references. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd conferred with > the Responsible Area Director so that the IESG can appoint the > needed Expert during the IESG Evaluation? The document contains a detailed IANA section. The document does not create any new registries. The requested allocations are described with appropriate references to the number spaces. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? There are no formal language descriptions in the document. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: >=20 > Technical Summary The document describes a new protocol designed to reduce the latency and packet loss experienced during handover. It does so by introducing new messages to be used among the Mobile Node (MN), Previous Access Router (PAR) and New Access Router (NAR). The messages allow the MN to establish a binding at the PAR such that packets are forwarded to/from the NAR immediately after a handover. This avoids the long round-trip time to the home network that would be incurred by a standard Mobile IPv4 messsage flow. > Working Group Summary The document underwent working group last call in September 2005, and has been actively discussed and edited since then. > Personnel > Who is the Document Shepherd for this document? Who is the > Responsible Area Director? Pete McCann is the document shepherd. Jari Arkko is the responsible AD. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 08 14:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlU2o-0006cC-3p; Tue, 08 May 2007 14:04:14 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hkz92-0007IN-8b for mip4-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 05:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkz8x-0007H9-WA; Mon, 07 May 2007 05:04:32 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hkz8x-0000nL-Hf; Mon, 07 May 2007 05:04:31 -0400 Received: from SNOOPY.unile.it (unknown [193.204.77.253]) by mailing.unile.it (Postfix) with ESMTP id 0E1EA104B43; Mon, 7 May 2007 11:04:08 +0200 (CEST) Message-Id: <7.0.1.0.2.20070507104820.02714420@unile.it> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 07 May 2007 11:04:08 +0200 To: softcom@fesb.hr,rozic@fesb.hr From: "Ing. Luigi Patrono" Mime-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-Mailman-Approved-At: Tue, 08 May 2007 14:04:12 -0400 Cc: Subject: [Mip4] Last Call: Symposium on Mobile Wireless Networks X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0593160631==" Errors-To: mip4-bounces@ietf.org --===============0593160631== Content-Type: multipart/alternative; boundary="=====================_5881484==.ALT" --=====================_5881484==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.) ************************************************************************************************************************************* Symposium on MOBILE WIRELESS NETWORKS September 27-29, 2007 Split-Dubrovnik (CROATIA) Symposium Chair: Mario De Blasi University of Lecce, Italy, (mario.deblasi@unile.it) The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC). The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility. We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication: * Ad Hoc Wireless Networks * Simulation, modelling or real-world test-beds of wireless networks and systems * Roadside-to-vehicle and vehicle-to-vehicle communication * Safety and non-safety applications * Wireless MAC protocols: design and analysis * Mobile Internet * Wireless Standards * Transport layer for Wireless Networks * Interoperability between heterogeneous Wireless Networks * Wireless Sensor Networks * Energy management in Ad Hoc Wireless Networks * Quality of Service in Wireless Networks Important dates: Paper submission: June 1, 2007 Notification of acceptance: July 1, 2007 Camera ready papers due: August 1, 2007 Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM). ---------------------------------------------------- Ing. Luigi Patrono, PhD ---------------------------------------------------- University of Lecce Dep. of Innovation Engineering Via Monteroni 73100 Lecce - ITALY Tel. +39 0832 297330 Fax. +39 0832 297279 e-mail: luigi.patrono@unile.it ---------------------------------------------------- --=====================_5881484==.ALT Content-Type: text/html; charset="us-ascii" (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.)
*************************************************************************************************************************************




Symposium on
MOBILE WIRELESS NETWORKS

September 27-29, 2007
Split-Dubrovnik (CROATIA)

Symposium Chair: Mario De Blasi
University of Lecce, Italy, (mario.deblasi@unile.it)


The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC).
 
The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility.
We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication:
* Ad Hoc Wireless Networks
* Simulation, modelling or real-world test-beds of wireless networks and systems
* Roadside-to-vehicle and vehicle-to-vehicle communication
* Safety and non-safety applications
* Wireless MAC protocols: design and analysis
* Mobile Internet
* Wireless Standards
* Transport layer for Wireless Networks
* Interoperability between heterogeneous Wireless Networks
* Wireless Sensor Networks
* Energy management in Ad Hoc Wireless Networks
* Quality of Service in Wireless Networks

Important dates:  
                          Paper submission: June 1, 2007
                          Notification of acceptance: July 1, 2007
                          Camera ready papers due: August 1, 2007


Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM).






----------------------------------------------------
Ing.  Luigi Patrono,  PhD
----------------------------------------------------
University of Lecce
Dep. of Innovation Engineering
Via Monteroni
73100 Lecce - ITALY

Tel.  +39 0832 297330
Fax. +39 0832 297279
e-mail: luigi.patrono@unile.it
---------------------------------------------------- --=====================_5881484==.ALT-- --===============0593160631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0593160631==-- From mip4-bounces@ietf.org Tue May 08 18:50: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 1HlYWD-0002BL-SA; Tue, 08 May 2007 18:50:53 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlYVu-0001lH-Kq for mip4-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 18:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVt-0001ie-7T; Tue, 08 May 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlYVs-0007t6-TW; Tue, 08 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9B1D017613; Tue, 8 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlYVO-0002F0-AF; Tue, 08 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for Configuration Options Exchange Author(s) : J. Bharatia, et al. Filename : draft-ietf-mip4-gen-ext-03.txt Pages : 13 Date : 2007-5-8 This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-03.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-ietf-mip4-gen-ext-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-mip4-gen-ext-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: <2007-5-8150830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-gen-ext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-gen-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8150830.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue May 08 19:29: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 1HlZ7j-00009T-6H; Tue, 08 May 2007 19:29:39 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlZ7h-00007N-5P for mip4-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 19:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ7g-00006E-Pp for mip4@ietf.org; Tue, 08 May 2007 19:29:36 -0400 Received: from mail.ece.gatech.edu ([143.215.151.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZ7g-0003oO-C8 for mip4@ietf.org; Tue, 08 May 2007 19:29:36 -0400 Received: from gc556bwnlap07 (c-24-131-45-131.hsd1.ga.comcast.net [24.131.45.131]) (authenticated bits=0) by mail.ece.gatech.edu (8.14.0/8.13.7) with ESMTP id l48NST18005556 for ; Tue, 8 May 2007 19:28:29 -0400 (EDT) From: "Dario Pompili" To: Date: Tue, 8 May 2007 19:29:12 -0400 Message-ID: <014801c791c8$b2a51b00$6601a8c0@ece.gatech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceRyEA2Tdi7dmaWSKaEjQcFLRKwoQAAAnagAAAXGGA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.8.160545 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_PBL_10 2.5, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, RELAY_IN_PBL 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_BROADBAND_4 0, __RDNS_POOLED_10 0, __SANE_MSGID 0, __USER_AGENT_MS_GENERIC 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [Mip4] CFP: The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) - Submission deadline (EXTENDED): May 18, 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [We apologize in advance if you receive multiple copies of this CFP] __________________________________________________________________________ __________________________________________________________________________ The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) http://wuwnet07.engr.uconn.edu/ In conjunction with ACM MobiCom 2007 September 14, 2007 Montreal, Quebec, Canada Sponsored by ACM SIGMOBILE __________________________________________________________________________ __________________________________________________________________________ Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are critical in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication and the complexity of diverse aquatic environments require us to completely re-think how a network should be deployed in underwater environments. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multi-path propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that nodes can passively move due to water currents and dispersion. All the above distinct features of underwater networks yield grand challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practitioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, keynote speeches, a panel session and a poster/demo session. Submissions for technical papers should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Data storage and management - Power and resource management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Network planning and deployment - New techniques for aquatic applications - New applications for underwater networks - Testbed and systems: real-world experiences and lessons Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for full papers (4 pages for short papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. All accepted papers will appear in the workshop proceedings. Detailed instructions for paper submission will be posted on the workshop website. Important Dates *************** Submission deadline (EXTENDED): May 18, 2007 Acceptance notification: June 16, 2007 Camera-ready version due: June 30, 2007 Workshop date: September 14, 2007 Organizing Committee ******************** General Co-Chairs: Ian F. Akyildiz (Georgia Institute of Technology) David Hung-Chang Du (University of Minnesota/NSF) Technical Program Co-Chairs: Robert H. Headrick (Office of Naval Research) Michele Zorzi (University of Padova, Italy) WUWNet Steering Committee: Ian F. Akyildiz (Georgia Institute of Technology) Jun-Hong Cui (University of Connecticut, Chair) David Hung-Chang Du (University of Minnesota/NSF) Kevin Fall (Intel Research, Berkeley) John Heidemann (University of Southern California/ISI) Urbashi Mitra (University of Southern California) Milica Stojanovic (Massachusetts Institute of Technology) Publicity Co-Chairs: Qilian Liang (University of Texas at Arlington) Dario Pompili (Georgia Institute of Technology) Work-In-Progress Poster Co-Chairs: Volkan Rodoplu (University of California at Santa Barbara) Wei Ye (University of Southern California/ISI) Demo Co-Chairs: Payman Arabshahi (University of Washington) Geoffrey Xie (Naval Postgrad School) Finance Chair: Shengli Zhou (University of Connecticut) Technical Program Committee (incomplete) **************************************** Jun-Hong Cui (University of Connecticut) Kevin Fall (Intel Research, Berkeley) Joo Pedro Gomes (Instituto Superior Tecnico, Portugal) Al Harris (University of Illinois at Urbana-Champaign) Brian Levine (University of Massachusetts) Urbashi Mitra (University of Southern California) James Preisig (Woods Hole Oceanographic Institution (WHOI)) Robert Qiu (Tennessee Technological University) Volkan Rodoplu (University of California, Santa Barbara) Sumit Roy (University of Washington) Winston Seah (Institute for Infocomm Research, Singapore) Milica Stojanovic (Massachusetts Institute of Technology) Yang Xiao (University of Alabama) Wei Ye (University of Southern California/ISI) ********************************************* Dario Pompili, Ph.D. Broadband & Wireless Networking Laboratory School of Electrical & Computer Engineering Georgia Institute of Technology, Atlanta, GA Email: dario@ece.gatech.edu http://users.ece.gatech.edu/dario/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 08 21:05: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 1Hlacu-0004uB-BD; Tue, 08 May 2007 21:05:56 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hlact-0004ty-24 for mip4-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 21:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlacs-0004tq-OT for mip4@ietf.org; Tue, 08 May 2007 21:05:54 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlacs-00088X-Cm for mip4@ietf.org; Tue, 08 May 2007 21:05:54 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160] helo=[127.0.0.1]) by a2s13.a2hosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Hlaco-0000iz-GV for mip4@ietf.org; Tue, 08 May 2007 21:05:51 -0400 Message-ID: <46411E65.1050307@acm.org> Date: Tue, 08 May 2007 17:05:41 -0800 From: Ken Laberteaux User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mip4@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------010601020404020703040707" X-A2hosting-MailScanner-Information: Please contact the ISP for more information X-A2hosting-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-A2hosting-MailScanner-SpamCheck: X-A2hosting-MailScanner-From: klaberte@acm.org X-Spam-Status: No X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2s13.a2hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acm.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Mip4] Reminder: VANET 2007 Submissions due May 14 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --------------010601020404020703040707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------010601020404020703040707 Content-Type: text/plain; name="VANET-2007-CFP.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="VANET-2007-CFP.txt" ANNOUNCEMENT and CALL FOR PAPERS VANET 2007 The Fourth ACM International Workshop on Vehicular Ad Hoc Networks In conjunction with ACM MobiCom 2007 September 10, 2007 Montréal, QC, Canada Sponsored by ACM SIGMOBILE http://www.sigmobile.org/workshops/vanet2007/ Important Dates: Paper Submission Deadline: May 14, 2007, 11:59 p.m. GMT Notification of Acceptance: June 18, 2007 Camera-Ready Deadline: July 16, 2007 The goal of this workshop is to present and discuss recent advances in the development of wireless vehicular ad hoc networking (VANET) technologies. Based on short- to medium-range communication systems (vehicle-to-vehicle and vehicle-to-roadside), vehicular ad hoc networks will enable vehicular safety applications (including collision and other safety warnings) as well as non-safety applications (like real-time traffic congestion and routing information, high-speed tolling, mobile infotainment, and many others). The creation of high-performance, highly reliable, highly scalable, and secure VANET technologies presents an extraordinary challenge for the wireless research community. A high degree of communication reliability is needed under unfavorable conditions. Clearly, the specificity of vehicular ad hoc networks in terms of mobility behavior and applications scenarios and requirements makes VANET research an exciting and demanding application- and purpose-driven sub-discipline of wireless networking. Following the successes of VANET 2004 held in Philadelphia, VANET 2005 held in Cologne, Germany, and VANET 2006 in Los Angeles, CA, the Fourth ACM International Workshop on Vehicular Ad Hoc Networks (VANET) will be held in Montréal, QC, Canada September 14, 2007, in conjunction with MobiCom 2007. Authors are invited to submit papers presenting new research related to the theory or practice of vehicular ad hoc networks (VANET). All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Areas of interest include, but are not limited to: - Safety and non-safety applications - Roadside-to-vehicle and vehicle-to-vehicle communication - Communication protocol design - Channel modeling - Modulation and coding - Power control and scalability issues - Multi-channel organization and operation - Security issues and countermeasures - Privacy issues - Network management - Simulation frameworks & real-world testbeds VANET present a highly active field of research, development, standardization and field trials. Throughout the world, there are many national/international projects in government, industry, and academia devoted to VANET. These include the consortia like Vehicle Safety Consortium (US), Car-2-Car Communication Consortium (Europe) and Advanced Safety Vehicle Program (Japan), standardization efforts like IEEE 802.11p (WAVE), and field trials like the large-scale Vehicle Infrastructure Integration Program (VII) in the US. Submission Instructions All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 10 pages (single- or double-column), in font no smaller than 11 points, and must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Submitted papers will be judged based on their quality through a double-blind review process, where the identities of the authors are withheld from the reviewers. Detailed instructions for paper submission will be posted on the VANET 2007 web page at: http://www.sigmobile.org/workshops/vanet2007/. General Co-Chairs: Wieland Holfelder, DaimlerChrysler REDNA Paolo Santi, Italian Natl. Research Council Technical Program Co-Chairs: Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Web Chair: Ken Laberteaux, Toyota Technical Center Technical Program Committee (partial list): Victor Bahl, Microsoft Research Fan Bai, General Motors Levente Buttyan, Budapest University of Technology and Economics Tracy Camp, Colorado School of Mines Eylem Ekici, Ohio State University Tamer ElBatt, San Diego Research Center Andreas Festag, NEC Europe Ltd Hannes Hartenstein, University of Karlsruhe Wieland Holfelder, DaimlerChrysler REDNA Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Markus Jakobsson, Indiana University Daniel Jiang, DaimlerChrysler REDNA Frank Kargl, Ulm University Timo Kosch, BMW Ken Laberteaux, Toyota Technical Center Martin Mauve, Heinrich Heine University Düsseldorf Christof Paar, Ruhr-University Bochum Panos Papadimitratos, EPFL Adrian Perrig, Carnegie Mellon University Maxim Raya, EPFL Paolo Santi, CNR Rajeev Shorey, General Motors Research Pravin Varaiya, University of California at Berkeley --------------010601020404020703040707 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --------------010601020404020703040707-- From mip4-bounces@ietf.org Wed May 09 16:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsME-0006IX-BP; Wed, 09 May 2007 16:01:54 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlsMD-0006IS-JD for mip4-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 16:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsMD-0006IK-9g for mip4@ietf.org; Wed, 09 May 2007 16:01:53 -0400 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlsMB-0000MO-Uv for mip4@ietf.org; Wed, 09 May 2007 16:01:53 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 09 May 2007 13:01:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.14,510,1170662400"; d="scan'208";a="226288412" Received: from orsmsx334.jf.intel.com ([10.22.226.45]) by azsmga001.ch.intel.com with ESMTP; 09 May 2007 13:01:53 -0700 Received: from orsmsx418.amr.corp.intel.com ([10.22.226.87]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 13:01:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: your support: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Date: Wed, 9 May 2007 13:01:28 -0700 Message-ID: <34B734D4F6C5BE4FB378F15FCD763A6103183CDF@orsmsx418.amr.corp.intel.com> In-Reply-To: <001001c7925b$128788e0$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: your support: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Thread-Index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQFZsQ+wAAZRF5A= From: "Adrangi, Farid" To: , X-OriginalArrivalTime: 09 May 2007 20:01:50.0416 (UTC) FILETIME=[E1B84500:01C79274] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Given the proposed attributes help support Mobile IP in a way that is uniform across SDOs & ensures interoperability, "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." Thanks, Farid -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Wednesday, May 02, 2007 12:56 PM To: mip4@ietf.org; radiusext@ops.ietf.org Cc: Henrik Levkowetz Subject: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt This message announces a 2 week working group last call on: "Mobile IPv4 RADIUS Requirements" draft-ietf-mip4-radius-requirements-02.txt.=20 The last call will end at 24:00 UTC on Wednesday, May 16th.=20 "Mobile IPv4 RADIUS Requirements" lists a set of goals and assumptions to lay the groundwork for future RADIUS extensions in support of Mobile IPv4. A URL for this internet draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 02.txt Please respond to this working group last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like =20 "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." If you have comments, please use a line similar to the one above, and supplement this with your comments. =20 =20 * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your=20 comments - =20 "I don't support the advancement of this document to the IESG with a request for publication as an Informational RFC, for the following reasons:" ... Please direct all replies to the Mobile IPv4 mailing list, mip4@ietf.org. -Pete & Henrik --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 09 22:29:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyPN-0006T0-5K; Wed, 09 May 2007 22:29:33 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HlyPL-0006RY-Sg for mip4-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 22:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyPL-0006Qm-Gs for mip4@ietf.org; Wed, 09 May 2007 22:29:31 -0400 Received: from tyo201.gate.nec.co.jp ([202.32.8.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlyPJ-0008UC-Uh for mip4@ietf.org; Wed, 09 May 2007 22:29:31 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l4A2TS95008493 for ; Thu, 10 May 2007 11:29:28 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l4A2TSP08615 for mip4@ietf.org; Thu, 10 May 2007 11:29:28 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id l4A2TRO28970 for ; Thu, 10 May 2007 11:29:27 +0900 (JST) Received: from atenza ([10.56.131.18] [10.56.131.18]) by mail.jp.nec.com with ESMTP; Thu, 10 May 2007 11:29:27 +0900 To: mip4@ietf.org Message-Id: <20070510113154j-awano@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1D0034 From: j-awano@az.jp.nec.com Date: Thu, 10 May 2007 11:31:54 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Mip4] Question about RFC4721(MIPv4 Challenge/Response) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, I have a question about RFC4721 (MIPv4 Challenge/Response Extension). According to the document, a MN can use challenge value which was included in the last received RRP when the MN sends RRQ. My question is that the MN still can use the challenge gotten by RRP even if the MN has processed deregistration. I think a MN can't. Because a FA is supporsed to be deleted all information of a MN which has processed deregistratrion. Is it right? Best Regards, Jun -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 09 22:55: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 1Hlyoi-0004PZ-R3; Wed, 09 May 2007 22:55:44 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hlyoh-0004PU-8P for mip4-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 22:55:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlyog-0004PM-VF for mip4@ietf.org; Wed, 09 May 2007 22:55:42 -0400 Received: from tyo201.gate.nec.co.jp ([202.32.8.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlyof-0003eC-Ax for mip4@ietf.org; Wed, 09 May 2007 22:55:42 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l4A2tdhe011090 for ; Thu, 10 May 2007 11:55:39 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l4A2tdu22852 for mip4@ietf.org; Thu, 10 May 2007 11:55:39 +0900 (JST) Received: from togyo.jp.nec.com (togyo.jp.nec.com [10.26.220.4]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l4A2tc224157 for ; Thu, 10 May 2007 11:55:39 +0900 (JST) Received: from atenza ([10.56.131.18] [10.56.131.18]) by mail.jp.nec.com with ESMTP; Thu, 10 May 2007 11:55:38 +0900 To: mip4@ietf.org Subject: Re: [Mip4] Question about RFC4721(MIPv4 Challenge/Response) In-reply-to: <20070510113154j-awano@mail.jp.nec.com> Message-Id: <20070510115806j-awano@mail.jp.nec.com> References: <20070510113154j-awano@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1D0034 From: j-awano@az.jp.nec.com Date: Thu, 10 May 2007 11:58:06 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Sorry, I made a mistake. >Because a FA is supporsed to be deleted all information of a MN which >has processed deregistratrion. Not all information. Exception exists. (mainly preconfigured info. like HoA, Mobility SA etc..) Best Regards, Jun 2007/05/10 11:31:54 +0900$B$K(Bj-awano@az.jp.nec.com$B$5$s$KD:$$$?(B $B!V(B[Mip4] Question about RFC4721(MIPv4 Challenge/Response)$B!W$X$NJV;v$G$9!#(B >Hi, > >I have a question about RFC4721 (MIPv4 Challenge/Response Extension). >According to the document, a MN can use challenge value which was included >in the last received RRP when the MN sends RRQ. >My question is that the MN still can use the challenge gotten by RRP even >if the MN has processed deregistration. >I think a MN can't. >Because a FA is supporsed to be deleted all information of a MN which >has processed deregistratrion. >Is it right? > >Best Regards, >Jun > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 10 07:32: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 1Hm6tG-00025W-Ai; Thu, 10 May 2007 07:32:58 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hm6tF-00025Q-6Z for mip4-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 07:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6tE-00025I-TI for mip4@ietf.org; Thu, 10 May 2007 07:32:56 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm6tD-0006Op-Mj for mip4@ietf.org; Thu, 10 May 2007 07:32:56 -0400 Received: by py-out-1112.google.com with SMTP id f31so428137pyh for ; Thu, 10 May 2007 04:32:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=ZTW4cE1zjCeu72PdvziX1kAJW5V9B+3FxCO/oY/XRIop7+cGbR8VomVWdJ4L9Js6sIFQI+Xxv7jNBKu1KIcynoC4jUkDJza6aBpByxy9gZkUFz+nScfwH3HiO4vxG5Nr/dasz2dZ0WZ561vW1D5CmG9uioH2mDzFzWEMLSCSWiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Q/ICG1885jaZQ5re43XZkqRveAtkXzb9Cz8yc9VzldOfvLx1b44ABachln1I7vwUHk0Vv6jZZxQVwT4jlY/WDzRCRx5rc79zq17eRcnggd1V0TMFaMwLHBwYi4tZrCbnaRukYplJJNguQAdjpvtbgO1j6hw6Zgl8nceFkUwZ/PU= Received: by 10.65.43.17 with SMTP id v17mr3067091qbj.1178796775362; Thu, 10 May 2007 04:32:55 -0700 (PDT) Received: by 10.65.252.12 with HTTP; Thu, 10 May 2007 04:32:55 -0700 (PDT) Message-ID: <88bc8c7a0705100432s7b187c4bwe587e79b6b1f2b75@mail.gmail.com> Date: Thu, 10 May 2007 14:32:55 +0300 From: "Bjorn Andersson" To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 70f35a42127fef21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip4] RFC3024 on multicasting X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org RFC3024 states: "Mobile nodes that wish to send either broadcast or multicast packets MUST use the Encapsulating Delivery Style." Is this really a MUST? On point-to-point links the encap delvivery style does not seem to give any added value. On the contrary it adds unnecessary overhead. Also, on links such as ethernet couldn't the MN send the packet with the unicast FA link address and multicast/broadcast IP address? Or would this behaviour violate some other specification? I have vague feeling that some spec says that IP multicast/broadcast packets MUST use multicast/broadcast L2 addresses, but I am not sure. Is it so? Bjorn -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 11 01:40: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 1HmNrz-00031s-FU; Fri, 11 May 2007 01:40:47 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmNrx-00031m-MJ for mip4-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 01:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNrx-00031e-AE for mip4@ietf.org; Fri, 11 May 2007 01:40:45 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNru-0000ky-Sa for mip4@ietf.org; Fri, 11 May 2007 01:40:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 834C49000A for ; Fri, 11 May 2007 01:40:39 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12496-11 for ; Fri, 11 May 2007 01:40:34 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 11 May 2007 01:40:34 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 01:40:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Fri, 11 May 2007 01:40:33 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9FE9@exchtewks2.starentnetworks.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAIx/6FA= From: "Chowdhury, Kuntal" To: "Tsirtsis, George" , X-OriginalArrivalTime: 11 May 2007 05:40:34.0131 (UTC) FILETIME=[E5147230:01C7938E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org George, A general question for clarification: is PMIPv4 accepted as a work item in IETF? If not, I am not sure what is the goal of this (yet another PMIP4 related) document. -Kuntal > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Tuesday, May 08, 2007 5:38 AM > To: mip4@ietf.org > Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi everyone, >=20 > The following draft extends draft-yegani-gre-key-extension-02.txt for a > slightly different use of GRE-keys in PMIPv4. >=20 > Let me know if you have any comments. >=20 > Best Regards > George >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, May 07, 2007 11:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : GRE-based L2 Tunneling with PMIPv4 > Author(s) : G. Tsirtsis, V. Park > Filename : draft-tsirtsis-l2gre-pmipv4-00.txt > Pages : 15 > Date : 2007-5-7 >=20 > This specification introduces mechanisms for creating a GRE-based L2 > Tunnel with PMIPv4. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > 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. >=20 > 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-tsirtsis-l2gre-pmipv4-00.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 11 08:22:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmU8d-0004LA-Jf; Fri, 11 May 2007 08:22:23 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmU8c-0004L3-Hh for mip4-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 08:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmU8c-0004Ks-80 for mip4@ietf.org; Fri, 11 May 2007 08:22:22 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmU8b-0001ab-Pq for mip4@ietf.org; Fri, 11 May 2007 08:22:22 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 82DD61986A0; Fri, 11 May 2007 15:22:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0E9AC198675; Fri, 11 May 2007 15:22:20 +0300 (EEST) Message-ID: <46445FFC.9040004@piuha.net> Date: Fri, 11 May 2007 15:22:20 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: McCann Peter-A001034 , draft-ietf-mip4-fmipv4@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Mobile IPv4 Mailing List Subject: [Mip4] AD review of draft-ietf-mip4-fmipv4-06.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, all, I have reviewed this specification and while it is generally in good shape for an Experimental RFC publication, there were a number of questions and issues that I believe need to be addressed before we can go to IETF Last Call. In Section 3, did you mean "default router reachability" when you wrote "default agent reachability"? Section 6.3 says this: > New Access Point Link-layer Address: The link-layer address or > identification of the access point for which the MN requests > routing advertisement information. It MUST be included in all > RtSolPr messages. More than one such address or identifier can > be present. This field can also be a wildcard address (see > Section 7.1). And then later Section 6.4 > New Access Point Link-layer Address: The link-layer address or > identification of the access point is copied from RtSolPr > message. This option MUST be present. > > ... > > New CoA Option: MAY be present when PrRtAdv is sent > unsolicited. There are a couple of issues around the role of New Access Point Link-layer Address option. Since you allow wildcards, what does the copying requirement mean? Copy the wildcard, or the matching entries? > New CoA Option: MAY be present when PrRtAdv is sent > unsolicited. PAR MAY compute new CoA using NAR's prefix > information and the MN's L2 address, or by any other means. In > any case, the MN should be prepared to use this address instead > of performing DHCP or similar operations to obtain an IPv4 > address. First, why would this be present only in an unsolicited message? Second, the combination of prefix and L2 address appears to be copied from IPv6 and not directly applicable in IPv4. Third, how is the lifetime of this address determined? When can the new access router re-allocate the same address for someone else? Why is there no instruction on what the NAR/PAR does in order to find such addresses. RFC 4068 had these instructions... Or are you saying in Section 1 that you always use foreign agent care-of address? If so, please require this later in the document when you transport the addresses around. In Section 6.4 you say: > New Access Point Link-layer Address: The link-layer address or > identification of the access point is copied from RtSolPr > message. This option MUST be present. > > ... > > A Proxy Router Advertisement with Code 3 means that new router > information is only present for a subset of access points requested. > The Option-Code values in the LLA option distinguish different > outcomes (see Section 7.1). If we get Code 3, is there a New Access Point Link-layer Address option included anyway? What would its contents be, in this case? > Type: To be assigned by IANA > > Code: 0 RtSolPr and PrRtAdv ask for an ICMP Type code to be assigned. I'm trying to understand why, given that RFC 4068 uses type code 150 allocated in RFC 4065 for experimental mobility purposes. RFC 4065 has a corresponding type code for IPv4, too (value 41). > 9. IANA Considerations > > All the messages and the option formats specified in this document > require Type assignment from IANA. Specifically, the Types, Sub- > types and the Codes need assignment from ICMP, Mobile IP and > Experimental Mobility Type [rfc4065] registries. It took a while for me to parse what this means, and it would be better if you can write the IANA instructions in a more explicit manner. In particular, you are asking ICMP Types and Mobile IP Type allocations, so at least explain what values are allocating from what registry. Also, this section may be affected by any changes resulting from my previous comment. Finally, the IANA considerations section is missing all instructions regarding future allocations from Option-Code and Code fields. Are these namespaces expected to be independent new spaces, or go in sync with RFC 4068? Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 11 10:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVqI-0007lH-Kr; Fri, 11 May 2007 10:11:34 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmVqI-0007lC-8U for mip4-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 10:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVqH-0007l4-VG for mip4@ietf.org; Fri, 11 May 2007 10:11:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVqG-0006Ec-Gu for mip4@ietf.org; Fri, 11 May 2007 10:11:33 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4BEBVkh010513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 May 2007 07:11:31 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4BEBIjN005682; Fri, 11 May 2007 07:11:30 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 07:11:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Fri, 11 May 2007 07:12:00 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4579F36@NAEX16.na.qualcomm.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9FE9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAIx/6FAAEcylYA== References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> <7CCD07160348804497EF29E9EA5560D7024D9FE9@exchtewks2.starentnetworks.com> From: "Tsirtsis, George" To: "Chowdhury, Kuntal" , X-OriginalArrivalTime: 11 May 2007 14:11:29.0221 (UTC) FILETIME=[44EFF750:01C793D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Kuntal, As you know, at this point, PMIPv4 is not part of any WG charter. As far as I understand, however, anyone can submit a personal draft. All work in the IETF, in fact, starts with personal drafts. I hope you do not have a problem with that. Regards George -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, May 11, 2007 6:41 AM To: Tsirtsis, George; mip4@ietf.org Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt=20 George, A general question for clarification: is PMIPv4 accepted as a work item in IETF? If not, I am not sure what is the goal of this (yet another PMIP4 related) document. -Kuntal > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Tuesday, May 08, 2007 5:38 AM > To: mip4@ietf.org > Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi everyone, >=20 > The following draft extends draft-yegani-gre-key-extension-02.txt for a > slightly different use of GRE-keys in PMIPv4. >=20 > Let me know if you have any comments. >=20 > Best Regards > George >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, May 07, 2007 11:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : GRE-based L2 Tunneling with PMIPv4 > Author(s) : G. Tsirtsis, V. Park > Filename : draft-tsirtsis-l2gre-pmipv4-00.txt > Pages : 15 > Date : 2007-5-7 >=20 > This specification introduces mechanisms for creating a GRE-based L2 > Tunnel with PMIPv4. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > 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. >=20 > 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-tsirtsis-l2gre-pmipv4-00.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 11 14:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZrb-0001RD-M4; Fri, 11 May 2007 14:29:11 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmZra-0001R7-3e for mip4-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 14:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZrZ-0001Qz-Q0; Fri, 11 May 2007 14:29:09 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmZrY-0008C4-8R; Fri, 11 May 2007 14:29:09 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1178908145!9769241!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5689 invoked from network); 11 May 2007 18:29:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 11 May 2007 18:29:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4BIT5pO019301; Fri, 11 May 2007 11:29:05 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4BIT42r007161; Fri, 11 May 2007 13:29:04 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4BIT4F6007147; Fri, 11 May 2007 13:29:04 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 May 2007 14:29:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to advance draft-ietf-mip4-gen-ext-03.txt to Proposed Standard thread-index: AceT+j+zTn2AJB/iTniUsko76Bwh0A== From: "McCann Peter-A001034" To: "IESG Secretary" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Mobile IPv4 Mailing List , mip4-ads@tools.ietf.org Subject: [Mip4] Request to advance draft-ietf-mip4-gen-ext-03.txt to Proposed Standard X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a request to advance draft-ietf-mip4-gen-ext-03.txt, "Mobile IPv4 Extension for Configuration Options Exchange", to Proposed Standard RFC. The draft has completed last call=20 and all outstanding issues have been addressed. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Pete McCann is the document shepherd. Yes, I have personally=20 reviewed the document and it is ready for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been adequately reviewed. I have no concern about the reviews. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? To be safe, the document should probably be reviewed by the dhc working group during IETF Last Call to make sure there are no inconsistencies with the way DHCP works and this draft. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. No issues. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is unanimous consensus to advance the document. I believe that the WG as a whole understands the approach and is comfortable with the document. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No appeals have been threatened. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? No nits found by the automated checker, and no nits found during manual proof-reading. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. The document has 4 normative reference, each one a published RFC of Proposed Standard or better status. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd conferred with > the Responsible Area Director so that the IESG can appoint the > needed Expert during the IESG Evaluation? The IANA Considerations section is complete. One assignment from=20 the Mobile IP extension space for skippable extensions is requested. Two new number spaces are created and both give a policy of approval by Designated Expert. We have not yet discussed the appointment of such an expert but will do so shortly. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal notation is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: >=20 > Technical Summary Existing Mobile IPv4 specifications allow for the configuration of a home address during Mobile IP Registration processing. This document extends the range of parameters that can be configured during registration by allowing for the transport of arbitrary DHCP options in a Mobile IP Registration Request or Response. The options are carried in a new extension to the Mobile IP registration and borrow their structure from existing DHCP options. > Working Group Summary The document completed last call in the mip4 working group in November, 2006. > Personnel > Who is the Document Shepherd for this document? Who is the > Responsible Area Director? Pete McCann is the document shepherd. Jari Arkko is the responsible AD. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 11 17:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcYu-0000xE-UU; Fri, 11 May 2007 17:22:04 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmcYt-0000wy-QQ for mip4-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcYt-0000wi-1i for mip4@ietf.org; Fri, 11 May 2007 17:22:03 -0400 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 1HmcYs-0005XR-CJ for mip4@ietf.org; Fri, 11 May 2007 17:22:03 -0400 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 l4BLLiTq016641; Sat, 12 May 2007 00:21:59 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 00:21:34 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 16:21:30 -0500 Received: from 10.241.58.17 ([10.241.58.17]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 21:21:29 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 11 May 2007 14:22:13 -0700 From: Rajeev Koodli To: ext Jari Arkko , McCann Peter-A001034 , Message-ID: Thread-Topic: AD review of draft-ietf-mip4-fmipv4-06.txt Thread-Index: AceUEnEHr7+COgAFEdy/YgAWy5YJpw== In-Reply-To: <46445FFC.9040004@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2007 21:21:30.0138 (UTC) FILETIME=[577B77A0:01C79412] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Mobile IPv4 Mailing List , Rajeev Koodli Subject: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Jari, Thanks for the review. See my responses inline. > In Section 3, did you mean "default router reachability" > when you wrote "default agent reachability"? Yes (we have assumed FA acting as a router). > > Section 6.3 says this: > >> New Access Point Link-layer Address: The link-layer address or >> identification of the access point for which the MN requests >> routing advertisement information. It MUST be included in all >> RtSolPr messages. More than one such address or identifier can >> be present. This field can also be a wildcard address (see >> Section 7.1). > > And then later Section 6.4 > >> New Access Point Link-layer Address: The link-layer address or >> identification of the access point is copied from RtSolPr >> message. This option MUST be present. >> >> ... >> >> New CoA Option: MAY be present when PrRtAdv is sent >> unsolicited. > > There are a couple of issues around the role of New Access Point > Link-layer Address option. Since you allow wildcards, what does > the copying requirement mean? Copy the wildcard, or the matching > entries? > It's the LLA. Wildcard only says provide information about all possible neighborhood access points. PrRtAdv contains the [AP-ID, AR-Info] tuple, which is what you see as Valid options in Section 6.4. Multiple such tuples may be present as a result of multiples LLAs present or a wildcard request in RtSolPr. So, the copy statement is applicable to LLAs present in RtSolPr. When the wildcard is present, PAR includes the LLA on its own. If it would help, I can add a sentence to make it clear. >> New CoA Option: MAY be present when PrRtAdv is sent >> unsolicited. PAR MAY compute new CoA using NAR's prefix >> information and the MN's L2 address, or by any other means. In >> any case, the MN should be prepared to use this address instead >> of performing DHCP or similar operations to obtain an IPv4 >> address. > First, why would this be present only in an unsolicited message? In RFC 4068, the unsolicited mode means a network-initiated handover, in which case the MN needs an NCoA, which is supplied in PrRtAdv. We have re-used it here, even though we do not bind the PCoA to NCoA (but to the new FA's address). > > Second, the combination of prefix and L2 address appears to be > copied from IPv6 and not directly applicable in IPv4. Yes. > > Third, how is the lifetime of this address determined? When can the > new access router re-allocate the same address for someone else? > Why is there no instruction on what the NAR/PAR does in order to > find such addresses. RFC 4068 had these instructions... Or are you > saying in Section 1 that you always use foreign agent care-of > address? If so, please require this later in the document when > you transport the addresses around. > Even with New CoA, the binding is always for the new FA's address. I will add this requirement again in Section 6.4. > In Section 6.4 you say: > >> New Access Point Link-layer Address: The link-layer address or >> identification of the access point is copied from RtSolPr >> message. This option MUST be present. >> >> ... >> >> A Proxy Router Advertisement with Code 3 means that new router >> information is only present for a subset of access points requested. >> The Option-Code values in the LLA option distinguish different >> outcomes (see Section 7.1). > > If we get Code 3, is there a New Access Point Link-layer Address > option included anyway? What would its contents be, in this case? > Yes. It is only saying that the [AP-ID, AR-Info] tuples are present for only a subset of all the APs included in the RtSolPr. >> Type: To be assigned by IANA >> >> Code: 0 > RtSolPr and PrRtAdv ask for an ICMP Type code > to be assigned. I'm trying to understand why, > given that RFC 4068 uses type code 150 allocated > in RFC 4065 for experimental mobility purposes. > RFC 4065 has a corresponding type code for IPv4, > too (value 41). > You are right. I forgot to update it after writing the IANA section. >> 9. IANA Considerations >> >> All the messages and the option formats specified in this document >> require Type assignment from IANA. Specifically, the Types, Sub- >> types and the Codes need assignment from ICMP, Mobile IP and >> Experimental Mobility Type [rfc4065] registries. > > It took a while for me to parse what this means, and it would be > better if you can write the IANA instructions in a more explicit > manner. In particular, you are asking ICMP Types and Mobile IP > Type allocations, so at least explain what values are allocating > from what registry. Also, this section may be affected by > any changes resulting from my previous comment. The subsequent paragraphs describe what assignments are needed, no? > > Finally, the IANA considerations section is missing all instructions > regarding future allocations from Option-Code and Code fields. > Are these namespaces expected to be independent new spaces, > or go in sync with RFC 4068? > I assumed they would just be in sync with RFC 4068. I can add some text as such. -Rajeev > Jari > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat May 12 17:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyqS-0006sD-0z; Sat, 12 May 2007 17:09:40 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HmyqQ-0006s8-QI for mip4-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 17:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyqQ-0006s0-Gj for mip4@ietf.org; Sat, 12 May 2007 17:09:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmyqP-0000tq-6N for mip4@ietf.org; Sat, 12 May 2007 17:09:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 May 2007 14:09:36 -0700 X-IronPort-AV: i="4.14,526,1170662400"; d="scan'208"; a="148173310:sNHT48746088" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4CL9anA008898; Sat, 12 May 2007 14:09:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4CL9Z20006512; Sat, 12 May 2007 21:09:35 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 14:09:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] RFC3024 on multicasting Date: Sat, 12 May 2007 14:09:36 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5203D9D3B2@xmb-sjc-235.amer.cisco.com> In-Reply-To: <88bc8c7a0705100432s7b187c4bwe587e79b6b1f2b75@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RFC3024 on multicasting Thread-Index: AceS94DvqRg/LnX6RsStppdVsEMMFwAPa1dQ From: "Kent Leung \(kleung\)" To: "Bjorn Andersson" , X-OriginalArrivalTime: 12 May 2007 21:09:35.0818 (UTC) FILETIME=[D820A2A0:01C794D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1354; t=1179004176; x=1179868176; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip4]=20RFC3024=20on=20multicasting |Sender:=20; bh=VukOuU4aoQxawi/Z3zhTKkHGu6yRKlxa6Xi4GqTBW20=; b=DukUcuYrJvxQw7CvAyiaZGseOHHjp+tvNuOg4nfRoB5OjN3Sy6wPpTTOL4G4iMmWVtTfcwUQ hyRpRQs9lW+/S4lGjXr/vQTP9pGtnrf16ipJuK0ShtYKC/w6miHyZjwEoKRP1pV66DQp8pSztL yH5yAb2pEMTswP6ZocfA0xAwk=; Authentication-Results: sj-dkim-1; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Bjorn. Comments below. -----Original Message----- From: Bjorn Andersson [mailto:bjorn@iki.fi]=20 Sent: Thursday, May 10, 2007 4:33 AM To: mip4@ietf.org Subject: [Mip4] RFC3024 on multicasting RFC3024 states: "Mobile nodes that wish to send either broadcast or multicast packets MUST use the Encapsulating Delivery Style." Is this really a MUST? On point-to-point links the encap delvivery style does not seem to give any added value. On the contrary it adds unnecessary overhead. KL> I agree with you that it should not be a MUST from the practical perspective for p2p links. =20 Also, on links such as ethernet couldn't the MN send the packet with the unicast FA link address and multicast/broadcast IP address? Or would this behaviour violate some other specification? I have vague feeling that some spec says that IP multicast/broadcast packets MUST use multicast/broadcast L2 addresses, but I am not sure. Is it so? KL> I'm not so clear why MN needs to use multicast/broadcast IP address of the FA (besides Agent Solicitation)? MN should learn the FA's address via Agent Advertisement and use that address for registration and data packets. If you are asking the other way around (i.e. FA sending to MN with broadcast IP address and unicast L2 address), then there are cases when this happen. Kent =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun May 13 10:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnFEu-0002AY-GJ; Sun, 13 May 2007 10:40:00 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hm7cF-0005tY-Sp for mip4-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 08:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm7cF-0005tL-Ie for mip4@ietf.org; Thu, 10 May 2007 08:19:27 -0400 Received: from hu-out-0506.google.com ([72.14.214.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm7cB-0005Ui-3Z for mip4@ietf.org; Thu, 10 May 2007 08:19:27 -0400 Received: by hu-out-0506.google.com with SMTP id 38so579148huc for ; Thu, 10 May 2007 05:19:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:to:subject:date:organization:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index:from; b=sXBzL0LoKyHSOlNJrV4eqiwa4GJMPQe5iN3KhyUApgNZKY8dW8WSMOlOmzBJzyjPayz3bGtbcsvUUZcYroF774aLMi9qt556UjHgcDJV8grjowdkHSjiP1omCD4HIBBzuTR5/s5p+Vwl0lZoz/CjBs00ZbyBFYoQq9UNTMnxTac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:to:subject:date:organization:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index:from; b=hNvAYVf6RSIQNjyL3gwJ6KxFXrTFnCodWdpB/76kwHvQGWkw6lewmNPJTO7EezzMcOsAxfa9VpJD4xn+3eXOaUvZ0IV19v8TBeQvkB6NThMM0apqMZM1BNoiu0E2rL7ahBGwN0KlOlJT5Th0us/JepLf1QxgNVde5yB4ZF3C4ik= Received: by 10.67.10.12 with SMTP id n12mr2050091ugi.1178799561865; Thu, 10 May 2007 05:19:21 -0700 (PDT) Received: from Melkor ( [195.83.213.102]) by mx.google.com with ESMTP id w40sm4185356ugc.2007.05.10.05.19.19; Thu, 10 May 2007 05:19:21 -0700 (PDT) To: Date: Thu, 10 May 2007 14:19:14 +0200 Organization: IRCICA/LIFL, CNRS UMR 8022, Univ. Lille 1, INRIA Futurs Message-ID: <007b01c792fd$6df01420$66d553c3@lifl.fr> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceS/HxQdYGbY3K5RtKVnUCfCg8FyA== From: david.simplotryl@gmail.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 1b2066b7e944cd0f55ca6d7a2077c2e4 X-Mailman-Approved-At: Sun, 13 May 2007 10:40:00 -0400 Cc: Subject: [Mip4] CFP: SenseID - Convergence of RFID and Wireless Sensor Networks and their Applications, Sydney, Australia, November 6-9, 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David.Simplot@lifl.fr List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1931671176==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1931671176== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C7930E.3178E420" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C7930E.3178E420 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------ We apologize if you received multiple copies of this posting. Please feel free to distribute it to those who might be interested. ------------------------------------------------------------------------ ACM SenSys 2007 The 5th ACM Conference on Embedded Networked Sensor Systems November 6-9, 2007, Sydney, Australia Call for Papers SenseID: Convergence of RFID and Wireless Sensor Networks and their Applications A one day workshop at the ACM SenSys'2007 conference http://www.lifl.fr/POPS/SenseID2007 TOPICS We are witnessing an increasing trend towards integration of RFID and wireless sensor networks technologies. On one hand, new generations of RFID tags, in particular active RFID tags, often include built-in sensing capabilities. On the other hand, applications based on sensor network often require means for unique identification and discovery of individual sensors or objects, which are monitored by the sensor network. A typical scenario, from the agriculture domain, is a herd monitoring, where every animal might be equipped with an RFID tag and at the same time subject of the several sensors measuring vital life and health parameters. Integration of sensor networks to the global database about physical objects introduces a staggering amount of new application opportunities, as well as demanding challenges in security and privacy. Convergence of sensing and identification technologies, together with deployment of a global IT and communication systems, can enable us to gain impressive awareness about the state of the real world. This kind of awareness, including identification of physical objects and their context, can drastically change the way we interact with our environment. Logistics, telemedicine, environmental monitoring, home applications and control, security and surveillance, industrial applications like process industry automation and agricultural applications are examples of potential applications of real-world aware systems. At the same time, possibility of building a global distributed database, capable of delivering information about both the nature and the state of every physical object can lead to an ultimate Big Brother scenario. Therefore, a particular care has to be taken in order to provide appropriate security and privacy control mechanisms. OBJECTIVES OF THE WORKSHOP: The workshop aims to provide a forum for presentation and discussion of the solutions integrating RFID and wireless sensor networks as well as challenges related to their implementation and deployment. We would like to solicit contributions that discuss design and implementations issues related to the heterogeneous systems relying on RFID and sensor network technology. We are particularly interested in discussion of challenges related to: * integration of RFID and wireless sensor networks systems * support for non-functional properties, such as availability, security, reliability and quality of service * acquisition and aggregation of sensor and RFID information * design and implementation challenges in the hybrid RFID/WSN systems * Integrated RFID and WSN as mobile network services? Topics of interest include but are not limited to: * active RFID tags and their applications * convergence of RFID and WSN architectures and protocols * targeted data acquisition from the sensor networks * security and privacy challenges introduced by the WSN and RFID convergence * data gathering, transport, storage, retrieval, mining and dissemination * data analysis and visualisation * experimental systems and demonstrations * middleware implementations * challenges in deployment, maintenance and operation of RFID/WSN systems * new application scenarios and use cases * integration with existing communication systems * reliability and quality of service * integration of information from sensors and RFID into applications * design and implementation challenges in real-world aware systems We expect concise papers presenting various theoretical and practical aspects of the integration of RFID and sensor networks, written from both academic and industrial perspective. Papers must be original, unpublished work not under consideration elsewhere. All submissions will be handled electronically and must be in PDF format. Papers must not exceed 6 pages (US "Letter" size, 8.5 x 11 inches) including all material (text, figures and references). The font size must be at least 10 points. Papers should be in two-column format with no more than 59 lines of text per column and at least 0.75" margins on all sides. All submitted papers will be peer-reviewed. Further instruction regarding the submission process can be found on the workshop web site: http://www.lifl.fr/POPS/SenseID2007 IMPORTANT DATES Paper submission deadline: 20/07/2007 Notification of paper acceptance: 20/08/2007 Camera ready paper copy: 30/08/2007 WORKSHOP CO-Chairs Dr Srdjan Krco, Ericsson Ltd, Ireland Prof. David Simplot-Ryl, INRIA-University of Lille, France Dr Konrad Wrona, SAP Research, France TECHNICAL PROGRAM COMMITTEE See website. ------=_NextPart_000_007C_01C7930E.3178E420 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 

-----------------------------------------------------------------=
-------
We apologize if =
you received multiple copies of this =
posting.
Please feel =
free to distribute it to those who might be =
interested.
-----------------------------------------------------------------=
-------
 
ACM SenSys 2007
The 5th ACM =
Conference on Embedded Networked Sensor =
Systems
November 6-9, =
2007, Sydney, Australia<=
/font>

 

Call for = Papers

 

SenseID:

Convergence of RFID and Wireless Sensor Networks = and their Applications

A one day workshop at the ACM SenSys'2007 conference

http://www.lifl.fr/POPS/Sen= seID2007

 

TOPIC= S

We are witnessing an increasing trend towards integration of RFID = and wireless sensor networks technologies. On one hand, new generations of = RFID tags, in particular active RFID tags, often include built-in sensing capabilities. On the other hand, applications based on sensor network = often require means for unique identification and discovery of individual = sensors or objects, which are monitored by the sensor network. A typical scenario, = from the agriculture domain, is a herd monitoring, where every animal might = be equipped with an RFID tag and at the same time subject of the several = sensors measuring vital life and health parameters. =

Integration of sensor networks to the global database about = physical objects introduces a staggering amount of new application opportunities, = as well as demanding challenges in security and = privacy.

Convergence of sensing and identification technologies, together = with deployment of a global IT and communication systems, can enable us to = gain impressive awareness about the state of the real world. This kind of = awareness, including identification of physical objects and their context, can = drastically change the way we interact with our environment. Logistics, = telemedicine, environmental monitoring, home applications and control, security and surveillance, industrial applications like process industry automation = and agricultural applications are examples of potential applications of = real-world aware systems.

At the same time, possibility of building a global distributed = database, capable of delivering information about both the nature and the state of = every physical object can lead to an ultimate Big Brother scenario. Therefore, = a particular care has to be taken in order to provide appropriate security = and privacy control mechanisms.

 <= /font>

OBJEC= TIVES OF THE WORKSHOP:

The workshop aims to provide a forum for presentation and = discussion of the solutions integrating RFID and wireless sensor networks as well as challenges related to their implementation and deployment. =

We would like to solicit contributions that discuss design and implementations issues related to the heterogeneous systems relying on = RFID and sensor network technology. We are particularly interested in discussion = of challenges related to:

  • integration of RFID and wireless sensor networks = systems
  • support for non-functional properties, such as availability, security, = reliability and quality of service
  • acquisition and aggregation of sensor and RFID = information
  • design and implementation challenges in the hybrid RFID/WSN = systems
  • Integrated RFID and WSN as mobile network = services?

 

Topics of interest include but are not limited to:

·       = active RFID tags and = their applications

·       = convergence of RFID and = WSN architectures and protocols

·       = targeted data acquisition = from the sensor networks

·       = security and privacy = challenges introduced by the WSN and RFID convergence

·       = data gathering, = transport, storage, retrieval, mining and dissemination

·       = data analysis and = visualisation

·       = experimental systems and demonstrations

·       = middleware = implementations

·       = challenges in deployment, maintenance and operation of RFID/WSN systems

·       = new application scenarios = and use cases

·       = integration with existing communication systems

·       = reliability and quality = of service

·       = integration of = information from sensors and RFID into applications

·       = design and implementation = challenges in real-world aware systems

 

We expect concise papers presenting various theoretical and practical aspects of the integration of RFID and = sensor networks, written from both academic and industrial perspective. = Papers must be = original, unpublished work not under consideration elsewhere. All submissions will = be handled electronically and must be in PDF format. Papers must not exceed = 6 pages (US "Letter" size, 8.5 x 11 inches) including all material = (text, figures and references). The font size must be at least 10 points. = Papers should be in two-column format with no more than 59 lines of text per = column and at least 0.75" margins on all sides. All submitted papers will = be peer-reviewed. Further instruction regarding the submission process can = be found on the workshop web site: http://www.lifl.fr/POPS/Sen= seID2007

 

IMPORTANT = DATES

Paper submission deadline: = 20/07/2007

Notification of paper acceptance: = 20/08/2007

Camera ready paper copy: = 30/08/2007

 

WORKS= HOP CO-Chairs

Dr Srdjan Krco, = Ericsson Ltd, Ireland

Prof. David = Simplot-Ryl, INRIA-University of Lille, France

Dr Konrad Wrona, SAP Research, France

 

TECHN= ICAL PROGRAM COMMITTEE

See website.

------=_NextPart_000_007C_01C7930E.3178E420-- --===============1931671176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1931671176==-- From mip4-bounces@ietf.org Sun May 13 10:44:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnFJ0-0004q8-8E; Sun, 13 May 2007 10:44:14 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hllm4-00063H-6r for mip4-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:00:08 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hllm3-000633-9Y for mip4@ietf.org; Wed, 09 May 2007 09:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HllVp-0004bt-2T; Wed, 09 May 2007 08:43:21 -0400 Received: from mail1.univ-avignon.fr ([195.83.163.50] helo=mail01c.univ-avignon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HllVn-0006NA-Jh; Wed, 09 May 2007 08:43:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01c.univ-avignon.fr (Postfix) with ESMTP id C92BA4E413D; Wed, 9 May 2007 14:43:16 +0200 (CEST) Received: from mail01c.univ-avignon.fr ([127.0.0.1]) by localhost (mail01c [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07372-02; Wed, 9 May 2007 14:43:13 +0200 (CEST) Received: from let3-taji1.iup.univ-avignon.fr (let3-taji1.iup.univ-avignon.fr [194.57.216.165]) by mail01c.univ-avignon.fr (Postfix) with ESMTP id 5F8554E4134; Wed, 9 May 2007 14:43:11 +0200 (CEST) From: Tania Jimenez To: sigmetrics-bb@merlot.usc.edu, petrinet@informatik.uni-hamburg.de, tci-announce@computer.org, tcgn@ieee.org, reres@laas.fr Content-Type: text/plain; charset=utf-8 Date: Wed, 09 May 2007 14:43:31 +0200 Message-Id: <1178714612.5124.370.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new at smtp.univ-avignon.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-TMDA-Confirmed: Wed, 09 May 2007 09:00:07 -0400 X-Mailman-Approved-At: Sun, 13 May 2007 10:44:13 -0400 Cc: koole@few.vu.nl, MOBICOM@acm.org, Naceur.Malouch@lip6.fr, rafael@ula.ve, uriy@post.tau.ac.il, lrleon@ula.ve, cesimo@ula.ve, Serge.Fdida@lip6.fr, aguilar , reinaldom@gmail.com, lia@univ-avignon.fr Subject: [Mip4] Net-coop 2007: Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org NET-COOP=E2=80=992007 International Conference on Network Control and Optimization 1st Edition June 5-7, 2007, Avignon, France http://www.lia.univ=C2=AD-avignon.fr/html/netcoop2007/ Important Dates: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Early registration: May 17th, 2007 Workshop date: June 5-7, 2007 We cordially invite you to attend the NET=C2=ADCOOP 2007 workshop to be h= eld in the Provence city of Avignon, which will bring together researchers from academia and industry. This workshop aims at developing research on control and optimization of the Internet, ranging from performance evaluation and optimization of general stochastic networks to more=20 specific targets such as lower=C2=ADlayer functionalities in mobile netwo= rks, routing for computational grids, game theoretic approaches to access control, cooperation, competition and adversary capacities in diverse environments.=20 Highlights: =20 A strong mostly single=C2=ADtrack technical program, held in the beautifu= l historical place of Ste. Marthe Avignon University (over 700 years old). The technical program consists of 31 refereed papers and includes three plenary talks by Thomas Bonald (FT R&D, France), Ravi Mazumdar (Univ. of Waterloo, Canada) and Moshe Haviv (Hebrew Univ. of Jerusalem, Israel).=20 Technical Program is available online. The conference proceedings will be published both in hard=C2=ADcopy and electronically by Springer Verlag, Heidelberg, Germany, in the Lecture Notes in Computer Science (LNCS) Series.=20 A best student paper award will be granted. Full details are on the conference Web site. Some funds are available for finantial support for participants by up to 500 euros/participant. Priority will be given to students. Those interested should contact Ephie Deriche: Ephie.Deriche@sophia.inria.fr Contact : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tijani Chahed (tijani.chahed@int-evry.fr) Bruno Tuffin (btuffin@irisa.fr) Co-sponsored by : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IEEE Control Systems Society (pending) IFIP TC-6 and TC-7 (pending) General Chair =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jorma Virtamo, HUT Program Co-Chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tijani Chahed, GET/INT Bruno Tuffin, INRIA Program Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ivo Adan, UTE K. Avratchenkov, INRIA Tamer Basar, U. Illinois Vivek Borkar, TIFR Onno Boxma, UTE Antonio Capone, Politecnico di Milano Rajarathnam Chandramouli, Stevens Institute of Tech. Costas Courcoubetis, Athens U. Econ. Business Serguei Foss, Heriot-Watt Brigitte Jaumard, Concordia Hisao Kameda, U. Tsukuba Peter Key, Microsoft Res. Arzad Kherani, IIT Anurag Kumar, IISC Harold J. Kushner, Brown Steven Low, CIT John Lui , The Chinese University of Hong Kong Patrick Maill=C3=A9, GET Michel Mandjes, CWI Peter Marbach, U. Toronto Ravi Mazumdar, University of Waterloo Boris Miller, IITP Isi Mitrani, U. Newcastle Jose Nino-Mora, U. Juan Carlos III de Madrid Fernando Paganini, U. ORT Guy Pujolle, U. Paris 6 R. N=C3=BA=C3=B1ez Queija, CWI Zari Rachev, UCSB Jacques Resing, EUT Ulrich Rieder, U. Ulm David Ros, GET/ENST-Br Sanjay Shakkottai, U. of Texas at Austin George Stamoulis, Athens U. of Econ. and Business Nicolas Stier, Columbia U. Pascale Vicat-Blanc, ENS-Lyon Jorma Virtamo, HUT Organizing committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Eitan Altman, INRIA Ephie Deriche, INRIA Monique Simonetti, INRIA Rachid Elazouzi, U. Avignon Yezekael Hayel, U. Avignon Tania Jimenez, U. Avignon -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 14 03:10: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 1HnUhK-0005UI-2k; Mon, 14 May 2007 03:10:22 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HnUhI-0005S6-Sn for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 03:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUhF-00057Z-4R for mip4@ietf.org; Mon, 14 May 2007 03:10:17 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnUhD-0005uZ-QL for mip4@ietf.org; Mon, 14 May 2007 03:10:17 -0400 Received: by ik-out-1112.google.com with SMTP id c29so983405ika for ; Mon, 14 May 2007 00:10:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=B1fcayrwht+rtbDGB3a5yywbWE6c1fDNfWCaM4mchbPPw0hWK3P6z61SSz1hkkGmwe4Kn8QsJhxWWTUt2ffAOlE8SQaZ6fot3biALh68w8sOjFcIdMFgEhbTdNfKtEpl/ummnt7rZurcgyYJrvp7ddBekZNSCeNTl336+HegsQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ML+3O6iFeU0FOJfclPtH2gx2PgWGHTbyvX46pHz1MwhwsCKs17FGF3aDy/78dCy/DVKdhjVvaA7mzxQL1pq1mlgWUI+w0ikfRHUIO96BNlzFDllPxbVl8IP6yfSPLKqb9V5QCvdTvykTpqTgZrKuq9WsX2YPJDSq5QIJ9kWRtu8= Received: by 10.64.24.20 with SMTP id 20mr3526575qbx.1179126614348; Mon, 14 May 2007 00:10:14 -0700 (PDT) Received: by 10.65.252.12 with HTTP; Mon, 14 May 2007 00:10:14 -0700 (PDT) Message-ID: <88bc8c7a0705140010l43de99cbq4c328c31a4e51349@mail.gmail.com> Date: Mon, 14 May 2007 10:10:14 +0300 From: "Bjorn Andersson" To: mip4@ietf.org Subject: Re: [Mip4] RFC3024 on multicasting In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5203D9D3B2@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88bc8c7a0705100432s7b187c4bwe587e79b6b1f2b75@mail.gmail.com> <2979E38DD6FC6544B789C8DAD7BAFC5203D9D3B2@xmb-sjc-235.amer.cisco.com> X-Google-Sender-Auth: 85494f6cfe6bc694 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Kent Leung \(kleung\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Should we write an updated reverse tunneling RFC were the encap delivery for multicast MUST is removed? At least I think there will be consensus for p2p links. What about other links? Bjorn Andersson: > Also, on links such as ethernet couldn't the MN send the packet with the > unicast FA link address and multicast/broadcast IP address? Or would > this behaviour violate some other specification? I have vague feeling > that some spec says that IP multicast/broadcast packets MUST use > multicast/broadcast L2 addresses, but I am not sure. Is it so? Kent Leung: > I'm not so clear why MN needs to use multicast/broadcast IP address > of the FA (besides Agent Solicitation)? MN should learn the FA's > address via Agent Advertisement and use that address for registration > and data packets. If you are asking the other way around (i.e. FA > sending to MN with broadcast IP address and unicast L2 address), then > there are cases when this happen. I meant that if the MN wants to send a multicast/broadcast packet to (or via) the home network. The FA could tunnel all broadcast/multicast to the home network except agent solicitations. Or maybe that's the reason why encap delivery MUST always be used, so that the FA can differentiate between multicast packets that are destined for the home network and the one for the local network? On the other hand the FA could do this differentiation by looking at the L2 address: if it is the FA L2 address tunnel the packet to the home network, else do nothing. Perhaps there are some problems with this that I am not aware of or come to think of? Bjorn -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 14 06:31: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 1HnXqG-00061M-3M; Mon, 14 May 2007 06:31:48 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HnXqE-00061G-9y for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 06:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXqD-000618-Vi for mip4@ietf.org; Mon, 14 May 2007 06:31:45 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnXqC-0002Ed-NX for mip4@ietf.org; Mon, 14 May 2007 06:31:45 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CBE01986A1; Mon, 14 May 2007 13:31:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 38EE3198675; Mon, 14 May 2007 13:31:43 +0300 (EEST) Message-ID: <46483A8F.9040201@piuha.net> Date: Mon, 14 May 2007 13:31:43 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] Request to advance draft-ietf-mip4-gen-ext-03.txt to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I have made my AD review on this document, and it revealed no issues. However, as Pete indicated in his e-mail this draft needs review from the DHCP experts and we are talking with them in order to find out how to best arrange that. Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 14 08:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZUC-0002ht-Is; Mon, 14 May 2007 08:17:08 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HnZUB-0002ho-PV for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 08:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZUB-0002hg-Fo for mip4@ietf.org; Mon, 14 May 2007 08:17:07 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZU9-0003gG-S4 for mip4@ietf.org; Mon, 14 May 2007 08:17:07 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 73F141986A3; Mon, 14 May 2007 15:17:04 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ED7F21986A2; Mon, 14 May 2007 15:17:03 +0300 (EEST) Message-ID: <46485340.60403@piuha.net> Date: Mon, 14 May 2007 15:17:04 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: draft-ietf-mip4-fmipv4@tools.ietf.org, Mobile IPv4 Mailing List , McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev, > It's the LLA. Wildcard only says provide information about all possible > neighborhood access points. > > PrRtAdv contains the [AP-ID, AR-Info] tuple, which is what you see as Valid > options in Section 6.4. Multiple such tuples may be present as a result of > multiples LLAs present or a wildcard request in RtSolPr. > > So, the copy statement is applicable to LLAs present in RtSolPr. When the > wildcard is present, PAR includes the LLA on its own. If it would help, I > can add a sentence to make it clear. > Please change the text -- if you actually provide the link layer addresses for all access points, then you are not copying the LLA option from request to advertisement; you are replacing the wildcard LLA with a number of specific LLAs, right? >>> New CoA Option: MAY be present when PrRtAdv is sent >>> unsolicited. PAR MAY compute new CoA using NAR's prefix >>> information and the MN's L2 address, or by any other means. In >>> any case, the MN should be prepared to use this address instead >>> of performing DHCP or similar operations to obtain an IPv4 >>> address. >>> >> First, why would this be present only in an unsolicited message? >> > > In RFC 4068, the unsolicited mode means a network-initiated handover, in > which case the MN needs an NCoA, which is supplied in PrRtAdv. We have > re-used it here, even though we do not bind the PCoA to NCoA (but to the new > FA's address). > Ok, but are you saying that if the mobile node initiates the handover, then the PAR can not provide an NCoA? That is, what is the keyword that you would use for solicited messages? MAY as well? Or maybe MUST NOT, if you disallow this? > Even with New CoA, the binding is always for the new FA's address. I will > add this requirement again in Section 6.4. > Good. > >> In Section 6.4 you say: >> >> >>> New Access Point Link-layer Address: The link-layer address or >>> identification of the access point is copied from RtSolPr >>> message. This option MUST be present. >>> >>> ... >>> >>> A Proxy Router Advertisement with Code 3 means that new router >>> information is only present for a subset of access points requested. >>> The Option-Code values in the LLA option distinguish different >>> outcomes (see Section 7.1). >>> >> If we get Code 3, is there a New Access Point Link-layer Address >> option included anyway? What would its contents be, in this case? >> >> > > Yes. It is only saying that the [AP-ID, AR-Info] tuples are present for only > a subset of all the APs included in the RtSolPr. > That's fine, but then it also means that the MUST that appeared earlier about the copying of LLAs from request to advertisement cannot be fulfilled. You need to adjust the MUST statement to say what you actually need to be done. Currently it makes an overall statement that does not appear to be the desired behaviour in a number of special cases (wildcard, code 3). >>> Type: To be assigned by IANA >>> >>> Code: 0 >>> >> RtSolPr and PrRtAdv ask for an ICMP Type code >> to be assigned. I'm trying to understand why, >> given that RFC 4068 uses type code 150 allocated >> in RFC 4065 for experimental mobility purposes. >> RFC 4065 has a corresponding type code for IPv4, >> too (value 41). >> >> > > You are right. I forgot to update it after writing the IANA section. > Ok, please update this. > >>> 9. IANA Considerations >>> >>> All the messages and the option formats specified in this document >>> require Type assignment from IANA. Specifically, the Types, Sub- >>> types and the Codes need assignment from ICMP, Mobile IP and >>> Experimental Mobility Type [rfc4065] registries. >>> >> It took a while for me to parse what this means, and it would be >> better if you can write the IANA instructions in a more explicit >> manner. In particular, you are asking ICMP Types and Mobile IP >> Type allocations, so at least explain what values are allocating >> from what registry. Also, this section may be affected by >> any changes resulting from my previous comment. >> > > The subsequent paragraphs describe what assignments are needed, no? > Ah, yes. I must have been looking at the old revision. >> Finally, the IANA considerations section is missing all instructions >> regarding future allocations from Option-Code and Code fields. >> Are these namespaces expected to be independent new spaces, >> or go in sync with RFC 4068? >> >> > > I assumed they would just be in sync with RFC 4068. I can add some text as > such. > Great! Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 14 16:26: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 1Hnh83-0000Qi-PH; Mon, 14 May 2007 16:26:47 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hnh82-0000PP-O9 for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 16:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngfJ-0008H6-MV for mip4@ietf.org; Mon, 14 May 2007 15:57:06 -0400 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 1HngfI-0002w3-3w for mip4@ietf.org; Mon, 14 May 2007 15:57:04 -0400 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 l4EJun9K002430; Mon, 14 May 2007 22:57:02 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 22:57:01 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 14:56:57 -0500 Received: from 10.241.32.16 ([10.241.32.16]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 May 2007 19:56:57 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 14 May 2007 12:56:58 -0700 Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt From: Rajeev Koodli To: ext Jari Arkko Message-ID: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt Thread-Index: AceWYgd9ReBsugJVEdyydwAWy5YJpw== In-Reply-To: <46485340.60403@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 May 2007 19:56:57.0626 (UTC) FILETIME=[0744CFA0:01C79662] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: draft-ietf-mip4-fmipv4@tools.ietf.org, Mobile IPv4 Mailing List , McCann Peter-A001034 , Rajeev Koodli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 5/14/07 5:17 AM, "ext Jari Arkko" wrote: > > Please change the text -- if you actually provide the link > layer addresses for all access points, then you are not > copying the LLA option from request to advertisement; > you are replacing the wildcard LLA with a number of > specific LLAs, right? > Yes. > > Ok, but are you saying that if the mobile node initiates > the handover, then the PAR can not provide an NCoA? > That is, what is the keyword that you would use for > solicited messages? MAY as well? Or maybe MUST NOT, > if you disallow this? > The specification does not disallow it (i.e., no MUST NOT), nor does it specify it. Traditionally, the NCoA option has only been used with unsolicited PrRtAdv (as a network-initiated handover). In principle, there is no reason not to use the option in solicited PrRtAdv as well. However, unlike the unsolicited scenario, the solicited PrRtAdv message is not tightly synchronized with the actual handover itself (i.e., neighborhood discovery [proxy router messages] and fast route update [fbu/fback] are logically independent phases). Also, providing NCoA when multiple LLAs are present in RtSolPr introduces ambiguity since the MN cannot determine on which AP it could use the supplied NCoA. So, perhaps we should state that use of NCoA in solicited PrRtAdv is unspecified in this version of the document, and some text reflecting the above description? > > That's fine, but then it also means that the MUST that appeared > earlier about the copying of LLAs from request to advertisement > cannot be fulfilled. You need to adjust the MUST statement > to say what you actually need to be done. Currently it makes > an overall statement that does not appear to be the desired > behaviour in a number of special cases (wildcard, code 3). > Ok. -Rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 14 18:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnjOc-00065J-8z; Mon, 14 May 2007 18:52:02 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HnjOa-000653-MN for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 18:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnjOa-00064v-CY for mip4@ietf.org; Mon, 14 May 2007 18:52:00 -0400 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 1HnjOY-0002nP-Ue for mip4@ietf.org; Mon, 14 May 2007 18:52:00 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4EMpuOg010676; Tue, 15 May 2007 01:51:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 01:51:55 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 17:51:53 -0500 Received: from 10.241.32.16 ([10.241.32.16]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 May 2007 22:51:53 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 14 May 2007 15:51:53 -0700 Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt From: Rajeev Koodli To: ext Jari Arkko Message-ID: Thread-Topic: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt Thread-Index: AceWYgd9ReBsugJVEdyydwAWy5YJpwAGG+DW In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 May 2007 22:51:53.0249 (UTC) FILETIME=[7725C910:01C7967A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: draft-ietf-mip4-fmipv4@tools.ietf.org, Mobile IPv4 Mailing List , McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > > In principle, there is no reason not to use the option in solicited PrRtAdv as > well. However, unlike the unsolicited scenario, the solicited PrRtAdv message > is not tightly synchronized with the actual handover itself (i.e., > neighborhood discovery [proxy router messages] and fast route update > [fbu/fback] are logically independent phases). Also, providing NCoA when > multiple LLAs are present in RtSolPr introduces ambiguity since the MN cannot > determine on which AP it could use the supplied NCoA. Actually, this last point _can_ be clarified because the new CoA option is part of an ordered tuple (section 6.4). Hence, if there are multiple LLAs present, each may have its own (or the same) new CoA option or none at all.. -Rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 15 01:08: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 1HnpHE-0007fb-Tz; Tue, 15 May 2007 01:08:48 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HnpHC-0007fV-Uc for mip4-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 01:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnpHC-0007fN-9c for mip4@ietf.org; Tue, 15 May 2007 01:08:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnpHA-0005IP-Ut for mip4@ietf.org; Tue, 15 May 2007 01:08:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B438C1986A5; Tue, 15 May 2007 08:08:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 62D91198675; Tue, 15 May 2007 08:08:43 +0300 (EEST) Message-ID: <4649405C.1070803@piuha.net> Date: Tue, 15 May 2007 08:08:44 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip4] Re: AD review of draft-ietf-mip4-fmipv4-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: McCann Peter-A001034 , Mobile IPv4 Mailing List , draft-ietf-mip4-fmipv4@tools.ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev, > So, perhaps we should state that use of NCoA in solicited PrRtAdv is > unspecified in this version of the document, and some text reflecting the > above description? > That would work for me. Jari > > >> That's fine, but then it also means that the MUST that appeared >> earlier about the copying of LLAs from request to advertisement >> cannot be fulfilled. You need to adjust the MUST statement >> to say what you actually need to be done. Currently it makes >> an overall statement that does not appear to be the desired >> behaviour in a number of special cases (wildcard, code 3). >> >> > > Ok. > > -Rajeev > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 15 14:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1Lz-0005Hc-LJ; Tue, 15 May 2007 14:02:31 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Ho1Ly-0005HX-Db for mip4-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1Ly-0005HP-3j for mip4@ietf.org; Tue, 15 May 2007 14:02:30 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ho1Lw-0004Wj-NF for mip4@ietf.org; Tue, 15 May 2007 14:02:30 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1179252146!9860987!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11426 invoked from network); 15 May 2007 18:02:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 15 May 2007 18:02:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4FI2P4m010940 for ; Tue, 15 May 2007 11:02:26 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l4FI2PB5002839 for ; Tue, 15 May 2007 13:02:25 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4FI2O4m002821 for ; Tue, 15 May 2007 13:02:24 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Working Group Last Call for draft-ietf-mip4-radius-requirements-02.txt Date: Tue, 15 May 2007 14:02:23 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Call for draft-ietf-mip4-radius-requirements-02.txt thread-index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQKJwZyw References: From: "McCann Peter-A001034" To: , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Reminder: this WGLC ends tomorrow, Wednesday the 16th. Please respond with your comments. So far we only have one response. If we do not see more support for the draft it will not be advanced. -Pete McCann Peter-A001034 wrote: > This message announces a 2 week working group last call > on: >=20 > "Mobile IPv4 RADIUS Requirements" > draft-ietf-mip4-radius-requirements-02.txt. >=20 > The last call will end at 24:00 UTC on Wednesday, May 16th. >=20 > "Mobile IPv4 RADIUS Requirements" lists a set of goals and > assumptions to lay the groundwork for future RADIUS extensions in > support of Mobile IPv4. =20 >=20 > A URL for this internet draft is: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 02.txt >=20 > Please respond to this working group last call: >=20 > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like >=20 > "I support the advancement of this document to the IESG with a > request for publication as an Informational RFC." >=20 > If you have comments, please use a line similar to the one above, > and supplement this with your comments. >=20 >=20 > * If you *don't* support its advancement, respond with a line > containing something like the following, supplemented by your > comments - >=20 > "I don't support the advancement of this document to the IESG with > a request for publication as an Informational RFC, for the > following reasons:" > ... >=20 > Please direct all replies to the Mobile IPv4 mailing list, > mip4@ietf.org.=20 >=20 > -Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue May 15 14:13:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1Wy-0002jY-4F; Tue, 15 May 2007 14:13:52 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Ho1Wx-0002jN-0g for mip4-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 14:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho1Ww-0002jF-NK for mip4@ietf.org; Tue, 15 May 2007 14:13:50 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho1Wv-0001WH-EH for mip4@ietf.org; Tue, 15 May 2007 14:13:50 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI30085OHB0M1@usaga01-in.huawei.com> for mip4@ietf.org; Tue, 15 May 2007 11:13:48 -0700 (PDT) Received: from YingzheWu ([10.192.25.73]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI300850HAUJ9@usaga01-in.huawei.com> for mip4@ietf.org; Tue, 15 May 2007 11:13:48 -0700 (PDT) Date: Tue, 15 May 2007 11:13:40 -0700 From: Yingzhe Wu Subject: RE: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt In-reply-to: To: 'McCann Peter-A001034' , mip4@ietf.org, radiusext@ops.ietf.org Message-id: <001a01c7971c$c49d4c70$4919c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQKIBS6Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Henrik Levkowetz' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org It would be great if MIP4 attributes could be standardized. That will benefit many SDOs. I support the advancement of this document to the IESG with a request for publication as an Informational RFC. Thanks, Yingzhe -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: Wednesday, May 02, 2007 12:56 PM To: mip4@ietf.org; radiusext@ops.ietf.org Cc: Henrik Levkowetz Subject: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt This message announces a 2 week working group last call on: "Mobile IPv4 RADIUS Requirements" draft-ietf-mip4-radius-requirements-02.txt. The last call will end at 24:00 UTC on Wednesday, May 16th. "Mobile IPv4 RADIUS Requirements" lists a set of goals and assumptions to lay the groundwork for future RADIUS extensions in support of Mobile IPv4. A URL for this internet draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 02.txt Please respond to this working group last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments - "I don't support the advancement of this document to the IESG with a request for publication as an Informational RFC, for the following reasons:" ... Please direct all replies to the Mobile IPv4 mailing list, mip4@ietf.org. -Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 16 03:40: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 1HoE7q-0000RM-AJ; Wed, 16 May 2007 03:40:46 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HoE7p-0000RD-3N for mip4-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 03:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE7k-0000Hi-Ty for mip4@ietf.org; Wed, 16 May 2007 03:40:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoE7j-0008St-G0 for mip4@ietf.org; Wed, 16 May 2007 03:40:40 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4G7ebPl018026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2007 00:40:37 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4G7eZLQ028641; Wed, 16 May 2007 00:40:36 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 00:40:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Date: Wed, 16 May 2007 00:40:33 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A2A7@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Thread-Index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQKJwZywAByfGeA= References: From: "Tsirtsis, George" To: "McCann Peter-A001034" , , X-OriginalArrivalTime: 16 May 2007 07:40:36.0388 (UTC) FILETIME=[7E066640:01C7978D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Tuesday, May 15, 2007 7:02 PM To: mip4@ietf.org; radiusext@ops.ietf.org Cc: Henrik Levkowetz Subject: RE: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Reminder: this WGLC ends tomorrow, Wednesday the 16th. Please respond with your comments. So far we only have one response. If we do not see more support for the draft it will not be advanced. -Pete McCann Peter-A001034 wrote: > This message announces a 2 week working group last call > on: >=20 > "Mobile IPv4 RADIUS Requirements" > draft-ietf-mip4-radius-requirements-02.txt. >=20 > The last call will end at 24:00 UTC on Wednesday, May 16th. >=20 > "Mobile IPv4 RADIUS Requirements" lists a set of goals and > assumptions to lay the groundwork for future RADIUS extensions in > support of Mobile IPv4. =20 >=20 > A URL for this internet draft is: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 02.txt >=20 > Please respond to this working group last call: >=20 > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like >=20 > "I support the advancement of this document to the IESG with a > request for publication as an Informational RFC." >=20 > If you have comments, please use a line similar to the one above, > and supplement this with your comments. >=20 >=20 > * If you *don't* support its advancement, respond with a line > containing something like the following, supplemented by your > comments - >=20 > "I don't support the advancement of this document to the IESG with > a request for publication as an Informational RFC, for the > following reasons:" > ... >=20 > Please direct all replies to the Mobile IPv4 mailing list, > mip4@ietf.org.=20 >=20 > -Pete & Henrik --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 16 06:03: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 1HoGLd-0001xe-Jq; Wed, 16 May 2007 06:03:09 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HoGLa-0001xY-Fj for mip4-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 06:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoGLa-0001xQ-2P for mip4@ietf.org; Wed, 16 May 2007 06:03:06 -0400 Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoGLY-0007UN-7q for mip4@ietf.org; Wed, 16 May 2007 06:03:06 -0400 Received: from [127.0.0.1] (c53.local.ipunplugged.com [192.168.4.253]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id l4GA2v16030701 for ; Wed, 16 May 2007 12:03:02 +0200 Message-ID: <464AD6D2.6010200@ipunplugged.com> Date: Wed, 16 May 2007 12:02:58 +0200 From: Hans Sjostrand User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mobile IPv4 Mailing List Subject: Re: [Mip4] Working Group Last Call for draft-ietf-mip4-radius-requirements-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org "I support the advancement of this document to the IESG with a request for publication as an Informational RFC." Regards /// Hasse On 2007-05-15 20:02, McCann Peter-A001034 wrote: > Reminder: this WGLC ends tomorrow, Wednesday the 16th. > Please respond with your comments. So far we only have > one response. If we do not see more support for the > draft it will not be advanced. > > -Pete > > McCann Peter-A001034 wrote: > >> This message announces a 2 week working group last call >> on: >> >> "Mobile IPv4 RADIUS Requirements" >> draft-ietf-mip4-radius-requirements-02.txt. >> >> The last call will end at 24:00 UTC on Wednesday, May 16th. >> >> "Mobile IPv4 RADIUS Requirements" lists a set of goals and >> assumptions to lay the groundwork for future RADIUS extensions in >> support of Mobile IPv4. >> >> A URL for this internet draft is: >> >> >> > http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- > 02.txt > >> Please respond to this working group last call: >> >> * If you have no comments on the draft, and support its advancement, >> simply respond with a line containing something like >> >> "I support the advancement of this document to the IESG with a >> request for publication as an Informational RFC." >> >> If you have comments, please use a line similar to the one above, >> and supplement this with your comments. >> >> >> * If you *don't* support its advancement, respond with a line >> containing something like the following, supplemented by your >> comments - >> >> "I don't support the advancement of this document to the IESG with >> a request for publication as an Informational RFC, for the >> following reasons:" >> ... >> >> Please direct all replies to the Mobile IPv4 mailing list, >> mip4@ietf.org. >> >> -Pete & Henrik >> > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 17 00:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoXj0-0007Aa-Sp; Thu, 17 May 2007 00:36:26 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HoXj0-000753-6T for mip4-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 00:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoXiy-00072r-Pk for mip4@ietf.org; Thu, 17 May 2007 00:36:25 -0400 Received: from mail.ece.gatech.edu ([143.215.151.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoXiv-0005iW-Cu for mip4@ietf.org; Thu, 17 May 2007 00:36:24 -0400 Received: from gc556bwnlap07 (c-24-131-45-131.hsd1.ga.comcast.net [24.131.45.131]) (authenticated bits=0) by mail.ece.gatech.edu (8.14.0/8.13.7) with ESMTP id l4H4YxSQ015071 for ; Thu, 17 May 2007 00:35:00 -0400 (EDT) From: "Dario Pompili" To: Date: Thu, 17 May 2007 00:36:15 -0400 Message-ID: <007f01c7983c$eb019e40$05000100@ece.gatech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceRyEA2Tdi7dmaWSKaEjQcFLRKwoQGc9IygAAAms1AAAAx68A== X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.16.212433 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_PBL_10 2.5, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, RELAY_IN_PBL 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_BROADBAND_4 0, __RDNS_POOLED_10 0, __SANE_MSGID 0, __USER_AGENT_MS_GENERIC 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [Mip4] CFP: The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) - Submission deadline (EXTENDED): May18, 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [We apologize in advance if you receive multiple copies of this CFP] __________________________________________________________________________ __________________________________________________________________________ The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) http://wuwnet07.engr.uconn.edu/ In conjunction with ACM MobiCom 2007 September 14, 2007 Montreal, Quebec, Canada Sponsored by ACM SIGMOBILE __________________________________________________________________________ __________________________________________________________________________ Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are critical in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication and the complexity of diverse aquatic environments require us to completely re-think how a network should be deployed in underwater environments. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multi-path propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that nodes can passively move due to water currents and dispersion. All the above distinct features of underwater networks yield grand challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practitioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, keynote speeches, a panel session and a poster/demo session. Submissions for technical papers should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Data storage and management - Power and resource management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Network planning and deployment - New techniques for aquatic applications - New applications for underwater networks - Testbed and systems: real-world experiences and lessons Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for full papers (4 pages for short papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. All accepted papers will appear in the workshop proceedings. Detailed instructions for paper submission will be posted on the workshop website. Important Dates *************** Submission deadline (EXTENDED): May 18, 2007 Acceptance notification: June 16, 2007 Camera-ready version due: June 30, 2007 Workshop date: September 14, 2007 Organizing Committee ******************** General Co-Chairs: Ian F. Akyildiz (Georgia Institute of Technology) David Hung-Chang Du (University of Minnesota/NSF) Technical Program Co-Chairs: Robert H. Headrick (Office of Naval Research) Michele Zorzi (University of Padova, Italy) WUWNet Steering Committee: Ian F. Akyildiz (Georgia Institute of Technology) Jun-Hong Cui (University of Connecticut, Chair) David Hung-Chang Du (University of Minnesota/NSF) Kevin Fall (Intel Research, Berkeley) John Heidemann (University of Southern California/ISI) Urbashi Mitra (University of Southern California) Milica Stojanovic (Massachusetts Institute of Technology) Publicity Co-Chairs: Qilian Liang (University of Texas at Arlington) Dario Pompili (Georgia Institute of Technology) Work-In-Progress Poster Co-Chairs: Volkan Rodoplu (University of California at Santa Barbara) Wei Ye (University of Southern California/ISI) Demo Co-Chairs: Payman Arabshahi (University of Washington) Geoffrey Xie (Naval Postgrad School) Finance Chair: Shengli Zhou (University of Connecticut) Technical Program Committee (incomplete) **************************************** Jun-Hong Cui (University of Connecticut) Kevin Fall (Intel Research, Berkeley) Joo Pedro Gomes (Instituto Superior Tecnico, Portugal) Al Harris (University of Illinois at Urbana-Champaign) Brian Levine (University of Massachusetts) Urbashi Mitra (University of Southern California) James Preisig (Woods Hole Oceanographic Institution (WHOI)) Robert Qiu (Tennessee Technological University) Volkan Rodoplu (University of California, Santa Barbara) Sumit Roy (University of Washington) Winston Seah (Institute for Infocomm Research, Singapore) Milica Stojanovic (Massachusetts Institute of Technology) Yang Xiao (University of Alabama) Wei Ye (University of Southern California/ISI) ********************************************* Dario Pompili, Ph.D. Broadband & Wireless Networking Laboratory School of Electrical & Computer Engineering Georgia Institute of Technology, Atlanta, GA Email: dario@ece.gatech.edu http://users.ece.gatech.edu/dario/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 17 10:48:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HohH5-0006Kd-F0; Thu, 17 May 2007 10:48:15 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HohH4-0006Hn-7o for mip4-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 10:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HohH3-0006Hf-UF for mip4@ietf.org; Thu, 17 May 2007 10:48:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HohH2-0006Lz-JR for mip4@ietf.org; Thu, 17 May 2007 10:48:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4HElqQ27847; Thu, 17 May 2007 14:47:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Thu, 17 May 2007 09:47:48 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3A= References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> From: "Ahmad Muhanna" To: "Tsirtsis, George" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, I am not sure how did you categorize the proposed functionality in this draft as a slightly different use from the functionality proposed by draft-yegani-gre-key-extension-02 draft. In my understanding all IP mobility protocol is used to establish L-3 mobility via allowing the Mobile Node to be able to use its IP address (Home) regardless of the point of attachment. However, it seems to me that what you are trying to propose here is to use PMIPv4, which is a network based IP mobility protocol, to establish a layer-2 tunnel, I may say a L-2 mobility, by violating the very basic principle of IP mobility. Are you suggesting here a new protocol using messages that already defined in IP Mobility v4 space? Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Tuesday, May 08, 2007 3:38 AM > To: mip4@ietf.org > Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi everyone, >=20 > The following draft extends=20 > draft-yegani-gre-key-extension-02.txt for a slightly=20 > different use of GRE-keys in PMIPv4.=20 >=20 > Let me know if you have any comments. >=20 > Best Regards > George=20 >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, May 07, 2007 11:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : GRE-based L2 Tunneling with PMIPv4 > Author(s) : G. Tsirtsis, V. Park > Filename : draft-tsirtsis-l2gre-pmipv4-00.txt > Pages : 15 > Date : 2007-5-7 > =09 > This specification introduces mechanisms for creating a=20 > GRE-based L2 > Tunnel with PMIPv4. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-tsirtsis-l2gre-pmipv4-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt". > =09 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 17 17:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonhI-0007vM-JN; Thu, 17 May 2007 17:39:44 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HonhH-0007vE-4n for mip4-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 17:39:43 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HonhG-0007v4-RZ for mip4@ietf.org; Thu, 17 May 2007 17:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hokfq-0004J4-00 for mip4@ietf.org; Thu, 17 May 2007 14:26:02 -0400 Received: from [219.93.227.99] (helo=greenpacket.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hokfo-0007yy-6v for mip4@ietf.org; Thu, 17 May 2007 14:26:01 -0400 Received: from greenpacket.com ([127.0.0.1]) by mailserver (InternetNow! MailNow! 4.433); Fri, 18 May 2007 02:25:34 +0800 Message-Id: <464C9E1E.0000C5.06572@mailserver> Date: Fri, 18 May 2007 02:25:34 +0800 From: "Koh Ee Haow" To: mip4@ietf.org Cc: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MN-SPAM: 1 X-MN-Loop: 1 X-MN-Info: 0x0001 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-TMDA-Confirmed: Thu, 17 May 2007 17:39:42 -0400 Subject: [Mip4] Addition to the Mobile-IP Implementation List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I would like to add GreenPacket (http://www.greenpacket.com) to the list. We have implemented mobile ipv4 client for Windows 2k, XP, PPC and mobile ipv4 server (ha) for Linux. The product is commercially available. Regards, Howie Koh /---------------------------------------------------------------------------\ Confidential and/ or privileged information may be contained in this e-mail and any attachments transmitted with it ('Message'). If you are not the addressee indicated in this Message (or responsible for delivery of this Message to such person),you are hereby notified that any dissemination, distribution, printing or copying of this Message or any part thereof is prohibited. Please delete this Message if received in error and advise the sender by return e-mail. Opinions, conclusions and other information in this Message that do not relate to the official business of this company shall be understood as neither given nor endorsed by this company. This mail is certified Virus Free by *ProtectNow! (InternetNow Sdn Bhd) *Scanner Engine powered by Norman Virus Control \--------------------------------------------------------------------------/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 17 22:15:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hos02-0001Te-DK; Thu, 17 May 2007 22:15:22 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hos00-0001OB-Rr for mip4-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 22:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hos00-0001Me-Fh for mip4@ietf.org; Thu, 17 May 2007 22:15:20 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Horzy-00080v-CR for mip4@ietf.org; Thu, 17 May 2007 22:15:20 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI700DXJSWCJK@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 18 May 2007 10:14:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JI7000LDSWALX@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 18 May 2007 10:14:36 +0800 (CST) Received: from z49950 ([10.121.32.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI70062SSW7Y7@szxml03-in.huawei.com> for mip4@ietf.org; Fri, 18 May 2007 10:14:34 +0800 (CST) Date: Fri, 18 May 2007 10:14:31 +0800 From: "John.zhao" To: mip4@ietf.org Message-id: <002101c798f2$4584d7f0$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceY8kVJbUFflzgFR/y/XkwqsO23Bg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 22ee92479d98f6ee260f4d663978f084 Subject: [Mip4] About FA-COA X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1956813281==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1956813281== Content-type: multipart/alternative; boundary="Boundary_(ID_hj9euMamdrIPzdyEkJcm6A)" This is a multi-part message in MIME format. --Boundary_(ID_hj9euMamdrIPzdyEkJcm6A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi,folks My 1 cents. I feel some confusion. The co-located can be used to communication to others mobile node, right? But FA-COA can be used to achieve this goal ,right? It can only be used to play the role of the node on the side of the tunnel between FA and HA? Best Rgds, Thanks, John.zhao --Boundary_(ID_hj9euMamdrIPzdyEkJcm6A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,folks

 

         My 1 cents.

         I feel some confusion. The co-located can be used to communication to others mobile node, right? But FA-COA can be used to achieve this goal ,right? It can only be used to play the role of the node on the side of the tunnel between FA and HA?

 

         Best Rgds,

Thanks,

 

John.zhao

--Boundary_(ID_hj9euMamdrIPzdyEkJcm6A)-- --===============1956813281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1956813281==-- From mip4-bounces@ietf.org Fri May 18 10:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3e1-0006El-UC; Fri, 18 May 2007 10:41:25 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hp3e0-0006Ec-MN for mip4-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3e0-0006EU-CN for mip4@ietf.org; Fri, 18 May 2007 10:41:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3dz-0007RC-QY for mip4@ietf.org; Fri, 18 May 2007 10:41:24 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4IEfIdd032024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2007 07:41:18 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4IEfHRP000599; Fri, 18 May 2007 07:41:17 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 07:41:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] About FA-COA Date: Fri, 18 May 2007 07:41:14 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A4F9@NAEX16.na.qualcomm.com> In-Reply-To: <002101c798f2$4584d7f0$a864a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] About FA-COA Thread-Index: AceY8kVJbUFflzgFR/y/XkwqsO23BgAZ+BHA References: <002101c798f2$4584d7f0$a864a8c0@china.huawei.com> From: "Tsirtsis, George" To: , X-OriginalArrivalTime: 18 May 2007 14:41:17.0209 (UTC) FILETIME=[978D8890:01C7995A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1924654400==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1924654400== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7995A.973815B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7995A.973815B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, =20 The FA-CoA is shared between all mobiles under a given FA, so it does not belong to any of them and can not be used by them as source address. Instead the CoA, belongs to the FA, so only the FA can use it as source address. Since the Co-located CoA belongs to a single mobile, it can, as you correctly say be used as source address by that mobile. =20 Best Regards George =20 ________________________________ From: John.zhao [mailto:john.zhao@huawei.com]=20 Sent: Friday, May 18, 2007 3:15 AM To: mip4@ietf.org Subject: [Mip4] About FA-COA =20 Hi,folks =20 My 1 cents. I feel some confusion. The co-located can be used to communication to others mobile node, right? But FA-COA can be used to achieve this goal ,right? It can only be used to play the role of the node on the side of the tunnel between FA and HA? =20 Best Rgds, Thanks, =20 John.zhao ------_=_NextPart_001_01C7995A.973815B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = John,

 

The FA-CoA is = shared between all mobiles under a given FA, so it does not belong to any of = them and can not be used by them as source address. Instead the CoA, belongs to = the FA, so only the FA can use it as source address.

Since the = Co-located CoA belongs to a single mobile, it can, as you correctly say be used as source = address by that mobile.

 

Best = Regards

George

 

From: John.zhao [mailto:john.zhao@huawei.com]
Sent: Friday, May 18, = 2007 3:15 AM
To: mip4@ietf.org
Subject: [Mip4] About = FA-COA

 

Hi,folks

 

      &= nbsp;  My 1 cents.

      &= nbsp;  I feel some confusion. The co-located can be used to communication to = others mobile node, right? But FA-COA can be used to achieve this goal ,right? = It can only be used to play the role of the node on the side of the tunnel = between FA and HA?

 

      &= nbsp;  Best Rgds,

Thanks,

 

John.zhao

------_=_NextPart_001_01C7995A.973815B4-- --===============1924654400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1924654400==-- From mip4-bounces@ietf.org Fri May 18 15:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp819-0000IN-2r; Fri, 18 May 2007 15:21:35 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hp817-0000I2-Tm for mip4-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp817-0000Hm-Ft; Fri, 18 May 2007 15:21:33 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp816-0003Hd-9f; Fri, 18 May 2007 15:21:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 30F2426ED6; Fri, 18 May 2007 19:21:32 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hp816-0005NS-3B; Fri, 18 May 2007 15:21:32 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 18 May 2007 15:21:32 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@ietf.org Subject: [Mip4] Last Call: draft-ietf-mip4-fmipv4 (Mobile IPv4 Fast Handovers) to Experimental RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has received a request from the Mobility for IPv4 WG (mip4) to consider the following document: - 'Mobile IPv4 Fast Handovers ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14318&rfc_flag=0 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 18 15:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Ss-0005h3-Iu; Fri, 18 May 2007 15:50:14 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hp8Sh-0005NP-9M for mip4-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Sg-0005N4-Nu; Fri, 18 May 2007 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8Sg-0006zX-Cr; Fri, 18 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3E1A326E8C; Fri, 18 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hp8Sg-0000Qs-4Y; Fri, 18 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 18 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Fast Handovers Author(s) : R. Koodli, C. Perkins Filename : draft-ietf-mip4-fmipv4-07.txt Pages : 28 Date : 2007-5-18 This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-07.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-ietf-mip4-fmipv4-07.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-mip4-fmipv4-07.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: <2007-5-18113045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-fmipv4-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-fmipv4-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-18113045.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon May 21 03:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq2Y3-0002kW-C0; Mon, 21 May 2007 03:43:19 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hq2Y2-0002kQ-1Z for mip4-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 03:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq2Y1-0002kA-4A for mip4@ietf.org; Mon, 21 May 2007 03:43:17 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq2Xz-0002CA-TD for mip4@ietf.org; Mon, 21 May 2007 03:43:17 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2126001nzd for ; Mon, 21 May 2007 00:43:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=jRWCKLDCavREa8K2gAqoHK/26pMbVK4o+uXpiAGsPb4d2S6dyNmtepB2kz698trZD8+eey9+vXXXJNLx+rXZpNRBIE0z1HoJhWAIKBVQYu5EZ4AMZctD6d9p7QHAjbtdF0XLwsNhxTHFLsaZZzWZqlie8Lw1/29TEh4UFHmIt8I= 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=IA5DKmcEcT1GjLcXQ+Yl9/r1GhV0mTTX0US569T2ecBB1zhyfuFsvTGdqWonDeFibEtxxBdlgemZqyBr6ThwflC05eBogwvhGqoX1H3EPxin3UQjdpddmXRlUkzKRubI0jHUCjxbZgSKtYIBIN/viPQ2sKkS8rF8IdLG+eeRI9g= Received: by 10.64.181.12 with SMTP id d12mr10161659qbf.1179733395563; Mon, 21 May 2007 00:43:15 -0700 (PDT) Received: by 10.65.213.12 with HTTP; Mon, 21 May 2007 00:43:15 -0700 (PDT) Message-ID: Date: Mon, 21 May 2007 14:43:15 +0700 From: "Kuljaree Tantayakul" To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Mip4] MIP4 patch X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Dear All, I interesting about Mobile IP both IPv4 and IPv6. Now I try to find patch for FreeBSD to setup my network to support both MIP. But I'm not have MIPv4 patch. Please suggest me about patch. And I have some question "Do you know the KAME patch support MIPv4? How to check it?" **Note In my works, I want to find a possible way to allow MIPv4 and MIPv6. Thanks for your suggestions. Best Regards, Kuljaree -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 21 05:08:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3sS-0003l3-Jg; Mon, 21 May 2007 05:08:28 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hq3sQ-0003kV-Pu for mip4-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3sQ-0003kA-8n for mip4@ietf.org; Mon, 21 May 2007 05:08:26 -0400 Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq3sN-0001q0-Bg for mip4@ietf.org; Mon, 21 May 2007 05:08:26 -0400 Received: from [127.0.0.1] (c53.local.ipunplugged.com [192.168.4.253]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id l4L98B16028595; Mon, 21 May 2007 11:08:15 +0200 Message-ID: <4651617C.1000507@ipunplugged.com> Date: Mon, 21 May 2007 11:08:12 +0200 From: Hans Sjostrand User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kuljaree Tantayakul Subject: Re: [Mip4] MIP4 patch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Kuljaree, A http://www.google.com/search?q=freebsd+"mobile-ip" gives you some valuable information. * Mobile-IP Implementations www.mip4.org/2004/implementations/ * Secure Mobile Networking Project Home Page www.cs.pdx.edu/research/SMN/ The top hit is a list of "current" Mobile IP implementations. The second hit is a Mobile IP implementation that should work on FreeBSD. The statement "Portland State University, actively updated" on the MIP implementations list is maybe an exaggeration. A good introduction to MIPv4 and MIPv6 could be the master thesis "Seamless Mobility Between Current and Future IP Networks" http://folk.uio.no/paalee/referencing_publications/ref-mt-linden-thesis04.pdf Good luck /// Hasse On 2007-05-21 09:43, Kuljaree Tantayakul wrote: > Dear All, > I interesting about Mobile IP both IPv4 and IPv6. Now I try to > find patch for FreeBSD to setup my network to support both MIP. But > I'm not have MIPv4 patch. Please suggest me about patch. And I have > some question "Do you know the KAME patch support MIPv4? How to check > it?" > > **Note > In my works, I want to find a possible way to allow MIPv4 and MIPv6. > > > Thanks for your suggestions. > Best Regards, > Kuljaree > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 23 08:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqphP-0005ad-Gb; Wed, 23 May 2007 08:12:15 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HncRX-0006gQ-Qt for mip4-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HncRX-0006g9-Ga for mip4@ietf.org; Mon, 14 May 2007 11:26:35 -0400 Received: from kronos.cti.gr ([150.140.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HncRW-0007EO-SK for mip4@ietf.org; Mon, 14 May 2007 11:26:35 -0400 Received: (qmail 16174 invoked from network); 14 May 2007 15:26:43 -0000 Received: from comet.cti.gr (150.140.12.12) by kronos.cti.gr with SMTP; 14 May 2007 15:26:43 -0000 Received: (qmail 17820 invoked from network); 14 May 2007 15:26:29 -0000 Received: from comet.cti.gr (HELO localhost) (150.140.12.12) by comet.cti.gr with SMTP; 14 May 2007 15:26:29 -0000 Received: from kallioph.ceid.upatras.gr (kallioph.ceid.upatras.gr [150.140.141.24]) by nts.cti.gr (IMP) with HTTP for ; Mon, 14 May 2007 18:26:27 +0300 Message-ID: <1179156387.46487fa3eb099@nts.cti.gr> Date: Mon, 14 May 2007 18:26:27 +0300 From: Christos Bouras To: bouras@cti.gr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 150.140.141.24 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Wed, 23 May 2007 08:12:13 -0400 Cc: Subject: [Mip4] ACM WMuNeP'07 Workshop Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org -------------------------------------------------------------------------- Sorry if you have received multiple message. ---------------------------------------------------------------------------- ------------------------------------- 3rd ACM* WMUNEP'07 THE THIRD ACM( INTERNATIONAL WORKSHOP ON WIRELESS MULTIMEDIA NETWORKING AND PERFORMANCE MODELING 22-26 October 2007 Chania, Creta Island, Greece _ http://wmunep2007.cti.gr/_ To be held jointly with 10th ACM/IEEE MSWiM 2007 the 10-th ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems _ http://www.cs.unibo.it/projects/mswim2007/_) *Pending. Sponsored by Association for Computer Machinery (ACM) ---------------------------------------------------------------------------- --------------------------- Paper Submission deadline: June 1, 2007 ___________________________________ SCOPE -------------------------------------------------------------------------- The Third ACM International Workshop on Wireless Multimedia Networking and Performance Modeling (WMuNeP'07) will be a one-day workshop, held in conjunction with the 10th Annual ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM´07). The demand for wireless multimedia communications thrives in today's consumer and corporate market. The need to evolve multimedia applications and services, and their associated protocols for emerging networks is at a critical point given the proliferation and integration of wireless systems to intelligent and broadband networks, mobility of people, data/voice convergence and the integration of computing and communication in mobile devices. This workshop is devoted to cover different aspects of wireless multimedia networking and performance modeling for WLANs, WPANs, WMANs, WWANs, MANETs and sensor networks such as wireless video and wireless streaming, systematic design methodologies, algorithms, synchronization, analysis and performance modeling. The workshop will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects. -------------------------------------------------------------------------- TOPICS -------------------------------------------------------------------------- Topics of interest include (but are not limited to): -Wireless multimedia network management -Wireless multimedia traffic modeling -Middleware and reflective systems support for wireless multimedia -Proxy-based systems for video transcoding and content distribution -Performance modeling, monitoring and evaluation of wireless multimedia networks and systems -Multipoint, multicast wireless multimedia services -Deployment of wireless multimedia applications, services and networks -Protocols for wireless multimedia networks -QoS and Resource Allocation in wireless multimedia networks -Integration of wireless multimedia networks to broadband networks -End-to-end IP multimedia wireless communications -Coding and transmission for wireless multimedia networks -Distributed wireless multimedia services -Content-based wireless multimedia information retrieval tools -Video, streaming, real-time wireless multimedia communications and applications Security in wireless multimedia networks -Wireless multimedia right protection and watermarking -Pricing mechanisms for wireless multimedia networks -E-Commerce and related applications for wireless multimedia networks -Multimedia evaluation and processing for wireless networks -Cross layer design for wireless multimedia networks -Software tools for system performance and evaluation of wireless multimedia networks -Case studies showing the role of evaluation in the design of systems -------------------------------------------------------------------------- SUBMISSIONS -------------------------------------------------------------------------- Authors are invited to submit research contributions representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Accepted papers will appear on the workshop proceedings that will be published by ACM press. At least one of the authors of accepted papers must attend the conference to present his/her paper. Paper length should be no more than 10 pages, double column, ACM style including tables and figures. More information about the submission template can be found in the workshop web site (_http://wmunep2007.cti.gr/_). Only Postscript and PDF formats are accepted. -------------------------------------------------------------------------- ORGANIZING COMMITTEES -------------------------------------------------------------------------- Program committee of the workshop can be found in the following URL: _http://wmunep2007.cti.gr/committees.php_ -------------------------------------------------------------------------- IMPORTANT DATES -------------------------------------------------------------------------- Paper Submission June 1, 2007 Author Notification July 5, 2007 Author Registration TBA Camera-ready Paper TBA For any question related to WMuNeP 2007, please contact the Program Co-Chairs Prof. Regina Araujo: regina at dc.ufscar.br and/or Prof. Christos Bouras: bouras at cti.gr) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 23 08:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqpjA-0007Im-Nu; Wed, 23 May 2007 08:14:04 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HoFQH-0008IR-46 for mip4-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 05:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFQG-0008Gb-G3 for mip4@ietf.org; Wed, 16 May 2007 05:03:52 -0400 Received: from mail.di.uniroma1.it ([151.100.17.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFQF-0008GK-M1 for mip4@ietf.org; Wed, 16 May 2007 05:03:52 -0400 Received: from [151.100.17.90] (unknown [151.100.17.90]) by mail.di.uniroma1.it (Postfix) with ESMTP id 866961BD651 for ; Wed, 16 May 2007 10:46:58 +0200 (CEST) Message-ID: <464AC8F2.4020007@di.uniroma1.it> Date: Wed, 16 May 2007 11:03:46 +0200 From: Gaia Maselli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-Mailman-Approved-At: Wed, 23 May 2007 08:14:02 -0400 Subject: [Mip4] ACM HealthNet 2007 - MobiSys Workshop: Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maselli@di.uniroma1.it List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP. ------------------------------------------------------------ ************************************************************ CALL FOR PARTICIPATION ACM HealthNet 2007 ********** EARLY REGISTRATION DEADLINE EXTENDED ********** to MAY 18, 2007 Please, check http://healthnet07.cs.uiuc.edu/ for venue and registration information ************************************************************ The 1st International Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments Sponsored by ACM SIGMOBILE in conjunction with ACM MobiSys 2007 =20 Corporate sponsors: Microsoft (gold), IBM (silver) Jointly organized by * The University of Illinois at Urbana Champaign, US, and * Universit=E0 di Roma "La Sapienza," Italy ************************************************************ You are cordially invited to join us in San Juan, Puerto Rico, on June 11, 2007 for participating to ACM HealthNet 2007. The workshop is devoted to presenting and discussing novel findings and approaches for healthcare systems and networks. ****************** WORKSHOP FEATURES ******************* * 13 full papers * * 7 research posters * ************************************************************ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TECHNICAL PROGRAM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Session 1: Access and Security * Rendezvous-based access control for medical records in the pre-hospital environment Feike Dillema (Universitetet i Troms=D8, NO); Simone Lupetti (Universitetet i Troms, NO) * Addressing Security in Medical Sensor Networks Kriangsiri Malasri (University of Memphis, US); Lan Wang (University of Memphis, US) * Context-aware Access to Public Shared Devices David Jea (University of California, Los Angeles, US); Ian Yap (University of California, Los Angeles, US); Mani Srivastava (University of California, Los Angeles, US) Session 2: Network Architectures and Support * Investigating Network Architectures for Body Sensor Networks Anirudh Natarajan (National University of Singapore, SG); Mehul Motani (National University of Singapore, SG); Buddhika De Silva (University of Singapore, SG); Kok Kiong Yap (Stanford University, US); Kee Chaing Chua (National University of Singapore, SG) * H-MAC, Heartbeat Driven Medium Access Control for Body Sensor Networks Huaming Li (Michigan Technological University, US) * Towards Highly-Available WSNs for Assisted Living Safwan Al-Omari (Wayne State Univeristy, US); Weisong Shi (Wayne State University, US) * Energy-Efficient Multi-hop Medical Sensor Networking Antonio Ruzzelli (University College Dublin, IE); Raja Jurdak (University College Dublin, IE); Gregory O'Hare (University College Dublin, IE); Peter van der Stok (Philips Research Laboratories, NL) Session 3: System Design * Participatory User Centered Design Techniques for a Large Scale Ad-Hoc Health Information System Tia Gao (John Hopkins University Applied Physics Lab, US); Tammara Massey (UCLA, US); Leo Selavo (University of Virginia, US); Matt Welsh (Harvard University, US); Majid Sarrafzadeh (UCLA, US) * Investigating and Supporting Health Management Practices of Individuals with Diabetes Lena Mamykina (Siemens Corporate Research, Inc., US); Elizabeth Mynatt (Georgia Institute of Technology, USA, US) * MACCS: An Industrial Study of Hands-Free Wireless Communications for Mobile Healthcare Workers Michael Sammon (Avaya Labs Research, US); Lynne Brotman (Avaya Labs Research, US); Ed Peebles (Avaya Labs Research, US); Dor=EFe Seligmann (Avaya Labs Research, US) Session 4: Research Posters * A Feature Combination Approach for the Detection of Early Morning Bathroom Activities with Wireless Sensors Nuri Ince (University of Minnesota, US); Cheol-Hong Min (University of Minnesota, US); Ahmed Tewfik (University of Minnesota, US) * A Resource Optimized Physical Movement Monitoring Scheme for Environmental and on-Body Sensor Networks Antti Vehkaoja (Tampere University of Technology, FI); Sameer Iyengar (UC Berkeley, US); Mari Zakrzewski (Tampere University of Technology, FI); Roozbeh Jafari (University of California, Berkeley, US); Ruzena Bajcsy (University of California, US); Steve Glaser (University of California at Berkeley, US); Jukka Lekkala (Tampere University of Technology, FI); Shankar Sastry (UC Berkeley, US)/ * Accelerometer-Based Human Abnormal Movement Detection in Wireless Sensor Networks Timothy Burchfield (University of Texas at Dallas, US); Subbarayan Venkatesan (University of Texas at Dallas, US) * An Integrated Wireless Sensing and Mobile Processing Architecture for Assisted Living and Healthcare Applications Serhan Dagtas (University of Arkansas at Little Rock, US) * Automatic Administration of the Get Up and Go Test Dounia Berrada (Georgia Institute of Technology, US); Mario Romero (Georgia Institute of Technology, US); Gregory Abowd (Georgia Institute of Technology, US); Marion Blount (IBM Research, US); John Davis (IBM, US) * Health-OS: A Positioning Paper Nuria Oliver (Microsoft Research, Redmond, US); Darko Kirovski (Microsoft Research, US); Desney Tan (Microsoft Research, US); Mike Sinclair (Microsoft Research, US) * Meditrina: Addressing the System-level Challenges to Ambient Assisted Living Albert Harris III (University of Illinois at Urbana-Champaign, US= ); Rob Kooper (UIUC, US); Robin Kravets (University of Illinois at Urbana-Champaign, US); Gaia Maselli (University of Rome "La Sapienza," IT); Chiara Petrioli (University of Rome "La Sapienza," IT) Session 5: Data and Event Management * Universal Real-Time Navigational Assistance (URNA): An Urban Bluetooth Beacon for the Blind Shawn Bohonos (UCSC, US); Alexander Lee (UCSC, US); Amir Malik (UCSC, US); Chung Thai (UCSC, US); Roberto Manduchi (University of California Santa Cruz, US) * Algorithm to Automatically Detect Abnormally Long Periods of Inactivity in a Home Paul Cuddihy (GE Global Research, US); Jenny Weisenberg (GE Global Research, US); Catherine Graichen (GE Global Research, US); Meena Ganesh (General Electric Company, US) * A Time-and-Value Centric Provenance Model and Architecture for Medical Event Streams Archan Misra (IBM TJ Watson Research Center, US); John Davis (IBM, US); Marion Blount (IBM Research, US); Daby Sow (IBM Watson, US); Min Wang (IBM Research, US) --=20 Gaia Maselli, Postdoc HealthNet 2007 Publicity Chair Computer Science Dept. Rome University "La Sapienza" Via Salaria 113, 00198 Rome Italy -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed May 23 17:03: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 1Hqxzd-0003xD-Du; Wed, 23 May 2007 17:03:37 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hqxzb-0003x8-Nz for mip4-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 17:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqxzb-0003x0-Dx for mip4@ietf.org; Wed, 23 May 2007 17:03:35 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hqxza-0003up-6a for mip4@ietf.org; Wed, 23 May 2007 17:03:35 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1179954213!14341733!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 9419 invoked from network); 23 May 2007 21:03:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-119.messagelabs.com with SMTP; 23 May 2007 21:03:33 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l4NL3Xvc020739 for ; Wed, 23 May 2007 14:03:33 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l4NL3WmG007082 for ; Wed, 23 May 2007 16:03:32 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4NL3VDp007066 for ; Wed, 23 May 2007 16:03:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 May 2007 17:03:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contradiction between RFC 3957 and RFC 4721 thread-index: AcedfdCkgMDuzt5QSXKahKaMFgAPaA== From: "McCann Peter-A001034" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Mip4] Contradiction between RFC 3957 and RFC 4721 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org It has been brought to my attention that there is a contradiction between RFC 3957 and RFC 4721 in=20 the specification of how the MN-AAA Authentication Extension can be used in Registration Replies. RFC 3957 contains the following text in Section 1, 2nd-to-last paragraph: > When the Mobile IP Registration Reply packet is authenticated > by the MN-AAA Authentication Extension [3], the mobile node can > verify that the key material contained in the extensions were > produced by the AAA server, and thus may be reliably used to create > Mobility Security Associations with the home agent and/or the foreign > agent. Meanwhile, RFC 4721 contains the following text in Section 6: > If the Mobile-AAA Authentication extension is present, the Mobile- > Home Authentication extension MUST appear prior to the Mobile-AAA > Authentication extension. The corresponding response MUST include > the Mobile-Home Authentication extension and MUST NOT include the > Mobile-AAA Authentication extension. It seems to me that inclusion of an MN-AAA extension in a Registration Reply is not strictly necessary to validate=20 the integrity of the new keys; that can be accomplished by computing the MN-HA (and MN-FA) keys from the supplied=20 nonces and verifying the corresponding MN-HA (or MN-FA) authentication extension. However, I also think that a blanket prohibition against including the MN-AAA extension in Registration Replies was not intended. Also, it seems that the text in RFC 4721 also requires the MN-HA authentication extension to be present in the registration request even when an MN-HA=20 key has not yet been distributed. Is there any information out there as to how implementations deal with MN-AAA authentication extensions in Registration Replies? Should we generate an erratum to RFC 4721, permitting their inclusion? -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 24 04:59: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 1Hr9Ag-0006w7-Lv; Thu, 24 May 2007 04:59:46 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hr9Ae-0006vy-I1 for mip4-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 04:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr9Ad-0006vm-RY for mip4@ietf.org; Thu, 24 May 2007 04:59:43 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr9Ad-0006ll-CS for mip4@ietf.org; Thu, 24 May 2007 04:59:43 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l4O8wOWh010076; Thu, 24 May 2007 10:58:24 +0200 Received: from [172.27.205.187] ([172.27.205.187]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 May 2007 10:59:31 +0200 Message-ID: <465553F4.2030202@alcatel-lucent.fr> Date: Thu, 24 May 2007 10:59:32 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] Contradiction between RFC 3957 and RFC 4721 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2007 08:59:31.0102 (UTC) FILETIME=[D7706BE0:01C79DE1] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org McCann Peter-A001034 wrote: > It has been brought to my attention that there is > a contradiction between RFC 3957 and RFC 4721 in > the specification of how the MN-AAA Authentication > Extension can be used in Registration Replies. > > RFC 3957 contains the following text in Section 1, > 2nd-to-last paragraph: > > >> When the Mobile IP Registration Reply packet is authenticated >> by the MN-AAA Authentication Extension [3], the mobile node can >> verify that the key material contained in the extensions were >> produced by the AAA server, and thus may be reliably used to create >> Mobility Security Associations with the home agent and/or the >> > foreign > >> agent. >> > > Meanwhile, RFC 4721 contains the following text in Section 6: > > >> If the Mobile-AAA Authentication extension is present, the Mobile- >> Home Authentication extension MUST appear prior to the Mobile-AAA >> Authentication extension. The corresponding response MUST include >> the Mobile-Home Authentication extension and MUST NOT include the >> Mobile-AAA Authentication extension. >> > > It seems to me that inclusion of an MN-AAA extension in a > Registration Reply is not strictly necessary to validate > the integrity of the new keys; that can be accomplished by > computing the MN-HA (and MN-FA) keys from the supplied > nonces and verifying the corresponding MN-HA (or MN-FA) > authentication extension. > > However, I also think that a blanket prohibition against > including the MN-AAA extension in Registration Replies > was not intended. Also, it seems that the text in RFC 4721 > also requires the MN-HA authentication extension to be > present in the registration request even when an MN-HA > key has not yet been distributed. > Yes i have pointed out the last point on the mailing list a while ago without success. The questions were: "What value should be set by the MN in the mandatory MN-HA authentication extension when MN-HA key is not yet available because being bootstrapped using the MN-AAA extension also contained in the registration request?" "In such a case, how should the MN-HA extension from the registration request be handled by the HA"? Be ignored? I don't have yet the answer. > Is there any information out there as to how implementations > deal with MN-AAA authentication extensions in Registration > Replies? Should we generate an erratum to RFC 4721, permitting > their inclusion? > > Erratum would certainly help. Should state clearly how RFC 3344bis should be interpreted/relaxed when AAA is used as an alternate authorization method. Bruno. > -Pete > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 24 06:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrAmp-0006xG-Fc; Thu, 24 May 2007 06:43:15 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HrAmn-0006x3-Jy for mip4-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 06:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrAmn-0006wv-9L for mip4@ietf.org; Thu, 24 May 2007 06:43:13 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrAmm-0002gE-Q7 for mip4@ietf.org; Thu, 24 May 2007 06:43:13 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4OAhAx4024072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 May 2007 03:43:11 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4OAh9Xw029605; Thu, 24 May 2007 03:43:10 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 03:43:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Thu, 24 May 2007 03:43:06 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIA== References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com> From: "Tsirtsis, George" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 24 May 2007 10:43:09.0594 (UTC) FILETIME=[51F2FFA0:01C79DF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Ahmad, Sorry for the delay in responding to you. GRE is an encapsulation method that can be used to transport any number of protocols on top of it (not limited to IP). The IETF has defined a number of mechanisms including L2TP, Pseudowires, MPLS etc, all of which are building L2 tunnels over IP, so I am not sure to what exactly you object. In any case, the intention of the draft is, in fact, much more "IP friendly" than you think....although IP friendliness is not a clear requirement for IDs I think :-)=20 Let me explain. Take as an example a PMIPv4 based network. In some such networks, when the network detects that a node attaches, the MPA registers to the HA. This typically creates a MPA-HA tunnel, connecting the mobile to the HA via the MPA, and it also allocates an IPv4 address to that mobile. If in the same network one wants to support IPv4, IPv6 and Dual Stack mobiles, the following problem arises. PMIPv4 (even extended with DSMIPv4), ALWAYS allocates an IPv4 address to the mobile, whether the mobile needs it or not, and even if the mobile is IPv6 only or if it is Dual Stack but it does not use the IPv4 stack. Note that when PMIPv6 is used this may not be such a concern because one can "waste" some IPv6 addresses or even /64 prefixes to keep things simple. In IPv4, however, due to the shortage of IPv4 addresses, such waste is some times not acceptable. The draft, allows PMIPv4 to set-up a tunnel without allocating an IPv4 address to the mobile. The mobile can then run DHCPv4, DHCPv6, RS/RA, or whatever address configuration mode it supports to configure its IP stack, so the "waste" of addresses is avoided. I hope this helps. George -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Sent: Thursday, May 17, 2007 3:48 PM To: Tsirtsis, George; mip4@ietf.org Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Hi George, I am not sure how did you categorize the proposed functionality in this draft as a slightly different use from the functionality proposed by draft-yegani-gre-key-extension-02 draft. In my understanding all IP mobility protocol is used to establish L-3 mobility via allowing the Mobile Node to be able to use its IP address (Home) regardless of the point of attachment. However, it seems to me that what you are trying to propose here is to use PMIPv4, which is a network based IP mobility protocol, to establish a layer-2 tunnel, I may say a L-2 mobility, by violating the very basic principle of IP mobility. Are you suggesting here a new protocol using messages that already defined in IP Mobility v4 space? Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Tuesday, May 08, 2007 3:38 AM > To: mip4@ietf.org > Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi everyone, >=20 > The following draft extends=20 > draft-yegani-gre-key-extension-02.txt for a slightly=20 > different use of GRE-keys in PMIPv4.=20 >=20 > Let me know if you have any comments. >=20 > Best Regards > George=20 >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, May 07, 2007 11:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : GRE-based L2 Tunneling with PMIPv4 > Author(s) : G. Tsirtsis, V. Park > Filename : draft-tsirtsis-l2gre-pmipv4-00.txt > Pages : 15 > Date : 2007-5-7 > =09 > This specification introduces mechanisms for creating a=20 > GRE-based L2 > Tunnel with PMIPv4. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-tsirtsis-l2gre-pmipv4-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt". > =09 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 24 13:13:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrGsc-0006eL-U2; Thu, 24 May 2007 13:13:38 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HrGsb-0006eA-4F for mip4-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 13:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrGsa-0006e2-Qk for mip4@ietf.org; Thu, 24 May 2007 13:13:36 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrGsa-0005ai-Bc for mip4@ietf.org; Thu, 24 May 2007 13:13:36 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4OHCMN08833; Thu, 24 May 2007 17:12:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Thu, 24 May 2007 12:13:22 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4g References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com> From: "Ahmad Muhanna" To: "Tsirtsis, George" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, Please see comments inline. Regards, Ahmad =20 > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi Ahmad, >=20 > Sorry for the delay in responding to you. [Ahmad] np. >=20 > GRE is an encapsulation method that can be used to transport=20 > any number of protocols on top of it (not limited to IP). The=20 [Ahmad] We do not disagree here. As a reference, the following text is extracted from RFC1701: " Abstract This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. " > IETF has defined a number of mechanisms including L2TP,=20 > Pseudowires, MPLS etc, all of which are building L2 tunnels=20 > over IP, so I am not sure to what exactly you object. [Ahmad] I do not think I raised the issue of what GRE is used for. Please reread my posting. >=20 > In any case, the intention of the draft is, in fact, much=20 > more "IP friendly" than you think....although IP friendliness=20 > is not a clear requirement for IDs I think :-) [Ahmad] It has nothing to do with IP friendly or not, IMO. However, when you announce the publication of your ID on MIP4 mailing list, you, I guess, expect people to point out if the ID use of MIP4/PMIP4 is not inline with what these protocol are developed for.=20 =20 >=20 > Let me explain. Take as an example a PMIPv4 based network. In=20 > some such networks, when the network detects that a node=20 > attaches, the MPA registers to the HA. This typically creates=20 > a MPA-HA tunnel, connecting the mobile to the HA via the MPA,=20 > and it also allocates an IPv4 address to that mobile. [Ahmad] Ok. >=20 > If in the same network one wants to support IPv4, IPv6 and=20 > Dual Stack mobiles, the following problem arises. PMIPv4=20 > (even extended with DSMIPv4), ALWAYS allocates an IPv4=20 > address to the mobile, whether the mobile needs it or not,=20 > and even if the mobile is IPv6 only or if it is Dual Stack=20 > but it does not use the IPv4 stack. [Ahmad] Few points here: 1. PMIPv4 is NOT a standard yet, so I am not sure how to judge what you are citing here.=20 2. Are you aware of any PMIPv4 deployment which address IPv6 ONLY MN. I doubt that operators have extra IPv4 to waste. 3. In comparison, PMIPv6, which on standard track, should not have the same problem, IMO. 4. For the sake of this argument, let us assume what you said about PMIPv4. I would like to remind you here, that the allocated IPv4 address is still topologically correct and can be used to reference the MN binding. i.e. that IPv4 address is still routable if necessary. >=20 > Note that when PMIPv6 is used this may not be such a concern=20 > because one can "waste" some IPv6 addresses or even /64=20 > prefixes to keep things simple. In IPv4, however, due to the=20 > shortage of IPv4 addresses, such waste is some times not acceptable. [Ahmad] I think this is irrelevant to the discussion. We are not comparing how PMIPv4 vs. PMIPv6 would be used to establish dynamic L-2 GRE tunnel. =20 > The draft, allows PMIPv4 to set-up a tunnel without=20 > allocating an IPv4 address to the mobile. The mobile can then=20 > run DHCPv4, DHCPv6, RS/RA, or whatever address configuration=20 > mode it supports to configure its IP stack, so the "waste" of=20 > addresses is avoided. [Ahmad] Again, I am not debating the value of generating a dynamic GRE keys to establish GRE tunnel dynamically. I think that functionality is a good one. My point here is you are using PMIPv4 to establish GRE tunneling dynamically. That is against the basic principle of PMIPv4, assuming it is an extension to MIPv4 for now. Let me explain a little more here: 1. GRE encapsulation as per RFC1701, although it is not mentioned explicitly, but the assumption is the key is static. But still, RFC2890 stated that is out of scope. 2. Anyway, we need to distinguish between two cases here: 2.1. using MIPv4/PMIPv4 to exchange GRE keys between peers while establishing a MIPv4/PMIPv4 session, for example to identify a private IPv4 address session. 2.2. using MIPv4/PMIPv4 to establish a per MN dynamic layer-2 tunnel. That is NOT within the scope of IP mobility. 3. Having said all of the above, If you would like to use the MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2 tunnel, that is FINE with me. However, that is totally a different animal than calling it "using PMIPv4 protocol" In other words, my question from my initial posting still valid: " Are you suggesting here a new protocol using messages that already defined in IP Mobility v4 space?" In your response, I did not see any answer for this question. 4. Finally, with respect to you citing L2TP, MPLS, etc in this context, I would like to mention the following: 4.1.: RFC2661, define a whole new protocol for achieving an on demand L2 tunnel, which is what you are trying to achieve in your ID using the wrong protocol, Please take a look at the following from RFC2661: " This document defines the necessary control protocol for on-demand creation of tunnels between two nodes and the accompanying encapsulation ...... >=20 > I hope this helps. [Ahmad] Sure it did. Please see comments above. > George >=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, May 17, 2007 3:48 PM > To: Tsirtsis, George; mip4@ietf.org > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Hi George, >=20 > I am not sure how did you categorize the proposed=20 > functionality in this draft as a slightly different use from=20 > the functionality proposed by > draft-yegani-gre-key-extension-02 draft. In my understanding=20 > all IP mobility protocol is used to establish L-3 mobility=20 > via allowing the Mobile Node to be able to use its IP address=20 > (Home) regardless of the point of attachment. However, it=20 > seems to me that what you are trying to propose here is to=20 > use PMIPv4, which is a network based IP mobility protocol, to=20 > establish a layer-2 tunnel, I may say a L-2 mobility, by=20 > violating the very basic principle of IP mobility. >=20 > Are you suggesting here a new protocol using messages that=20 > already defined in IP Mobility v4 space? >=20 > Thanks. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > > Sent: Tuesday, May 08, 2007 3:38 AM > > To: mip4@ietf.org > > Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt > >=20 > > Hi everyone, > >=20 > > The following draft extends > > draft-yegani-gre-key-extension-02.txt for a slightly=20 > different use of=20 > > GRE-keys in PMIPv4. > >=20 > > Let me know if you have any comments. > >=20 > > Best Regards > > George > >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Monday, May 07, 2007 11:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : GRE-based L2 Tunneling with PMIPv4 > > Author(s) : G. Tsirtsis, V. Park > > Filename : draft-tsirtsis-l2gre-pmipv4-00.txt > > Pages : 15 > > Date : 2007-5-7 > > =09 > > This specification introduces mechanisms for creating a=20 > GRE-based=20 > > L2 > > Tunnel with PMIPv4. > >=20 > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-tsirtsis-l2gre-pmipv4-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt". > > =09 > > 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=20 > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 25 09:39: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 1Hra1N-0008Ts-Re; Fri, 25 May 2007 09:39:57 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hra1M-0008Tm-Sq for mip4-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 09:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hra1M-0008Te-JA for mip4@ietf.org; Fri, 25 May 2007 09:39:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hra1L-00009C-6w for mip4@ietf.org; Fri, 25 May 2007 09:39:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4PDdrM2009525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 May 2007 06:39:54 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4PDdhBR009332; Fri, 25 May 2007 06:39:53 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 06:39:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Fri, 25 May 2007 06:39:51 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4gADE+YtA= References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com> From: "Tsirtsis, George" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 25 May 2007 13:39:52.0766 (UTC) FILETIME=[2C5865E0:01C79ED2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Ahmad, Some comments inline.... -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Sent: Thursday, May 24, 2007 6:13 PM To: Tsirtsis, George; mip4@ietf.org Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt ... 3. Having said all of the above, If you would like to use the MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2 tunnel, that is FINE with me. However, that is totally a different animal than calling it "using PMIPv4 protocol" In other words, my question from my initial posting still valid: " Are you suggesting here a new protocol using messages that already defined in IP Mobility v4 space?" In your response, I did not see any answer for this question. GT> Ahmad, I do not understand what you mean by "new protocol". The draft defines an extension which, when used in combination with PMIPv4, provides additional functionality. i.e., it allows PMIP to set-up a GRE-based L2 Tunnel specific to a given MN. GT> Of course PMIPv4 is not a WG document. That is fine. I point to the appropriate personal contributions in the draft. 4. Finally, with respect to you citing L2TP, MPLS, etc in this context, I would like to mention the following: 4.1.: RFC2661, define a whole new protocol for achieving an on demand L2 tunnel, which is what you are trying to achieve in your ID using the wrong protocol, Please take a look at the following from RFC2661: " This document defines the necessary control protocol for on-demand creation of tunnels between two nodes and the accompanying encapsulation ...... GT> Ahmed, I only raised L2TP and MPLS because in your earlier e-mail you criticized the proposal as follows: " ... you are trying to propose here is to use PMIPv4, which is a network based IP mobility protocol, to establish a layer-2 tunnel, I may say a L-2 mobility, by violating the very basic principle of IP mobility." So I felt oblidged to point to you that the IETF is not shying away from defining L2 tunneling mechanism.=20 GT> The draft proposal is simply a mechanism enabling mobile L2 tunneling. I am not sure why this is not obvious but L2TP can not handle movement. i.e., if one of the peers moves then L2TP stops working. This proposal is a bit different. It allows a system that already uses PMIP with GRE tunnels to set-up L2 Tunnels. Regards George -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri May 25 17:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhHa-0003Ev-LL; Fri, 25 May 2007 17:25:10 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HrhHZ-0003EZ-UN for mip4-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 17:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhHZ-0003EL-KW for mip4@ietf.org; Fri, 25 May 2007 17:25:09 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrhHZ-0000QO-3h for mip4@ietf.org; Fri, 25 May 2007 17:25:09 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4PLOvD07265; Fri, 25 May 2007 21:24:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Fri, 25 May 2007 16:24:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371148610A6@zrc2hxm2.corp.nortel.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4gADE+YtAAARD6IA== References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> From: "Ahmad Muhanna" To: "Tsirtsis, George" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, Please see comments inline. Regards, Ahmad > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Ahmad, >=20 > Some comments inline.... >=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, May 24, 2007 6:13 PM > To: Tsirtsis, George; mip4@ietf.org > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > ... >=20 > 3. Having said all of the above, If you would like to use the > MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2=20 > tunnel, that is FINE with me. However, that is totally a=20 > different animal than calling it "using PMIPv4 protocol" In=20 > other words, my question from my initial posting still valid: >=20 > " Are you suggesting here a new protocol using messages that=20 > already defined in IP Mobility v4 space?" >=20 >=20 > In your response, I did not see any answer for this question. >=20 > GT> Ahmad, I do not understand what you mean by "new protocol". The > draft defines an extension which, when used in combination=20 > with PMIPv4, provides additional functionality. i.e., it=20 > allows PMIP to set-up a GRE-based L2 Tunnel specific to a given MN. [Ahmad] I see some contradiction here. You just said that you are using an IP Mobility Protocol (L-3 mobility) to establish a (L-2 Tunnel) for the same MN. OK, let me ask a question, Does not L-3 Mobility protocol assumes that there is already a L-2 established. BTW, your draft does not defines a new extension. This extension is already defined in another personal draft: draft-yegani-gre-key-extension-02. I know you most probably did not mean that but for the sake of accuracy. > GT> Of course PMIPv4 is not a WG document. That is fine. I=20 > point to the > appropriate personal contributions in the draft. [Ahmad] Ok. >=20 > 4. Finally, with respect to you citing L2TP, MPLS, etc in=20 > this context, I would like to mention the following: >=20 > 4.1.: RFC2661, define a whole new protocol for achieving an=20 > on demand L2 tunnel, which is what you are trying to achieve=20 > in your ID using the wrong protocol, Please take a look at=20 > the following from RFC2661: > " > This document defines the necessary control protocol for on-demand > creation of tunnels between two nodes and the accompanying > encapsulation ...... >=20 >=20 > GT> Ahmed, I only raised L2TP and MPLS because in your earlier e-mail > you criticized the proposal as follows: " ... you are trying=20 > to propose here is to use PMIPv4, which is a network based IP=20 > mobility protocol, to establish a layer-2 tunnel, I may say a=20 > L-2 mobility, by violating the very basic principle of IP=20 > mobility." So I felt oblidged to point to you that the IETF=20 > is not shying away from defining L2 tunneling mechanism. [Ahmad] George, IETF has a lot of L-2 tunneling mechanisms, However, GRE tunneling is a Generic one which can be used for Layer-2 and Layer-3 tunneling. All drafts which use IP mobility protocol to establish a GRE tunnel or actually negotiate a GRE key, uses it for establishing what we can be called a L-3 GRE tunnel, IP over IP to be used for identifying a flow or to be used in case of private IP address overlapping, etc. In your case you are suggesting using a L-3 IP Mobility protocol to establish a Layer-2 tunnel. I believe that is different. >=20 > GT> The draft proposal is simply a mechanism enabling mobile L2 > tunneling. I am not sure why this is not obvious but L2TP can=20 > not handle movement. i.e., if one of the peers moves then=20 > L2TP stops working.=20 [Ahmad] Excellent point, MIP4/PMIP4 is a L-3 Tunnel mobility protocol (If I may call it that way) which has certain semantics and rules to allow IP mobility. I do not see how this protocol can be used to establish a L-2 tunnel mobility without violating the semantics and rules of the L-3 tunnel mobility protocol. I believe that you are trying to use the signaling of that protocol (MIP4/PMIP4) with some new rules to enable it for establishing a L-2 tunnel mobility. If you agree with this description, I have no problem with that approach. Basically we just can not call the new set of rules with the existing MIP4/PMIP4 signaling messages a MIP4/PMIP4 protocol. I hope you do not have a problem here:-) > This proposal is a bit different. It=20 > allows a system that already uses PMIP with GRE tunnels to=20 > set-up L2 Tunnels. >=20 > Regards > George >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun May 27 09:02: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 1HsIOY-00036A-Ie; Sun, 27 May 2007 09:02:50 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HsIOW-00035v-Sm for mip4-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 09:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsIOW-00035n-J7 for mip4@ietf.org; Sun, 27 May 2007 09:02:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsIOU-00015j-1l for mip4@ietf.org; Sun, 27 May 2007 09:02:48 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4RD2grc028363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 May 2007 06:02:42 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4RD2fB4020180; Sun, 27 May 2007 06:02:41 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 06:02:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Sun, 27 May 2007 06:02:39 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF462978D@NAEX16.na.qualcomm.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371148610A6@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4gADE+YtAAARD6IABilnYw References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA4371148610A6@zrc2hxm2.corp.nortel.com> From: "Tsirtsis, George" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 27 May 2007 13:02:40.0975 (UTC) FILETIME=[4EEB9DF0:01C7A05F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Sent: Friday, May 25, 2007 10:25 PM To: Tsirtsis, George; mip4@ietf.org Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Hi George, Please see comments inline. Regards, Ahmad > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > Ahmad, >=20 > Some comments inline.... >=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, May 24, 2007 6:13 PM > To: Tsirtsis, George; mip4@ietf.org > Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > ... >=20 > 3. Having said all of the above, If you would like to use the > MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2=20 > tunnel, that is FINE with me. However, that is totally a=20 > different animal than calling it "using PMIPv4 protocol" In=20 > other words, my question from my initial posting still valid: >=20 > " Are you suggesting here a new protocol using messages that=20 > already defined in IP Mobility v4 space?" >=20 >=20 > In your response, I did not see any answer for this question. >=20 > GT> Ahmad, I do not understand what you mean by "new protocol". The > draft defines an extension which, when used in combination=20 > with PMIPv4, provides additional functionality. i.e., it=20 > allows PMIP to set-up a GRE-based L2 Tunnel specific to a given MN. [Ahmad] I see some contradiction here. You just said that you are using an IP Mobility Protocol (L-3 mobility) to establish a (L-2 Tunnel) for the same MN. OK, let me ask a question, Does not L-3 Mobility protocol assumes that there is already a L-2 established. GT> Ahmad, we are going in circles. Running L2 over L4/L3 is nothing new or strange. It is called layering. As we discussed before, L2TP and MPLS do exactly that. i.e., they are allowing an L2 connection to be established over IP. GRE, itself is designed to do the same thing. BTW, your draft does not defines a new extension. This extension is already defined in another personal draft: draft-yegani-gre-key-extension-02. I know you most probably did not mean that but for the sake of accuracy. GT> Yes, correct. > GT> Of course PMIPv4 is not a WG document. That is fine. I=20 > point to the > appropriate personal contributions in the draft. [Ahmad] Ok. >=20 > 4. Finally, with respect to you citing L2TP, MPLS, etc in=20 > this context, I would like to mention the following: >=20 > 4.1.: RFC2661, define a whole new protocol for achieving an=20 > on demand L2 tunnel, which is what you are trying to achieve=20 > in your ID using the wrong protocol, Please take a look at=20 > the following from RFC2661: > " > This document defines the necessary control protocol for on-demand > creation of tunnels between two nodes and the accompanying > encapsulation ...... >=20 >=20 > GT> Ahmed, I only raised L2TP and MPLS because in your earlier e-mail > you criticized the proposal as follows: " ... you are trying=20 > to propose here is to use PMIPv4, which is a network based IP=20 > mobility protocol, to establish a layer-2 tunnel, I may say a=20 > L-2 mobility, by violating the very basic principle of IP=20 > mobility." So I felt oblidged to point to you that the IETF=20 > is not shying away from defining L2 tunneling mechanism. [Ahmad] George, IETF has a lot of L-2 tunneling mechanisms, However, GRE tunneling is a Generic one which can be used for Layer-2 and Layer-3 tunneling. All drafts which use IP mobility protocol to establish a GRE tunnel or actually negotiate a GRE key, uses it for establishing what we can be called a L-3 GRE tunnel, IP over IP to be used for identifying a flow or to be used in case of private IP address overlapping, etc. In your case you are suggesting using a L-3 IP Mobility protocol to establish a Layer-2 tunnel. I believe that is different. GT> Yes, it is different. If it was the same, I would not have to write a draft about it. >=20 > GT> The draft proposal is simply a mechanism enabling mobile L2 > tunneling. I am not sure why this is not obvious but L2TP can=20 > not handle movement. i.e., if one of the peers moves then=20 > L2TP stops working.=20 [Ahmad] Excellent point, MIP4/PMIP4 is a L-3 Tunnel mobility protocol (If I may call it that way) which has certain semantics and rules to allow IP mobility. I do not see how this protocol can be used to establish a L-2 tunnel mobility without violating the semantics and rules of the L-3 tunnel mobility protocol. I believe that you are trying to use the signaling of that protocol (MIP4/PMIP4) with some new rules to enable it for establishing a L-2 tunnel mobility. If you agree with this description, I have no problem with that approach. Basically we just can not call the new set of rules with the existing MIP4/PMIP4 signaling messages a MIP4/PMIP4 protocol. I hope you do not have a problem here:-) GT> Ahmad, we are now approaching the bizarre :-) So, in your opinion, instead of defining a flag in an extension, I should create a whole new protocol that is 99.99% the same with MIPv4/PMIPv4 (as well as all the multitude of extensions defined for them) but call it something different. I think I might not do that, thank you. > This proposal is a bit different. It=20 > allows a system that already uses PMIP with GRE tunnels to=20 > set-up L2 Tunnels. >=20 > Regards > George >=20 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 28 09:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsf7H-00071O-69; Mon, 28 May 2007 09:18:31 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hsf7G-00071J-CW for mip4-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 09:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsf7G-00071B-2w for mip4@ietf.org; Mon, 28 May 2007 09:18:30 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsf7E-0005Aa-QQ for mip4@ietf.org; Mon, 28 May 2007 09:18:30 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4SDIJG07293; Mon, 28 May 2007 13:18:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Mon, 28 May 2007 08:17:48 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114861469@zrc2hxm2.corp.nortel.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF462978D@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4gADE+YtAAARD6IABilnYwADMRCfA= References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA4371148610A6@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF462978D@NAEX16.na.qualcomm.com> From: "Ahmad Muhanna" To: "Tsirtsis, George" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org >=20 > [Ahmad] > Excellent point, MIP4/PMIP4 is a L-3 Tunnel mobility protocol=20 > (If I may > call it that way) which has certain semantics and rules to allow IP > mobility. I do not see how this protocol can be used to=20 > establish a L-2 > tunnel mobility without violating the semantics and rules of the L-3 > tunnel mobility protocol. I believe that you are trying to use the > signaling of that protocol (MIP4/PMIP4) with some new rules=20 > to enable it > for establishing a L-2 tunnel mobility. If you agree with this > description, I have no problem with that approach. Basically=20 > we just can > not call the new set of rules with the existing MIP4/PMIP4 signaling > messages a MIP4/PMIP4 protocol. >=20 > I hope you do not have a problem here:-) >=20 > GT> Ahmad, we are now approaching the bizarre :-) So, in your opinion, > instead of defining a flag in an extension, I should create a=20 > whole new > protocol that is 99.99% the same with MIPv4/PMIPv4 (as well as all the > multitude of extensions defined for them) but call it something > different. I think I might not do that, thank you. >=20 [Ahmad] Ok. However, the functionality you are trying to perform is not within the scope of MIP4/PMIP4 nor the MIP4 charter. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon May 28 10:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgCo-0004hu-2x; Mon, 28 May 2007 10:28:18 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HsgCn-0004hp-5y for mip4-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 10:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgCm-0004hd-SV for mip4@ietf.org; Mon, 28 May 2007 10:28:16 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsgCm-00077a-GH for mip4@ietf.org; Mon, 28 May 2007 10:28:16 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4SESCs8006861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 May 2007 07:28:13 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4SESCQV007197; Mon, 28 May 2007 07:28:12 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 07:28:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Date: Mon, 28 May 2007 07:28:22 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF46297A7@NAEX16.na.qualcomm.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114861469@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt Thread-Index: AceQ+k3fQqepaLy2RKyJ8K5UiNEZzQAYkg5wAcz/G3AAMVSXIAEtGT4gADE+YtAAARD6IABilnYwADMRCfAAAoKucA== References: <2309978910A6A6478C2C7585692B0AF4579C05@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA43711451A91E@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457A9DC@NAEX16.na.qualcomm.com><6FC4416DDE56C44DA0AEE67BC7CA4371147AE4B3@zrc2hxm2.corp.nortel.com><2309978910A6A6478C2C7585692B0AF457AB25@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA4371148610A6@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF462978D@NAEX16.na.qualcomm.com> <6FC4416DDE56C44DA0AEE67BC7CA437114861469@zrc2hxm2.corp.nortel.com> From: "Tsirtsis, George" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 28 May 2007 14:28:12.0459 (UTC) FILETIME=[6BEFAFB0:01C7A134] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Ahmad, I disagree but that is OK. The issue of making this draft a WG document has not come up yet...we can discuss this again if/when this issue becomes relevant. Regards George -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Sent: Monday, May 28, 2007 2:18 PM To: Tsirtsis, George; mip4@ietf.org Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt >=20 > [Ahmad] > Excellent point, MIP4/PMIP4 is a L-3 Tunnel mobility protocol=20 > (If I may > call it that way) which has certain semantics and rules to allow IP > mobility. I do not see how this protocol can be used to=20 > establish a L-2 > tunnel mobility without violating the semantics and rules of the L-3 > tunnel mobility protocol. I believe that you are trying to use the > signaling of that protocol (MIP4/PMIP4) with some new rules=20 > to enable it > for establishing a L-2 tunnel mobility. If you agree with this > description, I have no problem with that approach. Basically=20 > we just can > not call the new set of rules with the existing MIP4/PMIP4 signaling > messages a MIP4/PMIP4 protocol. >=20 > I hope you do not have a problem here:-) >=20 > GT> Ahmad, we are now approaching the bizarre :-) So, in your opinion, > instead of defining a flag in an extension, I should create a=20 > whole new > protocol that is 99.99% the same with MIPv4/PMIPv4 (as well as all the > multitude of extensions defined for them) but call it something > different. I think I might not do that, thank you. >=20 [Ahmad] Ok. However, the functionality you are trying to perform is not within the scope of MIP4/PMIP4 nor the MIP4 charter. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu May 31 12:43: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 1HtnkM-0005wA-Uz; Thu, 31 May 2007 12:43:34 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HtKzk-0007Pa-St for mip4-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 06:01:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKzk-0007PS-F2 for mip4@ietf.org; Wed, 30 May 2007 06:01:32 -0400 Received: from xsmtp0.ethz.ch ([82.130.70.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKzj-0001Ae-VH for mip4@ietf.org; Wed, 30 May 2007 06:01:32 -0400 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 May 2007 12:01:31 +0200 Received: from vs5.inf.ethz.ch ([129.132.130.184]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 May 2007 12:01:30 +0200 Received: by vs5.inf.ethz.ch (sSMTP sendmail emulation); Wed, 30 May 2007 12:01:23 +0200 Date: Wed, 30 May 2007 12:01:23 +0200 From: Marc Langheinrich - IOT 2008 To: mip4@ietf.org Message-ID: <20070530100123.GA25757@inf.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 30 May 2007 10:01:30.0106 (UTC) FILETIME=[7E9DE5A0:01C7A2A1] X-Spam-Score: 0.6 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-Mailman-Approved-At: Thu, 31 May 2007 12:43:34 -0400 Subject: [Mip4] CFP: Internet of Things 2008 - Preliminary Announcement and Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Internet of Things 2008 List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org apologies if you receive multiple copies. see signature to unsubscribe. ----------------------------------------------------------------- ********************************************** Preliminary Announcement and Call for Papers ********************************************** INTERNET OF THINGS 2008 International Conference for Industry and Academia March 26-28, 2008, Zurich (Switzerland) Organized by ETH Zurich, University St.Gallen, and MIT www.internet-of-things-2008.org The term "Internet of Things" has come to describe a number of technologies and research disciplines that enable the Internet to reach out into the real world of physical objects. Technologies like RFID, short-range wireless communications, real-time locali- zation, and sensor networks are now becoming increasingly common, bringing the Internet of Things into commercial use. They fore- shadow an exciting future that closely interlinks the physical world and cyberspace -- a development that is highly relevant to researchers, corporations, and individuals. This conference will be the first that brings leading researchers and practitioners from both academia and industry together to facilitate sharing of applications, research results, and know- ledge. The three-day event will feature keynotes from industrial and academic visionaries, technical presentations of cutting-edge research, reports on the user-experience from seasoned practi- tioners, panel discussions on hot topics, poster sessions summa- rizing late-breaking results, and hands-on demos of current technology. Be sure to mark your calendars if you want to know more about: * Novel services and applications in an Internet of Things (IOT) * Emerging IOT business models and process changes * Communication systems and network architectures for the IOT * Technologies and concepts for embedding sensing, actuation, communication, and computation into networked things * Experience reports from the introduction and operation of net- worked things in areas such as healthcare, logistics & transport * Security & privacy aspects of IOT infrastructures & applications For more information and an advanced agenda, visit www.internet-of-things-2008.org Scientific contributions are expected to be published in the Springer LNCS series. We are particularly interested in work addressing real-world implementation and deployment issues. For submission instructions and further information, see the full call at: www.internet-of-things-2008.org/cfp/ ------------------------------------------------------------------ Important Dates: - Sep. 15, 2007 Technical papers submissions deadline - Oct. 20, 2007 Workshop/tutorials/demo proposals due - Nov. 15, 2007 Technical papers acceptance notifications - Nov. 30, 2007 Workshop/tutorials/demo acceptance notification - Dec. 10, 2007 Technical papers camera-ready version due ------------------------------------------------------------------ General Chairs: --------------- * Elgar Fleisch, ETH Zurich & University St.Gallen * Friedemann Mattern, ETH Zurich * Sanjay Sarma, MIT Program Chairs: --------------- * Christian Floerkemeier, MIT * Marc Langheinrich, ETH Zurich Workshops and Demos Chair: -------------------------- * Florian Michahelles, ETH Zurich Industrial Program Chair: ------------------------- * Ulrich Eisert, SAP Research Scientific Program Committee ---------------------------- Karl Aberer (EPFL), Manfred Aigner (Technical Univ. Graz), Michael Beigl (Braunschweig Univ.), Alastair Beresford (Cambridge Univ.), Peter Cole (Univ. of Adelaide), Nigel Davies (Lancaster Univ.), Jean-Pierre Émond (Univ. of Florida), Alois Ferscha (Univ. of Linz), Elgar Fleisch (ETH Zurich & Univ. St.Gallen), Anatole Gershman (CMU), Bill C. Hardgrave (Univ. of Arkansas), Mark Harrison (Cambridge Univ.), Ralf Guido Herrtwich (DaimlerChysler), Lutz Heuser (SAP Research), Lorenz Hilty (Univ. of St.Gallen), Thomas Hof-mann (Google Labs Zurich), Michael ten Hompel (FHG Logistik), Ryo Imura (Hitachi & Univ. of Tokyo), Sozo Inoue (Kyushu Univ.), Yuri Ivanov (MERL), Günter Karjoth (IBM Research Zurich), Wolfgang Kellerer (NTT DoCoMo European Research Labs), Daeyoung Kim (ICU), Kwangjo Kim (ICU), Tim Kindberg (HP Labs Bristol), Gerd Kortuem (Lancaster Univ.), Anthony LaMarca (Intel Research Seattle), Hau Lee (Stanford Univ.), Friedemann Mattern (ETH Zurich), Hao Min (Fudan Univ.), Jin Mitsugi (Keio Univ.), Paul Moskowitz (IBM Watson Research Center), Jun Murai (Keio Univ.), Osamu Nakamura (Keio Univ.), Paddy Nixon (Univ. College Dublin), Thomas Odenwald (SAP Research), Joe Paradiso (MIT), Aaron Quigley (Univ. College Dublin), Hartmut Raffler (Siemens Corporate Technology), Matt Reynolds (Georgia Tech), Antonio Rizzi (Univ. Parma), Sanjay Sarma (MIT), Albrecht Schmidt (Fraunhofer IAIS & B-IT Bonn), Bernd Scholz-Reiter (Univ. of Bremen), James Scott (Microsoft Research Cambridge), Ted Selker (MIT), Andrea Soppera (BT Research), Sarah Spiekerman (Humboldt Univ. Berlin), Frédéric Thiesse (Univ. of St.Gallen), Khai Truong (Univ. of Toronto), Kristof Van Laerhoven (Darmstadt Univ. of Technology), Harald Vogt (SAP Research), Wolfgang Wahlster (DFKI), Kamin Whitehouse (Univ. of Virginia), John Williams (MIT). -- For more information see: www.internet-of-things-2008.org Questions? Want no e-mails? Contact us: -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/