From mip4-bounces@ietf.org Thu Jan 04 10:05:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2U9I-0005PA-13; Thu, 04 Jan 2007 10:04:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ShB-0005TU-Uj for mip4@ietf.org; Thu, 04 Jan 2007 08:31:49 -0500 Received: from posta.dis.uniroma1.it ([151.100.59.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ShA-0004He-6a for mip4@ietf.org; Thu, 04 Jan 2007 08:31:49 -0500 Received: from localhost (localhost [127.0.0.1]) by posta.dis.uniroma1.it (Postfix) with ESMTP id 72B1ED38E0 for ; Thu, 4 Jan 2007 14:31:47 +0100 (CET) Received: from posta.dis.uniroma1.it ([127.0.0.1]) by localhost (posta [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18381-20; Thu, 4 Jan 2007 14:31:47 +0100 (CET) Received: from [82.59.196.249] (disdmz.dis.uniroma1.it [151.100.59.80]) by posta.dis.uniroma1.it (Postfix) with ESMTP id 3068DD341D; Thu, 4 Jan 2007 14:31:47 +0100 (CET) Mime-Version: 1.0 Message-Id: Date: Thu, 4 Jan 2007 14:31:23 +0100 To: mip4@ietf.org From: Camil Demetrescu Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at dis.uniroma1.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Thu, 04 Jan 2007 10:04:54 -0500 Cc: demetres@dis.uniroma1.it Subject: [Mip4] WEA 2007 Second CFP 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 WEA 2007 6th International Workshop on Experimental Algorithms http://www.dis.uniroma1.it/~wea07 June 6-9, 2007 School of Engineering University of Rome "La Sapienza", Rome, Italy SECOND CALL FOR PAPERS SUBMISSION DEADLINE: January 20, 2007 GENERAL INFORMATION WEA is an international forum for researchers in the area of experimental evaluation and engineering of algorithms, as well as in various aspects of computational optimization and its applications. The preceding Workshops were held in Riga (Latvia, 2001), Ascona (Switzerland, 2003), Angra dos Reis (Brazil, 2004), Santorini (Greece, 2005), and Menorca Island (Spain, 2006). TOPICS OF INTEREST Contributions solicited cover a variety of topics including but not limited to: - Algorithm Engineering - Algorithmic Libraries - Algorithmic Mechanism Design - Algorithms for Memory Hierarchies - Approximation Techniques - Branch and Bound Algorithms - Combinatorial Structures and Graphs - Combinatorial and Irregular Problems - Communication Networks - Complex Networks - Computational Biology - Computational Geometry - Computational Learning Theory - Computational Optimization - Computer Systems - Cryptography and Security - Data Streams - Data Structures - Distributed Algorithms - Evaluation of Algorithms for Realistic Environments - Graph Drawing - Heuristics for Combinatorial Optimization - Implementation, Testing, Evaluation, and Fine-tuning - Information Retrieval - Integer Programming - Logistics and Operations Management - Machine Learning and Data Mining - Mathematical Programming - Metaheuristic Methodologies - Network Analysis - Novel Applications of Algorithms in Other Disciplines - On-line Problems - Parallel Algorithms and Computing - Railway Optimization using Algorithmic Methods - Randomized Techniques - Robotics - Semidefinite Programming - Simulation - Software Repositories and Platforms for using Algorithms - Telecommunications and Networking - World Wide Web Algorithms IMPORTANT DATES Submission deadline: January 20, 2007 (11:59 PM PST) Author notification: March 7, 2007 Camera ready due: March 21, 2007 Conference: June 6-9, 2007 PLENARY SPEAKERS Corinna Cortes (Google) Peter Sanders (U. Karlsruhe) Maria J. Serna (T.U. of Catalonia) PROCEEDINGS Accepted papers will appear in the WEA 2007 Proceedings published by Springer Verlag in the LNCS series. SPECIAL ISSUE Selected papers from WEA 2007 will be considered for a Special Issue of the ACM Journal of Experimental Algorithmics (JEA, http://www.jea.acm.org/). SUBMISSION Authors are invited to submit high-quality manuscripts reporting original unpublished research and recent developments in the topics related to the Workshop. Simultaneous submission to other conferences or workshops with published proceedings is not allowed. All papers will be peer reviewed and comments will be provided to the authors. Submission website and further details: http://www.dis.uniroma1.it/~wea07 PROGRAM COMMITTEE Susanne Albers (U. Freiburg) Eric Angel (U. Evry Val D'Essonne) Giorgio Ausiello (U. Roma "La Sapienza") Ricardo Baeza-Yates (Yahoo! Research) Jon Bentley (Avaya Labs Research) Adam Buchsbaum (AT&T Labs--Research) Ioannis Chatzigiannakis (U. Patras) Camil Demetrescu (U. Roma "La Sapienza") (chair) Cid de Souza (U. Campinas) Rolf Fagerberg (U. Sourthern Denmark, Odense) Rudolf Fleischer (Fudan U. Shanghai) Monika Henzinger (Google & EPFL) Dorit S. Hochbaum (U. California at Berkeley) Michel Gendreau (U. Montr=E9al) Giuseppe F. Italiano (U. Roma "Tor Vergata") Riko Jacob (ETH Zurich) Richard Ladner (U. Washington) Kurt Mehlhorn (MPII Saarbruecken) Bernard Moret (EPFL) S. Muthukrishnan (Google) Petra Mutzel (U. Dortmund) Giri Narasimhan (Florida International U.) Robert Sedgewick (Princeton U.) Thomas Stuetzle (U. Libre de Bruxelles) Jan Vahrenhold (U. Dortmund) Renato Werneck (Microsoft Research Silicon Valley) Norbert Zeh (Dalhousie U., Halifax) STEERING COMMITTEE Edoardo Amaldi (Politecnico di Milano) David A. Bader (Georgia Tech) Josep Diaz (T.U. Catalonia) Giuseppe F. Italiano (U. Roma "Tor Vergata") David Johnson (AT&T Labs--Research) Klaus Jansen (U. Kiel) Kurt Mehlhorn (MPII Saarbruecken) Ian Munro (U. Waterloo) Sotiris Nikoletseas (U. Patras & CTI) Jose Rolim (U. Geneva) (chair) Pavlos Spirakis (U. Patras & CTI) ORGANIZING COMMITTEE Vincenzo Bonifaci (U. Roma "La Sapienza") Saverio Caminiti (U. Roma "La Sapienza") =46abio Dellutri (U. Roma "Tor Vergata") Camil Demetrescu (U. Roma "La Sapienza") Irene Finocchi (U. Roma "La Sapienza") Luigi Laura (U. Roma "La Sapienza") Andrea Vitaletti (U. Roma "La Sapienza") CONTACT Camil Demetrescu Dipartimento di Informatica e Sistemistica Universit=E0 di Roma "La Sapienza" Via Salaria, 113, II piano, 00198 ROMA, ITALY Tel.: (+39) 06 4991 8457, Fax: (+39) 06 85300849 Email: demetres [at] dis [dot] uniroma1 [dot] it -- ________________________________________________________oo_____ Camil Demetrescu, Ph.D. - http://www.dis.uniroma1.it/~demetres Dept. Computer and System Sciences, Univ. of Rome "La Sapienza" Via Salaria, 113 - 00198 Roma, Italy, ph. +39-06-4991-8457 -- 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 Jan 04 15:50:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXv-0002eD-Nn; Thu, 04 Jan 2007 15:50:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXm-0002Ua-EO; Thu, 04 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2ZXl-0000oM-3H; Thu, 04 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BE04F176A5; Thu, 4 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2ZXG-0000ei-BN; Thu, 04 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-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 : Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Author(s) : V. Devarapalli, P. Eronen Filename : draft-ietf-mip4-mobike-connectivity-02.txt Pages : 15 Date : 2007-1-4 Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-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-mobike-connectivity-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-mobike-connectivity-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-1-4143623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-mobike-connectivity-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-mobike-connectivity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-4143623.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 Thu Jan 04 17:03:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2agM-0005pN-0u; Thu, 04 Jan 2007 17:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2agL-0005pI-2P for mip4@ietf.org; Thu, 04 Jan 2007 17:03:29 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2agJ-0006Jb-PO for mip4@ietf.org; Thu, 04 Jan 2007 17:03:29 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1167948206!18443858!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27087 invoked from network); 4 Jan 2007 22:03:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 4 Jan 2007 22:03:26 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l04M3QFF009513 for ; Thu, 4 Jan 2007 15:03:26 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l04M3Q4k008123 for ; Thu, 4 Jan 2007 16:03:26 -0600 (CST) 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-mobike-connectivity-02.txt Date: Thu, 4 Jan 2007 17:03:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-02.txt Thread-Index: AccwQhtbzgirad/0RaKhGMI1FUnJcgACeCfg From: "McCann Peter-A001034" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 for submitting a new version. Can the people who raised issues please check this version to see that they were addressed? If there are no further issues we will proceed to send this version up 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 : Secure Connectivity and Mobility using Mobile IPv4 and > MOBIKE Author(s) : V. Devarapalli, P. Eronen > Filename : draft-ietf-mip4-mobike-connectivity-02.txt > Pages : 15 > Date : 2007-1-4 >=20 > Enterprise users require mobility and secure connectivity when they > roam and connect to the services offered in the enterprise. Secure > connectivity is required when the user connects to the enterprise > from an untrusted network. Mobility is beneficial when the user > moves, either inside or outside the enterprise network, and > acquires a new IP address. This document describes a solution > using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to > provide secure connectivity and mobility. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity- 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-mobike-connectivity-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-mobike-connectivity-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 Thu Jan 04 17:46:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bLw-0004Oa-4Y; Thu, 04 Jan 2007 17:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bLu-0004O3-1X for mip4@ietf.org; Thu, 04 Jan 2007 17:46:26 -0500 Received: from web60317.mail.yahoo.com ([209.73.178.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2bLr-00066R-Hv for mip4@ietf.org; Thu, 04 Jan 2007 17:46:26 -0500 Received: (qmail 38365 invoked by uid 60001); 4 Jan 2007 22:46:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=r4SPTUiS9JBVF3zh9XzmIMEGkQ6GRcl+kTUaM/pHOaj4pAiCdoF0knPXIBQxNRui1VFoSXZTkfn+X92e6Y/I1OEj0Lp9U7MOPBqYGMbOVPrN8fZwfP0Be0Eq0ul+Rl6czfA53fe4rqQOSr8F/Hpj4ORo35kLjzDx2kG1NJLOtEM= ; Message-ID: <20070104224623.38363.qmail@web60317.mail.yahoo.com> Received: from [12.129.211.52] by web60317.mail.yahoo.com via HTTP; Thu, 04 Jan 2007 14:46:23 PST Date: Thu, 4 Jan 2007 14:46:23 -0800 (PST) From: Behcet Sarikaya To: mip4@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Mip4] DHCP vs FA X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757034916==" Errors-To: mip4-bounces@ietf.org --===============0757034916== Content-Type: multipart/alternative; boundary="0-243297926-1167950783=:38353" --0-243297926-1167950783=:38353 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi all,=0A I was reading RFC 3344 and noticed that it is not clear on the = choice between the co-located care-of address mode using DHCP and FA provid= ed care-of address mode of operation. If MN does get a =0Aco-located care-o= f address and there is an FA what happens then?=0AIf this had been discusse= d in the past, I'll appreciate if someone can summarize the conclusion.=0A= =0ARegards,=0A=0A--behcet=0A=0A----- Original Message ----=0AFrom: McCann P= eter-A001034 =0ATo: mip4@ietf.org=0ASent: Thursda= y, January 4, 2007 4:03:26 PM=0ASubject: RE: [Mip4] I-D ACTION:draft-ietf-m= ip4-mobike-connectivity-02.txt=0A=0A=0AThanks Vijay for submitting a new ve= rsion.=0A=0ACan the people who raised issues please check this version=0Ato= see that they were addressed?=0A=0AIf there are no further issues we will = proceed to send this=0Aversion up to the IESG.=0A=0A-Pete=0A=0AInternet-Dra= fts@ietf.org wrote:=0A> A New Internet-Draft is available from the on-line = Internet-Drafts=0A> directories. =0A> This draft is a work item of the Mobi= lity for IPv4 Working Group of=0A> the IETF. =0A> =0A> Title : S= ecure Connectivity and Mobility using Mobile=0AIPv4 and=0A> MOBIKE Auth= or(s) : V. Devarapalli, P. Eronen=0A> Filename : draft-ietf-mip4-= mobike-connectivity-02.txt=0A> Pages : 15=0A> Date : = 2007-1-4=0A> =0A> Enterprise users require mobility and secure connectivity= when they=0A> roam and connect to the services offered in the enterpris= e. Secure=0A> connectivity is required when the user connects to the en= terprise=0A> from an untrusted network. Mobility is beneficial when the= user=0A> moves, either inside or outside the enterprise network, and=0A= > acquires a new IP address. This document describes a solution=0A> = using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to=0A> provi= de secure connectivity and mobility.=0A> =0A> A URL for this Internet-Draft= is:=0A>=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-conne= ctivity-=0A02.txt=0A> =0A> To remove yourself from the I-D Announcement lis= t, send a message to=0A> i-d-announce-request@ietf.org with the word unsubs= cribe in the body=0A> of the message. =0A> You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce=0A> to change your subscription set= tings.=0A> =0A> Internet-Drafts are also available by anonymous FTP. Login = with the=0A> username "anonymous" and a password of your e-mail address. Af= ter=0A> logging in, type "cd internet-drafts" and then "get=0A> draft-ietf-= mip4-mobike-connectivity-02.txt". =0A> =0A> A list of Internet-Drafts dir= ectories can be found in=0A> http://www.ietf.org/shadow.html or=0A> ftp://f= tp.ietf.org/ietf/1shadow-sites.txt =0A> =0A> Internet-Drafts can also be o= btained by e-mail.=0A> =0A> Send a message to:=0A> mailserv@ietf.org.= =0A> In the body type:=0A> "FILE=0A/internet-drafts/draft-ietf-mip4-mob= ike-connectivity-02.txt".=0A> =0A> NOTE: The mail server at ietf.org can= return the document in=0A> MIME-encoded form by using the "mpack" util= ity. To use this=0A> feature, insert the command "ENCODING mime" befor= e the "FILE"=0A> command. To decode the response(s), you will need "mu= npack" or=0A> a MIME-compliant mail reader. Different MIME-compliant m= ail=0Areaders=0A> exhibit different behavior, especially when dealing w= ith=0A> "multipart" MIME messages (i.e. documents which have been split= =0A> up into multiple messages), so check your local documentation on= =0A> how to manipulate these messages.=0A> =0A> Below is the data which= will enable a MIME compliant mail reader=0A> implementation to automatical= ly retrieve the ASCII version of the=0A> Internet-Draft. =0A=0A=0A--=0AMip= 4 mailing list: Mip4@ietf.org=0A Web interface: https://www1.ietf.org/ma= ilman/listinfo/mip4=0A Charter page: http://www.ietf.org/html.charters/= mip4-charter.html=0ASupplemental site: http://www.mip4.org/ --0-243297926-1167950783=:38353 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
  I was reading RF= C 3344 and noticed that it is not clear on the choice between the co-locate= d care-of address mode using DHCP and FA provided care-of address mode of o= peration. If MN does get a
co-located care-of address and there is an F= A what happens then?
=0A
If this had been discussed in the pa= st, I'll appreciate if someone can summarize the conclusion.
=0A
 
=0A
Regards,
=0A
 
=0A--behcet
=0A
----- Original Message ----
From: M= cCann Peter-A001034 <pete.mccann@motorola.com>
To: mip4@ietf.orgSent: Thursday, January 4, 2007 4:03:26 PM
Subject: RE: [Mip4] I-D ACT= ION:draft-ietf-mip4-mobike-connectivity-02.txt

=0A
Thanks Vijay = for submitting a new version.

Can the people who raised issues pleas= e check this version
to see that they were addressed?

If there ar= e no further issues we will proceed to send this
version up to the IESG.=

-Pete

Internet-Drafts@ietf.org wrote:
> A New Internet= -Draft is available from the on-line Internet-Drafts
> directories. <= BR>> This draft is a work item of the Mobility for IPv4 Working Group of=
> the IETF.
>
>     Title &nb= sp;      : Secure Connectivity and Mobility u= sing Mobile
IPv4 and
>     MOBIKE Author(s)&nb= sp;   : V. Devarapalli, P. Eronen
>    =  Filename    : draft-ietf-mip4-mobike-connectivity= -02.txt
>     Pages     =    : 15
>     Date       &nbs= p;: 2007-1-4
>
> Enterprise users require mobility and secure = connectivity when they
>    roam and connect to t= he services offered in the enterprise.  Secure
>  = ;  connectivity is required when the user connects to the enterpr= ise
>    from an untrusted network.  Mo= bility is beneficial when the user
>    moves, ei= ther inside or outside the enterprise network, and
>   = ; acquires a new IP address.  This document describes a solu= tion
>    using Mobile IPv4 and mobility extensio= ns to IKEv2 (MOBIKE) to
>    provide secure conne= ctivity and mobility.
>
> A URL for this Internet-Draft is:>
http://www.ietf.org/internet-drafts/draft-ietf-mip4-= mobike-connectivity-
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/listi= nfo/I-D-announce
> to change your subscription settings.
> =
> Internet-Drafts are also available by anonymous FTP. Login with th= e
> username "anonymous" and a password of your e-mail address. After=
> logging in, type "cd internet-drafts" and then "get
> draft-= ietf-mip4-mobike-connectivity-02.txt".  
>
> A list= of Internet-Drafts directories can be found in
> http://www.ietf.o= rg/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt&nbs= p; 
>
> Internet-Drafts can also be obtained by e-mail.>
> Send a message to:
>     mailserv= @ietf.org.
> In the body type:
>     "FILE<= BR>/internet-drafts/draft-ietf-mip4-mobike-connectivity-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"
> &nbs= p;   command.  To decode the response(s), you will= need "munpack" or
>     a MIME-compliant mail re= ader.  Different MIME-compliant mail
readers
>     exhibit different behavior, especially when dealin= g with
>     "multipart" MIME messages (i.e. docu= ments which have been split
>     up into multipl= e 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 a= utomatically retrieve the ASCII version of the
> Internet-Draft. = ; 


--
Mip4 mailing list: Mip4@ietf.org
  &n= bsp; Web interface: https://www1.ietf.org/mailman/listinfo/mip4
&n= bsp;    Charter page: http://www.ietf.org/html.charters= /mip4-charter.html
Supplemental site: http://www.mip4.org/
=0A

--0-243297926-1167950783=:38353-- --===============0757034916== 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/ --===============0757034916==-- From mip4-bounces@ietf.org Thu Jan 04 17:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bQb-00015h-0G; Thu, 04 Jan 2007 17:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bQZ-0000zZ-KF for mip4@ietf.org; Thu, 04 Jan 2007 17:51:15 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bQY-0006mn-4x for mip4@ietf.org; Thu, 04 Jan 2007 17:51:15 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2007 14:51:14 -0800 X-IronPort-AV: i="4.12,240,1165219200"; d="scan'208"; a="455265038:sNHT48535392" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l04MpDpo023702; Thu, 4 Jan 2007 14:51:13 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l04MpD05010180; Thu, 4 Jan 2007 14:51:13 -0800 (PST) Date: Thu, 4 Jan 2007 14:51:13 -0800 (PST) From: Sri Gundavelli To: Behcet Sarikaya Subject: Re: [Mip4] DHCP vs FA In-Reply-To: <20070104224623.38363.qmail@web60317.mail.yahoo.com> Message-ID: References: <20070104224623.38363.qmail@web60317.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4151; t=1167951073; x=1168815073; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip4]=20DHCP=20vs=20FA |Sender:=20; bh=flHAZ4p5BSv5sedjPGxh9zfgcld0Ox4UsvZU9YbqvOM=; b=0aPEnzp31E0jb5QA6KazleWaksya6Ovu1ra63JM362j1prMrRUhIeBG0+BXNP+CoJ2CNHufZ 5D15Dj8Ex9rtRlcfIxK6aEjxeMhjtmHHvLg/B3izPWOBjoQ8Il4FDWNi; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 If the "R" bit is the agent advertisement is not set, it is up to the mobile to decide on the FA-COA or CCOA mode of registration. Sri On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > Hi all, > I was reading RFC 3344 and noticed that it is not clear on the choice between the co-located care-of address mode using DHCP and FA provided care-of address mode of operation. If MN does get a > co-located care-of address and there is an FA what happens then? > If this had been discussed in the past, I'll appreciate if someone can summarize the conclusion. > > Regards, > > --behcet > > ----- Original Message ---- > From: McCann Peter-A001034 > To: mip4@ietf.org > Sent: Thursday, January 4, 2007 4:03:26 PM > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-02.txt > > > Thanks Vijay for submitting a new version. > > Can the people who raised issues please check this version > to see that they were addressed? > > If there are no further issues we will proceed to send this > version up to the IESG. > > -Pete > > Internet-Drafts@ietf.org wrote: >> 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 : Secure Connectivity and Mobility using Mobile > IPv4 and >> MOBIKE Author(s) : V. Devarapalli, P. Eronen >> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >> Pages : 15 >> Date : 2007-1-4 >> >> Enterprise users require mobility and secure connectivity when they >> roam and connect to the services offered in the enterprise. Secure >> connectivity is required when the user connects to the enterprise >> from an untrusted network. Mobility is beneficial when the user >> moves, either inside or outside the enterprise network, and >> acquires a new IP address. This document describes a solution >> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >> provide secure connectivity and mobility. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity- > 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-mobike-connectivity-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-mobike-connectivity-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. > > > -- > 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 Jan 05 13:18:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2te3-0007CY-O3; Fri, 05 Jan 2007 13:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2te3-0007CT-5B for mip4@ietf.org; Fri, 05 Jan 2007 13:18:23 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tdy-0001Kx-Ki for mip4@ietf.org; Fri, 05 Jan 2007 13:18:23 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2007 10:18:18 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208"; a="455430865:sNHT63178540" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l05IIIhq002146; Fri, 5 Jan 2007 10:18:18 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l05IIHUg009984; Fri, 5 Jan 2007 10:18:17 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:18:17 -0800 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] DHCP vs FA Date: Fri, 5 Jan 2007 10:18:17 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52031BBE45@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] DHCP vs FA Thread-Index: AccwUuTQb/qQeMsaQ+KxEfhnF2hjPQAoumMw From: "Kent Leung \(kleung\)" To: "Sri Gundavelli \(sgundave\)" , "Behcet Sarikaya" X-OriginalArrivalTime: 05 Jan 2007 18:18:17.0682 (UTC) FILETIME=[DF6B4B20:01C730F5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4718; t=1168021098; x=1168885098; c=relaxed/simple; s=sjdkim1002; 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]=20DHCP=20vs=20FA |Sender:=20; bh=VoY5hRomSNJkMT2rKVObFX3z7vhD6RjUJiDLJXifCas=; b=LtyiE4AjxPqE/ZzO/TOKQ483WbZw0601yIwsGPyRsYmm04mYNAQb9B0LBkmX1P2Z3t1U1mO+ f+KV3j/Rp2wBr50twC6RLk3VK3T02ER0qTxhb31i2lQm16jxx0SvebaM; Authentication-Results: sj-dkim-1; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 Right. Though typically the MIP client tend to favor the FA CoA mode of operation in this case. Kent=20 -----Original Message----- From: Sri Gundavelli (sgundave)=20 Sent: Thursday, January 04, 2007 2:51 PM To: Behcet Sarikaya Cc: mip4@ietf.org Subject: Re: [Mip4] DHCP vs FA If the "R" bit is the agent advertisement is not set, it is up to the mobile to decide on the FA-COA or CCOA mode of registration. Sri On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > Hi all, > I was reading RFC 3344 and noticed that it is not clear on the choice > between the co-located care-of address mode using DHCP and FA provided care-of address mode of operation. If MN does get a co-located care-of address and there is an FA what happens then? > If this had been discussed in the past, I'll appreciate if someone can summarize the conclusion. > > Regards, > > --behcet > > ----- Original Message ---- > From: McCann Peter-A001034 > To: mip4@ietf.org > Sent: Thursday, January 4, 2007 4:03:26 PM > Subject: RE: [Mip4] I-D=20 > ACTION:draft-ietf-mip4-mobike-connectivity-02.txt > > > Thanks Vijay for submitting a new version. > > Can the people who raised issues please check this version to see that > they were addressed? > > If there are no further issues we will proceed to send this version up > 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 Working Group of=20 >> the IETF. >> >> Title : Secure Connectivity and Mobility using Mobile > IPv4 and >> MOBIKE Author(s) : V. Devarapalli, P. Eronen >> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >> Pages : 15 >> Date : 2007-1-4 >> >> Enterprise users require mobility and secure connectivity when they >> roam and connect to the services offered in the enterprise. Secure >> connectivity is required when the user connects to the enterprise >> from an untrusted network. Mobility is beneficial when the user >> moves, either inside or outside the enterprise network, and >> acquires a new IP address. This document describes a solution >> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >> provide secure connectivity and mobility. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivit > y- > 02.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=20 >> of the message. >> You can also visit=20 >> 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=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-mobike-connectivity-02.txt". >> >> 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 >> >> 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-mobike-connectivity-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=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/ -- 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 Jan 08 00:51:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nPS-0008H5-Rp; Mon, 08 Jan 2007 00:51:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nPR-0008Gq-E2 for mip4@ietf.org; Mon, 08 Jan 2007 00:51:01 -0500 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3nPO-0005sU-25 for mip4@ietf.org; Mon, 08 Jan 2007 00:51:01 -0500 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 00:49:22 -0500 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" Subject: RE: [Mip4] DHCP vs FA Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jan 2007 11:19:16 +0530 Message-ID: <653F3CF58193744C9DE59C217C072B58AB4CB3@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] DHCP vs FA Thread-Index: AccwUuTQb/qQeMsaQ+KxEfhnF2hjPQAoumMwAHyCOiA= From: "Arun SG" To: "Kent Leung \(kleung\)" , "Sri Gundavelli \(sgundave\)" , "Behcet Sarikaya" X-OriginalArrivalTime: 08 Jan 2007 05:49:22.0728 (UTC) FILETIME=[BF56B280:01C732E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Just curious about the probable reason for the typical [or default] behaviour of the MIP client - why it prefers FA CoA mode over Ccoa, since if FA does not mandate registration, the MIP Client might very well register directly at HA. Is it to do with accounting at FA or something different?=20 Thanks, Arun -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Friday, January 05, 2007 11:48 PM To: Sri Gundavelli (sgundave); Behcet Sarikaya Cc: mip4@ietf.org Subject: RE: [Mip4] DHCP vs FA Right. Though typically the MIP client tend to favor the FA CoA mode of operation in this case. Kent=20 -----Original Message----- From: Sri Gundavelli (sgundave) Sent: Thursday, January 04, 2007 2:51 PM To: Behcet Sarikaya Cc: mip4@ietf.org Subject: Re: [Mip4] DHCP vs FA If the "R" bit is the agent advertisement is not set, it is up to the mobile to decide on the FA-COA or CCOA mode of registration. Sri On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > Hi all, > I was reading RFC 3344 and noticed that it is not clear on the choice > between the co-located care-of address mode using DHCP and FA provided care-of address mode of operation. If MN does get a co-located care-of address and there is an FA what happens then? > If this had been discussed in the past, I'll appreciate if someone can summarize the conclusion. > > Regards, > > --behcet > > ----- Original Message ---- > From: McCann Peter-A001034 > To: mip4@ietf.org > Sent: Thursday, January 4, 2007 4:03:26 PM > Subject: RE: [Mip4] I-D=20 > ACTION:draft-ietf-mip4-mobike-connectivity-02.txt > > > Thanks Vijay for submitting a new version. > > Can the people who raised issues please check this version to see that > they were addressed? > > If there are no further issues we will proceed to send this version up > 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 Working Group of=20 >> the IETF. >> >> Title : Secure Connectivity and Mobility using Mobile > IPv4 and >> MOBIKE Author(s) : V. Devarapalli, P. Eronen >> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >> Pages : 15 >> Date : 2007-1-4 >> >> Enterprise users require mobility and secure connectivity when they >> roam and connect to the services offered in the enterprise. Secure >> connectivity is required when the user connects to the enterprise >> from an untrusted network. Mobility is beneficial when the user >> moves, either inside or outside the enterprise network, and >> acquires a new IP address. This document describes a solution >> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >> provide secure connectivity and mobility. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivit > y- > 02.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=20 >> of the message. >> You can also visit=20 >> 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=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-mobike-connectivity-02.txt". >> >> 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 >> >> 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-mobike-connectivity-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=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/ -- 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/ --=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 Jan 08 01:07:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nf5-0005zM-B9; Mon, 08 Jan 2007 01:07:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nf3-0005y3-Id for mip4@ietf.org; Mon, 08 Jan 2007 01:07:09 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3nf1-00085i-VC for mip4@ietf.org; Mon, 08 Jan 2007 01:07:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2007 22:07:07 -0800 X-IronPort-AV: i="4.13,158,1167638400"; d="scan'208"; a="99036878:sNHT50578119" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l08677eA006118; Sun, 7 Jan 2007 22:07:07 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l08677ZI014883; Sun, 7 Jan 2007 22:07:07 -0800 (PST) Date: Sun, 7 Jan 2007 22:07:07 -0800 (PST) From: Sri Gundavelli To: Arun SG Subject: RE: [Mip4] DHCP vs FA In-Reply-To: <653F3CF58193744C9DE59C217C072B58AB4CB3@nilgiri.india.wirelessworld.airvananet.com> Message-ID: References: <653F3CF58193744C9DE59C217C072B58AB4CB3@nilgiri.india.wirelessworld.airvananet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5869; t=1168236427; x=1169100427; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip4]=20DHCP=20vs=20FA |Sender:=20; bh=Jq0nRRHa2ta5DrVwmXdLn7MT6NgYH/ZiidGNBCNah74=; b=Jg2ku1onTprngA/LnKlmq0dTNTCiq4iFypdLg0zfkLuX1m/96EwSYvibvDKBriHnXW7LxHFv 2izeO1VxXPiDSBxe2p1lFcjwQekDpAwD1+KqpWIZMbDIAoURDdhhh8dI; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Behcet Sarikaya 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 For CCOA mode, the home agent needs to have a unique tunnel for each mobile and that has a bearing on the resources when compared to the FA-COA mode. This could be one other reason. Sri On Mon, 8 Jan 2007, Arun SG wrote: > Just curious about the probable reason for the typical [or default] > behaviour of the MIP client - why it prefers FA CoA mode over Ccoa, > since if FA does not mandate registration, the MIP Client might very > well register directly at HA. Is it to do with accounting at FA or > something different? > > Thanks, > Arun > > > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, January 05, 2007 11:48 PM > To: Sri Gundavelli (sgundave); Behcet Sarikaya > Cc: mip4@ietf.org > Subject: RE: [Mip4] DHCP vs FA > > Right. Though typically the MIP client tend to favor the FA CoA mode of > operation in this case. > > Kent > > -----Original Message----- > From: Sri Gundavelli (sgundave) > Sent: Thursday, January 04, 2007 2:51 PM > To: Behcet Sarikaya > Cc: mip4@ietf.org > Subject: Re: [Mip4] DHCP vs FA > > > If the "R" bit is the agent advertisement is not set, it is up to the > mobile to decide on the FA-COA or CCOA mode of registration. > > Sri > > On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > >> Hi all, >> I was reading RFC 3344 and noticed that it is not clear on the choice > >> between the co-located care-of address mode using DHCP and FA provided > care-of address mode of operation. If MN does get a co-located care-of > address and there is an FA what happens then? >> If this had been discussed in the past, I'll appreciate if someone can > summarize the conclusion. >> >> Regards, >> >> --behcet >> >> ----- Original Message ---- >> From: McCann Peter-A001034 >> To: mip4@ietf.org >> Sent: Thursday, January 4, 2007 4:03:26 PM >> Subject: RE: [Mip4] I-D >> ACTION:draft-ietf-mip4-mobike-connectivity-02.txt >> >> >> Thanks Vijay for submitting a new version. >> >> Can the people who raised issues please check this version to see that > >> they were addressed? >> >> If there are no further issues we will proceed to send this version up > >> to the IESG. >> >> -Pete >> >> Internet-Drafts@ietf.org wrote: >>> 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 : Secure Connectivity and Mobility using Mobile >> IPv4 and >>> MOBIKE Author(s) : V. Devarapalli, P. Eronen >>> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >>> Pages : 15 >>> Date : 2007-1-4 >>> >>> Enterprise users require mobility and secure connectivity when they >>> roam and connect to the services offered in the enterprise. > Secure >>> connectivity is required when the user connects to the enterprise >>> from an untrusted network. Mobility is beneficial when the user >>> moves, either inside or outside the enterprise network, and >>> acquires a new IP address. This document describes a solution >>> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >>> provide secure connectivity and mobility. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivit >> y- >> 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-mobike-connectivity-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-mobike-connectivity-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. >> >> >> -- >> 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/ > > -- > 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 Jan 08 04:46:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r5a-0003Wu-Ct; Mon, 08 Jan 2007 04:46:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r5Y-0003Vm-QA for mip4@ietf.org; Mon, 08 Jan 2007 04:46:44 -0500 Received: from cassius.ee.usyd.edu.au ([129.78.13.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3r5W-0002O4-Uy for mip4@ietf.org; Mon, 08 Jan 2007 04:46:44 -0500 Received: from ee.usyd.edu.au (localhost [127.0.0.1]) by cassius.ee.usyd.edu.au (8.13.6/8.13.6) with SMTP id l089i4bu004382; Mon, 8 Jan 2007 20:44:05 +1100 (EST) From: Guo Qiang Mao Received: from 220.233.86.132 (SquirrelMail authenticated user guoqiang) by www.ee.usyd.edu.au with HTTP; Mon, 8 Jan 2007 20:44:05 +1100 (EST) Message-ID: <16307.220.233.86.132.1168249445.squirrel@www.ee.usyd.edu.au> Date: Mon, 8 Jan 2007 20:44:05 +1100 (EST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-ElectricalEngineering-MailScanner-Information: Please contact the ISP for more information X-ElectricalEngineering-MailScanner: Found to be clean X-ElectricalEngineering-MailScanner-From: guoqiang@ee.usyd.edu.au Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cassius.ee.usyd.edu.au id l089i4bu004382 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: g.mao@ieee.org Subject: [Mip4] ACM SenSys 2007: 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 [Our apologies if you receive multiple copies of this message] =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=3D=3D=3D=3D=3D=3D=3D=3D=3D ACM SenSys 2007: Call for Papers The 5th ACM Conference on Embedded Networked Sensor Systems November 6-9, 2007* (subject to confirmation) Sydney, Australia http://sensys.acm.org/2007/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGBED (approval pending); with support from NSF. The 5th ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedde= d computation capabilities enable an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. This conference provides an ideal venue to address the research challenges facing the design, deployment, use, and fundamental limits of these systems. Sensor networks require contributions from many fields, from wireless communication and networking, embedded systems and hardware, distributed systems, data management, and applications, so we welcome cross-disciplinary work. This year we particularly encourage papers that extend the scope of the conference beyond wireless mote-class sensor networks and we seek contributions from a broad range of sensing-related fields, such as actuator networks, RFID applications, mobile ad-hoc networks, camera networks, and others. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, the following: =95 Sensor network architecture and protocols =95 Applications =95 Rich sensor systems leveraging RFID, mobile devices (e.g., cell phone= s), cameras, robotics, etc. =95 Analysis of real-world systems and fundamental limits =95 Sensor network planning, provisioning, calibration and deployment =95 Deployment experience and testbeds =95 Experimental methodology, including measurement, simulation, and=20 emulation infrastructure =95 Integration with back-end systems such as web-based information syste= ms, process control, and enterprise software =95 Programming methodology =95 Operating systems =95 Sensor network algorithms such as localization, routing, time synchronization, clustering, topology control, and coverage control algorithms =95 Failure resilience and fault isolation =95 Energy management =95 Data, information, and signal processing =95 Data storage and management =95 Distributed actuation and control =95 Security and privacy Important dates: Paper Registration and Abstract: April 10, 2007, midnight US Eastern Time Paper Submission Deadline: April 17, 2007, midnight US Eastern Time Notification of Paper Acceptance: July 2, 2007 Camera Ready Paper Copy: August 30, 2007 All deadlines are firm; we will not honor extensions. 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 14 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. The review process is double-blind and hence, all submissions must be anonymized. Selected papers of particular merit will be proposed for publication in the ACM Transactions on Sensor Networks. For submission details, see the conference web site. Demos: Demonstrations showing innovative research and applications are solicited. SenSys is very interested in demonstrations of technology, platforms, and applications of sensor systems. Abstracts of accepted demo= s will be published in the SenSys conference proceedings. Submissions from both industry and academia are encouraged. For submission details, see th= e conference web site. A call for demos with submission dates, etc., will b= e posted at a later point. Posters: Posters showing exciting early work on sensor systems are solicited. Areas of interest are the same as those listed in the technica= l call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. For submission details, see the conference web site. A call fo= r posters with submission dates, etc., will be posted at a later point. Workshops: Following last year=92s workshop success, workshop proposals a= re highly encouraged in emerging areas related to sensor networks. A call fo= r workshop proposals will be posted on the SenSys website. Organization: General Chair: Sanjay Jha (U. New South Wales) Program Co-Chairs: Phillip B. Gibbons (Intel Research), Akos Ledeczi (Vanderbilt) Poster Co-Chairs: Nirupama Bulusu (Portland State), Rachel Cardell-Oliver (U. Western Australia) Demo Co-Chairs: Suman Nath (Microsoft Research), Max Ott (NICTA, Australia) Workshop Chair: Andreas Savvides (Yale) Local Arrangements Chairs: Subhash Challa (U. Technology, Sydney), Salil Kanhere, (U. New South Wales) Publicity Co-Chairs: Rajeev Shorey (GM Research, India), Guoqiang Mao (U. Sydney) Web Chair: Wen Hu (CSIRO, Australia) Registration Chair: Ren Liu (CSIRO, Australia) Finance Chair: Chun Tung Chou (U. New South Wales) Steering Committee Chair: John Heidemann (USC) Program Committee: Tarek Abdelzaher (UIUC), Gaetano Borriello (U. Washington), Andrew Campbell (Dartmouth), Peter Corke (CSIRO, Australia), Richard Han (U. Colorado), Tien He (U. Minnesota), John Heidemann (USC), Ted Herman (Iowa), Polly Huang (National Taiwan U.), Brad Karp (U. Colleg= e London), Phil Levis (Stanford), Jie Liu (Microsoft Research), Chenyang Lu (Washington U. in St. Louis), Sam Madden (MIT), Miklos Maroti (U. Szeged, Hungary), Margaret Martonosi (Princeton), Lama Nachman (Intel Research), Kay R=F6mer (ETH Zurich), Mani Srivastava (UCLA), John Stankovic (U. Virginia), Subhash Suri (UCSB), Thiemo Voigt (SICS, Sweden) Yours sincerely, Guoqiang Guoqiang Mao, PhD Senior Lecturer, School of Electrical and Information Engineering The University of Sydney, Tel: +61 2 93512962 Fax: +61 2 93513847 Homepage: http://www.ee.usyd.edu.au/~guoqiang -- 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 Jan 08 08:41:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ul1-0006hl-TL; Mon, 08 Jan 2007 08:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ul0-0006gJ-Iy for mip4@ietf.org; Mon, 08 Jan 2007 08:41:46 -0500 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3uge-0003lg-CX for mip4@ietf.org; Mon, 08 Jan 2007 08:37:19 -0500 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 08:35:46 -0500 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] DHCP vs FA Date: Mon, 8 Jan 2007 19:05:42 +0530 Message-ID: <653F3CF58193744C9DE59C217C072B58AB4DEC@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] DHCP vs FA Thread-Index: Accy6wewqQEhx6BmShqJzJqkqYktHgAAggsw From: "Arun SG" To: "Sri Gundavelli" X-OriginalArrivalTime: 08 Jan 2007 13:35:46.0903 (UTC) FILETIME=[E734EE70:01C73329] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Behcet Sarikaya 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 thought that the tunnel from HA anyway exists. It's the end point at the other end [whether the mobile or the FA] that is negotiated by the "R" bit; from Kent's mail, the answer seems to be that the mobile prefers the FA to be the end point - the reason for which I'm trying to understand... Thx, Arun -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Monday, January 08, 2007 11:37 AM To: Arun SG Cc: Kent Leung (kleung); Behcet Sarikaya; mip4@ietf.org Subject: RE: [Mip4] DHCP vs FA For CCOA mode, the home agent needs to have a unique tunnel for each mobile and that has a bearing on the resources when compared to the FA-COA mode. This could be one other reason. Sri On Mon, 8 Jan 2007, Arun SG wrote: > Just curious about the probable reason for the typical [or default]=20 > behaviour of the MIP client - why it prefers FA CoA mode over Ccoa,=20 > since if FA does not mandate registration, the MIP Client might very=20 > well register directly at HA. Is it to do with accounting at FA or=20 > something different? > > Thanks, > Arun > > > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, January 05, 2007 11:48 PM > To: Sri Gundavelli (sgundave); Behcet Sarikaya > Cc: mip4@ietf.org > Subject: RE: [Mip4] DHCP vs FA > > Right. Though typically the MIP client tend to favor the FA CoA mode=20 > of operation in this case. > > Kent > > -----Original Message----- > From: Sri Gundavelli (sgundave) > Sent: Thursday, January 04, 2007 2:51 PM > To: Behcet Sarikaya > Cc: mip4@ietf.org > Subject: Re: [Mip4] DHCP vs FA > > > If the "R" bit is the agent advertisement is not set, it is up to the=20 > mobile to decide on the FA-COA or CCOA mode of registration. > > Sri > > On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > >> Hi all, >> I was reading RFC 3344 and noticed that it is not clear on the=20 >> choice > >> between the co-located care-of address mode using DHCP and FA=20 >> provided > care-of address mode of operation. If MN does get a co-located care-of > address and there is an FA what happens then? >> If this had been discussed in the past, I'll appreciate if someone=20 >> can > summarize the conclusion. >> >> Regards, >> >> --behcet >> >> ----- Original Message ---- >> From: McCann Peter-A001034 >> To: mip4@ietf.org >> Sent: Thursday, January 4, 2007 4:03:26 PM >> Subject: RE: [Mip4] I-D >> ACTION:draft-ietf-mip4-mobike-connectivity-02.txt >> >> >> Thanks Vijay for submitting a new version. >> >> Can the people who raised issues please check this version to see=20 >> that > >> they were addressed? >> >> If there are no further issues we will proceed to send this version=20 >> up > >> 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 Working Group of=20 >>> the IETF. >>> >>> Title : Secure Connectivity and Mobility using Mobile >> IPv4 and >>> MOBIKE Author(s) : V. Devarapalli, P. Eronen >>> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >>> Pages : 15 >>> Date : 2007-1-4 >>> >>> Enterprise users require mobility and secure connectivity when they >>> roam and connect to the services offered in the enterprise. > Secure >>> connectivity is required when the user connects to the enterprise >>> from an untrusted network. Mobility is beneficial when the user >>> moves, either inside or outside the enterprise network, and >>> acquires a new IP address. This document describes a solution >>> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >>> provide secure connectivity and mobility. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivi >> t >> y- >> 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=20 >>> 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=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-mobike-connectivity-02.txt". >>> >>> 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 >>> >>> 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-mobike-connectivity-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=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/ > > -- > 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/ > -- 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 Jan 08 11:52:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xjO-0006Jg-Qw; Mon, 08 Jan 2007 11:52:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xjN-0006Jb-JR for mip4@ietf.org; Mon, 08 Jan 2007 11:52:17 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3xjJ-0002By-Uo for mip4@ietf.org; Mon, 08 Jan 2007 11:52:17 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2007 08:52:13 -0800 X-IronPort-AV: i="4.13,159,1167638400"; d="scan'208"; a="99218317:sNHT73445229" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l08GqDwh026742; Mon, 8 Jan 2007 08:52:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l08GqDIl018588; Mon, 8 Jan 2007 08:52:13 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 08:52:12 -0800 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] DHCP vs FA Date: Mon, 8 Jan 2007 08:52:12 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52031BC2F7@xmb-sjc-235.amer.cisco.com> In-Reply-To: <653F3CF58193744C9DE59C217C072B58AB4DEC@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] DHCP vs FA Thread-Index: Accy6wewqQEhx6BmShqJzJqkqYktHgAAggswABX+WiA= From: "Kent Leung \(kleung\)" To: "Arun SG" , "Sri Gundavelli \(sgundave\)" X-OriginalArrivalTime: 08 Jan 2007 16:52:12.0816 (UTC) FILETIME=[58288900:01C73345] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6958; t=1168275133; x=1169139133; c=relaxed/simple; s=sjdkim7002; 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]=20DHCP=20vs=20FA |Sender:=20; bh=IHwkHfj2wgVCQeoruRGjht+GQx4gtOzYk2LznVOhPIs=; b=XnwRADkn/k6hHNMLa/DEvYfE79Td09YYVGjFWETETdK0Uvbm+hIv3vboF6lCJuoTYx9CAN42 kVhO9hE+0IxvNPw22p4wyvkNRiEU3p7eyZgeCjkL5CrSk6T3aNjzSFdH; Authentication-Results: sj-dkim-7; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Behcet Sarikaya , 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 Arun. There are several advantages of FA CoA mode which includes no tunnel header overhead per packet, less consumption of address space for CoA, aggregated use of CoA, less tunnel endpoints on the HA, etc. Kent=20 -----Original Message----- From: Arun SG [mailto:arunsg@airvana.com]=20 Sent: Monday, January 08, 2007 5:36 AM To: Sri Gundavelli (sgundave) Cc: Kent Leung (kleung); Behcet Sarikaya; mip4@ietf.org Subject: RE: [Mip4] DHCP vs FA I thought that the tunnel from HA anyway exists. It's the end point at the other end [whether the mobile or the FA] that is negotiated by the "R" bit; from Kent's mail, the answer seems to be that the mobile prefers the FA to be the end point - the reason for which I'm trying to understand... Thx, Arun -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Monday, January 08, 2007 11:37 AM To: Arun SG Cc: Kent Leung (kleung); Behcet Sarikaya; mip4@ietf.org Subject: RE: [Mip4] DHCP vs FA For CCOA mode, the home agent needs to have a unique tunnel for each mobile and that has a bearing on the resources when compared to the FA-COA mode. This could be one other reason. Sri On Mon, 8 Jan 2007, Arun SG wrote: > Just curious about the probable reason for the typical [or default]=20 > behaviour of the MIP client - why it prefers FA CoA mode over Ccoa,=20 > since if FA does not mandate registration, the MIP Client might very=20 > well register directly at HA. Is it to do with accounting at FA or=20 > something different? > > Thanks, > Arun > > > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, January 05, 2007 11:48 PM > To: Sri Gundavelli (sgundave); Behcet Sarikaya > Cc: mip4@ietf.org > Subject: RE: [Mip4] DHCP vs FA > > Right. Though typically the MIP client tend to favor the FA CoA mode=20 > of operation in this case. > > Kent > > -----Original Message----- > From: Sri Gundavelli (sgundave) > Sent: Thursday, January 04, 2007 2:51 PM > To: Behcet Sarikaya > Cc: mip4@ietf.org > Subject: Re: [Mip4] DHCP vs FA > > > If the "R" bit is the agent advertisement is not set, it is up to the=20 > mobile to decide on the FA-COA or CCOA mode of registration. > > Sri > > On Thu, 4 Jan 2007, Behcet Sarikaya wrote: > >> Hi all, >> I was reading RFC 3344 and noticed that it is not clear on the=20 >> choice > >> between the co-located care-of address mode using DHCP and FA=20 >> provided > care-of address mode of operation. If MN does get a co-located care-of > address and there is an FA what happens then? >> If this had been discussed in the past, I'll appreciate if someone=20 >> can > summarize the conclusion. >> >> Regards, >> >> --behcet >> >> ----- Original Message ---- >> From: McCann Peter-A001034 >> To: mip4@ietf.org >> Sent: Thursday, January 4, 2007 4:03:26 PM >> Subject: RE: [Mip4] I-D >> ACTION:draft-ietf-mip4-mobike-connectivity-02.txt >> >> >> Thanks Vijay for submitting a new version. >> >> Can the people who raised issues please check this version to see=20 >> that > >> they were addressed? >> >> If there are no further issues we will proceed to send this version=20 >> up > >> 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 Working Group of=20 >>> the IETF. >>> >>> Title : Secure Connectivity and Mobility using Mobile >> IPv4 and >>> MOBIKE Author(s) : V. Devarapalli, P. Eronen >>> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >>> Pages : 15 >>> Date : 2007-1-4 >>> >>> Enterprise users require mobility and secure connectivity when they >>> roam and connect to the services offered in the enterprise. > Secure >>> connectivity is required when the user connects to the enterprise >>> from an untrusted network. Mobility is beneficial when the user >>> moves, either inside or outside the enterprise network, and >>> acquires a new IP address. This document describes a solution >>> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >>> provide secure connectivity and mobility. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivi >> t >> y- >> 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=20 >>> 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=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-mobike-connectivity-02.txt". >>> >>> 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 >>> >>> 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-mobike-connectivity-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=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/ > > -- > 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/ > -- 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 Jan 08 15:20:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40yy-0007Tf-7x; Mon, 08 Jan 2007 15:20:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ypS-0004EH-Pk for mip4@ietf.org; Mon, 08 Jan 2007 13:02:38 -0500 Received: from grid.lrg.ufsc.br ([150.162.63.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3yop-0001Hp-TD for mip4@ietf.org; Mon, 08 Jan 2007 13:02:02 -0500 Received: from localhost.grid.lrg.ufsc.br (localhost [127.0.0.1]) by grid.lrg.ufsc.br (Postfix) with ESMTP id 382AC12B4B6; Mon, 8 Jan 2007 12:52:06 -0200 (BRST) X-Original-To: mycolleagues@grid.lrg.ufsc.br Delivered-To: mycolleagues@grid.lrg.ufsc.br Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by grid.lrg.ufsc.br (Postfix) with ESMTP id 368BB129EC9 for ; Thu, 4 Jan 2007 08:03:05 -0200 (BRST) Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DDD0C20031E5 for ; Thu, 4 Jan 2007 11:53:31 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMNRs2oNFZhj for ; Thu, 4 Jan 2007 11:53:31 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BAB3B20001AF for ; Thu, 4 Jan 2007 11:53:31 +0100 (CET) Received: from [10.1.1.176] ([10.1.1.176]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:52:53 +0100 Message-ID: <459CDC80.3050505@netlab.nec.de> Date: Thu, 04 Jan 2007 11:52:48 +0100 From: Joao Girao User-Agent: Icedove 1.5.0.8 (X11/20061128) MIME-Version: 1.0 To: mycolleagues@grid.lrg.ufsc.br X-Enigmail-Version: 0.94.1.0 X-OriginalArrivalTime: 04 Jan 2007 10:52:53.0894 (UTC) FILETIME=[7C631A60:01C72FEE] X-Mailman-Approved-At: Mon, 08 Jan 2007 10:55:38 -0200 X-BeenThere: mycolleagues@grid.lrg.ufsc.br X-Mailman-Version: 2.1.8 Precedence: list Content-Type: multipart/mixed; boundary="===============0871108701==" X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-Mailman-Approved-At: Mon, 08 Jan 2007 15:20:35 -0500 Cc: Subject: [Mip4] [mycolleagues] ESAS 2007 - Fourth European Workshop on Security and Privacy in Ad hoc and Sensor Networks, Cambridge, England X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0871108701== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080208010205000905010309" This is a cryptographically signed message in MIME format. --------------ms080208010205000905010309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -- We apologize if you receive multiple copies of this CFP -- -- Note that the submission deadline is 31st of January -- --------------------------------------------------------------------- Fourth European Workshop on Security and Privacy in Ad hoc and Sensor Networks (ESAS 2007) http://www.netlab.nec.de/esas/ Sidney Sussex College, Cambridge, England July 2-3, 2007 --------------------------------------------------------------------- Call for Papers The vision of ubiquitous computing has generated a lot of interest in wireless ad hoc and sensor networks. However, besides their potential advantages, these new generations of networks also raise some challenging problems with respect to security and privacy. The aim of this workshop is to bring together the network security, cryptography, and wireless networking communities in order to discuss these problems and to propose new solutions. The fourth ESAS workshop seeks submissions that present original research on all aspects of security and privacy in wireless ad hoc and sensor networks. Submission of papers based on work-in-progress is encouraged. Topics of interest include, but are not limited to the following: Privacy and anonymity Cooperation and fairness Secure topology control Secure localization Secure in-network processing Security for embedded systems Prevention of traffic analysis Key management Secure routing Secure MAC protocols Secure time synchronization Distributed intrusion detection Location privacy Trust establishment Secure context aware computing --------------------------------------------------------------------- Important dates: Submission deadline: January 31, 2007 Notification of acceptance: March 31, 2007 Camera-ready version: April 15, 2007 Workshop: July 2-3, 2007 --------------------------------------------------------------------- Instructions for Authors and Workshop Proceedings: Authors are invited to submit a complete paper of their original work. Maximum length for submissions is 15 pages in LNCS format. The preferred submission format is PDF and for the final version the sources of the contribution in LaTeX will also be required. Submissions must not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel. All submissions will be refereed. Accepted papers must be presented at the workshop. Further information on how to submit papers will be available on the web site of the workshop: http://www.netlab.nec.de/esas/ As in previous years, we expect to publish the proceedings in the Springer Lecture Notes in Computer Science (LNCS) Series (currently under negotiation). Note that this year the final proceedings volume will be distributed at the workshop. --------------------------------------------------------------------- Organization Committee: General chair: Frank Stajano, University of Cambridge Program co-chairs: Cathy Meadows, Naval Research Laboratory Srdjan Capkun, ETH Zurich Local arrangements chair: Tyler Moore, University of Cambridge Publicity chair: Joao Girao, NEC Europe Network Lab Steering Committee: Levente Buttyan, BUTE Claude Castelluccia, INRIA Dirk Westhoff, NEC Europe Network Lab Program Committee: Imad Aad, DoCoMo Lab Europe, Germany Tansu Alpcan, Deutsche Telekom Laboratories/TU Berlin Farooq Anjum, Telcordia research, USA N. Asokan, Nokia, Finland Gildas Avoine, MIT, USA Lejla Batina, ESAT SCD/COSIC, Belgium Levente Buttyan, Budapest University of Technology and Economics, Hungary Mario Cagalj, University of Split, Croatia Claude Castelluccia, INRIA, France Xuhua Ding, Singapore Management University, Singapore Saurabh Ganeriwal, Google, USA Virgil Gligor, University of Maryland, College Park, USA Christian D. Jensen, Technical University of Denmark Markus Kuhn, University of Cambridge, UK Loukas Lazos, University of Washington, USA Wenke Lee, Georgia Institute of Technology, USA Mingyan Li, Boeing, USA Donggang Liu, University of Texas at Arlington, USA Refik Molva, Institute Eurocom, France Peng Ning, NC State, USA Kaisa Nyberg, Helsinki University of Technology, Finland Radha Poovendran, University of Washington, USA Michael Roe, Microsoft Research, Cambridge, UK Mani Srivastava, UCLA, USA Dirk Westhoff, NEC Europe Network Lab, Germany Susanne Wetzel, Stevens Institute of Technology, USA --------------ms080208010205000905010309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNuMIIC16ADAgECAhBIEnhyL8BGaRxC0jyI5k7Y MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNjA4MTAxMjQ4MDNaFw0wNzA4MTAxMjQ4MDNaMIGkMQ4wDAYDVQQEEwVH aXJhbzENMAsGA1UEKhMESm9hbzETMBEGA1UEAxMKSm9hbyBHaXJhbzEnMCUGCSqGSIb3DQEJ ARYYam9hby5naXJhb0BuZXRsYWIubmVjLmRlMSYwJAYJKoZIhvcNAQkBFhdqb2FvLmdpcmFv QGNjcmxlLm5lYy5kZTEdMBsGCSqGSIb3DQEJARYOam9hb0BnaXJhby5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKBwubqPARedECtlpWmIUqY8IsYxwV4Bml+3ZYoVEm ZlMBGlZ8OGYKd5m5hr54h9GO3GDi2ju68RQqNgbgSB54oUngc9CplT+FH0LNk9OxFclJQkkD YT6kPSE7F0U81lA3hclZALOw+63rxn52IJ2pOEoCFcfOxFtw7M9ojHhjzkwhbPg9GSMI+9eM HT+XkUVjV6Ou4TOYYyLWmrqWo42Gx3FQqwxv3ImIGdkZnkQ4O4e5tLPQy2AN9mVT92Oy+DJ9 x/WFVuQC0Aaf3FS2uyJ1VVOzVdT096FtakV3bSBALPYinOsTyprTGdEJ7dTZYsSt/KO9DcRm i8PfOiK1sJUfAgMBAAGjXjBcMEwGA1UdEQRFMEOBGGpvYW8uZ2lyYW9AbmV0bGFiLm5lYy5k ZYEXam9hby5naXJhb0BjY3JsZS5uZWMuZGWBDmpvYW9AZ2lyYW8ub3JnMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAfTB+eOPK/f/HPEfHi9MpX5DyPilyVD+TcbV9BtiY0mxc OpLpHvBo645NjS6E6jDmiMhq+AfA278uwDC/Lv2PShFVrPfPSYASDiwj3ydlbcPRYH2SmGIG 8fh28Jw7eJZ7Bi7BcIHM62+M1/k56KoZQ7wnQlT4GOrJq2acgtSVw00wggNuMIIC16ADAgEC AhBIEnhyL8BGaRxC0jyI5k7YMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA4MTAxMjQ4MDNaFw0wNzA4MTAxMjQ4 MDNaMIGkMQ4wDAYDVQQEEwVHaXJhbzENMAsGA1UEKhMESm9hbzETMBEGA1UEAxMKSm9hbyBH aXJhbzEnMCUGCSqGSIb3DQEJARYYam9hby5naXJhb0BuZXRsYWIubmVjLmRlMSYwJAYJKoZI hvcNAQkBFhdqb2FvLmdpcmFvQGNjcmxlLm5lYy5kZTEdMBsGCSqGSIb3DQEJARYOam9hb0Bn aXJhby5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKBwubqPARedECtlpW mIUqY8IsYxwV4Bml+3ZYoVEmZlMBGlZ8OGYKd5m5hr54h9GO3GDi2ju68RQqNgbgSB54oUng c9CplT+FH0LNk9OxFclJQkkDYT6kPSE7F0U81lA3hclZALOw+63rxn52IJ2pOEoCFcfOxFtw 7M9ojHhjzkwhbPg9GSMI+9eMHT+XkUVjV6Ou4TOYYyLWmrqWo42Gx3FQqwxv3ImIGdkZnkQ4 O4e5tLPQy2AN9mVT92Oy+DJ9x/WFVuQC0Aaf3FS2uyJ1VVOzVdT096FtakV3bSBALPYinOsT yprTGdEJ7dTZYsSt/KO9DcRmi8PfOiK1sJUfAgMBAAGjXjBcMEwGA1UdEQRFMEOBGGpvYW8u Z2lyYW9AbmV0bGFiLm5lYy5kZYEXam9hby5naXJhb0BjY3JsZS5uZWMuZGWBDmpvYW9AZ2ly YW8ub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAfTB+eOPK/f/HPEfHi9Mp X5DyPilyVD+TcbV9BtiY0mxcOpLpHvBo645NjS6E6jDmiMhq+AfA278uwDC/Lv2PShFVrPfP SYASDiwj3ydlbcPRYH2SmGIG8fh28Jw7eJZ7Bi7BcIHM62+M1/k56KoZQ7wnQlT4GOrJq2ac gtSVw00xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIQSBJ4ci/ARmkcQtI8iOZO2DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAxMDQxMDUyNDhaMCMGCSqGSIb3 DQEJBDEWBBS8JzWOURGMft/16whcPkIYxmO/jDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEgSeHIvwEZpHELSPIjmTtgwgYcGCyqGSIb3DQEJEAILMXigdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEgSeHIvwEZp HELSPIjmTtgwDQYJKoZIhvcNAQEBBQAEggEAnCkI9mhzLtkQ4Z2jJNvYNvZcU6c31zIsD3Lu GmN7CeurHlWvLofKJNy3xf0a0Q+N0Vm3+J8MPekt5ULvm5CNgoPcCHBernvX/g+ymu5bqzyH 5zGTQQk1vHL6v0DQuKiwNM8XJ8y6TKBfxQExAvF+CoD1CA4UHNz2QP23f8ja41gZLIB0uw4N usPF13dfv3Rys0dALzrtR3O1zEtgJRMrKZUQTzSdyjIR7H6P/sxiq6/9uiEtaOU35p7cL1Qz Q0V2zhqIPaZDfftrVKehxapf4oZjHzqtt2MUv3poc7vJavPhBrqVn9GS97qyIGfN2U0rzFUc lY2MD1o4/ahF1tRAvAAAAAAAAA== --------------ms080208010205000905010309-- --===============0871108701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mycolleagues mailing list mycolleagues@grid.lrg.ufsc.br http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues --===============0871108701== 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/ --===============0871108701==-- From mip4-bounces@ietf.org Tue Jan 09 06:02:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4EkM-0006Wi-Be; Tue, 09 Jan 2007 06:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4EkL-0006Wd-HE for mip4@ietf.org; Tue, 09 Jan 2007 06:02:25 -0500 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 1H4EkG-0006qY-Ui for mip4@ietf.org; Tue, 09 Jan 2007 06:02:25 -0500 Received: from [127.0.0.1] (c43.local.ipunplugged.com [192.168.4.242]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id l09B1c45015842; Tue, 9 Jan 2007 12:01:47 +0100 Message-ID: <45A37611.4010508@ipunplugged.com> Date: Tue, 09 Jan 2007 12:01:37 +0100 From: Hans Sjostrand User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Arun SG Subject: Re: [Mip4] DHCP vs FA References: <653F3CF58193744C9DE59C217C072B58AB4DEC@nilgiri.india.wirelessworld.airvananet.com> In-Reply-To: <653F3CF58193744C9DE59C217C072B58AB4DEC@nilgiri.india.wirelessworld.airvananet.com> 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: 1e467ff145ef391eb7b594ef62b8301f Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Behcet Sarikaya , Sri Gundavelli 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 There are some other reasons aswell, 1. Speed The mobile needs to make choices when discovering a visited network. The FA solicitation-advertisement is normally a lot faster than the dhcp process. So, the mobile of course uses the first available way to register and only uses a secondary mechanism such as collocated CoA (CCoA) if it has a reason (e.g. fails with the FA with a reason that is recoverable). 2. Convenience Very often where there are a visiting network with DHCP and FA, authentication is required. And in quite a few times outside the lab, web-authentication is used for the dhcp people, and mip's fa authentication is used for the mip capable people. In the fa case the authentication is automatic and requires no user intervention. In the dhcp case, the mobile doesn't go anywhere until the owner has filled in a web form. So, together with all the other reasons mentioned by the people on the list, I see no reason at all for a MN to wait for the CCoA case if there are usable FA around. regards /// Hasse Arun SG wrote: > I thought that the tunnel from HA anyway exists. It's the end point at > the other end [whether the mobile or the FA] that is negotiated by the > "R" bit; from Kent's mail, the answer seems to be that the mobile > prefers the FA to be the end point - the reason for which I'm trying to > understand... > Thx, > Arun > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Monday, January 08, 2007 11:37 AM > To: Arun SG > Cc: Kent Leung (kleung); Behcet Sarikaya; mip4@ietf.org > Subject: RE: [Mip4] DHCP vs FA > > > For CCOA mode, the home agent needs to have a unique tunnel for each > mobile and that has a bearing on the resources when compared to the > FA-COA mode. This could be one other reason. > > Sri > > > On Mon, 8 Jan 2007, Arun SG wrote: > > >> Just curious about the probable reason for the typical [or default] >> behaviour of the MIP client - why it prefers FA CoA mode over Ccoa, >> since if FA does not mandate registration, the MIP Client might very >> well register directly at HA. Is it to do with accounting at FA or >> something different? >> >> Thanks, >> Arun >> >> >> >> -----Original Message----- >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> Sent: Friday, January 05, 2007 11:48 PM >> To: Sri Gundavelli (sgundave); Behcet Sarikaya >> Cc: mip4@ietf.org >> Subject: RE: [Mip4] DHCP vs FA >> >> Right. Though typically the MIP client tend to favor the FA CoA mode >> of operation in this case. >> >> Kent >> >> -----Original Message----- >> From: Sri Gundavelli (sgundave) >> Sent: Thursday, January 04, 2007 2:51 PM >> To: Behcet Sarikaya >> Cc: mip4@ietf.org >> Subject: Re: [Mip4] DHCP vs FA >> >> >> If the "R" bit is the agent advertisement is not set, it is up to the >> mobile to decide on the FA-COA or CCOA mode of registration. >> >> Sri >> >> On Thu, 4 Jan 2007, Behcet Sarikaya wrote: >> >> >>> Hi all, >>> I was reading RFC 3344 and noticed that it is not clear on the >>> choice >>> >>> between the co-located care-of address mode using DHCP and FA >>> provided >>> >> care-of address mode of operation. If MN does get a co-located care-of >> > > >> address and there is an FA what happens then? >> >>> If this had been discussed in the past, I'll appreciate if someone >>> can >>> >> summarize the conclusion. >> >>> Regards, >>> >>> --behcet >>> >>> ----- Original Message ---- >>> From: McCann Peter-A001034 >>> To: mip4@ietf.org >>> Sent: Thursday, January 4, 2007 4:03:26 PM >>> Subject: RE: [Mip4] I-D >>> ACTION:draft-ietf-mip4-mobike-connectivity-02.txt >>> >>> >>> Thanks Vijay for submitting a new version. >>> >>> Can the people who raised issues please check this version to see >>> that >>> >>> they were addressed? >>> >>> If there are no further issues we will proceed to send this version >>> up >>> >>> to the IESG. >>> >>> -Pete >>> >>> Internet-Drafts@ietf.org wrote: >>> >>>> 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 : Secure Connectivity and Mobility using Mobile >>>> >>> IPv4 and >>> >>>> MOBIKE Author(s) : V. Devarapalli, P. Eronen >>>> Filename : draft-ietf-mip4-mobike-connectivity-02.txt >>>> Pages : 15 >>>> Date : 2007-1-4 >>>> >>>> Enterprise users require mobility and secure connectivity when they >>>> roam and connect to the services offered in the enterprise. >>>> >> Secure >> >>>> connectivity is required when the user connects to the enterprise >>>> from an untrusted network. Mobility is beneficial when the user >>>> moves, either inside or outside the enterprise network, and >>>> acquires a new IP address. This document describes a solution >>>> using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to >>>> provide secure connectivity and mobility. >>>> >>>> A URL for this Internet-Draft is: >>>> >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivi >>> t >>> y- >>> 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-mobike-connectivity-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-mobike-connectivity-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. >>>> >>> -- >>> 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/ >> >> -- >> 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 Tue Jan 09 10:12:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ie1-00033T-Ju; Tue, 09 Jan 2007 10:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4AKt-0005dF-Of for mip4@ietf.org; Tue, 09 Jan 2007 01:19:51 -0500 Received: from proliant.st.ewi.tudelft.nl ([130.161.158.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4AKs-0002pY-BD for mip4@ietf.org; Tue, 09 Jan 2007 01:19:51 -0500 Received: from lehar.st.ewi.tudelft.nl (lehar.st.ewi.tudelft.nl [130.161.158.254]) by proliant.st.ewi.tudelft.nl (8.12.11/8.12.8) with ESMTP id l096JnnR000737 for ; Tue, 9 Jan 2007 07:19:49 +0100 Received: from koen by lehar.st.ewi.tudelft.nl with local (Exim 3.36 #1 (Debian)) id 1H4AKr-0000UQ-00 for ; Tue, 09 Jan 2007 07:19:49 +0100 To: mip4@ietf.org From: info@ewsn.org Message-Id: Date: Tue, 09 Jan 2007 07:19:49 +0100 X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Tue, 09 Jan 2007 10:12:08 -0500 Subject: [Mip4] EWSN 2007 EARLY REGISTRATION DEADLINE (Jan 15) 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 [Apologies if you receive multiple copies of this e-mail] ======================================================================== CALL FOR PARTICIPATION 4th European conference on Wireless Sensor Networks (EWSN 2007) Delft University of Technology, The Netherlands January 29-31, 2007 http://www.ewsn.org Early registration expires by January 15th, 2007 ======================================================================== EWSN 2007, the European conference on Wireless Sensor Networks, is the fourth of a series of annual meetings focusing on the latest research in the rapidly growing area of wireless sensor networks. EWSN 2007 will be held at Delft University of Technology, Delft, The Netherlands, on January 29-31, 2007. It will provide a forum where researchers with different experience and background, from hardware to applications, can discuss cross-layer integration, novel solutions for specific problems and envisage the future development of WSN functionalities. To this end EWSN 2007 features two tutorials, two keynotes, a poster/demo session, and 22 presentations of high quality papers. - tutorial 1 "Mathematical Modeling of Data-Centric Querying in Sensor Networks" by Bhaskar Krishnamachari (USC, USA) - tutorial 2 "Reliable Multihop Networking with Bluetooth" by Jan Beutel (ETH Zurich, Switzerland) - keynote 1 "Sensornets: the Next Big Thing (broadening the definition of sensornet research)" by John Heidemann (USC/ISI, USA) - keynote 2 "Wireless sensor networks - From science to reality" by Paul Havinga (UTwente and Ambient Systems) The full program is available at the web site (http://www.ewsn.org). IMPORTANT DATES early registration January 15, 2007 conference January 29-30, 2007 You are cordially invited to participate, Koen Langendoen (EWSN 2007 general chair). -- 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 Jan 09 10:12:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IeL-0003P9-7w; Tue, 09 Jan 2007 10:12:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H437U-00088g-HD; Mon, 08 Jan 2007 17:37:32 -0500 Received: from ozzie.acm.org ([63.118.7.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H437P-0007sA-DM; Mon, 08 Jan 2007 17:37:32 -0500 Received: from ozzie (localhost) by ozzie.acm.org (LSMTP for Windows NT v1.1b) with SMTP id <0.002447BC@ozzie.acm.org>; Mon, 8 Jan 2007 17:41:21 -0500 Received: by LISTSERV.ACM.ORG (LISTSERV-TCP/IP release 14.3) with spool id 19785353 for SENSORNET@LISTSERV.ACM.ORG; Mon, 8 Jan 2007 17:41:09 -0500 Received: from psmtp.com (exprod7mx66.postini.com) by ozzie.acm.org (LSMTP for Windows NT v1.1b) with SMTP id <0.002447BB@ozzie.acm.org>; Mon, 8 Jan 2007 17:41:09 -0500 Received: from source ([63.118.7.109]) (using SSLv3) by exprod7mx66.postini.com ([64.18.6.14]) with SMTP; Mon, 08 Jan 2007 14:37:06 PST Received: from psmtp.com ([64.18.2.83]) by acm26-4.acm.org (ACM Email Forwarding Service) with SMTP id NXQ32857 for ; Mon, 08 Jan 2007 17:34:57 -0500 Received: from source ([13.1.64.93]) by exprod7mx81.postini.com ([64.18.6.14]) with SMTP; Mon, 08 Jan 2007 14:34:47 PST Received: from [13.2.19.35] ([13.2.19.35]) by alpha.xerox.com with SMTP id <515876(1)>; Mon, 8 Jan 2007 14:34:34 PST User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-pstn-levels: (S:44.08631/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 5 (2.0000:0.0000) s gt3 gt2 GT1 r p m c X-pstn-addresses: from [283/18] X-pstn-levels: (S:44.08631/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 4 (1.5000:1.5000) s gt3 gt2 gt1 r p m c X-pstn-addresses: from [141/11] Message-ID: <45A2C6FA.1040809@parc.com> Date: Mon, 8 Jan 2007 14:34:34 PST From: Ying Zhang X-To: sensornet@acm.org To: SENSORNET@LISTSERV.ACM.ORG Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Tue, 09 Jan 2007 10:12:28 -0500 Cc: Subject: [Mip4] IPSN 2007: Call for Demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Reply-To: Ying Zhang List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org IPSN 2007: Call for Demos The 6th International Conference on Information Processing in Sensor Networks (IPSN 2007) Sponsored by ACM and IEEE Cambridge (MIT Campus), Massachusetts, USA April 24 - 27, 2007 http://www.cse.wustl.edu/ipsn07.html CALL FOR DEMOS The 6th International Conference on Information Processing in Sensor Networks (IPSN 2007) draws upon many disciplines including networking, signal and image processing, information and coding theory, databases, embedded systems, wireless communications, and machine learning. In addition to full-length technical papers, IPSN is very interested in demonstrations of novel sensor network technology, applications, and hardware. The IPSN Program Commitee encourages submissions from industry as well as academia. DEMO SUBMISSION INSTRUCTIONS Accepted demos will be included in the IPSN proceedings. Submissions should be sent to: ipsn2007demos@gmail.com and should be a two-page abstract that follows the IPSN formatting guidelines: refer to the IPSN submission instructions for details. Be specific as possible in describing what you will demonstrate. The demo session will have power and wireless connectivity available. If a demonstration requires special arrangements, please note them in the mail message with the submission (not in the submission itself). IMPORTANT DATES Two-page demo descriptions: 11:59pm (PST), February 9, 2007 Notification of acceptance: February 16, 2007 Conference dates: April 25-27 IPSN 2007 Demo Chair Philip Levis (Stanford University) -- 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 Jan 11 11:03:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ot-0003T5-IY; Thu, 11 Jan 2007 11:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4X2Z-00010r-OC for mip4@ietf.org; Wed, 10 Jan 2007 01:34:27 -0500 Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4X2U-00006H-4u for mip4@ietf.org; Wed, 10 Jan 2007 01:34:27 -0500 Received: (qmail 68614 invoked from network); 10 Jan 2007 06:34:21 -0000 Received: from unknown (HELO YEOBS) (boonsain.yeo@sensimesh.com@210.193.15.58 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 10 Jan 2007 06:34:20 -0000 X-YMail-OSG: CQAkBN0VM1lHVenf0nAjDHloGD38nuANQiCv4.057bs_WJJwwS9MWf6IHdJJQ9rJF0_HNbQ3SQbaMiLG6Jso5HO_MvAejW34Nryp6._ebFqI_HfXETYSwemvOeimgM1PtuLm6S55sCQieW20j3ZGyfbL_6OTykXZ00FujFRed9_rg9IiTPUKRQ-- Message-ID: <01c101c73481$40b99c40$8300a8c0@YEOBS> From: "Boon Sain YEO" To: Date: Wed, 10 Jan 2007 14:33:23 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 X-Mailman-Approved-At: Thu, 11 Jan 2007 11:03:34 -0500 Cc: Subject: [Mip4] Call for Participation - ISWPC 2007, San Juan, Puerto Rico (Special RFID Panels by Organized by HP) 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="===============1429600325==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1429600325== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BC_01C734C4.48211330" This is a multi-part message in MIME format. ------=_NextPart_000_01BC_01C734C4.48211330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Apologies if you receive multiple copies of this message) ---------------------------------------------------------------------- CALL FOR PARTICIPATION International Symposium on Wireless Pervasive Computing 2007 (ISWPC 2007) 5-7 February 2007, San Juan, Puerto Rico, USA http://www.iswpc.org/2007/ Technically Sponsored By IEEE Communications Society and IEEE Vehicular Technology Society Hosted By University of Puerto Rico at Mayaguez ---------------------------------------------------------------------- SCOPE Wireless pervasive computing is a rapidly growing area that has = attracted significant attention due to its potential impact on the quality of lifestyles of individuals. To enable wireless pervasive computing, it is necessary to integrate technologies from the fields of communications, signal processing, distributed computing, and numerous other fields. The = aim of this symposium is to provide a platform for researchers in the area = of wireless pervasive computing and related areas to showcase their = results, launch new ideas, as well as to interact with colleagues from these = areas. The scope of the symposium covers all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing. A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in = this area. -----------------------------------From mip4-bounces@ietf.org Thu Jan 11 11:03:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ot-0003T5-IY; Thu, 11 Jan 2007 11:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4X2Z-00010r-OC for mip4@ietf.org; Wed, 10 Jan 2007 01:34:27 -0500 Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4X2U-00006H-4u for mip4@ietf.org; Wed, 10 Jan 2007 01:34:27 -0500 Received: (qmail 68614 invoked from network); 10 Jan 2007 06:34:21 -0000 Received: from unknown (HELO YEOBS) (boonsain.yeo@sensimesh.com@210.193.15.58 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 10 Jan 2007 06:34:20 -0000 X-YMail-OSG: CQAkBN0VM1lHVenf0nAjDHloGD38nuANQiCv4.057bs_WJJwwS9MWf6IHdJJQ9rJF0_HNbQ3SQbaMiLG6Jso5HO_MvAejW34Nryp6._ebFqI_HfXETYSwemvOeimgM1PtuLm6S55sCQieW20j3ZGyfbL_6OTykXZ00FujFRed9_rg9IiTPUKRQ-- Message-ID: <01c101c73481$40b99c40$8300a8c0@YEOBS> From: "Boon Sain YEO" To: Date: Wed, 10 Jan 2007 14:33:23 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 X-Mailman-Approved-At: Thu, 11 Jan 2007 11:03:34 -0500 Cc: Subject: [Mip4] Call for Participation - ISWPC 2007, San Juan, Puerto Rico (Special RFID Panels by Organized by HP) 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="===============1429600325==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1429600325== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BC_01C734C4.48211330" This is a multi-part message in MIME format. ------=_NextPart_000_01BC_01C734C4.48211330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Apologies if you receive multiple copies of this message) ---------------------------------------------------------------------- CALL FOR PARTICIPATION International Symposium on Wireless Pervasive Computing 2007 (ISWPC 2007) 5-7 February 2007, San Juan, Puerto Rico, USA http://www.iswpc.org/2007/ Technically Sponsored By IEEE Communications Society and IEEE Vehicular Technology Society Hosted By University of Puerto Rico at Mayaguez ---------------------------------------------------------------------- SCOPE Wireless pervasive computing is a rapidly growing area that has = attracted significant attention due to its potential impact on the quality of lifestyles of individuals. To enable wireless pervasive computing, it is necessary to integrate technologies from the fields of communications, signal processing, distributed computing, and numerous other fields. The = aim of this symposium is to provide a platform for researchers in the area = of wireless pervasive computing and related areas to showcase their = results, launch new ideas, as well as to interact with colleagues from these = areas. The scope of the symposium covers all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing. A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in = this area. ---------------------------------------------------------------------- KEYNOTES Wireless Networks Work - What's Next? Dr Victor Bahl, Microsoft Research RF Localization and the Internet of Things Professor Kaveh Pahlavan, Worcester Polytechnic Institute Context Modelng in Smart Environments: A Perspective from Pervasive Computing Professor Sajal K. Das, University of Texas at Arlington ---------------------------------------------------------------------- WORKSHOP ON WIRELESS NETWORKING, AUTOMATED INFORMATION PROCESSING, AND = WEB & GRID SERVICES The workshop will be hold on 4th Feb 2007 and is free to all registered participants of ISWPC 2007. SCOPE This workshop intends to serve as a forum for the exchange of new ideas, concepts, and results associated with three specific areas showing a = degree of convergence: Wireless Networking (WN), Grid and Web Services (GWS), = and Automated Information Processing (AIP). AIP is serving as a bridge = between WN and GWS and in this context is bringing out new exciting and = challenging issues. The workshop is addressing issues along the following lines = through a set of thought-provoking questions: Grid and Web Services Grid Computing: a new technology or a cheaper alternative? What are the financial and technological benefits of grid computing = versus cluster computing? What markets stand to benefit the most from grid computing? Does wireless access to computing grids open up new application/ service markets? Which ones? Do projected trends for future data processing needs align favorably = with the capabilities of computing grids? Wireless Networking How wireless sensor networks (WSN) integrate with wireless networking in general? How can WSNs characterize smart environments in our automated society? How to manage uncertainty due inhabitants' contexts in smart = environments? What significant automated information processing issues need to be addressed for context-aware resource management in smart environments? Beyond mere wireless access to grids: are there any wireless-specific services or applications that may benefit from grid computing? Automated Information Processing What information processing applications are good and poor matches for grids? What is automated in automated information processing? How to integrate syntactic and semantic issues in automated information processing? How AIP is serving as a bridge between grid and web services and = wireless networking? What role plays signal processing in automated information processing = and smart environments? TOPICS Wireless Networking Web and Grid Services Sensor and Mobile Databases Collaborative Signal Processing Sensor Metadata Interoperability and Management Secure Wireless Sensor Networks Signal-based Automated Information Processing Sensor Grids and Sensor Registry Environmental Surveillance Monitoring SPEAKERS Ian Foster - http://www-fp.mcs.anl.gov/~foster/ Sajal Das - http://ranger.uta.edu/~das/ Sandra Thuel - http://www.bell-labs.com/user/thuel/ ---------------------------------------------------------------------- PANAL SESSION ON RFID Fulfilling the promise of RFID: Applications, Case Studies and Future Research SCOPE Radio Frequency Identification (RFID) will certainly be an integral part = of most supply chains in 10 to 20 years' time. Up to now, however, RFID has failed to live up to its promise, remaining hurdled by limited implementation and applications, and has yet to be considered a = mainstream technology on its own. A range of technologies, from WiFi to Sensor Networks to RFID, is being explored for asset management to "smart" shelving - but what combination = of technologies solves the right sets of problems? How does one identify = the problems to solve? What are the capabilities of each technology to solve them in differing use scenarios? Where can WiFi be more useful vs. RFID = or EPC (Electronic Product Codes) in other situations? In this panel, we will discuss these questions, current and potential = future applications, and possibilities for further research and study. PANELISTS Dr. Rajit Gadh, UCLA Dr. Sa----------------------------------- KEYNOTES Wireless Networks Work - What's Next? Dr Victor Bahl, Microsoft Research RF Localization and the Internet of Things Professor Kaveh Pahlavan, Worcester Polytechnic Institute Context Modelng in Smart Environments: A Perspective from Pervasive Computing Professor Sajal K. Das, University of Texas at Arlington ---------------------------------------------------------------------- WORKSHOP ON WIRELESS NETWORKING, AUTOMATED INFORMATION PROCESSING, AND = WEB & GRID SERVICES The workshop will be hold on 4th Feb 2007 and is free to all registered participants of ISWPC 2007. SCOPE This workshop intends to serve as a forum for the exchange of new ideas, concepts, and results associated with three specific areas showing a = degree of convergence: Wireless Networking (WN), Grid and Web Services (GWS), = and Automated Information Processing (AIP). AIP is serving as a bridge = between WN and GWS and in this context is bringing out new exciting and = challenging issues. The workshop is addressing issues along the following lines = through a set of thought-provoking questions: Grid and Web Services Grid Computing: a new technology or a cheaper alternative? What are the financial and technological benefits of grid computing = versus cluster computing? What markets stand to benefit the most from grid computing? Does wireless access to computing grids open up new application/ service markets? Which ones? Do projected trends for future data processing needs align favorably = with the capabilities of computing grids? Wireless Networking How wireless sensor networks (WSN) integrate with wireless networking in general? How can WSNs characterize smart environments in our automated society? How to manage uncertainty due inhabitants' contexts in smart = environments? What significant automated information processing issues need to be addressed for context-aware resource management in smart environments? Beyond mere wireless access to grids: are there any wireless-specific services or applications that may benefit from grid computing? Automated Information Processing What information processing applications are good and poor matches for grids? What is automated in automated information processing? How to integrate syntactic and semantic issues in automated information processing? How AIP is serving as a bridge between grid and web services and = wireless networking? What role plays signal processing in automated information processing = and smart environments? TOPICS Wireless Networking Web and Grid Services Sensor and Mobile Databases Collaborative Signal Processing Sensor Metadata Interoperability and Management Secure Wireless Sensor Networks Signal-based Automated Information Processing Sensor Grids and Sensor Registry Environmental Surveillance Monitoring SPEAKERS Ian Foster - http://www-fp.mcs.anl.gov/~foster/ Sajal Das - http://ranger.uta.edu/~das/ Sandra Thuel - http://www.bell-labs.com/user/thuel/ ---------------------------------------------------------------------- PANAL SESSION ON RFID Fulfilling the promise of RFID: Applications, Case Studies and Future Research SCOPE Radio Frequency Identification (RFID) will certainly be an integral part = of most supply chains in 10 to 20 years' time. Up to now, however, RFID has failed to live up to its promise, remaining hurdled by limited implementation and applications, and has yet to be considered a = mainstream technology on its own. A range of technologies, from WiFi to Sensor Networks to RFID, is being explored for asset management to "smart" shelving - but what combination = of technologies solves the right sets of problems? How does one identify = the problems to solve? What are the capabilities of each technology to solve them in differing use scenarios? Where can WiFi be more useful vs. RFID = or EPC (Electronic Product Codes) in other situations? In this panel, we will discuss these questions, current and potential = future applications, and possibilities for further research and study. PANELISTS Dr. Rajit Gadh, UCLA Dr. Salil Pradhan, CTO, HP RFID Program Dr. Dario Sassi Thober, Wernher Von Braun Center for Advanced Research, Campinas, Brazil Marcelo de Carvalho Pandini, Manager, RFID & Business Development, Hewlett-Packard Brazil Martina Y. Trucco, University Relations Latin America, Hewlett-Packard = Labs ------=_NextPart_000_01BC_01C734C4.48211330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(Apologies if you receive multiple = copies of this=20 message)

---------------------------------------------------------= -------------

CALL=20 FOR PARTICIPATION

International Symposium on Wireless Pervasive = Computing=20 2007
           = ;            =     =20 (ISWPC=20 2007)
          &nbs= p; =20 5-7 February 2007, San Juan, Puerto Rico,=20 USA
           =          =20 http://www.iswpc.org/2007/


          &nbs= p;          =20 Technically Sponsored By
IEEE Communications Society and IEEE = Vehicular=20 Technology=20 Society

         &nbs= p;           =20 Hosted By
University of Puerto Rico at=20 Mayaguez

---------------------------------------------------------= -------------

SCOPE

Wireless=20 pervasive computing is a rapidly growing area that has = attracted
significant=20 attention due to its potential impact on the quality of
lifestyles of = individuals. To enable wireless pervasive computing, it is
necessary = to=20 integrate technologies from the fields of communications,
signal = processing,=20 distributed computing, and numerous other fields. The aim
of this = symposium=20 is to provide a platform for researchers in the area of
wireless = pervasive=20 computing and related areas to showcase their results,
launch new = ideas, as=20 well as to interact with colleagues from these areas.

The scope = of the=20 symposium covers all enabling technologies of wireless
pervasive = computing.=20 This includes a huge variety of topics ranging from
wireless = communications=20 and networking to services and applications of
pervasive computing. A = series=20 of panel and tutorials will also seek to
inform and invoke = interaction among=20 researchers which are interested in=20 this
area.

----------------------------------------------------= ------------------

KEYNOTES

Wireless=20 Networks Work - What's Next?
Dr Victor Bahl, Microsoft = Research

RF=20 Localization and the Internet of Things
Professor Kaveh Pahlavan, = Worcester=20 Polytechnic Institute

Context Modelng in Smart Environments: A=20 Perspective from Pervasive
Computing
Professor  Sajal K. Das, = University of Texas at=20 Arlington

--------------------------------------------------------= --------------

WORKSHOP=20 ON WIRELESS NETWORKING, AUTOMATED INFORMATION PROCESSING, AND WEB = &
GRID=20 SERVICES

The workshop will be hold on 4th Feb 2007 and is free to = all=20 registered
participants of ISWPC 2007.

SCOPE
This workshop = intends=20 to serve as a forum for the exchange of new ideas,
concepts, and = results=20 associated with three specific areas showing a degree
of convergence: = Wirlil Pradhan, CTO, HP RFID Program Dr. Dario Sassi Thober, Wernher Von Braun Center for Advanced Research, Campinas, Brazil Marcelo de Carvalho Pandini, Manager, RFID & Business Development, Hewlett-Packard Brazil Martina Y. Trucco, University Relations Latin America, Hewlett-Packard = Labs ------=_NextPart_000_01BC_01C734C4.48211330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(Apologies if you receive multiple = copies of this=20 message)

---------------------------------------------------------= -------------

CALL=20 FOR PARTICIPATION

International Symposium on Wireless Pervasive = Computing=20 2007
           = ;            =     =20 (ISWPC=20 2007)
          &nbs= p; =20 5-7 February 2007, San Juan, Puerto Rico,=20 USA
           =          =20 http://www.iswpc.org/2007/


          &nbs= p;          =20 Technically Sponsored By
IEEE Communications Society and IEEE = Vehicular=20 Technology=20 Society

         &nbs= p;           =20 Hosted By
University of Puerto Rico at=20 Mayaguez

---------------------------------------------------------= -------------

SCOPE

Wireless=20 pervasive computing is a rapidly growing area that has = attracted
significant=20 attention due to its potential impact on the quality of
lifestyles of = individuals. To enable wireless pervasive computing, it is
necessary = to=20 integrate technologies from the fields of communications,
signal = processing,=20 distributed computing, and numerous other fields. The aim
of this = symposium=20 is to provide a platform for researchers in the area of
wireless = pervasive=20 computing and related areas to showcase their results,
launch new = ideas, as=20 well as to interact with colleagues from these areas.

The scope = of the=20 symposium covers all enabling technologies of wireless
pervasive = computing.=20 This includes a huge variety of topics ranging from
wireless = communications=20 and networking to services and applications of
pervasive computing. A = series=20 of panel and tutorials will also seek to
inform and invoke = interaction among=20 researchers which are interested in=20 this
area.

----------------------------------------------------= ------------------

KEYNOTES

Wireless=20 Networks Work - What's Next?
Dr Victor Bahl, Microsoft = Research

RF=20 Localization and the Internet of Things
Professor Kaveh Pahlavan, = Worcester=20 Polytechnic Institute

Context Modelng in Smart Environments: A=20 Perspective from Pervasive
Computing
Professor  Sajal K. Das, = University of Texas at=20 Arlington

--------------------------------------------------------= --------------

WORKSHOP=20 ON WIRELESS NETWORKING, AUTOMATED INFORMATION PROCESSING, AND WEB = &
GRID=20 SERVICES

The workshop will be hold on 4th Feb 2007 and is free to = all=20 registered
participants of ISWPC 2007.

SCOPE
This workshop = intends=20 to serve as a forum for the exchange of new ideas,
concepts, and = results=20 associated with three specific areas showing a degree
of convergence: = Wireless Networking (WN), Grid and Web Services (GWS), and
Automated=20 Information Processing (AIP). AIP is serving as a bridge between
WN = and GWS=20 and in this context is bringing out new exciting and = challenging
issues. The=20 workshop is addressing issues along the following lines through
a set = of=20 thought-provoking questions:

Grid and Web Services
Grid = Computing: a=20 new technology or a cheaper alternative?
What are the financial and=20 technological benefits of grid computing versus
cluster = computing?
What=20 markets stand to benefit the most from grid computing?
Does wireless = access=20 to computing grids open up new application/ service
markets? Which=20 ones?
Do projected trends for future data processing needs align = favorably=20 with
the capabilities of computing grids?

Wireless = Networking
How=20 wireless sensor networks (WSN) integrate with wireless networking=20 in
general?
How can WSNs characterize smart environments in our = automated=20 society?
How to manage uncertainty due inhabitants' contexts in smart = environments?
What significant automated information processing = issues need=20 to be
addressed for context-aware resource management in smart=20 environments?
Beyond mere wireless access to grids: are there any=20 wireless-specific
services or applications that may benefit from grid = computing?

Automated Information Processing
What information=20 processing applications are good and poor matches for
grids?
What = is=20 automated in automated information processing?
How to integrate = syntactic and=20 semantic issues in automated information
processing?
How AIP is = serving as=20 a bridge between grid and web services and = wireless
networking?
What role=20 plays signal processing in automated information processing and
smart = environments?

TOPICS
Wireless Networking
Web and Grid=20 Services
Sensor and Mobile Databases
Collaborative Signal=20 Processing
Sensor Metadata Interoperability and Management
Secure = Wireless=20 Sensor Networks
Signal-based Automated Information = Processing
Sensor Grids=20 and Sensor Registry
Environmental Surveillance=20 Monitoring

SPEAKERS
Ian Foster - http://www-fp.mcs.anl.gov/~foster/
Sajal Das -=20 http://ranger.uta.edu/~das/
Sandra Thuel - http://www.bell-labs.com/user/thuel/

----------------------------------------------------------------= ------

PANAL=20 SESSION ON RFID
Fulfilling the promise of RFID: Applications, Case = Studies=20 and Future
Research

SCOPE
Radio Frequency Identification = (RFID)=20 will certainly be an integral part of
most supply chains in 10 to 20 = years'=20 time. Up to now, however, RFID has
failed to live up to its promise,=20 remaining hurdled by limited
implementation and applications, and has = yet to=20 be considered a mainstream
technology on its own.
A range of = technologies,=20 from WiFi to Sensor Networks to RFID, is being
explored for asset = management=20 to "smart" shelving - but what combination of
technologies solves the = right=20 sets of problems? How does one identify the
problems to solve? What = are the=20 capabilities of each technology to solve
them in differing use = scenarios?=20 Where can WiFi be more useful vs. RFID or
EPC (Electronic Product = Codes) in=20 other situations?
In this panel, we will discuss these questions, = current and=20 potential future
applications, and possibilities for further research = and=20 study.

PANELISTS
Dr. Rajit Gadh, UCLA
Dr. Salil Pradhan, = CTO, HP=20 RFID Program
Dr. Dario Sassi Thober, Wernher Von Braun Center for = Advanced=20 Research,
Campinas, Brazil
Marcelo de Carvalho Pandini, Manager, = RFID=20 & Business Developmenteless Networking (WN), Grid and Web Services (GWS), and
Automated=20 Information Processing (AIP). AIP is serving as a bridge between
WN = and GWS=20 and in this context is bringing out new exciting and = challenging
issues. The=20 workshop is addressing issues along the following lines through
a set = of=20 thought-provoking questions:

Grid and Web Services
Grid = Computing: a=20 new technology or a cheaper alternative?
What are the financial and=20 technological benefits of grid computing versus
cluster = computing?
What=20 markets stand to benefit the most from grid computing?
Does wireless = access=20 to computing grids open up new application/ service
markets? Which=20 ones?
Do projected trends for future data processing needs align = favorably=20 with
the capabilities of computing grids?

Wireless = Networking
How=20 wireless sensor networks (WSN) integrate with wireless networking=20 in
general?
How can WSNs characterize smart environments in our = automated=20 society?
How to manage uncertainty due inhabitants' contexts in smart = environments?
What significant automated information processing = issues need=20 to be
addressed for context-aware resource management in smart=20 environments?
Beyond mere wireless access to grids: are there any=20 wireless-specific
services or applications that may benefit from grid = computing?

Automated Information Processing
What information=20 processing applications are good and poor matches for
grids?
What = is=20 automated in automated information processing?
How to integrate = syntactic and=20 semantic issues in automated information
processing?
How AIP is = serving as=20 a bridge between grid and web services and = wireless
networking?
What role=20 plays signal processing in automated information processing and
smart = environments?

TOPICS
Wireless Networking
Web and Grid=20 Services
Sensor and Mobile Databases
Collaborative Signal=20 Processing
Sensor Metadata Interoperability and Management
Secure = Wireless=20 Sensor Networks
Signal-based Automated Information = Processing
Sensor Grids=20 and Sensor Registry
Environmental Surveillance=20 Monitoring

SPEAKERS
Ian Foster - http://www-fp.mcs.anl.gov/~foster/
Sajal Das -=20 http://ranger.uta.edu/~das/
Sandra Thuel - http://www.bell-labs.com/user/thuel/

----------------------------------------------------------------= ------

PANAL=20 SESSION ON RFID
Fulfilling the promise of RFID: Applications, Case = Studies=20 and Future
Research

SCOPE
Radio Frequency Identification = (RFID)=20 will certainly be an integral part of
most supply chains in 10 to 20 = years'=20 time. Up to now, however, RFID has
failed to live up to its promise,=20 remaining hurdled by limited
implementation and applications, and has = yet to=20 be considered a mainstream
technology on its own.
A range of = technologies,=20 from WiFi to Sensor Networks to RFID, is being
explored for asset = management=20 to "smart" shelving - but what combination of
technologies solves the = right=20 sets of problems? How does one identify the
problems to solve? What = are the=20 capabilities of each technology to solve
them in differing use = scenarios?=20 Where can WiFi be more useful vs. RFID or
EPC (Electronic Product = Codes) in=20 other situations?
In this panel, we will discuss these questions, = current and=20 potential future
applications, and possibilities for further research = and=20 study.

PANELISTS
Dr. Rajit Gadh, UCLA
Dr. Salil Pradhan, = CTO, HP=20 RFID Program
Dr. Dario Sassi Thober, Wernher Von Braun Center for = Advanced=20 Research,
Campinas, Brazil
Marcelo de Carvalho Pandini, Manager, = RFID=20 & Business Development,
Hewlett-Packard Brazil
Martina Y. = Trucco,=20 University Relations Latin America, Hewlett-Packard=20 Labs

------=_NextPart_000_01BC_01C734C4.48211330-- --===============1429600325== 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/ --===============1429600325==-- From mip4-bounces@ietf.org Thu Jan 11 11:03:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ot-0003TA-Q9; Thu, 11 Jan 2007 11:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4YjK-0006Cv-Pv; Wed, 10 Jan 2007 03:22:42 -0500 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4YjI-0003QS-Ja; Wed, 10 Jan 2007 03:22:42 -0500 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.13.7/jtpda-5.3.1) with ESMTP id l0A8LRrR027906 ; Wed, 10 Jan 2007 09:21:27 +0100 Received: from ROMY (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l0A8L4300329 ; Wed, 10 Jan 2007 09:21:04 +0100 (MET) From: "Nathalie Mitton" To: "Nathalie Mitton" Date: Wed, 10 Jan 2007 09:21:06 +0100 Organization: LIFL Message-ID: <000001c73490$54b19e50$d80bce86@ROMY> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc0kEYNrGfodsY6Sc+s92x+nrzv3g== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Wed, 10 Jan 2007 09:21:33 +0100 (CET) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@insa-lyon.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 82399e64b40cc35c75057a238056f806 X-Mailman-Approved-At: Thu, 11 Jan 2007 11:03:34 -0500 Cc: Subject: [Mip4] Call for Workshops: 4-th IEEE MASS 2007 (Oct. 8-11, Pisa, Italy) 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="===============1875310796==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1875310796== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C73498.B6760650" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C73498.B6760650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning everyone, Please find below a call for workshops proposals which would be held in conjunction with MASS 2007 in October in Pisa, Italy. Workshops proposals submission deadline is February 9, 2007. The deadline for submitting paper to MASS 2007 (http://cnd.iit.cnr.it/mass2007/) is March 31, 2007. This message is cross-posted to several lists. Apologies for any duplicate postings. ---------------------------------------------------------------------------- - CALL FOR WORKSHOPS PROPOSALS Fourth IEEE International Conference on Mobile Ad-Hoc and Sensor Systems MASS 2007 (http://cnd.iit.cnr.it/mass2007/) Pisa, Italy, October 8-11, 2007 --------------------------------------------------------,
Hewlett-Packard Brazil
Martina Y. = Trucco,=20 University Relations Latin America, Hewlett-Packard=20 Labs

------=_NextPart_000_01BC_01C734C4.48211330-- --===============1429600325== 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/ --===============1429600325==-- From mip4-bounces@ietf.org Thu Jan 11 11:03:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ot-0003TA-Q9; Thu, 11 Jan 2007 11:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4YjK-0006Cv-Pv; Wed, 10 Jan 2007 03:22:42 -0500 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4YjI-0003QS-Ja; Wed, 10 Jan 2007 03:22:42 -0500 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.13.7/jtpda-5.3.1) with ESMTP id l0A8LRrR027906 ; Wed, 10 Jan 2007 09:21:27 +0100 Received: from ROMY (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l0A8L4300329 ; Wed, 10 Jan 2007 09:21:04 +0100 (MET) From: "Nathalie Mitton" To: "Nathalie Mitton" Date: Wed, 10 Jan 2007 09:21:06 +0100 Organization: LIFL Message-ID: <000001c73490$54b19e50$d80bce86@ROMY> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc0kEYNrGfodsY6Sc+s92x+nrzv3g== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Wed, 10 Jan 2007 09:21:33 +0100 (CET) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@insa-lyon.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 82399e64b40cc35c75057a238056f806 X-Mailman-Approved-At: Thu, 11 Jan 2007 11:03:34 -0500 Cc: Subject: [Mip4] Call for Workshops: 4-th IEEE MASS 2007 (Oct. 8-11, Pisa, Italy) 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="===============1875310796==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1875310796== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C73498.B6760650" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C73498.B6760650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning everyone, Please find below a call for workshops proposals which would be held in conjunction with MASS 2007 in October in Pisa, Italy. Workshops proposals submission deadline is February 9, 2007. The deadline for submitting paper to MASS 2007 (http://cnd.iit.cnr.it/mass2007/) is March 31, 2007. This message is cross-posted to several lists. Apologies for any duplicate postings. ---------------------------------------------------------------------------- - CALL FOR WORKSHOPS PROPOSALS Fourth IEEE International Conference on Mobile Ad-Hoc and Sensor Systems MASS 2007 (http://cnd.iit.cnr.it/mass2007/) Pisa, Italy, October 8-11, 2007 ---------------------------------------------------------------------------- -- **** Workshop Proposals Deadline --- February 9, 2007 **** Sponsored by IEEE and IEEE Computer Society Co-sponsored by the IEEE TCCC and the IEEE TCPP ---------------------------------------------------------------------------- -- IEEE MASS 2007 will be the fourth annual conference on the rapidly expanding area of multi-hop wireless computing and sensor networking, and will provide an exciting platform for discussing research vision of a digitally networked wireless environment. The MASS Organizing Committee invites proposals for one-day workshops affiliated with the conference. The workshops will be held prior to, or after, the main conference. The purpose of these workshops is to provide a platform for presenting novel ideas and more specific research areas in a less formal and possibly more focused way than at the conference itself. Please visit http://www.cse.fau.edu/mass2006/workshops.html to view information on workshops held last year at MASS 2006. Workshops Proposals are solicited in all areas and topics pertaining to ad-hoc wireless and sensor networking research and applications, including, but not limited to, theoretical performance bounds for ad-hoc networks, sensor and wireless network and application security/privacy, mesh networks, middleware platforms and applications of specific techniques (e.g., control theory or biological networks) to wireless networks. We expect all selected workshops to adhere to a common paper submission and reviewing schedule outlined below. All papers included in the MASS 2007 workshops will appear in the MASS 2007 Proceedings published by IEEE. ------------------------------- Proposal Submission Guidelines: ------------------------------- Each workshop proposal must include: 1. The name of the workshop. 2. The names, addresses, and a short bio (up to 200 words) of the organizers (maximum up to three). 3. A brief description (up to 1 page) of the technical issues that the workshop will address, and the reasons why the workshop is of interest this time. 4. The names of potential participants, such as program committee members, 5. Planned format of the workshop, such as number of refereed papers, keynotes, panels etc. 6. If appropriate, a description of past versions of the workshop, including: number of submitted and accepted papers, number of attendees. 7. A description of the publicity plan. 8. A call for papers 9. The workshop website address Workshop proposals should be submitted, no later than February 9, 2007, by e-mail (in PDF format) with "MASS 2007 Workshop Proposal" in the subject, to BOTH MASS 2007 Workshop Co-chairs: Luciano Bononi Department of Computer Science, University of Bologna, Italy Mura Anteo Zamboni 7, 40127, Bologna, Italy E-mail: bononi@cs.unibo.it and Archan Misra IBM T.J. Watson Research Center 19 Skyline Drive, Room 2N-B18 Hawthorne, NY 10532 Email: archan@us.ibm.com ---------------- IMPORTANT DATES: ---------------- Proposals submission deadline: February 9, 2007 Acceptance/Reject notification: February 21, 2007 Papers due by: April 30, 2005 Paper selections due by: July 15, 2007 Final papers due to IEEE: August 10, 2007 -- ------=_NextPart_000_0001_01C73498.B6760650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good morning everyone, =

 

Please find below a call for workshops = proposals which would be held in conjunction with MASS 2007 in October = in Pisa, Italy.

Workshops proposals submission deadline is = February 9, 2007.

The deadline for submitting paper to MASS 2007 = (http://cnd.iit.cnr.it/mass2007/<= /a>) is March 31, 2007.

 

This message is cross-posted to several lists. = Apologies for any duplicate postings.

 

Good morning everyone, =

 

Please find below a call for workshops = proposals which would be held in conjunction with MASS 2007 in October = in Pisa, Italy.

Workshops proposals submission deadline is = February 9, 2007.

The deadline for submitting paper to MASS 2007 = (http://cnd.iit.cnr.it/mass2007/<= /a>) is March 31, 2007.

 

This message is cross-posted to several lists. = Apologies for any duplicate postings.

 

 

-----------------------------------------------= ------------------------------

  &nb= sp;           &nbs= p;          CALL FOR WORKSHOPS PROPOSALS

 

  Fourth IEEE International Conference on = Mobile Ad-Hoc and Sensor = Systems

        = ;            =             &= nbsp; MASS  2007

        = ;            =    (http://cnd.iit.cnr.it/mass2007/)

 

        = ;            =     Pisa, Italy, October 8-11, 2007

-----------------------------------------------= -------------------------------

 

 

        = ;   **** Workshop Proposals Deadline --- = February 9, 2007 = ****

 

        = ;            =              = Sponsored by

 

-----------------------------------------------= ------------------------------

  &nb= sp;           &nbs= p;          CALL FOR WORKSHOPS PROPOSALS

 

  Fourth IEEE International Conference on = Mobile Ad-Hoc and Sensor = Systems

        = ;            =             &= nbsp; MASS  2007

        = ;            =    (http://cnd.iit.cnr.it/mass2007/)

 

        = ;            =     Pisa, Italy, October 8-11, 2007

-----------------------------------------------= -------------------------------

 

 

        = ;   **** Workshop Proposals Deadline --- = February 9, 2007 = ****

 

        = ;            =              = Sponsored by

        = ;            =     IEEE and IEEE Computer Society

        = ;            =   

        = ;        Co-sponsored by the IEEE = TCCC and the IEEE TCPP

 

-----------------------------------------------= -------------------------------

 

 

IEEE MASS 2007 will be the fourth annual = conference on the rapidly expanding

area of multi-hop wireless computing and = sensor networking, and will provide

an exciting platform for discussing research = vision of a digitally networked

wireless environment. =

 

The MASS Organizing Committee invites = proposals for one-day workshops

affiliated with the conference. =

The workshops will be held prior to, or after, = the main conference.

 

The purpose of these workshops is to provide a platform for presenting novel

ideas and more specific research areas in a = less formal and possibly more

focused way than at the conference itself. =

Please visit http://www.cse.fau.edu/mass2006/workshops.html to view =

        = ;            =     IEEE and IEEE Computer Society

        = ;            =   

        = ;        Co-sponsored by the IEEE = TCCC and the IEEE TCPP

 

-----------------------------------------------= -------------------------------

 

 

IEEE MASS 2007 will be the fourth annual = conference on the rapidly expanding

area of multi-hop wireless computing and = sensor networking, and will provide

an exciting platform for discussing research = vision of a digitally networked

wireless environment. =

 

The MASS Organizing Committee invites = proposals for one-day workshops

affiliated with the conference. =

The workshops will be held prior to, or after, = the main conference.

 

The purpose of these workshops is to provide a platform for presenting novel

ideas and more specific research areas in a = less formal and possibly more

focused way than at the conference itself. =

Please visit http://www.cse.fau.edu/mass2006/workshops.html to view =

information on workshops held last year at = MASS 2006.

 

Workshops Proposals are solicited in all areas = and topics pertaining to

ad-hoc wireless and sensor networking research = and applications, including,

but not limited to, theoretical performance = bounds for ad-hoc networks,

sensor and wireless network and application security/privacy, mesh networks,

middleware platforms and applications of = specific techniques (e.g., control

theory or biological networks) to wireless = networks.

We expect all selected workshops to adhere to = a common paper submission and

reviewing schedule outlined below. All papers included in the MASS 2007

workshops will appear in the MASS 2007 = Proceedings published by IEEE.

 

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

 

Proposal Submission = Guidelines:

 

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

 

Each workshop proposal must = include:

 

1. The name of the = workshop.

 information on workshops held last year at = MASS 2006.

 

Workshops Proposals are solicited in all areas = and topics pertaining to

ad-hoc wireless and sensor networking research = and applications, including,

but not limited to, theoretical performance = bounds for ad-hoc networks,

sensor and wireless network and application security/privacy, mesh networks,

middleware platforms and applications of = specific techniques (e.g., control

theory or biological networks) to wireless = networks.

We expect all selected workshops to adhere to = a common paper submission and

reviewing schedule outlined below. All papers included in the MASS 2007

workshops will appear in the MASS 2007 = Proceedings published by IEEE.

 

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

 

Proposal Submission = Guidelines:

 

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

 

Each workshop proposal must = include:

 

1. The name of the = workshop.

 

2. The names, addresses, and a short bio (up = to 200 words) of the

   organizers (maximum up to = three).

 

3. A brief description (up to 1 = page) of the technical issues that the

   workshop will address, and the = reasons why the workshop is of interest

   this = time.

 

4. The names of potential participants, such = as program committee members,

 

5. Planned format of the workshop, such as = number of refereed papers,

   keynotes, panels = etc.

 

6. If appropriate, a description of past = versions of the workshop,

   including: number of submitted = and accepted papers, number of attendees.

 

7. A description of the = publicity plan.

 

8. A call for = papers

 

p>

2. The names, addresses, and a short bio (up = to 200 words) of the

   organizers (maximum up to = three).

 

3. A brief description (up to 1 = page) of the technical issues that the

   workshop will address, and the = reasons why the workshop is of interest

   this = time.

 

4. The names of potential participants, such = as program committee members,

 

5. Planned format of the workshop, such as = number of refereed papers,

   keynotes, panels = etc.

 

6. If appropriate, a description of past = versions of the workshop,

   including: number of submitted = and accepted papers, number of attendees.

 

7. A description of the = publicity plan.

 

8. A call for = papers

 

9. The workshop website = address

 

Workshop proposals should be submitted, no = later than February 9, 2007,

by e-mail (in PDF format) with "MASS 2007 Workshop Proposal" in the subject,

to BOTH MASS 2007 Workshop = Co-chairs:

 

 

  Luciano = Bononi

  Department of Computer Science, = University of Bologna, Italy

  Mura Anteo = Zamboni 7, 40127, Bologna, Italy

  E-mail: = bononi@cs.unibo.it

 

  and=

 

  Archan = Misra

  IBM T.J. Watson Research Center

  19 Skyline Drive, Room = 2N-B18

  Hawthorne, NY 10532

9. The workshop website = address

 

Workshop proposals should be submitted, no = later than February 9, 2007,

by e-mail (in PDF format) with "MASS 2007 Workshop Proposal" in the subject,

to BOTH MASS 2007 Workshop = Co-chairs:

 

 

  Luciano = Bononi

  Department of Computer Science, = University of Bologna, Italy

  Mura Anteo = Zamboni 7, 40127, Bologna, Italy

  E-mail: = bononi@cs.unibo.it

 

  and=

 

  Archan = Misra

  IBM T.J. Watson Research Center

  19 Skyline Drive, Room = 2N-B18

  Hawthorne, NY 10532

  Email: = archan@us.ibm.com

 

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

IMPORTANT DATES:

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

 

Proposals submission = deadline:          February = 9, 2007

Acceptance/Reject = notification:         February = 21, 2007

 

Papers due = by:           &nbs= p;            = ;  April 30, 2005

Paper selections due = by:           &nbs= p;    July 15, 2007

Final papers due to = IEEE:           &n= bsp;   August 10, 2007

 

--

------=_NextPart_000_0001_01C73498.B6760650-- --===============1875310796== 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/ --===============1875310796==-- 2 face=3DArial>  Email: = archan@us.ibm.com

 

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

IMPORTANT DATES:

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

 

Proposals submission = deadline:          February = 9, 2007

Acceptance/Reject = notification:         February = 21, 2007

 

Papers due = by:           &nbs= p;            = ;  April 30, 2005

Paper selections due = by:           &nbs= p;    July 15, 2007

Final papers due to = IEEE:           &n= bsp;   August 10, 2007

 

--

------=_NextPart_000_0001_01C73498.B6760650-- --===============1875310796== 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/ --===============1875310796==-- From mip4-bounces@ietf.org Fri Jan 12 12:13:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Py1-0002SG-6A; Fri, 12 Jan 2007 12:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Pxz-0002RX-QN; Fri, 12 Jan 2007 12:13:23 -0500 Received: from tmailer.gwdg.de ([134.76.10.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Pxv-0004j1-Ai; Fri, 12 Jan 2007 12:13:23 -0500 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.22.0.58]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1H5Pxr-0000Xr-VE; Fri, 12 Jan 2007 18:13:16 +0100 Message-ID: <45A7C1A8.5060805@cs.uni-goettingen.de> Date: Fri, 12 Jan 2007 18:13:12 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mipshop@ietf.org, mobopts@irtf.org, mip4@ietf.org, mip6@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [Mip4] CFP: MobiArch'07 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 [Apologies if you receive multiple copies of this CFP] -------------------------------------------------------------------- The Second International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2007) Kyoto, Japan, August 27, 2007 (to be held with ACM SIGCOMM 2007, August 27-31, 2007) http://user.informatik.uni-goettingen.de/~mobiarch/2007 -------------------------------------------------------------------- With the recent development of technologies in wireless access and mobile devices, user, terminal, and network mobility has become an indispensable component of today's Internet vision, and it is likely to continue in the near future, while affecting the whole architectural design of the future Internet. Yet, issues like efficient mobility management and optimization, locator-identifier split, multihoming, security, and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles, and business models will require rethinking due to the massive penetration of mobility into the Internet. MobiArch'07 welcomes submissions, from both researchers and practitioners, in exploration of recent advances in architectures, protocols, and experiences with emerging technologies on wireless and mobility over the Internet, with an emphasis on wireless infrastructures and mobility patterns for mobility support, new mobility protocols, service discovery, routing and location management, mobile network performance evaluation and modeling, multi-homing, security, architectural impacts and deployment considerations. Topics of Interest: ================== Topics of MobiArch’07 cover all aspects of architectural issues and system support for wireless and mobility in the Internet, including but not limited to: - Impacts of new wireless technologies/services and mobility patterns on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link, network, transport to session/application layers and cross-layer design - Location management, positioning and data management systems for wireless and mobility - Routing and addressing, including locator/identifier split issues and their impacts to the Internet architecture - IP multihoming including flow distribution and load sharing for wireless and mobility - Performance evaluation, experimentation and modeling of mobility in the Internet - Accounting, access control, security and privacy issues and impacts to Internet architecture - Economic, scalability and deployment issues of mobility infrastructure design - Mechanisms and issues with connecting developing regions into the Internet Following the success of MobiArch'06, the MobiArch'07 workshop will be a single-track one-day workshop. Early stages, position papers, systems and measurement papers will be particularly welcome. The proceedings will be published by the ACM and ACM digital library. Submissions: =========== Submissions must be made to MobiArch'07 EDAS entry: http://edas.info/5238, following the guidelines in MobiArch'07 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/2007 Important Dates: =============== Abstract registration: March 20, 2007 Submission Deadline: March 27, 2007 Acceptance Notification: May 15, 2007 Camera-ready version due: June 12, 2007 MobiArch'07 Workshop: August 27, 2007 SIGCOMM'07: August 27-31, 2007 PROGRAM CO-CHAIRS ================= Xiaoming Fu, University of Goettingen (Germany) Katherine Guo, Bell Labs (USA) Sue Moon, KAIST (Korea) Ryuji Wakikawa, Keio University (Japan) PUBLICITY CHAIR =============== Jon Crowcroft, University of Cambridge (UK) QUESTIONS ========= Please consult the Program Co-Chairs (mobiarch@informatik.uni-goettingen.de) if you are uncertain whether your paper falls within the scope of the workshop. -- 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 Jan 15 11:09:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UOy-0007V6-C1; Mon, 15 Jan 2007 11:09:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UOx-0007Ud-Gr for mip4@ietf.org; Mon, 15 Jan 2007 11:09:39 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6UOx-0001yM-0f for mip4@ietf.org; Mon, 15 Jan 2007 11:09:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1168877375!14246759!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 29667 invoked from network); 15 Jan 2007 16:09:35 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-9.tower-119.messagelabs.com with SMTP; 15 Jan 2007 16:09:35 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0FG9QO1012382; Mon, 15 Jan 2007 09:09:26 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0FG9Ox8022875; Mon, 15 Jan 2007 10:09:25 -0600 (CST) Message-ID: <45ABA733.7070001@motorola.com> Date: Mon, 15 Jan 2007 17:09:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vijay Devarapalli References: <457E204A.5060609@azairenet.com> In-Reply-To: <457E204A.5060609@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: "Kent Leung \(kleung\)" , mip4@ietf.org Subject: [Mip4] Re: Comments on draft-ietf-nemo-v4-base-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 Vijay, thanks for detail comments. I responded one by one to the different issues you raised, with proposed text. Please let us know whether resolution is fine with you, whether not, whether you'd like me to split every issue on a different mail, etc. Vijay Devarapalli wrote: > Hello, > > Here are some comments on draft-ietf-nemo-v4-base-01.txt > > Some high level comments > > - The terms "subnet", "prefix" and "mobile network" are used > interchangeably in many places. Needs to be fixed throughout in the > document. Ok, tried to substitute 'mobile network prefix' in several places where 'subnet' appears. > - Support for mobile networks using the FA CoA mode is not explained > clearly. Ok, trying to clear that. The goal is to have as little as possible FA talkin this document, ideally none at all. There's another draft looking about enhancing FA for moving network support. The goal is also to have this draft work ok when 'legacy' FAs are present. Would you agree with the generic idea to completely avoid FA text in this 'base' draft? It would involve removal of following text about: (1) intermerdiary tunnel optimization (3) MR obtains a FA CoA (4) HA replies back to FA (5) HA encapsulates to FA (6) MR routes packet to FA. > - Running a dynamic routing protocol between the mobile router and > the home agent probably does not work when FA-CoA mode is used. Ok, good to know. Even more reason to reduce the FA talk in this document. >> IPv4 Network Mobility (NEMO) Basic Support Protocol > > Lets just call it "IPv4 Network Mobility (NEMO) Protocol". The Basic > Support was used for NEMOv6 since there was a plan to work on route > optimization for NEMOv6 and this was called Extended Support. Its not > the same with MIPv4 and IPv4 NEMO. I agree. I've changed the title to "IPv4 Network Mobility (NEMO) Protocol". If anybody is against this change in title please say so. Remark the Charter main nemo text doesn't use "basic support" but does use "base protocol" in the timeline. If we change the draft title then the timeline should be updated too. >> This document describes the support of Mobile Networks, as defined >> in Mobile IPv4, by the Mobile Router and Home Agent. > > This statement is confusing. What does "as defined in Mobile IPv4" > mean? Perhaps rephrase to > > This document describes a protocol for supporting Mobile Networks > between a Mobile Router and a Home Agent by extending the Mobile IPv4 > protocol. I agree it's less confusing, I've copypasted. >> This document describes protocol extensions to Mobile IPv4 >> ([RFC3344]) to enable support for Mobile Networks. A Mobile >> Network is defined as a network segment or subnet that can change >> its point of attachment to the routing infrastructure. Such >> movement is performed by a Mobile Router, which is the mobility >> entity that provides connectivity and reachability as well as >> session continuity for all the nodes in the Mobile Network. The >> Mobile Router typically serves as the default gateway for the >> devices on the Mobile Network. > > s/devices/hosts/ Done. >> Mobility for the Mobile Network is supported by the Mobile Router >> registering the point of attachment to its Home Agent. This >> signaling sets up the tunnel between the two entities. The Mobile >> Networks (either implicitly configured on the Home Agent or >> explicitly identified by the Mobile Router) are advertised by the >> Home Agent for route propagation. Traffic to and from nodes in the >> Mobile Network are tunneled by the Home Agent to the Mobile >> Router, and vice versa. Though packets from the Mobile Network can >> be forwarded directly without tunneling when reverse tunneling is >> not enabled, > > Not just "not enabled" but also "not used". Ok. >> reachability is still subject to ingress filtering conditions for >> the path in this case. > > What reachability? I guess you want to say packets can be dropped if > ingress filtering is turned on. Changed to: > Though packets from the Mobile Network can be forwarded directly > without tunneling (if reverse tunneling is not used) packets will be > dropped if ingress filtering is turned on. Ok that? >> This document specifies an additional tunnel between Mobile >> Router's Home Address and the Home Agent. This tunnel is >> encapsulated within the normal tunnel between the Care-of Address >> (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between >> the Mobile Router and Home Agent is needed to allow the Foreign >> Agent to direct the decapsulated packet to the proper visiting >> Mobile Router. > > Lets take an example. > > IPv4 hdr (src=HA, dst=FA-CoA) IPv4 hdr (src=HA, dst=HoA) IPv4 hdr > (src=CN, dst=MNN) Payload > > I borrowed the MNN terminology for NEMOv6 to indicate a host that is > attached to the mobile network. The above packet format is always > used for FA CoA mode, correct? Yes, should be correct. I think that additional tunnel for FA-CoA mode should be specified in the FA NEMO draft. >> However, in Collocated CoA mode, the additional tunnel is not >> essential and can be eliminated because the Mobile Router is the >> recipient of the encapsulated packets for the Mobile Network. > > This would give us > > IPv4 hdr (src=HA, dst=CoA) IPv4 hdr (src=CN, dst=MNN) Payload > > This gives us a unique case of the packet overhead being the same for > the co-located CoA mode and the FA CoA mode. :) Yes, I understand. Looks strange to me too, but that's logical conclusion - tunnel overhead same for CCoA and FACoA modes, for a MR, not for a MH. I agree to remove the MR-FA-CoA tunnel overhead optimization, if that's what you suggest. However, I find the idea of clearly showing what encapsulated headers look like very appealing. Do you want me to add that? >> A similar protocol has been documented in [RFC3963] for supporting >> IPv6 moving networks with Mobile IPv6 extensions. > > s/moving networks/mobile networks/ Ok in this rfc3963 phrase. >> Although Mobile IPv4 stated that Mobile Network can be supported by >> the Mobile Router and Home Agent using static configuration or >> running a routing protocol, there is no solution for explicit >> registration of the Mobile Networks served by the Mobile Router. > > Perhaps elaborate to say that there is no mechanism for the home > agent to know that the mobile router is authorized to send routing > updates for a particular mobile network prefix? Is this the intention > of the above sentence? Yes, that's one intent. Another is for network debugging purposes: one would like to know looking at passing packets that a RegReq is for an entire network, not only for one host. One would like to see that distinction in the Regitration Table too. HEre's proposed text: > Although Mobile IPv4 stated that Mobile Network can be supported by > the Mobile Router and Home Agent using static configuration or > running a routing protocol, there is no solution for explicit > registration of the Mobile Networks served by the Mobile Router. A > solution needs to provide the Home Agent a means to ensure that a > Mobile Router claiming a certain Mobile Network Prefix is authorized > to do so. A solution would also expose the Mobile Network Prefixes > (and potentially other subnet-relevant information) in the exchanged > messages, to aid in network debugging. >> 4.2. Mobile Network Acknowledgement Extension >> >> The Registration Reply contains zero, one or several Mobile Network >> Acknowledgement extensions in addition to any other extensions >> defined by or in the context of ([RFC3344]). For Implicit Mode, >> the Mobile Network Acknowledgement informs the Mobile Router the >> prefixes served by the Home Agent. > > You mean owned by the Mobile Router? The Home Agent only sets up > forwarding for the mobile network prefix. Is this what you mean by > "served by the Home Agent"? changed that too, look: > The Registration Reply contains zero, one or several Mobile Network > Acknowledgement extensions in addition to any other extensions > defined by or in the context of ([RFC3344]). For Implicit Mode, the > Mobile Network Acknowledgement informs the Mobile Router the prefixes > for which the Home Agent sets up forwarding with respect to this > Mobile Router. [...] >> In accordance with this specification, a Mobile Router may operate >> in one of the following two modes: explicit and implicit. In >> explicit mode, the Mobile Router includes Mobile Network Prefix >> information in all Registration Requests (as Mobile Network Request >> extensions), while in implicit mode it does not include this >> information in any Registration Request. In this latter case, the >> Home Agent obtains the Mobile Network Prefixes by other means than >> Mobile IP. > > Perhaps give one example, like configuration on the home agent. What example would be more helpful to your reading? Can I say that the HA obtains the MR's routes from its routing table, from an ICMP Redirect sent by the BR or from a static configuration file. Or from all three. From another? >> A Mobile Router can obtain a Collocated or Foreign Agent Care-of- >> Address while operating in explicit or implicit modes. > > Whether the mobile router is using the explicit or implicit mode it > has no impact on FA or colocated CoA mode, right? Anyway re-phrase > the above sentence to > > A Mobile Router MAY use either Co-located or Foreign Agent Care-of > Address while operating in explicit or implicit mode. Ok. If we get rid entirely of specifying FA behaviour then I'd be completely silent about MR obtaining a FA CoA, would you agree to remove the FA CoA obtention. >> 1. Check that the subnet information is valid > > s/subnet/Mobile Network Prefix/ Ok. > We have used mobile network prefix or just mobile network so far. > >> 2. Ensure such subnet is authorized to be on the Mobile Router > > Same as above. Ok. >> 6.2.1. Registration Table >> >> The registration table in the Home Agent, in accordance with >> ([RFC3344]), contains binding information for every mobile node >> registered with it. > > Mention that the Registration Table is already defined in RFC 3344. Ok, now looks: > The Registration Table in the Home Agent, in accordance with > [RFC3344], contains binding information for every Mobile Node > registered with it. [RFC3344] defines the format of Registration > Table. [...] >> If all checks are successful, the Home Agent either creates a new >> entry(ies) for the Mobile Router or updates an existing binding >> entry(ies) for it > > Isn't there only one entry per Mobile Router? If there are two egress interfaces and moving simultaneously then there would be two HoAs, right? > Are you considering multiple home addresses per mobile router? Yes, one per interface. > Anyway a registration request can only modify one binding cache entry > at a time. It cannot modify more than one, right? Yes, because of that HoA. So text became: > If all checks are successful, the Home Agent either creates a new > entry for the Mobile Router or updates an existing binding entry for > it and returns a successful registration reply back to the Mobile > Router or the Foreign Agent (if the registration request was received > from a Foreign Agent). >> 6.4. Advertising Mobile Network Reachability >> >> If the mobile network prefixes served by the Home Agent are >> aggregated with the home network prefix and if the Home Agent is >> the default router on the home network, the Home Agent does not >> have to do anything different than normal. > > s/do anything different than normal/advertise the mobile network > prefixes. Ok. >> The routes for the mobile network prefix are automatically >> aggregated into the home network prefix. > > Mention that it is assumed that the mobile network prefixes are > automatically aggregated under the home network prefix. So text became: > The routes for the Mobile Network Prefix are automatically aggregated > into the home network prefix (it is assumed that the Mobile Network > Prefixes are automatically aggregated into the home network prefix). >> If the Mobile Router updates the mobile network prefix routes via a >> dynamic routing protocol, the Home Agent SHOULD propagate the >> routes on the appropriate networks. > > This is the first mention of running a dynamic routing protocol > between the MR and the HA. Perhaps it should be described briefly > somewhere earlier on how to run a dynamic routing protocol between > the mobile router and the HA. Not sure how to do that. I mean if I want to do it completely I'd split it from this document. Not sure what kind of text would you like here. A new subsection earlier than this? If I remove the mentioning of dynamic routing protocol completely would it fit your reading? Alex -- 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 Jan 15 17:52:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6agY-0003xr-5A; Mon, 15 Jan 2007 17:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6agW-0003qP-T7; Mon, 15 Jan 2007 17:52:12 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6agV-0001l5-5H; Mon, 15 Jan 2007 17:52:12 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0FMpjE1012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jan 2007 14:51:46 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0FMpiW8025353; Mon, 15 Jan 2007 14:51:44 -0800 (PST) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 14:51:44 -0800 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] AD review of draft-ietf-mip6-dsmip-problem-02.txt Date: Mon, 15 Jan 2007 14:51:46 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF414ABFC@NAEX16.na.qualcomm.com> In-Reply-To: <4595284F.5000204@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AccrWMLmUC/HMw1WSIazDa0UeulA9gNntGfA From: "Tsirtsis, George" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 15 Jan 2007 22:51:44.0098 (UTC) FILETIME=[BA893420:01C738F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: Mobile IPv6 Mailing List , 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 Jari, thanks for the review and sorry for the long delay in replying. I am going over your comments and revising the draft so I think I will come up with a new draft soon. Thanks again for the thorough review. George > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, December 29, 2006 9:38 AM > To: Soliman, Hesham; Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List > Subject: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt >=20 > Hi all, >=20 > I reviewed this document. While I agree with > its conclusions, the draft still needs another > revision. >=20 > Here are the detailed comments: >=20 > Technical: > > - Double the amount of configuration in the mobile node and the home > > > > agent (e.g., security associations). > ... and later ... > > In addition, deploying both protocols will require duplication of > > security credentials on mobile nodes and home agents. This includes, > > IPsec security associations, keying material, and new authentication > > protocols for Mobile IPv6, in addition to the security credentials > > and associations required by Mobile IPv4. Such duplication is again > > significant with no gain to the operator or the mobile node. >=20 > Is this true under all circumstances? For instance, > is it true if one uses RFC 4285 or EAP for Mobile IPv6 > authentication? >=20 > Depending on the answer, please reword > and add the necessary explanations. > > - Local network optimizations for handovers will also need to be > > duplicated. > Only insofar as they are bound to the mobility > protocol. There are a large number of optimizations > (L2 pre-auth etc) that deal with other aspects of the > handover problem and do not impact what happens > at IP or IP mobility layers. >=20 > Please reword. > > 3.1. Implementation burdens > > > > As mentioned above, a node that is IPv4 and IPv6 capable must also be > > > > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > > will add implementation efforts, which, we argue, are not necessary. > > > > > > In addition to the implementation efforts, some vendors may not > > support both protocols in either mobile nodes or home agents. > > Although this is more of a commercial issue, it does affect the > > large-scale deployment of mobile devices on the Internet. > > > I'm not sure this section reflects the complete > picture. In a situation where host vendors > are independent of those who deploy the > mobility infrastructure, for instance, its > not clear that there is any reduction in > implementation effort. >=20 > Please reword for better balance. >=20 > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > * The document seems to lack a Security Considerations section. > > >=20 > This is needed (not just the section but the > content as well). >=20 > > Further work in this area, possibly independent of Mobile IP, may > > also be of interest to some parties in which case it should be dealt > > with separately from the incremental Mobile IP based changes. > This statement seems out of place. Or at least I could > not think of what specific further work you were thinking > of. > > 3.0 Problem description > I am missing an explanation of why various existing, > non-mobility related transition mechanisms are insufficient > for solving the issues listed in this document. I believe > they are insufficient, but the document needs to explain > why. >=20 > Please add the explanation. >=20 > Editorial: >=20 > Overall, this document needs an editorial > cleanup and better formatting. Random > linefeeds in particular are making it hard > to read. > > 1. Terminology > > > > In addition to [KEYWORDS], this draft uses the following terms as > You do not use any keywords. > > * The document seems to lack an IANA Considerations section. > > > This is optional, but I normally insert a "There are no IANA > considerations." text just to make it clear that the IANA does > not have to read the entire document. > > * The document seems to lack separate sections for > Informative/Normative > > References. > > > This is needed. > > > > Checking conformance with RFC 3978/3979 boilerplate... > > > > * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- > however, > > there's a paragraph with a matching beginning. Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 1 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 2 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > > * The document seems to lack a 1id_guidelines paragraph about > > Internet-Drafts being working documents -- however, there's a > paragraph > > with a matching beginning. Boilerplate error? > > * The document seems to lack a 1id_guidelines paragraph about 6 months > > document validity -- however, there's a paragraph with a matching > > beginning. Boilerplate error? > > * The document seems to lack a 1id_guidelines paragraph about the list > of > > current Internet-Drafts -- however, there's a paragraph with a > matching > > beginning. Boilerplate error? > > - The page length should not exceed 58 lines per page, but there was 7 > > longer pages, the longest (page 6) being 68 lines > > - It seems as if not all pages are separated by form feeds - found 0 > form > > feeds but 7 pages > > > Hesham, please, move to xml2rfc. Its so much easier > for everyone. You don't need any software, btw, > you can convert to text at xml.resource.org. > > Miscellaneous warnings: > > - The "Author's Address" (or "Authors' Addresses") section title is > > misspelled. > > > Please fix. >=20 > > We argue that all of the above will hinder the deployment of Mobile > > IPv6 as well as any dual stack solution in a mobile environment. We > I would suggest saying "makes harder to deploy ..." instead > of "will hinder". This could be just a language issue, but > my understanding is that "hinder" can be interpreted > as "block" -- and I'm not sure I would agree with such > a strong statement. > > clearly inefficient since it requires: > s/clearly// (better style) >=20 > > Each of these systems > > requiring their own sets of optimizations that may include > > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > > Handoffs for Mobile IPv4, mechanisms that are currently in > > development in the IETF. > The list seems a bit out of place, and somewhat arbitrary. > I would suggest s/optimizations .*/optimizations./ >=20 > > Deploying both in a dual stack mobile node > > introduces a number of inefficiencies. > s/inefficiencies/problems/ (a pure mip6+mip4 solution > would block either v4 or v6 communications, depending > on which type of access network you are in) > > The draft > > also hints on how the current [MIPv4] and [MIPv6] protocols could be > > extended so that they can support mobility management for a dual > > stack node. > References in abstract. >=20 > Also, I'm not sure you really talk or should talk about the "how" > part. Suggested rewording: "The draft also discusses requirements > for the Mobile IPv4 and Mobile IPv6 protocols so that they can > support ..." >=20 > > 2. Introduction and motivation > This section focuses on the argument that we need > to have one mobility protocol handle both protocol > versions. I would suggest the addition of the basic > connectivity problem explanation before bullet > list. > > 3.4. The impossibility of maintaining IP connectivity > I would start with this in Section 3. >=20 > --Jari >=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 Tue Jan 16 09:13:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6p4I-00076d-HY; Tue, 16 Jan 2007 09:13:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6p4H-00076V-Bp for mip4@ietf.org; Tue, 16 Jan 2007 09:13:41 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6p48-00071x-Mu for mip4@ietf.org; Tue, 16 Jan 2007 09:13:41 -0500 X-VirusChecked: Checked X-Env-Sender: pradap@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1168956811!1156622!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 21091 invoked from network); 16 Jan 2007 14:13:31 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-15.tower-128.messagelabs.com with SMTP; 16 Jan 2007 14:13:31 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l0GEDVmK007082 for ; Tue, 16 Jan 2007 07:13:31 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l0GEDS30014078 for ; Tue, 16 Jan 2007 08:13:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jan 2007 22:13:25 +0800 Message-ID: <405ECA8A30557F439A723E52D50838F901316F49@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Doubts in RFC 3344 Thread-Index: Acc5eHzqfl87asptT5u3ZpIpI2AJLQ== From: "K V Pradap-a22072" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e02509f7a15c0aaea12155beed3396f0 Subject: [Mip4] Doubts in RFC 3344 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="===============1552051298==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1552051298== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73978.7D5F29BE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73978.7D5F29BE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All I have got few questions that I have listed below with regard to MIPv4 as specified in RFC 3344 =20 =20 =20 =20 Question-1) In the case of Dynamic Home Agent Address Resolution as described in RFC 3344, the mobile node does not know the address of Home Agent and thus send a Registration Request as specified in Sec 3.6.1.1 , 3.6.1.2 .=20 =20 sec 3.6.1.1 " If the mobile node is registering directly with its home agent, but does not know the IP address of its home agent, the mobile node may use dynamic home agent address resolution to automatically determine the IP address of its home agent (Section 3.6.1.2)" =20 sec 3.6.1.2 " The Home Agent field MUST be set to the address of the mobile node's home agent, if the mobile node knows this address. Otherwise, the mobile node MAY use dynamic home agent address resolution to learn the address of its home agent." =20 sec 3.2 " Registration messages between a mobile node and its home agent MUST be authenticated with an authorization-enabling extension, e.g. the Mobile-Home Authentication Extension (Section 3.5.2). =20 " sec 3.5.2 " The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document " =20 What should be the authorization enabling extension should the message be protected with, as here Mobile Node -Home Agent Authentication Extension cannot be used as MN does not know its Home Agent? =20 Question-2)If the Mobile Node has the Key for HA, but HA does not have the key of MN, can the HA get the Keys of MN by some other means. as sec 3.5.2 specifies "Exactly one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document" Is there a way for HA to get the MSA dynamically from the AAA? I understand that 3957 is way to do this, I also understand that 4004 gives a Diameter based approach to the whole thing. But in this case, where MN sends MN-HA auth ext, is there a way for HA to just lookup the MSA from the AAA? =20 Question-3)if HA doesn't support simultaneous binding, for every "accepted" registration , HA will send Registration reply with code set to 1. if MN moves to new FA, and sends a Registration Request with "S" bit set what should be the behavior of HA.=20 - Whether it should keep earlier binding and disallow the new RRQ or - Delete the earlier binding and allow the new RRQ. as sec 3.8.2 specifies " 3.8.2.2: " If the Lifetime is nonzero, the home agent adds an entry containing the requested Care-of Address to the mobility binding list for the mobile node. If the 'S' bit is set and the home agent supports simultaneous mobility bindings, the previous mobility binding entries are retained. Otherwise, the home agent removes all previous entries in the mobility binding list for the mobile node. " But this does not specify what should the HA do if the S bit is set & HA does not support the simultaneous bindings. =20 Question-4)In the case of non-co located Mobile Nodes requesting a copy of Broadcast datagrams by setting B bit in Registration Request. Does HA while transmitting the broadcast datagrams, encapsulate inner and outer datagrams with same mode (say, GRE or IP-IP)? sec 3.6.1.2 specifies " If the 'D' bit is NOT set, then the mobile node has indicated that it is using a foreign agent care-of address, and that the foreign agent will thus decapsulate arriving datagrams before forwarding them to the mobile node. In this case, to forward such a received broadcast datagram to the mobile node, the home agent MUST first encapsulate the broadcast datagram in a unicast datagram addressed to the mobile node's home address, and then MUST tunnel this resulting datagram to the mobile node's care-of address. =20 When decapsulated by the foreign agent, the inner datagram will thus be a unicast IP datagram addressed to the mobile node, identifying to the foreign agent the intended destination of the encapsulated broadcast datagram, and will be delivered to the mobile node in the same way as any tunneled datagram arriving for the mobile node. The foreign agent MUST NOT decapsulate the encapsulated broadcast datagram and MUST NOT use a local network broadcast to transmit it to the mobile node. The mobile node thus MUST decapsulate the encapsulated broadcast datagram itself, and thus MUST NOT set the 'B' bit in its Registration Request in this case unless it is capable of decapsulating datagrams. " Normally, if an MN uses FA CoA as tunneling end-point, it does not matter what decapsulation capability the MN has. But in this case, looks like, a decapsulation is being forced upon it & hence the capability matters.=20 =20 Question-5) How does multi-homed mobiles register with the HA? Do they use one CoA? or multiple CoAs? Do they acquire multiple HoAs? =20 =20 =20 I would be appreciable, if you can provide clarifications or references to discussions(if any ) for the above mentioned issues. =20 Thanks and Regards Pradap ------_=_NextPart_001_01C73978.7D5F29BE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 All
I have = got few=20 questions that I have listed below with regard to MIPv4 as specified in = RFC=20 3344
 
 
 
 
Question-1)=20 In the case of Dynamic Home Agent Address Resolution as = described in=20 RFC 3344, the mobile node does not know the address of Home=20 Agent and thus send a Registration Request as specified in Sec=20 3.6.1.1 , 3.6.1.2 .
 
sec 3.6.1.1
" If the mobile node = is=20 registering directly with its home agent,

        =20 but does not know the IP address of its home agent, the = mobile

         node may=20 use dynamic home agent address resolution to

        =20 automatically determine the IP address of its home = agent

        =20 (Section 3.6.1.2)"

 

sec 3.6.1.2

"

   The Home Agent field MUST = be set to=20 the address of the mobile node's

   home agent, if the = mobile node=20 knows this address.  = Otherwise,=20 the

   mobile node MAY use = dynamic home=20 agent address resolution to learn

   the address of its home=20 agent."

 

sec=20 3.2

"

   Registration = messages=20 between

   a mobile node and its = home agent=20 MUST be authenticated with an

   authorization-enabling = extension,=20 e.g. the Mobile-Home Authentication

   Extension (Section=20 3.5.2). =20

"

sec 3.5.2

"

The Mobile-Home = Authentication=20 Extension is

always an=20 authorization-enabling for registration messages specified

in this document

"

 

What should be the authorization = enabling=20 extension should the message be protected with, as here Mobile Node = -Home Agent=20 Authentication Extension cannot be used as MN does not know its Home = Agent?
 
Question-2)If the Mobile Node has the = Key for=20 HA, but HA does not have the key of MN, can the HA get the Keys of MN by some other means.  as sec 3.5.2 = specifies
"Exactly one=20 authorization-enabling extension MUST be present in all

   Registration Requests, = and also in=20 all Registration Replies generated

   by the Home Agent.  The Mobile-Home Authentication = Extension=20 is

   always an = authorization-enabling=20 for registration messages specified

    in this=20 document"
Is there a way for HA to get the MSA dynamically from the AAA? = I=20 understand that 3957 is way to do this,  I also understand that = 4004 gives=20 a Diameter based approach to the whole thing. But in this case, where MN = sends=20 MN-HA auth ext, is there a way for HA to just lookup the MSA from the=20 AAA?
 
Question-3)if HA doesn't support = simultaneous=20 binding, for every "accepted" registration , HA will send Registration = reply=20 with code set to 1. if MN moves to = new FA,=20 and sends a Registration Request with "S" bit set what should be the = behavior of=20 HA.=20
        - = Whether it=20 should keep earlier binding and disallow the new RRQ = or
      &nb= sp; -=20 Delete the earlier binding and allow the=20 new RRQ.
   as sec 3.8.2 = specifies
"

3.8.2.2:

“
If the Lifetime is nonzero, the home agent = adds an=20 entry containing the requested Care-of Address to the mobility binding = list for=20 the mobile node. If the 'S' bit is set and the home agent supports = simultaneous=20 mobility bindings, the previous mobility binding entries are retained.=20 Otherwise, the home agent removes all previous entries in the mobility = binding=20 list for the mobile = node.
"
But this=20 does not specify what should the HA do if the S bit is set & HA does = not=20 support the simultaneous = bindings.
 
=
Question-4)In the case of non-co = located Mobile=20 Nodes requesting a copy of Broadcast datagrams by setting B bit in = Registration=20 Request.  Does HA while transmitting the broadcast datagrams,=20 encapsulate inner and outer datagrams with same mode (say, GRE or IP-IP)?
sec 3.6.1.2=20 specifies
"

       &nbs= p; If=20 the 'D' bit is NOT set, then the mobile node has indicated

        =20 that it is using a foreign agent care-of address, and that = the

        =20 foreign agent will thus decapsulate arriving datagrams = before

        =20 forwarding them to the mobile node. =20 In this case, to forward

        =20 such a received broadcast datagram to the mobile node, the=20 home

        =20 agent MUST first encapsulate the broadcast datagram in = a

        =20 unicast datagram addressed to the mobile node's home = address,

        =20 and then MUST tunnel this resulting datagram to the = mobile

        =20 node's care-of address.

 

        =20 When decapsulated by the foreign agent, the inner datagram=20 will

        =20 thus be a unicast IP datagram addressed to the mobile = node,

        =20 identifying to the foreign agent the intended destination = of

        =20 the encapsulated broadcast datagram, and will be delivered = to

        =20 the mobile node in the same way as any tunneled = datagram

        =20 arriving for the mobile node. =20 The foreign agent MUST NOT

        =20 decapsulate the encapsulated broadcast datagram and MUST = NOT

        =20 use a local network broadcast to transmit it to the = mobile

        =20 node.  The mobile = node thus=20 MUST decapsulate the encapsulated

        =20 broadcast datagram itself, and thus MUST NOT set the 'B' bit=20 in

        =20 its Registration Request in this case unless it is capable = of

        =20 decapsulating datagrams.

"
Normally, if an MN uses FA CoA as tunneling = end-point,=20 it does not matter what decapsulation capability the MN has. But in this = case,=20 looks like, a decapsulation is being forced upon it & hence the = capability=20 matters.
 
Question-5) How=20 does multi-homed mobiles register with the HA? Do they use one CoA? or = multiple=20 CoAs? Do they acquire multiple HoAs?
 
 
 
I would be appreciable, if you can provide=20 clarifications or references to discussions(if any ) for the above = mentioned=20 issues.
 
Thanks and Regards
Pradap
------_=_NextPart_001_01C73978.7D5F29BE-- --===============1552051298== 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/ --===============1552051298==-- From mip4-bounces@ietf.org Tue Jan 16 10:00:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pnO-0004BL-57; Tue, 16 Jan 2007 10:00:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pnM-0004BF-BS for mip4@ietf.org; Tue, 16 Jan 2007 10:00:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6pnJ-0005ZV-Sl for mip4@ietf.org; Tue, 16 Jan 2007 10:00:16 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0GF0Fhi016668; Tue, 16 Jan 2007 16:00:15 +0100 Received: from [172.25.78.187] ([172.25.78.187]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2007011616000863:12190 ; Tue, 16 Jan 2007 16:00:08 +0100 Message-ID: <45ACE878.6000106@alcatel.fr> Date: Tue, 16 Jan 2007 16:00:08 +0100 From: Bruno.Mongazon-Cazavet@alcatel-lucent.fr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: K V Pradap-a22072 Subject: Re: [Mip4] Doubts in RFC 3344 References: <405ECA8A30557F439A723E52D50838F901316F49@ZMY16EXM66.ds.mot.com> In-Reply-To: <405ECA8A30557F439A723E52D50838F901316F49@ZMY16EXM66.ds.mot.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/16/2007 16:00:08, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/16/2007 16:00:09, Serialize complete at 01/16/2007 16:00:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 See inline my 2 cents for question 1) K V Pradap-a22072 wrote: > Hi All > I have got few questions that I have listed below with regard to MIPv4 > as specified in RFC 3344 > > > > > Question-1) In the case of Dynamic Home Agent Address Resolution as > described in RFC 3344, the mobile node does not know the address of > Home Agent and thus send a Registration Request as specified in Sec > 3.6.1.1 , 3.6.1.2 . > > sec 3.6.1.1 > " If the mobile node is registering directly with its home agent, > > but does not know the IP address of its home agent, the mobile > > node may use dynamic home agent address resolution to > > automatically determine the IP address of its home agent > > (Section 3.6.1.2)" > > > > sec 3.6.1.2 > > " > > The Home Agent field MUST be set to the address of the mobile node's > > home agent, if the mobile node knows this address. Otherwise, the > > mobile node MAY use dynamic home agent address resolution to learn > > the address of its home agent." > Later in the 3.6.1.2 section: In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network. Each home agent receiving such a Registration Request with a broadcast destination address MUST reject the mobile node's registration and SHOULD return a rejection Registration Reply indicating its unicast IP address for use by the mobile node in a future registration attempt. So then, registration has to be performed again using one the Home Agent addresses replied. > > > sec 3.2 > > " > > Registration messages between > > a mobile node and its home agent MUST be authenticated with an > > authorization-enabling extension, e.g. the Mobile-Home Authentication > > Extension (Section 3.5.2). > > " > > sec 3.5.2 > > " > > The Mobile-Home Authentication Extension is > > always an authorization-enabling for registration messages specified > > in this document > > " > > > What should be the authorization enabling extension should the message > be protected with, as here Mobile Node -Home Agent Authentication > Extension cannot be used as MN does not know its Home Agent? > The MN will choose one of the "in-error" registration reply to pickup the Home Agent Adress and process authorization with the chosen HA. Regards, Bruno. -- 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 Jan 16 10:07:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pud-0000Nn-QJ; Tue, 16 Jan 2007 10:07:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6puc-0000Nf-BT for mip4@ietf.org; Tue, 16 Jan 2007 10:07:46 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6pua-0006TR-Bm for mip4@ietf.org; Tue, 16 Jan 2007 10:07:46 -0500 X-VirusChecked: Checked X-Env-Sender: pradap@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1168960063!14330222!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5784 invoked from network); 16 Jan 2007 15:07:43 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-9.tower-119.messagelabs.com with SMTP; 16 Jan 2007 15:07:43 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0GF7gFB024722 for ; Tue, 16 Jan 2007 08:07:42 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0GF7fA3027264 for ; Tue, 16 Jan 2007 09:07:42 -0600 (CST) 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] Doubts in RFC 3344 Date: Tue, 16 Jan 2007 23:07:38 +0800 Message-ID: <405ECA8A30557F439A723E52D50838F901316F57@ZMY16EXM66.ds.mot.com> In-reply-to: <45ACE878.6000106@alcatel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Doubts in RFC 3344 Thread-Index: Acc5fw1lA5FUEHmaSsikkbkxwAMqQwAAF89Q From: "K V Pradap-a22072" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Bruno Thanks for the reply. I have an added question that, By what Authorization enabling extension will the Initial Registration request(which is used for Home Agent Discovery) will be protected with? Thanks and regards Pradap -----Original Message----- From: Bruno.Mongazon-Cazavet@alcatel-lucent.fr [mailto:Bruno.Mongazon-Cazavet@alcatel-lucent.fr] Sent: Tuesday, January 16, 2007 8:30 PM To: K V Pradap-a22072 Cc: mip4@ietf.org Subject: Re: [Mip4] Doubts in RFC 3344 See inline my 2 cents for question 1) K V Pradap-a22072 wrote: > Hi All > I have got few questions that I have listed below with regard to MIPv4 > as specified in RFC 3344 >=20 >=20 >=20 >=20 > Question-1) In the case of Dynamic Home Agent Address Resolution as > described in RFC 3344, the mobile node does not know the address of > Home Agent and thus send a Registration Request as specified in Sec > 3.6.1.1 , 3.6.1.2 . >=20 > sec 3.6.1.1 > " If the mobile node is registering directly with its home agent, > > but does not know the IP address of its home agent, the > mobile > > node may use dynamic home agent address resolution to > > automatically determine the IP address of its home agent > > (Section 3.6.1.2)" > >=20 > > sec 3.6.1.2 > > " > > The Home Agent field MUST be set to the address of the mobile > node's > > home agent, if the mobile node knows this address. Otherwise, the > > mobile node MAY use dynamic home agent address resolution to learn > > the address of its home agent." > Later in the 3.6.1.2 section: In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network. Each home agent receiving such a Registration Request with a broadcast destination address MUST reject the mobile node's registration and SHOULD return a rejection Registration Reply indicating its unicast IP address for use by the mobile node in a future registration attempt. So then, registration has to be performed again using one the Home Agent addresses replied. >=20 > > sec 3.2 > > " > > Registration messages between > > a mobile node and its home agent MUST be authenticated with an > > authorization-enabling extension, e.g. the Mobile-Home > Authentication > > Extension (Section 3.5.2). > > " > > sec 3.5.2 > > " > > The Mobile-Home Authentication Extension is > > always an authorization-enabling for registration messages specified > > in this document > > " > >=20 > What should be the authorization enabling extension should the message > be protected with, as here Mobile Node -Home Agent Authentication > Extension cannot be used as MN does not know its Home Agent? >=20 The MN will choose one of the "in-error" registration reply to pickup the Home Agent Adress and process authorization with the chosen HA. Regards, Bruno. -- 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 Jan 16 10:34:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qJu-0000d2-3G; Tue, 16 Jan 2007 10:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qJs-0000cl-1s for mip4@ietf.org; Tue, 16 Jan 2007 10:33:52 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qJp-00023d-GD for mip4@ietf.org; Tue, 16 Jan 2007 10:33:52 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0GFXsF2006634; Tue, 16 Jan 2007 16:33:54 +0100 Received: from [172.25.78.187] ([172.25.78.187]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2007011616334641:12644 ; Tue, 16 Jan 2007 16:33:46 +0100 Message-ID: <45ACF05A.4040504@alcatel.fr> Date: Tue, 16 Jan 2007 16:33:46 +0100 From: Bruno.Mongazon-Cazavet@alcatel-lucent.fr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: K V Pradap-a22072 Subject: Re: [Mip4] Doubts in RFC 3344 References: <405ECA8A30557F439A723E52D50838F901316F57@ZMY16EXM66.ds.mot.com> In-Reply-To: <405ECA8A30557F439A723E52D50838F901316F57@ZMY16EXM66.ds.mot.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/16/2007 16:33:46, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/16/2007 16:33:47, Serialize complete at 01/16/2007 16:33:47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Bruno.Mongazon-Cazavet@alcatel-lucent.fr, 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 K V Pradap-a22072 wrote: > Hi Bruno > Thanks for the reply. > I have an added question that, > By what Authorization enabling extension will the Initial Registration > request(which is used for Home Agent Discovery) will be protected with? > Good question. Not sure of my answer but let's try: If co-located FA is used, i think the RFC assumes that the check for IP broadcast destination address is performed before authorization checks. If so the MN does not care about Authorization enabling extension in the initial request. If FA is used, i guess the same assumption applies. The Foreign Agent authorization extension will be present while relaying the initial registration request i guess. Not sure of this however! > Thanks and regards > Pradap > > -----Original Message----- > From: Bruno.Mongazon-Cazavet@alcatel-lucent.fr > [mailto:Bruno.Mongazon-Cazavet@alcatel-lucent.fr] > Sent: Tuesday, January 16, 2007 8:30 PM > To: K V Pradap-a22072 > Cc: mip4@ietf.org > Subject: Re: [Mip4] Doubts in RFC 3344 > > See inline my 2 cents for question 1) > > K V Pradap-a22072 wrote: > >> Hi All >> I have got few questions that I have listed below with regard to MIPv4 >> as specified in RFC 3344 >> >> >> >> >> Question-1) In the case of Dynamic Home Agent Address Resolution as >> described in RFC 3344, the mobile node does not know the address of >> Home Agent and thus send a Registration Request as specified in Sec >> 3.6.1.1 , 3.6.1.2 . >> >> sec 3.6.1.1 >> " If the mobile node is registering directly with its home agent, >> >> but does not know the IP address of its home agent, the >> mobile >> >> node may use dynamic home agent address resolution to >> >> automatically determine the IP address of its home agent >> >> (Section 3.6.1.2)" >> >> >> >> sec 3.6.1.2 >> >> " >> >> The Home Agent field MUST be set to the address of the mobile >> node's >> >> home agent, if the mobile node knows this address. Otherwise, the >> >> mobile node MAY use dynamic home agent address resolution to learn >> >> the address of its home agent." >> >> > Later in the 3.6.1.2 section: > > In this case, the mobile node MUST > set the Home Agent field to the subnet-directed broadcast address of > the mobile node's home network. Each home agent receiving such a > Registration Request with a broadcast destination address MUST reject > the mobile node's registration and SHOULD return a rejection > Registration Reply indicating its unicast IP address for use by the > mobile node in a future registration attempt. > > So then, registration has to be performed again using one the Home Agent > addresses replied. > > >> sec 3.2 >> >> " >> >> Registration messages between >> >> a mobile node and its home agent MUST be authenticated with an >> >> authorization-enabling extension, e.g. the Mobile-Home >> Authentication >> >> Extension (Section 3.5.2). >> >> " >> >> sec 3.5.2 >> >> " >> >> The Mobile-Home Authentication Extension is >> >> always an authorization-enabling for registration messages specified >> >> in this document >> >> " >> >> >> What should be the authorization enabling extension should the message >> be protected with, as here Mobile Node -Home Agent Authentication >> Extension cannot be used as MN does not know its Home Agent? >> >> > The MN will choose one of the "in-error" registration reply to pickup > the Home Agent Adress and process authorization with the chosen HA. > > Regards, Bruno. > > > > -- 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 Jan 16 12:53:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sVA-0007Tj-Mo; Tue, 16 Jan 2007 12:53:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sEN-0003FE-U9; Tue, 16 Jan 2007 12:36:19 -0500 Received: from ozzie.acm.org ([63.118.7.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sEM-0005lW-KS; Tue, 16 Jan 2007 12:36:19 -0500 Received: from ozzie (localhost) by ozzie.acm.org (LSMTP for Windows NT v1.1b) with SMTP id <2.002A695E@ozzie.acm.org>; Tue, 16 Jan 2007 12:40:21 -0500 Received: by LISTSERV.ACM.ORG (LISTSERV-TCP/IP release 14.3) with spool id 19921031 for SENSORNET@LISTSERV.ACM.ORG; Tue, 16 Jan 2007 12:40:10 -0500 Received: from psmtp.com (exprod7mx74.postini.com) by ozzie.acm.org (LSMTP for Windows NT v1.1b) with SMTP id <4.002A6F59@ozzie.acm.org>; Tue, 16 Jan 2007 12:40:09 -0500 Received: from source ([63.118.7.108]) (using SSLv3) by exprod7mx74.postini.com ([64.18.6.14]) with SMTP; Tue, 16 Jan 2007 12:35:57 EST Received: from psmtp.com ([64.18.2.106]) by acm26-3.acm.org (ACM Email Forwarding Service) with SMTP id VSZ43756 for ; Tue, 16 Jan 2007 12:35:56 -0500 Received: from source ([13.1.64.93]) by exprod7mx56.postini.com ([64.18.6.14]) with SMTP; Tue, 16 Jan 2007 12:35:55 EST Received: from [13.2.19.35] ([13.2.19.35]) by alpha.xerox.com with SMTP id <219068(1)>; Tue, 16 Jan 2007 09:35:38 PST User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-pstn-levels: (S: 3.20491/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 5 (2.0000:0.0000) s gt3 gt2 GT1 r p m c X-pstn-addresses: from [301/19] X-pstn-levels: (S: 3.20491/99.90000 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 4 (1.5000:1.5000) s gt3 gt2 gt1 r p m c X-pstn-addresses: from [141/11] Message-ID: <45AD0CE9.2080609@parc.com> Date: Tue, 16 Jan 2007 09:35:37 PST From: Ying Zhang X-To: sensornet@acm.org To: SENSORNET@LISTSERV.ACM.ORG Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Tue, 16 Jan 2007 12:53:39 -0500 Cc: Subject: [Mip4] IPSN'07 Competition X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Reply-To: Ying Zhang List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Call For Participation What: IPSN '07 Extreme Sensing Competition When: April 25-27, 2007 Deadline: April 10, 2007 1st Prize: Nintendo Wii Details: http://www.cs.virginia.edu/~whitehouse/ipsn07competition/ IPSN '07 will be hosting an Extreme Sensing competition April 25-27, 2007. Each team will need to build a sensor system using five sensors or less that can count people walking through a 10ft x 10ft arena. In Phase 1, the arena will be placed in a high traffic area and all teams will sense normal foot traffic from conference attendees for a duration of 10 minutes. Points will be awarded for correct detections and subtracted for false positives and false negatives. In Phase 2, each team must try to walk through the arena 10 times without being detected by their opponents' sensors, in order to increase their own score while decreasing the scores of their opponents. Results will be broadcast live during Phase 1, providing each team an opportunity to discern how the other systems work and how they might fail. For more details about the competition, and how to enter, visit the URL listed above. -- 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 Jan 16 15:50:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vFw-0004tt-HR; Tue, 16 Jan 2007 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vFq-0004Ye-E7; Tue, 16 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vFq-00049b-5F; Tue, 16 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 20A56329FF; Tue, 16 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6vFq-0002vl-0b; Tue, 16 Jan 2007 15:50:02 -0500 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, 16 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-message-string-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 Message String Extension Author(s) : V. Sastry, et al. Filename : draft-ietf-mip4-message-string-ext-02.txt Pages : 13 Date : 2007-1-16 This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-message-string-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-message-string-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-message-string-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-1-16121932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-message-string-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-message-string-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-16121932.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 Jan 17 05:12:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77mO-0005Gi-63; Wed, 17 Jan 2007 05:12:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77mN-0005FV-BE; Wed, 17 Jan 2007 05:12:27 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77mJ-00012I-LH; Wed, 17 Jan 2007 05:12:27 -0500 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 l0HACGZH010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 02:12:16 -0800 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 l0HACFSG001177; Wed, 17 Jan 2007 02:12:15 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 02:12:15 -0800 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] AD review of draft-ietf-mip6-dsmip-problem-02.txt Date: Wed, 17 Jan 2007 02:12:06 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> In-Reply-To: <4595284F.5000204@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AccrWMLmUC/HMw1WSIazDa0UeulA9gNV0KOA From: "Tsirtsis, George" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 17 Jan 2007 10:12:15.0012 (UTC) FILETIME=[F611FE40:01C73A1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Mobile IPv6 Mailing List , 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 Hi Jari, Thanks again for the review. Please find some comments below as well as some suggestions about how to deal with some of your comments. If you are ok with these I will publish a new version early next week. Regards George > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, December 29, 2006 9:38 AM > To: Soliman, Hesham; Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List > Subject: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt >=20 > Hi all, >=20 > I reviewed this document. While I agree with > its conclusions, the draft still needs another > revision. >=20 > Here are the detailed comments: >=20 > Technical: > > - Double the amount of configuration in the mobile node and the home > > > > agent (e.g., security associations). > ... and later ... > > In addition, deploying both protocols will require duplication of > > security credentials on mobile nodes and home agents. This includes, > > IPsec security associations, keying material, and new authentication > > protocols for Mobile IPv6, in addition to the security credentials > > and associations required by Mobile IPv4. Such duplication is again > > significant with no gain to the operator or the mobile node. >=20 > Is this true under all circumstances? For instance, > is it true if one uses RFC 4285 or EAP for Mobile IPv6 > authentication? >=20 > Depending on the answer, please reword > and add the necessary explanations. GT> I believe that, assuming nothing is changed, what the draft says is accurate since typically applications/protocols can not share keys unless security is implemented at a lower layer than that of the application/protocol. Still, I will add something to indicate that for some of the mechanisms listed and with further work, it might be possible to optimize operations. > > - Local network optimizations for handovers will also need to be > > duplicated. > Only insofar as they are bound to the mobility > protocol. There are a large number of optimizations > (L2 pre-auth etc) that deal with other aspects of the > handover problem and do not impact what happens > at IP or IP mobility layers. >=20 > Please reword. GT> I will clarify that we are talking about IP layer optimizations > > 3.1. Implementation burdens > > > > As mentioned above, a node that is IPv4 and IPv6 capable must also be > > > > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > > will add implementation efforts, which, we argue, are not necessary. > > > > > > In addition to the implementation efforts, some vendors may not > > support both protocols in either mobile nodes or home agents. > > Although this is more of a commercial issue, it does affect the > > large-scale deployment of mobile devices on the Internet. > > > I'm not sure this section reflects the complete > picture. In a situation where host vendors > are independent of those who deploy the > mobility infrastructure, for instance, its > not clear that there is any reduction in > implementation effort. >=20 > Please reword for better balance. >=20 GT> OK, I will clarify=20 > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > * The document seems to lack a Security Considerations section. > > >=20 > This is needed (not just the section but the > content as well). >=20 > > Further work in this area, possibly independent of Mobile IP, may > > also be of interest to some parties in which case it should be dealt > > with separately from the incremental Mobile IP based changes. > This statement seems out of place. Or at least I could > not think of what specific further work you were thinking > of. GT> Ok, I think we can remove this. > > 3.0 Problem description > I am missing an explanation of why various existing, > non-mobility related transition mechanisms are insufficient > for solving the issues listed in this document. I believe > they are insufficient, but the document needs to explain > why. >=20 > Please add the explanation. GT> It is a bit difficult to write general negative statements like this. I will add a section on this and add something generic about the fact that current transition mechanisms do not seem to deal with mobility.=20 >=20 > Editorial: >=20 > Overall, this document needs an editorial > cleanup and better formatting. Random > linefeeds in particular are making it hard > to read. GT> Yes, the XML template corrected all this, sorry about that. > > 1. Terminology > > > > In addition to [KEYWORDS], this draft uses the following terms as > You do not use any keywords. > > * The document seems to lack an IANA Considerations section. > > > This is optional, but I normally insert a "There are no IANA > considerations." text just to make it clear that the IANA does > not have to read the entire document. GT> I added this in a new IANA section. > > * The document seems to lack separate sections for > Informative/Normative > > References. > > > This is needed. > > GT> fixed > > Checking conformance with RFC 3978/3979 boilerplate... > > > > * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- > however, > > there's a paragraph with a matching beginning. Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 1 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? GT> Fixed > > * The document seems to lack an RFC 3979 Section 5, para 2 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > GT> Fixed > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > > * The document seems to lack a 1id_guidelines paragraph about > > Internet-Drafts being working documents -- however, there's a > paragraph > > with a matching beginning. Boilerplate error? GT> Fixed > > * The document seems to lack a 1id_guidelines paragraph about 6 months > > document validity -- however, there's a paragraph with a matching > > beginning. Boilerplate error? GT> Fixed > > * The document seems to lack a 1id_guidelines paragraph about the list > of > > current Internet-Drafts -- however, there's a paragraph with a > matching > > beginning. Boilerplate error? GT> Fixed > > - The page length should not exceed 58 lines per page, but there was 7 > > longer pages, the longest (page 6) being 68 lines GT> Fixed > > - It seems as if not all pages are separated by form feeds - found 0 > form > > feeds but 7 pages > > GT> Fixed > Hesham, please, move to xml2rfc. Its so much easier > for everyone. You don't need any software, btw, > you can convert to text at xml.resource.org. > > Miscellaneous warnings: > > - The "Author's Address" (or "Authors' Addresses") section title is > > misspelled. > > > Please fix. >=20 GT> Fixed > > We argue that all of the above will hinder the deployment of Mobile > > IPv6 as well as any dual stack solution in a mobile environment. We > I would suggest saying "makes harder to deploy ..." instead > of "will hinder". This could be just a language issue, but > my understanding is that "hinder" can be interpreted > as "block" -- and I'm not sure I would agree with such > a strong statement. GT> OK > > clearly inefficient since it requires: > s/clearly// (better style) >=20 GT> OK > > Each of these systems > > requiring their own sets of optimizations that may include > > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > > Handoffs for Mobile IPv4, mechanisms that are currently in > > development in the IETF. > The list seems a bit out of place, and somewhat arbitrary. > I would suggest s/optimizations .*/optimizations./ >=20 GT> I will remove the list. > > Deploying both in a dual stack mobile node > > introduces a number of inefficiencies. > s/inefficiencies/problems/ (a pure mip6+mip4 solution > would block either v4 or v6 communications, depending > on which type of access network you are in) > > The draft > > also hints on how the current [MIPv4] and [MIPv6] protocols could be > > extended so that they can support mobility management for a dual > > stack node. > References in abstract. >=20 GT> Removed > Also, I'm not sure you really talk or should talk about the "how" > part. Suggested rewording: "The draft also discusses requirements > for the Mobile IPv4 and Mobile IPv6 protocols so that they can > support ..." >=20 GT> OK > > 2. Introduction and motivation > This section focuses on the argument that we need > to have one mobility protocol handle both protocol > versions. I would suggest the addition of the basic > connectivity problem explanation before bullet > list. GT> Added > > 3.4. The impossibility of maintaining IP connectivity > I would start with this in Section 3. >=20 GT> Done > --Jari >=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 Wed Jan 17 06:19:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78pN-0006lb-Vl; Wed, 17 Jan 2007 06:19:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78pN-0006lD-8D; Wed, 17 Jan 2007 06:19:37 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78pL-00089e-Q7; Wed, 17 Jan 2007 06:19:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F2EAB198767; Wed, 17 Jan 2007 13:19:34 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ADEAB198766; Wed, 17 Jan 2007 13:19:34 +0200 (EET) Message-ID: <45AE0648.5060204@piuha.net> Date: Wed, 17 Jan 2007 13:19:36 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> 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: 14582b0692e7f70ce7111d04db3781c8 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , "Soliman, Hesham" 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, >> Is this true under all circumstances? For instance, >> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >> authentication? >> >> Depending on the answer, please reword >> and add the necessary explanations. >> > > > GT> I believe that, assuming nothing is changed, what the draft says is > accurate since typically applications/protocols can not share keys > unless security is implemented at a lower layer than that of the > application/protocol. Still, I will add something to indicate that for > some of the mechanisms listed and with further work, it might be > possible to optimize operations. > Do you have text? We are not talking about typical applications, we are talking about a very specific case. And there are many applications that can share the same credentials through, say, AAA. >>> - Local network optimizations for handovers will also need to be >>> duplicated. >>> >> Only insofar as they are bound to the mobility >> protocol. There are a large number of optimizations >> (L2 pre-auth etc) that deal with other aspects of the >> handover problem and do not impact what happens >> at IP or IP mobility layers. >> >> Please reword. >> > > GT> I will clarify that we are talking about IP layer optimizations > Ok. >>> 3.1. Implementation burdens >>> >>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso be >>> >>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>> will add implementation efforts, which, we argue, are not necessary. >>> >>> In addition to the implementation efforts, some vendors may not >>> support both protocols in either mobile nodes or home agents. >>> Although this is more of a commercial issue, it does affect the >>> large-scale deployment of mobile devices on the Internet. >>> >>> >> I'm not sure this section reflects the complete >> picture. In a situation where host vendors >> are independent of those who deploy the >> mobility infrastructure, for instance, its >> not clear that there is any reduction in >> implementation effort. >> >> Please reword for better balance. >> >> > > GT> OK, I will clarify > Good. Again, I would like to see the text... >>> Further work in this area, possibly independent of Mobile IP, may >>> also be of interest to some parties in which case it should be dealt >>> >>> with separately from the incremental Mobile IP based changes. >>> >> This statement seems out of place. Or at least I could >> not think of what specific further work you were thinking >> of. >> > > GT> Ok, I think we can remove this. > Good. >>> 3.0 Problem description >>> >> I am missing an explanation of why various existing, >> non-mobility related transition mechanisms are insufficient >> for solving the issues listed in this document. I believe >> they are insufficient, but the document needs to explain >> why. >> >> Please add the explanation. >> > > GT> It is a bit difficult to write general negative statements like > this. I will add a section on this and add something generic about the > fact that current transition mechanisms do not seem to deal with > mobility. > Ok. Text needed. 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 Wed Jan 17 06:30:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78zX-00025w-RW; Wed, 17 Jan 2007 06:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78zW-000213-EB; Wed, 17 Jan 2007 06:30:06 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78zS-0002YR-I0; Wed, 17 Jan 2007 06:30:06 -0500 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 l0HBTntK012772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 03:29:50 -0800 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 l0HBTmP3022157; Wed, 17 Jan 2007 03:29:49 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 03:29:48 -0800 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: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Date: Wed, 17 Jan 2007 03:29:52 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: Acc6KWnMd7SVRMnQRUaOr9EY2gScdQAAJnoA From: "Tsirtsis, George" To: "Jari Arkko " X-OriginalArrivalTime: 17 Jan 2007 11:29:48.0592 (UTC) FILETIME=[CBD1F300:01C73A2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , "Soliman, Hesham" 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 Jari, See below the text requested for some of your requests. George -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Wednesday, January 17, 2007 6:20 AM To: Tsirtsis, George Cc: Soliman, Hesham; Mobile IPv6 Mailing List; Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt George, >> Is this true under all circumstances? For instance, >> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >> authentication? >> >> Depending on the answer, please reword >> and add the necessary explanations. >> =20 > > > GT> I believe that, assuming nothing is changed, what the draft says is > accurate since typically applications/protocols can not share keys > unless security is implemented at a lower layer than that of the > application/protocol. Still, I will add something to indicate that for > some of the mechanisms listed and with further work, it might be > possible to optimize operations. > =20 Do you have text? We are not talking about typical applications, we are talking about a very specific case. And there are many applications that can share the same credentials through, say, AAA. GT> Here is what I have.=20 " In addition, deploying both protocols will require duplication of security credentials on mobile nodes and home agents. This includes, IPsec security associations, keying material, and new authentication protocols for Mobile IPv6, in addition to the security credentials and associations required by Mobile IPv4. Depending on the security mechanisms used and with some further work it might be possible to optimize some of these processes. Assuming nothing else changes, however, such duplication is again significant with no gain to the operator or the mobile node." >>> - Local network optimizations for handovers will also need to be >>> duplicated. >>> =20 >> Only insofar as they are bound to the mobility >> protocol. There are a large number of optimizations >> (L2 pre-auth etc) that deal with other aspects of the >> handover problem and do not impact what happens >> at IP or IP mobility layers. >> >> Please reword. >> =20 > > GT> I will clarify that we are talking about IP layer optimizations > =20 Ok. >>> 3.1. Implementation burdens >>> >>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso be >>> =20 >>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>> will add implementation efforts, which, we argue, are not necessary. >>> =20 >>> In addition to the implementation efforts, some vendors may not >>> support both protocols in either mobile nodes or home agents. >>> Although this is more of a commercial issue, it does affect the >>> large-scale deployment of mobile devices on the Internet. >>> >>> =20 >> I'm not sure this section reflects the complete >> picture. In a situation where host vendors >> are independent of those who deploy the >> mobility infrastructure, for instance, its >> not clear that there is any reduction in >> implementation effort. >> >> Please reword for better balance. >> >> =20 > > GT> OK, I will clarify=20 > =20 Good. Again, I would like to see the text... GT> Here it is: " As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. Clearly this increases the complexity of implementations for vendors that decide to support both protocols. Some vendors, however, may not support both protocols in either mobile nodes or home agents. Although this is more of a commercial issue, it does affect the large-scale deployment of mobile devices on the Internet." >>> Further work in this area, possibly independent of Mobile IP, may >>> also be of interest to some parties in which case it should be dealt >>> =20 >>> with separately from the incremental Mobile IP based changes. >>> =20 >> This statement seems out of place. Or at least I could >> not think of what specific further work you were thinking >> of. >> =20 > > GT> Ok, I think we can remove this. > =20 Good. >>> 3.0 Problem description >>> =20 >> I am missing an explanation of why various existing, >> non-mobility related transition mechanisms are insufficient >> for solving the issues listed in this document. I believe >> they are insufficient, but the document needs to explain >> why. >> >> Please add the explanation. >> =20 > > GT> It is a bit difficult to write general negative statements like > this. I will add a section on this and add something generic about the > fact that current transition mechanisms do not seem to deal with > mobility.=20 > =20 Ok. Text needed. GT> Here it is:=20 "4.5. IPv4 to IPv6 Transition Mechanisms The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. A cursory examination of such transition mechanisms indicates that none of them is designed to deal with mobile nodes. While some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have been shown to assist with the issues described in this document." 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 Wed Jan 17 13:20:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7FOa-0003Xu-I6; Wed, 17 Jan 2007 13:20:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7FOZ-0003Xc-4L for mip4@ietf.org; Wed, 17 Jan 2007 13:20:23 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7FOX-0004hK-GL for mip4@ietf.org; Wed, 17 Jan 2007 13:20:23 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 19:20:12 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Jan 2007 19:19:49 +0100 Message-ID: <14FD20369E52DE478BD9612D63BE21B4070F841F@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem of using layer 2 triggers alone for the Low latency Handoff for MIPv4 Thread-Index: Acc6ZBMjBPM6YhfKRresU9oqIr93Iw== From: "ANTOINE Stephane RD-ILAB-LON" To: X-OriginalArrivalTime: 17 Jan 2007 18:20:12.0353 (UTC) FILETIME=[20B9B310:01C73A64] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Subject: [Mip4] Problem of using layer 2 triggers alone for the Low latency Handoff for MIPv4 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="===============0144353835==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0144353835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A64.22967983" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73A64.22967983 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to get some feedback about the problem, as described below, of using layer 2 triggers alone to initiate the Low latency Handoff for MIPv4: =20 The Low Latency Handoff for MIPv4 as described in=20 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hando ffs-v4-11.txt =20 assumes availability of the L2 triggers which contain Layer 3 information such as the IP address of the new Foreign Agent. Availability of the Layer 3 information is assumed in the Layer 2 trigger. However the method by which the Layer 3 information is made available in the Layer 2 trigger has not been specified. Moreover, Layer 2 trigger will actually occur in response or in prevision to certain link events such as the fading of the relative signal noise ratio below a certain level. Relying only on link information to initiate a handoff does not generally gather enough information for the Mobile Node to handoff to the most suitable available access network at the most suitable time.=20 =20 Information from layers higher than Layer 2 (that may come from various protocols) can be used as triggers to compensate the insufficiency of using Layer 2 triggers alone for the Low latency Handoff for MIPv4.=20 =20 I would also appreciate receiving some feedback upon the work presenting scenarios describing how the low latency Handoff for MIPv4 is initiated by higher layer triggers. http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handof f-triggers-00.txt =20 =20 Cheers =20 Stephane =20 ------_=_NextPart_001_01C73A64.22967983 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I=20 would like to get some feedback about the problem, as described below, = of using=20 layer 2 triggers alone to initiate the Low latency Handoff for=20 MIPv4:

  

The Low Latency = Handoff for MIPv4=20 as described in

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlaten= cy-handoffs-v4-11.txt

assumes = availability of the L2=20 triggers which contain Layer 3 information such as the IP address of the = new=20 Foreign Agent. Availability of the Layer 3 information is assumed in the = Layer 2=20 trigger. However the method by which the Layer 3 information is made available in the = Layer 2=20 trigger has not been specified.

Moreover, Layer 2 = trigger will=20 actually occur in response or in = prevision=20 to certain link events such as the fading of the relative signal = noise=20 ratio below a certain level. Relying only on link information to = initiate a=20 handoff does not generally gather enough information for the Mobile Node to handoff to the most = suitable=20 available access network at the most suitable time.

 

Information from = layers higher=20 than Layer 2 (that may come from various protocols) can be used as = triggers to=20 compensate the insufficiency of using Layer 2 triggers alone for the Low = latency=20 Handoff for MIPv4.

 

I would also = appreciate receiving=20 some feedback upon the work presenting scenarios describing how the low = latency=20 Handoff for MIPv4 is initiated by higher layer = triggers.

http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatenc= y-handoff-triggers-00.txt

 

Cheers

 

Stephane

 

------_=_NextPart_001_01C73A64.22967983-- --===============0144353835== 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/ --===============0144353835==-- From mip4-bounces@ietf.org Wed Jan 17 14:20:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GL8-00008R-02; Wed, 17 Jan 2007 14:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GL7-00008I-0V for mip4@ietf.org; Wed, 17 Jan 2007 14:20:53 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7GL5-0006Rb-GI for mip4@ietf.org; Wed, 17 Jan 2007 14:20:52 -0500 Received: by py-out-1112.google.com with SMTP id f31so1140103pyh for ; Wed, 17 Jan 2007 11:20:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type; b=GDWDhGkDUszwn07pY57oEvGg2KXfHz3FF1KwSj1R5vB0hmxmfvsfpQPDRz5075pUK9U3RUSVn5C9lHDVW0UbG7s93PNA54LZzYw9SKd2lPpJQ61KHQ9GK8857BWw9Vd6x78OEDiLH0W7RQqbEkEW9lXDTTlwItfKU4nDvUaYC4o= Received: by 10.35.9.15 with SMTP id m15mr13235183pyi.1169061650786; Wed, 17 Jan 2007 11:20:50 -0800 (PST) Received: from ?10.105.16.28? ( [12.192.138.117]) by mx.google.com with ESMTP id f78sm9848711pyh.2007.01.17.11.20.48; Wed, 17 Jan 2007 11:20:49 -0800 (PST) Message-ID: <45AE7709.5020005@gmail.com> Date: Wed, 17 Jan 2007 13:20:41 -0600 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ANTOINE Stephane RD-ILAB-LON Subject: Re: [Mip4] Problem of using layer 2 triggers alone for the Low latency Handoff for MIPv4 References: <14FD20369E52DE478BD9612D63BE21B4070F841F@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <14FD20369E52DE478BD9612D63BE21B4070F841F@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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: , Content-Type: multipart/mixed; boundary="===============1210201007==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1210201007== Content-Type: multipart/alternative; boundary="------------010501060407090905010909" This is a multi-part message in MIME format. --------------010501060407090905010909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Stephane, Thanks for your query. Please note my responses in-line. Regards, Sebastian ANTOINE Stephane RD-ILAB-LON wrote: > Hello, > > I would like to get some feedback about the problem, as described > below, of using layer 2 triggers alone to initiate the Low latency > Handoff for MIPv4: > > > > The Low Latency Handoff for MIPv4 as described in > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt > > assumes availability of the L2 triggers which contain Layer 3 > information such as the IP address of the new Foreign Agent. > Availability of the Layer 3 information is assumed in the Layer 2 > trigger. However the method by which the Layer 3 information is made > available in the Layer 2 trigger has not been specified. > st> The specific procedure used to acquire the L3 information, such as the IP address of the appropriate access gateway is dependent on the access technology over which the low-latency handoff scheme is applied. For instance, the radio access point or base station identifier could be used to determine the L3 information associated with the radio access point or the base station (L2 entities). The L3 information could be statically or dynamically configured at the L2 entity based on the connectivity to an L3 entity (access gateway). > Moreover, Layer 2 trigger will actually occur in response or in > prevision to certain link events such as the fading of the relative > signal noise ratio below a certain level. > st> Yes. > Relying only on link information to initiate a handoff does not > generally gather enough information for the Mobile Node to handoff to > the most suitable available access network at the most suitable time. > st> See the previous response on L3 information acquisition. > > > Information from layers higher than Layer 2 (that may come from > various protocols) can be used as triggers to compensate the > insufficiency of using Layer 2 triggers alone for the Low latency > Handoff for MIPv4. > st> The L2 trigger information is used to assist the upper layer protocols, in the case of wireless mobility with minimum latency, and not vice-versa. Using access technology specific schemes, the required L3 information, such as the serving access gateway IP address can be obtained from the L2 trigger information. > > > I would also appreciate receiving some feedback upon the work > presenting scenarios describing how the low latency Handoff for MIPv4 > is initiated by higher layer triggers. > > http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handoff-triggers-00.txt > > > > Cheers > > > > Stephane > > > --------------010501060407090905010909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Stephane,
                               Thanks for your query.

                                Please note my responses in-line.

Regards,
     Sebastian

ANTOINE Stephane RD-ILAB-LON wrote:

Hello,

I would like to get some feedback about the problem, as described below, of using layer 2 triggers alone to initiate the Low latency Handoff for MIPv4:

  

The Low Latency Handoff for MIPv4 as described in

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt

assumes availability of the L2 triggers which contain Layer 3 information such as the IP address of the new Foreign Agent. Availability of the Layer 3 information is assumed in the Layer 2 trigger. However the method by which the Layer 3 information is made available in the Layer 2 trigger has not been specified.

st> The specific procedure used to acquire the L3 information, such as the IP address of the appropriate access gateway is dependent on the access technology over which the low-latency handoff scheme is applied. For instance, the radio access point or base station identifier could be used to determine the L3 information associated with the radio access point or the base station (L2 entities). The L3 information could be statically or dynamically configured at the L2 entity based on the connectivity to an L3 entity (access gateway).

Moreover, Layer 2 trigger will actually occur in response or in prevision to certain link events such as the fading of the relative signal noise ratio below a certain level.

st> Yes.

Relying only on link information to initiate a handoff does not generally gather enough information for the Mobile Node to handoff to the most suitable available access network at the most suitable time.

st> See the previous response on L3 information acquisition.

 

Information from layers higher than Layer 2 (that may come from various protocols) can be used as triggers to compensate the insufficiency of using Layer 2 triggers alone for the Low latency Handoff for MIPv4.

st> The L2 trigger information is used to assist the upper layer protocols, in the case of wireless mobility with minimum latency, and not vice-versa. Using access technology specific schemes, the required L3 information, such as the serving access gateway IP address can be obtained from the L2 trigger information.

 

I would also appreciate receiving some feedback upon the work presenting scenarios describing how the low latency Handoff for MIPv4 is initiated by higher layer triggers.

http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handoff-triggers-00.txt

 

Cheers

 

Stephane

 


--------------010501060407090905010909-- --===============1210201007== 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/ --===============1210201007==-- From mip4-bounces@ietf.org Thu Jan 18 09:06:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xtv-0001pT-Gn; Thu, 18 Jan 2007 09:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xtt-0001o4-Jq for mip4@ietf.org; Thu, 18 Jan 2007 09:05:57 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Xts-00021g-36 for mip4@ietf.org; Thu, 18 Jan 2007 09:05:57 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 15:05:54 +0100 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] Problem of using layer 2 triggers alone for the Low latencyHandoff for MIPv4 Date: Thu, 18 Jan 2007 15:05:49 +0100 Message-ID: <14FD20369E52DE478BD9612D63BE21B4070F8420@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Problem of using layer 2 triggers alone for the Low latencyHandoff for MIPv4 Thread-Index: Acc6bJu0tpLGT142QIebGn/82EMqvQAjGVAQ From: "ANTOINE Stephane RD-ILAB-LON" To: X-OriginalArrivalTime: 18 Jan 2007 14:05:54.0961 (UTC) FILETIME=[C5063010:01C73B09] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Hello Sebastian, Thanks for your comments. Please find my responses in-line. Stephane > Hello, Stephane, > Thanks for your query. >=20 > Please note my responses in-line. >=20 > Regards, > Sebastian >=20 > ANTOINE Stephane RD-ILAB-LON wrote:=20 >=20 > =09 > Hello, >=20 > I would like to get some feedback about the problem, as=20 > described below, of using layer 2 triggers alone to initiate=20 > the Low latency Handoff for MIPv4: >=20 > =20 >=20 > The Low Latency Handoff for MIPv4 as described in=20 >=20 > =09 > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlat > ency-handoffs-v4-11.txt=20 > tency-handoffs-v4-11.txt>=20 >=20 > assumes availability of the L2 triggers which contain=20 > Layer 3 information such as the IP address of the new Foreign=20 > Agent. Availability of the Layer 3 information is assumed in=20 > the Layer 2 trigger. However the method by which the Layer 3=20 > information is made available in the Layer 2 trigger has not=20 > been specified. >=20 > st> The specific procedure used to acquire the L3=20 > information, such as the IP address of the appropriate access=20 > gateway is dependent on the access technology over which the=20 > low-latency handoff scheme is applied. For instance, the=20 > radio access point or base station identifier could be used=20 > to determine the L3 information associated with the radio=20 > access point or the base station (L2 entities). The L3=20 > information could be statically or dynamically configured at=20 > the L2 entity based on the connectivity to an L3 entity=20 > (access gateway). >=20 SA> It may be quite straightforward to statically configure the Layer 2 entity (Access Point (AP)) with L3 information (IP address) of the Access Gateway (Foreign Agent) directly connected to it and have this IP address advertised in the Beacon of the AP. However, it becomes more problematic to have the AP advertise the IP address of the new Foreign Agent (FA) the Mobile Node is going to handoff to. In general the AP cannot guess which Foreign Agent the Mobile Node is going to handoff to. The AP serving the Mobile Node may not be directly connected to the new FA. For instance, handoff between a serving AP and a target AP that are attached to two completely independent networks occurs when moving between Wi-Fi and 3G.=20 >=20 > Moreover, Layer 2 trigger will actually occur in=20 > response or in prevision to certain link events such as the=20 > fading of the relative signal noise ratio below a certain level.=20 >=20 > st> Yes. >=20 >=20 > Relying only on link information to initiate a handoff=20 > does not generally gather enough information for the Mobile=20 > Node to handoff to the most suitable available access network=20 > at the most suitable time. >=20 > st> See the previous response on L3 information acquisition. >=20 > Information from layers higher than Layer 2 (that may=20 > come from various protocols) can be used as triggers to=20 > compensate the insufficiency of using Layer 2 triggers alone=20 > for the Low latency Handoff for MIPv4. >=20 > st> The L2 trigger information is used to assist the upper=20 > layer protocols, in the case of wireless mobility with=20 > minimum latency, and not vice-versa. Using access technology=20 > specific schemes, the required L3 information, such as the=20 > serving access gateway IP address can be obtained from the L2=20 > trigger information. >=20 SA> The use of the Layer 2 trigger alone to assist the upper layer protocols is exactly what we pinpoint as being an insufficiency. If one relies only on Layer 2 trigger information, the Handoff might always be initiated towards a network offering the highest signal noise ratio. However the network offering the best signal noise ratio is not always the most suitable network for a given Mobile Node to handoff to. One can introduce an overall system, involving higher layer triggers that initiate the L3 handoff to the most suitable network before the L2 handoff actually takes place.=20 > =20 >=20 > I would also appreciate receiving some feedback upon=20 > the work presenting scenarios describing how the low latency=20 > Handoff for MIPv4 is initiated by higher layer triggers. >=20 > =09 > http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlate > ncy-handoff-triggers-00.txt=20 > ency-handoff-triggers-00.txt>=20 >=20 > =20 >=20 > Cheers >=20 > =20 >=20 > Stephane >=20 > =20 >=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 Thu Jan 18 14:57:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dNq-0007eH-VG; Thu, 18 Jan 2007 14:57:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dNq-0007eC-7B for mip4@ietf.org; Thu, 18 Jan 2007 14:57:14 -0500 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dNp-00040Z-Jb for mip4@ietf.org; Thu, 18 Jan 2007 14:57:14 -0500 Received: by py-out-1112.google.com with SMTP id f31so135208pyh for ; Thu, 18 Jan 2007 11:57:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type; b=MUSZDLZmskOBYT8FEj38MgNaKUOHEmGq8eM59QCNRoRBm9TTXeOaUgkhsI0NWALAPSv8XjJPITKOUqBx1b8RTAVP7/cS9nMImOJHibIaTnL2x4ezMDtBQByjHWzVuzokHCdxL0qAP+Y5TyTkO5ZTmcY8LP9aKhQihThWa5hqVRs= Received: by 10.35.81.1 with SMTP id i1mr2175081pyl.1169150232990; Thu, 18 Jan 2007 11:57:12 -0800 (PST) Received: from ?10.105.16.28? ( [12.192.138.117]) by mx.google.com with ESMTP id z80sm1151952pyg.2007.01.18.11.57.10; Thu, 18 Jan 2007 11:57:11 -0800 (PST) Message-ID: <45AFD10E.8050803@gmail.com> Date: Thu, 18 Jan 2007 13:57:02 -0600 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ANTOINE Stephane RD-ILAB-LON Subject: Re: [Mip4] Problem of using layer 2 triggers alone for the Low latencyHandoff for MIPv4 References: <14FD20369E52DE478BD9612D63BE21B4070F8420@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <14FD20369E52DE478BD9612D63BE21B4070F8420@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 0.6 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b 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: , Content-Type: multipart/mixed; boundary="===============0363853001==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0363853001== Content-Type: multipart/alternative; boundary="------------050309070201030101020303" This is a multi-part message in MIME format. --------------050309070201030101020303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Stephane, Thanks for your feedback. Please note my comments in-line. Regards, Sebastian ANTOINE Stephane RD-ILAB-LON wrote: >Hello Sebastian, > >Thanks for your comments. Please find my responses in-line. > >Stephane > > > > > >>Hello, Stephane, >> Thanks for your query. >> >> Please note my responses in-line. >> >>Regards, >> Sebastian >> >>ANTOINE Stephane RD-ILAB-LON wrote: >> >> >> Hello, >> >> I would like to get some feedback about the problem, as >>described below, of using layer 2 triggers alone to initiate >>the Low latency Handoff for MIPv4: >> >> >> >> The Low Latency Handoff for MIPv4 as described in >> >> >>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlat >>ency-handoffs-v4-11.txt >>>tency-handoffs-v4-11.txt> >> >> assumes availability of the L2 triggers which contain >>Layer 3 information such as the IP address of the new Foreign >>Agent. Availability of the Layer 3 information is assumed in >>the Layer 2 trigger. However the method by which the Layer 3 >>information is made available in the Layer 2 trigger has not >>been specified. >> >>st> The specific procedure used to acquire the L3 >>information, such as the IP address of the appropriate access >>gateway is dependent on the access technology over which the >>low-latency handoff scheme is applied. For instance, the >>radio access point or base station identifier could be used >>to determine the L3 information associated with the radio >>access point or the base station (L2 entities). The L3 >>information could be statically or dynamically configured at >>the L2 entity based on the connectivity to an L3 entity >>(access gateway). >> >> >> >SA> It may be quite straightforward to statically configure the Layer 2 >entity (Access Point (AP)) with L3 information (IP address) of the >Access Gateway (Foreign Agent) directly connected to it and have this IP >address advertised in the Beacon of the AP. However, it becomes more >problematic to have the AP advertise the IP address of the new Foreign >Agent (FA) the Mobile Node is going to handoff to. In general the AP >cannot guess which Foreign Agent the Mobile Node is going to handoff to. >The AP serving the Mobile Node may not be directly connected to the new >FA. For instance, handoff between a serving AP and a target AP that are >attached to two completely independent networks occurs when moving >between Wi-Fi and 3G. > > > st> The procedures by which the L2 entity discovers a connected or a neighboring L3 entity are beyond the scope of this draft. The layer 2 trigger schemes proposed by this draft can be leveraged by L3 entity discovery schemes. The L3 entity discovery schemes could range from a static configiration to a dynamic configuration based on the reachability of one or more L3 entities from any given L2 entity. Other criteria, such as the associated network capacity, QoS etc. could be used for the selection of an L3 entity that is reachable from an L2 entity. This approach could be used across diverse access technologies (Wi-Fi, 3G etc.) >> Moreover, Layer 2 trigger will actually occur in >>response or in prevision to certain link events such as the >>fading of the relative signal noise ratio below a certain level. >> >>st> Yes. >> >> >> Relying only on link information to initiate a handoff >>does not generally gather enough information for the Mobile >>Node to handoff to the most suitable available access network >>at the most suitable time. >> >>st> See the previous response on L3 information acquisition. >> >> Information from layers higher than Layer 2 (that may >>come from various protocols) can be used as triggers to >>compensate the insufficiency of using Layer 2 triggers alone >>for the Low latency Handoff for MIPv4. >> >>st> The L2 trigger information is used to assist the upper >>layer protocols, in the case of wireless mobility with >>minimum latency, and not vice-versa. Using access technology >>specific schemes, the required L3 information, such as the >>serving access gateway IP address can be obtained from the L2 >>trigger information. >> >> >> > >SA> The use of the Layer 2 trigger alone to assist the upper layer >protocols is exactly what we pinpoint as being an insufficiency. > st> The scope of the L2 trigger schemes for a low-latency handoff allows a variety of techniques to acquire the required L3 information, without specifically defining or restricting them. > If one >relies only on Layer 2 trigger information, the Handoff might always be >initiated towards a network offering the highest signal noise ratio. >However the network offering the best signal noise ratio is not always >the most suitable network for a given Mobile Node to handoff to. >One can introduce an overall system, involving higher layer triggers >that initiate the L3 handoff to the most suitable network before the L2 >handoff actually takes place. > st> The draft proposes the use of L2 triggers to assist an L3 handoff, since L2 is closely tied with the nuances of the associated wireless link technology. > > > > >> >> >> I would also appreciate receiving some feedback upon >>the work presenting scenarios describing how the low latency >>Handoff for MIPv4 is initiated by higher layer triggers. >> >> >>http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlate >>ncy-handoff-triggers-00.txt >>>ency-handoff-triggers-00.txt> >> >> >> >> Cheers >> >> >> >> Stephane >> >> >> >> >> >> >> > > > --------------050309070201030101020303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Stephane,
                          Thanks for your feedback. Please note my comments in-line.

Regards,
      Sebastian


ANTOINE Stephane RD-ILAB-LON wrote: 
Hello Sebastian,

Thanks for your comments. Please find my responses in-line.

Stephane



  
Hello, Stephane,
                               Thanks for your query.

                                Please note my responses in-line.

Regards,
     Sebastian

ANTOINE Stephane RD-ILAB-LON wrote: 

	
	Hello,

	I would like to get some feedback about the problem, as 
described below, of using layer 2 triggers alone to initiate 
the Low latency Handoff for MIPv4:

	  

	The Low Latency Handoff for MIPv4 as described in 

	
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlat
ency-handoffs-v4-11.txt 
<http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowla
tency-handoffs-v4-11.txt> 

	assumes availability of the L2 triggers which contain 
Layer 3 information such as the IP address of the new Foreign 
Agent. Availability of the Layer 3 information is assumed in 
the Layer 2 trigger. However the method by which the Layer 3 
information is made available in the Layer 2 trigger has not 
been specified.

st> The specific procedure used to acquire the L3 
information, such as the IP address of the appropriate access 
gateway is dependent on the access technology over which the 
low-latency handoff scheme is applied. For instance, the 
radio access point or base station identifier could be used 
to determine the L3 information associated with the radio 
access point or the base station (L2 entities). The L3 
information could be statically or dynamically configured at 
the L2 entity based on the connectivity to an L3 entity 
(access gateway).

    
SA> It may be quite straightforward to statically configure the Layer 2
entity (Access Point (AP)) with L3 information (IP address) of the
Access Gateway (Foreign Agent) directly connected to it and have this IP
address advertised in the Beacon of the AP. However, it becomes more
problematic to have the AP advertise the IP address of the new Foreign
Agent (FA) the Mobile Node is going to handoff to. In general the AP
cannot guess which Foreign Agent the Mobile Node is going to handoff to.
The AP serving the Mobile Node may not be directly connected to the new
FA. For instance, handoff between a serving AP and a target AP that are
attached to two completely independent networks occurs when moving
between Wi-Fi and 3G.
st> The procedures by which the L2 entity discovers a connected or a neighboring L3 entity are beyond the scope of this draft. The layer 2 trigger schemes proposed by this draft can be leveraged by L3 entity discovery schemes. The L3 entity discovery schemes could range from a static configiration to a dynamic configuration based on the reachability of one or more L3 entities from any given L2 entity. Other criteria, such as the associated network capacity, QoS etc. could be used for the selection of an L3 entity that is reachable from an L2 entity. This approach could be used across diverse access technologies (Wi-Fi, 3G etc.)

  

    
	Moreover, Layer 2 trigger will actually occur in 
response or in prevision to certain link events such as the 
fading of the relative signal noise ratio below a certain level. 

st> Yes.


	Relying only on link information to initiate a handoff 
does not generally gather enough information for the Mobile 
Node to handoff to the most suitable available access network 
at the most suitable time.

st> See the previous response on L3 information acquisition.

	Information from layers higher than Layer 2 (that may 
come from various protocols) can be used as triggers to 
compensate the insufficiency of using Layer 2 triggers alone 
for the Low latency Handoff for MIPv4.

st> The L2 trigger information is used to assist the upper 
layer protocols, in the case of wireless mobility with 
minimum latency, and not vice-versa. Using access technology 
specific schemes, the required L3 information, such as the 
serving access gateway IP address can be obtained from the L2 
trigger information.

    

  

  

SA> The use of the Layer 2 trigger alone to assist the upper layer
protocols is exactly what we pinpoint as being an insufficiency.



st> The scope of the L2 trigger schemes for a low-latency handoff
allows a variety of techniques to acquire the required L3 information,
without specifically defining or restricting them.



  
 If one
relies only on Layer 2 trigger information, the Handoff might always be
initiated towards a network offering the highest signal noise ratio.
However the network offering the best signal noise ratio is not always
the most suitable network for a given Mobile Node to handoff to.
One can introduce an overall system, involving higher layer triggers
that initiate the L3 handoff to the most suitable network before the L2
handoff actually takes place.



st> The draft proposes the use of L2 triggers to assist an L3
handoff, since L2 is closely tied with the nuances of the associated
wireless link technology.



  
 

  

  

    
	 

	I would also appreciate receiving some feedback upon 
the work presenting scenarios describing how the low latency 
Handoff for MIPv4 is initiated by higher layer triggers.

	
http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlate
ncy-handoff-triggers-00.txt 
<http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlat
ency-handoff-triggers-00.txt> 

	 

	Cheers

	 

	Stephane

	 



    

  

  

  








--------------050309070201030101020303--


--===============0363853001==
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/

--===============0363853001==--




From mip4-bounces@ietf.org Fri Jan 19 10:01:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7vEi-0006jT-S7; Fri, 19 Jan 2007 10:01:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vEh-0006jO-1D
	for mip4@ietf.org; Fri, 19 Jan 2007 10:00:59 -0500
Received: from mail128.messagelabs.com ([216.82.250.131])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7vEf-0005Ka-LU
	for mip4@ietf.org; Fri, 19 Jan 2007 10:00:59 -0500
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-10.tower-128.messagelabs.com!1169218854!3350814!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 23742 invoked from network); 19 Jan 2007 15:00:54 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102)
	by server-10.tower-128.messagelabs.com with SMTP;
	19 Jan 2007 15:00:54 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l0JF0oks003014
	for ; Fri, 19 Jan 2007 08:00:54 -0700 (MST)
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 l0JF0ns3017741
	for ; Fri, 19 Jan 2007 09:00:50 -0600 (CST)
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, 19 Jan 2007 10:00:45 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPR Disclosure on Proxy MIP4
Thread-Index: Acc72pjOIbAub7i6Qu2169YbnZkA9Q==
From: "McCann Peter-A001034" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Mip4] IPR Disclosure on Proxy MIP4
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

FYI.

> -------- Original Message --------
> Subject: Posting of IPR Disclosure
> Date: Thu, 18 Jan 2007 14:16:45 -0500
> From: IETF Secretariat 
> To: kleung@cisco.com
> CC: brc@zurich.ibm.com
>
> Dear Kent Leung:
>
> An IPR disclosure that pertains to your Internet-Draft entitled=20
> "Mobility Management using Proxy Mobile IPv4"=20
> (draft-leung-mip4-proxy-mode) was submitted to the IETF Secretariat on

> 2007-01-11 and has been posted on the "IETF Page of Intellectual=20
> Property Rights Disclosures"
> (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the=20
> IPR disclosure is "Cisco's Statement about IPR Claimed in=20
> draft-leung-mip4-proxy-mode-00.txt."
>
> The IETF Secretariat
>
>
>

-- 
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 Jan 19 10:47:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7vxZ-00075V-Lg; Fri, 19 Jan 2007 10:47:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vxY-00075Q-2m
	for mip4@ietf.org; Fri, 19 Jan 2007 10:47:20 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vxV-0002h7-Hi
	for mip4@ietf.org; Fri, 19 Jan 2007 10:47:20 -0500
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 19 Jan 2007 16:47:09 +0100
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] Problem of using layer 2 triggers alone for the Low
	latencyHandofffor MIPv4
Date: Fri, 19 Jan 2007 16:46:51 +0100
Message-ID: <14FD20369E52DE478BD9612D63BE21B4070F8425@ftrdmel3.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] Problem of using layer 2 triggers alone for the Low
	latencyHandofffor MIPv4
Thread-Index: Acc7OtnClSLqviIpSpKkMjpp75q5lAAnpwEw
From: "ANTOINE Stephane RD-ILAB-LON" 
To: "Sebastian Thalanany" 
X-OriginalArrivalTime: 19 Jan 2007 15:47:09.0564 (UTC)
	FILETIME=[142ECBC0:01C73BE1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
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 Sebastian,

Find some comments in-line...
Thanks,

Stephane



 	=09
> 		st> The specific procedure used to acquire the L3=20
> 		information, such as the IP address of the=20
> appropriate access=20
> 		gateway is dependent on the access technology=20
> over which the=20
> 		low-latency handoff scheme is applied. For=20
> instance, the=20
> 		radio access point or base station identifier=20
> could be used=20
> 		to determine the L3 information associated with=20
> the radio=20
> 		access point or the base station (L2 entities). The L3=20
> 		information could be statically or dynamically=20
> configured at=20
> 		the L2 entity based on the connectivity to an L3 entity=20
> 		(access gateway).
> 	=09
> 		   =20
>=20
> 	SA> It may be quite straightforward to statically=20
> configure the Layer 2
> 	entity (Access Point (AP)) with L3 information (IP=20
> address) of the
> 	Access Gateway (Foreign Agent) directly connected to it=20
> and have this IP
> 	address advertised in the Beacon of the AP. However, it=20
> becomes more
> 	problematic to have the AP advertise the IP address of=20
> the new Foreign
> 	Agent (FA) the Mobile Node is going to handoff to. In=20
> general the AP
> 	cannot guess which Foreign Agent the Mobile Node is=20
> going to handoff to.
> 	The AP serving the Mobile Node may not be directly=20
> connected to the new
> 	FA. For instance, handoff between a serving AP and a=20
> target AP that are
> 	attached to two completely independent networks occurs=20
> when moving
> 	between Wi-Fi and 3G.=20
> =09
> 	 =20
>=20
> st> The procedures by which the L2 entity discovers a connected or a=20
> st> neighboring L3 entity are beyond the scope of this draft.=20
> The layer=20
> st> 2 trigger schemes proposed by this draft can be leveraged by L3=20
> st> entity discovery schemes. The L3 entity discovery schemes could=20
> st> range from a static configiration to a dynamic=20
> configuration based=20
> st> on the reachability of one or more L3 entities from any given L2=20
> st> entity.=20

SA> Having the L2 trigger based handoff initiated by a Layer 3 discovery
mechanism is part of the issues addressed in this draft. The document
does not preclude the use of Layer 2 triggers for the low latency draft
when using higher layer means to discover and initiate the handoff. The
Layer 2 triggers could result from the L3 discovery and initiation
process. Alternatively, Layer 2 triggers can be substituted for higher
layers triggers in a method where only the higher layer triggers are
initiating the low latency handoff. The object of this document is to
inform the community that higher layer triggers can be used to initiate
the Low Latency handoff.


Other criteria, such as the associated network=20
> capacity, QoS=20
> st> etc. could be used for the selection of an L3 entity that is=20
> st> reachable from an L2 entity. This approach could be used across=20
> st> diverse access technologies (Wi-Fi, 3G etc.)

SA> The selection of a L3 entity (FA), to handoff to, based on various
network characteristics, client profiles..., would typically be taken at
a higher level. Hence the introduction of the higher layer triggers.


>=20
>=20
> =09
>=20
> 			Moreover, Layer 2 trigger will actually=20
> occur in=20
> 		response or in prevision to certain link events=20
> such as the=20
> 		fading of the relative signal noise ratio below=20
> a certain level.=20
> 	=09
> 		st> Yes.
> 	=09
> 	=09
> 			Relying only on link information to=20
> initiate a handoff=20
> 		does not generally gather enough information=20
> for the Mobile=20
> 		Node to handoff to the most suitable available=20
> access network=20
> 		at the most suitable time.
> 	=09
> 		st> See the previous response on L3 information=20
> acquisition.
> 	=09
> 			Information from layers higher than=20
> Layer 2 (that may=20
> 		come from various protocols) can be used as triggers to=20
> 		compensate the insufficiency of using Layer 2=20
> triggers alone=20
> 		for the Low latency Handoff for MIPv4.
> 	=09
> 		st> The L2 trigger information is used to=20
> assist the upper=20
> 		layer protocols, in the case of wireless mobility with=20
> 		minimum latency, and not vice-versa. Using=20
> access technology=20
> 		specific schemes, the required L3 information,=20
> such as the=20
> 		serving access gateway IP address can be=20
> obtained from the L2=20
> 		trigger information.
> 	=09
> 		   =20
>=20
> =09
> 	SA> The use of the Layer 2 trigger alone to assist the=20
> upper layer
> 	protocols is exactly what we pinpoint as being an insufficiency.
>=20
> st> The scope of the L2 trigger schemes for a low-latency=20
> handoff allows a variety of techniques to acquire the=20
> required L3 information, without specifically defining or=20
> restricting them.

SA> The draft "Using Higher Layer Triggers for Low Latency Handoffs in
MIPv4" is extending the scope of the triggers used to initiate the low
latency handoff. It is introducing the use of Layer 3 or above triggers
without necessarily relying on layer 2 triggers. The draft is presenting
the motivation for this choice.
http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handof
f-triggers-00.txt=20



>=20
>=20
> 	 If one
> 	relies only on Layer 2 trigger information, the Handoff=20
> might always be
> 	initiated towards a network offering the highest signal=20
> noise ratio.
> 	However the network offering the best signal noise=20
> ratio is not always
> 	the most suitable network for a given Mobile Node to handoff to.
> 	One can introduce an overall system, involving higher=20
> layer triggers
> 	that initiate the L3 handoff to the most suitable=20
> network before the L2
> 	handoff actually takes place.
>=20
> st> The draft proposes the use of L2 triggers to assist an L3=20
> handoff, since L2 is closely tied with the nuances of the=20
> associated wireless link technology.

SA> Using higher layer triggers might consist in passing Layer 2
information to higher layers where the decision to handoff to the most
preferable network is taken.=20

>=20
> 	=20
> =09
> 	 =20
>=20
> 			=20
> 	=09
> 			I would also appreciate receiving some=20
> feedback upon=20
> 		the work presenting scenarios describing how=20
> the low latency=20
> 		Handoff for MIPv4 is initiated by higher layer triggers.
> 	=09
> 		=09
> 	=09
> http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlate
> 		ncy-handoff-triggers-00.txt=20
> 	=09
>  		ency-handoff-triggers-00.txt>=20
>  ency-handoff-triggers-00.txt> =20
> 	=09
> 			=20
> 	=09
> 			Cheers
> 	=09
> 			=20
> 	=09
> 			Stephane
> 	=09
> 			=20
> 	=09
> 	=09
> 	=09
> 		   =20
>=20
> =09
> 	 =20
>=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 Fri Jan 19 11:45:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7wrX-0004O6-Lo; Fri, 19 Jan 2007 11:45:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e4u-00071d-Ih
	for mip4@ietf.org; Thu, 18 Jan 2007 15:41:44 -0500
Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7e4t-0004G7-7o
	for mip4@ietf.org; Thu, 18 Jan 2007 15:41:44 -0500
Received: from saffron.ece.neu.edu (saffron.ece.neu.edu [129.10.60.111])
	by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id l0IKfcog020780
	for ; Thu, 18 Jan 2007 15:41:43 -0500 (EST)
Received: from ECE.NEU.EDU ([129.10.60.216])
	by saffron.ece.neu.edu (SMSSMTP 4.1.5.31) with SMTP id
	M2007011815410029400
	for ; Thu, 18 Jan 2007 15:41:00 -0500
Received: from localhost (basagni@localhost)
	by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id l0IKf0H5004056
	for ; Thu, 18 Jan 2007 15:41:00 -0500
Date: Thu, 18 Jan 2007 15:41:00 -0500 (EST)
From: Stefano Basagni 
To: mip4@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
X-Mailman-Approved-At: Fri, 19 Jan 2007 11:45:10 -0500
Subject: [Mip4] CFP: 18th Tyrrhenian Workshop on Digital Communication
 (Ischia island, Italy)
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 if you receive for multiple copies of this CfP)

         PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS

     18th Tyrrhenian Workshop on Digital Communications
     Ischia island, Naples, Italy  September 9-12, 2007

                       Workshop theme
                  WIRELESS COMMUNICATIONS

* OVERVIEW
The  Tyrrhenian workshop on  digital communications  is each
year  devoted to  a specific  theme in  the area  of digital
communications  and its  applications.  After  several years
the theme  of wireless communications return.   The scope of
the workshop  is a  friendly exchange of  ideas on  the main
research  lines in the  field of  the workshop  theme.  This
year we  have chosen  five chapters, and  to each of  them a
session has been devoted:
-4G wireless systems
-Sensor and ad hoc networks
-Security in wireless networks
-QoS  and efficiency  in  multimedia heterogeneous  wireless
 networks
-Wireless system applications

The  five  sessions  are  in some  sense  complementary  and
interlaced each  other.  Suggested Technical  areas included
in  the  sessions, but  are  not  limited, are:  modulation,
coding,  effects of  system  impairments, channel  modeling,
MIMO  and smart  antennas,  cross layer  and radio  resource
management,   protocols,  routing   in   wireless  networks,
cognitive radio, multimedia wireless communications, Quality
of   Service  architectures,  security,   architectures  for
security, etc.
Some sessions are specifically devoted to and we are looking
for  the  most  advanced  solutions  for  security  and  for
applications   of  wireless   systems   in  many   different
environment,  like multimedia  communications, infomobility,
health care, emergency situations, etc.

Interested  authors  are  invited  to submit  their  papers.
Authors could also submit  papers yet open for discussion in
the area of wireless  communications and its applications to
the poster session.

All submitted papers will  be carefully reviewed and, due to
the  limited space available  in the  sessions some  of them
could be proposed for the inclusion in the poster session.

* PAPER SUBMISSION GUIDELINES
Authors are invited to  submit extended summary of the final
manuscript  of maximum  length  5 pages  including the  main
results  (figures,  tables)  electronically in  PDF  format.
Selection  of the  final manuscripts  will be  based  on the
extended summary.

Final manuscripts to be  considered as regular papers should
be limited  to 15 double-spaced pages.  Final manuscripts to
be considered for the poster session should be limited to 10
double-spaced  pages. Any  paper submitted  to  the Workshop
must  not  have been  published  in  or  submitted to  other
technical   conferences/journals.     Proceedings   of   the
Conference will be published as a book by Springer.

The web page of the workshop will be ready soon at
http://www.cnit.it/html/workshops/2007

* IMPORTANT DATES
Deadline for extended abstract:               March 31, 2007
Notification of acceptance:                   April 30, 2007
Final manuscript submission:                    June 1, 2007

Workshop co-chairs
Shingo Ohmori, NiCT, Japan
Silvano Pupolin, University of Padova and CNIT, Italy

Technical Program Committee
Hiroyo Ogawa, NiCT, Japan
Anand Prasad, NTT Docomo EuroLab, Germany
Kato Shuzo, NiCT, Japan
Michele Zorzi, University of Padova and CNIT, Italy

Publicity
Stefano Basagni, Northeastern University, Boston, MA, USA

Publications
Tomaso Erseghe,  University of Padova and CNIT, Italy





--
Stefano Basagni, Ph.D.      Assistant Professor of Computer Engineering
Dept. of Electrical and Computer Engineering   312 Dana Research Center
Northeastern University            360 Huntington Ave. Boston, MA 02115
Tel. 617 373 3061, Fax 617 373 8970         E-mail: basagni@ece.neu.edu
***               http://www.ece.neu.edu/faculty/basagni/           ***



-- 
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 Jan 19 13:24:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7yQ4-0001ut-RN; Fri, 19 Jan 2007 13:24:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yQ3-0001ul-GW
	for mip4@ietf.org; Fri, 19 Jan 2007 13:24:55 -0500
Received: from nz-out-0506.google.com ([64.233.162.232])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yPm-0003dC-5D
	for mip4@ietf.org; Fri, 19 Jan 2007 13:24:55 -0500
Received: by nz-out-0506.google.com with SMTP id z6so511348nzd
	for ; Fri, 19 Jan 2007 10:24:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=SrawTInfh4XYeUtLpDABTwWd5uRExjixLoCtObM9YbALDe6pM6phHyM/4tI/6KWKyUsVIpbxBjB1O4qxirNL2AjpEGsLNqLsqxDWXItm8UnmM/xerf1mKbcHU1qhmDGE/G5fgILBvwwdOg8oK+/hdi4teOYlK9cPW3ds7IZKCFw=
Received: by 10.35.89.10 with SMTP id r10mr4439989pyl.1169231074435;
	Fri, 19 Jan 2007 10:24:34 -0800 (PST)
Received: from ?10.105.16.28? ( [12.192.138.117])
	by mx.google.com with ESMTP id a70sm2230982pye.2007.01.19.10.24.33;
	Fri, 19 Jan 2007 10:24:33 -0800 (PST)
Message-ID: <45B10CD7.4040008@gmail.com>
Date: Fri, 19 Jan 2007 12:24:23 -0600
From: Sebastian Thalanany 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ANTOINE Stephane RD-ILAB-LON 
Subject: Re: [Mip4] Problem of using layer 2 triggers alone for the Low
	latencyHandofffor MIPv4
References: <14FD20369E52DE478BD9612D63BE21B4070F8425@ftrdmel3.rd.francetelecom.fr>
In-Reply-To: <14FD20369E52DE478BD9612D63BE21B4070F8425@ftrdmel3.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
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, Stephane,
                          Please note my comments in-line. Thanks.

Regards,
     Sebastian

ANTOINE Stephane RD-ILAB-LON wrote:

>Hi Sebastian,
>
>Find some comments in-line...
>Thanks,
>
>Stephane
>
>
>
> 		
>  
>
>>		st> The specific procedure used to acquire the L3 
>>		information, such as the IP address of the 
>>appropriate access 
>>		gateway is dependent on the access technology 
>>over which the 
>>		low-latency handoff scheme is applied. For 
>>instance, the 
>>		radio access point or base station identifier 
>>could be used 
>>		to determine the L3 information associated with 
>>the radio 
>>		access point or the base station (L2 entities). The L3 
>>		information could be statically or dynamically 
>>configured at 
>>		the L2 entity based on the connectivity to an L3 entity 
>>		(access gateway).
>>		
>>		    
>>
>>	SA> It may be quite straightforward to statically 
>>configure the Layer 2
>>	entity (Access Point (AP)) with L3 information (IP 
>>address) of the
>>	Access Gateway (Foreign Agent) directly connected to it 
>>and have this IP
>>	address advertised in the Beacon of the AP. However, it 
>>becomes more
>>	problematic to have the AP advertise the IP address of 
>>the new Foreign
>>	Agent (FA) the Mobile Node is going to handoff to. In 
>>general the AP
>>	cannot guess which Foreign Agent the Mobile Node is 
>>going to handoff to.
>>	The AP serving the Mobile Node may not be directly 
>>connected to the new
>>	FA. For instance, handoff between a serving AP and a 
>>target AP that are
>>	attached to two completely independent networks occurs 
>>when moving
>>	between Wi-Fi and 3G. 
>>	
>>	  
>>
>>st> The procedures by which the L2 entity discovers a connected or a 
>>st> neighboring L3 entity are beyond the scope of this draft. 
>>The layer 
>>st> 2 trigger schemes proposed by this draft can be leveraged by L3 
>>st> entity discovery schemes. The L3 entity discovery schemes could 
>>st> range from a static configiration to a dynamic 
>>configuration based 
>>st> on the reachability of one or more L3 entities from any given L2 
>>st> entity. 
>>    
>>
>
>SA> Having the L2 trigger based handoff initiated by a Layer 3 discovery
>mechanism is part of the issues addressed in this draft. The document
>does not preclude the use of Layer 2 triggers for the low latency draft
>when using higher layer means to discover and initiate the handoff. The
>Layer 2 triggers could result from the L3 discovery and initiation
>process. Alternatively, Layer 2 triggers can be substituted for higher
>layers triggers in a method where only the higher layer triggers are
>initiating the low latency handoff. The object of this document is to
>inform the community that higher layer triggers can be used to initiate
>the Low Latency handoff.
>  
>
st> The low-latency draft proposes the L2 triggers to optimize L3 
handoff. It does not preclude other L3 or upper layer initiated handoff. 
The techniques proposed in the low-latency draft can be applied together 
with other L3 schemes.

>
>Other criteria, such as the associated network 
>  
>
>>capacity, QoS 
>>st> etc. could be used for the selection of an L3 entity that is 
>>st> reachable from an L2 entity. This approach could be used across 
>>st> diverse access technologies (Wi-Fi, 3G etc.)
>>    
>>
>
>SA> The selection of a L3 entity (FA), to handoff to, based on various
>network characteristics, client profiles..., would typically be taken at
>a higher level. Hence the introduction of the higher layer triggers.
>  
>
st> This draft is based on the use of L2 triggers that are based on the 
radio-link conditions. The L3 and above entities are not implicitly 
aware of radio-link conditions. The intent of the draft is not to define 
conditions or triggers at L3 or above.

>
>  
>
>>	
>>
>>			Moreover, Layer 2 trigger will actually 
>>occur in 
>>		response or in prevision to certain link events 
>>such as the 
>>		fading of the relative signal noise ratio below 
>>a certain level. 
>>		
>>		st> Yes.
>>		
>>		
>>			Relying only on link information to 
>>initiate a handoff 
>>		does not generally gather enough information 
>>for the Mobile 
>>		Node to handoff to the most suitable available 
>>access network 
>>		at the most suitable time.
>>		
>>		st> See the previous response on L3 information 
>>acquisition.
>>		
>>			Information from layers higher than 
>>Layer 2 (that may 
>>		come from various protocols) can be used as triggers to 
>>		compensate the insufficiency of using Layer 2 
>>triggers alone 
>>		for the Low latency Handoff for MIPv4.
>>		
>>		st> The L2 trigger information is used to 
>>assist the upper 
>>		layer protocols, in the case of wireless mobility with 
>>		minimum latency, and not vice-versa. Using 
>>access technology 
>>		specific schemes, the required L3 information, 
>>such as the 
>>		serving access gateway IP address can be 
>>obtained from the L2 
>>		trigger information.
>>		
>>		    
>>
>>	
>>	SA> The use of the Layer 2 trigger alone to assist the 
>>upper layer
>>	protocols is exactly what we pinpoint as being an insufficiency.
>>
>>st> The scope of the L2 trigger schemes for a low-latency 
>>handoff allows a variety of techniques to acquire the 
>>required L3 information, without specifically defining or 
>>restricting them.
>>    
>>
>
>SA> The draft "Using Higher Layer Triggers for Low Latency Handoffs in
>MIPv4" is extending the scope of the triggers used to initiate the low
>latency handoff. It is introducing the use of Layer 3 or above triggers
>without necessarily relying on layer 2 triggers. The draft is presenting
>the motivation for this choice.
>http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handof
>f-triggers-00.txt 
>  
>
st> Good. Reliance on L2 conditions is essential, since the radio-link 
is stochastic in nature, and L3 and above layers cannot be expected to 
implicity determine radio-link conditions. L2 information is required by 
the L3 and above layers for handoff related optimization. The 
low-latency draft proposal does not preclude other L3 
conditions/triggers such as network capacity, load balancing etc. which 
could force a handoff in cases where the radio-link condition is not 
impacted.

>
>
>  
>
>>	 If one
>>	relies only on Layer 2 trigger information, the Handoff 
>>might always be
>>	initiated towards a network offering the highest signal 
>>noise ratio.
>>	However the network offering the best signal noise 
>>ratio is not always
>>	the most suitable network for a given Mobile Node to handoff to.
>>	One can introduce an overall system, involving higher 
>>layer triggers
>>	that initiate the L3 handoff to the most suitable 
>>network before the L2
>>	handoff actually takes place.
>>
>>st> The draft proposes the use of L2 triggers to assist an L3 
>>handoff, since L2 is closely tied with the nuances of the 
>>associated wireless link technology.
>>    
>>
>
>SA> Using higher layer triggers might consist in passing Layer 2
>information to higher layers where the decision to handoff to the most
>preferable network is taken. 
>  
>
st> Yes. L3 and above triggers or conditions are beyond the scope of 
this draft.

>  
>
>>	 
>>	
>>	  
>>
>>			 
>>		
>>			I would also appreciate receiving some 
>>feedback upon 
>>		the work presenting scenarios describing how 
>>the low latency 
>>		Handoff for MIPv4 is initiated by higher layer triggers.
>>		
>>			
>>		
>>http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlate
>>		ncy-handoff-triggers-00.txt 
>>		
>>>		ency-handoff-triggers-00.txt> 
>>>ency-handoff-triggers-00.txt>  
>>		
>>			 
>>		
>>			Cheers
>>		
>>			 
>>		
>>			Stephane
>>		
>>			 
>>		
>>		
>>		
>>		    
>>
>>	
>>	  
>>
>>
>>
>>    
>>
>
>  
>


-- 
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 Jan 19 13:51:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ypn-0006HV-Rp; Fri, 19 Jan 2007 13:51:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7ypm-0006H4-Ej; Fri, 19 Jan 2007 13:51:30 -0500
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1H7ypk-0002DB-Tu; Fri, 19 Jan 2007 13:51:30 -0500
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-15.tower-153.messagelabs.com!1169232687!101675!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 11668 invoked from network); 19 Jan 2007 18:51:27 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-15.tower-153.messagelabs.com with SMTP;
	19 Jan 2007 18:51:27 -0000
Received: from az33exr04.mot.com ([10.64.251.234])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0JIpQxl000452;
	Fri, 19 Jan 2007 11:51:27 -0700 (MST)
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 l0JIpNKs002872;
	Fri, 19 Jan 2007 12:51:24 -0600 (CST)
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, 19 Jan 2007 13:51:21 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Request to advance draft-ietf-mip4-mobike-connectivity-02.txt to
	Best Current Practice
Thread-Index: Acc7+s+ZtNboD1urTc6w4FeBcd50AQ==
From: "McCann Peter-A001034" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Cc: mip4@ietf.org, mip4-ads@tools.ietf.org
Subject: [Mip4] Request to advance
	draft-ietf-mip4-mobike-connectivity-02.txt to Best Current Practice
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-mobike-connectivity-02.txt,
"Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE",=20
to Best Current Practice.  The draft has completed its 2nd working
group last call and all issues have been addressed.  Questionnaire=20
answers are below.

>    (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 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 2 working group last calls and substantive
comments were received each time.  All comments have been addressed
in the latest version.

>    (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?

The document is authored by knowledgeable IPSec experts, but perhaps
it could benefit from a more official security area review.  The topic
of the draft is directly related to security, but many of the security
concerns are similar to the earlier Mobile IP VPN traversal mechanism
described in draft-ietf-mip4-vpn-problem-solution-02.txt.

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

>    (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?

The document received pretty broad review during the two working group
last calls.

>    (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, there are no pending disagreements about the document.

>    (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 serious nits were found, but the following should be noted:

The document uses RFC 3978 boilerplate instead of RFC 4748 boilerplate.

In section 2, the key words usage statement appears twice, once at the
beginning of the section and once at the end.

In section 3.2, 3rd line, there is a repeated "address" in the text:
   The
   mobile node always configures a care-of address address through DHCP
Also in section 3.2, the word "the" is repeated in the text:
   all times at the home agent mapping the the home address to the

Section 3.4.1:
      sent in step 2,
should be:
      sent in step 1b,

>    (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, the references are split.  There is a normative reference to
draft-ietf-mip4-vpn-problem-solution-02, which is still in progress
but expected to go to BCP.  No downward normative references exist.

>    (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 has no IANA actions required, and contains a section 6 IANA
Considerations which states this explicitly.

>    (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 such formal language constructs used 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

This document describes the interaction of Mobile IPv4 and MOBIKE.
The focus is on providing access to an enterprise or operator private
network where the mobile node can connect either directly on trusted
links or through a VPN gateway from the untrusted Internet.  The
document outlines various scenarios for the different arrangements of
VPN and Mobile IP tunnels, and recommends procedures for execution
upon detection of mobility events.

>           Working Group Summary

This document is a product of the Mobile IPv4 working group.  It
has gone through 2 working group last calls and is mature and
ready for publication.

>           Document Quality

Document quality is good.

>           Personnel
>              Who is the Document Shepherd for this document?  Who is
the
>              Responsible Area Director?

Document shepherd: Pete McCann
Responsible AD: Jari Arkko
=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 Jan 19 13:56:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7yuN-0001Tl-7k; Fri, 19 Jan 2007 13:56:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yuL-0001Mf-Fb
	for mip4@ietf.org; Fri, 19 Jan 2007 13:56:13 -0500
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yuK-0002l6-7E
	for mip4@ietf.org; Fri, 19 Jan 2007 13:56:13 -0500
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id 5B59E3B6448
	for ; Fri, 19 Jan 2007 10:56:11 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 30532-10 for ; Fri, 19 Jan 2007 10:56:11 -0800 (PST)
Received: from [155.53.42.154] (trilobite.redback.com [155.53.42.154])
	by prattle.redback.com (Postfix) with ESMTP id 490943B6446
	for ; Fri, 19 Jan 2007 10:56:06 -0800 (PST)
Message-ID: <45B11445.7080501@redback.com>
Date: Fri, 19 Jan 2007 10:56:05 -0800
From: Chezhian Renganathan 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: mip4@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: [Mip4] Mipv4 conformance
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

Hello,
I believe Sun has some mipv4 conformance test tool. I saw something to 
this effect
in a 'connectathon 2002' interoperability test update document. If 
someone knows
of other sources for conformance please let me know.
thanks
chez


-- 
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 Jan 19 14:28:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7zPn-0006xn-96; Fri, 19 Jan 2007 14:28:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zPl-0006xh-V6
	for mip4@ietf.org; Fri, 19 Jan 2007 14:28:41 -0500
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7zPk-0000rJ-JY
	for mip4@ietf.org; Fri, 19 Jan 2007 14:28:41 -0500
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-4.tower-153.messagelabs.com!1169234919!161536!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 31950 invoked from network); 19 Jan 2007 19:28:39 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-4.tower-153.messagelabs.com with SMTP;
	19 Jan 2007 19:28:39 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0JJSdWb012521
	for ; Fri, 19 Jan 2007 12:28:39 -0700 (MST)
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 l0JJScdB002156
	for ; Fri, 19 Jan 2007 13:28:38 -0600 (CST)
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, 19 Jan 2007 14:28:37 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: FMIPv4
Thread-Index: Acc8AASUplSd4qsRSkS2TCi7YmXLWQ==
From: "McCann Peter-A001034" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: [Mip4] FMIPv4
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 San Diego at IETF 67 we saw a presentation of the=20
changes in draft-ietf-mip4-fmipv4-02.txt.  However,
we have not had any list discussion on whether the
changes were adequate.

Can I ask all those who made comments to review the
current draft, available at:

http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-02.txt

If there are no further issues I will send the draft
up for publication next week.

-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 Jan 19 18:50:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H83VF-0006cx-35; Fri, 19 Jan 2007 18:50:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H83VB-0006YI-94; Fri, 19 Jan 2007 18:50:33 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H83VA-0001Ik-UO; Fri, 19 Jan 2007 18:50:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5EE352AD7D;
	Fri, 19 Jan 2007 23:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H83Ug-0008BO-4F; Fri, 19 Jan 2007 18:50:02 -0500
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, 19 Jan 2007 18:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: mip4@ietf.org
Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc2006bis-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		: The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised
	Author(s)	: R. Rathi, et al.
	Filename	: draft-ietf-mip4-rfc2006bis-03.txt
	Pages		: 112
	Date		: 2007-1-19
	
This memo defines a portion of the Management Information Base (MIB) 
   for use with network management protocols in the Internet community. 
   In particular, it describes managed objects used for managing the 
   Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc2006bis-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-rfc2006bis-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-rfc2006bis-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-1-19154223.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-03.txt

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

Content-Type: text/plain
Content-ID: <2007-1-19154223.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 Fri Jan 19 18:55:51 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H83aJ-0000JY-St; Fri, 19 Jan 2007 18:55:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H83Zd-0008De-8w; Fri, 19 Jan 2007 18:55:09 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H83Ug-0001Z5-BG; Fri, 19 Jan 2007 18:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4946332A64;
	Fri, 19 Jan 2007 23:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H83Ug-0008BR-4z; Fri, 19 Jan 2007 18:50:02 -0500
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, 19 Jan 2007 18:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: mip4@ietf.org
Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc2006bis-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		: The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised
	Author(s)	: R. Rathi, et al.
	Filename	: draft-ietf-mip4-rfc2006bis-03.txt
	Pages		: 112
	Date		: 2007-1-19
	
This memo defines a portion of the Management Information Base (MIB) 
   for use with network management protocols in the Internet community. 
   In particular, it describes managed objects used for managing the 
   Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc2006bis-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-rfc2006bis-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-rfc2006bis-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-1-19154628.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-03.txt

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

Content-Type: text/plain
Content-ID: <2007-1-19154628.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 Jan 22 09:58:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H90cF-0003up-4S; Mon, 22 Jan 2007 09:57:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H90cE-0003ud-B6; Mon, 22 Jan 2007 09:57:46 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H90cA-0003Qx-GQ; Mon, 22 Jan 2007 09:57:46 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	07E5B20C7E; Mon, 22 Jan 2007 15:54:34 +0100 (CET)
X-AuditID: c1b4fb3c-b06a4bb000003b9d-92-45b4d0292bff 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	D131120AAA; Mon, 22 Jan 2007 15:54:33 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 Jan 2007 15:54:33 +0100
Received: from [147.214.237.61] ([147.214.237.61]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 Jan 2007 15:54:33 +0100
Message-ID: <45B4D029.5090205@levkowetz.com>
Date: Mon, 22 Jan 2007 15:54:33 +0100
From: Henrik Levkowetz 
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: IESG Secretary ,  mip4-chairs@tools.ietf.org, 
	mip4-ads@tools.ietf.org,  mip4@ietf.org
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2007 14:54:33.0548 (UTC)
	FILETIME=[3A4A38C0:01C73E35]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Cc: 
Subject: [Mip4] Request to advance draft-ietf-mip4-message-string-ext 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-message-string-ext-02,
"Mobile IPv4 Message String Extension", to Proposed Standard.  The
draft has completed its working group last call and all issues have
been addressed.


Regards,

	Henrik

--------

Here's the Document Shepherd Write-Up:

>    (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?

Henrik Levkowetz is Document Shepherd for this document.

Yes, I've personally reviewed this version of the document and believe
it is ready for forwarding to the IESG 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 through WG last call and additional review.  I
don't have any concerns about depth or breath 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.

>    (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 has not been any expressed disagreement about the purpose or need
for this document; the only strong discussion has been about details in
wording of one of the paragraph, which has been resolved.

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

>    (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?

Yes.

>    (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 split references (Note: the shepherd writeup template needs
updating on this point; this overlaps the requirements of the ID-Checklist).

All normative references are to published documents.  One normative reference
is to a BCP (RFC 2434), and should not be normative; it should be listed as
an informative reference or removed (it is *not* needed for implementation
of this specification).

>    (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?

Yes to all of these except a name for the new subtype registry; here the
name of the subtype is routinely used in the IANA registry for MIPv4
extension subtypes.  As for the Expert Review required, it is specified
to use the same mechanism (and presumably expert) as RFC 3344.

>    (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?

Not applicable.

>    (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:
> 
>           Technical Summary
>              Relevant content can frequently be found in the abstract
>              and/or introduction of the document.  If not, this may be
>              an indication that there are deficiencies in the abstract
>              or introduction.
> 
>           Working Group Summary
>              Was there anything in WG process that is worth noting?  For
>              example, was there controversy about particular points or
>              were there decisions where the consensus was particularly
>              rough?
> 
>           Document Quality
>              Are there existing implementations of the protocol?  Have a
>              significant number of vendors indicated their plan to
>              implement the specification?  Are there any reviewers that
>              merit special mention as having done a thorough review,
>              e.g., one that resulted in important changes or a
>              conclusion that the document had no substantive issues?  If
>              there was a MIB Doctor, Media Type or other expert review,
>              what was its course (briefly)?  In the case of a Media Type
>              review, on what date was the request posted?
> 
>           Personnel
>              Who is the Document Shepherd for this document?  Who is the
>              Responsible Area Director?

Technical Summary

   This document specifies a new extension for use in Mobile IPv4.  This
   extension can be added by the Home Agent and the Foreign Agent to
   Registration Reply messages.  This extension carries a text string
   that is intended for the user of the Mobile Node.

Working Group Summary

   There is consensus in the MIP4 working group to publish this document
   as a Proposed Standard. 

Document Quality

   The document has been through working group last call and additional
   reviews.
 
Personnel
       
   Document Sheperd for this document is Henrik Levkowetz, and Jari Arkko
   is the Responsible Area Director.





-- 
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 Jan 22 10:17:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H90uy-0002cw-VI; Mon, 22 Jan 2007 10:17:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H90ux-0002cp-LU
	for mip4@ietf.org; Mon, 22 Jan 2007 10:17:07 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H90uv-0001Jn-QA
	for mip4@ietf.org; Mon, 22 Jan 2007 10:17:07 -0500
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 Jan 2007 16:16:54 +0100
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] Problem of using layer 2 triggers alone for the Low
	latencyHandoffforMIPv4
Date: Mon, 22 Jan 2007 16:16:50 +0100
Message-ID: <14FD20369E52DE478BD9612D63BE21B4070F842C@ftrdmel3.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] Problem of using layer 2 triggers alone for the Low
	latencyHandoffforMIPv4
Thread-Index: Acc79xQbfbIl69EASQuA8GKZfX7D3gCPi9Mw
From: "ANTOINE Stephane RD-ILAB-LON" 
To: "Sebastian Thalanany" 
X-OriginalArrivalTime: 22 Jan 2007 15:16:54.0440 (UTC)
	FILETIME=[59861A80:01C73E38]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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


Sebastian, thanks for your reply=20
More comments in-line...

> >
> >SA> The draft "Using Higher Layer Triggers for Low Latency=20
> Handoffs in
> >MIPv4" is extending the scope of the triggers used to=20
> initiate the low
> >latency handoff. It is introducing the use of Layer 3 or=20
> above triggers
> >without necessarily relying on layer 2 triggers. The draft=20
> is presenting
> >the motivation for this choice.
> >http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlat
> ency-handof
> >f-triggers-00.txt=20
> > =20
> >
> st> Good. Reliance on L2 conditions is essential, since the=20
> radio-link=20
> is stochastic in nature, and L3 and above layers cannot be=20
> expected to=20
> implicity determine radio-link conditions. L2 information is=20
> required by=20
> the L3 and above layers for handoff related optimization. The=20
> low-latency draft proposal does not preclude other L3=20
> conditions/triggers such as network capacity, load balancing=20
> etc. which=20
> could force a handoff in cases where the radio-link condition is not=20
> impacted.
>=20

SA> The Low Latency draft as it is only relies on the L2 triggers
without precluding any L3 discovery, decision scheme ...Similarly the
draft "Using higher layer trigger for the low latency draft"=20
http://www.ietf.org/internet-drafts/draft-antoine-mip4-lowlatency-handof
f-triggers-00.txt=20
points out that Higher layer triggers can be used without precluding any
L3 discovery mechanism. Moreover, the draft presents the benefits of
relying on higher Layer triggers instead of L2 triggers alone.
I think the low latency handoff in MIPv4 should not restrict the origin
of the trigger. The Low latency should be independent of whether the
trigger initiating the L3 handoff comes from L2 or higher layers. What I
suggest is to have a separation of the work into 2 main parts:=20
1.	The Low Latency Handoff without mention of the origin of the
trigger.
2.	Mechanisms to trigger the Low latency from Layer 2 or from
higher Layers.=20


Cheers
Stephane

-- 
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 Jan 22 12:50:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H93J7-0004bS-Vk; Mon, 22 Jan 2007 12:50:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H93J6-0004bA-NE
	for mip4@ietf.org; Mon, 22 Jan 2007 12:50:12 -0500
Received: from mail119.messagelabs.com ([216.82.241.179])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H93J5-0001qp-Eh
	for mip4@ietf.org; Mon, 22 Jan 2007 12:50:12 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-6.tower-119.messagelabs.com!1169488210!9753968!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 25976 invoked from network); 22 Jan 2007 17:50:10 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-6.tower-119.messagelabs.com with SMTP;
	22 Jan 2007 17:50:10 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0MHo5Gm007730
	for ; Mon, 22 Jan 2007 10:50:10 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0MHo4kt022726;
	Mon, 22 Jan 2007 11:50:04 -0600 (CST)
Message-ID: <45B4F94B.7080309@motorola.com>
Date: Mon, 22 Jan 2007 18:50:03 +0100
From: Alexandru Petrescu 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: McCann Peter-A001034 
Subject: Re: [Mip4] FMIPv4
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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:
> In San Diego at IETF 67 we saw a presentation of the changes in 
> draft-ietf-mip4-fmipv4-02.txt.  However, we have not had any list 
> discussion on whether the changes were adequate.
> 
> Can I ask all those who made comments to review the current draft, 
> available at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-02.txt

REviewing it...

BAsically I'm fine with it, here's a few minor editorial.

> Optimizations have been proposed and are being standardized in IEEE 
> however.

... for example IEEE 802.11r (Fast Roaming, Fast BSS Transition) and to
a certain extent 802.21; probably worth mentioning.

> The design of the protocol is the same as for Mobile IPv6 [2]. 
> Readers should consult [2] for details, and here we provide a 
> summary.
[...]
> [2] R. Koodli (Editor).  Fast Handovers for Mobile IPv6 (work in 
> progress).  Internet Draft, Internet Engineering Task Force. 
> draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.

Editing nit.  The draft referred as [2] no longer exists I believe.  I
think there may be plans in the mipshop WG to take RFC4068 on a Stds
Track.  So maybe RFC4068 and RFC3775 should be referred for the moment,
or any other update more up to date.  This '[2]' is cited several times
in the draft.

> 5.3. Router Solicitation for Proxy Advertisement (RtSolPr)

Is this an RS carried as ICMP (RFC1256) or as ICMPv6.  Encoding is 
different.  Remark that existing implementations of ICMPv4 RS could be 
re-used for minimal modifications, or otherwise ICMPv6 could be re-used. 
  It's a choice.  But in a FMIPv4 deployment one wouldn't assume 
availability of ICMPv6... or maybe yes (?).  Also it's strange to use 
Checksum field as computed from rfc1256 but the format from ICMPv6.

Same for Proxy Router Advertisement.

Alex



-- 
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 Jan 22 13:55:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H94Jy-0003Ty-OP; Mon, 22 Jan 2007 13:55:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H93QG-00063u-AR; Mon, 22 Jan 2007 12:57:36 -0500
Received: from [2001:12f0:201:1:202:e3ff:fe0f:b8d] (helo=mailman.ufsc.br)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H93QB-0002Zj-Rm; Mon, 22 Jan 2007 12:57:36 -0500
Received: from localhost (localhost [127.0.0.1])
	by mailman.ufsc.br (Postfix) with ESMTP id 1BC867E9B5;
	Mon, 22 Jan 2007 15:54:16 -0200 (BRST)
Received: from mailman.ufsc.br ([127.0.0.1])
	by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10250-01; Mon, 22 Jan 2007 15:54:02 -0200 (BRST)
Received: from mailman.ufsc.br (mailman.ufsc.br [150.162.1.5])
	by mailman.ufsc.br (Postfix) with ESMTP id 3FC067E85A;
	Mon, 22 Jan 2007 15:52:51 -0200 (BRST)
X-Original-To: researchers@mailman.ufsc.br
Delivered-To: researchers@mailman.ufsc.br
Received: from localhost (localhost [127.0.0.1])
	by mailman.ufsc.br (Postfix) with ESMTP id 525E37E80A
	for ;
	Mon, 22 Jan 2007 15:52:43 -0200 (BRST)
Received: from mailman.ufsc.br ([127.0.0.1])
	by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10064-04 for ;
	Mon, 22 Jan 2007 15:52:36 -0200 (BRST)
Received: from rot.barddal.br (44054.static.fln.virtua.com.br [200.174.44.54])
	by mailman.ufsc.br (Postfix) with ESMTP id C4C807E7F8
	for ;
	Mon, 22 Jan 2007 15:52:36 -0200 (BRST)
Received: from mi0f9a3e303b4e (201-3-219-69.fnsce7004.dsl.brasiltelecom.net.br
	[201.3.219.69]) (authenticated bits=0)
	by rot.barddal.br (8.13.1/8.13.1) with ESMTP id l0MHqjqp009204;
	Mon, 22 Jan 2007 17:52:45 GMT
Message-ID: <04d101c73e4e$457400f0$6800a8c0@mi0f9a3e303b4e>
From: "Profa Mirela Sechi Moretti Annoni Notare" 
To: 
Date: Mon, 22 Jan 2007 15:53:41 -0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-barddal-MailScanner-Information: Please contact the ISP for more information
X-barddal-MailScanner: Found to be clean
X-barddal-MailScanner-SpamCheck: spam, SpamAssassin (not cached,
	escore=8.682, requerido 6, BAYES_00 -2.60, HELO_DYNAMIC_IPADDR 4.40,
	RCVD_IN_DSBL 3.81, RCVD_IN_XBL 3.08)
X-barddal-MailScanner-SpamScore: ssssssss
X-barddal-MailScanner-From: mirela@barddal.br
X-Virus-Scanned: by amavisd-new at mailman.ufsc.br
X-BeenThere: researchers@mailman.ufsc.br
X-Mailman-Version: 2.1.5
Precedence: list
X-Virus-Scanned: by amavisd-new at mailman.ufsc.br
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
X-Mailman-Approved-At: Mon, 22 Jan 2007 13:55:09 -0500
Cc: 
Subject: [Mip4] [Researchers] {Spam?} 32th IEEE LCN'2007  - Dublin,
	15-18/10/2006.
X-BeenThere: mip4@ietf.org
List-Id: Mobility for IPv4 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: mip4-bounces@ietf.org

=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=3D=3D=3D=3D=3D
Apologies if you receive multiple copies of this Call for Papers
=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=3D=3D=3D=3D=3D

                           LCN 2007
               The 32nd Annual IEEE Conference on
                 Local Computer Networks (LCN)
                     http://www.ieeelcn.org

             Sponsored by the IEEE Computer Society (pending)
                 with support from the Telecommunications
                      Software & Systems Group (TSSG)/
                     Waterford Institute of Technology

                          Dublin, Ireland
                        October 15-18, 2007

                         CALL FOR PAPERS

LCN invites you to Europe for the second time in its history! The IEEE LC=
N
conference is the premier conference on the leading edge of practical=20
computer
networking. LCN is a highly interactive conference that enables an effect=
ive
interchange of results and ideas among researchers, users, and product=20
developers.
During 32 years of this conference, major developments from high-speed lo=
cal
networks to the global Internet to specialized sensor networks have been
reported at this conference.  We encourage you to submit original papers
describing research results or practical solutions in leading edge topics=
.
Paper topics include, but are not limited to:

Ad hoc and sensor networks       Adaptive applications
Embedded networks                Authentication, authorization, accountin=
g
High-speed access networks       Congestion and flow control
Home and SOHO networks           Context-aware network services
IPv6 networks                    IPv6 deployment and migration
Local area networks              Mobility management
Optical networks                 Multimedia and real-time communication
Overlay networks                 Network management
Peer-to-peer networks            Network reliability and security
Personal and wearable networks   Network traffic characterization
Storage area networks            Performance evaluation/engineering
Ubiquitous networking            Performance measurement and tuning
Wireless networks                Quality-of-Service provisioning

Authors are invited to submit full or short papers for presentation at th=
e
conference. Full 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 conference. Short papers are an opportunity to prese=
nt
preliminary or interim results and are limited to 2 camera-ready pages in
length. Short papers will be presented in a poster format and are publish=
ed
in the proceedings. All papers must include title, complete contact
information for all authors, abstract, and keywords on the cover page.

PAPER SUBMISSION:
Papers must be submitted electronically in PDF. All submission instructio=
ns=20
will
be posted on the conference website.  Please direct your questions to the
program co-chairs, Matthias Frank   and Ehab Elmalla=
h
.

IMPORTANT DATES:
Paper registration deadline: April 2, 2007
Paper submission deadline:   April 9, 2007
Notification of acceptance:  June 25, 2007
Camera-ready paper due:      July 23, 2007
Author registration by:      July 23, 2007

WORKSHOPS:
A number of workshops will be co-located with the conference. Workshop=20
papers
will be published in the LCN proceedings. Information on workshops,=20
submission
deadlines and all other details will be posted on the conference web site=
.

General Chair:
- Ken Christensen, University of South Florida
Program Chair:
- Matthias Frank, University of Bonn
Program Co-Chair:
- Ehab Elmallah, University of Alberta
Finance Chair:
- Frank H=FCbner, AT&T Labs
Local Arrangements Chair:
- Tom Pfeifer, TSSG, Waterford IT
Workshops Chair:
- Chun Tung Chou, University of New South Wales
Publication Chair:
- Mohamed Younis, University of  Maryland, BC
Publicity Chair:
- Azzedine Boukerche, University of Ottawa
Corporate Relations Chair:
- Declan O'Sullivan, Trinity College Dublin
International Advisors:
- Burkhard Stiller, University of Z=FCrich and ETH Z=FCrich
- Hossam Hassanein, Queen's University, Canada
- Sanjay Jha, University of New South Wales
Webmaster:
-Gary Kessler, Champlain College

Standing Committee:
- Joe Bumblis, BAE Systems
- Hossam Hassanein, Queen's University, Canada
- Gary Kessler, Champlain College
- Peter Martini, University of Bonn
- Burkhard Stiller, University of Z=FCrich and ETH Z=FCrich
- Tim Strayer, BBN=20


--=20
Esta mensagem foi verificada pelo sistema de antiv=EDrus e
 acredita-se estar livre de perigo.

_______________________________________________
Researchers mailing list
Researchers@mailman.ufsc.br
http://mailman.ufsc.br/mailman/listinfo/researchers

-- 
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 Jan 23 05:39:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9J47-0008Dm-Ha; Tue, 23 Jan 2007 05:39:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9J46-0008Dh-9u
	for mip4@ietf.org; Tue, 23 Jan 2007 05:39:46 -0500
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9J45-0005Lv-1N
	for mip4@ietf.org; Tue, 23 Jan 2007 05:39:46 -0500
Received: from p130.piuha.net (localhost [127.0.0.1])
	by p130.piuha.net (Postfix) with ESMTP id CEA7D19876D;
	Tue, 23 Jan 2007 12:39:39 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 7B614198766;
	Tue, 23 Jan 2007 12:39:39 +0200 (EET)
Message-ID: <45B5E5EC.8030901@piuha.net>
Date: Tue, 23 Jan 2007 12:39:40 +0200
From: Jari Arkko 
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: vsastry@cisco.com, "Kent Leung (kleung)" 
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: 7655788c23eb79e336f5f8ba8bce7906
Cc: Mobile IPv4 Mailing List ,
	Henrik Levkowetz 
Subject: [Mip4] AD review of draft-ietf-mip4-message-string-ext-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


I have reviewed this specification. I have two issues that
need a small text change before we can go forward.
Otherwise the draft looks great.

Here are my issues:

1) The draft uses serviceprovider.com and paymore.com
as example domain names. You should only use the
names reserved for example purposes in RFC 2606.
Say, paymore.example.com or eliminate the name
entirely.

2) The subtype registry IANA allocation rules have
not been specified. Please indicate the policy that
you wish to be used, e.g., IETF Consensus. Alternatively,
if there are other documents that specify the default
MIP4 subtype allocation rules, refer to them.

I'm expecting a revised draft.

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 Tue Jan 23 06:59:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9KIu-0005D5-I1; Tue, 23 Jan 2007 06:59:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9KIt-0005BY-W1
	for mip4@ietf.org; Tue, 23 Jan 2007 06:59:07 -0500
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9KIs-0004EF-No
	for mip4@ietf.org; Tue, 23 Jan 2007 06:59:07 -0500
Received: from p130.piuha.net (localhost [127.0.0.1])
	by p130.piuha.net (Postfix) with ESMTP id 7961C19876D;
	Tue, 23 Jan 2007 13:59:05 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 29A4B19876C;
	Tue, 23 Jan 2007 13:59:05 +0200 (EET)
Message-ID: <45B5F88A.2030902@piuha.net>
Date: Tue, 23 Jan 2007 13:59:06 +0200
From: Jari Arkko 
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: Vijay Devarapalli , 
	Pasi Eronen 
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: 6d62ab47271805379d7172ee693a45db
Cc: Pete McCann , Mobile IPv4 Mailing List 
Subject: [Mip4] AD review of draft-ietf-mip4-mobike-connectivity-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

I have reviewed this specification. I found no issues.
It will be sent for IETF Last Call.

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 Tue Jan 23 09:40:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9Mot-0006XN-9P; Tue, 23 Jan 2007 09:40:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Mos-0006XH-6s
	for mip4@ietf.org; Tue, 23 Jan 2007 09:40:18 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Mon-0002oh-LF
	for mip4@ietf.org; Tue, 23 Jan 2007 09:40:18 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	30216217A4; Tue, 23 Jan 2007 15:38:58 +0100 (CET)
X-AuditID: c1b4fb3e-ac11ebb000002522-85-45b61e025713 
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	2096A210D4; Tue, 23 Jan 2007 15:38:58 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 15:38:57 +0100
Received: from [147.214.237.61] ([147.214.237.61]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 15:28:53 +0100
Message-ID: <45B61BA5.5020208@levkowetz.com>
Date: Tue, 23 Jan 2007 15:28:53 +0100
From: Henrik Levkowetz 
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Jari Arkko 
References: <45B5E5EC.8030901@piuha.net>
In-Reply-To: <45B5E5EC.8030901@piuha.net>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jan 2007 14:28:53.0519 (UTC)
	FILETIME=[CEC631F0:01C73EFA]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: "Kent Leung \(kleung\)" ,
	Mobile IPv4 Mailing List , vsastry@cisco.com
Subject: [Mip4] Re: AD review of draft-ietf-mip4-message-string-ext-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

Hi Jari,

The most recent version of the draft is -02, produced in
response to my comments to the authors when doing the final
review before requesting publication.  More inline.

On 2007-01-23 11:39 Jari Arkko said the following:
> I have reviewed this specification. I have two issues that
> need a small text change before we can go forward.
> Otherwise the draft looks great.
> 
> Here are my issues:
> 
> 1) The draft uses serviceprovider.com and paymore.com
> as example domain names. You should only use the
> names reserved for example purposes in RFC 2606.
> Say, paymore.example.com or eliminate the name
> entirely.

This is fixed in -02.

> 2) The subtype registry IANA allocation rules have
> not been specified. Please indicate the policy that
> you wish to be used, e.g., IETF Consensus. Alternatively,
> if there are other documents that specify the default
> MIP4 subtype allocation rules, refer to them.

I believe this is also fixed in -02.

I'm forwarding my review notes of -01 to you in a separate
mail, for your information.

> I'm expecting a revised draft.

I expect you'll let us know if this is still needed after
checking -02.


Regards,

	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 Jan 23 09:44:42 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9Mt8-0007tM-7v; Tue, 23 Jan 2007 09:44:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Mt7-0007tH-13
	for mip4@ietf.org; Tue, 23 Jan 2007 09:44:41 -0500
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Mt4-0003sS-O0
	for mip4@ietf.org; Tue, 23 Jan 2007 09:44:41 -0500
Received: from p130.piuha.net (localhost [127.0.0.1])
	by p130.piuha.net (Postfix) with ESMTP id 21DE919876E;
	Tue, 23 Jan 2007 16:44:38 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id CF84E198766;
	Tue, 23 Jan 2007 16:44:37 +0200 (EET)
Message-ID: <45B61F56.10603@piuha.net>
Date: Tue, 23 Jan 2007 16:44:38 +0200
From: Jari Arkko 
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: Henrik Levkowetz 
References: <45B5E5EC.8030901@piuha.net> <45B61BA5.5020208@levkowetz.com>
In-Reply-To: <45B61BA5.5020208@levkowetz.com>
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: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: "Kent Leung \(kleung\)" ,
	Mobile IPv4 Mailing List , vsastry@cisco.com
Subject: [Mip4] Re: AD review of draft-ietf-mip4-message-string-ext-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

Henrik Levkowetz kirjoitti:
> Hi Jari,
>
> The most recent version of the draft is -02, produced in
> response to my comments to the authors when doing the final
> review before requesting publication. 
Ah -- sorry, my local draft database hadn't been synchronized.
Both of my issues have indeed been resolved in the new
revision. Thanks.

I will request IETF Last Call on this document as well, then.

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 Tue Jan 23 10:11:07 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9NIh-0005sj-Hx; Tue, 23 Jan 2007 10:11:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9NIe-0005rM-Qh; Tue, 23 Jan 2007 10:11:04 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H9NIe-0001iE-Kp; Tue, 23 Jan 2007 10:11:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 96B00328E4;
	Tue, 23 Jan 2007 15:11:04 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H9NIe-00054q-GX; Tue, 23 Jan 2007 10:11:04 -0500
X-test-idtracker: no
To: IETF-Announce 
From: The IESG 
Message-Id: 
Date: Tue, 23 Jan 2007 10:11:04 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: mip4@ietf.org
Subject: [Mip4] Last Call: draft-ietf-mip4-message-string-ext (Mobile IPv4 
 Message String Extension) to Proposed Standard 
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 Message String Extension '
    as a Proposed Standard

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-02-06. 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-message-string-ext-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14174&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 Tue Jan 23 10:13:51 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9NLE-0006tX-Fj; Tue, 23 Jan 2007 10:13:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9NLB-0006sz-GO; Tue, 23 Jan 2007 10:13:41 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1H9NLB-0005db-8O; Tue, 23 Jan 2007 10:13:41 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 33D582ACD0;
	Tue, 23 Jan 2007 15:13:11 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H9NKg-000596-Vc; Tue, 23 Jan 2007 10:13:10 -0500
X-test-idtracker: no
To: IETF-Announce 
From: The IESG 
Message-Id: 
Date: Tue, 23 Jan 2007 10:13:10 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: mip4@ietf.org
Subject: [Mip4] Last Call: draft-ietf-mip4-mobike-connectivity (Secure 
 Connectivity and Mobility using Mobile IPv4 and MOBIKE) to BCP 
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:

- 'Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE '
    as a BCP

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-02-06. 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-mobike-connectivity-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14170&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 Tue Jan 23 15:05:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9Rtw-0001dD-Hl; Tue, 23 Jan 2007 15:05:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Rtv-0001cx-3c
	for mip4@ietf.org; Tue, 23 Jan 2007 15:05:51 -0500
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Rts-00077D-JI
	for mip4@ietf.org; Tue, 23 Jan 2007 15:05:51 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l0NK2n60001216; Tue, 23 Jan 2007 22:03:16 +0200
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 22:05:23 +0200
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by
	daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 14:05:44 -0600
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] FMIPv4
Date: Tue, 23 Jan 2007 14:05:45 -0600
Message-ID: <3C33B44F3E969F4D8DE8D578078410C86F8E3B@daebe103.NOE.Nokia.com>
In-Reply-To: <45B4F94B.7080309@motorola.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] FMIPv4
Thread-Index: Acc+TgMwzGRyT+OCSam6l4eu+AtWHQA2yTvw
From: 
To: , 
X-OriginalArrivalTime: 23 Jan 2007 20:05:44.0631 (UTC)
	FILETIME=[DD892470:01C73F29]
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
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 Alex,

thank you for your review.
=20
>BAsically I'm fine with it, here's a few minor editorial.
>
>> Optimizations have been proposed and are being standardized in IEEE=20
>> however.
>
>... for example IEEE 802.11r (Fast Roaming, Fast BSS=20
>Transition) and to a certain extent 802.21; probably worth mentioning.
>

Ok.


>> The design of the protocol is the same as for Mobile IPv6 [2].=20
>> Readers should consult [2] for details, and here we provide=20
>a summary.
>[...]
>> [2] R. Koodli (Editor).  Fast Handovers for Mobile IPv6 (work in=20
>> progress).  Internet Draft, Internet Engineering Task Force.
>> draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.
>
>Editing nit.  The draft referred as [2] no longer exists I=20
>believe.  I think there may be plans in the mipshop WG to take=20
>RFC4068 on a Stds Track.  So maybe RFC4068 and RFC3775 should=20
>be referred for the moment, or any other update more up to=20
>date.  This '[2]' is cited several times in the draft.
>

That should be RFC 4068. Thanks for catching it!


>> 5.3. Router Solicitation for Proxy Advertisement (RtSolPr)
>
>Is this an RS carried as ICMP (RFC1256) or as ICMPv6. =20
>Encoding is different.  Remark that existing implementations=20
>of ICMPv4 RS could be re-used for minimal modifications, or=20
>otherwise ICMPv6 could be re-used.=20
>  It's a choice.  But in a FMIPv4 deployment one wouldn't=20
>assume availability of ICMPv6... or maybe yes (?).  Also it's=20
>strange to use Checksum field as computed from rfc1256 but the=20
>format from ICMPv6.
>
>Same for Proxy Router Advertisement.
>

It _should_ be ICMPv4, with the allowance for ICMPv6 I guess.=20
Will revise.

Regards,

-Rajeev



>Alex
>
>
>
>--
>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 Jan 25 16:33:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACDS-0007XR-UY; Thu, 25 Jan 2007 16:33:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OOW-00080w-Aw
	for mip4@ietf.org; Tue, 23 Jan 2007 11:21:12 -0500
Received: from grid.lrg.ufsc.br ([150.162.63.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ONv-0000YE-Gi
	for mip4@ietf.org; Tue, 23 Jan 2007 11:20:40 -0500
Received: from localhost.grid.lrg.ufsc.br (localhost [127.0.0.1])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id C770312A8B0;
	Tue, 23 Jan 2007 12:59:47 -0200 (BRST)
X-Original-To: mycolleagues@grid.lrg.ufsc.br
Delivered-To: mycolleagues@grid.lrg.ufsc.br
Received: from courriel.site.uottawa.ca (courriel.site.uottawa.ca
	[137.122.89.224])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id 41D7A12A35A
	for ;
	Sun, 21 Jan 2007 17:26:05 -0200 (BRST)
Received: from www.site.uottawa.ca (mail.site.uottawa.ca [137.122.89.142])
	by courriel.site.uottawa.ca (8.13.4/8.13.4) with ESMTP id
	l0LKETVT020432 for ;
	Sun, 21 Jan 2007 15:14:29 -0500 (EST)
	(envelope-from boukerch@site.uottawa.ca)
Received: from 127.0.0.1 (SquirrelMail authenticated user boukerch);
	by www.site.uottawa.ca with HTTP;
	Sun, 21 Jan 2007 15:14:28 -0500 (EST)
Message-ID: <4416.127.0.0.1.1169410468.squirrel@127.0.0.1>
Date: Sun, 21 Jan 2007 15:14:28 -0500 (EST)
From: boukerch@site.uottawa.ca
To: mycolleagues@grid.lrg.ufsc.br
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
X-Mailman-Approved-At: Tue, 23 Jan 2007 12:38:16 -0200
X-BeenThere: mycolleagues@grid.lrg.ufsc.br
X-Mailman-Version: 2.1.8
Precedence: list
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
X-Mailman-Approved-At: Thu, 25 Jan 2007 16:33:05 -0500
Cc: 
Subject: [Mip4] [mycolleagues] RE; CFP IEEE LCN 2007
X-BeenThere: mip4@ietf.org
List-Id: Mobility for IPv4 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: mip4-bounces@ietf.org

=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=3D=3D=3D=3D=3D
Apologies if you receive multiple copies of this Call for Papers
=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=3D=3D=3D=3D=3D
IMPORTANT DATES:
Paper registration deadline: April 2, 2007
Paper submission deadline:   April 9, 2007
=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=3D=3D=3D=3D=3D
                           LCN 2007
               The 32nd Annual IEEE Conference on
                 Local Computer Networks (LCN)
                     http://www.ieeelcn.org

             Sponsored by the IEEE Computer Society (pending)
                 with support from the Telecommunications
                      Software & Systems Group (TSSG)/
                     Waterford Institute of Technology

                          Dublin, Ireland
                        October 15-18, 2007

                         CALL FOR PAPERS

LCN invites you to Europe for the second time in its history! The IEEE LCN
conference is the premier conference on the leading edge of practical
computer
networking. LCN is a highly interactive conference that enables an effective
interchange of results and ideas among researchers, users, and product
developers.
During 32 years of this conference, major developments from high-speed local
networks to the global Internet to specialized sensor networks have been
reported at this conference.  We encourage you to submit original papers
describing research results or practical solutions in leading edge topics.
Paper topics include, but are not limited to:

Ad hoc and sensor networks       Adaptive applications
Embedded networks                Authentication, authorization, accounting
High-speed access networks       Congestion and flow control
Home and SOHO networks           Context-aware network services
IPv6 networks                    IPv6 deployment and migration
Local area networks              Mobility management
Optical networks                 Multimedia and real-time communication
Overlay networks                 Network management
Peer-to-peer networks            Network reliability and security
Personal and wearable networks   Network traffic characterization
Storage area networks            Performance evaluation/engineering
Ubiquitous networking            Performance measurement and tuning
Wireless networks                Quality-of-Service provisioning

Authors are invited to submit full or short papers for presentation at the
conference. Full 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 conference. Short papers are an opportunity to present
preliminary or interim results and are limited to 2 camera-ready pages in
length. Short papers will be presented in a poster format and are published
in the proceedings. All papers must include title, complete contact
information for all authors, abstract, and keywords on the cover page.

PAPER SUBMISSION:
Papers must be submitted electronically in PDF. All submission
instructions will
be posted on the conference website.  Please direct your questions to the
program co-chairs, Matthias Frank   and Ehab Elmallah
.

IMPORTANT DATES:
Paper registration deadline: April 2, 2007
Paper submission deadline:   April 9, 2007
Notification of acceptance:  June 25, 2007
Camera-ready paper due:      July 23, 2007
Author registration by:      July 23, 2007

WORKSHOPS:
A number of workshops will be co-located with the conference. Workshop pape=
rs
will be published in the LCN proceedings. Information on workshops,
submission
deadlines and all other details will be posted on the conference web site.

General Chair:
- Ken Christensen, University of South Florida
Program Chair:
- Matthias Frank, University of Bonn
Program Co-Chair:
- Ehab Elmallah, University of Alberta
Finance Chair:
- Frank H=FCbner, AT&T Labs
Local Arrangements Chair:
- Tom Pfeifer, TSSG, Waterford IT
Workshops Chair:
- Chun Tung Chou, University of New South Wales
Publication Chair:
- Mohamed Younis, University of  Maryland, BC
Publicity Chair:
- Azzedine Boukerche, University of Ottawa
Corporate Relations Chair:
- Declan O=92Sullivan, Trinity College Dublin
International Advisors:
- Burkhard Stiller, University of Z=FCrich and ETH Z=FCrich
- Hossam Hassanein, Queen=92s University, Canada
- Sanjay Jha, University of New South Wales
Webmaster:
-Gary Kessler, Champlain College

Standing Committee:
- Joe Bumblis, BAE Systems
- Hossam Hassanein, Queen=92s University, Canada
- Gary Kessler, Champlain College
- Peter Martini, University of Bonn
- Burkhard Stiller, University of Z=FCrich and ETH Z=FCrich
- Tim Strayer, BBN


_______________________________________________
mycolleagues mailing list
mycolleagues@grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues

-- 
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 Jan 25 16:33:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACDz-0007m0-9l; Thu, 25 Jan 2007 16:33:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9U6K-0004pN-4i
	for mip4@ietf.org; Tue, 23 Jan 2007 17:26:48 -0500
Received: from [140.98.194.93] (helo=conan.comsoc.org)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9U6I-0008Cx-QP
	for mip4@ietf.org; Tue, 23 Jan 2007 17:26:48 -0500
Received: from conan.comsoc.org (conan.comsoc.org [140.98.194.93]) by
	conan.comsoc.org (GMS Comm 12.01.3461/NY9491.00.1c184a6e) with ESMTP id
	za3661248 for wcnccfp@comsocconferences.org;
	Mon, 22 Jan 2007 13:03:26 -0500
Received: from conan.comsoc.org (conan.comsoc.org [140.98.194.93]) by
	conan.comsoc.org (GMS Comm 12.01.3461/NY9491.00.1c184a6e) with ESMTP id
	za3661248 for wcnccfp@comsocconferences.org;
	Mon, 22 Jan 2007 13:02:29 -0500
Received: from [140.98.210.253] by conan.comsoc.org (GMS
	12.01.3461/NY9491.00.1c184a6e) with ESMTP id pnxeadaa for
	wcnccfp@comsocconferences.org; Mon, 22 Jan 2007 13:00:15 -0500
From: ComSocConferences@comsoc.org
To: wcnccfp@comsocconferences.org
Date: Mon, 22 Jan 2007 12:17:32 -0500
MIME-Version: 1.0
Message-ID: <1169468244664788eae43a08eb3ee71f830142f982@comsoc.org>
X-Originating-IP: [140.98.210.253]
X-ListVersion: 12
X-ListMember: mip4@ietf.org [wcnccfp@comsocconferences.org]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
X-Mailman-Approved-At: Thu, 25 Jan 2007 16:33:37 -0500
Cc: 
Subject: [Mip4] WCNC 2007:  Registration Deadline!
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="===============0632368805=="
Errors-To: mip4-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0632368805==
Content-Type: multipart/alternative;
	boundary="--=_NextPart_19E2F78B_23768DDF_01C9F258.D84EF1C0"

This is a multi-part message in MIME format.

----=_NextPart_19E2F78B_23768DDF_01C9F258.D84EF1C0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit

EARLY REGISTRATION DEADLINE:    27 JANUARY 2007 

IEEE Wireless Communications & Networking Conference (WCNC 2007)
11 – 15 March 2007 /Hong Kong / http://www.ieee-wcnc.org 

Make sure you are a part of the first WCNC conference outside North America – held in Asia’s world city, Hong Kong, China, The WCNC is the one of the world’s foremost international technical conference for engineers and researchers at the forefront of development and deployment of wireless technologies. 

Highlights include:    Tutorials, Technical Papers, Panels, Keynote Speakers, Poster Sessions and plenty of networking opportunities.

Don’t forget to make your hotel reservations!

ORGANIZATION

General Chairs                                             Technical Program Chair
Khaled B. Letaief, Chih-Lin I                       Ross D. Murch

For more WCNC 2007 details & updates, visit:  http://www.ieee-wcnc.org

 




To unsubscribe from this IEEE Communications Society Meetings and
Conferences mailing list send a blank email message
to WCNCcfp-remove@comsocconferences.org.

You can also request removal by mail.  Please send a note with your email address
and the list name (WCNCcfp@comsocconferences.org) to

ComSoc List Removal - IT
3 Park Avenue, 17th Floor
New York, NY 10016 USA

----=_NextPart_19E2F78B_23768DDF_01C9F258.D84EF1C0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit












 


EARLY
REGISTRATION DEADLINE:
   27
JANUARY 2007 


IEEE
Wireless Communications & Networking Conference (WCNC
2007)
11 – 15 March 2007 /Hong Kong /
http://www.ieee-wcnc.org 


Make sure you are a part of the
first WCNC conference outside North America – held in Asia’s world city,
Hong Kong,
China, The WCNC
is the one of the world’s foremost international technical conference for
engineers and researchers at the forefront of development and deployment of
wireless technologies. 


Highlights
include:    Tutorials, Technical Papers, Panels, Keynote
Speakers, Poster Sessions and plenty of networking
opportunities.


Don’t
forget to make your hotel reservations!


ORGANIZATION


General Chairs
               
               
            Technical Program
Chair
Khaled B. Letaief, Chih-Lin
I                       Ross
D. Murch


For more WCNC
2007 details & updates, visit:  http://www.ieee-wcnc.org


 












To unsubscribe from this IEEE Communications Society Meetings and


Conferences mailing list send a blank email message


to WCNCcfp-remove@comsocconferences.org.





You can also request removal by mail.  Please send a note with your email address


and the list name (WCNCcfp@comsocconferences.org) to





ComSoc List Removal - IT


3 Park Avenue, 17th Floor


New York, NY 10016 USA


----=_NextPart_19E2F78B_23768DDF_01C9F258.D84EF1C0--



--===============0632368805==
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/

--===============0632368805==--





From mip4-bounces@ietf.org Thu Jan 25 16:34:06 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACEQ-0007q8-6E; Thu, 25 Jan 2007 16:34:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Nzt-0003VT-G4
	for mip4@ietf.org; Tue, 23 Jan 2007 10:55:45 -0500
Received: from grid.lrg.ufsc.br ([150.162.63.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Nuj-0001LR-3y
	for mip4@ietf.org; Tue, 23 Jan 2007 10:50:26 -0500
Received: from localhost.grid.lrg.ufsc.br (localhost [127.0.0.1])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id 4B84D12A7FB;
	Tue, 23 Jan 2007 12:55:34 -0200 (BRST)
X-Original-To: mycolleagues@grid.lrg.ufsc.br
Delivered-To: mycolleagues@grid.lrg.ufsc.br
Received: from techie.cs.gsu.edu (techie.cs.gsu.edu [131.96.49.104])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id 4512E12C054
	for ;
	Sun, 21 Jan 2007 12:34:24 -0200 (BRST)
Received: from techie.cs.gsu.edu (techie [127.0.0.1] (may be forged))
	by techie.cs.gsu.edu (8.13.1/8.13.1) with ESMTP id l0LFMW6m018795;
	Sun, 21 Jan 2007 10:22:32 -0500
Received: from localhost (cscyip@localhost)
	by techie.cs.gsu.edu (8.13.1/8.13.1/Submit) with ESMTP id
	l0LFMTIe018792; Sun, 21 Jan 2007 10:22:32 -0500
Date: Sun, 21 Jan 2007 10:22:29 -0500 (EST)
From: Yi Pan 
To: mycolleagues@grid.lrg.ufsc.br
Message-ID: 
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 23 Jan 2007 12:38:16 -0200
X-BeenThere: mycolleagues@grid.lrg.ufsc.br
X-Mailman-Version: 2.1.8
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
X-Mailman-Approved-At: Thu, 25 Jan 2007 16:34:04 -0500
Cc: 
Subject: [Mip4] [mycolleagues] Call for book proposals in Wireless
	COmmunication
X-BeenThere: mip4@ietf.org
List-Id: Mobility for IPv4 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: mip4-bounces@ietf.org



Dear Colleagues:

Prof. Sherman Shen of University of Waterloo and I have been appointed by
John Wiley to serve as Series Editors for the new Wiley Book Series on 
Wireless Communication and Mobile Computing. If you are interested in 
editing or authoring a book related to any area in Wireless 
Communication and Mobile Computing, please contact us. Right now, we are 
particularly interested in projects for authored books.

Many thanks

> --------------------------------------------------------------------------
> Dr. Yi Pan
> Chair and Professor
> Department of Computer Science
> Georgia State University
> 34 Peachtree Street, Suite 1450
> Atlanta,  GA  30302-4110, USA
> email: pan@cs.gsu.edu
> Phone: (404) 651-0649
> Fax: (404) 463-9912
> http://www.cs.gsu.edu/pan
> --------------------------------------------------------------------------
_______________________________________________
mycolleagues mailing list
mycolleagues@grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues

-- 
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 Jan 25 16:35:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACFM-0000Sz-Ln; Thu, 25 Jan 2007 16:35:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zvW-0002Yx-BT
	for mip4@ietf.org; Thu, 25 Jan 2007 03:25:46 -0500
Received: from grid.lrg.ufsc.br ([150.162.63.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zql-0001OI-Py
	for mip4@ietf.org; Thu, 25 Jan 2007 03:20:55 -0500
Received: from localhost.grid.lrg.ufsc.br (localhost [127.0.0.1])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id BD3EB12C6F3;
	Thu, 25 Jan 2007 02:26:34 -0200 (BRST)
X-Original-To: mycolleagues@grid.lrg.ufsc.br
Delivered-To: mycolleagues@grid.lrg.ufsc.br
Received: from ufc.univ-fcomte.fr (ufc.univ-fcomte.fr [194.57.91.200])
	by grid.lrg.ufsc.br (Postfix) with ESMTP id C31D212915F
	for ;
	Mon, 22 Jan 2007 05:27:45 -0200 (BRST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ufc.univ-fcomte.fr (Postfix) with ESMTP id 7E78B9E8AC2;
	Mon, 22 Jan 2007 09:16:09 +0100 (CET)
Received: from ufc.univ-fcomte.fr ([127.0.0.1])
	by localhost (ufc.univ-fcomte.fr [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 23708-09; Mon, 22 Jan 2007 09:16:04 +0100 (CET)
Received: from ufc204.univ-fcomte.fr (ufc204.univ-fcomte.fr [194.57.91.204])
	by ufc.univ-fcomte.fr (Postfix) with ESMTP id D3F1F9E886C;
	Mon, 22 Jan 2007 09:16:04 +0100 (CET)
Received: from [194.57.88.251] (localhost.localdomain [127.0.0.1])
	by ufc204.univ-fcomte.fr (Postfix) with ESMTP id C14853C287B;
	Mon, 22 Jan 2007 09:16:04 +0100 (CET)
Message-ID: <45B472C8.8080006@univ-fcomte.fr>
Date: Mon, 22 Jan 2007 09:16:08 +0100
From: lapayre 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Admin 
References: 
In-Reply-To: 
X-Virus-Scanned: amavisd-new at univ-fcomte.fr
X-Mailman-Approved-At: Thu, 25 Jan 2007 01:44:44 -0200
X-BeenThere: mycolleagues@grid.lrg.ufsc.br
X-Mailman-Version: 2.1.8
Precedence: list
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.5 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
X-Mailman-Approved-At: Thu, 25 Jan 2007 16:35:02 -0500
Cc: mycolleagues@grid.lrg.ufsc.br
Subject: [Mip4] [mycolleagues] DFMA07 : Deadline extended to Feb 2nd
X-BeenThere: mip4@ietf.org
List-Id: Mobility for IPv4 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: mip4-bounces@ietf.org

Apologies if you received multiple copies of this announcement.

                                CALL FOR PAPERS

                          The Third International Workshop on
                Distributed Frameworks for Multimedia Applications
                                DFMA'07

                                     July 4-6, 2007
                                     PARIS FRANCE
                                     http://lifc.univ-fcomte.fr/dfma07


                          Submission Deadline: January 20, 2007

Technical co-sponsorship IEEE France Section

In cooperation with
National Advanced IPv6 Center, Malaysia
Universiti Sains Malaysia
Ecole Nationale Sup=E9rieure des T=E9l=E9coms (ENST)
Groupement des Ecoles de T=E9l=E9coms (GET, pending of approval)
Universit=E9 de Franche-Comt=E9, France

GENERAL INFORMATION
The series of annual Franco - Malaysia Conference on Multimedia namely
DFMA (Distributed Frame for Multimedia Applications) has already
initiated in 2005 by the University Franche-Comt=E9, and the University of
Science Malaysia (USM)
to provide a forum for researchers in computer science from both
countries and to promote interaction with
researchers from other regions as well. DFMA is an international
conference born from the collaboration
between Network Research Group from University Sains Malaysia and the
Laboratoire d'Informatique,
University of Franche-Comt=E9, France. DFMA is technically co-sponsored by
IEEE France Section.
The first conference was held in Besan=E7on, France, in February 2005, the
second one was held in Penang,
Malaysia in May 2006 and the third will be held in Paris, France on 4-6
July, 2007. In order to encourage
closer interaction between academic and industrial networking research
communities, we solicit both academic
research papers and industrial contributions. The aim of this conference
is to cluster manufacturers and researchers.

TOPICS OF SPECIAL INTEREST
Papers are invited on all aspects of Multimedia, but particularly sought
are those addressing aspects of the theme.
An indicative list of such aspects includes:
- Active Networks for Multimedia
- Adaptation, and Malleability
- Agents for Distributed Systems
- Distributed and Parallel Systems
- Distributed Systems Modeling
- Distributed Algorithms and Protocols
- Distributed IHM for Multimedia Applications
- High-speed Communications
- Home Network
- Image, File and Audio-Video Compression, Coding and Encryption
- Intelligent Multimedia Signal Processing
- Manet for Multimedia
- Mobile and Ubiquitous Computing
- Multimedia Communications and Systems
- Multimedia Database and Retrieval
- Multimedia Industrial Applications
- Multimedia using Web Services
- Network Quality of Service
- Ontology for Multimedia
- Security in Multimedia Network
- Virtual Collaborative Environments
- Virtual Reality
- Wireless Network for Multimedia

INSTRUCTION FOR AUTHORS
The proceedings will be published by IEEE Computer Society.
Only .PDF or .DOC files will be accepted for paper submission. All
received papers will be acknowledged.
Papers must use single-column per page, double spacing and Times New
Roman style characters with 12-point font size.
The paper size should be so as not to exceed 8 pages when it is
converted to the camera-ready format
(two columns, single spacing, Times New Roman style characters, 10-point
font size) after acceptance.
All the manuscripts must be written in English. The top of the first
page of each paper should include the title of the paper,
authors' name, position, address, telephone and fax numbers, e-mail of
the author responsible for correspondence
and a list of four keywords. The deadline for submission of full paper
is January 20, 2007 with notification
of acceptance by March 10th, 2007. Submission of camera-ready paper is
by March 30th, 2007.
Authors of accepted papers will be invited to submit full-length
manuscripts for inclusion in the
IEEE proceedings with ISBN.

All paper submissions will be handled electronically, only. Please use
the Submission Form at the DFMA'07
homepage to submit your paper(s).
Submission: http://www.edas.info/newPaper.php?c=3D5242&submit=3D0& 

For more information please contact: dfma07@lifc.univ-fcomte.fr 
Check our Web page at http://lifc.univ-fcomte.fr/dfma07 for the latest
information concerning the conference.
Best papers will be forwarded for consideration in a special issue of a
journal.

TUTORIALS

Tutorial proposals must clearly identify the intended audience. A
proposal should include, in English,
a description and outline of the proposed contents, names, affiliations,
and biographical sketches
of the speaker(s). The intended length of the tutorial (3 or 6 hours)
should also be indicated.
Submit the proposals (preferably by email) directly to the Program
Co-Chair (dfma07@lifc.univ-fcomte.fr )
by January 1st 2007.




ORGANIZERS AND COMMITTEE

Steering Committee:
Herv=E9 Guyennet Professor, University of Franche-Comt=E9, Besan=E7on, Fran=
ce
J.-Christophe Lapayre Professor, University of Franche-Comt=E9, Besan=E7on,
France
Sureswaran Ramadass Assoc. Professor, Nav6, USM, Malaysia
Pascal Lorenz Professor, University of Haute-Alsace / IEEE, France


Program Co-Chairs:
Jean-Claude Moissinac(Head of Organization) Assist. Professor, ENST, France
Rahmat Budiarto Assist. Professor, NAv6, USM, Malaysia
Eric Garcia Assist. Professor, Univ.Franche-Comt=E9, Besan=E7on, France
Christophe Lang Assist. Professor, Univ.Franche-Comt=E9, Besan=E7on, France

Program Committee:
Fran=E7oise Andre IRISA, Rennes, France
Nadia Baaziz DII, University of Qu=E9bec en Outaouais, Canada
Markus Buchhorn AARNET, Canberra, Australia
Rahmat Budiarto Nav6, USM, Malaysia
Rajkumar Buyya DCSSE, Melbourne, Australia
Christophe Cerin LIPN, university of Paris XIII, France
Huah-Yong Chan GC, USM, Malaysia
Andrea Clematis IMATI, Genova, Italia
Bertrand David ECL, Lyon, France
Isabelle Demeure ENST, Paris, France
Eric Garcia University of Franche-Comt=E9, Besan=E7on, France
Shigeki Goto Waseda University, Tokyo, Japan
Uma Gunasilan School of Computer Science, Middlesex University London, UK
Herv=E9 Guyennet University of Franche-Comt=E9, Besan=E7on, France
Rosnah Idrus Computer Sciences, USM, Malaysia
Narayanan Kulathuramaiyer UNIMAS, Malaysia
Christophe Lang University of Franche-Comt=E9, Besan=E7on, France
J.-Christophe Lapayre University of Franche-Comt=E9, Besan=E7on, France
Van Le Keane Federal System inc., USA
Laurent Lefevre INRIA, RESO, Lyon, France
Pascal Lorenz University of Haute-Alsace / IEEE, France
Yan Ma BUPT, PR China
Borhanuddin Mohd Ali UPM, Serdang, Malaysia
Alejandro Pe=F1a National Polytechnic Institute, Mexico
Sureswaran Ramadass NAv6, USM, Malaysia
Seow San Temasek Polytechnic, Singapore
Ichiro Satoh National Institute of Informatics, Tokyo, Japan
Isaac Scherson University of California, Irvine, USA
Andr=E9 Schaff ESIAL, Nancy, France
Shahidah Sulaiman Computer Sciences, USM, Malaysia
Jean-Philippe Thiran EPFL, Lausanne, Switzerland
St=E9phane Vialle SUPELEC, Metz, France
Denis Villorente Advanced Sc. and Tech. Inst. (ASTI), Quezon City,
Philippines
Tat Chee Wan USM, Penang, Malaysia
Lawrence Wong Institute for Infocomm Research, Singapore
Zaharin Yusoff USM, Penang, Malaysia

IMPORTANT DATES
Submission Deadline: February 2nd 2007
Authors Notification: March 10th 2007
Final Manuscript Due: March 30th 2007

CONFERENCE VENUE

ENST Ecole Nationale Sup=E9rieure des T=E9l=E9coms de Paris
46, rue Barrault
75013 PARIS

Banquet:
DFMA's banquet will be organized for the Thursday diner with cultural show

Social events:
On Wednesday, local organizing committee will arrange a trip to Paris...












_______________________________________________
mycolleagues mailing list
mycolleagues@grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues

-- 
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 Jan 25 17:18:54 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACve-0005dZ-Kg; Thu, 25 Jan 2007 17:18:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACvb-0005aC-GQ; Thu, 25 Jan 2007 17:18:43 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HACva-0003WK-8x; Thu, 25 Jan 2007 17:18:43 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 39D3A32A10;
	Thu, 25 Jan 2007 22:18:42 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HACva-0003Nl-4I; Thu, 25 Jan 2007 17:18:42 -0500
X-test-idtracker: no
From: The IESG 
To: IETF-Announce 
Message-Id: 
Date: Thu, 25 Jan 2007 17:18:42 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: mip4 chair ,
	Internet Architecture Board ,
	mip4 mailing list , RFC Editor 
Subject: [Mip4] Document Action: 'Mobile IPv4 Regional Registration' 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

The IESG has approved the following document:

- 'Mobile IPv4 Regional Registration '
    as an Experimental RFC

This document is the product of the Mobility for IPv4 Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-04.txt

Technical Summary
 
  The document describes a mechanism for reducing the number of round-trip

  registrations to a Mobile IP Home Agent with the introduction of a new
  network node, the Gateway Foreign Agent.  Mobility within the domain of
  the Gateway Foreign Agent can be handled by local signaling.
 
Working Group Summary
 
  The draft was originally produced and reviewed in the old Mobile IP
  working group but is now a product of the mip4 working group.

Protocol Quality

  The document was reviewed for protocol quality by Pete McCann,
  co-chair of MIP4 WG. The specification has also been reviewed 
  for the IESG by Margaret Wasserman and Jari Arkko.

Note to RFC Editor
 
  Please insert the following new paragraph at the end
  of the security considerations section:

    "A co-operating malicious MN-HA pair can trick the GFA into 
    setting up state for an incorrect MN home address. This would
    result in redirection of data of the node that actually owns
    that IP address to the malicious MN. Given that the forwarding
    happens based on the home address at the GFA, such an attack 
    is scoped to the prefix of the HA, not that of the GFA. This 
    type of attack, or its consequences, is not considered in 
    this document."


-- 
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 Jan 30 01:51:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBmp7-0005Yi-UW; Tue, 30 Jan 2007 01:50:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmp6-0005RX-Bn
	for mip4@ietf.org; Tue, 30 Jan 2007 01:50:32 -0500
Received: from airmail.airvananet.com ([12.6.244.34]
	helo=airmail.wirelessworld.airvananet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBmp5-000895-4d
	for mip4@ietf.org; Tue, 30 Jan 2007 01:50:32 -0500
Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by
	airmail.wirelessworld.airvananet.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 01:48:47 -0500
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, 30 Jan 2007 12:18:42 +0530
Message-ID: <653F3CF58193744C9DE59C217C072B58B61E10@nilgiri.india.wirelessworld.airvananet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Revocation clarification - 3543
Thread-Index: AcdEOq37LmN0ss6NTteXSPN1EJ3yTg==
From: "Arun SG" 
To: 
X-OriginalArrivalTime: 30 Jan 2007 06:48:47.0936 (UTC)
	FILETIME=[B174C400:01C7443A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Subject: [Mip4] Revocation clarification - 3543
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 am a little unsure of the exact point in the revocation process that
the ACK is to be sent.

Assume a scenario where HA sends a Revocation, does the FA send the ACK
on simply receiving a valid revocation message as para 3.4 seems to
suggest OR after revoking the binding indentified by the revocation as
recommended by 4.2.2.2 ?=20


3.4.  Registration Revocation Acknowledgment Message

   A revocation acknowledgment message is sent by mobility agents or
'direct' co-located mobile nodes to indicate the successful receipt of a
revocation message.
.
.
.

A registration revocation acknowledgment message MUST be sent in
response to a valid and authenticated registration revocation message.



4.2.2.2.  Foreign Agent Responsibilities

.....revocations are only valid for existing registrations, .... .. Upon
locating the binding, the foreign agent MUST revoke it, and MUST respond
with a revocation acknowledgment sent to the source address of the
revocation message.


My two questions hence are:
1. Does ACk signify merely receiving the revocation message, or
successful completion of revocation?
2. What is the correct behaviour when the HA sends a revocation, but the
binding does not exist? Does the FA still send  ACK as having received a
message or keeps quiet, since it has not revoked any binding? =20


Thanks,
Arun



The nice thing about Standards is that there are so many of them to
choose from.
Andrew Tannenbaum




-- 
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 Jan 30 02:09:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBn7T-0004jO-9Z; Tue, 30 Jan 2007 02:09:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBn7R-0004jJ-Ue
	for mip4@ietf.org; Tue, 30 Jan 2007 02:09:29 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBn7O-0005of-Fc
	for mip4@ietf.org; Tue, 30 Jan 2007 02:09:29 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 29 Jan 2007 23:09:25 -0800
X-IronPort-AV: i="4.13,255,1167638400"; 
	d="scan'208"; a="106855633:sNHT53416980"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0U79PDD029938; 
	Mon, 29 Jan 2007 23:09:25 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0U79PUw007142;
	Mon, 29 Jan 2007 23:09:25 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 23:09:25 -0800
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] Revocation clarification - 3543
Date: Mon, 29 Jan 2007 23:09:21 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52034162C8@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <653F3CF58193744C9DE59C217C072B58B61E10@nilgiri.india.wirelessworld.airvananet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] Revocation clarification - 3543
Thread-Index: AcdEOq37LmN0ss6NTteXSPN1EJ3yTgAAikSQ
From: "Kent Leung \(kleung\)" 
To: "Arun SG" , 
X-OriginalArrivalTime: 30 Jan 2007 07:09:25.0208 (UTC)
	FILETIME=[92ED7D80:01C7443D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2363; t=1170140965;
	x=1171004965; 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]=20Revocation=20clarification=20-=203543
	|Sender:=20
	|To:=20=22Arun=20SG=22=20,=20
	|Content-Type:=20text/plain=3B=0A=09charset=3D=22us-ascii=22
	|Content-Transfer-Encoding:=20quoted-printable
	|MIME-Version:=201.0;
	bh=nMYbi9IqSfVyyjMnoJhSeZH9ka0Xc3dM2hmjlnC+zjA=;
	b=qAEOn2L3v2aszdYQXxzsDArgIYzDn2k6RcomaZmpqMDfMQs0xUWhxtX6NTRSz05HoUG1MMeT
	1X+eX2fwyx4U4qdtmZrwY65HmG21CXYzgcPaSP8A3CbpvT6gRm7C9Hnwq+sq6s11Uzzb79XaQJ
	xqp+hnSBpy9xhG0LHcxnXxaFQ=;
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: 6cca30437e2d04f45110f2ff8dc1b1d5
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 Arun.  My comments below in "KL>".=20

-----Original Message-----
From: Arun SG [mailto:arunsg@airvana.com]=20
Sent: Monday, January 29, 2007 10:49 PM
To: mip4@ietf.org
Subject: [Mip4] Revocation clarification - 3543


Hi,
I am a little unsure of the exact point in the revocation process that
the ACK is to be sent.

Assume a scenario where HA sends a Revocation, does the FA send the ACK
on simply receiving a valid revocation message as para 3.4 seems to
suggest OR after revoking the binding indentified by the revocation as
recommended by 4.2.2.2 ?=20


3.4.  Registration Revocation Acknowledgment Message

   A revocation acknowledgment message is sent by mobility agents or
'direct' co-located mobile nodes to indicate the successful receipt of a
revocation message.
.
.
.

A registration revocation acknowledgment message MUST be sent in
response to a valid and authenticated registration revocation message.



4.2.2.2.  Foreign Agent Responsibilities

.....revocations are only valid for existing registrations, .... .. Upon
locating the binding, the foreign agent MUST revoke it, and MUST respond
with a revocation acknowledgment sent to the source address of the
revocation message.


My two questions hence are:
1. Does ACk signify merely receiving the revocation message, or
successful completion of revocation?

KL> ACK is sent in response to a valid and authentication registration
revocation message.  BTW, why would FA not be able to revoke the
binding?

2. What is the correct behaviour when the HA sends a revocation, but the
binding does not exist? Does the FA still send  ACK as having received a
message or keeps quiet, since it has not revoked any binding? =20

KL> Yes, FA should still send ACK.  Since the point of the revocation is
to clean up resources such as the binding entry, it makes sense that FA
respond to HA that the binding is no longer around (i.e. maybe an
administrator had manually cleared the entry).

Kent


Thanks,
Arun



The nice thing about Standards is that there are so many of them to
choose from.
Andrew Tannenbaum




--
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 Tue Jan 30 02:28:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBnPz-0004KD-Fs; Tue, 30 Jan 2007 02:28:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnPy-0004FG-5S
	for mip4@ietf.org; Tue, 30 Jan 2007 02:28:38 -0500
Received: from airmail.airvananet.com ([12.6.244.34]
	helo=airmail.wirelessworld.airvananet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBnPw-0000XQ-Rf
	for mip4@ietf.org; Tue, 30 Jan 2007 02:28:38 -0500
Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by
	airmail.wirelessworld.airvananet.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 02:26:57 -0500
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] Revocation clarification - 3543
Date: Tue, 30 Jan 2007 12:56:42 +0530
Message-ID: <653F3CF58193744C9DE59C217C072B58B61E27@nilgiri.india.wirelessworld.airvananet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] Revocation clarification - 3543
Thread-Index: AcdEOq37LmN0ss6NTteXSPN1EJ3yTgAAikSQAACMopA=
From: "Arun SG" 
To: "Kent Leung \(kleung\)" ,
	
X-OriginalArrivalTime: 30 Jan 2007 07:26:57.0701 (UTC)
	FILETIME=[06432D50:01C74440]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
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

Thanks for the very prompt response, Kent !

I get the picture, and maybe this then is more an editorial nit-pick.


But reading 4.2.2.2 gives the impression that the ACK is sent upon=20
A) Revocation being valid - and binding existing
B) Revoking itself happening.

If ACK is to be sent regardless of the above conditions, then that para
might re-order the actions taken to emphasise that the ACK is sent on
receiving a valid revocation and then proceeding with identifying the
binding, revoking etc. This will make it more consistent with para 3.4.

Thanks again,
Arun


=20

-----Original Message-----
From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20
Sent: Tuesday, January 30, 2007 12:39 PM
To: Arun SG; mip4@ietf.org
Subject: RE: [Mip4] Revocation clarification - 3543

Hi Arun.  My comments below in "KL>".=20

-----Original Message-----
From: Arun SG [mailto:arunsg@airvana.com]
Sent: Monday, January 29, 2007 10:49 PM
To: mip4@ietf.org
Subject: [Mip4] Revocation clarification - 3543


Hi,
I am a little unsure of the exact point in the revocation process that
the ACK is to be sent.

Assume a scenario where HA sends a Revocation, does the FA send the ACK
on simply receiving a valid revocation message as para 3.4 seems to
suggest OR after revoking the binding indentified by the revocation as
recommended by 4.2.2.2 ?=20


3.4.  Registration Revocation Acknowledgment Message

   A revocation acknowledgment message is sent by mobility agents or
'direct' co-located mobile nodes to indicate the successful receipt of a
revocation message.
.
.
.

A registration revocation acknowledgment message MUST be sent in
response to a valid and authenticated registration revocation message.



4.2.2.2.  Foreign Agent Responsibilities

.....revocations are only valid for existing registrations, .... .. Upon
locating the binding, the foreign agent MUST revoke it, and MUST respond
with a revocation acknowledgment sent to the source address of the
revocation message.


My two questions hence are:
1. Does ACk signify merely receiving the revocation message, or
successful completion of revocation?

KL> ACK is sent in response to a valid and authentication registration
revocation message.  BTW, why would FA not be able to revoke the
binding?

2. What is the correct behaviour when the HA sends a revocation, but the
binding does not exist? Does the FA still send  ACK as having received a
message or keeps quiet, since it has not revoked any binding? =20

KL> Yes, FA should still send ACK.  Since the point of the revocation is
to clean up resources such as the binding entry, it makes sense that FA
respond to HA that the binding is no longer around (i.e. maybe an
administrator had manually cleared the entry).

Kent


Thanks,
Arun



The nice thing about Standards is that there are so many of them to
choose from.
Andrew Tannenbaum




--
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 Jan 31 21:18:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCRWD-0000zF-W4; Wed, 31 Jan 2007 21:17:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HCRWA-0000so-Vw; Wed, 31 Jan 2007 21:17:42 -0500
Received: from nit.isi.edu ([128.9.160.116])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HCRW8-0001TV-Il; Wed, 31 Jan 2007 21:17:42 -0500
Received: from nit.isi.edu (loopback [127.0.0.1])
	by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l112Hepe011862; 
	Wed, 31 Jan 2007 18:17:40 -0800
Received: (from apache@localhost)
	by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l112Hexa011861;
	Wed, 31 Jan 2007 18:17:40 -0800
Date: Wed, 31 Jan 2007 18:17:40 -0800
Message-Id: <200702010217.l112Hexa011861@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
X-Spam-Score: -14.8 (--------------)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: mip4@ietf.org, rfc-editor@rfc-editor.org
Subject: [Mip4] RFC 4721 on Mobile IPv4 Challenge/Response Extensions
	(Revised)
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


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4721

        Title:      Mobile IPv4 Challenge/Response Extensions (Revised) 
        Author:     C. Perkins, P. Calhoun,
                    J. Bharatia
        Status:     Standards Track
        Date:       January 2007
        Mailbox:    charles.perkins@nokia.com, 
                    pcalhoun@cisco.com, 
                    jayshree@nortel.com
        Pages:      26
        Characters: 60386
        

        I-D Tag:    draft-ietf-mip4-rfc3012bis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4721.txt

Mobile IP, as originally specified, defines an authentication
extension (the Mobile-Foreign Authentication extension) by which a
mobile node can authenticate itself to a foreign agent.
Unfortunately, that extension does not provide the foreign agent any
direct guarantee that the protocol is protected from replays and
does not allow for the use of existing techniques (such as Challenge
Handshake Authentication Protocol (CHAP)) for
authenticating portable computer devices.

In this specification, we define extensions for the Mobile IP Agent
Advertisements and the Registration Request that allow a foreign
agent to use a challenge/response mechanism to authenticate the
mobile node.

Furthermore, this document updates RFC 3344 by including a new
authentication extension called the Mobile-Authentication,
Authorization, and Accounting (AAA) Authentication
extension.  This new extension is provided so that a mobile node can
supply credentials for authorization, using commonly available AAA
infrastructure elements.  This authorization-enabling extension MAY
co-exist in the same Registration Request with authentication
extensions defined for Mobile IP Registration by RFC 3344.  This
document obsoletes RFC 3012.  [STANDARDS TRACK]

This document is a product of the Mobility for IPv4
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...



-- 
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/