From mif-bounces@ietf.org Mon Jan 5 06:41:12 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C083A6853; Mon, 5 Jan 2009 06:41:12 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BF13A657C; Mon, 5 Jan 2009 06:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNwVqrhiprPQ; Mon, 5 Jan 2009 06:36:36 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 00A913A6359; Mon, 5 Jan 2009 06:36:35 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so3952923wag.5 for ; Mon, 05 Jan 2009 06:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=Hn/eFlkDaR+vBXcd2j2ivoqofvr1tAzubICqM1ylU20=; b=WmCqMaEMgE30LVwhadKg78G/yWyS6C8aCkhTB/Tn8JvDWRxrqcDWY0zwlJYioOG4OO /cicVh+iLaWZbi3qK5fjVrmiRUl8nxpOfVTTT/xASz9inutyImVrwq3KH7liFL8VOcZW x3BLea4mZzLD5hm8FbZyzCXEyqW3UZB6MT3TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=q0EKRuI6jXR/o7Di49FCve4kYaAeisO4j2fyiaXQV6uasttJq8sRFo3eW02BKf9qnn x0Ujn0kpbpnU/xMidjslafBLmEQg2eHRKDbhavvRJRqBKylxgr3WjAzjAKYFJ9B7rMZR rnyd9m+kvdlvncKj/TinW9Pjq8S4DsZLJvcj0= Received: by 10.114.79.18 with SMTP id c18mr13829113wab.215.1231166182809; Mon, 05 Jan 2009 06:36:22 -0800 (PST) Received: by 10.115.58.3 with HTTP; Mon, 5 Jan 2009 06:36:22 -0800 (PST) Message-ID: <1d38a3350901050636recdc184h8e645a467e5811a8@mail.gmail.com> Date: Mon, 5 Jan 2009 22:36:22 +0800 From: "Hui Deng" To: ietf@ietf.org, mif@ietf.org MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 05 Jan 2009 06:41:11 -0800 Subject: [mif] The Internet architecture - pointer to MIF (Multiple Interfaces) discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1485138958==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1485138958== Content-Type: multipart/alternative; boundary="----=_Part_160676_6465504.1231166182801" ------=_Part_160676_6465504.1231166182801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,all We have setup an mailing list to discuss the host which would like to use multiple interfaces. several issues has been identified based on problem statement. http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt Please be awared that it is different from multihoming (site with multiple interfaces). Please feel free to join our discussion over there, https://www.ietf.org/mailman/listinfo/mif thanks -Hui ------=_Part_160676_6465504.1231166182801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,all
 
We have setup an mailing list to discuss the host which would like to use multiple interfaces.
several issues has been identified based on problem statement.
http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt
 
Please be awared that it is different from multihoming (site with multiple interfaces).
 
Please feel free to join our discussion over there,
https://www.ietf.org/mailman/listinfo/mif
 
thanks
 
-Hui
 
------=_Part_160676_6465504.1231166182801-- --===============1485138958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1485138958==-- From mif-bounces@ietf.org Mon Jan 5 11:24:16 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272BC3A6959; Mon, 5 Jan 2009 11:24:16 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B333A6959 for ; Mon, 5 Jan 2009 11:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT8JIt9O1-yL for ; Mon, 5 Jan 2009 11:24:14 -0800 (PST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 722113A6937 for ; Mon, 5 Jan 2009 11:24:14 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54537) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1LJv3P-00084b-3b (Exim 4.70) for mif@ietf.org (return-path ); Mon, 05 Jan 2009 19:23:59 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LJv3P-0002r8-3I (Exim 4.67) for mif@ietf.org (return-path ); Mon, 05 Jan 2009 19:23:59 +0000 Date: Mon, 5 Jan 2009 19:23:59 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: mif@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Subject: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org The discussion of host-scoped vs interface-scoped configuration is really good - enlightening though not very cheerful. Perhaps another useful example would be a server with an Ethernet interface for the public Internet, and another for a private service network. It seems to me that the draft mostly concentrates on things that ought to work in the current Internet. Do you plan to extend it to include features that should be supported in the future? If so... The problem statement says packet forwarding is out of scope, but in practice it is common for portable devices to act as gateways for each other, e.g. a phone gatewaying 3G to Bluetooth for a laptop, or a laptop acting as a WiFi base station with an Ethernet uplink. At the moment this often relies on NAT, but ideally these ad-hoc edge networks should be able to get proper Internet connectivity. How do the problems relate to mobile IP? Is there any way of using multiple interfaces to get redundancy and fail-over? If so, servers are likely to want to provide services on multiple interfaces for reliability. How does that affect address selection? Can a host use multiple interfaces to get more bandwidth? Obviously yes now by binding the local end of each socket to each interface, but that introduces much more complexity to an area that was previously simple. Is that complexity avoidable? Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHERLY OR NORTHWESTERLY, VEERING EASTERLY 3 OR 4, INCREASING 5 AT TIMES. MODERATE OR ROUGH. RAIN OR SHOWERS, WINTRY IN NORTH. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Mon Jan 5 11:41:32 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD46E3A6A12; Mon, 5 Jan 2009 11:41:32 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8063A6A0B for ; Mon, 5 Jan 2009 11:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHafNjqeHSz9 for ; Mon, 5 Jan 2009 11:41:31 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id BF14F3A6A0A for ; Mon, 5 Jan 2009 11:41:30 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id D4E0929E1546; Mon, 5 Jan 2009 14:41:17 -0500 (EST) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id BB66129E14EE; Mon, 5 Jan 2009 14:41:17 -0500 (EST) Message-ID: <4962625D.1080604@viagenie.ca> Date: Mon, 05 Jan 2009 14:41:17 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Tony Finch References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Tony Finch a =E9crit : > The discussion of host-scoped vs interface-scoped configuration is really > good - enlightening though not very cheerful. Perhaps another useful > example would be a server with an Ethernet interface for the public > Internet, and another for a private service network. > = > It seems to me that the draft mostly concentrates on things that ought to > work in the current Internet. = - another draft is in the works on documenting how current implementations work. Many of them just take the last configuration info (i.e. last dhcp answer just rewrite everything). - it does not work, that is why we are documenting it and see if there is enough interest to make a wg or standard or best practice or ... - my own personal experience is daily with this problem... > Do you plan to extend it to include features > that should be supported in the future? If so... > = > The problem statement says packet forwarding is out of scope, yes. see below. > but in > practice it is common for portable devices to act as gateways for each > other, e.g. a phone gatewaying 3G to Bluetooth for a laptop, or a laptop > acting as a WiFi base station with an Ethernet uplink. At the moment this > often relies on NAT, but ideally these ad-hoc edge networks should be able > to get proper Internet connectivity. The document does not discuss packet forwarding. That does not mean it could not be done. it is out of scope because packet forwarding is _not_ the purpose of mif. a device which has a mif problem may or may not do packet forwarding, it does not really matter. > = > How do the problems relate to mobile IP? = if the mobile IP is implemented as an additional interface, then it does. > Is there any way of using > multiple interfaces to get redundancy and fail-over? in my book, failover is where there are 2 interfaces, and only one is active at a given time. therefore, it does not apply to mif. > If so, servers are > likely to want to provide services on multiple interfaces for reliability. > How does that affect address selection? > = > Can a host use multiple interfaces to get more bandwidth? Obviously yes > now by binding the local end of each socket to each interface, but that > introduces much more complexity to an area that was previously simple. Is > that complexity avoidable? > = > Tony. -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Tue Jan 6 01:00:56 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763B93A68A4; Tue, 6 Jan 2009 01:00:56 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D513A68A4 for ; Tue, 6 Jan 2009 01:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2yxby9QUmPQ for ; Tue, 6 Jan 2009 01:00:54 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 9AB973A686D for ; Tue, 6 Jan 2009 01:00:54 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so4196844wag.5 for ; Tue, 06 Jan 2009 01:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=Q+QKTjY7X6LnlpTKYLlS/cTuEkvaOBgVA1JFx37kn8E=; b=qblVMhQAV2jedJFlPHucoHxckkhRA2PqqtfrZAv0arhT1mxn/YuK6CmtGTTcCXCS6H snb4bxqJ2lYDO/1QN0RvTfNgJvsplAK6SWdSTQhbQXOfsiCoEKJuMyKjVla0nrMSsnyl 1lpPEu4jUSsxO84ponk5FJS9gI0BCgDJfg2Tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=WmI3Rnn/UH6yqUPojfIRiVtCVqLtXCo3TAFeToCHXzSnf+N5hqrXrt2CVGdBTSzrOt 5UDY4htUZIdyZFSPZw7A2BgOzT/ymWT0caIqXyMx5qVfhjNRiScZI/uAdAN+GWPtL4ID lLOeWnvs4FJyz7VomZi2NC1W3v/umyS5646yg= Received: by 10.115.106.18 with SMTP id i18mr14375466wam.213.1231232440567; Tue, 06 Jan 2009 01:00:40 -0800 (PST) Received: by 10.115.58.3 with HTTP; Tue, 6 Jan 2009 01:00:40 -0800 (PST) Message-ID: <1d38a3350901060100w54b14fc2l660211a0d0ab5930@mail.gmail.com> Date: Tue, 6 Jan 2009 17:00:40 +0800 From: "Hui Deng" To: mif@ietf.org MIME-Version: 1.0 Subject: [mif] Mobile IP related X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0790171259==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0790171259== Content-Type: multipart/alternative; boundary="----=_Part_171651_7228394.1231232440557" ------=_Part_171651_7228394.1231232440557 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me to chime in, > How do the problems relate to mobile IP? MEXT wg is working on MONAMI related topic, they are based on multiple CoA flow control mechanism. mif is not related to this direction. Current Mobile network such as 3GPP network, it is assumed that IP address doesn't change under this scenario. many thanks -Hui ------=_Part_171651_7228394.1231232440557 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please allow me to chime in,
 
> How do the problems relate to mobile IP?
MEXT wg is working on MONAMI related topic,
they are based on multiple CoA flow control mechanism.
 
mif is not related to this direction.
Current Mobile network such as 3GPP network, it is assumed that
IP address doesn't change under this scenario.
 
many thanks
 
-Hui
 
 
------=_Part_171651_7228394.1231232440557-- --===============0790171259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0790171259==-- From mif-bounces@ietf.org Wed Jan 7 21:44:16 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43753A6827; Wed, 7 Jan 2009 21:44:16 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873FD28C0E5 for ; Wed, 7 Jan 2009 21:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.742 X-Spam-Level: *** X-Spam-Status: No, score=3.742 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWfMbvj0r6jj for ; Wed, 7 Jan 2009 21:44:15 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 609373A6827 for ; Wed, 7 Jan 2009 21:44:15 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 8 Jan 2009 14:44:04 +0900 X-ReadCheckMessageID: X-ReadCheckName: mif%40ietf.org From: "Hong Yong-Geun" To: Cc: Date: Thu, 8 Jan 2009 14:44:04 +0900 Priority: normal Comment: ??, u-??, thread-index: AclxVB2XkaFm4WryQf+SX/Y9UdMo9wAAAAjr Message-ID: <8ba101c97154$1dbae930$8310fe81@etri.info> Content-Class: urn:content-classes:message X-Mailer: Microsoft CDO for Exchange 2000 MIME-Version: 1.0 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mobility issues and general issues on mif X-OriginalArrivalTime: 08 Jan 2009 05:44:04.0878 (UTC) FILETIME=[1DD9E2E0:01C97154] Subject: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1765030511==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1765030511== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97153.90213750" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97153.90213750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C97153.90213750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4NCjxESVY+DQo8UD48Rk9OVCBzaXplPTI+SGkuIG1pZi4uPEJSPjxCUj5MZXQg bWUgam9pbiB0aGlzIGRpc2N1c3Npb24uPEJSPjxCUj5JdCBpcyB2ZXJ5IGludGVyZXN0aW5nIHRv IHNlZSBtaWYuPEJSPjxCUj5BcyBIdWkgRGVuZyBzYXlzLCBJIHVuZGVyc3RhbmQgdGhhdCBtaWYg aGFzIGRpZmZlcmVudCBhcHByb2FjaDxCUj5mcm9tIG90aGVyIFdHIHN1Y2ggYXMgTUVYVCBhbmQg bW9uYW1pNiBXRywgZXRjLjxCUj48QlI+SW4gTUVYVCwgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1 ZXMgYXJlIHJlbGF0ZWQgdG8gTW9iaWxlIElQLCBORU1PLC4uPEJSPkluIG1pZiwgbXVsdGlwbGUg aW50ZXJmYWNlcyBpc3N1ZXMgYXJlIGRpZmZlcmVudCBmcm9tIHRob3NlIG9mIE1FWFQuPEJSPlNv LCBpbiBtaWYsIGl0IGlzIGJldHRlciB0byBmaW5kIG1vcmUgZ2VuZXJhbCBpc3N1ZXMgd2hpY2gg YXJlIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUC48QlI+PEJSPkkgdGhpbmsgdGhhdCBNLkJsYW5j aGV0J3MgIk11bHRpcGxlIEludGVyZmFjZXMgUHJvYmxlbSBTdGF0ZW1lbnQiIGRyYWZ0IGlzPEJS PmEgZ29vZCBzdGFydGluZyBwb2ludCB0byBkaXNjdXNzIGdlbmVyYWwgaXNzdWVzIG9uIG1pZi48 QlI+PEJSPkkgd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgYW5vdGhlciByZWxhdGVkIGRyYWZ0cyB3 aGljaCBJIHByZXNlbnRlZCBhdCBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nLjxCUj48 QlI+Jm5ic3A7LSBBbmFseXNpcyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIE5v ZGUoZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMCk8QlI+Jm5ic3A7IDxB IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYt bW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAu dHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25n LW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1z dGF0ZW1lbnQtMDAudHh0PC9BPjxCUj48QlI+Jm5ic3A7LSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJm YWNlIGZvciBtdWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUgdXNpbmcgTW9iaWxl IElQdjY8QlI+Jm5ic3A7Jm5ic3A7IChkcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMCk8 QlI+Jm5ic3A7IDxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25n LXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQi IHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2RyYWZ0L2RyYWZ0LWhvbmctdmly dHVhbGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dDwvQT48 QlI+PEJSPjxCUj5JbiB0aGUgc2VjdGlvbiAyLjIgKEdlbmVyYWwgTmV0d29yayBJc3N1ZXMpIGlu IHRoZSBmaXJzdCBkcmFmdCw8QlI+dGhlcmUgYXJlIGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgZHVl IHRvIG11bHRpcGxlIGludGVyZmFjZXMuPEJSPjxCUj5JbmNsdWRpbmcgdGhlc2UgZHJhZnRzLCBJ IGhvcGUgdG8gZW5jb3VyYWdlIHRoaXMgZGlzY3Vzc2lvbjxCUj48QlI+WW9uZy1HZXVuLjxCUj48 L0ZPTlQ+PC9QPjwvRElWPjwvRElWPjwvRElWPjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lk dGg9MCBoZWlnaHQ9MCBzcmM9Imh0dHA6Ly91bWFpbC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRD aGVjay5hc3B4P2VtYWlsPW1pZkBpZXRmLm9yZyZuYW1lPW1pZiU0MGlldGYub3JnJmZyb21lbWFp bD15Z2hvbmdAZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDYWViYWU5OTMtODFiMy00NTA4LWJiOGIt MTU3NjA3NjgwNWUyQGV0cmkucmUua3IlM0UiPg== ------_=_NextPart_001_01C97153.90213750-- --===============1765030511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1765030511==-- From mif-bounces@ietf.org Thu Jan 8 06:47:37 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCFC3A6942; Thu, 8 Jan 2009 06:47:37 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0702C3A6977 for ; Thu, 8 Jan 2009 06:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTvJBidaXrD1 for ; Thu, 8 Jan 2009 06:47:35 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2FA4F3A690B for ; Thu, 8 Jan 2009 06:47:35 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n08EkLBP005028; Thu, 8 Jan 2009 08:47:16 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 16:45:32 +0200 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 16:45:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 16:45:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet-mif-problem-statement-00.txt Thread-Index: Aclvay5TWt+4KP4xQ1W4TH36+aAAWQCDirIQ References: From: "teemu.savolainen@nokia.com" To: , X-OriginalArrivalTime: 08 Jan 2009 14:45:32.0296 (UTC) FILETIME=[C1DC7880:01C9719F] X-Nokia-AV: Clean Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On >Behalf Of ext Tony Finch >Sent: 05 January, 2009 21:24 >To: mif@ietf.org >Subject: [mif] draft-blanchet-mif-problem-statement-00.txt > >Can a host use multiple interfaces to get more bandwidth? >Obviously yes now by binding the local end of each socket to >each interface, but that introduces much more complexity to an >area that was previously simple. Is that complexity avoidable? This is probably not in mif scope. There's some interesting work ongoing on having multipath support on transpor layer (multipath TCP): http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf Maybe mif could help to select the network interfaces that are usable for this kind of use (e.g. if host has two network interfaces for public Internet and one for private Intranet). Also as was mentioned already Mext is working on MONAMI and multiple CoA, but additionally similar approaches might be possible on netlmm-scope. From mif point of view application running in a host utilizing host based IP mobility there is one network interface with CoA and one network interface with HoA to choose from. On network based mobility case there's just the (virtual) network interface with "HoA", and that network interface hides from mif the possible usage of parallel physical network interfaces. Best regards, Teemu _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 8 07:14:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CB03A6A6B; Thu, 8 Jan 2009 07:14:08 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E684B3A6A3A for ; Thu, 8 Jan 2009 07:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQkRSGfOfSDW for ; Thu, 8 Jan 2009 07:14:06 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 36B683A6942 for ; Thu, 8 Jan 2009 07:14:06 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so4904240wag.5 for ; Thu, 08 Jan 2009 07:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+es1C1o8HTToWwnsrbcpcDK8ibN6/EiAnksNSYpFUeM=; b=W6e8MIiYtKkqhrGBkHNJTCye8kD8SLXIiW+0t5Y88hAIgJlX5A7pyHuomn/gg+ESuS 5FNZmHPkypF6AeYk7PZ5CQRBcAA7ieLi3cUysp+ufcwVpovyVQyy/OCX/mw+8jDcdFPI Y//l9gsCsnrAe87fm+WA4zzoV6H/mNou0FCCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=TWBaZgOnTaDEyEepJN3XSP0171krUVLCpJRdBe9hr8GxasFC9s1P9mMsnAnnLV32NV bpH5+vXuqzfNSwqo1MKnEVKLUh8Ev9Hh27pSaM6kgreX6WUkJDYHzA20khv+Pm3uTbHz tSdm3IzQZ7cOvOLJrk/sPO7+c4M5YIXBt18mU= Received: by 10.114.39.5 with SMTP id m5mr16136755wam.41.1231427632406; Thu, 08 Jan 2009 07:13:52 -0800 (PST) Received: by 10.115.58.3 with HTTP; Thu, 8 Jan 2009 07:13:52 -0800 (PST) Message-ID: <1d38a3350901080713q32c1a564m20b583b1daefd224@mail.gmail.com> Date: Thu, 8 Jan 2009 23:13:52 +0800 From: "Hui Deng" To: mif@ietf.org MIME-Version: 1.0 Subject: [mif] Mailing list Issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239818367==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0239818367== Content-Type: multipart/alternative; boundary="----=_Part_202043_7489716.1231427632394" ------=_Part_202043_7489716.1231427632394 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all I saw lots of email with mif-bounces@ietf.org. It seems some people has issue with this mailing list. If that is the case, please don't hestitate to let me know that, many thanks -Hui ------=_Part_202043_7489716.1231427632394 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, all
 
I saw lots of email with  mif-bounces@ietf.org.
 
It seems some people has issue with this mailing list.
If that is the case, please don't hestitate to let me know that,
 
many thanks
 
-Hui
------=_Part_202043_7489716.1231427632394-- --===============0239818367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0239818367==-- From mif-bounces@ietf.org Thu Jan 8 18:31:27 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E243A6AB3; Thu, 8 Jan 2009 18:31:27 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732F43A6AB3 for ; Thu, 8 Jan 2009 18:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMUqF5-xTv75 for ; Thu, 8 Jan 2009 18:31:25 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E0B6D3A6879 for ; Thu, 8 Jan 2009 18:31:24 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD6009GRMZW0X@szxga02-in.huawei.com> for mif@ietf.org; Fri, 09 Jan 2009 10:31:08 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD6005X5MZWEU@szxga02-in.huawei.com> for mif@ietf.org; Fri, 09 Jan 2009 10:31:08 +0800 (CST) Received: from w53375a ([10.164.12.28]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD60058IMZVPG@szxml05-in.huawei.com> for mif@ietf.org; Fri, 09 Jan 2009 10:31:08 +0800 (CST) Date: Fri, 09 Jan 2009 10:31:07 +0800 From: Qin Wu To: Hui Deng , mif@ietf.org Message-id: <00b701c97202$540059e0$1c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350901080713q32c1a564m20b583b1daefd224@mail.gmail.com> Subject: Re: [mif] Mailing list Issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0696841820==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0696841820== Content-type: multipart/alternative; boundary="Boundary_(ID_M4dwBYMFdWlQ3YWmh5rxvA)" This is a multi-part message in MIME format. --Boundary_(ID_M4dwBYMFdWlQ3YWmh5rxvA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Interesting topic, As we discussed before, you thought Internet IP model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it is a little different, mobile terminal has multiple modes, it would like to use all of them simulatenously which orginal IP model doesn't work any more on it. I can understand IETF more concentrates on single-point technology, not end to end solution. As regarding Internet IP model, dual radio model has already been developing to support inter-technology handover. Dual mode teminal is not fanciful. In the future, with the development of femto technolgy, single mode teminal can access mobile network via a femto basestation at home. I can not judge whether single radio technology or dual radio technology will dominate the future market. Any way, from the technical perspective, I think the traditional internet IP model will be gradually evolving. multiple interface requirements will become one big issue to be considered, e.g., dynamic provision and routing , coordination and synchronization mechanisms are needed to be further study. -Qin ----- Original Message ----- From: Hui Deng To: mif@ietf.org Sent: Thursday, January 08, 2009 11:13 PM Subject: [mif] Mailing list Issue Hello, all I saw lots of email with mif-bounces@ietf.org. It seems some people has issue with this mailing list. If that is the case, please don't hestitate to let me know that, many thanks -Hui ------------------------------------------------------------------------------ _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_M4dwBYMFdWlQ3YWmh5rxvA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Interesting topic, As we discussed before, you thought Internet IP model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it is a little different, mobile terminal has multiple modes, it would like to use all of them simulatenously which orginal IP model doesn't work any more on it.
I can understand IETF more concentrates on single-point technology, not end to end solution.
As regarding Internet IP model, dual radio model has already been developing to support inter-technology handover. Dual mode teminal is not fanciful.
In the future, with the development of femto technolgy, single mode teminal can access mobile network via a femto basestation at home. I can not  judge whether single radio technology or dual radio technology will dominate the future market. Any way, from the technical perspective, I think the traditional internet IP model will be gradually evolving. multiple interface requirements will become one big issue to be considered, e.g., dynamic provision and routing , coordination and synchronization mechanisms are needed to be further study.
 
-Qin
----- Original Message -----
From: Hui Deng
Sent: Thursday, January 08, 2009 11:13 PM
Subject: [mif] Mailing list Issue

Hello, all
 
I saw lots of email with  mif-bounces@ietf.org.
 
It seems some people has issue with this mailing list.
If that is the case, please don't hestitate to let me know that,
 
many thanks
 
-Hui

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
--Boundary_(ID_M4dwBYMFdWlQ3YWmh5rxvA)-- --===============0696841820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0696841820==-- From mif-bounces@ietf.org Sat Jan 10 21:40:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E493A6991; Sat, 10 Jan 2009 21:40:08 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839D33A6984 for ; Sat, 10 Jan 2009 21:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg0J2YhKl3mC for ; Sat, 10 Jan 2009 21:29:52 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by core3.amsl.com (Postfix) with ESMTP id A52523A6948 for ; Sat, 10 Jan 2009 21:29:52 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so4032376qbd.41 for ; Sat, 10 Jan 2009 21:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=z2ejk5nlSyRTdWgCUIkIRofEkE04B+meYxDSplUAGZA=; b=QXAMj36mM82wtD7dP7OuK1qODHMB04UWmwwpsns+myIQnCdlL1vLIcN/mFA8qMFPL6 e5TjTYC+76YOIXLN9EKM/wiMLyIeFUAgMNUNtnn/AqvoTT0khU4W1k79MLm4aaXMvrHl k6DWEEHCF1kEfk7LRw/CTpdbny3e4UvQii7LY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=PbTdoL8OdOJ9/J3utYImZtsQiY2CDMbkhx0oWotF2Ovv1kFfltBbLwEQUgMqoE1Js3 WwlccpLT5fU6P32owOJmrJztLTM7ItHJOFL+hulIzwQtpFM2RcKdJYU2eWv+/W6i4uIc IRSVRZw3SfFPoLrLg4y1AnaGY9X/UQVb4ULGI= Received: by 10.65.11.17 with SMTP id o17mr18984011qbi.4.1231651776952; Sat, 10 Jan 2009 21:29:36 -0800 (PST) Received: by 10.65.219.11 with HTTP; Sat, 10 Jan 2009 21:29:36 -0800 (PST) Message-ID: <3db7b9d60901102129j55db6b0fp3ef2cb44a9570807@mail.gmail.com> Date: Sun, 11 Jan 2009 13:29:36 +0800 From: "Kai Ju" To: mif@ietf.org MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 10 Jan 2009 21:40:07 -0800 Subject: Re: [mif] =?windows-1256?q?draft-blanchet-mif-problem-statement-00=2E?= =?windows-1256?q?txt=FE?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1033608179==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1033608179== Content-Type: multipart/alternative; boundary="----=_Part_89095_24875756.1231651776950" ------=_Part_89095_24875756.1231651776950 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksYWxsCgpBcyB2aWV3ZWQgZnJvbSB0aGUgYXNwZWN0IG9mIHRlcm1pbmFso6x3b3VsZCB5b3Ug cGxlYXNlIGNsYWZpcnkgdGhlc2UKcXVlc3Rpb25zIGJlbG93OgoKMaGiV2hpY2ggd2F5IHdvdWxk IHRoZSBzZXJ2ZXIgYXNzaWduIHRoZSByb3V0aW5nIHRhYmxlIHRvIHRoZSB0ZXJtaW5hbCBieT8K MqGiQXNzdW1pbmcgcXVlc3Rpb24gMSBpcyBkb25lLCBob3cgdG8gZGVjaWRlIHdoaWNoIGdhdGV3 YXkgdG8gYXNzaWduIHRoZQp0ZXJtaW5hbCdzIHJvdXRpbmcgc3RyYXRlZ3kgaW4gYSBtdWx0aS1j b25uZWN0aW9uIGVudmlyb25tZW50PyBBbmQgaG93IGNhbgp0aGlzIGdhdGV3YXkga25vdyBhYm91 dCB0aGUgd2hvbGUgY29ubmVjdGlvbiBlbnZpcm9ubWVudKO/CjOhokFzc3VtaW5nIHF1ZXN0aW9u IDIgY2FuIGJlIHNvbHZlZCBpbiB0aGUgd2F5IHRoYXQgdGhlIGNvcnJlc3BvbmRpbmcKZ2F0ZXdh eSBvZiBlYWNoIGNvbm5lY3Rpb24gYXNzaWducyBpdHMgb3duIHJvdXRpbmcgc3RyYXRlZ3kgZm9y IHRoZQp0ZXJtaW5hbCwgdGhlbiB0aGUgdGVybWluYWwgbmVlZHMgdG8gbWFrZSBhIHN0cmF0ZWd5 IHByaW9yaXR5IGZpbHRlcmluZwptZWNoYW5pc20uIFRoZSBuZXcgcHJvYmxlbSByZXN1bHRpbmcg ZnJvbSB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgdGhpcwptZWNoYW5pc20gYWxzbyBuZWVkcyB0byBi ZSBkZWZpbmVkLgoKSWYgYWxsIHRoZXNlIHF1ZXN0aW9ucyBhcmUgc29sdmVkLCBzbWFydCBwaG9u ZSBzaG91bGQgYmUgYWJsZSB0byByZWFsaXplIGl0LApvbmx5IHNvbWUgcHJvYmxlbSwgYXMgeW91 IGtub3csIG1pZ2h0IG9jY3VyIGluIGZlYXR1cmUgcGhvbmUuCg== ------=_Part_89095_24875756.1231651776950 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksYWxsIDxicj48YnI+PGZvbnQgc2l6ZT0iMiI+QXMgdmlld2VkIGZyb20gdGhlIGFzcGVjdCBv ZiB0ZXJtaW5hbDwvZm9udD48Zm9udCBzaXplPSIyIj6jrHdvdWxkIHlvdSBwbGVhc2UgY2xhZmly eSB0aGVzZSBxdWVzdGlvbnMgYmVsb3c6PC9mb250PiA8YnI+PGJyPjxmb250IHNpemU9IjIiPjGh oldoaWNoIHdheSB3b3VsZCB0aGUgc2VydmVyIGFzc2lnbiB0aGUgcm91dGluZyB0YWJsZSB0byB0 aGUgdGVybWluYWwgYnk/PC9mb250PiA8YnI+Cjxmb250IHNpemU9IjIiPjKhokFzc3VtaW5nIHF1 ZXN0aW9uIDEgaXMgZG9uZSwgaG93IHRvIGRlY2lkZSB3aGljaCBnYXRld2F5IHRvIGFzc2lnbiB0 aGUgdGVybWluYWwmIzM5O3Mgcm91dGluZyBzdHJhdGVneSBpbiBhIG11bHRpLWNvbm5lY3Rpb24g ZW52aXJvbm1lbnQ/IEFuZCBob3cgY2FuIHRoaXMgZ2F0ZXdheSBrbm93IGFib3V0IHRoZSB3aG9s ZSBjb25uZWN0aW9uIGVudmlyb25tZW50o788L2ZvbnQ+IDxicj4KPGZvbnQgc2l6ZT0iMiI+M6Gi QXNzdW1pbmcgcXVlc3Rpb24gMiBjYW4gYmUgc29sdmVkIGluIHRoZSB3YXkgdGhhdCB0aGUgY29y cmVzcG9uZGluZyBnYXRld2F5IG9mIGVhY2ggY29ubmVjdGlvbiBhc3NpZ25zIGl0cyBvd24gcm91 dGluZyBzdHJhdGVneSBmb3IgdGhlIHRlcm1pbmFsLCB0aGVuIHRoZSB0ZXJtaW5hbCBuZWVkcyB0 byBtYWtlIGEgc3RyYXRlZ3kgcHJpb3JpdHkgZmlsdGVyaW5nIG1lY2hhbmlzbS4gVGhlIG5ldyBw cm9ibGVtIHJlc3VsdGluZyBmcm9tIHRoaXMgc29sdXRpb24gaXMgdGhhdCB0aGlzIG1lY2hhbmlz bSBhbHNvIG5lZWRzIHRvIGJlIGRlZmluZWQuIDwvZm9udD48YnI+Cjxicj48Zm9udCBzaXplPSIy Ij5JZiBhbGwgdGhlc2UgcXVlc3Rpb25zIGFyZSBzb2x2ZWQsIHNtYXJ0IHBob25lIHNob3VsZCBi ZSBhYmxlIHRvIHJlYWxpemUgaXQsIG9ubHkgc29tZSBwcm9ibGVtLCBhcyB5b3Uga25vdywgbWln aHQgb2NjdXIgaW4gZmVhdHVyZSBwaG9uZS48L2ZvbnQ+IAo= ------=_Part_89095_24875756.1231651776950-- --===============1033608179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1033608179==-- From mif-bounces@ietf.org Sun Jan 11 08:51:22 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7FD3A69FE; Sun, 11 Jan 2009 08:51:22 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B773A6A08 for ; Sun, 11 Jan 2009 08:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPastm2+EFK2 for ; Sun, 11 Jan 2009 08:51:21 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CDEF33A69FE for ; Sun, 11 Jan 2009 08:51:21 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0BGoUvf003911; Sun, 11 Jan 2009 10:51:03 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Jan 2009 18:51:01 +0200 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Jan 2009 18:51:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Jan 2009 18:50:47 +0200 Message-ID: In-Reply-To: <493ED933.7030906@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [Fwd: I-D Action:draft-blanchet-mif-problem-statement-00.txt] Thread-Index: AclaP0JUd1xko5+zQFC8y+Qy0NXtgwZxxyHw References: <493ED933.7030906@viagenie.ca> From: To: , X-OriginalArrivalTime: 11 Jan 2009 16:51:01.0694 (UTC) FILETIME=[C8F8ADE0:01C9740C] X-Nokia-AV: Clean Subject: Re: [mif] [Fwd: I-D Action:draft-blanchet-mif-problem-statement-00.txt] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, On 1. "Introduction" you might want to add IKEv2 [RFC4306] into example lis= t of mechanisms. On 2. "Split DNS" you might want to expand with that this may influence on = DNS server selection as well, e.g.: "Therefore the traffic related to these names and addresses has to go throu= gh the right interface, including the traffic related to the DNS name resol= ution procedures. The DNS resolution procedure may fail if a DNS resolver i= mplementation does not take split DNS into account during DNS server select= ion. Furthermore, a typical IP stack..." On 3. "Routing", perhaps mention that multi-homed host may have just a sing= le route to a destination, e.g. "A multi-homed host may have single or multiple routes to a destination." Best regards, Teemu >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On = >Behalf Of ext Marc Blanchet >Sent: 09 December, 2008 22:47 >To: mif@ietf.org >Subject: [mif] [Fwd: I-D = >Action:draft-blanchet-mif-problem-statement-00.txt] > >hi, > here is the first pass of the PS document. I tried to = >summarize the issues, be concise and to the point. Please comment! > >Marc. > >-------- Message original -------- >Sujet : I-D Action:draft-blanchet-mif-problem-statement-00.txt >Date : Tue, 9 Dec 2008 12:45:02 -0800 (PST) De : = >Internet-Drafts@ietf.org R=E9pondre =E0 : internet-drafts@ietf.org = >Pour : i-d-announce@ietf.org > >A New Internet-Draft is available from the on-line = >Internet-Drafts directories. > > Title : Multiple Interfaces Problem Statement > Author(s) : M. Blanchet > Filename : draft-blanchet-mif-problem-statement-00.txt > Pages : 7 > Date : 2008-12-09 > >A multi-homed host receives node configuration information = >from each of its access networks. Some configuration objects = >are global to the node, some are local to the interface. = >Various issues arise when multiple configuration objects that = >are global to the node are received on the many interfaces the = >multi-homed host has. This document describes these issues. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem- >statement-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail = >reader implementation to automatically retrieve the ASCII = >version of the Internet-Draft. > > >-- >=3D=3D=3D=3D=3D=3D=3D=3D=3D >IPv6 book: Migrating to IPv6, Wiley, 2006. = >http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW = >traversal: http://numb.viagenie.ca > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Tue Jan 13 14:20:47 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071D63A68DD; Tue, 13 Jan 2009 14:20:47 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE97F3A6768 for ; Tue, 13 Jan 2009 14:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOM5bnABH2Bq for ; Tue, 13 Jan 2009 14:20:44 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id E2AA73A68DD for ; Tue, 13 Jan 2009 14:20:44 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so115747wag.5 for ; Tue, 13 Jan 2009 14:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=dwW98V4A6HKs+Qf9BnirLooq0fDxTli7bcxP64IR64Q=; b=vunycq+8wHdQbPGY/G3GZQV5RASwrf4nBQ3IuSzQFkd3Pjn7+2XjIVq9p4e4dsrrxT xHTC9KnwPuiOUrl0MR4ygt+mFcH//B6UI/2QXuOPaZqMP8/fArqRgV8Ro1hEjJTwT9ta rcqT+cbYNf9DiVUk+9m99SjuWjoKAylIKhUsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=rRQqKNzVznBD+2HoDRLTb+fi/iUD8i+aT0ZEqcMEto67RJS5HOgkDerWBQSRDOjZoa cEHjau0kdjBq/3RNr/l6bAt+ZS0lmYzmxDBbKtx1ml7Bz1TLVwAIRYY4bMrhlPgt4MGR eTQHgtXIoOsyRlpIrPb/7K9aNRp7Iz6538mSE= Received: by 10.115.58.1 with SMTP id l1mr20629613wak.191.1231885229730; Tue, 13 Jan 2009 14:20:29 -0800 (PST) Received: by 10.115.58.3 with HTTP; Tue, 13 Jan 2009 14:20:29 -0800 (PST) Message-ID: <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> Date: Tue, 13 Jan 2009 15:20:29 -0700 From: "Hui Deng" To: "Hong Yong-Geun" In-Reply-To: <8ba101c97154$1dbae930$8310fe81@etri.info> MIME-Version: 1.0 References: <8ba101c97154$1dbae930$8310fe81@etri.info> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017143768==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============2017143768== Content-Type: multipart/alternative; boundary="----=_Part_248865_28069430.1231885229722" ------=_Part_248865_28069430.1231885229722 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Hong Yong, I read through your two drafts, understand you are talking the issue without Monami it seems Mobile Ipv6 internal also has similar issue with us if I understand it correctly, In this case I would like to encourage you to propose this issue to our work, if allowed, it mightbe doable within our scope, many thanks -Hui 2009/1/7 Hong Yong-Geun > Hi. mif.. > > Let me join this discussion. > > It is very interesting to see mif. > > As Hui Deng says, I understand that mif has different approach > from other WG such as MEXT and monami6 WG, etc. > > In MEXT, multiple interfaces issues are related to Mobile IP, NEMO,.. > In mif, multiple interfaces issues are different from those of MEXT. > So, in mif, it is better to find more general issues which are not related > to Mobile IP. > > I think that M.Blanchet's "Multiple Interfaces Problem Statement" draft is > a good starting point to discuss general issues on mif. > > I would like to introduce another related drafts which I presented at > monami6 WG at 64th IETF meeting. > > - Analysis of multiple interfaces in a Mobile > Node(draft-hong-multipleif-mn-pb-statement-00) > > http://tools.ietf.org/draft/draft-hong-multipleif-mn-pb-statement/draft-hong-multipleif-mn-pb-statement-00.txt > > - Virtual network interface for multiple interfaces in a Mobile node using > Mobile IPv6 > (draft-hong-virtualif-mn-mipv6-00) > > http://tools.ietf.org/draft/draft-hong-virtualif-mn-mipv6/draft-hong-virtualif-mn-mipv6-00.txt > > > In the section 2.2 (General Network Issues) in the first draft, > there are general network issues due to multiple interfaces. > > Including these drafts, I hope to encourage this discussion > > Yong-Geun. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ------=_Part_248865_28069430.1231885229722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Hong Yong,
 
I read through your two drafts, understand you are talking the issue without Monami
it seems Mobile Ipv6 internal also has similar issue with us if I understand it correctly,
In this case I would like to encourage you to propose this issue to our work, if allowed,
it mightbe doable within our scope,
 
many thanks
 
-Hui
2009/1/7 Hong Yong-Geun <yghong@etri.re.kr>

Hi. mif..

Let me join this discussion.

It is very interesting to see mif.

As Hui Deng says, I understand that mif has different approach
from other WG such as MEXT and monami6 WG, etc.

In MEXT, multiple interfaces issues are related to Mobile IP, NEMO,..
In mif, multiple interfaces issues are different from those of MEXT.
So, in mif, it is better to find more general issues which are not related to Mobile IP.

I think that M.Blanchet's "Multiple Interfaces Problem Statement" draft is
a good starting point to discuss general issues on mif.

I would like to introduce another related drafts which I presented at monami6 WG at 64th IETF meeting.

 - Analysis of multiple interfaces in a Mobile Node(draft-hong-multipleif-mn-pb-statement-00)
  http://tools.ietf.org/draft/draft-hong-multipleif-mn-pb-statement/draft-hong-multipleif-mn-pb-statement-00.txt

 - Virtual network interface for multiple interfaces in a Mobile node using Mobile IPv6
   (draft-hong-virtualif-mn-mipv6-00)
  http://tools.ietf.org/draft/draft-hong-virtualif-mn-mipv6/draft-hong-virtualif-mn-mipv6-00.txt


In the section 2.2 (General Network Issues) in the first draft,
there are general network issues due to multiple interfaces.

Including these drafts, I hope to encourage this discussion

Yong-Geun.


_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


------=_Part_248865_28069430.1231885229722-- --===============2017143768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2017143768==-- From mif-bounces@ietf.org Tue Jan 13 14:35:33 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821EF3A6932; Tue, 13 Jan 2009 14:35:33 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93F13A6932 for ; Tue, 13 Jan 2009 14:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MDYndtOm3I0 for ; Tue, 13 Jan 2009 14:35:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id CC21B3A689E for ; Tue, 13 Jan 2009 14:35:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so258662rvf.49 for ; Tue, 13 Jan 2009 14:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=eb060ECWzeFqGNtzug+p8ZYW5UScJ+740OkKkGHttYs=; b=oCc/16pJrmV+JLupuYL40+xQVrjV8gYNDEQOe/DRmCfIWp0gC5qePDMD8JJ0scSwyK dm6S5Kj6Ni+3CVRSJ0MGObsLocT0OAVjlfIX7KfE+8STU3WYn7x5nN4d2No6tBMBz+M/ UA9NVNgLqBjPhv/ucxtGWJUmJ5tcu6qLT+JBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=pZtsTTkToSBzKAM6wKa4ir+r79BPVLPBWi1hbfRI5akpwpkbNWH8PqjXg3FF+30Bg+ /1nd0KxoX1fY3eIIgXNW5A00uFIM4tiuMfo+PCARYiUD5M/9vU73g/TxSpCMFgpqj1mn RxvidEjO2IXfcmNt96hFPLX2xpGha3EbymCgo= Received: by 10.114.133.1 with SMTP id g1mr3194270wad.162.1231886115625; Tue, 13 Jan 2009 14:35:15 -0800 (PST) Received: by 10.115.58.3 with HTTP; Tue, 13 Jan 2009 14:35:15 -0800 (PST) Message-ID: <1d38a3350901131435v9995ebai80880b98b0456e7c@mail.gmail.com> Date: Tue, 13 Jan 2009 15:35:15 -0700 From: "Hui Deng" To: "Qin Wu" MIME-Version: 1.0 Cc: mif@ietf.org Subject: [mif] IP model for multiple mode mobile terminal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283105202==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1283105202== Content-Type: multipart/alternative; boundary="----=_Part_249014_1119843.1231886115608" ------=_Part_249014_1119843.1231886115608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Qin, Thanks for your comments. see below inline reply. 2009/1/8 Qin Wu > Interesting topic, As we discussed before, you thought Internet IP > model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it > is a little different, mobile terminal has multiple modes, it would like to > use all of them simulatenously which orginal IP model doesn't work any more > on it. > Thanks for your agreement on this issue. > I can understand IETF more concentrates on single-point technology, not > end to end solution. > As regarding Internet IP model, dual radio model has already been > developing to support inter-technology handover. Dual mode teminal is not > fanciful. > Could you help to write down how you implement on this? > In the future, with the development of femto technolgy, single mode > teminal can access mobile network via a femto basestation at home. I can not > judge whether single radio technology or dual radio technology will > dominate the future market. Any way, from the technical perspective, I think > the traditional internet IP model will be gradually evolving. multiple > interface requirements will become one big issue to be considered, e.g., > dynamic provision and routing , coordination and synchronization mechanisms > are needed to be further study. > > it seems that dynamical provision and routing, coordination and synchronization will become more complicated, simple way make deployment easy, it is the way of Internet exist thanks -Hui > -Qin > > ----- Original Message ----- > *From:* Hui Deng > *To:* mif@ietf.org > *Sent:* Thursday, January 08, 2009 11:13 PM > *Subject:* [mif] Mailing list Issue > > Hello, all > > I saw lots of email with mif-bounces@ietf.org. > > It seems some people has issue with this mailing list. > If that is the case, please don't hestitate to let me know that, > > many thanks > > -Hui > > ------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ------=_Part_249014_1119843.1231886115608 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgUWluLCA8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5UaGFua3MgZm9yIHlv dXIgY29tbWVudHMuIHNlZSBiZWxvdyBpbmxpbmUgcmVwbHkuPGJyPjwvZGl2Pgo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+MjAwOS8xLzggUWluIFd1IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJl Zj0ibWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb20iPnN1bnNlYXdxQGh1YXdlaS5jb208L2E+Jmd0 Ozwvc3Bhbj48YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJ TkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2Nj YyAxcHggc29saWQiPgo8ZGl2IGJnY29sb3I9IiNmZmZmZmYiPgo8ZGl2Pjxmb250IGZhY2U9IsvO zOUiIHNpemU9IjIiPgo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+ SW50ZXJlc3RpbmcgdG9waWMsIEFzIHdlIGRpc2N1c3NlZCBiZWZvcmUsIHlvdSB0aG91Z2h0IElu dGVybmV0IElQIG1vZGVsJm5ic3A7d2FzIGludmVudGVkIGJ5IDEgUEMsIDEgRGVmYXVsdCBHYXRl d2F5LCAxIGRlZmF1bHQgcm91dGUuIEJ1dCB0b2RheSBpdCBpcyBhIGxpdHRsZSBkaWZmZXJlbnQs IG1vYmlsZSB0ZXJtaW5hbCBoYXMgbXVsdGlwbGUgbW9kZXMsIGl0IHdvdWxkIGxpa2UgdG8gdXNl IGFsbCBvZiB0aGVtIHNpbXVsYXRlbm91c2x5IHdoaWNoIG9yZ2luYWwgSVAgbW9kZWwgZG9lc24m IzM5O3Qgd29yayBhbnkgbW9yZSBvbiBpdC48L2ZvbnQ+PC9kaXY+CjwvZm9udD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+CjxkaXY+VGhhbmtzIGZvciB5b3VyIGFncmVlbWVudCBvbiB0aGlzIGlz c3VlLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsg Qk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KPGRpdiBiZ2NvbG9yPSIjZmZmZmZmIj4KPGRp dj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj4KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9IjMiPjxzcGFuIGlkPSIiPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXY+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj5JIGNhbiB1bmRlcnN0YW5kIElFVEYg bW9yZSZuYnNwO2NvbmNlbnRyYXRlcyBvbiBzaW5nbGUtcG9pbnQgdGVjaG5vbG9neSwgbm90IGVu ZCB0byBlbmQgc29sdXRpb24uPC9mb250PjwvZGl2Pgo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0iMyI+QXMgcmVnYXJkaW5nIEludGVybmV0IElQIG1vZGVsLCBkdWFsIHJh ZGlvIG1vZGVsIGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGluZyB0byBzdXBwb3J0IGludGVyLXRl Y2hub2xvZ3kgaGFuZG92ZXIuIER1YWwgbW9kZSB0ZW1pbmFsIGlzIG5vdCBmYW5jaWZ1bC48L2Zv bnQ+PC9kaXY+PC9mb250PjwvZGl2PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxkaXY+Q291bGQgeW91 IGhlbHAgdG8gd3JpdGUgZG93biBob3cmbmJzcDt5b3UgaW1wbGVtZW50IG9uIHRoaXM/PC9kaXY+ CjxkaXY+Jm5ic3A7PC9kaXY+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVG VDogI2NjYyAxcHggc29saWQiPgo8ZGl2IGJnY29sb3I9IiNmZmZmZmYiPgo8ZGl2Pjxmb250IGZh Y2U9IsvOzOUiIHNpemU9IjIiPgo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0iMyI+PHNwYW4gaWQ9IiI+PC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdj48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPkluIHRoZSBmdXR1cmUsIHdpdGggdGhlIGRldmVsb3Bt ZW50IG9mIGZlbXRvIHRlY2hub2xneSwgc2luZ2xlIG1vZGUgdGVtaW5hbCBjYW4gYWNjZXNzJm5i c3A7bW9iaWxlIG5ldHdvcmsgdmlhIGEgZmVtdG8gYmFzZXN0YXRpb24gYXQgaG9tZS4gSSZuYnNw O2NhbiBub3QgJm5ic3A7anVkZ2Ugd2hldGhlciBzaW5nbGUgcmFkaW8gdGVjaG5vbG9neSBvciBk dWFsIHJhZGlvIHRlY2hub2xvZ3kgd2lsbCBkb21pbmF0ZSB0aGUgZnV0dXJlIG1hcmtldC4gQW55 IHdheSwgZnJvbSB0aGUgdGVjaG5pY2FsIHBlcnNwZWN0aXZlLCBJIHRoaW5rIHRoZSB0cmFkaXRp b25hbCBpbnRlcm5ldCBJUCBtb2RlbCB3aWxsIGJlIGdyYWR1YWxseSBldm9sdmluZy4gbXVsdGlw bGUgaW50ZXJmYWNlIHJlcXVpcmVtZW50cyB3aWxsIGJlY29tZSBvbmUgYmlnIGlzc3VlIHRvIGJl IGNvbnNpZGVyZWQsIGUuZy4sIGR5bmFtaWMgcHJvdmlzaW9uIGFuZCByb3V0aW5nICwgY29vcmRp bmF0aW9uIGFuZCBzeW5jaHJvbml6YXRpb24gbWVjaGFuaXNtcyBhcmUgbmVlZGVkIHRvIGJlIGZ1 cnRoZXIgc3R1ZHkuPC9mb250PjwvZGl2PgoKPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9IjMiPjwvZm9udD4mbmJzcDs8L2Rpdj48L2ZvbnQ+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPgo8ZGl2Pml0IHNlZW1zJm5ic3A7dGhhdCBkeW5hbWljYWwgcHJvdmlzaW9uIGFuZCBy b3V0aW5nLCBjb29yZGluYXRpb24gYW5kIHN5bmNocm9uaXphdGlvbiB3aWxsIGJlY29tZSBtb3Jl IGNvbXBsaWNhdGVkLCBzaW1wbGUgd2F5IG1ha2UgZGVwbG95bWVudCBlYXN5LCBpdCBpcyB0aGUg d2F5IG9mIEludGVybmV0IGV4aXN0PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+dGhhbmtz PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+LUh1aTwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2 Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFl eDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlk Ij4KPGRpdiBiZ2NvbG9yPSIjZmZmZmZmIj4KPGRpdj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIy Ij4KPGRpdj48c3BhbiBpZD0iIj48L3NwYW4+PC9kaXY+CjxkaXY+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPSIzIj4tUWluPC9mb250PjwvZGl2PjwvZm9udD48L2Rpdj4KPGJsb2Nr cXVvdGUgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJ Ti1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hU OiAwcHgiPgo8ZGl2Pgo8ZGl2PjwvZGl2Pgo8ZGl2IGNsYXNzPSJXajNDN2MiPgo8ZGl2Pi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9kaXY+CjxkaXYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNl NGU0ZTQiPjxiPkZyb206PC9iPiA8YSB0aXRsZT0iZGVuZ2h1aTAyQGdtYWlsLmNvbSIgaHJlZj0i bWFpbHRvOmRlbmdodWkwMkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5IdWkgRGVuZzwvYT4g PC9kaXY+CjxkaXY+PGI+VG86PC9iPiA8YSB0aXRsZT0ibWlmQGlldGYub3JnIiBocmVmPSJtYWls dG86bWlmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlmQGlldGYub3JnPC9hPiA8L2Rpdj4K PGRpdj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMDgsIDIwMDkgMTE6MTMgUE08L2Rp dj4KPGRpdj48Yj5TdWJqZWN0OjwvYj4gW21pZl0gTWFpbGluZyBsaXN0IElzc3VlPC9kaXY+Cjxk aXY+PGJyPjwvZGl2Pgo8ZGl2PkhlbGxvLCBhbGw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRp dj5JIHNhdyBsb3RzIG9mIGVtYWlsIHdpdGgmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOm1pZi1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Ljwv ZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pkl0IHNlZW1zIHNvbWUgcGVvcGxlIGhhcyBpc3N1 ZSB3aXRoIHRoaXMgbWFpbGluZyBsaXN0LjwvZGl2Pgo8ZGl2PklmIHRoYXQgaXMgdGhlIGNhc2Us IHBsZWFzZSBkb24mIzM5O3QgaGVzdGl0YXRlIHRvIGxldCBtZSBrbm93IHRoYXQsPC9kaXY+Cjxk aXY+Jm5ic3A7PC9kaXY+CjxkaXY+bWFueSB0aGFua3M8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4K PGRpdj4tSHVpPC9kaXY+PC9kaXY+PC9kaXY+CjxwPgo8aHI+Cgo8cD48L3A+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bWlmIG1haWxpbmcgbGlzdDxi cj48YSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlmQGlldGYu b3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWlmPC9hPjxicj4KCjxwPjwvcD48L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+Cg== ------=_Part_249014_1119843.1231886115608-- --===============1283105202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1283105202==-- From mif-bounces@ietf.org Tue Jan 13 18:32:24 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5062628C14F; Tue, 13 Jan 2009 18:32:24 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87603A6A6E for ; Tue, 13 Jan 2009 18:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yleeIzZ5wgE for ; Tue, 13 Jan 2009 18:32:21 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id D30C93A6A4A for ; Tue, 13 Jan 2009 18:32:21 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so169323wag.5 for ; Tue, 13 Jan 2009 18:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Y+5XLlk49SHYT/FLxbgoQ2ZxNTf2x/dSdwB2wDZ+8T0=; b=oC6gNpy06BFAwPPA8og9tHPGCxbJrUsvg2wfnAPBQ758LFME6q3dw+n7bS6ZnUbKay 2OZIZt1Q4R/hwCSXXb4hO5RGjh/XlAL7EeTB0VVTEOUwu99mMYtgIHnFfDcN/yl1/Q6c 0to8FXkzzCMTNuIAr19l8NLqIJ09JwVVa+W38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=cKnmmh7ZhN9NJgEe87JLC2y1sBM2SMHYVrgSxbaQ46slc3655ZwzBhrCCZLY0aHfYg To++3Dqm785hatg6RiWMsE6dbePGH+/1/5lXiPxyx6h1oBTE56KkvMcvquZS0xCWq+fl dkzYgAV+HQ2/UGSuK8/JSQJlKFesqYbEWnuTg= Received: by 10.114.196.1 with SMTP id t1mr20762590waf.107.1231900326351; Tue, 13 Jan 2009 18:32:06 -0800 (PST) Received: by 10.115.58.3 with HTTP; Tue, 13 Jan 2009 18:32:06 -0800 (PST) Message-ID: <1d38a3350901131832r242ad5c9mb411874aed5be752@mail.gmail.com> Date: Tue, 13 Jan 2009 19:32:06 -0700 From: "Hui Deng" To: "Kai Ju" In-Reply-To: <3db7b9d60901102129j55db6b0fp3ef2cb44a9570807@mail.gmail.com> MIME-Version: 1.0 References: <3db7b9d60901102129j55db6b0fp3ef2cb44a9570807@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] =?windows-1256?q?draft-blanchet-mif-problem-statement-00=2E?= =?windows-1256?q?txt=FE?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0341960566==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0341960566== Content-Type: multipart/alternative; boundary="----=_Part_249983_5691455.1231900326345" ------=_Part_249983_5691455.1231900326345 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIEthaSBKdSwKCnRoYW5rcyBmb3IgeW91ciBjb21tZW50cywgd2hhdCB0aGUgcXVlc3Rpb24g eW91IGFza2VkIGhlcmUgaXMgcmVsYXRlZApwcm9wb3NhbCBmcm9tIENoaW5hIE1vYmlsZS4gc2Vl IGlubGluZSByZXBseQoKMjAwOS8xLzEwIEthaSBKdSA8anVrYWkuenRlQGdtYWlsLmNvbT4KCj4g SGksYWxsCj4KPiBBcyB2aWV3ZWQgZnJvbSB0aGUgYXNwZWN0IG9mIHRlcm1pbmFso6x3b3VsZCB5 b3UgcGxlYXNlIGNsYWZpcnkgdGhlc2UKPiBxdWVzdGlvbnMgYmVsb3c6Cj4KPiAxoaJXaGljaCB3 YXkgd291bGQgdGhlIHNlcnZlciBhc3NpZ24gdGhlIHJvdXRpbmcgdGFibGUgdG8gdGhlIHRlcm1p bmFsIGJ5PwoKPT0+VGhlcmUgYXJlIG11bHRpcGxlIHdheSBjb3VsZCBkbyB0aGlzLCBpbiB0aGUg bW9iaWxlIGFjY2VzcyBuZXR3b3JrICwKQU5EU0YsIERIQ1AsIElLRSBldCBhbC4KCgo+Cj4gMqGi QXNzdW1pbmcgcXVlc3Rpb24gMSBpcyBkb25lLCBob3cgdG8gZGVjaWRlIHdoaWNoIGdhdGV3YXkg dG8gYXNzaWduIHRoZQo+IHRlcm1pbmFsJ3Mgcm91dGluZyBzdHJhdGVneSBpbiBhIG11bHRpLWNv bm5lY3Rpb24gZW52aXJvbm1lbnQ/IEFuZCBob3cgY2FuCj4gdGhpcyBnYXRld2F5IGtub3cgYWJv dXQgdGhlIHdob2xlIGNvbm5lY3Rpb24gZW52aXJvbm1lbnSjvwoKPT0+IGl0IGNvdWxkIHJlbHkg b24gSVNQJ3MgcG9saWN5IHN0cmF0ZWd5LiBhbnl3YXksIGl0IGlzIGEgcG9pbnQgdG8gYmUKc29s dmVkIGZvciBjb29yZGluYXRpb24uCgoKPgo+IDOhokFzc3VtaW5nIHF1ZXN0aW9uIDIgY2FuIGJl IHNvbHZlZCBpbiB0aGUgd2F5IHRoYXQgdGhlIGNvcnJlc3BvbmRpbmcKPiBnYXRld2F5IG9mIGVh Y2ggY29ubmVjdGlvbiBhc3NpZ25zIGl0cyBvd24gcm91dGluZyBzdHJhdGVneSBmb3IgdGhlCj4g dGVybWluYWwsIHRoZW4gdGhlIHRlcm1pbmFsIG5lZWRzIHRvIG1ha2UgYSBzdHJhdGVneSBwcmlv cml0eSBmaWx0ZXJpbmcKPiBtZWNoYW5pc20uIFRoZSBuZXcgcHJvYmxlbSByZXN1bHRpbmcgZnJv bSB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgdGhpcwo+IG1lY2hhbmlzbSBhbHNvIG5lZWRzIHRvIGJl IGRlZmluZWQuCgo9PT4gc29tZSB0aW1lLCBtb2JpbGUgdGVybWluYWwgY291bGQgc2VsZWN0IGJh c2VkIG9uIHNldmVyYWwgb3B0aW9ucywgYnV0Cm5vdCBhbGwgc3Vic2NyaWJlciBhcmUgc21hcnQg bGlrZSB0aGF0LCBhbnl3YXksIGJvdGggc29sdXRpb24gc2hvdWxkIGJlCmNvbnNpZGVyZWQuCgoK Pgo+IElmIGFsbCB0aGVzZSBxdWVzdGlvbnMgYXJlIHNvbHZlZCwgc21hcnQgcGhvbmUgc2hvdWxk IGJlIGFibGUgdG8gcmVhbGl6ZQo+IGl0LCBvbmx5IHNvbWUgcHJvYmxlbSwgYXMgeW91IGtub3cs IG1pZ2h0IG9jY3VyIGluIGZlYXR1cmUgcGhvbmUuCgo9PT4gVGhhbmtzIGZvciB5b3VyIGRpc2N1 c3Npb24sIGZlYXR1cmUgcGhvbmUgc3RpbGwgaGF2ZSBzb21lIGlzc3VlLCBzbWFydApwaG9uZSBp cyBiZXN0IGhvc3QgZmFjaW5nIHRoaXMgY2hhbGxlbmdlcywKClBsZWFzZSBmZWVsIGZyZWUgdG8g cmFpc2UgeW91ciBxdWVzdGlvbiBhbmQgc29sdXRpb24uCgp0aGFua3MgYWdhaW4KCi1IdWkKCgo+ Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBtaWYg bWFpbGluZyBsaXN0Cj4gbWlmQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9taWYKPgo+Cg== ------=_Part_249983_5691455.1231900326345 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgS2FpIEp1LDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PnRoYW5rcyBmb3Ig eW91ciBjb21tZW50cywgd2hhdCB0aGUgcXVlc3Rpb24geW91IGFza2VkIGhlcmUgaXMgcmVsYXRl ZCBwcm9wb3NhbCBmcm9tIENoaW5hIE1vYmlsZS4gc2VlIGlubGluZSByZXBseTxicj48YnI+PC9k aXY+CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzEvMTAgS2FpIEp1IDxzcGFuIGRpcj0i bHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmp1a2FpLnp0ZUBnbWFpbC5jb20iPmp1a2FpLnp0ZUBn bWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBC T1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPkhpLGFsbCA8YnI+PGJyPjxmb250IHNpemU9IjIi PkFzIHZpZXdlZCBmcm9tIHRoZSBhc3BlY3Qgb2YgdGVybWluYWw8L2ZvbnQ+PGZvbnQgc2l6ZT0i MiI+o6x3b3VsZCB5b3UgcGxlYXNlIGNsYWZpcnkgdGhlc2UgcXVlc3Rpb25zIGJlbG93OjwvZm9u dD4gPGJyPgo8YnI+PGZvbnQgc2l6ZT0iMiI+MaGiV2hpY2ggd2F5IHdvdWxkIHRoZSBzZXJ2ZXIg YXNzaWduIHRoZSByb3V0aW5nIHRhYmxlIHRvIHRoZSB0ZXJtaW5hbCBieT88L2ZvbnQ+IDwvYmxv Y2txdW90ZT4KPGRpdj49PSZndDtUaGVyZSBhcmUgbXVsdGlwbGUgd2F5IGNvdWxkIGRvIHRoaXMs IGluIHRoZSBtb2JpbGUgYWNjZXNzIG5ldHdvcmsgLCBBTkRTRiwgREhDUCwgSUtFIGV0IGFsLjwv ZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVS LUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj48c3BhbiBpZD0iIj48L3NwYW4+PGJyPjxmb250IHNpemU9 IjIiPjKhokFzc3VtaW5nIHF1ZXN0aW9uIDEgaXMgZG9uZSwgaG93IHRvIGRlY2lkZSB3aGljaCBn YXRld2F5IHRvIGFzc2lnbiB0aGUgdGVybWluYWwmIzM5O3Mgcm91dGluZyBzdHJhdGVneSBpbiBh IG11bHRpLWNvbm5lY3Rpb24gZW52aXJvbm1lbnQ/IEFuZCBob3cgY2FuIHRoaXMgZ2F0ZXdheSBr bm93IGFib3V0IHRoZSB3aG9sZSBjb25uZWN0aW9uIGVudmlyb25tZW50o788L2ZvbnQ+IDwvYmxv Y2txdW90ZT4KCjxkaXY+PT0mZ3Q7IGl0Jm5ic3A7Y291bGQgcmVseSBvbiZuYnNwO0lTUCYjMzk7 cyBwb2xpY3kgc3RyYXRlZ3kuIGFueXdheSwgaXQgaXMgYSBwb2ludCB0byBiZSBzb2x2ZWQgZm9y IGNvb3JkaW5hdGlvbi48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAw cHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+PHNwYW4gaWQ9IiI+PC9zcGFu Pjxicj48Zm9udCBzaXplPSIyIj4zoaJBc3N1bWluZyBxdWVzdGlvbiAyIGNhbiBiZSBzb2x2ZWQg aW4gdGhlIHdheSB0aGF0IHRoZSBjb3JyZXNwb25kaW5nIGdhdGV3YXkgb2YgZWFjaCBjb25uZWN0 aW9uIGFzc2lnbnMgaXRzIG93biByb3V0aW5nIHN0cmF0ZWd5IGZvciB0aGUgdGVybWluYWwsIHRo ZW4gdGhlIHRlcm1pbmFsIG5lZWRzIHRvIG1ha2UgYSBzdHJhdGVneSBwcmlvcml0eSBmaWx0ZXJp bmcgbWVjaGFuaXNtLiBUaGUgbmV3IHByb2JsZW0gcmVzdWx0aW5nIGZyb20gdGhpcyBzb2x1dGlv biBpcyB0aGF0IHRoaXMgbWVjaGFuaXNtIGFsc28gbmVlZHMgdG8gYmUgZGVmaW5lZC4gPC9mb250 PjwvYmxvY2txdW90ZT4KCjxkaXY+PT0mZ3Q7IHNvbWUgdGltZSwgbW9iaWxlIHRlcm1pbmFsIGNv dWxkIHNlbGVjdCBiYXNlZCBvbiBzZXZlcmFsIG9wdGlvbnMsIGJ1dCBub3QgYWxsIHN1YnNjcmli ZXIgYXJlIHNtYXJ0IGxpa2UgdGhhdCwgYW55d2F5LCBib3RoIHNvbHV0aW9uIHNob3VsZCBiZSBj b25zaWRlcmVkLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAw LjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj48c3BhbiBpZD0iIj48L3NwYW4+PGJy Pjxmb250IHNpemU9IjIiPklmIGFsbCB0aGVzZSBxdWVzdGlvbnMgYXJlIHNvbHZlZCwgc21hcnQg cGhvbmUgc2hvdWxkIGJlIGFibGUgdG8gcmVhbGl6ZSBpdCwgb25seSBzb21lIHByb2JsZW0sIGFz IHlvdSBrbm93LCBtaWdodCBvY2N1ciBpbiBmZWF0dXJlIHBob25lLjwvZm9udD4gPC9ibG9ja3F1 b3RlPgoKPGRpdj49PSZndDsgVGhhbmtzIGZvciB5b3VyIGRpc2N1c3Npb24sIGZlYXR1cmUgcGhv bmUgc3RpbGwgaGF2ZSBzb21lIGlzc3VlLCBzbWFydCBwaG9uZSBpcyBiZXN0IGhvc3QgZmFjaW5n IHRoaXMgY2hhbGxlbmdlcyw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5QbGVhc2UgZmVl bCBmcmVlIHRvIHJhaXNlIHlvdXIgcXVlc3Rpb24gYW5kIHNvbHV0aW9uLjwvZGl2Pgo8ZGl2PiZu YnNwOzwvZGl2Pgo8ZGl2PnRoYW5rcyBhZ2FpbjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2 Pi1IdWk8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7 IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+PHNwYW4gaWQ9IiI+PC9zcGFuPjxicj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5taWYgbWFpbGlu ZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciPm1pZkBpZXRmLm9yZzwvYT48 YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8 L2E+PGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_249983_5691455.1231900326345-- --===============0341960566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0341960566==-- From mif-bounces@ietf.org Wed Jan 14 03:38:00 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405193A6827; Wed, 14 Jan 2009 03:38:00 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8C43A63EC for ; Wed, 14 Jan 2009 03:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.666 X-Spam-Level: * X-Spam-Status: No, score=1.666 tagged_above=-999 required=5 tests=[AWL=2.076, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFkg+VBT2KmC for ; Wed, 14 Jan 2009 03:37:57 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id CCFF43A6827 for ; Wed, 14 Jan 2009 03:37:56 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 14 Jan 2009 20:37:41 +0900 X-ReadCheckMessageID: X-ReadCheckName: mif%40ietf.org From: "Hong Yong-Geun" To: "Hui Deng" Date: Wed, 14 Jan 2009 20:37:40 +0900 Priority: normal Comment: ??, u-??, Content-Class: urn:content-classes:message Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 in-reply-to: <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif thread-index: Acl1zSlUK5kHQadQSqO1HyASSMYVUwAa9RfAAADhFlk= References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> X-OriginalArrivalTime: 14 Jan 2009 11:37:41.0089 (UTC) FILETIME=[822D4510:01C9763C] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584694549==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1584694549== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9763B.9B742D00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9763B.9B742D00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C9763B.9B742D00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTr prwiPg0KPERJVj4mbmJzcDsmbmJzcDsgPCEtLSBzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTeXN0ZW07DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1w aXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDE1MTM4ODE2MCAxNiAwIDUyNDI4OCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk66rW066a8Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxOw0KCW1zby1mb250 LWFsdDpHdWxpbTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFu Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTYxMDYx MTk4NSAxMTA3MzA0NjgzIDAgMCAxNTkgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLr p5HsnYAg6rOg65SVIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDsNCgltc28tZm9u dC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xODc5MDQ3NTA1IDE2NTEx NzE3OSAxOCAwIDUyNDI4OSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA6rW066a8 IjsNCglwYW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEy OTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFy aWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1 MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOunkeydgCDqs6DrlJUiOw0K CXBhbm9zZS0xOjIgMTEgNSAzIDIgMCAwIDIgMCA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTI5Ow0K CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTE4NzkwNDc1MDUgMTY1MTE3MTc5IDE4IDAgNTI0Mjg5 IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25h dHVyZToxNjI3NDAwODM5IC0yMTQ3NDgzNjQ4IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU3lzdGVtIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0K CW1zby1mb250LWNoYXJzZXQ6MTI5Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJ bXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmF1dG87DQoJbXNvLWZvbnQt c2lnbmF0dXJlOjEgMTUxMzg4MTYwIDE2IDAgNTI0Mjg4IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFy ZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Iuunkeyd gCDqs6DrlJUiOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFzdDt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRl cmxpbmU6c2luZ2xlO30NCnANCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1w YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Iuun keydgCDqs6DrlJUiOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFzdDt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1z by1zdHlsZS1xZm9ybWF0OnllczsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjQwLjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJbXNvLXBhcmEtbWFyZ2luLXRvcDowY207DQoJbXNvLXBhcmEtbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOjBjbTsNCgltc28tcGFyYS1tYXJn aW4tbGVmdDo0LjBnZDsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBh Z2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToi66eR 7J2AIOqzoOuUlSI7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1mYXJlYXN0O30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiLr p5HsnYAg6rOg65SVIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0K CW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWZhcmVh c3Q7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28taGFuc2kt dGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7DQoJY29sb3I6IzFGNDk3 RDsNCgltc28tdGhlbWVjb2xvcjpkYXJrMjt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFt ZToiIjsNCgltc28tc3BsLWU6eWVzO30NCnNwYW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7 DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCW1zby1hc2NpaS1mb250LWZhbWls eToi66eR7J2AIOqzoOuUlSI7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktdGhlbWUt Zm9udDptaW5vci1iaWRpO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjozLjBjbSA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsNCgltc28taGVhZGVyLW1hcmdp bjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6 MDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI0NjQ5NjY1NzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1OTQzMDM3NzAgLTgwMzE0NzM4NCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oj87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjIxLjc1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUi Ow0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFzdDsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJp ZGk7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9TVFlMRSAtLT4NCjxESVYgbGFuZz1LTyBzdHlsZT0idGFiLWludGVydmFsOiA0MC4w cHQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPERJViBjbGFzcz1TZWN0aW9uMT4NCjxQ IGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1m b250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1m b250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1z by1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9u dDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5IaTxTUEFOIGNsYXNzPUdyYW1F Pi4uPC9TUEFOPjxTUEFOIGNsYXNzPVNwZWxsRT5IdWk8L1NQQU4+PFNQQU4gY2xhc3M9R3JhbUU+ Li48L1NQQU4+PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gbnMgPSAidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1mb250 OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDog bWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+VGhhbmsgeW91 IGZvciBjb21tZW50cy4gU2VlIGJlbG93IGlubGluZSByZXBseS48bzpwPjwvbzpwPjwvU1BBTj48 L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNv LWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRp bjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3Qt dGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxh dGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRo ZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2A IOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7 IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1m b250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n OyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIi PkJlc3QgcmVnYXJkcy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7 IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFz dDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1z by10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQt c2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6 IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJp ZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBt aW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPllvbmctR2V1bjxTUEFOIGNsYXNzPUdy YW1FPi4uPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsg bXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0 OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNv LXRoZW1lY29sb3I6IGRhcmsyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWIHN0 eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RU T006IDBjbTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPkZy b206PC9TUEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJyI+IEh1aSBEZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGdtYWlsLmNv bV0gPEJSPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEphbnVhcnkgMTQsIDIwMDkgNzoyMCBBTTxC Uj48Qj5Ubzo8L0I+IDwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTog6rW066a8OyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8Ij7tmY3smqnqt7w8L1NQ QU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbiciPjxCUj48Qj5DYzo8L0I+IG1pZkBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4g UmU6IFttaWZdIG1vYmlsaXR5IGlzc3VlcyBhbmQgZ2VuZXJhbCBpc3N1ZXMgb24gbWlmPG86cD48 L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4t VVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiBsYW5nPUVOLVVTPkhpLCBIb25nIFlvbmcsPG86cD48L286cD48L1NQQU4+PC9QPjwv RElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPiZuYnNwOzxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gbGFuZz1FTi1VUz5JIHJlYWQgdGhyb3VnaCB5b3VyIHR3byBkcmFmdHMsIHVuZGVyc3RhbmQg eW91IGFyZSB0YWxraW5nIHRoZSBpc3N1ZSZuYnNwO3dpdGhvdXQgPFNQQU4gY2xhc3M9U3BlbGxF Pk1vbmFtaTwvU1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IG1zby10aGVtZWNvbG9y OiBkYXJrMiI+PG86cD48L286cD48L1NQQU4+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0xpc3RQ YXJhZ3JhcGggc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQ7 IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAwZ2Q7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9O VC1GQU1JTFk6IFdpbmdkaW5nczsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBXaW5nZGlu Z3M7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUi Pj88U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsgPC9TUEFO PjwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9u dDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28t YmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6 IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+WWVzLCB5b3UgYXJlIGNvcnJlY3Qu IDxCUj5JIHdhbnQgdG8gc29sdmUgdGhlIG11bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyB3aXRo b3V0IG1vZGlmeWluZyBNb2JpbGUgSVB2Ni9ORU1PIGNvZGUuPEJSPihJbiBNb25hbWk2LCBtdWx0 aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgKHdoaWNoJm5ic3A7YXJlIHJlbGF0ZWQgdG8gbW9iaWxp dHkgaXNzdWVzLCBzdWNoIGFzIG11bHRpcGxlIDxTUEFOIGNsYXNzPVNwZWxsRT5Db0E8L1NQQU4+ LDxCUj5tdWx0aXBsZSA8U1BBTiBjbGFzcz1TcGVsbEU+SG9BPC9TUEFOPiwgZXRjLiwgKSBhcmUg cmVzb2x2aW5nIGJ5IG1vZGlmeWluZyBNb2JpbGUgSVB2Ni9ORU1PIHByb3RvY29sKTxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxCUj48 U1BBTiBjbGFzcz1HcmFtRT5pdDwvU1BBTj4gc2VlbXMgTW9iaWxlIElwdjYgaW50ZXJuYWwgYWxz byBoYXMgc2ltaWxhciBpc3N1ZSB3aXRoIHVzIGlmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHks IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9 Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQ7IG1zby1wYXJhLW1hcmdp bi1sZWZ0OiAwZ2Q7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFdpbmdk aW5nczsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiBXaW5nZGluZ3M7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7IG1zby10aGVtZWNv bG9yOiBkYXJrMiI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPj88U1BBTiBzdHlsZT0i Rk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7 IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFz dDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1z by10aGVtZWNvbG9yOiBkYXJrMiI+WWVzLCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJhc2VkIG9u IHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2NiwgTW9iaWxlIElQdjYgaW50ZXJuYWw8QlI+PFNQ QU4gY2xhc3M9R3JhbUU+aGFzPC9TUEFOPiBzaW1pbGFyIGlzc3VlcyBvZiA8U1BBTiBjbGFzcz1T cGVsbEU+bWlmPC9TUEFOPi4gU28sIEkgdGhpbmsgdGhhdCBpdCBpcyB2YWx1YWJsZSB0byBzZXBh cmF0ZSBtb3JlIGdlbmVyYWwgaXNzdWVzIGZyb208QlI+PFNQQU4gY2xhc3M9R3JhbUU+bXVsdGlw bGU8L1NQQU4+IGludGVyZmFjZSBpc3N1ZXMgd2hpY2ggYXJlIGRpcmVjdGx5IHJlbGF0ZWQgdG8g TW9iaWxlIElQdjYvTkVNTy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4w cHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFy ZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7 IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjwvRElW Pg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPkluIHRoaXMgY2Fz ZSBJIHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHlvdSB0byBwcm9wb3NlIHRoaXMgaXNzdWUgdG8g b3VyIHdvcmssIGlmIGFsbG93ZWQsPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4N CjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBjbGFzcz1HcmFtRT48U1BBTiBsYW5nPUVOLVVTPml0 PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPiBtaWdodGJlIGRvYWJsZSB3aXRoaW4gb3Vy IHNjb3BlLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQ7IG1zby1wYXJh LW1hcmdpbi1sZWZ0OiAwZ2Q7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6 IFdpbmdkaW5nczsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiBXaW5nZGluZ3M7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7IG1zby10 aGVtZWNvbG9yOiBkYXJrMiI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPj88U1BBTiBz dHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsgPC9TUEFOPjwvU1BBTj48 L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAx MS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3It ZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJp ZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+VGhhbmtzLiBJdCBpcyBteSBwbGVhc3VyZS4uPC9T UEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1V Uz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+bWFueSB0aGFua3M8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiBsYW5nPUVOLVVTPi1IdWk8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+MjAwOS8xLzcgSG9uZyBZb25nLUdl dW4gJmx0OzxBIGhyZWY9Im1haWx0bzp5Z2hvbmdAZXRyaS5yZS5rciI+eWdob25nQGV0cmkucmUu a3I8L0E+Jmd0OzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxQ PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5 c3RlbSI+SGkuIG1pZi4uPEJSPjxCUj5MZXQgbWUgam9pbiB0aGlzIGRpc2N1c3Npb24uPEJSPjxC Uj5JdCBpcyB2ZXJ5IGludGVyZXN0aW5nIHRvIHNlZSBtaWYuPEJSPjxCUj5BcyBIdWkgRGVuZyBz YXlzLCBJIHVuZGVyc3RhbmQgdGhhdCBtaWYgaGFzIGRpZmZlcmVudCBhcHByb2FjaDxCUj5mcm9t IG90aGVyIFdHIHN1Y2ggYXMgTUVYVCBhbmQgbW9uYW1pNiBXRywgZXRjLjxCUj48QlI+SW4gTUVY VCwgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgYXJlIHJlbGF0ZWQgdG8gTW9iaWxlIElQLCBO RU1PLC4uPEJSPkluIG1pZiwgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgYXJlIGRpZmZlcmVu dCBmcm9tIHRob3NlIG9mIE1FWFQuPEJSPlNvLCBpbiBtaWYsIGl0IGlzIGJldHRlciB0byBmaW5k IG1vcmUgZ2VuZXJhbCBpc3N1ZXMgd2hpY2ggYXJlIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUC48 QlI+PEJSPkkgdGhpbmsgdGhhdCBNLkJsYW5jaGV0J3MgIk11bHRpcGxlIEludGVyZmFjZXMgUHJv YmxlbSBTdGF0ZW1lbnQiIGRyYWZ0IGlzPEJSPmEgZ29vZCBzdGFydGluZyBwb2ludCB0byBkaXNj dXNzIGdlbmVyYWwgaXNzdWVzIG9uIG1pZi48QlI+PEJSPkkgd291bGQgbGlrZSB0byBpbnRyb2R1 Y2UgYW5vdGhlciByZWxhdGVkIGRyYWZ0cyB3aGljaCBJIHByZXNlbnRlZCBhdCBtb25hbWk2IFdH IGF0IDY0dGggSUVURiBtZWV0aW5nLjxCUj48QlI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPi0gQW5hbHlzaXMg b2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlKGRyYWZ0LWhvbmctbXVsdGlw bGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDApPEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1h c2NpaS1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4gPEEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2RyYWZ0L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0 ZW1lbnQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMC50eHQiIHRhcmdl dD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2RyYWZ0L2RyYWZ0LWhvbmctbXVsdGlwbGVp Zi1tbi1wYi1zdGF0ZW1lbnQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0w MC50eHQ8L0E+PEJSPjxCUj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtOyBtc28tYXNjaWktZm9udC1m YW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+LSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJm YWNlIGZvciBtdWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUgdXNpbmcgTW9iaWxl IElQdjY8QlI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBT eXN0ZW0iPiZuYnNwOyZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiAoZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4t bWlwdjYtMDApPEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1hc2NpaS1mb250LWZhbWls eTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4gPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2RyYWZ0L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2LTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv ZHJhZnQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYvZHJhZnQtaG9uZy12aXJ0dWFsaWYt bW4tbWlwdjYtMDAudHh0PC9BPjxCUj48QlI+PEJSPkluIHRoZSBzZWN0aW9uIDIuMiAoR2VuZXJh bCBOZXR3b3JrIElzc3VlcykgaW4gdGhlIGZpcnN0IGRyYWZ0LDxCUj50aGVyZSBhcmUgZ2VuZXJh bCBuZXR3b3JrIGlzc3VlcyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcy48QlI+PEJSPkluY2x1 ZGluZyB0aGVzZSBkcmFmdHMsIEkgaG9wZSB0byBlbmNvdXJhZ2UgdGhpcyBkaXNjdXNzaW9uPEJS PjxCUj5Zb25nLUdldW4uPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPjwvRElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0Ij48U1BBTiBsYW5n PUVOLVVTPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj5taWYgbWFpbGluZyBsaXN0PEJSPjxBIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciIHRh cmdldD1fYmxhbms+bWlmQGlldGYub3JnPC9BPjxCUj48QSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZjwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+ DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25l IiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxf UmVhZENoZWNrLmFzcHg/ZW1haWw9bWlmQGlldGYub3JnJm5hbWU9bWlmJTQwaWV0Zi5vcmcmZnJv bWVtYWlsPXlnaG9uZ0BldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0NhZWUwZTk0OC1kZTM5LTQzMzUt OGZiZi04YzY1MWExNzIzNDNAZXRyaS5yZS5rciUzRSI+ ------_=_NextPart_001_01C9763B.9B742D00-- --===============1584694549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1584694549==-- From mif-bounces@ietf.org Wed Jan 14 22:47:28 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA1E3A6999; Wed, 14 Jan 2009 22:47:28 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC9D3A6999 for ; Wed, 14 Jan 2009 22:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQALnjccyfRG for ; Wed, 14 Jan 2009 22:47:26 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 378383A6984 for ; Wed, 14 Jan 2009 22:47:25 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so518554wag.5 for ; Wed, 14 Jan 2009 22:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=9CRiFaEcfwHs1SNqDxr3v6yor6GL8ebyFqprjfEMElg=; b=mBuIjwMZL8wVTnLTK1q3kVlXScd4sqqGqJ/Ni/ExDkhM+mvAcLFiE5FgmkH6JpTpyc bD2QRWKeE1fYjjcAVA1HsWyQIx1V1xDDymVExRGDCxvU/GYeFkTqf4Rg6JjjDBD+XhPU evGHBXU7Cc21xbkBhcfP5QXIvt2IhNfYlA1mw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=YMlWBHl9vjpyIX7YL/On7Bz5E8JfIgm63//oW9MR7RlWCKm5lZfWz5VvzfoLNwC6Yv 5Mmjwy5hKbpkB135BgbyPXriYVh4h8BVD4scr9t15RJlelbqGEE/d8jGCJP1oy4+HV5G qYutDi8PrKL1HbGFpHtspHLt0dlZ0+X62ZHsI= Received: by 10.115.46.10 with SMTP id y10mr670215waj.33.1232002029798; Wed, 14 Jan 2009 22:47:09 -0800 (PST) Received: by 10.115.58.3 with HTTP; Wed, 14 Jan 2009 22:47:09 -0800 (PST) Message-ID: <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> Date: Wed, 14 Jan 2009 23:47:09 -0700 From: "Hui Deng" To: "Hong Yong-Geun" In-Reply-To: MIME-Version: 1.0 References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412228488==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0412228488== Content-Type: multipart/alternative; boundary="----=_Part_261542_2402905.1232002029787" ------=_Part_261542_2402905.1232002029787 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline eW91IGFscmVhZHkgaGFkIGEgZGlzY3Vzc2lvbiB3aXRoIG1leHQgd2csIHRoZXkgYXJlIG5vdCBh ZG9wdGluZyB0aGlzIHdvcms/CgotSHVpCgoyMDA5LzEvMTQgSG9uZyBZb25nLUdldW4gPHlnaG9u Z0BldHJpLnJlLmtyPgoKPgo+Cj4gSGkuLkh1aS4uCj4KPgo+Cj4gVGhhbmsgeW91IGZvciBjb21t ZW50cy4gU2VlIGJlbG93IGlubGluZSByZXBseS4KPgo+Cj4KPiBCZXN0IHJlZ2FyZHMuCj4KPgo+ Cj4gWW9uZy1HZXVuLi4KPgo+Cj4KPiAqRnJvbToqIEh1aSBEZW5nIFttYWlsdG86ZGVuZ2h1aTAy QGdtYWlsLmNvbV0KPiAqU2VudDoqIFdlZG5lc2RheSwgSmFudWFyeSAxNCwgMjAwOSA3OjIwIEFN Cj4gKlRvOiogyKu/67HZCj4gKkNjOiogbWlmQGlldGYub3JnCj4gKlN1YmplY3Q6KiBSZTogW21p Zl0gbW9iaWxpdHkgaXNzdWVzIGFuZCBnZW5lcmFsIGlzc3VlcyBvbiBtaWYKPgo+Cj4KPiBIaSwg SG9uZyBZb25nLAo+Cj4KPgo+IEkgcmVhZCB0aHJvdWdoIHlvdXIgdHdvIGRyYWZ0cywgdW5kZXJz dGFuZCB5b3UgYXJlIHRhbGtpbmcgdGhlCj4gaXNzdWUgd2l0aG91dCBNb25hbWkKPgo+ID8gIFll cywgeW91IGFyZSBjb3JyZWN0Lgo+IEkgd2FudCB0byBzb2x2ZSB0aGUgbXVsdGlwbGUgaW50ZXJm YWNlIHByb2JsZW1zIHdpdGhvdXQgbW9kaWZ5aW5nIE1vYmlsZQo+IElQdjYvTkVNTyBjb2RlLgo+ IChJbiBNb25hbWk2LCBtdWx0aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgKHdoaWNoIGFyZSByZWxh dGVkIHRvIG1vYmlsaXR5Cj4gaXNzdWVzLCBzdWNoIGFzIG11bHRpcGxlIENvQSwKPiBtdWx0aXBs ZSBIb0EsIGV0Yy4sICkgYXJlIHJlc29sdmluZyBieSBtb2RpZnlpbmcgTW9iaWxlIElQdjYvTkVN Two+IHByb3RvY29sKQo+Cj4KPiBpdCBzZWVtcyBNb2JpbGUgSXB2NiBpbnRlcm5hbCBhbHNvIGhh cyBzaW1pbGFyIGlzc3VlIHdpdGggdXMgaWYgSQo+IHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LAo+ Cj4gPyAgWWVzLCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJhc2VkIG9uIHRoZSBiYXNpYyBvcGVy YXRpb24gb2YgSVB2NiwKPiBNb2JpbGUgSVB2NiBpbnRlcm5hbAo+IGhhcyBzaW1pbGFyIGlzc3Vl cyBvZiBtaWYuIFNvLCBJIHRoaW5rIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8gc2VwYXJhdGUKPiBt b3JlIGdlbmVyYWwgaXNzdWVzIGZyb20KPiBtdWx0aXBsZSBpbnRlcmZhY2UgaXNzdWVzIHdoaWNo IGFyZSBkaXJlY3RseSByZWxhdGVkIHRvIE1vYmlsZSBJUHY2L05FTU8uCj4KPgo+Cj4gSW4gdGhp cyBjYXNlIEkgd291bGQgbGlrZSB0byBlbmNvdXJhZ2UgeW91IHRvIHByb3Bvc2UgdGhpcyBpc3N1 ZSB0byBvdXIKPiB3b3JrLCBpZiBhbGxvd2VkLAo+Cj4gaXQgbWlnaHRiZSBkb2FibGUgd2l0aGlu IG91ciBzY29wZSwKPgo+ID8gIFRoYW5rcy4gSXQgaXMgbXkgcGxlYXN1cmUuLgo+Cj4KPgo+IG1h bnkgdGhhbmtzCj4KPgo+Cj4gLUh1aQo+Cj4gMjAwOS8xLzcgSG9uZyBZb25nLUdldW4gPHlnaG9u Z0BldHJpLnJlLmtyPgo+Cj4gSGkuIG1pZi4uCj4KPiBMZXQgbWUgam9pbiB0aGlzIGRpc2N1c3Np b24uCj4KPiBJdCBpcyB2ZXJ5IGludGVyZXN0aW5nIHRvIHNlZSBtaWYuCj4KPiBBcyBIdWkgRGVu ZyBzYXlzLCBJIHVuZGVyc3RhbmQgdGhhdCBtaWYgaGFzIGRpZmZlcmVudCBhcHByb2FjaAo+IGZy b20gb3RoZXIgV0cgc3VjaCBhcyBNRVhUIGFuZCBtb25hbWk2IFdHLCBldGMuCj4KPiBJbiBNRVhU LCBtdWx0aXBsZSBpbnRlcmZhY2VzIGlzc3VlcyBhcmUgcmVsYXRlZCB0byBNb2JpbGUgSVAsIE5F TU8sLi4KPiBJbiBtaWYsIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGFyZSBkaWZmZXJlbnQg ZnJvbSB0aG9zZSBvZiBNRVhULgo+IFNvLCBpbiBtaWYsIGl0IGlzIGJldHRlciB0byBmaW5kIG1v cmUgZ2VuZXJhbCBpc3N1ZXMgd2hpY2ggYXJlIG5vdCByZWxhdGVkCj4gdG8gTW9iaWxlIElQLgo+ Cj4gSSB0aGluayB0aGF0IE0uQmxhbmNoZXQncyAiTXVsdGlwbGUgSW50ZXJmYWNlcyBQcm9ibGVt IFN0YXRlbWVudCIgZHJhZnQgaXMKPiBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgdG8gZGlzY3VzcyBn ZW5lcmFsIGlzc3VlcyBvbiBtaWYuCj4KPiBJIHdvdWxkIGxpa2UgdG8gaW50cm9kdWNlIGFub3Ro ZXIgcmVsYXRlZCBkcmFmdHMgd2hpY2ggSSBwcmVzZW50ZWQgYXQKPiBtb25hbWk2IFdHIGF0IDY0 dGggSUVURiBtZWV0aW5nLgo+Cj4gIC0gQW5hbHlzaXMgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBp biBhIE1vYmlsZQo+IE5vZGUoZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0w MCkKPgo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYt bW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAu dHh0Cj4KPiAgLSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGZvciBtdWx0aXBsZSBpbnRlcmZh Y2VzIGluIGEgTW9iaWxlIG5vZGUKPiB1c2luZyBNb2JpbGUgSVB2Ngo+ICAgIChkcmFmdC1ob25n LXZpcnR1YWxpZi1tbi1taXB2Ni0wMCkKPgo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9k cmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2 Ni0wMC50eHQKPgo+Cj4gSW4gdGhlIHNlY3Rpb24gMi4yIChHZW5lcmFsIE5ldHdvcmsgSXNzdWVz KSBpbiB0aGUgZmlyc3QgZHJhZnQsCj4gdGhlcmUgYXJlIGdlbmVyYWwgbmV0d29yayBpc3N1ZXMg ZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMuCj4KPiBJbmNsdWRpbmcgdGhlc2UgZHJhZnRzLCBJ IGhvcGUgdG8gZW5jb3VyYWdlIHRoaXMgZGlzY3Vzc2lvbgo+Cj4gWW9uZy1HZXVuLgo+Cj4KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG1pZiBtYWls aW5nIGxpc3QKPiBtaWZAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pZgo+Cj4KPgo= ------=_Part_261542_2402905.1232002029787 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj55b3UgYWxyZWFkeSBoYWQgYSBkaXNjdXNzaW9uIHdpdGggbWV4dCB3ZywgdGhleSBhcmUg bm90IGFkb3B0aW5nIHRoaXMgd29yaz88L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4tSHVp PGJyPjxicj48L2Rpdj4KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMDkvMS8xNCBIb25nIFlv bmctR2V1biA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp5Z2hvbmdAZXRyaS5y ZS5rciI+eWdob25nQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj48YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAw cHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPgo8ZGl2IHN0eWxlPSJG T05ULVNJWkU6IDEwcHQiPgo8ZGl2PiZuYnNwOyZuYnNwOyAKPGRpdiBsYW5nPSJLTyIgdmxpbms9 InB1cnBsZSIgbGluaz0iYmx1ZSI+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+SGk8c3Bhbj4uLjwvc3Bhbj48c3Bhbj5I dWk8L3NwYW4+PHNwYW4+Li48L3NwYW4+PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj4mbmJzcDs8L3NwYW4+PC9w Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMx ZjQ5N2QiPlRoYW5rIHlvdSBmb3IgY29tbWVudHMuIFNlZSBiZWxvdyBpbmxpbmUgcmVwbHkuPC9z cGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiAjMWY0OTdkIj4mbmJzcDs8L3NwYW4+PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2QiPkJlc3QgcmVnYXJkcy48L3NwYW4+ PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 ICMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48L3A+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+WW9uZy1HZXVuPHNwYW4+Li48L3NwYW4+ PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiAjMWY0OTdkIj4mbmJzcDs8L3NwYW4+PC9wPgo8ZGl2IHN0eWxlPSJCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYg MXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006IDBjbTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZSI+CjxwPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPiBIdWkgRGVuZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGVuZ2h1aTAyQGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE0LCAyMDA5IDc6MjAgQU08YnI+CjxiPlRvOjwvYj4gPC9z cGFuPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPsirv+ux2Twvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pZkBpZXRmLm9yZzwvYT48YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBbbWlmXSBtb2JpbGl0eSBpc3N1ZXMgYW5kIGdlbmVyYWwgaXNz dWVzIG9uIG1pZjwvc3Bhbj48L3A+CjwvZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjwvcD4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCBIb25nIFlvbmcsPC9z cGFuPjwvcD48L2Rpdj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 L3A+PC9kaXY+CjxkaXY+CjxkaXYgY2xhc3M9IkloMkUzZCI+CjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIHJlYWQgdGhyb3VnaCB5b3VyIHR3byBkcmFmdHMsIHVuZGVyc3RhbmQgeW91IGFyZSB0YWxr aW5nIHRoZSBpc3N1ZSZuYnNwO3dpdGhvdXQgPHNwYW4+TW9uYW1pPC9zcGFuPjxzcGFuIHN0eWxl PSJDT0xPUjogIzFmNDk3ZCI+PC9zcGFuPjwvc3Bhbj48L3A+PC9kaXY+CjxwIHN0eWxlPSJNQVJH SU4tTEVGVDogMjEuNzVwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBXaW5n ZGluZ3MiPjxzcGFuPj88c3BhbiBzdHlsZT0iRk9OVDogN3B0ICYjMzk7VGltZXMgTmV3IFJvbWFu JiMzOTsiPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2QiPlllcywgeW91IGFyZSBjb3JyZWN0 LiA8YnI+Ckkgd2FudCB0byBzb2x2ZSB0aGUgbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIHdp dGhvdXQgbW9kaWZ5aW5nIE1vYmlsZSBJUHY2L05FTU8gY29kZS48YnI+KEluIE1vbmFtaTYsIG11 bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyAod2hpY2gmbmJzcDthcmUgcmVsYXRlZCB0byBtb2Jp bGl0eSBpc3N1ZXMsIHN1Y2ggYXMgbXVsdGlwbGUgPHNwYW4+Q29BPC9zcGFuPiw8YnI+bXVsdGlw bGUgPHNwYW4+SG9BPC9zcGFuPiwgZXRjLiwgKSBhcmUgcmVzb2x2aW5nIGJ5IG1vZGlmeWluZyBN b2JpbGUgSVB2Ni9ORU1PIHByb3RvY29sKTwvc3Bhbj48L3A+Cgo8ZGl2IGNsYXNzPSJJaDJFM2Qi Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPjxzcGFuPml0PC9zcGFuPiBzZWVtcyBNb2JpbGUg SXB2NiBpbnRlcm5hbCBhbHNvIGhhcyBzaW1pbGFyIGlzc3VlIHdpdGggdXMgaWYgSSB1bmRlcnN0 YW5kIGl0IGNvcnJlY3RseSwgPC9zcGFuPjwvcD48L2Rpdj4KPHAgc3R5bGU9Ik1BUkdJTi1MRUZU OiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5ncyI+ PHNwYW4+PzxzcGFuIHN0eWxlPSJGT05UOiA3cHQgJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OyI+ Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+WWVzLCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlz IGJhc2VkIG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2NiwgTW9iaWxlIElQdjYgaW50ZXJu YWw8YnI+CjxzcGFuPmhhczwvc3Bhbj4gc2ltaWxhciBpc3N1ZXMgb2YgPHNwYW4+bWlmPC9zcGFu Pi4gU28sIEkgdGhpbmsgdGhhdCBpdCBpcyB2YWx1YWJsZSB0byBzZXBhcmF0ZSBtb3JlIGdlbmVy YWwgaXNzdWVzIGZyb208YnI+PHNwYW4+bXVsdGlwbGU8L3NwYW4+IGludGVyZmFjZSBpc3N1ZXMg d2hpY2ggYXJlIGRpcmVjdGx5IHJlbGF0ZWQgdG8gTW9iaWxlIElQdjYvTkVNTy48L3NwYW4+PC9w PgoKPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAj MWY0OTdkIj4mbmJzcDs8L3NwYW4+PC9wPjwvZGl2Pgo8ZGl2IGNsYXNzPSJJaDJFM2QiPgo8ZGl2 Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhpcyBjYXNlIEkgd291bGQgbGlrZSB0byBlbmNv dXJhZ2UgeW91IHRvIHByb3Bvc2UgdGhpcyBpc3N1ZSB0byBvdXIgd29yaywgaWYgYWxsb3dlZCw8 L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pgo8ZGl2Pgo8ZGl2IGNsYXNzPSJJaDJFM2QiPgo8cD48c3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+aXQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4g bWlnaHRiZSBkb2FibGUgd2l0aGluIG91ciBzY29wZSw8L3NwYW4+PC9wPjwvZGl2Pgo8cCBzdHls ZT0iTUFSR0lOLUxFRlQ6IDIxLjc1cHQ7IFRFWFQtSU5ERU5UOiAtMThwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlM WTogV2luZ2RpbmdzIj48c3Bhbj4/PHNwYW4gc3R5bGU9IkZPTlQ6IDdwdCAmIzM5O1RpbWVzIE5l dyBSb21hbiYjMzk7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5UaGFua3MuIEl0IGlz IG15IHBsZWFzdXJlLi48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPGRpdj48L2Rpdj4KPGRpdiBj bGFzcz0iV2ozQzdjIj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 L3A+PC9kaXY+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5tYW55IHRoYW5rczwvc3Bhbj48 L3A+PC9kaXY+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPjwv ZGl2Pgo8ZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyI+LUh1aTwvc3Bhbj48L3A+PC9kaXY+Cjxk aXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4yMDA5LzEvNyBIb25nIFlvbmctR2V1biAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJnZXQ9Il9ibGFuayI+eWdob25nQGV0 cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj48L3A+CjxkaXY+CjxkaXY+CjxkaXY+CjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5I aS4gbWlmLi48YnI+PGJyPkxldCBtZSBqb2luIHRoaXMgZGlzY3Vzc2lvbi48YnI+PGJyPkl0IGlz IHZlcnkgaW50ZXJlc3RpbmcgdG8gc2VlIG1pZi48YnI+PGJyPkFzIEh1aSBEZW5nIHNheXMsIEkg dW5kZXJzdGFuZCB0aGF0IG1pZiBoYXMgZGlmZmVyZW50IGFwcHJvYWNoPGJyPgpmcm9tIG90aGVy IFdHIHN1Y2ggYXMgTUVYVCBhbmQgbW9uYW1pNiBXRywgZXRjLjxicj48YnI+SW4gTUVYVCwgbXVs dGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgYXJlIHJlbGF0ZWQgdG8gTW9iaWxlIElQLCBORU1PLC4u PGJyPkluIG1pZiwgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgYXJlIGRpZmZlcmVudCBmcm9t IHRob3NlIG9mIE1FWFQuPGJyPlNvLCBpbiBtaWYsIGl0IGlzIGJldHRlciB0byBmaW5kIG1vcmUg Z2VuZXJhbCBpc3N1ZXMgd2hpY2ggYXJlIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUC48YnI+Cjxi cj5JIHRoaW5rIHRoYXQgTS5CbGFuY2hldCYjMzk7cyAmcXVvdDtNdWx0aXBsZSBJbnRlcmZhY2Vz IFByb2JsZW0gU3RhdGVtZW50JnF1b3Q7IGRyYWZ0IGlzPGJyPmEgZ29vZCBzdGFydGluZyBwb2lu dCB0byBkaXNjdXNzIGdlbmVyYWwgaXNzdWVzIG9uIG1pZi48YnI+PGJyPkkgd291bGQgbGlrZSB0 byBpbnRyb2R1Y2UgYW5vdGhlciByZWxhdGVkIGRyYWZ0cyB3aGljaCBJIHByZXNlbnRlZCBhdCBt b25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nLjxicj4KPGJyPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4tIEFu YWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZShkcmFmdC1ob25n LW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwKTxicj4KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBi LXN0YXRlbWVudC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11 bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0 ZW1lbnQtMDAudHh0PC9hPjxicj4KPGJyPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4tIFZpcnR1YWwgbmV0d29yayBp bnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgbm9kZSB1c2luZyBN b2JpbGUgSVB2Njxicj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IChkcmFmdC1ob25nLXZpcnR1YWxpZi1t bi1taXB2Ni0wMCk8YnI+Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2RyYWZ0L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2LTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9kcmFmdC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1YWxp Zi1tbi1taXB2Ni0wMC50eHQ8L2E+PGJyPgo8YnI+PGJyPkluIHRoZSBzZWN0aW9uIDIuMiAoR2Vu ZXJhbCBOZXR3b3JrIElzc3VlcykgaW4gdGhlIGZpcnN0IGRyYWZ0LDxicj50aGVyZSBhcmUgZ2Vu ZXJhbCBuZXR3b3JrIGlzc3VlcyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcy48YnI+PGJyPklu Y2x1ZGluZyB0aGVzZSBkcmFmdHMsIEkgaG9wZSB0byBlbmNvdXJhZ2UgdGhpcyBkaXNjdXNzaW9u PGJyPjxicj5Zb25nLUdldW4uPC9zcGFuPjwvcD4KPC9kaXY+PC9kaXY+PC9kaXY+CjxwIHN0eWxl PSJNQVJHSU4tQk9UVE9NOiAxMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm1pZiBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pZkBpZXRm Lm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9taWYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21pZjwvYT48L3NwYW4+PC9wPgo8L2Rpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGltZyBoZWln aHQ9IjAiIHdpZHRoPSIwIj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_261542_2402905.1232002029787-- --===============0412228488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0412228488==-- From mif-bounces@ietf.org Thu Jan 15 03:12:13 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577A93A6877; Thu, 15 Jan 2009 03:12:13 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BC33A6877 for ; Thu, 15 Jan 2009 03:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nbxiqDV23J5 for ; Thu, 15 Jan 2009 03:12:10 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 1100C3A685D for ; Thu, 15 Jan 2009 03:12:09 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 15 Jan 2009 20:11:53 +0900 X-ReadCheckMessageID: X-ReadCheckName: mif%40ietf.org From: "Hong Yong-Geun" To: "Hui Deng" Date: Thu, 15 Jan 2009 20:11:53 +0900 Priority: normal Comment: ??, u-??, Content-Class: urn:content-classes:message Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Importance: normal In-Reply-To: <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif thread-index: Acl23RiNKskAWY3GR6CEkgW4XouuWAAIw++gAAB6aa0= References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> X-OriginalArrivalTime: 15 Jan 2009 11:11:53.0356 (UTC) FILETIME=[1211B4C0:01C97702] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1464652531==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1464652531== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97700.E0B56760" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97700.E0B56760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C97700.E0B56760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDsmbmJzcDsgPCEtLSBzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTeXN0ZW07DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1w aXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDE1MTM4ODE2MCAxNiAwIDUyNDI4OCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk66rW066a8Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxOw0KCW1zby1mb250 LWFsdDpHdWxpbTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFu Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTYxMDYx MTk4NSAxMTA3MzA0NjgzIDAgMCAxNTkgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLr p5HsnYAg6rOg65SVIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDsNCgltc28tZm9u dC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xODc5MDQ3NTA1IDE2NTEx NzE3OSAxOCAwIDUyNDI4OSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6MTYyNzQwMDgzOSAtMjE0NzQ4MzY0OCA4IDAgNjYwNDcgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOq1tOumvCI7DQoJcGFub3NlLTE6MiAxMSA2 IDAgMCAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtY2hhcnNldDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9u dC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNp Z25hdHVyZTotMTM0MjE3NjU5MyAxNzc1NzI5OTE1IDQ4IDAgNTI0NDQ3IDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEDrp5HsnYAg6rOg65SVIjsNCglwYW5vc2UtMToyIDExIDUgMyAy IDAgMCAyIDAgNDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOi0xODc5MDQ3NTA1IDE2NTExNzE3OSAxOCAwIDUyNDI4OSAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU3lzdGVtIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0K CW1zby1mb250LWNoYXJzZXQ6MTI5Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJ bXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmF1dG87DQoJbXNvLWZvbnQt c2lnbmF0dXJlOjEgMTUxMzg4MTYwIDE2IDAgNTI0Mjg4IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFy ZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5Ouq1 tOumvDsNCgltc28tYmlkaS1mb250LWZhbWlseTrqtbTrprw7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJs aW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9 DQpwDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRv dy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrqtbTrprw7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk66rW066a8O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHls ZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tYXNjaWkt Zm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9y LWxhdGluOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28t ZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWZhcmVhc3Q7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiLrp5HsnYAg6rOg65SVIjsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1m b250Om1pbm9yLWJpZGk7DQoJY29sb3I6IzFGNDk3RDsNCgltc28tdGhlbWVjb2xvcjpkYXJrMjt9 DQpzcGFuLkdyYW1FDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0 LXByb3BzOnllczsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCW1z by1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLXRoZW1lLWZvbnQ6bWlub3ItYmlkaTt9DQpAcGFn ZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46My4wY20gNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7DQoJbXNvLWhlYWRlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1mb290ZXIt bWFyZ2luOjM2LjBwdDsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+PC9TVFlMRSAtLT4NCjxESVYgbGFuZz1LTyBzdHlsZT0idGFiLWlu dGVydmFsOiA0MC4wcHQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPERJViBjbGFzcz1T ZWN0aW9uMT4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUn OyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2kt dGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6 IGRhcmsyIj5IaS4uSHVpLi48P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48L1NQQU4+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1i aWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47 IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1m b250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n OyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZB TUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFz Y2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5v ci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3It YmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5ObywgSSBkaWRu4oCZdCBkaXNjdXNzIHdpdGgg bWV4dCB3Zy4gSSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCB3aXRoIG1vbmFtaTYgd2cgYXQgNjR0 aCBJRVRGIG1lZXRpbmcuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0 OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZv bnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNv LWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250 OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPkFuZCBpdCB3YXMgbm90IGFkb3B0 ZWQgaW4gbW9uYW1pNiB3ZyBiZWNhdXNlIGl0IHdhcyBub3QgaW4gdGhlIHNjb3BlIG9mIG1vbmFt aTYgd2cuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFN SUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNj aWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9y LWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1i aWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlk aS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBt c28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5C ZXN0IHJlZ2FyZHMuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZP TlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBt c28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6 IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJp ZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBt aW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBt c28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxh dGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhl bWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRh cmsyIj5Zb25nLUdldW48U1BBTiBjbGFzcz1HcmFtRT4uLjwvU1BBTj48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsg bXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBk YXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPERJViBzdHlsZT0iQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctQk9UVE9NOiAwY207IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmUiPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJv bTo8L1NQQU4+PC9CPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+IEh1aSBEZW5nIFttYWlsdG86ZGVuZ2h1 aTAyQGdtYWlsLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAw OSAzOjQ3IFBNPEJSPjxCPlRvOjwvQj4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBUYWhvbWE7IG1zby1hc2NpaS1mb250LWZhbWlseTog VGFob21hOyBtc28taGFuc2ktZm9udC1mYW1pbHk6IFRhaG9tYSI+7ZmN7Jqp6re8PC9TUEFOPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJyI+PEJSPjxCPkNjOjwvQj4gbWlmQGlldGYub3JnPEJSPjxCPlN1Ympl Y3Q6PC9CPiBSZTogW21pZl0gbW9iaWxpdHkgaXNzdWVzIGFuZCBnZW5lcmFsIGlzc3VlcyBvbiBt aWY8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g bGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+eW91IGFscmVhZHkgaGFkIGEgZGlzY3Vzc2lvbiB3 aXRoIG1leHQgd2csIHRoZXkgYXJlIG5vdCBhZG9wdGluZyB0aGlzIHdvcms/PG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVO LVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxTUEFOIGxhbmc9RU4tVVM+LUh1 aTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTi1VUz4yMDA5LzEvMTQgSG9uZyBZb25nLUdldW4gJmx0OzxBIGhyZWY9Im1h aWx0bzp5Z2hvbmdAZXRyaS5yZS5rciI+eWdob25nQGV0cmkucmUua3I8L0E+Jmd0OzxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+SGkuLkh1aS4uPC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+ Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86 cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+VGhhbmsgeW91IGZvciBjb21tZW50cy4gU2VlIGJlbG93 IGlubGluZSByZXBseS48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5C ZXN0IHJlZ2FyZHMuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dCI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+WW9u Zy1HZXVuLi48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWIHN0eWxl PSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006 IDBjbTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVIt Qk9UVE9NOiBtZWRpdW0gbm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPkZyb206PC9TUEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPiBIdWkgRGVuZyBbbWFpbHRvOjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJA Z21haWwuY29tIiB0YXJnZXQ9X2JsYW5rPmRlbmdodWkwMkBnbWFpbC5jb208L0E+XSA8QlI+PEI+ U2VudDo8L0I+IFdlZG5lc2RheSwgSmFudWFyeSAxNCwgMjAwOSA3OjIwIEFNPEJSPjxCPlRvOjwv Qj4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPu2Zjeyaqeq3vDxTUEFOIGxh bmc9RU4tVVM+PEJSPjxCPkNjOjwvQj4gPEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFy Z2V0PV9ibGFuaz5taWZAaWV0Zi5vcmc8L0E+PEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogW21pZl0g bW9iaWxpdHkgaXNzdWVzIGFuZCBnZW5lcmFsIGlzc3VlcyBvbiBtaWY8bzpwPjwvbzpwPjwvU1BB Tj48L1NQQU4+PC9QPjwvRElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFA+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5IaSwgSG9uZyBZb25nLDxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8 RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JIHJlYWQg dGhyb3VnaCB5b3VyIHR3byBkcmFmdHMsIHVuZGVyc3RhbmQgeW91IGFyZSB0YWxraW5nIHRoZSBp c3N1ZSZuYnNwO3dpdGhvdXQgTW9uYW1pPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFAg c3R5bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQiPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFN SUxZOiBXaW5nZGluZ3MiPj88L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiA3cHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nl cmlmJyI+Jm5ic3A7IDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiAjMWY0OTdkIj5ZZXMsIHlvdSBhcmUgY29ycmVjdC4gPEJSPkkgd2FudCB0byBz b2x2ZSB0aGUgbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIHdpdGhvdXQgbW9kaWZ5aW5nIE1v YmlsZSBJUHY2L05FTU8gY29kZS48QlI+KEluIE1vbmFtaTYsIG11bHRpcGxlIGludGVyZmFjZSBw cm9ibGVtcyAod2hpY2gmbmJzcDthcmUgcmVsYXRlZCB0byBtb2JpbGl0eSBpc3N1ZXMsIHN1Y2gg YXMgbXVsdGlwbGUgQ29BLDxCUj5tdWx0aXBsZSBIb0EsIGV0Yy4sICkgYXJlIHJlc29sdmluZyBi eSBtb2RpZnlpbmcgTW9iaWxlIElQdjYvTkVNTyBwcm90b2NvbCk8L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElW Pg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48QlI+aXQgc2Vl bXMgTW9iaWxlIElwdjYgaW50ZXJuYWwgYWxzbyBoYXMgc2ltaWxhciBpc3N1ZSB3aXRoIHVzIGlm IEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4N CjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogMjEuNzVwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05U LUZBTUlMWTogV2luZ2RpbmdzIj4/PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogN3B0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n LCdzZXJpZiciPiZuYnNwOyA8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+WWVzLCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJhc2Vk IG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2NiwgTW9iaWxlIElQdjYgaW50ZXJuYWw8QlI+ aGFzIHNpbWlsYXIgaXNzdWVzIG9mIG1pZi4gU28sIEkgdGhpbmsgdGhhdCBpdCBpcyB2YWx1YWJs ZSB0byBzZXBhcmF0ZSBtb3JlIGdlbmVyYWwgaXNzdWVzIGZyb208QlI+bXVsdGlwbGUgaW50ZXJm YWNlIGlzc3VlcyB3aGljaCBhcmUgZGlyZWN0bHkgcmVsYXRlZCB0byBNb2JpbGUgSVB2Ni9ORU1P LjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPjxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6ICMxZjQ5N2QiPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8RElW Pg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JbiB0aGlzIGNh c2UgSSB3b3VsZCBsaWtlIHRvIGVuY291cmFnZSB5b3UgdG8gcHJvcG9zZSB0aGlzIGlzc3VlIHRv IG91ciB3b3JrLCBpZiBhbGxvd2VkLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj4N CjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij5pdCBtaWdodGJlIGRvYWJsZSB3aXRoaW4gb3VyIHNjb3BlLDxvOnA+PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogMjEuNzVwdDsgVEVYVC1JTkRFTlQ6IC0x OHB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0 OTdkOyBGT05ULUZBTUlMWTogV2luZ2RpbmdzIj4/PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogN3B0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nLCdzZXJpZiciPiZuYnNwOyA8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+VGhhbmtzLiBJdCBpcyBteSBwbGVhc3Vy ZS4uPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD48 L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0Ij5tYW55IHRoYW5rczxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPi1IdWk8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4yMDA5LzEvNyBIb25nIFlv bmctR2V1biAmbHQ7PEEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJnZXQ9X2Js YW5rPnlnaG9uZ0BldHJpLnJlLmtyPC9BPiZndDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElW Pg0KPERJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkhpLiBtaWYuLjxCUj48QlI+TGV0IG1lIGpvaW4gdGhp cyBkaXNjdXNzaW9uLjxCUj48QlI+SXQgaXMgdmVyeSBpbnRlcmVzdGluZyB0byBzZWUgbWlmLjxC Uj48QlI+QXMgSHVpIERlbmcgc2F5cywgSSB1bmRlcnN0YW5kIHRoYXQgbWlmIGhhcyBkaWZmZXJl bnQgYXBwcm9hY2g8QlI+ZnJvbSBvdGhlciBXRyBzdWNoIGFzIE1FWFQgYW5kIG1vbmFtaTYgV0cs IGV0Yy48QlI+PEJSPkluIE1FWFQsIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGFyZSByZWxh dGVkIHRvIE1vYmlsZSBJUCwgTkVNTywuLjxCUj5JbiBtaWYsIG11bHRpcGxlIGludGVyZmFjZXMg aXNzdWVzIGFyZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBvZiBNRVhULjxCUj5TbywgaW4gbWlmLCBp dCBpcyBiZXR0ZXIgdG8gZmluZCBtb3JlIGdlbmVyYWwgaXNzdWVzIHdoaWNoIGFyZSBub3QgcmVs YXRlZCB0byBNb2JpbGUgSVAuPEJSPjxCUj5JIHRoaW5rIHRoYXQgTS5CbGFuY2hldCdzICJNdWx0 aXBsZSBJbnRlcmZhY2VzIFByb2JsZW0gU3RhdGVtZW50IiBkcmFmdCBpczxCUj5hIGdvb2Qgc3Rh cnRpbmcgcG9pbnQgdG8gZGlzY3VzcyBnZW5lcmFsIGlzc3VlcyBvbiBtaWYuPEJSPjxCUj5JIHdv dWxkIGxpa2UgdG8gaW50cm9kdWNlIGFub3RoZXIgcmVsYXRlZCBkcmFmdHMgd2hpY2ggSSBwcmVz ZW50ZWQgYXQgbW9uYW1pNiBXRyBhdCA2NHRoIElFVEYgbWVldGluZy48QlI+PEJSPjwvU1BBTj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzwvU1BBTj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0i Pi0gQW5hbHlzaXMgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlKGRyYWZ0 LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDApPEJSPjwvU1BBTj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8QSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBi LXN0YXRlbWVudC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dCIg dGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQtaG9uZy1tdWx0 aXBsZWlmLW1uLXBiLXN0YXRlbWVudC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVt ZW50LTAwLnR4dDwvQT48QlI+PEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPi0gVmlydHVhbCBuZXR3b3JrIGludGVyZmFj ZSBmb3IgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBub2RlIHVzaW5nIE1vYmlsZSBJ UHY2PEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZu YnNwOyZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiAoZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYtMDAp PEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNw OzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPiA8QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQt aG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYtMDAu dHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25n LXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ8 L0E+PEJSPjxCUj48QlI+SW4gdGhlIHNlY3Rpb24gMi4yIChHZW5lcmFsIE5ldHdvcmsgSXNzdWVz KSBpbiB0aGUgZmlyc3QgZHJhZnQsPEJSPnRoZXJlIGFyZSBnZW5lcmFsIG5ldHdvcmsgaXNzdWVz IGR1ZSB0byBtdWx0aXBsZSBpbnRlcmZhY2VzLjxCUj48QlI+SW5jbHVkaW5nIHRoZXNlIGRyYWZ0 cywgSSBob3BlIHRvIGVuY291cmFnZSB0aGlzIGRpc2N1c3Npb248QlI+PEJSPllvbmctR2V1bi48 L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+DQo8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MTJwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48QlI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+bWlmIG1haWxpbmcg bGlzdDxCUj48QSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1pZkBp ZXRmLm9yZzwvQT48QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWYiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWY8L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFA+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PEI+7Jik66WYPFNQQU4gbGFuZz1FTi1VUz4hIDwvU1BBTj7tjIzsnbwg7J2066aE7J20IOyngOyg leuQmOyWtCDsnojsp4Ag7JWK7Iq164uI64ukPFNQQU4gbGFuZz1FTi1VUz4uPC9TUEFOPjwvQj48 U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxQIGNsYXNzPU1z b05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVp Z2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNw eD9lbWFpbD1taWZAaWV0Zi5vcmcmbmFtZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25n QGV0cmkucmUua3ImbWVzc2FnZWlkPSUzQ2NlMjIzNDg3LTAzMmMtNGNjNS1iMDA4LTg4NDA4YjVk YmQ2MEBldHJpLnJlLmtyJTNFIj4= ------_=_NextPart_001_01C97700.E0B56760-- --===============1464652531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1464652531==-- From mif-bounces@ietf.org Fri Jan 16 05:50:32 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8168C3A680C; Fri, 16 Jan 2009 05:50:32 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853613A67EE for ; Fri, 16 Jan 2009 05:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7PUbnQuP177 for ; Fri, 16 Jan 2009 05:50:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id A17443A680C for ; Fri, 16 Jan 2009 05:50:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1760382rvf.49 for ; Fri, 16 Jan 2009 05:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=CsQMe18dbMIvBj8tXNtQanumqz/hc7Tzki1WP50/yBE=; b=RxWjLMd8l5EovdxM1yEOMSvPgk4empB9+kYrvIYsdL5FBKST9WcBikA8yqLQruam9Y Qu+rQUmFcTOYVK3Z5wvTpk5wcEZePqgMHeG1GPW11bfO5VmTuE2zRvMf6iRMLyv1Q/gQ pUz4mvTALTXeg4wxegFzs1kq+E83BRObDqOCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=EpsWq/Bt/lM/HRL+uM+VUc9qQIHHJM4qnxMdKnR8f506tbkP+JzrBh2kwiIwn5fl0C XK/26bnQS2KIrk7Rbp6D91Tiup6SjeMDiLMMmPCkA27f3R8NuZ7rIdYS3KA2nbxdxD6P jYJpVYXgPk3nzlSnnIXH0f+/A0zxf/Crh2UJg= Received: by 10.142.11.20 with SMTP id 20mr1053022wfk.62.1232113814185; Fri, 16 Jan 2009 05:50:14 -0800 (PST) Received: by 10.142.224.2 with HTTP; Fri, 16 Jan 2009 05:50:14 -0800 (PST) Message-ID: <3db7b9d60901160550g53f051eaqb51e5e2eea3e05f0@mail.gmail.com> Date: Fri, 16 Jan 2009 21:50:14 +0800 From: "Kai Ju" To: mif@ietf.org MIME-Version: 1.0 Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838000572==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0838000572== Content-Type: multipart/alternative; boundary="----=_Part_319257_30177676.1232113814176" ------=_Part_319257_30177676.1232113814176 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all >-----Original Message----- >From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] On >Behalf Of ext Tony Finch >Sent: 05 January, 2009 21:24 >To: mif at ietf.org >Subject: [mif] draft-blanchet-mif-problem-statement-00.txt > >Can a host use multiple interfaces to get more bandwidth? >Obviously yes now by binding the local end of each socket to >each interface, but that introduces much more complexity to an >area that was previously simple. Is that complexity avoidable? This is probably not in mif scope. There's some interesting work ongoing on having multipath support on transpor layer (multipath TCP): http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf Yes, We agree that it's not in mif scope, that one application can get more bandwidth by using multiple interfaces. But we believe that a host who has several applications on can optimize the bandwidth condition by using multiple interfaces, under the policy provided by the ISP. For example, one application is moved from one interface to another due to the network congestion, or the requirement for more bandwidth. We think it's one direction which is worth to be discussed by MIF. Best regards, Kai ------=_Part_319257_30177676.1232113814176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, all
>-----Original Message-----
>From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] On
>Behalf Of ext Tony Finch
>Sent: 05 January, 2009 21:24
>To: mif at ietf.org
>Subject: [mif] draft-blanchet-mif-problem-statement-00.txt
>
>Can a host use multiple interfaces to get more bandwidth?
>Obviously yes now by binding the local end of each socket to
>each interface, but that introduces much more complexity to an
>area that was previously simple. Is that complexity avoidable?

This is probably not in mif scope. There's some interesting work ongoing
on having multipath support on transpor layer (multipath TCP):
http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf


Yes, We agree that it's not in mif scope, that one application can get more
bandwidth by using multiple interfaces.
But we believe that a host who has several applications on can optimize the bandwidth
condition by using multiple interfaces, under the policy provided by the ISP. For example,
one application is moved from one interface to another due to the network congestion,
or the requirement for more bandwidth.
We think it's one direction which is worth to be discussed by MIF.
Best regards,

Kai
------=_Part_319257_30177676.1232113814176-- --===============0838000572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0838000572==-- From mif-bounces@ietf.org Fri Jan 16 08:33:55 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327F53A6904; Fri, 16 Jan 2009 08:33:55 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FC028C15E for ; Fri, 16 Jan 2009 08:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ9wX6fLmNSH for ; Fri, 16 Jan 2009 08:33:52 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 91ED23A68CC for ; Fri, 16 Jan 2009 08:33:51 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sat, 17 Jan 2009 01:33:35 +0900 X-ReadCheckMessageID: <617bc284-c26d-4f5e-91f0-b1a3028179cd@etri.re.kr> X-ReadCheckName: mif%40ietf.org From: "Hong Yong-Geun" To: "Kai Ju" , Date: Sat, 17 Jan 2009 01:33:35 +0900 Priority: normal Comment: ??, u-??, Content-class: urn:content-classes:message Message-ID: X-Mailer: Microsoft CDO for Exchange 2000 MIME-Version: 1.0 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 in-reply-to: <3db7b9d60901160550g53f051eaqb51e5e2eea3e05f0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet-mif-problem-statement-00.txt thread-index: Acl34V5ltsd2awWbQ1SekCOrO/KbBAAFCxhQAAConvk= References: <3db7b9d60901160550g53f051eaqb51e5e2eea3e05f0@mail.gmail.com> X-OriginalArrivalTime: 16 Jan 2009 16:33:35.0383 (UTC) FILETIME=[2D630A70:01C977F8] Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1955920795==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1955920795== Content-class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C977F7.DF2437D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C977F7.DF2437D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C977F7.DF2437D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDsmbmJzcDsgPCEtLSBzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTeXN0ZW07DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1w aXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDE1MTM4ODE2MCAxNiAwIDUyNDI4OCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMt Zm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQt c2lnbmF0dXJlOi0xNjEwNjExOTg1IDExMDczMDQ2ODMgMCAwIDE1OSAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMCAw IDIgMCA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTI5Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 Om1vZGVybjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 LTE4NzkwNDc1MDUgMTY1MTE3MTc5IDE4IDAgNTI0Mjg5IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZv bnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250 LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZToxNjI3NDAwODM5IC0yMTQ3NDgz NjQ4IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA66eR7J2AIOqz oOuUlSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7DQoJbXNvLWZvbnQtY2hhcnNl dDoxMjk7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNo OnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTg3OTA0NzUwNSAxNjUxMTcxNzkgMTgg MCA1MjQyODkgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFN5c3RlbSI7DQoJcGFu b3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28t Zm9udC1waXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDE1MTM4ODE2MCAxNiAwIDUy NDI4OCAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUt cWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tZmFyZWFzdC10aGVt ZS1mb250Om1pbm9yLWZhcmVhc3Q7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5 ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwDQoJe21zby1zdHls ZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tZmFyZWFzdC10 aGVtZS1mb250Om1pbm9yLWZhcmVhc3Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCW1zby1hc2NpaS1m b250LWZhbWlseToi66eR7J2AIOqzoOuUlSI7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3It bGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCW1zby1m YXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFzdDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6 IuunkeydgCDqs6DrlJUiOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLXRoZW1lLWZv bnQ6bWlub3ItYmlkaTsNCgljb2xvcjojMUY0OTdEOw0KCW1zby10aGVtZWNvbG9yOmRhcmsyO30N CnNwYW4uU3BlbGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0Kc3Bh bi5HcmFtRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9w czp5ZXM7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tYXNj aWktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7fQ0KQHBhZ2UgU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjMuMGNtIDcyLjBwdCA3Mi4w cHQgNzIuMHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdp bjozNi4wcHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNl Y3Rpb24xO30NCi0tPjwvU1RZTEUgLS0+DQo8RElWIGxhbmc9S08gc3R5bGU9InRhYi1pbnRlcnZh bDogNDAuMHB0IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxESVYgY2xhc3M9U2VjdGlv bjE+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNv LWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRp bjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3Qt dGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxh dGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRo ZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+SGksIGFsbC48P3ht bDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0 OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVh c3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBt c28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1mb250 OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDog bWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5JIHRoaW5rIHRoYXQgYSBob3N0IGNh biB1c2UgbXVsdGlwbGUgaW50ZXJmYWNlcyB0byBnZXQgbW9yZSBiYW5kd2lkdGggd2l0aG91dDxC Uj48U1BBTiBjbGFzcz1HcmFtRT5pbmNyZWFzaW5nPC9TUEFOPiBjb21wbGV4aXR5LiBFdmVuIHRo b3VnaCBtdWx0aXBsZSBpbnRlcmZhY2VzIGV4aXN0LCBpZiBpdCBpcyBwb3NzaWJsZSB0byBoaWRl PEJSPjxTUEFOIGNsYXNzPUdyYW1FPnRoZTwvU1BBTj4gZXhpc3Rpbmcgb2YgbXVsdGlwbGUgaW50 ZXJmYWNlcyB0byB0aGUgdXBwZXIgbGF5ZXIgKG5ldHdvcmsgbGF5ZXIpLCBtdWx0aXBsZSBpbnRl cmZhY2VzPEJSPjxTUEFOIGNsYXNzPUdyYW1FPmNhbjwvU1BBTj4gYmUgdXNlZCB0byBnZXQgbW9y ZSBiYW5kd2lkdGguIE9uZSBvZiBzb2x1dGlvbnMgZm9yIHRoaXMgaXMgYSB2aXJ0dWFsIG5ldHdv cmsgaW50ZXJmYWNlIGNvbmNlcHQuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IFN5c3RlbSI+PEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2RyYWZ0L2RyYWZ0LWhv bmctdmlydHVhbGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4 dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQtaG9uZy12 aXJ0dWFsaWYtbW4tbWlwdjYvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0PC9B PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAj MWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6 IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5v ci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3It YmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9u dDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28t YmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6 IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJl YXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5v ci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlk aS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPkFzIEthaSBz YXlzLCBJIGFncmVlZCB0aGF0IHVzaW5nIG11bHRpcGxlIGludGVyZmFjZXMgYW5kIGNoYW5naW5n IGludGVyZmFjZXMgZHVyaW5nIGNvbW11bmljYXRpb248QlI+PFNQQU4gY2xhc3M9R3JhbUU+Zm9y PC9TUEFOPiB0aGUgYXZvaWRhbmNlIG9mIG5ldHdvcmsgY29uZ2VzdGlvbiBvciB0aGUgcmVxdWly ZW1lbnQgZm9yIG1vcmUgYmFuZHdpZHRoIGNhbiBiZSBvbmUgb2Ygc3R1ZHk8QlI+PFNQQU4gY2xh c3M9R3JhbUU+aXRlbXM8L1NQQU4+IGluIG1pZi48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9u dDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28t YmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6 IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1mYXJl YXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5v ci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlk aS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPlRoYW5rczxT UEFOIGNsYXNzPUdyYW1FPi4uPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNp emU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBt aW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRp LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlu b3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9R3JhbUU+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg 65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBk YXJrMiI+WW9uZy1HZXVuLjwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SV JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5v ci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZh cmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1p bm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1i aWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+IDxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeyd gCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZv bnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn OyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu JzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsy Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1G QU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1h c2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICfr p5HsnYAg6rOg65SVJzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNv LWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVt ZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPERJViBzdHlsZT0i Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9Q OiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwY207IEJP UkRFUi1MRUZUOiBibHVlIDEuNXB0IHNvbGlkOyBQQURESU5HLVRPUDogMGNtOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZSI+DQo8RElWPg0KPERJViBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctQk9UVE9NOiAwY207IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUi Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPiBt aWYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pZi1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBC ZWhhbGYgT2YgPC9CPkthaSBKdTxCUj48Qj5TZW50OjwvQj4gRnJpZGF5LCBKYW51YXJ5IDE2LCAy MDA5IDEwOjUwIFBNPEJSPjxCPlRvOjwvQj4gbWlmQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9C PiBSZTogW21pZl0gZHJhZnQtYmxhbmNoZXQtbWlmLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dDxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8UCBjbGFz cz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5IaSwgYWxsPG86cD48L286cD48L1NQQU4+PC9Q PjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPiZndDst LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7RnJvbTogbWlmLWJvdW5jZXMgYXQgPEEg aHJlZj0iaHR0cDovL2lldGYub3JnLyIgdGFyZ2V0PV9ibGFuaz5pZXRmLm9yZzwvQT4gW21haWx0 bzo8QSBocmVmPSJtYWlsdG86bWlmLWJvdW5jZXMiPm1pZi1ib3VuY2VzPC9BPiBhdCA8QSBocmVm PSJodHRwOi8vaWV0Zi5vcmcvIiB0YXJnZXQ9X2JsYW5rPmlldGYub3JnPC9BPl0gT24gPEJSPiZn dDtCZWhhbGYgT2YgZXh0IFRvbnkgRmluY2g8QlI+Jmd0O1NlbnQ6IDA1IEphbnVhcnksIDIwMDkg MjE6MjQ8QlI+Jmd0O1RvOiBtaWYgYXQgPEEgaHJlZj0iaHR0cDovL2lldGYub3JnLyIgdGFyZ2V0 PV9ibGFuaz5pZXRmLm9yZzwvQT48QlI+Jmd0O1N1YmplY3Q6IFttaWZdIGRyYWZ0LWJsYW5jaGV0 LW1pZi1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQ8QlI+Jmd0OzxCUj4mZ3Q7Q2FuIGEgaG9zdCB1 c2UgbXVsdGlwbGUgaW50ZXJmYWNlcyB0byBnZXQgbW9yZSBiYW5kd2lkdGg/IDxCUj4mZ3Q7T2J2 aW91c2x5IHllcyBub3cgYnkgYmluZGluZyB0aGUgbG9jYWwgZW5kIG9mIGVhY2ggc29ja2V0IHRv IDxCUj4mZ3Q7ZWFjaCBpbnRlcmZhY2UsIGJ1dCB0aGF0IGludHJvZHVjZXMgbXVjaCBtb3JlIGNv bXBsZXhpdHkgdG8gYW4gPEJSPiZndDthcmVhIHRoYXQgd2FzIHByZXZpb3VzbHkgc2ltcGxlLiBJ cyB0aGF0IGNvbXBsZXhpdHkgYXZvaWRhYmxlPzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4N CjxQPjxTUEFOIGxhbmc9RU4tVVM+VGhpcyBpcyBwcm9iYWJseSBub3QgaW4gbWlmIHNjb3BlLiBU aGVyZSdzIHNvbWUgaW50ZXJlc3Rpbmcgd29yayBvbmdvaW5nPEJSPm9uIGhhdmluZyBtdWx0aXBh dGggc3VwcG9ydCBvbiB0cmFuc3BvciBsYXllciAobXVsdGlwYXRoIFRDUCk6PEJSPjxBIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhqdWwvc2xpZGVzL3RzdmFyZWEtMi5w ZGYiIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9z bGlkZXMvdHN2YXJlYS0yLnBkZjwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEJSPlllcywgV2UgYWdyZWUgdGhhdCBp dCdzIG5vdCBpbiBtaWYgc2NvcGUsIHRoYXQgb25lIGFwcGxpY2F0aW9uIGNhbiBnZXQgbW9yZSA8 bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIGxhbmc9RU4tVVM+YmFuZHdpZHRoIGJ5IHVzaW5nIG11bHRpcGxlIGludGVyZmFjZXMuPG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiBsYW5nPUVOLVVTPkJ1dCB3ZSBiZWxpZXZlIHRoYXQgYSBob3N0IHdobyBoYXMgc2V2ZXJhbCBh cHBsaWNhdGlvbnMgb24gY2FuIG9wdGltaXplIHRoZSBiYW5kd2lkdGggPG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT PmNvbmRpdGlvbiBieSB1c2luZyBtdWx0aXBsZSBpbnRlcmZhY2VzLCB1bmRlciB0aGUgcG9saWN5 IHByb3ZpZGVkIGJ5IHRoZSBJU1AuIEZvciBleGFtcGxlLCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+b25lIGFw cGxpY2F0aW9uIGlzIG1vdmVkIGZyb20gb25lIGludGVyZmFjZSB0byBhbm90aGVyIGR1ZSB0byB0 aGUgbmV0d29yayBjb25nZXN0aW9uLCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElW Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+b3IgdGhlIHJlcXVpcmVtZW50 IGZvciBtb3JlIGJhbmR3aWR0aC48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+V2UgdGhpbmsgaXQncyBvbmUgZGly ZWN0aW9uIHdoaWNoIGlzIHdvcnRoIHRvIGJlIGRpc2N1c3NlZCBieSBNSUYuPG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVO LVVTPkJlc3QgcmVnYXJkcyw8QlI+PEJSPkthaTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48 L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdp ZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFk Q2hlY2suYXNweD9lbWFpbD1taWZAaWV0Zi5vcmcmbmFtZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1h aWw9eWdob25nQGV0cmkucmUua3ImbWVzc2FnZWlkPSUzQzYxN2JjMjg0LWMyNmQtNGY1ZS05MWYw LWIxYTMwMjgxNzljZEBldHJpLnJlLmtyJTNFIj4= ------_=_NextPart_001_01C977F7.DF2437D0-- --===============1955920795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1955920795==-- From mif-bounces@ietf.org Sat Jan 17 03:45:29 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843053A69DD; Sat, 17 Jan 2009 03:45:29 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EEE3A69DD for ; Sat, 17 Jan 2009 03:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.143 X-Spam-Level: ** X-Spam-Status: No, score=2.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AFA5LWKtnJK for ; Sat, 17 Jan 2009 03:45:28 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9B82D3A67B2 for ; Sat, 17 Jan 2009 03:45:27 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDM004C05Z1LX@szxga04-in.huawei.com> for mif@ietf.org; Sat, 17 Jan 2009 19:45:01 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDM007CH5Z1JC@szxga04-in.huawei.com> for mif@ietf.org; Sat, 17 Jan 2009 19:45:01 +0800 (CST) Received: from jys8064005 (dyn.83-228-134-092.dsl.vtx.ch [83.228.134.92]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDM00AS75YW4E@szxml02-in.huawei.com>; Sat, 17 Jan 2009 19:45:01 +0800 (CST) Date: Sat, 17 Jan 2009 19:03:22 +0800 From: w53375 To: Hui Deng Message-id: <01c901c97899$12dd4430$0201a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350901131435v9995ebai80880b98b0456e7c@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0840280535==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0840280535== Content-type: multipart/alternative; boundary="Boundary_(ID_F3gbligIJCRnvzuW0SJwqA)" This is a multi-part message in MIME format. --Boundary_(ID_F3gbligIJCRnvzuW0SJwqA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thanks for your reply, Please see the follow up comments below. -Qin ----- Original Message ----- From: Hui Deng To: Qin Wu Cc: mif@ietf.org Sent: Wednesday, January 14, 2009 6:35 AM Subject: IP model for multiple mode mobile terminal Hi, Qin, Thanks for your comments. see below inline reply. 2009/1/8 Qin Wu Interesting topic, As we discussed before, you thought Internet IP model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it is a little different, mobile terminal has multiple modes, it would like to use all of them simulatenously which orginal IP model doesn't work any more on it. Thanks for your agreement on this issue. I can understand IETF more concentrates on single-point technology, not end to end solution. As regarding Internet IP model, dual radio model has already been developing to support inter-technology handover. Dual mode teminal is not fanciful. Could you help to write down how you implement on this? [Qin]What I understand in order to achieve seamless handover during the inter-technology handover, the UE is required to support dual mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access network to the CDMA access network, the UE can attach to WIMAX and CDMA link simuteneusly,in this situation, the traffic can be bicasted to the UE through two links, the packet loss can be avoided wholly, however, the difficulty is when the UE frequently moves between hetergeneous network at high speed, there are great chanllenge for the UE to maintain the WiMAX link and CDMA link simuteneously. In the future, with the development of femto technolgy, single mode teminal can access mobile network via a femto basestation at home. I can not judge whether single radio technology or dual radio technology will dominate the future market. Any way, from the technical perspective, I think the traditional internet IP model will be gradually evolving. multiple interface requirements will become one big issue to be considered, e.g., dynamic provision and routing , coordination and synchronization mechanisms are needed to be further study. it seems that dynamical provision and routing, coordination and synchronization will become more complicated, simple way make deployment easy, it is the way of Internet exist [Qin} I agree more optimized approach can be used to faciliate utilizing the network resource and better user experience. thanks -Hui -Qin ----- Original Message ----- From: Hui Deng To: mif@ietf.org Sent: Thursday, January 08, 2009 11:13 PM Subject: [mif] Mailing list Issue Hello, all I saw lots of email with mif-bounces@ietf.org. It seems some people has issue with this mailing list. If that is the case, please don't hestitate to let me know that, many thanks -Hui -------------------------------------------------------------------------- _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_F3gbligIJCRnvzuW0SJwqA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yOTEyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzs+VGhhbmtzIGZvciB5b3VyIHJlcGx5LCBQbGVhc2Ugc2VlIHRoZSBmb2xsb3cgdXAgY29tbWVu dHMgDQpiZWxvdy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz4tUWluPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDog MHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMw MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW Pg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9ZGVu Z2h1aTAyQGdtYWlsLmNvbSBocmVmPSJtYWlsdG86ZGVuZ2h1aTAyQGdtYWlsLmNvbSI+SHVpIERl bmc8L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMw NzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFp bHRvOnN1bnNlYXdxQGh1YXdlaS5jb20iPlFpbiBXdTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPW1pZkBpZXRm Lm9yZyANCiAgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyI+bWlmQGlldGYub3JnPC9BPiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9C PiBXZWRuZXNkYXksIEphbnVhcnkgMTQsIDIwMDkgNjozNSANCiAgQU08L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBJUCBtb2Rl bCBmb3IgbXVsdGlwbGUgbW9kZSBtb2JpbGUgDQogIHRlcm1pbmFsPC9ESVY+DQogIDxESVY+PEJS PjwvRElWPg0KICA8RElWPkhpLCBRaW4sIDwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8 RElWPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gc2VlIGJlbG93IGlubGluZSByZXBseS48QlI+ PC9ESVY+DQogIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+MjAwOS8xLzggUWluIFd1IDxTUEFOIGRp cj1sdHI+Jmx0OzxBIA0KICBocmVmPSJtYWlsdG86c3Vuc2Vhd3FAaHVhd2VpLmNvbSI+c3Vuc2Vh d3FAaHVhd2VpLmNvbTwvQT4mZ3Q7PC9TUEFOPjxCUj4NCiAgPEJMT0NLUVVPVEUgY2xhc3M9Z21h aWxfcXVvdGUgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBw eCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4NCiAgICA8RElWIGJnY29sb3I9 IiNmZmZmZmYiPg0KICAgIDxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj4NCiAgICA8RElWPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPkludGVyZXN0aW5nIHRvcGljLCBBcyB3 ZSBkaXNjdXNzZWQgDQogICAgYmVmb3JlLCB5b3UgdGhvdWdodCBJbnRlcm5ldCBJUCBtb2RlbCZu YnNwO3dhcyBpbnZlbnRlZCBieSAxIFBDLCAxIERlZmF1bHQgDQogICAgR2F0ZXdheSwgMSBkZWZh dWx0IHJvdXRlLiBCdXQgdG9kYXkgaXQgaXMgYSBsaXR0bGUgZGlmZmVyZW50LCBtb2JpbGUgDQog ICAgdGVybWluYWwgaGFzIG11bHRpcGxlIG1vZGVzLCBpdCB3b3VsZCBsaWtlIHRvIHVzZSBhbGwg b2YgdGhlbSBzaW11bGF0ZW5vdXNseSANCiAgICB3aGljaCBvcmdpbmFsIElQIG1vZGVsIGRvZXNu J3Qgd29yayBhbnkgbW9yZSBvbiANCiAgICBpdC48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPjwv RElWPjwvQkxPQ0tRVU9URT4NCiAgPERJVj5UaGFua3MgZm9yIHlvdXIgYWdyZWVtZW50IG9uIHRo aXMgaXNzdWUuPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNsYXNz PWdtYWlsX3F1b3RlIA0KICBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBw eCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+DQogICAgPERJViBiZ2Nv bG9yPSIjZmZmZmZmIj4NCiAgICA8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+DQogICAgPERJ Vj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiBpZD0iIj48L1NQQU4+ PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PTM+SSBjYW4gdW5kZXJzdGFuZCBJRVRGIA0KICAgIG1vcmUmbmJzcDtjb25jZW50cmF0ZXMgb24g c2luZ2xlLXBvaW50IHRlY2hub2xvZ3ksIG5vdCBlbmQgdG8gZW5kIA0KICAgIHNvbHV0aW9uLjwv Rk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0z PkFzIHJlZ2FyZGluZyBJbnRlcm5ldCBJUCBtb2RlbCwgDQogICAgZHVhbCByYWRpbyBtb2RlbCBo YXMgYWxyZWFkeSBiZWVuIGRldmVsb3BpbmcgdG8gc3VwcG9ydCBpbnRlci10ZWNobm9sb2d5IA0K ICAgIGhhbmRvdmVyLiBEdWFsIG1vZGUgdGVtaW5hbCBpcyBub3QgDQogIGZhbmNpZnVsLjwvRk9O VD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPg0KICA8RElWPkNvdWxkIHlv dSBoZWxwIHRvIHdyaXRlIGRvd24gaG93Jm5ic3A7eW91IGltcGxlbWVudCBvbiB0aGlzPzwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5bUWluXVdoYXQgSSB1bmRlcnN0 YW5kIGluIG9yZGVyIHRvIGFjaGlldmUgc2VhbWxlc3MgDQogIGhhbmRvdmVyIGR1cmluZyB0aGUg aW50ZXItdGVjaG5vbG9neSBoYW5kb3ZlciwgdGhlJm5ic3A7VUUgaXMgcmVxdWlyZWQgdG8gDQog IHN1cHBvcnQgZHVhbCBtb2RlLGUuZy4sV2lNQVgmbmJzcDttb2RlIGFuZCZuYnNwO0NETUEgbW9k ZS5CZWZvcmUgVUUgbW92ZXMgZnJvbSANCiAgV2lNQVggYWNjZXNzIG5ldHdvcmsgdG8gdGhlIENE TUEgYWNjZXNzIG5ldHdvcmssIHRoZSBVRSBjYW4gYXR0YWNoIHRvIFdJTUFYIA0KICBhbmQgQ0RN QSBsaW5rIHNpbXV0ZW5ldXNseSxpbiB0aGlzIHNpdHVhdGlvbiwgdGhlIHRyYWZmaWMgY2FuIGJl IGJpY2FzdGVkIHRvIA0KICB0aGUgVUUgdGhyb3VnaCB0d28gbGlua3MsIHRoZSBwYWNrZXQgbG9z cyBjYW4gYmUgYXZvaWRlZCB3aG9sbHksIGhvd2V2ZXIsIHRoZSANCiAgZGlmZmljdWx0eSBpcyB3 aGVuIHRoZSBVRSBmcmVxdWVudGx5IG1vdmVzIGJldHdlZW4gaGV0ZXJnZW5lb3VzIG5ldHdvcmsg YXQgDQogIGhpZ2ggc3BlZWQsIHRoZXJlIGFyZSBncmVhdCBjaGFubGxlbmdlIGZvciB0aGUgVUUg dG8gbWFpbnRhaW4gdGhlIFdpTUFYIGxpbmsgDQogIGFuZCBDRE1BIGxpbmsgc2ltdXRlbmVvdXNs eS48L0ZPTlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0KICBzdHls ZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1M RUZUOiAjY2NjIDFweCBzb2xpZCI+DQogICAgPERJViBiZ2NvbG9yPSIjZmZmZmZmIj4NCiAgICA8 RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9Mz48U1BBTiBpZD0iIj48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+SW4gdGhlIGZ1dHVyZSwgd2l0 aCB0aGUgZGV2ZWxvcG1lbnQgDQogICAgb2YgZmVtdG8gdGVjaG5vbGd5LCBzaW5nbGUgbW9kZSB0 ZW1pbmFsIGNhbiBhY2Nlc3MmbmJzcDttb2JpbGUgbmV0d29yayB2aWEgYSANCiAgICBmZW10byBi YXNlc3RhdGlvbiBhdCBob21lLiBJJm5ic3A7Y2FuIG5vdCAmbmJzcDtqdWRnZSB3aGV0aGVyIHNp bmdsZSByYWRpbyANCiAgICB0ZWNobm9sb2d5IG9yIGR1YWwgcmFkaW8gdGVjaG5vbG9neSB3aWxs IGRvbWluYXRlIHRoZSBmdXR1cmUgbWFya2V0LiBBbnkgDQogICAgd2F5LCBmcm9tIHRoZSB0ZWNo bmljYWwgcGVyc3BlY3RpdmUsIEkgdGhpbmsgdGhlIHRyYWRpdGlvbmFsIGludGVybmV0IElQIA0K ICAgIG1vZGVsIHdpbGwgYmUgZ3JhZHVhbGx5IGV2b2x2aW5nLiBtdWx0aXBsZSBpbnRlcmZhY2Ug cmVxdWlyZW1lbnRzIHdpbGwgDQogICAgYmVjb21lIG9uZSBiaWcgaXNzdWUgdG8gYmUgY29uc2lk ZXJlZCwgZS5nLiwgZHluYW1pYyBwcm92aXNpb24gYW5kIHJvdXRpbmcgLCANCiAgICBjb29yZGlu YXRpb24gYW5kIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc21zIGFyZSBuZWVkZWQgdG8gYmUgZnVy dGhlciANCiAgICBzdHVkeS48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0KICAgIHNpemU9Mz48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9GT05UPjwvRElW PjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPERJVj5pdCBzZWVtcyZuYnNwO3RoYXQgZHluYW1pY2Fs IHByb3Zpc2lvbiBhbmQgcm91dGluZywgY29vcmRpbmF0aW9uIGFuZCANCiAgc3luY2hyb25pemF0 aW9uIHdpbGwgYmVjb21lIG1vcmUgY29tcGxpY2F0ZWQsIHNpbXBsZSB3YXkgbWFrZSBkZXBsb3lt ZW50IGVhc3ksIA0KICBpdCBpcyB0aGUgd2F5IG9mIEludGVybmV0IGV4aXN0PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PltRaW59IEkgYWdyZWUgbW9yZSBvcHRpbWl6 ZWQgYXBwcm9hY2ggY2FuIGJlIHVzZWQgdG8gDQogIGZhY2lsaWF0ZSB1dGlsaXppbmcgdGhlIG5l dHdvcmsgcmVzb3VyY2UgYW5kIGJldHRlciB1c2VyIA0KICBleHBlcmllbmNlLjwvRk9OVD48L0RJ Vj4NCiAgPERJVj50aGFua3M8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj4tSHVp PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1 b3RlIA0KICBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44 ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+DQogICAgPERJViBiZ2NvbG9yPSIjZmZm ZmZmIj4NCiAgICA8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+DQogICAgPERJVj48U1BBTiBp ZD0iIj48L1NQQU4+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz4tUWluPC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSAN CiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+DQogICAgICA8RElWPg0KICAgICAgPERJVj48L0RJVj4NCiAgICAgIDxESVYgY2xhc3M9 V2ozQzdjPg0KICAgICAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0K ICAgICAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNCI+PEI+RnJvbTo8L0I+IDxBIHRp dGxlPWRlbmdodWkwMkBnbWFpbC5jb20gDQogICAgICBocmVmPSJtYWlsdG86ZGVuZ2h1aTAyQGdt YWlsLmNvbSIgdGFyZ2V0PV9ibGFuaz5IdWkgRGVuZzwvQT4gPC9ESVY+DQogICAgICA8RElWPjxC PlRvOjwvQj4gPEEgdGl0bGU9bWlmQGlldGYub3JnIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmci IA0KICAgICAgdGFyZ2V0PV9ibGFuaz5taWZAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICAgICAgPERJ Vj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEphbnVhcnkgMDgsIDIwMDkgMTE6MTMgUE08L0RJVj4N CiAgICAgIDxESVY+PEI+U3ViamVjdDo8L0I+IFttaWZdIE1haWxpbmcgbGlzdCBJc3N1ZTwvRElW Pg0KICAgICAgPERJVj48QlI+PC9ESVY+DQogICAgICA8RElWPkhlbGxvLCBhbGw8L0RJVj4NCiAg ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPkkgc2F3IGxvdHMgb2YgZW1haWwgd2l0 aCZuYnNwOyA8QSBocmVmPSJtYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmciIA0KICAgICAgdGFy Z2V0PV9ibGFuaz5taWYtYm91bmNlc0BpZXRmLm9yZzwvQT4uPC9ESVY+DQogICAgICA8RElWPiZu YnNwOzwvRElWPg0KICAgICAgPERJVj5JdCBzZWVtcyBzb21lIHBlb3BsZSBoYXMgaXNzdWUgd2l0 aCB0aGlzIG1haWxpbmcgbGlzdC48L0RJVj4NCiAgICAgIDxESVY+SWYgdGhhdCBpcyB0aGUgY2Fz ZSwgcGxlYXNlIGRvbid0IGhlc3RpdGF0ZSB0byBsZXQgbWUga25vdyANCnRoYXQsPC9ESVY+DQog ICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj5tYW55IHRoYW5rczwvRElWPg0KICAg ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+LUh1aTwvRElWPjwvRElWPjwvRElWPg0K ICAgICAgPFA+DQogICAgICA8SFI+DQoNCiAgICAgIDxQPjwvUD5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5taWYgbWFpbGluZyANCiAgICAgIGxpc3Q8 QlI+PEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5taWZAaWV0Zi5v cmc8L0E+PEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taWYiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pZjwvQT48QlI+DQogICAgICA8UD48L1A+DQogICAgICA8UD48L1A+ PC9CTE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= --Boundary_(ID_F3gbligIJCRnvzuW0SJwqA)-- --===============0840280535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0840280535==-- From mif-bounces@ietf.org Sat Jan 17 09:56:10 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A913A68AD; Sat, 17 Jan 2009 09:56:10 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CEA3A69CF for ; Sat, 17 Jan 2009 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A3fmFPxLQjb for ; Sat, 17 Jan 2009 09:56:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 4BD3F3A6895 for ; Sat, 17 Jan 2009 09:56:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2218222rvf.49 for ; Sat, 17 Jan 2009 09:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=WrkESSEl7VVOmfGx9ku/zQxb5zUoTZp0v1Hu1EmRyZA=; b=eT8Z/nODhq/1wOzdsiy0AuPtEuvL6Q0I1eW1eJ+AUOPbNq3GZRSL4lKSXv1A08a8Fa steXEfT51G9wV4fPBeL2I2REMtA6Qx/fzHBq+zNBxZCJnHj6FWkvwxHaNL/JoykDhrD6 cNb/q2s7BkrGjuVXhQLmN/p3grHd4drfc6PsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=ItP4CLJQdawuhlLaTyQa+cDC4IiHjhG18pj1hHSaU3KMZpJ61XqXFG8nbrCaNWEZs8 1ROgKW/BXFoCcYgUMgLy9gWrlv/m+60GzFF2faWUqd0sfANU+Cb/zaJ6K/NyflScMvqU tcvEhw8CI+K1yzYSuoZf4pDvnaTRB6W9pNoa0= Received: by 10.142.164.10 with SMTP id m10mr1575573wfe.184.1232214951687; Sat, 17 Jan 2009 09:55:51 -0800 (PST) Received: by 10.142.224.2 with HTTP; Sat, 17 Jan 2009 09:55:51 -0800 (PST) Message-ID: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> Date: Sun, 18 Jan 2009 01:55:51 +0800 From: "Kai Ju" To: denghui02@gmail.com MIME-Version: 1.0 Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1723581367==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1723581367== Content-Type: multipart/alternative; boundary="----=_Part_2279_5077616.1232214951677" ------=_Part_2279_5077616.1232214951677 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Hui As you said, there are multiple way to assign the routing policy by in the mobile access network. As viewed from the aspect of terminal, I think its a good idea that terminal can get its routing policy from the ANDSF. We think a default policy can be used, when terminal can't find corresponding policy in the routing policy from the ANDSF. The default policy can be sent by the network. On another hand, I am a little confused between MIF and Multihoming, would you please help me to clarify the difference between them? Thanks and best regards Kai ------=_Part_2279_5077616.1232214951677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Hui
 
As you said, there are multiple way to assign the routing policy by in the mobile access network. As viewed from the aspect of terminal, I think its a good idea that terminal can get its routing policy from the ANDSF.
 
We think a default policy can be used,  when terminal can't find corresponding policy in the routing policy from the ANDSF. The default policy can be sent by the network.
 
On another hand, I am a little confused between MIF and Multihoming, would you please help me to clarify the difference between them?
 
Thanks and best regards
 
Kai
 
 
------=_Part_2279_5077616.1232214951677-- --===============1723581367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1723581367==-- From mif-bounces@ietf.org Sat Jan 17 21:35:31 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED4C3A6AC8; Sat, 17 Jan 2009 21:35:31 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A062F3A6B1A for ; Sat, 17 Jan 2009 07:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA7uB3X8Iknr for ; Sat, 17 Jan 2009 07:15:08 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 9D71E3A6880 for ; Sat, 17 Jan 2009 07:15:07 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so1437553tib.25 for ; Sat, 17 Jan 2009 07:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=rewbTv3zW7P9v4xoOr1hYXM2baUDw8a443v8lnqiXmE=; b=pG8FCUQUoHxkmkIt4TTOdGNFEcZVqvsKMWkCdIlOW+iM8+YlYnbohWr0bPfQv/ThVG G7quum5rsaH431CE+mdS7aQexZ703nL/3R4+Z8doZRK4rGh9+PjjQK+TOqxm6IyXjc00 PPlmkC9/NJi3dqI5+5m2Eu52zaUYwstk4F4yQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=mckVWCbsGBUQz+AmWld3e5sJECQFm2mZwlYkSoaCq8WY9HZSbSSO9gCMwUrvoAtR2b enhqdOQzoqrP4k0YQoYR9XLbSLX3azKXzI4ScXrt/Y+cqfAKgR6SC04kUHb6F68yOSF9 q4Mg0zgHr8KnfGp2l01rhUHSLP60xjDOoEJE8= Received: by 10.110.93.12 with SMTP id q12mr5132806tib.8.1232205290492; Sat, 17 Jan 2009 07:14:50 -0800 (PST) Received: from hwj ([219.243.215.245]) by mx.google.com with ESMTPS id 2sm4056769tif.33.2009.01.17.07.14.48 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jan 2009 07:14:49 -0800 (PST) Date: Sat, 17 Jan 2009 23:15:18 +0800 From: "shshrosh" To: "mif" Message-ID: <200901172315172652691@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Subject: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145095847==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0145095847== Content-Type: multipart/alternative; boundary="=====003_Dragon334138627705_=====" This is a multi-part message in MIME format. --=====003_Dragon334138627705_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, all I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B? --=====003_Dragon334138627705_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hello, all
 
I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?
--=====003_Dragon334138627705_=====-- --===============0145095847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0145095847==-- From mif-bounces@ietf.org Sat Jan 17 22:05:09 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041603A69D4; Sat, 17 Jan 2009 22:05:09 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84ED03A6922 for ; Sat, 17 Jan 2009 22:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+mGwTVv6-M3 for ; Sat, 17 Jan 2009 22:05:06 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 380853A67CC for ; Sat, 17 Jan 2009 22:05:06 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so1562049tib.25 for ; Sat, 17 Jan 2009 22:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=z5r1PSeaM4lpWP+YEUMaT4zjM+ktMUTDi1JnpdZmw4g=; b=wKo8+bMxxZv4GoX6IR6NeeTkUno2sa0x+r+rFLdQbbYfGANBzp+t87gMVHzyFMJ42e 8R/vclmNSIl9P4g7M0Fdz1IXzvWtZLc8NEZL0/EPlYv9WLYpFK147/okvptAEnenGJuG jivIJ1yiB3LDzYuuOyTAeZbTGVzlbKHHICsBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=KyMqWjuKIcRvUNCzCqgYBzaCVPB7UaFYMTQm44FY1wiaD/y95vRfSjV0XoNlo4nVio 481oMJveb8fq8rgDdDwoIpW1rykWwqIn2DFkHBTvZH5JeBFQ/MU+vhoFoPrBV5wr3fKz 2fsD68LvrXzHwTl2rJ2KQ7GK5dXhnWz6A8BzU= Received: by 10.110.11.7 with SMTP id 7mr5881977tik.40.1232258688825; Sat, 17 Jan 2009 22:04:48 -0800 (PST) Received: from hwj ([219.243.215.245]) by mx.google.com with ESMTPS id i6sm5556538tid.16.2009.01.17.22.04.46 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jan 2009 22:04:47 -0800 (PST) Date: Sun, 18 Jan 2009 14:05:17 +0800 From: "shshrosh" To: "mif" Message-ID: <200901181405165005812@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Subject: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239908656==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0239908656== Content-Type: multipart/alternative; boundary="=====003_Dragon327337374760_=====" This is a multi-part message in MIME format. --=====003_Dragon327337374760_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, all I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B? --=====003_Dragon327337374760_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hello, all
 
I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?
--=====003_Dragon327337374760_=====-- --===============0239908656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0239908656==-- From mif-bounces@ietf.org Sat Jan 17 22:30:00 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6933A6AC8; Sat, 17 Jan 2009 22:30:00 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEF13A6AB1 for ; Sat, 17 Jan 2009 22:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5J1ihij7yQy for ; Sat, 17 Jan 2009 22:29:59 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 0E63D3A6A90 for ; Sat, 17 Jan 2009 22:29:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2616986wfd.31 for ; Sat, 17 Jan 2009 22:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=JPsOTuw9ofY4HGRTOZ0k4au2jTpQcNmQ+CkbCfA4tFY=; b=EGVY0Cs5tF3mPyBIA3yll/0wb+/MrCyK10mX/wxXg3KJHW/+ebshuKHr3OXBcbYgWD v89pJIgV+Wi8fn+ArtpK1hg35TLjhvVBOCkt1DOAEs/w5pzMwePzYbHse16BMc+1rhVC 5kCYs0+uLC2ktqjkqCzazQivD8+2u8kMEWAT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=MOtuIQKh+f5ZrYfzmNZM5iX3CoopSjm953mkHcTLFK8Lu3TkevS5pVZprb53WHPsci fUDbP8hJ41bQlkodu2YpewLz8249uObu8SE0CYYGN0fkrDe+PdO1za1JGxoLzVzrXs0i CYToyVzlAyphw91q0CkFemNGWrM8gVDS0zVak= Received: by 10.142.172.12 with SMTP id u12mr1806985wfe.26.1232260182348; Sat, 17 Jan 2009 22:29:42 -0800 (PST) Received: by 10.142.224.2 with HTTP; Sat, 17 Jan 2009 22:29:42 -0800 (PST) Message-ID: <3db7b9d60901172229o5f4b0bcwa2afa6440841efec@mail.gmail.com> Date: Sun, 18 Jan 2009 14:29:42 +0800 From: "Kai Ju" To: shshrosh In-Reply-To: <200901181405165005812@gmail.com> MIME-Version: 1.0 References: <200901181405165005812@gmail.com> Cc: mif Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1944124774==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1944124774== Content-Type: multipart/alternative; boundary="----=_Part_4407_4437522.1232260182345" ------=_Part_4407_4437522.1232260182345 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Glad to see your question, because it's a typical user case about multiple interface. As I know, when one interface of B has failed, the network should get it, then ask B to change the IP flow from the failed interface to another. At the same time, A should know all transformation to maintain their communication from the network. I prefer the ANDSF to do this work. If you still have other questions, please feel free to raise them, thanks. 2009/1/18 shshrosh > Hello, all > > I have a problem about multiple interface. Suppose host A communicates with > host B, which has multiple interfaces. When one interface of B fails, A may > switch to the address of another interface of B to maintain the > communication. But how can A know the two addresses corresponde to the same > host B? > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ------=_Part_4407_4437522.1232260182345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
Glad to see your question, because it's a typical user case about multiple interface.
 
As I know, when one interface of B has failed, the network should get it, then ask B to change the IP flow from the failed interface to another. At the same time, A should know all transformation to maintain their communication from the network. I prefer the ANDSF to do this work.
If you still have other questions, please feel free to raise them, thanks.
2009/1/18 shshrosh <shshrosh@gmail.com>
Hello, all
 
I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


------=_Part_4407_4437522.1232260182345-- --===============1944124774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1944124774==-- From mif-bounces@ietf.org Sat Jan 17 23:07:12 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006663A681F; Sat, 17 Jan 2009 23:07:12 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3226D3A681F for ; Sat, 17 Jan 2009 23:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxG42c6o-eJl for ; Sat, 17 Jan 2009 23:07:10 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id E7CB73A6810 for ; Sat, 17 Jan 2009 23:07:09 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so1476656tib.22 for ; Sat, 17 Jan 2009 23:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:references :subject:message-id:x-mailer:mime-version:content-type; bh=EMwzRd9eFvFurW9QCLIVQT2pyV7FzUYV4K20APWKsJM=; b=uYldEb2xPZ0Lq+GpIAf4uN78PrLqA3rm0QRpyEzqnvXur+hSPfba95VyqMgDXWRbzX XiStOnl2MNEgVsYWN9GCXBRj1QMJE7t+AhjqbzlQ/nfu9ujFrPoTb31lpzZjnstxarPx wpnuRs757eyFptk1cQAVXKv+rV04XUUxoVoyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=eaJOrPCV5QTtCX+fpHIYqcMErTy8aS7v8rJWC4y/Ttc1vbWHh2fUJzl7G6XuLhltPo ezO+6qXqYhx/CC9CTppI7Zl9LimwF6RAAnH4+nhY3P54usuZaOtS54gi36dB13fTVWAg NLSqLnRqhDlhzhauKN7hcZ8y66/umW5rS2WiI= Received: by 10.110.28.15 with SMTP id b15mr5960473tib.56.1232262413389; Sat, 17 Jan 2009 23:06:53 -0800 (PST) Received: from hwj ([219.243.215.245]) by mx.google.com with ESMTPS id d7sm2482799tib.37.2009.01.17.23.06.50 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jan 2009 23:06:51 -0800 (PST) Date: Sun, 18 Jan 2009 15:07:21 +0800 From: "=?utf-8?B?c2hzaHJvc2g=?=" To: "=?utf-8?B?S2FpIEp1?=" References: <200901181405165005812@gmail.com>, <3db7b9d60901172229o5f4b0bcwa2afa6440841efec@mail.gmail.com> Message-ID: <200901181507195318824@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Cc: =?utf-8?B?bWlm?= Subject: Re: [mif] =?utf-8?q?How_to_identify_a_host_with_multiple_interfaces?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689064410==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1689064410== Content-Type: multipart/alternative; boundary="=====003_Dragon888520321887_=====" This is a multi-part message in MIME format. --=====003_Dragon888520321887_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gS2FpSnUsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhZHZpY2UuDQpJIGtub3cgbGl0dGxl IGFib3V0IEFORFNGLiBJcyBpdCBhIGRyYWZ0IG9yIGFuIFJGQz8NCg0K5Y+R5Lu25Lq677yaIEth aSBKdSANCuWPkemAgeaXtumXtO+8miAyMDA5LTAxLTE4ICAxNDoyOTo0MyANCuaUtuS7tuS6uu+8 miBzaHNocm9zaCANCuaKhOmAge+8miBtaWYgDQrkuLvpopjvvJogUmU6IFttaWZdIEhvdyB0byBp ZGVudGlmeSBhIGhvc3Qgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzIA0KIA0KSGksDQoNCkdsYWQg dG8gc2VlIHlvdXIgcXVlc3Rpb24sIGJlY2F1c2UgaXQncyBhIHR5cGljYWwgdXNlciBjYXNlIGFi b3V0IG11bHRpcGxlIGludGVyZmFjZS4gDQoNCkFzIEkga25vdywgd2hlbiBvbmUgaW50ZXJmYWNl IG9mIEIgaGFzIGZhaWxlZCwgdGhlIG5ldHdvcmsgc2hvdWxkIGdldCBpdCwgdGhlbiBhc2sgQiB0 byBjaGFuZ2UgdGhlIElQIGZsb3cgZnJvbSB0aGUgZmFpbGVkIGludGVyZmFjZSB0byBhbm90aGVy LiBBdCB0aGUgc2FtZSB0aW1lLCBBIHNob3VsZCBrbm93IGFsbCB0cmFuc2Zvcm1hdGlvbiB0byBt YWludGFpbiB0aGVpciBjb21tdW5pY2F0aW9uIGZyb20gdGhlIG5ldHdvcmsuIEkgcHJlZmVyIHRo ZSBBTkRTRiB0byBkbyB0aGlzIHdvcmsuDQoNCklmIHlvdSBzdGlsbCBoYXZlIG90aGVyIHF1ZXN0 aW9ucywgcGxlYXNlIGZlZWwgZnJlZSB0byByYWlzZSB0aGVtLCB0aGFua3MuDQoNCjIwMDkvMS8x OCBzaHNocm9zaCA8c2hzaHJvc2hAZ21haWwuY29tPg0KDQpIZWxsbywgYWxsDQoNCkkgaGF2ZSBh IHByb2JsZW0gYWJvdXQgbXVsdGlwbGUgaW50ZXJmYWNlLiBTdXBwb3NlIGhvc3QgQSBjb21tdW5p Y2F0ZXMgd2l0aCBob3N0IEIsIHdoaWNoIGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzLiBXaGVuIG9u ZSBpbnRlcmZhY2Ugb2YgQiBmYWlscywgQSBtYXkgc3dpdGNoIHRvIHRoZSBhZGRyZXNzIG9mIGFu b3RoZXIgaW50ZXJmYWNlIG9mIEIgdG8gbWFpbnRhaW4gdGhlIGNvbW11bmljYXRpb24uIEJ1dCBo b3cgY2FuIEEga25vdyB0aGUgdHdvIGFkZHJlc3NlcyBjb3JyZXNwb25kZSB0byB0aGUgc2FtZSBo b3N0IEI/DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptaWYgbWFpbGluZyBsaXN0DQptaWZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlmDQo= --=====003_Dragon888520321887_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5h Ow0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBTZWN0 aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5 DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05U LVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVz dGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7 DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5v cm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2Vj dGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJ TUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0N Ck9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1B UkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGVsbG8mbmJzcDtLYWlK dSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+PEZPTlQgY29sb3I9IzAwMDA4MD5U aGFuayB5b3UgZm9yIHlvdXIgDQphZHZpY2UuPC9GT05UPjwvRElWPg0KPERJViBzdHlsZT0iVEVY VC1JTkRFTlQ6IDJlbSI+PEZPTlQgY29sb3I9IzAwMDA4MD5JIGtub3cgbGl0dGxlIGFib3V0IEFO RFNGLiBJcyANCml0IGEgZHJhZnQgb3IgYW4gUkZDPzwvRk9OVD48L0RJVj4NCjxESVYgc3R5bGU9 IlRFWFQtSU5ERU5UOiAyZW0iPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R5Lu25Lq677yaPC9T VFJPTkc+IEthaSBKdSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz7lj5HpgIHml7bpl7TvvJo8L1NUUk9ORz4gMjAwOS0wMS0xOCZuYnNwOyAxNDoy OTo0MyANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RS T05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiBzaHNocm9zaCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gbWlmIDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuS4u+mi mO+8mjwvU1RST05HPiBSZTogW21pZl0gSG93IHRvIGlkZW50aWZ5IGEgDQpob3N0IHdpdGggbXVs dGlwbGUgaW50ZXJmYWNlcyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxE SVY+SGksPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5HbGFkIHRvIHNlZSB5b3VyIHF1 ZXN0aW9uLCBiZWNhdXNlIGl0J3MgYSB0eXBpY2FsIHVzZXIgY2FzZSBhYm91dCBtdWx0aXBsZSAN CmludGVyZmFjZS4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BcyBJIGtub3csIHdo ZW4gb25lIGludGVyZmFjZSBvZiBCIGhhcyBmYWlsZWQsIHRoZSBuZXR3b3JrIHNob3VsZCBnZXQg DQppdCwmbmJzcDt0aGVuIGFzayBCIHRvIGNoYW5nZSB0aGUgSVAgZmxvdyBmcm9tIHRoZSBmYWls ZWQgaW50ZXJmYWNlIHRvIGFub3RoZXIuIA0KQXQgdGhlIHNhbWUgdGltZSwgQSBzaG91bGQga25v dyBhbGwgdHJhbnNmb3JtYXRpb24gdG8gbWFpbnRhaW4gdGhlaXIgDQpjb21tdW5pY2F0aW9uIGZy b20gdGhlIG5ldHdvcmsuIEkgcHJlZmVyIHRoZSBBTkRTRiB0byBkbyB0aGlzIHdvcmsuPEJSPjwv RElWPg0KPERJVj5JZiB5b3Ugc3RpbGwgaGF2ZSBvdGhlciBxdWVzdGlvbnMsIHBsZWFzZSBmZWVs IGZyZWUgdG8gcmFpc2UgdGhlbSwgDQp0aGFua3MuPEJSPjwvRElWPg0KPERJViBjbGFzcz1nbWFp bF9xdW90ZT4yMDA5LzEvMTggc2hzaHJvc2ggPFNQQU4gZGlyPWx0cj4mbHQ7PEEgDQpocmVmPSJt YWlsdG86c2hzaHJvc2hAZ21haWwuY29tIj5zaHNocm9zaEBnbWFpbC5jb208L0E+Jmd0OzwvU1BB Tj48QlI+DQo8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCnN0eWxlPSJQQURESU5HLUxF RlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4 IHNvbGlkIj4NCiAgPERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVy ZGFuYSI+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCiAgPERJVj48Rk9OVCBm YWNlPVZlcmRhbmEgc2l6ZT0yPjxTUEFOPjwvU1BBTj5IZWxsbywgYWxsPC9GT05UPjwvRElWPg0K ICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWIHN0eWxlPSJURVhULUlOREVOVDogMmVtIj5JIGhh dmUgYSBwcm9ibGVtIGFib3V0IG11bHRpcGxlIGludGVyZmFjZS4gDQogIFN1cHBvc2UgaG9zdCBB IGNvbW11bmljYXRlcyB3aXRoIGhvc3QgQiwgd2hpY2ggaGFzIG11bHRpcGxlIGludGVyZmFjZXMu IFdoZW4gDQogIG9uZSBpbnRlcmZhY2Ugb2YgQiBmYWlscywgQSBtYXkgc3dpdGNoIHRvIHRoZSBh ZGRyZXNzIG9mIGFub3RoZXIgaW50ZXJmYWNlIG9mIA0KICBCIHRvJm5ic3A7bWFpbnRhaW4gdGhl IGNvbW11bmljYXRpb24uIEJ1dCBob3cgY2FuIEEga25vdyB0aGUgdHdvIGFkZHJlc3NlcyANCiAg Y29ycmVzcG9uZGUgdG8gdGhlIHNhbWUgaG9zdCBCPzwvRElWPjwvRk9OVD48Rk9OVCBmYWNlPVZl cmRhbmEgDQogIHNpemU9Mj48L0ZPTlQ+PC9ESVY+PC9ESVY+PEJSPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm1pZiANCiAgbWFpbGluZyBsaXN0PEJS PjxBIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciPm1pZkBpZXRmLm9yZzwvQT48QlI+PEEgDQog IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmIiANCiAgdGFy Z2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZjwvQT48 QlI+PEJSPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= --=====003_Dragon888520321887_=====-- --===============1689064410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1689064410==-- From mif-bounces@ietf.org Sun Jan 18 18:32:23 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F403A69EB; Sun, 18 Jan 2009 18:32:23 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429593A68C9 for ; Sun, 18 Jan 2009 18:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzxX5N7wYhtD for ; Sun, 18 Jan 2009 18:32:20 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 3FEC53A68B1 for ; Sun, 18 Jan 2009 18:32:20 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2159752ywj.49 for ; Sun, 18 Jan 2009 18:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HkyXMnI1YNEzJqMfIwHeQJOlI2tfKJ/ZIFQQBtMTgTA=; b=DfYSItPrEdRrjnaEVZh78xVjy96/eSBt71r2DgNvuQyAKwBSktbgierpGwlqSY/CHp R5thGHUVv7pczh5qSvhNSnWl5z8O5+572SyxcHLf34ILyoWbMgYpmbRffwecLbvs/RoM MG6jKeNQAy5TIQIlQQscz39CQQh6lEtpbr5tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gsQsbi8jarIgzlcnFU3AHEqZtvgGE8S3y5/Y3v4WFvRzZK2WMx//Fjb6CTkqXh4Ovn VZ0DE7mZ0keOGklYlrD/hTJUGm2iMCaprmxoqjRpHXSW00smzZMU3dC1Hg8iAB8n6Yhv BDc4qID1i/npXU03uLSWHsCe/wNecNCFCaOXE= MIME-Version: 1.0 Received: by 10.100.207.14 with SMTP id e14mr3617897ang.60.1232331847169; Sun, 18 Jan 2009 18:24:07 -0800 (PST) In-Reply-To: <01c901c97899$12dd4430$0201a8c0@china.huawei.com> References: <1d38a3350901131435v9995ebai80880b98b0456e7c@mail.gmail.com> <01c901c97899$12dd4430$0201a8c0@china.huawei.com> Date: Mon, 19 Jan 2009 10:24:07 +0800 Message-ID: <4c5c7a6d0901181824n3f6aa313y4c2120ee1bcd0a06@mail.gmail.com> From: Peny Yang To: w53375 Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Qin: It's a interesting point. Check the lines below: On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: > Thanks for your reply, Please see the follow up comments below. > -Qin > > ----- Original Message ----- > From: Hui Deng > To: Qin Wu > Cc: mif@ietf.org > Sent: Wednesday, January 14, 2009 6:35 AM > Subject: IP model for multiple mode mobile terminal > Hi, Qin, > > Thanks for your comments. see below inline reply. > 2009/1/8 Qin Wu >> >> Interesting topic, As we discussed before, you thought Internet IP >> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it >> is a little different, mobile terminal has multiple modes, it would like to >> use all of them simulatenously which orginal IP model doesn't work any more >> on it. > > [Qin]What I understand in order to achieve seamless handover during the > inter-technology handover, the UE is required to support dual > mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access network > to the CDMA access network, the UE can attach to WIMAX and CDMA link > simuteneusly,in this situation, the traffic can be bicasted to the UE > through two links, the packet loss can be avoided wholly, however, the > difficulty is when the UE frequently moves between hetergeneous network at > high speed, there are great chanllenge for the UE to maintain the WiMAX link > and CDMA link simuteneously. [Peny] Are you talking about MIP case or non-MIP case? In case of MIP, I agree with you. In case of non-MIP, it seems in IETF there is no way to bi-cast the streams to two different interfaces with two addresses of MN. I just review the discussion in this list. Personally, I think MIF is to solve the issue of GENERIC IP model. As hui said previously, IP model should no longer have the original assumption of "one link" as many terminals have multiple links so far. MIP has the way to support the multiple links in MN. I once did some work on this as well. Basically, Generic MIP solution is not adequate to make the seamless handover. It needs some low layer modifications (such as one address for multiple link, prevent the high layers to detecting the link transfer event, etc). All the problems originated from the "one default link" design of current OS. Maybe it's the time to do something to improve the generic IP model for multiple link support in MN. > it seems that dynamical provision and routing, coordination and > synchronization will become more complicated, simple way make deployment > easy, it is the way of Internet exist > [Qin} I agree more optimized approach can be used to faciliate utilizing the > network resource and better user experience. > thanks [Peny] I agree with you two as well. BRG Peny _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Sun Jan 18 18:47:55 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC1F3A68B1; Sun, 18 Jan 2009 18:47:55 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDDD3A68B1 for ; Sun, 18 Jan 2009 18:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZFr18Q82-5r for ; Sun, 18 Jan 2009 18:47:53 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 6C9073A68A4 for ; Sun, 18 Jan 2009 18:47:53 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2159598yxg.49 for ; Sun, 18 Jan 2009 18:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MR/Azk8N5T3wg0S02gr9fuFU/va+C41f+TVy/FR4heA=; b=BembKDTOM/4X3q51qWSe/nm/dikUqfImO+kTphAT6jI4Nl3CJdttlG/iazFphoSKqh gtfakB67J61CNojFNSKSiuul59VDKL3CPzOCxldt6oe82eQuoRjMpm0c9ZHbxJyqSwLV Lk/MCN3MOPog2j+48TJ+jfHW1RksT0s6lWRlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l9v9tV0Y9CPdyrjpjHn0egQP1YnS0JNX49NvZ0FHYpYuJfKI5iRBI0VDIhrw9G6G59 FO7n7fwAQROCxXzB3Ot1mMhqfDXLyoW/ROVq/QSQ6xhbsiWtbAKbHNzgE5KW4pi8eCL0 ko2cAx3WT+ltx/upSZOHsr8l28FYZ/XvFXleI= MIME-Version: 1.0 Received: by 10.100.163.8 with SMTP id l8mr3617826ane.127.1232333256674; Sun, 18 Jan 2009 18:47:36 -0800 (PST) In-Reply-To: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> Date: Mon, 19 Jan 2009 10:47:36 +0800 Message-ID: <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> From: Peny Yang To: Kai Ju Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Kai: Nice point. Please check the lines below: > As you said, there are multiple way to assign the routing policy by in the > mobile access network. As viewed from the aspect of terminal, I think its a > good idea that terminal can get its routing policy from the ANDSF. [Peny] ANDSF may be one of the choices. But ANDSF just follows the assumption of generic "one default link" IP model. So, in 3GPP, even though ANDSF can help UE to select accesses and find the route, UE can only choose one of the interfaces as a result. Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, since it's a specific definition in one SDO. > We think a default policy can be used, when terminal can't find > corresponding policy in the routing policy from the ANDSF. The default > policy can be sent by the network. [Peny] Could we give a chance to MN to change the policy (like user preference) ? > On another hand, I am a little confused between MIF and Multihoming, would > you please help me to clarify the difference between them? [Peny] I am also not clear yet. Just give some lines as a seed for discussion. In my personal feeling, MIF is to change the "one default link" feature of current generic IP model. Multi-homing is to ensure the reachability and reliability of IP network. Well, in multi-homing MN scenarios, multi-link-multi-address is also one case. But, in this case, MN only can choose one link as default. Some other comments? BRG Peny _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Sun Jan 18 22:55:59 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC013A68F9; Sun, 18 Jan 2009 22:55:59 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6023A6B2A for ; Sun, 18 Jan 2009 22:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCZGpzHd2Yjd for ; Sun, 18 Jan 2009 22:55:56 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 4A3AF3A67AA for ; Sun, 18 Jan 2009 22:55:56 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1470247wag.5 for ; Sun, 18 Jan 2009 22:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=OXRDAJ9hwGw0t/68plDNLjs1ZUQvcHowxQgI5P0FwQw=; b=eRRXueotUVNvMy0r0V7QU5qZeWqEfu/cT/jsYjGTCROIuFbY4W9Gk8I2TWzp8d6rMc uKzycIU0Cmxa+MXfd5hn87nHm7w0m0RE9BJaFOxX94C3zemcqHa0Bj/rtJorqTBTnQU3 vSkzWH+P7yx0Um5aRD3Fgb6cN7pk/8mR9upwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=CSoES3KzdkKseyToUocDRBzgLDFHDz+nrbxo/oX25VqGw9NaHXJh5Ru45R57jnXqfR 997o0nv3NjaUqNk86sDU7FhutTU5vSM0g4tHcbpM+39ioe0qNwzKXVmBtJDEeo6UsnOp 2CxGoXA2eXWbO/QoBsp5QkFz4MdkmcmbtR5Yo= Received: by 10.114.36.4 with SMTP id j4mr2704878waj.119.1232348140176; Sun, 18 Jan 2009 22:55:40 -0800 (PST) Received: by 10.115.16.13 with HTTP; Sun, 18 Jan 2009 22:55:40 -0800 (PST) Message-ID: <1d38a3350901182255h4dc067fdw9be0333e839d72fb@mail.gmail.com> Date: Mon, 19 Jan 2009 14:55:40 +0800 From: "Hui Deng" To: "Peny Yang" In-Reply-To: <4c5c7a6d0901181824n3f6aa313y4c2120ee1bcd0a06@mail.gmail.com> MIME-Version: 1.0 References: <1d38a3350901131435v9995ebai80880b98b0456e7c@mail.gmail.com> <01c901c97899$12dd4430$0201a8c0@china.huawei.com> <4c5c7a6d0901181824n3f6aa313y4c2120ee1bcd0a06@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0738969874==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0738969874== Content-Type: multipart/alternative; boundary="----=_Part_11384_28818937.1232348140170" ------=_Part_11384_28818937.1232348140170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What Peng pointed out here is really what we would like to work on, Many thanks -Hui 2009/1/19 Peny Yang > Hi, Qin: > > It's a interesting point. Check the lines below: > > On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: > > Thanks for your reply, Please see the follow up comments below. > > -Qin > > > > ----- Original Message ----- > > From: Hui Deng > > To: Qin Wu > > Cc: mif@ietf.org > > Sent: Wednesday, January 14, 2009 6:35 AM > > Subject: IP model for multiple mode mobile terminal > > Hi, Qin, > > > > Thanks for your comments. see below inline reply. > > 2009/1/8 Qin Wu > >> > >> Interesting topic, As we discussed before, you thought Internet IP > >> model was invented by 1 PC, 1 Default Gateway, 1 default route. But > today it > >> is a little different, mobile terminal has multiple modes, it would like > to > >> use all of them simulatenously which orginal IP model doesn't work any > more > >> on it. > > > > [Qin]What I understand in order to achieve seamless handover during the > > inter-technology handover, the UE is required to support dual > > mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access > network > > to the CDMA access network, the UE can attach to WIMAX and CDMA link > > simuteneusly,in this situation, the traffic can be bicasted to the UE > > through two links, the packet loss can be avoided wholly, however, the > > difficulty is when the UE frequently moves between hetergeneous network > at > > high speed, there are great chanllenge for the UE to maintain the WiMAX > link > > and CDMA link simuteneously. > [Peny] Are you talking about MIP case or non-MIP case? > In case of MIP, I agree with you. > In case of non-MIP, it seems in IETF there is no way to bi-cast the > streams to two different interfaces with two addresses of MN. > I just review the discussion in this list. Personally, I think MIF is > to solve the issue of GENERIC IP model. As hui said previously, IP > model should no longer have the original assumption of "one link" as > many terminals have multiple links so far. > MIP has the way to support the multiple links in MN. I once did some > work on this as well. Basically, Generic MIP solution is not adequate > to make the seamless handover. It needs some low layer modifications > (such as one address for multiple link, prevent the high layers to > detecting the link transfer event, etc). All the problems originated > from the "one default link" design of current OS. Maybe it's the time > to do something to improve the generic IP model for multiple link > support in MN. > > > it seems that dynamical provision and routing, coordination and > > synchronization will become more complicated, simple way make deployment > > easy, it is the way of Internet exist > > [Qin} I agree more optimized approach can be used to faciliate utilizing > the > > network resource and better user experience. > > thanks > [Peny] I agree with you two as well. > > BRG > Peny > ------=_Part_11384_28818937.1232348140170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
What Peng pointed out here is really what we would like to work on,
Many thanks
 
-Hui

2009/1/19 Peny Yang <peng.yang.chn@gmail.com>
Hi, Qin:

It's a interesting point. Check the lines below:

On Sat, Jan 17, 2009 at 7:03 PM, w53375 <sunseawq@huawei.com> wrote:
> Thanks for your reply, Please see the follow up comments below.
> -Qin
>
> ----- Original Message -----
> From: Hui Deng
> To: Qin Wu
> Cc: mif@ietf.org
> Sent: Wednesday, January 14, 2009 6:35 AM
> Subject: IP model for multiple mode mobile terminal
> Hi, Qin,
>
> Thanks for your comments. see below inline reply.
> 2009/1/8 Qin Wu <sunseawq@huawei.com>
>>
>> Interesting topic, As we discussed before, you thought Internet IP
>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it
>> is a little different, mobile terminal has multiple modes, it would like to
>> use all of them simulatenously which orginal IP model doesn't work any more
>> on it.
>
> [Qin]What I understand in order to achieve seamless handover during the
> inter-technology handover, the UE is required to support dual
> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access network
> to the CDMA access network, the UE can attach to WIMAX and CDMA link
> simuteneusly,in this situation, the traffic can be bicasted to the UE
> through two links, the packet loss can be avoided wholly, however, the
> difficulty is when the UE frequently moves between hetergeneous network at
> high speed, there are great chanllenge for the UE to maintain the WiMAX link
> and CDMA link simuteneously.
[Peny] Are you talking about MIP case or non-MIP case?
In case of MIP, I agree with you.
In case of non-MIP, it seems in IETF there is no way to bi-cast the
streams to two different interfaces with two addresses of MN.
I just review the discussion in this list. Personally, I think MIF is
to solve the issue of GENERIC  IP model. As hui said previously, IP
model should no longer have the original assumption of "one link" as
many terminals have multiple links so far.
MIP has the way to support the multiple links in MN. I once did some
work on this as well. Basically, Generic MIP solution is not adequate
to make the seamless handover. It needs some low layer modifications
(such as one address for multiple link, prevent the high layers to
detecting the link transfer event, etc). All the problems originated
from the "one default link" design of current OS. Maybe it's the time
to do something to improve the generic IP model for multiple link
support in MN.

> it seems that dynamical provision and routing, coordination and
> synchronization will become more complicated, simple way make deployment
> easy, it is the way of Internet exist
> [Qin} I agree more optimized approach can be used to faciliate utilizing the
> network resource and better user experience.
> thanks
[Peny] I agree with you two as well.

BRG
Peny

------=_Part_11384_28818937.1232348140170-- --===============0738969874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0738969874==-- From mif-bounces@ietf.org Sun Jan 18 23:06:10 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0133A683D; Sun, 18 Jan 2009 23:06:10 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CDF28C15C for ; Sun, 18 Jan 2009 23:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6l0GWowcLEx for ; Sun, 18 Jan 2009 23:06:09 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 06CEB3A6803 for ; Sun, 18 Jan 2009 23:06:09 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2656283rvf.49 for ; Sun, 18 Jan 2009 23:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ACTJBz49f3OcsQZmhDyo6Sitj7H7qVdsuQ2qAcVAS/s=; b=k+3bUWhvv3eSVxMM72gEFJ8Z4iLj1gIozeWz/jSl33UPNCzS260suelDH7PdxdqNHB ldY13y8ivMVqT0gvGrfyeLMYpXyA4jK16ncXscAwa+tYk183PYprf5RAtweu9RiKgy/S 0nBNKmKzMYTd7lIMEQFOES78oUij37wovgr9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=uVs5BkLpZLWFK6Zx3J74aJbd9ajSEuqxzDjAC1JeupAPe4ZWaayNThKDBQmm5LgGCg EcBHC9pZug53m2vcM10dPyADFufGzwh4WgLVuN8A3G7COVW0qMbfML/dLytOWZcs9nnX dcijWO565KSzIunQ8wAkc8llKZYa+qAjUe4dE= Received: by 10.114.201.1 with SMTP id y1mr3826306waf.154.1232348752134; Sun, 18 Jan 2009 23:05:52 -0800 (PST) Received: by 10.115.16.13 with HTTP; Sun, 18 Jan 2009 23:05:52 -0800 (PST) Message-ID: <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> Date: Mon, 19 Jan 2009 15:05:52 +0800 From: "Hui Deng" To: "Peny Yang" In-Reply-To: <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> MIME-Version: 1.0 References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621388791==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1621388791== Content-Type: multipart/alternative; boundary="----=_Part_11414_29335933.1232348752129" ------=_Part_11414_29335933.1232348752129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Peng and Kai, See reply inline below. thanks for the discussion. 2009/1/19 Peny Yang > Hi, Kai: > Nice point. Please check the lines below: > > > As you said, there are multiple way to assign the routing policy by in > the > > mobile access network. As viewed from the aspect of terminal, I think its > a > > good idea that terminal can get its routing policy from the ANDSF. > [Peny] ANDSF may be one of the choices. But ANDSF just follows the > assumption of generic "one default link" IP model. So, in 3GPP, even > though ANDSF can help UE to select accesses and find the route, UE can > only choose one of the interfaces as a result. > Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, > since it's a specific definition in one SDO. ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for 23.402 for non-3GPP access still a issue, it may need some mechanism to coordinate between two type of access entwork.what do you think? > > > We think a default policy can be used, when terminal can't find > > corresponding policy in the routing policy from the ANDSF. The default > > policy can be sent by the network. > [Peny] Could we give a chance to MN to change the policy (like user > preference) ? > > > On another hand, I am a little confused between MIF and Multihoming, > would > > you please help me to clarify the difference between them? > [Peny] I am also not clear yet. Just give some lines as a seed for > discussion. In my personal feeling, MIF is to change the "one default > link" feature of current generic IP model. Multi-homing is to ensure > the reachability and reliability of IP network. Well, in multi-homing > MN scenarios, multi-link-multi-address is also one case. But, in this > case, MN only can choose one link as default. > Some other comments? > To challenge one default link, it really takes time for mif to consider on it, current first step in mif is to consider some straight forward way which is simple to resolve some issues. Regarding to multi-homing, I guess that it is more site multi-homing. For last multi-link-multi-address mn's scenario, it will be one of MIF scenario. thanks -Hui > > BRG > Peny > ------=_Part_11414_29335933.1232348752129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Peng and Kai,
 
See reply inline below. thanks for the discussion.
2009/1/19 Peny Yang <peng.yang.chn@gmail.com>
Hi, Kai:
Nice point. Please check the lines below:

> As you said, there are multiple way to assign the routing policy by in the
> mobile access network. As viewed from the aspect of terminal, I think its a
> good idea that terminal can get its routing policy from the ANDSF.
[Peny] ANDSF may be one of the choices. But ANDSF just follows the
assumption of generic "one default link" IP model. So, in 3GPP, even
though ANDSF can help UE to select accesses and find the route, UE can
only choose one of the interfaces as a result.
Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP,
since it's a specific definition in one SDO.
ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for
23.402 for non-3GPP access still a issue, it may need some mechanism to coordinate
between two type of access entwork.what do you think?
 

> We think a default policy can be used,  when terminal can't find
> corresponding policy in the routing policy from the ANDSF. The default
> policy can be sent by the network.
[Peny] Could we give a chance to MN to change the policy (like user
preference) ?

> On another hand, I am a little confused between MIF and Multihoming, would
> you please help me to clarify the difference between them?
[Peny] I am also not clear yet. Just give some lines as a seed for
discussion. In my personal feeling, MIF is to change the "one default
link" feature of current generic IP model. Multi-homing is to ensure
the reachability and reliability of IP network. Well, in multi-homing
MN scenarios, multi-link-multi-address is also one case. But, in this
case, MN only can choose one link as default.
Some other comments?
To challenge one default link, it really takes time for mif to consider on it, current first step in mif is to consider some straight forward way which is simple to resolve some issues.
Regarding to multi-homing, I guess that it is more site multi-homing.
For last multi-link-multi-address mn's scenario, it will be one of MIF scenario.
 
thanks
 
-Hui
 

BRG
Peny

------=_Part_11414_29335933.1232348752129-- --===============1621388791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1621388791==-- From mif-bounces@ietf.org Sun Jan 18 23:30:52 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE2A3A67EA; Sun, 18 Jan 2009 23:30:52 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C873A67EA for ; Sun, 18 Jan 2009 23:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA1tS0O2vqHL for ; Sun, 18 Jan 2009 23:30:49 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 73E603A67AA for ; Sun, 18 Jan 2009 23:30:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0J7UEeP017733; Mon, 19 Jan 2009 09:30:29 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 09:30:28 +0200 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 09:30:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 09:30:08 +0200 Message-ID: In-Reply-To: <200901181405165005812@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] How to identify a host with multiple interfaces Thread-Index: Acl5MrDNa69OD7/jQZKovbBUOliMSgA1Fafg References: <200901181405165005812@gmail.com> From: To: , X-OriginalArrivalTime: 19 Jan 2009 07:30:27.0745 (UTC) FILETIME=[CCE15910:01C97A07] X-Nokia-AV: Clean Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2029458491==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============2029458491== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A07.CCAD7EF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A07.CCAD7EF2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 In my opinion the fallback (or movement) to use another interface of B for the same session is not in mif scope, but it is more works for shim6/hip/etc, right? Or even at application level to reconnect to different address of B after one fails (the list of addresses application learns e.g. from DNS). =20 Best regards, =20 Teemu ________________________________ From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext shshrosh Sent: 18 January, 2009 08:05 To: mif Subject: [mif] How to identify a host with multiple interfaces =09 =09 =09 Hello, all =20 I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B? =09 ------_=_NextPart_001_01C97A07.CCAD7EF2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
In my=20 opinion the fallback (or movement) to use another interface of B for the = same=20 session is not in mif scope, but it is more works for shim6/hip/etc, = right? Or=20 even at application level to reconnect to different address of B after = one fails=20 (the list of addresses application learns e.g. from = DNS).
 
Best=20 regards,
 
    Teemu

From: mif-bounces@ietf.org=20 [mailto:mif-bounces@ietf.org] On Behalf Of ext = shshrosh
Sent:=20 18 January, 2009 08:05
To: mif
Subject: [mif] How = to=20 identify a host with multiple interfaces

Hello, all
 
I have a problem about multiple = interface.=20 Suppose host A communicates with host B, which has multiple = interfaces. When=20 one interface of B fails, A may switch to the address of another = interface of=20 B to maintain the communication. But how can A know the two = addresses=20 corresponde to the same host B?
------_=_NextPart_001_01C97A07.CCAD7EF2-- --===============2029458491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2029458491==-- From mif-bounces@ietf.org Sun Jan 18 23:31:50 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38603A67EA; Sun, 18 Jan 2009 23:31:50 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437B83A67EA for ; Sun, 18 Jan 2009 23:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i74aHlELujwh for ; Sun, 18 Jan 2009 23:31:48 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 663CE3A67AA for ; Sun, 18 Jan 2009 23:31:48 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1477150wag.5 for ; Sun, 18 Jan 2009 23:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=7zOe/RM18rikrrRJ4ukSCl5J67Yf97nl8VKiYSc3G48=; b=EaWs8ZR3Fy6ZmsTMhiiQMydymvIRJk0eB+WAg+O8qqgqeVTGXc9MWzBQ4hOvxRsoZQ hWWoIEb00KiM/u3978GSIMISSoV87dKvB6O8gHkgvWyh9tXjq/TFcLIzOz0Z0Z9+p6ou 000DmwZdOfC3kgidiy32QFLkfQPcPh5XWubmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=h76fZ2USyMnxKOOdjaK1iG7xlE3nw55j5hVCuez1gp1sUQX6zPoP2NM7JXavlFa+RB xl+elkLLyDBEiKqKtS2wW9JjxZEjY7MmK5DDUi7L6R8eP8r+ba0WlyRfv7lgb4GKbznO q1SwN1tcP5WD2XXUhwIF5p7HqKN/hYdzmmQV8= Received: by 10.114.184.11 with SMTP id h11mr3848617waf.100.1232350291965; Sun, 18 Jan 2009 23:31:31 -0800 (PST) Received: by 10.115.16.13 with HTTP; Sun, 18 Jan 2009 23:31:31 -0800 (PST) Message-ID: <1d38a3350901182331n31185d0avc3dd966e1e6bd919@mail.gmail.com> Date: Mon, 19 Jan 2009 15:31:31 +0800 From: "Hui Deng" To: shshrosh In-Reply-To: <200901172315172652691@gmail.com> MIME-Version: 1.0 References: <200901172315172652691@gmail.com> Cc: mif Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2026269355==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============2026269355== Content-Type: multipart/alternative; boundary="----=_Part_11624_3672380.1232350291960" ------=_Part_11624_3672380.1232350291960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I will try to reply your issue, most application don't decide it's source address when it set up his network connection, this ability has been given to network socket, which is discussed in our proposal discussion: source address selection. when one interface fails, host A will switch, but whether the session will be continued depends on some assumptions. In the current IP model, without consideration of IP mobility multihoming, it's really hard to main the communication. How host A know Host B has two interface is out of scope of MIF, it need more complicated way to realize it. thanks for the discussion -Hui 2009/1/17 shshrosh > Hello, all > > I have a problem about multiple interface. Suppose host A communicates with > host B, which has multiple interfaces. When one interface of B fails, A may > switch to the address of another interface of B to maintain the > communication. But how can A know the two addresses corresponde to the same > host B? > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ------=_Part_11624_3672380.1232350291960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I will try to reply your issue, most application don't decide it's source address when it set up his network connection, this ability has been given to network socket, which is discussed in our proposal discussion: source address selection.
 
when one interface fails, host A will switch, but whether the session will be continued depends on some assumptions. In the current IP model, without consideration of IP mobility multihoming, it's really hard to main the communication.
 
How host A know Host B has two interface is out of scope of MIF, it need more complicated way to realize it.
 
thanks for the discussion
 
-Hui

2009/1/17 shshrosh <shshrosh@gmail.com>
Hello, all
 
I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


------=_Part_11624_3672380.1232350291960-- --===============2026269355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2026269355==-- From mif-bounces@ietf.org Sun Jan 18 23:37:31 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB72428B797; Sun, 18 Jan 2009 23:37:31 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8419B3A67EA for ; Sun, 18 Jan 2009 23:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyM-f-x9rq+N for ; Sun, 18 Jan 2009 23:37:29 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D347C3A67AA for ; Sun, 18 Jan 2009 23:37:28 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0J7arUh030622; Mon, 19 Jan 2009 01:37:04 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 09:37:01 +0200 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 09:36:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 09:36:38 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet-mif-problem-statement-00.txt Thread-Index: Acl34V5ltsd2awWbQ1SekCOrO/KbBAAFCxhQAAConvkAg+XEYA== References: <3db7b9d60901160550g53f051eaqb51e5e2eea3e05f0@mail.gmail.com> From: To: , , X-OriginalArrivalTime: 19 Jan 2009 07:36:57.0836 (UTC) FILETIME=[B56482C0:01C97A08] X-Nokia-AV: Clean Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0036334688==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0036334688== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A08.B522C5F2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A08.B522C5F2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 But for this approach you need deployment of MIP Home Agent, right? My impression of mif work is that the solution must be usable without P(MIP) being deployed (though of course if it helps (P)MIP, the better). =20 With (DS)MIPv6 in place, certainly a host can have a virtual interface and multiple CoAs (simultaneously in use). However, that is not a solution for the scenario where a host is having multiple interfaces to different management domains (intranets, walled gardens), which interfaces cannot be bound together as a single virtual network interface. =20 Best regards, =20 Teemu ________________________________ From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext Hong Yong-Geun Sent: 16 January, 2009 18:34 To: Kai Ju; mif@ietf.org Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt =09 =09 =20 Hi, all. =20 I think that a host can use multiple interfaces to get more bandwidth without increasing complexity. Even though multiple interfaces exist, if it is possible to hide the existing of multiple interfaces to the upper layer (network layer), multiple interfaces can be used to get more bandwidth. One of solutions for this is a virtual network interface concept. =09 http://tools.ietf.org/draft/draft-hong-virtualif-mn-mipv6/draft-hong-vir tualif-mn-mipv6-00.txt =20 As Kai says, I agreed that using multiple interfaces and changing interfaces during communication for the avoidance of network congestion or the requirement for more bandwidth can be one of study items in mif. =20 Thanks.. =20 Yong-Geun.=20 =20 =20 From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Kai Ju Sent: Friday, January 16, 2009 10:50 PM To: mif@ietf.org Subject: Re: [mif] draft-blanchet-mif-problem-statement-00.txt =20 Hi, all >-----Original Message----- >From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org ] On=20 >Behalf Of ext Tony Finch >Sent: 05 January, 2009 21:24 >To: mif at ietf.org =20 >Subject: [mif] draft-blanchet-mif-problem-statement-00.txt > >Can a host use multiple interfaces to get more bandwidth?=20 >Obviously yes now by binding the local end of each socket to=20 >each interface, but that introduces much more complexity to an=20 >area that was previously simple. Is that complexity avoidable? This is probably not in mif scope. There's some interesting work ongoing on having multipath support on transpor layer (multipath TCP): http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf =09 Yes, We agree that it's not in mif scope, that one application can get more=20 bandwidth by using multiple interfaces. But we believe that a host who has several applications on can optimize the bandwidth=20 condition by using multiple interfaces, under the policy provided by the ISP. For example,=20 one application is moved from one interface to another due to the network congestion,=20 or the requirement for more bandwidth. We think it's one direction which is worth to be discussed by MIF. Best regards, =09 Kai =09 =20 ------_=_NextPart_001_01C97A08.B522C5F2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
But for this approach you need deployment of = MIP Home=20 Agent, right? My impression of mif work is that the solution must be = usable=20 without P(MIP) being deployed (though of course if it helps (P)MIP, the=20 better).
 
With (DS)MIPv6 in place, certainly a host can = have a=20 virtual interface and multiple CoAs (simultaneously in use). However, = that is=20 not a solution for the scenario where a host is having multiple = interfaces to=20 different management domains (intranets, walled gardens), which = interfaces=20 cannot be bound together as a single virtual network=20 interface.
 
Best regards,
 
    Teemu

From: mif-bounces@ietf.org=20 [mailto:mif-bounces@ietf.org] On Behalf Of ext Hong=20 Yong-Geun
Sent: 16 January, 2009 18:34
To: Kai Ju; = mif@ietf.org
Subject: Re: [mif]=20 draft-blanchet-mif-problem-statement-00.txt

  

Hi,=20 all.

 

I=20 think that a host can use multiple interfaces to get more bandwidth=20 without
increasing complexity. Even = though=20 multiple interfaces exist, if it is possible to hide
the existing of multiple interfaces to the upper = layer=20 (network layer), multiple interfaces
can = be used=20 to get more bandwidth. One of solutions for this is a virtual network=20 interface concept.

http://tools.ietf.org/draft/draft-hong-virtualif-mn-mipv6= /draft-hong-virtualif-mn-mipv6-00.txt

 

As=20 Kai says, I agreed that using multiple interfaces and changing = interfaces=20 during communication
for the avoidance = of network=20 congestion or the requirement for more bandwidth can be one of = study
items in mif.

 

Thanks..

 

Yong-Geun.=20

 

 

From:=20 mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = Kai=20 Ju
Sent: Friday, January 16, 2009 10:50 PM
To:=20 mif@ietf.org
Subject: Re: [mif]=20 = draft-blanchet-mif-problem-statement-00.txt

 

Hi, = all

>-----Original=20 Message-----
>From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] On
>Behalf Of ext Tony = Finch
>Sent:=20 05 January, 2009 21:24
>To: mif at ietf.org
>Subject: [mif]=20 draft-blanchet-mif-problem-statement-00.txt
>
>Can a host = use=20 multiple interfaces to get more bandwidth?
>Obviously yes now = by=20 binding the local end of each socket to
>each interface, but = that=20 introduces much more complexity to an
>area that was previously = simple.=20 Is that complexity avoidable?

This is probably not in mif scope. There's some=20 interesting work ongoing
on having multipath support on transpor = layer=20 (multipath TCP):
http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pd= f


Yes, We agree that it's = not in mif=20 scope, that one application can get more

bandwidth by using multiple=20 interfaces.

But we believe that a host who = has several=20 applications on can optimize the bandwidth =

condition by using multiple = interfaces,=20 under the policy provided by the ISP. For example,=20

one application is moved from = one=20 interface to another due to the network congestion,=20

or the requirement for more=20 bandwidth.

We think it's one direction = which is worth=20 to be discussed by MIF.

Best=20 = regards,

Kai

------_=_NextPart_001_01C97A08.B522C5F2-- --===============0036334688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0036334688==-- From mif-bounces@ietf.org Sun Jan 18 23:38:04 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE61D3A699D; Sun, 18 Jan 2009 23:38:04 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207433A67AA for ; Sun, 18 Jan 2009 23:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQY6gsLqC99s for ; Sun, 18 Jan 2009 23:38:00 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 761BB3A68BA for ; Sun, 18 Jan 2009 23:38:00 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1478488wag.5 for ; Sun, 18 Jan 2009 23:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=4y9E4Ajh17DNYyw0Nv2VtT8PjvbQ9twDhoL2YN61FUU=; b=rqVrDLlugSZlGiDy9bRhA6FzcCs9tDDjThD/PJhLua1TLljLESSVQRG3QZgmtezUkD GrOeW8SbVC5r1ef6xpRtf7qGJ5wczI0NT40ab31JFE0IcyeCZgCqWFA5WCJIP05z/f81 qZxhI7xF4aY6rrzrHPLNHVHeGjhHKdzAYHAiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=EU0akiA4IWBBK/JJlMR4mRFaGQMm6u49cFe74PGDkb9ZzRrHV02PAf/RTnd4Fzwpe3 CIeXifB9gN9HJ/Mqb9ivhxvSzsu0S1fn1dT7Q8kqBLvSkgcGxNYFGX0BM2ADxM2bZUjC 1mC5dn15PQt7nX9Cn3Pk8yLz0Apg9wsWcC14s= Received: by 10.114.153.18 with SMTP id a18mr3825349wae.200.1232350664543; Sun, 18 Jan 2009 23:37:44 -0800 (PST) Received: by 10.115.16.13 with HTTP; Sun, 18 Jan 2009 23:37:44 -0800 (PST) Message-ID: <1d38a3350901182337k5d08a312t705622e1237f2a9b@mail.gmail.com> Date: Mon, 19 Jan 2009 15:37:44 +0800 From: "Hui Deng" To: "Hong Yong-Geun" In-Reply-To: MIME-Version: 1.0 References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1857658294==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1857658294== Content-Type: multipart/alternative; boundary="----=_Part_11658_9968273.1232350664534" ------=_Part_11658_9968273.1232350664534 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIEhvbmcsCgpDb3VsZCB5b3UgbWFrZSBhIHNob3J0IHN1bW1hcnkgLCBjcm9zcy1wb3N0IHRv IHRoZSBtZXh0L21pZiwgYW5kIGNjIHRvCmNoYWlycywgYW5kCnNlZSB0aGVpciBjb21tZW50cz8K TWFueSB0aGFua3MKCi1IdWkKMjAwOS8xLzE1IEhvbmcgWW9uZy1HZXVuIDx5Z2hvbmdAZXRyaS5y ZS5rcj4KCj4KPgo+IEhpLi5IdWkuLgo+Cj4KPgo+IE5vLCBJIGRpZG4ndCBkaXNjdXNzIHdpdGgg bWV4dCB3Zy4gSSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCB3aXRoIG1vbmFtaTYKPiB3ZyBhdCA2 NHRoIElFVEYgbWVldGluZy4KPgo+IEFuZCBpdCB3YXMgbm90IGFkb3B0ZWQgaW4gbW9uYW1pNiB3 ZyBiZWNhdXNlIGl0IHdhcyBub3QgaW4gdGhlIHNjb3BlIG9mCj4gbW9uYW1pNiB3Zy4KPgo+Cj4K PiBCZXN0IHJlZ2FyZHMuCj4KPgo+Cj4gWW9uZy1HZXVuLi4KPgo+Cj4KPiAqRnJvbToqIEh1aSBE ZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGdtYWlsLmNvbV0KPiAqU2VudDoqIFRodXJzZGF5LCBKYW51 YXJ5IDE1LCAyMDA5IDM6NDcgUE0KPiAqVG86KiDIq7/rsdkKPgo+ICpDYzoqIG1pZkBpZXRmLm9y Zwo+ICpTdWJqZWN0OiogUmU6IFttaWZdIG1vYmlsaXR5IGlzc3VlcyBhbmQgZ2VuZXJhbCBpc3N1 ZXMgb24gbWlmCj4KPgo+Cj4geW91IGFscmVhZHkgaGFkIGEgZGlzY3Vzc2lvbiB3aXRoIG1leHQg d2csIHRoZXkgYXJlIG5vdCBhZG9wdGluZyB0aGlzIHdvcms/Cj4KPgo+Cj4gLUh1aQo+Cj4gMjAw OS8xLzE0IEhvbmcgWW9uZy1HZXVuIDx5Z2hvbmdAZXRyaS5yZS5rcj4KPgo+Cj4KPiBIaS4uSHVp Li4KPgo+Cj4KPiBUaGFuayB5b3UgZm9yIGNvbW1lbnRzLiBTZWUgYmVsb3cgaW5saW5lIHJlcGx5 Lgo+Cj4KPgo+IEJlc3QgcmVnYXJkcy4KPgo+Cj4KPiBZb25nLUdldW4uLgo+Cj4KPgo+ICpGcm9t OiogSHVpIERlbmcgW21haWx0bzpkZW5naHVpMDJAZ21haWwuY29tXQo+ICpTZW50OiogV2VkbmVz ZGF5LCBKYW51YXJ5IDE0LCAyMDA5IDc6MjAgQU0KPiAqVG86KiDIq7/rsdkKPiAqQ2M6KiBtaWZA aWV0Zi5vcmcKPiAqU3ViamVjdDoqIFJlOiBbbWlmXSBtb2JpbGl0eSBpc3N1ZXMgYW5kIGdlbmVy YWwgaXNzdWVzIG9uIG1pZgo+Cj4KPgo+IEhpLCBIb25nIFlvbmcsCj4KPgo+Cj4gSSByZWFkIHRo cm91Z2ggeW91ciB0d28gZHJhZnRzLCB1bmRlcnN0YW5kIHlvdSBhcmUgdGFsa2luZyB0aGUKPiBp c3N1ZSB3aXRob3V0IE1vbmFtaQo+Cj4gPyAgWWVzLCB5b3UgYXJlIGNvcnJlY3QuCj4gSSB3YW50 IHRvIHNvbHZlIHRoZSBtdWx0aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgd2l0aG91dCBtb2RpZnlp bmcgTW9iaWxlCj4gSVB2Ni9ORU1PIGNvZGUuCj4gKEluIE1vbmFtaTYsIG11bHRpcGxlIGludGVy ZmFjZSBwcm9ibGVtcyAod2hpY2ggYXJlIHJlbGF0ZWQgdG8gbW9iaWxpdHkKPiBpc3N1ZXMsIHN1 Y2ggYXMgbXVsdGlwbGUgQ29BLAo+IG11bHRpcGxlIEhvQSwgZXRjLiwgKSBhcmUgcmVzb2x2aW5n IGJ5IG1vZGlmeWluZyBNb2JpbGUgSVB2Ni9ORU1PIHByb3RvY29sKQo+Cj4KPiBpdCBzZWVtcyBN b2JpbGUgSXB2NiBpbnRlcm5hbCBhbHNvIGhhcyBzaW1pbGFyIGlzc3VlIHdpdGggdXMgaWYgSQo+ IHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LAo+Cj4gPyAgWWVzLCBiZWNhdXNlIE1vYmlsZSBJUHY2 IGlzIGJhc2VkIG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2NiwKPiBNb2JpbGUgSVB2NiBp bnRlcm5hbAo+IGhhcyBzaW1pbGFyIGlzc3VlcyBvZiBtaWYuIFNvLCBJIHRoaW5rIHRoYXQgaXQg aXMgdmFsdWFibGUgdG8gc2VwYXJhdGUgbW9yZQo+IGdlbmVyYWwgaXNzdWVzIGZyb20KPiBtdWx0 aXBsZSBpbnRlcmZhY2UgaXNzdWVzIHdoaWNoIGFyZSBkaXJlY3RseSByZWxhdGVkIHRvIE1vYmls ZSBJUHY2L05FTU8uCj4KPgo+Cj4gSW4gdGhpcyBjYXNlIEkgd291bGQgbGlrZSB0byBlbmNvdXJh Z2UgeW91IHRvIHByb3Bvc2UgdGhpcyBpc3N1ZSB0byBvdXIKPiB3b3JrLCBpZiBhbGxvd2VkLAo+ Cj4gaXQgbWlnaHRiZSBkb2FibGUgd2l0aGluIG91ciBzY29wZSwKPgo+ID8gIFRoYW5rcy4gSXQg aXMgbXkgcGxlYXN1cmUuLgo+Cj4KPgo+IG1hbnkgdGhhbmtzCj4KPgo+Cj4gLUh1aQo+Cj4gMjAw OS8xLzcgSG9uZyBZb25nLUdldW4gPHlnaG9uZ0BldHJpLnJlLmtyPgo+Cj4gSGkuIG1pZi4uCj4K PiBMZXQgbWUgam9pbiB0aGlzIGRpc2N1c3Npb24uCj4KPiBJdCBpcyB2ZXJ5IGludGVyZXN0aW5n IHRvIHNlZSBtaWYuCj4KPiBBcyBIdWkgRGVuZyBzYXlzLCBJIHVuZGVyc3RhbmQgdGhhdCBtaWYg aGFzIGRpZmZlcmVudCBhcHByb2FjaAo+IGZyb20gb3RoZXIgV0cgc3VjaCBhcyBNRVhUIGFuZCBt b25hbWk2IFdHLCBldGMuCj4KPiBJbiBNRVhULCBtdWx0aXBsZSBpbnRlcmZhY2VzIGlzc3VlcyBh cmUgcmVsYXRlZCB0byBNb2JpbGUgSVAsIE5FTU8sLi4KPiBJbiBtaWYsIG11bHRpcGxlIGludGVy ZmFjZXMgaXNzdWVzIGFyZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBvZiBNRVhULgo+IFNvLCBpbiBt aWYsIGl0IGlzIGJldHRlciB0byBmaW5kIG1vcmUgZ2VuZXJhbCBpc3N1ZXMgd2hpY2ggYXJlIG5v dCByZWxhdGVkCj4gdG8gTW9iaWxlIElQLgo+Cj4gSSB0aGluayB0aGF0IE0uQmxhbmNoZXQncyAi TXVsdGlwbGUgSW50ZXJmYWNlcyBQcm9ibGVtIFN0YXRlbWVudCIgZHJhZnQgaXMKPiBhIGdvb2Qg c3RhcnRpbmcgcG9pbnQgdG8gZGlzY3VzcyBnZW5lcmFsIGlzc3VlcyBvbiBtaWYuCj4KPiBJIHdv dWxkIGxpa2UgdG8gaW50cm9kdWNlIGFub3RoZXIgcmVsYXRlZCBkcmFmdHMgd2hpY2ggSSBwcmVz ZW50ZWQgYXQKPiBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nLgo+Cj4gIC0gQW5hbHlz aXMgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZQo+IE5vZGUoZHJhZnQtaG9uZy1t dWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMCkKPgo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9k cmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVs dGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0Cj4KPiAgLSBWaXJ0dWFsIG5ldHdvcmsgaW50 ZXJmYWNlIGZvciBtdWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUKPiB1c2luZyBN b2JpbGUgSVB2Ngo+ICAgIChkcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMCkKPgo+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni9k cmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQKPgo+Cj4gSW4gdGhlIHNlY3Rpb24g Mi4yIChHZW5lcmFsIE5ldHdvcmsgSXNzdWVzKSBpbiB0aGUgZmlyc3QgZHJhZnQsCj4gdGhlcmUg YXJlIGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMuCj4K PiBJbmNsdWRpbmcgdGhlc2UgZHJhZnRzLCBJIGhvcGUgdG8gZW5jb3VyYWdlIHRoaXMgZGlzY3Vz c2lvbgo+Cj4gWW9uZy1HZXVuLgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IG1pZiBtYWlsaW5nIGxpc3QKPiBtaWZAaWV0Zi5vcmcKPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZgo+Cj4KPgo+ICq/wLf5ISDGxMDP IMDMuKfAzCDB9sGktce+7iDA1sH2IL7KvcC0z7TZLioKPgo+Cj4K ------=_Part_11658_9968273.1232350664534 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgSG9uZyw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5Db3VsZCB5b3UgbWFr ZSBhIHNob3J0IHN1bW1hcnkgLCBjcm9zcy1wb3N0IHRvIHRoZSBtZXh0L21pZiwgYW5kIGNjIHRv IGNoYWlycywgYW5kPC9kaXY+CjxkaXY+c2VlIHRoZWlyIGNvbW1lbnRzPzxicj48L2Rpdj4KPGRp dj5NYW55IHRoYW5rczwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pi1IdWk8YnI+PC9kaXY+ CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzEvMTUgSG9uZyBZb25nLUdldW4gPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86eWdob25nQGV0cmkucmUua3IiPnlnaG9uZ0Bl dHJpLnJlLmtyPC9hPiZndDs8L3NwYW4+PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsg Qk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KPGRpdiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogU3lzdGVtIj4KPGRpdj4mbmJzcDsmbmJzcDsgCjxkaXYgbGFuZz0iS08i IHZsaW5rPSJwdXJwbGUiIGxpbms9ImJsdWUiPgo8ZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2QiPkhpLi5IdWkuLjwvc3Bhbj48 L3A+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5ObywgSSBkaWRuJ3QgZGlzY3VzcyB3aXRo IG1leHQgd2cuIEkgcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgd2l0aCBtb25hbWk2IHdnIGF0IDY0 dGggSUVURiBtZWV0aW5nLjwvc3Bhbj48L3A+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+QW5kIGl0IHdhcyBub3QgYWRvcHRlZCBp biBtb25hbWk2IHdnIGJlY2F1c2UgaXQgd2FzIG5vdCBpbiB0aGUgc2NvcGUgb2YgbW9uYW1pNiB3 Zy48L3NwYW4+PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6ICMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48L3A+CjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+QmVzdCByZWdhcmRzLjwv c3Bhbj48L3A+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5Zb25nLUdldW48c3Bhbj4uLjwv c3Bhbj48L3NwYW4+PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6ICMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48L3A+CjxkaXYgc3R5bGU9IkJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogI2I1 YzRkZiAxcHQgc29saWQ7IFBBRERJTkctTEVGVDogMGNtOyBQQURESU5HLUJPVFRPTTogMGNtOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQ7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lIj4KPHA+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+IEh1aSBEZW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRlbmdodWkwMkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5kZW5naHVpMDJAZ21haWwuY29tPC9hPl0gPGJyPjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAwOSAzOjQ3IFBNPGJyPgo8Yj5Ubzo8L2I+ IDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij7Iq7/rsdk8L3NwYW4+IAo8ZGl2 Pgo8ZGl2PjwvZGl2Pgo8ZGl2IGNsYXNzPSJXajNDN2MiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0Ij48YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bWlmQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlmQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0Ojwv Yj4gUmU6IFttaWZdIG1vYmlsaXR5IGlzc3VlcyBhbmQgZ2VuZXJhbCBpc3N1ZXMgb24gbWlmPC9z cGFuPjwvZGl2Pgo8L2Rpdj4KPHA+PC9wPjwvcD48L2Rpdj4KPGRpdj4KPGRpdj48L2Rpdj4KPGRp diBjbGFzcz0iV2ozQzdjIj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+ CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj55b3UgYWxyZWFkeSBoYWQgYSBkaXNjdXNzaW9u IHdpdGggbWV4dCB3ZywgdGhleSBhcmUgbm90IGFkb3B0aW5nIHRoaXMgd29yaz88L3NwYW4+PC9w PjwvZGl2Pgo8ZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD48L2Rp dj4KPGRpdj4KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tSHVpPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj4KPGRpdj4KPGRpdj4KPGRpdj48L2Rp dj4KPGRpdiBjbGFzcz0iV2ozQzdjIj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjIwMDkvMS8xNCBI b25nIFlvbmctR2V1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJn ZXQ9Il9ibGFuayI+eWdob25nQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj48L3A+CjxkaXY+Cjxk aXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDsm bmJzcDsgPC9zcGFuPjwvcD4KPGRpdj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5IaS4uSHVpLi48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48L3A+CjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48L3Nw YW4+PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxZjQ5N2QiPlRoYW5rIHlvdSBmb3IgY29tbWVudHMuIFNlZSBiZWxvdyBpbmxpbmUgcmVw bHkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48L3Nw YW4+PC9wPgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5CZXN0IHJlZ2FyZHMuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPgo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PC9zcGFu PjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkIj5Zb25nLUdldW4uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48L3A+CjxkaXYgc3R5bGU9IkJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDog I2I1YzRkZiAxcHQgc29saWQ7IFBBRERJTkctTEVGVDogMGNtOyBQQURESU5HLUJPVFRPTTogMGNt OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQ7IEJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lIj4KPHA+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+IEh1aSBEZW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRlbmdodWkwMkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kZW5naHVpMDJAZ21haWwuY29tPC9hPl0gPGJyPjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTQsIDIwMDkgNzoyMCBBTTxicj4KPGI+VG86 PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+yKu/67HZPHNwYW4gbGFu Zz0iRU4tVVMiPjxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5taWZAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW21p Zl0gbW9iaWxpdHkgaXNzdWVzIGFuZCBnZW5lcmFsIGlzc3VlcyBvbiBtaWY8L3NwYW4+PC9zcGFu PjwvcD4KPC9kaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij4mbmJzcDs8L3NwYW4+PC9wPgo8ZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTBwdCI+SGksIEhvbmcgWW9uZyw8L3NwYW4+PC9wPjwvZGl2Pgo8ZGl2Pgo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9zcGFuPjwv cD48L2Rpdj4KPGRpdj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPkkgcmVhZCB0aHJvdWdoIHlvdXIgdHdvIGRyYWZ0cywgdW5kZXJzdGFuZCB5b3Ug YXJlIHRhbGtpbmcgdGhlIGlzc3VlJm5ic3A7d2l0aG91dCBNb25hbWk8L3NwYW4+PC9wPjwvZGl2 Pgo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDIxLjc1cHQ7IFRFWFQtSU5ERU5UOiAtMThwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogV2luZ2RpbmdzIj4/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiA3cHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJiMzOTtUaW1lcyBO ZXcgUm9tYW4mIzM5OywmIzM5O3NlcmlmJiMzOTsiPiZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkIj5ZZXMsIHlvdSBh cmUgY29ycmVjdC4gPGJyPgpJIHdhbnQgdG8gc29sdmUgdGhlIG11bHRpcGxlIGludGVyZmFjZSBw cm9ibGVtcyB3aXRob3V0IG1vZGlmeWluZyBNb2JpbGUgSVB2Ni9ORU1PIGNvZGUuPGJyPihJbiBN b25hbWk2LCBtdWx0aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgKHdoaWNoJm5ic3A7YXJlIHJlbGF0 ZWQgdG8gbW9iaWxpdHkgaXNzdWVzLCBzdWNoIGFzIG11bHRpcGxlIENvQSw8YnI+bXVsdGlwbGUg SG9BLCBldGMuLCApIGFyZSByZXNvbHZpbmcgYnkgbW9kaWZ5aW5nIE1vYmlsZSBJUHY2L05FTU8g cHJvdG9jb2wpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij48L3NwYW4+PC9wPgoKPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPjxicj5pdCBzZWVtcyBNb2JpbGUgSXB2NiBpbnRlcm5hbCBhbHNvIGhhcyBzaW1p bGFyIGlzc3VlIHdpdGggdXMgaWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgPC9zcGFuPjwv cD48L2Rpdj4KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4 cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5ncyI+Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogN3B0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICYjMzk7 VGltZXMgTmV3IFJvbWFuJiMzOTssJiMzOTtzZXJpZiYjMzk7Ij4mbmJzcDsgPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+WWVz LCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJhc2VkIG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2Yg SVB2NiwgTW9iaWxlIElQdjYgaW50ZXJuYWw8YnI+CmhhcyBzaW1pbGFyIGlzc3VlcyBvZiBtaWYu IFNvLCBJIHRoaW5rIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8gc2VwYXJhdGUgbW9yZSBnZW5lcmFs IGlzc3VlcyBmcm9tPGJyPm11bHRpcGxlIGludGVyZmFjZSBpc3N1ZXMgd2hpY2ggYXJlIGRpcmVj dGx5IHJlbGF0ZWQgdG8gTW9iaWxlIElQdjYvTkVNTy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48L3A+Cgo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD48L2Rp dj4KPGRpdj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPkluIHRoaXMgY2FzZSBJIHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHlvdSB0byBwcm9wb3Nl IHRoaXMgaXNzdWUgdG8gb3VyIHdvcmssIGlmIGFsbG93ZWQsPC9zcGFuPjwvcD48L2Rpdj48L2Rp dj4KPGRpdj4KPGRpdj4KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPml0IG1pZ2h0YmUgZG9hYmxlIHdpdGhpbiBvdXIgc2NvcGUsPC9zcGFuPjwvcD48L2Rpdj4K PHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9O VC1GQU1JTFk6IFdpbmdkaW5ncyI+Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogN3B0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICYjMzk7VGltZXMgTmV3 IFJvbWFuJiMzOTssJiMzOTtzZXJpZiYjMzk7Ij4mbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZCI+VGhhbmtzLiBJdCBp cyBteSBwbGVhc3VyZS4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0Ij48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPGRpdj4KPGRpdj4KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzwvc3Bhbj48L3A+PC9kaXY+ CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5tYW55 IHRoYW5rczwvc3Bhbj48L3A+PC9kaXY+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPjwvZGl2Pgo8ZGl2Pgo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+LUh1aTwvc3Bhbj48L3A+PC9k aXY+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4y MDA5LzEvNyBIb25nIFlvbmctR2V1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJl LmtyIiB0YXJnZXQ9Il9ibGFuayI+eWdob25nQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj48L3A+ CjxkaXY+CjxkaXY+CjxkaXY+CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5IaS4gbWlmLi48YnI+PGJyPkxldCBtZSBqb2lu IHRoaXMgZGlzY3Vzc2lvbi48YnI+PGJyPkl0IGlzIHZlcnkgaW50ZXJlc3RpbmcgdG8gc2VlIG1p Zi48YnI+PGJyPkFzIEh1aSBEZW5nIHNheXMsIEkgdW5kZXJzdGFuZCB0aGF0IG1pZiBoYXMgZGlm ZmVyZW50IGFwcHJvYWNoPGJyPgpmcm9tIG90aGVyIFdHIHN1Y2ggYXMgTUVYVCBhbmQgbW9uYW1p NiBXRywgZXRjLjxicj48YnI+SW4gTUVYVCwgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgYXJl IHJlbGF0ZWQgdG8gTW9iaWxlIElQLCBORU1PLC4uPGJyPkluIG1pZiwgbXVsdGlwbGUgaW50ZXJm YWNlcyBpc3N1ZXMgYXJlIGRpZmZlcmVudCBmcm9tIHRob3NlIG9mIE1FWFQuPGJyPlNvLCBpbiBt aWYsIGl0IGlzIGJldHRlciB0byBmaW5kIG1vcmUgZ2VuZXJhbCBpc3N1ZXMgd2hpY2ggYXJlIG5v dCByZWxhdGVkIHRvIE1vYmlsZSBJUC48YnI+Cjxicj5JIHRoaW5rIHRoYXQgTS5CbGFuY2hldCYj Mzk7cyAmcXVvdDtNdWx0aXBsZSBJbnRlcmZhY2VzIFByb2JsZW0gU3RhdGVtZW50JnF1b3Q7IGRy YWZ0IGlzPGJyPmEgZ29vZCBzdGFydGluZyBwb2ludCB0byBkaXNjdXNzIGdlbmVyYWwgaXNzdWVz IG9uIG1pZi48YnI+PGJyPkkgd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgYW5vdGhlciByZWxhdGVk IGRyYWZ0cyB3aGljaCBJIHByZXNlbnRlZCBhdCBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0 aW5nLjxicj4KPGJyPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog MTBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4tIEFuYWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFj ZXMgaW4gYSBNb2JpbGUgTm9kZShkcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50 LTAwKTxicj4KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJh ZnQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRlbWVudC9kcmFmdC1ob25nLW11bHRp cGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2Ry YWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0PC9hPjxicj4KPGJyPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogU3lzdGVtIj4tIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVy ZmFjZXMgaW4gYSBNb2JpbGUgbm9kZSB1c2luZyBNb2JpbGUgSVB2Njxicj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZuYnNwOyZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5 c3RlbSI+IChkcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMCk8YnI+Cjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVt Ij4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2RyYWZ0L2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLXZpcnR1YWxp Zi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ8L2E+PGJyPgo8 YnI+PGJyPkluIHRoZSBzZWN0aW9uIDIuMiAoR2VuZXJhbCBOZXR3b3JrIElzc3VlcykgaW4gdGhl IGZpcnN0IGRyYWZ0LDxicj50aGVyZSBhcmUgZ2VuZXJhbCBuZXR3b3JrIGlzc3VlcyBkdWUgdG8g bXVsdGlwbGUgaW50ZXJmYWNlcy48YnI+PGJyPkluY2x1ZGluZyB0aGVzZSBkcmFmdHMsIEkgaG9w ZSB0byBlbmNvdXJhZ2UgdGhpcyBkaXNjdXNzaW9uPGJyPjxicj5Zb25nLUdldW4uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPgo8L2Rp dj48L2Rpdj48L2Rpdj4KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bWlmIG1haWxpbmcgbGlzdDxicj48YSBocmVm PSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWlmQGlldGYub3JnPC9hPjxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmPC9h Pjwvc3Bhbj48L3A+CjwvZGl2Pgo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+Jm5ic3A7PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj4KPHA+PGI+v8C3+TxzcGFuIGxhbmc9IkVOLVVTIj4hIDwvc3Bhbj7G xMDPIMDMuKfAzCDB9sGktce+7iDA1sH2IL7KvcC0z7TZPHNwYW4gbGFuZz0iRU4tVVMiPi48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9wPjwvZGl2Pgo8cD48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48aW1nIGhl aWdodD0iMCIgd2lkdGg9IjAiPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_11658_9968273.1232350664534-- --===============1857658294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1857658294==-- From mif-bounces@ietf.org Sun Jan 18 23:42:41 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EC43A68BA; Sun, 18 Jan 2009 23:42:41 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40853A68BA for ; Sun, 18 Jan 2009 23:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f8GeVM1lymo for ; Sun, 18 Jan 2009 23:42:39 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 2EC023A67AA for ; Sun, 18 Jan 2009 23:42:39 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1479384wag.5 for ; Sun, 18 Jan 2009 23:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=jyRYPG1Xo/TMPgBGdP6QgcncY2ALD+9qfI2Ow/ZZLvI=; b=sQoH4EGw3WrXCr3fu3S8jOl8FaHFuZtXHHmpleaui3gmTkhzscp3D/GYq+ly5AtJdc DBSBc85CzmJ7Wdbt7YP/94i+4Wn6pWL3ncEJtAUfxhV93VcAAF6QgGAlp8PO86/6xMhY zj5XCdOKRaLOMy8SlwJJYeraSdZ2mPaj7r1vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=hxcJ3d9zlfJMHX5CNMUtnBs8Lvn/eWay3MZdGRb1cSoFhYTHRbg+USpvWWkhkSL1XT 4uGR0ZFmYevBSmDb5k1yZbbjeGwRiQg0FKajIapbiRp0l2gVFJjTbSob2wObQFjKxkbG 2/UjtfZmL/VQM0G+aYI5HWtwNNNnznt5EJqOo= Received: by 10.114.208.20 with SMTP id f20mr1603025wag.46.1232350942900; Sun, 18 Jan 2009 23:42:22 -0800 (PST) Received: by 10.115.16.13 with HTTP; Sun, 18 Jan 2009 23:42:22 -0800 (PST) Message-ID: <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> Date: Mon, 19 Jan 2009 15:42:22 +0800 From: "Hui Deng" To: teemu.savolainen@nokia.com In-Reply-To: MIME-Version: 1.0 References: <200901181405165005812@gmail.com> Cc: mif@ietf.org Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0450617530==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0450617530== Content-Type: multipart/alternative; boundary="----=_Part_11679_5052770.1232350942893" ------=_Part_11679_5052770.1232350942893 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Teemu I agree your point here, fallback and movement to use another interface for the same session will be not in the mif scope. -Hui 2009/1/19 > Hi, > > In my opinion the fallback (or movement) to use another interface of B for > the same session is not in mif scope, but it is more works for > shim6/hip/etc, right? Or even at application level to reconnect to different > address of B after one fails (the list of addresses application learns e.g. > from DNS). > > Best regards, > > Teemu > > ------------------------------ > *From:* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *On Behalf Of *ext > shshrosh > *Sent:* 18 January, 2009 08:05 > *To:* mif > *Subject:* [mif] How to identify a host with multiple interfaces > > Hello, all > > I have a problem about multiple interface. Suppose host A communicates with > host B, which has multiple interfaces. When one interface of B fails, A may > switch to the address of another interface of B to maintain the > communication. But how can A know the two addresses corresponde to the same > host B? > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ------=_Part_11679_5052770.1232350942893 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Teemu
 
I agree your point here, fallback and movement to use another interface for the same session will be not in the mif scope.
 
-Hui

2009/1/19 <teemu.savolainen@nokia.com>
Hi,
 
In my opinion the fallback (or movement) to use another interface of B for the same session is not in mif scope, but it is more works for shim6/hip/etc, right? Or even at application level to reconnect to different address of B after one fails (the list of addresses application learns e.g. from DNS).
 
Best regards,
 
    Teemu

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext shshrosh
Sent: 18 January, 2009 08:05
To: mif
Subject: [mif] How to identify a host with multiple interfaces

Hello, all
 
I have a problem about multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address of another interface of B to maintain the communication. But how can A know the two addresses corresponde to the same host B?

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


------=_Part_11679_5052770.1232350942893-- --===============0450617530== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0450617530==-- From mif-bounces@ietf.org Mon Jan 19 00:45:17 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC75B3A6B82; Mon, 19 Jan 2009 00:45:17 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9747E28C157 for ; Mon, 19 Jan 2009 00:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IM7ScMNvSEm for ; Mon, 19 Jan 2009 00:45:15 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 5D00C3A6B80 for ; Mon, 19 Jan 2009 00:45:15 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 09:44:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 09:44:56 +0100 Message-ID: In-Reply-To: <200901181507195318824@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif]How to identify a host with multiple interfaces Thread-Index: Acl5O1s9nYrOg5DZSzGri5p8DPcGhwA06Cvw References: <200901181405165005812@gmail.com>, <3db7b9d60901172229o5f4b0bcwa2afa6440841efec@mail.gmail.com> <200901181507195318824@gmail.com> From: To: , X-OriginalArrivalTime: 19 Jan 2009 08:44:56.0921 (UTC) FILETIME=[34B77C90:01C97A12] Cc: mif@core3.amsl.com Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org SGVsbG8sDQoNCkFORFNGIGRvZXMgbm90IGNvbWUgZnJvbSBJRVRGIHdvcmxkLiBBY3R1YWxseSwg QU5EU0Ygc3RhbmRzIGZvciAiQWNjZXNzIE5ldHdvcmsgRGlzY292ZXJ5IGFuZCBTZWxlY3Rpb24g RnVuY3Rpb24iLiBUaGlzIGZ1bmN0aW9uIGhhcyBiZWVuIGludHJvZHVjZWQgaW4gM0dQUCBhcmNo aXRlY3R1cmUgaW4gcmVsZWFzZSA4IGFuZCBhaW1zIGF0IHByb3ZpZGluZyBpbmZvcm1hdGlvbi9p bmRpY2F0aW9uL3JlY29tbWVuZGF0aW9uL2V0Yy4uLiB0byB0aGUgbXVsdGktaW50ZXJmYWNlIE1O IGZvciBkaXNjb3ZlcnkgYW5kIHNlbGVjdGlvbiBvZiB0aGUgImJlc3QiIGFjY2Vzcy4gRm9yIGRl dGFpbHMsIHBsZWFzZSBzZWUgM0dQUCBUUyAyMy40MDIgaHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAv U3BlY3MvaHRtbC1pbmZvLzIzNDAyLmh0bSAoc2VjdGlvbiA0LjguMi4xKQ0KDQpSZWdhcmRzLA0K UGllcnJpY2sNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlwqA6 IG1pZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgc2hzaHJvc2gNCkVudm95w6nCoDogZGltYW5jaGUgMTggamFudmllciAyMDA5IDA4 OjA3DQrDgMKgOiBLYWkgSnUNCkNjwqA6IG1pZg0KT2JqZXTCoDogUmU6IFttaWZdSG93IHRvIGlk ZW50aWZ5IGEgaG9zdCB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMNCg0KSGVsbG/CoEthaUp1LA0K wqANCiAgICAgVGhhbmsgeW91IGZvciB5b3VyIGFkdmljZS4NCiAgICAgSSBrbm93IGxpdHRsZSBh Ym91dCBBTkRTRi4gSXMgaXQgYSBkcmFmdCBvciBhbiBSRkM/DQogICAgIMKgDQrlj5Hku7bkurrv vJogS2FpIEp1IA0K5Y+R6YCB5pe26Ze077yaIDIwMDktMDEtMTjCoCAxNDoyOTo0MyANCuaUtuS7 tuS6uu+8miBzaHNocm9zaCANCuaKhOmAge+8miBtaWYgDQrkuLvpopjvvJogUmU6IFttaWZdIEhv dyB0byBpZGVudGlmeSBhIGhvc3Qgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzIA0KSGksDQrCoA0K R2xhZCB0byBzZWUgeW91ciBxdWVzdGlvbiwgYmVjYXVzZSBpdCdzIGEgdHlwaWNhbCB1c2VyIGNh c2UgYWJvdXQgbXVsdGlwbGUgaW50ZXJmYWNlLiANCsKgDQpBcyBJIGtub3csIHdoZW4gb25lIGlu dGVyZmFjZSBvZiBCIGhhcyBmYWlsZWQsIHRoZSBuZXR3b3JrIHNob3VsZCBnZXQgaXQswqB0aGVu IGFzayBCIHRvIGNoYW5nZSB0aGUgSVAgZmxvdyBmcm9tIHRoZSBmYWlsZWQgaW50ZXJmYWNlIHRv IGFub3RoZXIuIEF0IHRoZSBzYW1lIHRpbWUsIEEgc2hvdWxkIGtub3cgYWxsIHRyYW5zZm9ybWF0 aW9uIHRvIG1haW50YWluIHRoZWlyIGNvbW11bmljYXRpb24gZnJvbSB0aGUgbmV0d29yay4gSSBw cmVmZXIgdGhlIEFORFNGIHRvIGRvIHRoaXMgd29yay4NCklmIHlvdSBzdGlsbCBoYXZlIG90aGVy IHF1ZXN0aW9ucywgcGxlYXNlIGZlZWwgZnJlZSB0byByYWlzZSB0aGVtLCB0aGFua3MuDQoyMDA5 LzEvMTggc2hzaHJvc2ggPHNoc2hyb3NoQGdtYWlsLmNvbT4NCkhlbGxvLCBhbGwNCsKgDQogICAg IEkgaGF2ZSBhIHByb2JsZW0gYWJvdXQgbXVsdGlwbGUgaW50ZXJmYWNlLiBTdXBwb3NlIGhvc3Qg QSBjb21tdW5pY2F0ZXMgd2l0aCBob3N0IEIsIHdoaWNoIGhhcyBtdWx0aXBsZSBpbnRlcmZhY2Vz LiBXaGVuIG9uZSBpbnRlcmZhY2Ugb2YgQiBmYWlscywgQSBtYXkgc3dpdGNoIHRvIHRoZSBhZGRy ZXNzIG9mIGFub3RoZXIgaW50ZXJmYWNlIG9mIEIgdG/CoG1haW50YWluIHRoZSBjb21tdW5pY2F0 aW9uLiBCdXQgaG93IGNhbiBBIGtub3cgdGhlIHR3byBhZGRyZXNzZXMgY29ycmVzcG9uZGUgdG8g dGhlIHNhbWUgaG9zdCBCPw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbWlmIG1haWxpbmcgbGlzdA0KbWlmQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwptaWYgbWFpbGluZyBsaXN0Cm1pZkBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZgo= From mif-bounces@ietf.org Mon Jan 19 01:01:52 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BF23A69A3; Mon, 19 Jan 2009 01:01:52 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0703A695D for ; Mon, 19 Jan 2009 01:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAido5UyZ-fH for ; Mon, 19 Jan 2009 01:01:50 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id E5E893A69A3 for ; Mon, 19 Jan 2009 01:01:49 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so1826015tib.22 for ; Mon, 19 Jan 2009 01:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:references :subject:message-id:x-mailer:mime-version:content-type; bh=VgS58Q7X0MKZxbCxUyU7c+As5L6LlKWZ/3xkiAy/0lo=; b=PQDUtP3AbJEQOrGzIMgSZfOaV1rPYb9lwMRy8C9yOmTGaGr7DVICJw49YiW3aoEyJM p34uxwGX/G6HqxeAeRllOUMjmkPQ4ou69fSUpuwZrI1vZAYAKm1qs5vGhLBYWLhYOMW1 zOV+e/GD64Z26Sh/ahkTDjEgbdG6qVIX+89Wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=r8Mt4RtkatO7GrO5MeFwtlJ3dKqQS9TLHkrnPyru2C9e3jDodGDWo8ORUhtHFnXzs/ Bc8rh945fLMB6d2eUkqditJWovnc6mnzgjaUkfj7Ho9Qq82lo/dzWmAkQxorLRjCsklt jTb2OnOEEo3I6AqUo47XEJMZx1GSW2cwWbSLg= Received: by 10.110.20.15 with SMTP id 15mr7762951tit.46.1232355693262; Mon, 19 Jan 2009 01:01:33 -0800 (PST) Received: from hwj (th024131.ip.tsinghua.edu.cn [59.66.24.131]) by mx.google.com with ESMTPS id 22sm304209tim.35.2009.01.19.01.01.30 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jan 2009 01:01:31 -0800 (PST) Date: Mon, 19 Jan 2009 17:02:03 +0800 From: "shshrosh" To: "pierrick.seite@orange-ftgroup.com" References: <200901181405165005812@gmail.com>, <3db7b9d60901172229o5f4b0bcwa2afa6440841efec@mail.gmail.com>, <200901181507195318824@gmail.com>, Message-ID: <200901191702005625771@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Cc: mif Subject: Re: [mif] =?utf-8?q?How_to_identify_a_host_with_multiple_interfaces?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985324445==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1985324445== Content-Type: multipart/alternative; boundary="=====003_Dragon275336428738_=====" This is a multi-part message in MIME format. --=====003_Dragon275336428738_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IQ0KDQoNCg0KDQrlj5Hku7bkurrvvJogcGllcnJpY2suc2VpdGVAb3JhbmdlLWZ0 Z3JvdXAuY29tIA0K5Y+R6YCB5pe26Ze077yaIDIwMDktMDEtMTkgIDE2OjQ1OjA0IA0K5pS25Lu2 5Lq677yaIHNoc2hyb3NoQGdtYWlsLmNvbTsganVrYWkuenRlQGdtYWlsLmNvbSANCuaKhOmAge+8 miBtaWZAY29yZTMuYW1zbC5jb20gDQrkuLvpopjvvJogUkU6IFttaWZdSG93IHRvIGlkZW50aWZ5 IGEgaG9zdCB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMgDQogDQpIZWxsbywNCkFORFNGIGRvZXMg bm90IGNvbWUgZnJvbSBJRVRGIHdvcmxkLiBBY3R1YWxseSwgQU5EU0Ygc3RhbmRzIGZvciAiQWNj ZXNzIE5ldHdvcmsgRGlzY292ZXJ5IGFuZCBTZWxlY3Rpb24gRnVuY3Rpb24iLiBUaGlzIGZ1bmN0 aW9uIGhhcyBiZWVuIGludHJvZHVjZWQgaW4gM0dQUCBhcmNoaXRlY3R1cmUgaW4gcmVsZWFzZSA4 IGFuZCBhaW1zIGF0IHByb3ZpZGluZyBpbmZvcm1hdGlvbi9pbmRpY2F0aW9uL3JlY29tbWVuZGF0 aW9uL2V0Yy4uLiB0byB0aGUgbXVsdGktaW50ZXJmYWNlIE1OIGZvciBkaXNjb3ZlcnkgYW5kIHNl bGVjdGlvbiBvZiB0aGUgImJlc3QiIGFjY2Vzcy4gRm9yIGRldGFpbHMsIHBsZWFzZSBzZWUgM0dQ UCBUUyAyMy40MDIgaHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvU3BlY3MvaHRtbC1pbmZvLzIzNDAy Lmh0bSAoc2VjdGlvbiA0LjguMi4xKQ0KUmVnYXJkcywNClBpZXJyaWNrDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IG1pZi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgc2hzaHJvc2gNCkVudm95 w6kgOiBkaW1hbmNoZSAxOCBqYW52aWVyIDIwMDkgMDg6MDcNCsOAIDogS2FpIEp1DQpDYyA6IG1p Zg0KT2JqZXQgOiBSZTogW21pZl1Ib3cgdG8gaWRlbnRpZnkgYSBob3N0IHdpdGggbXVsdGlwbGUg aW50ZXJmYWNlcw0KSGVsbG8gS2FpSnUsDQoNCiAgICAgVGhhbmsgeW91IGZvciB5b3VyIGFkdmlj ZS4NCiAgICAgSSBrbm93IGxpdHRsZSBhYm91dCBBTkRTRi4gSXMgaXQgYSBkcmFmdCBvciBhbiBS RkM/DQogICAgICANCuWPkeS7tuS6uu+8miBLYWkgSnUgDQrlj5HpgIHml7bpl7TvvJogMjAwOS0w MS0xOCAgMTQ6Mjk6NDMgDQrmlLbku7bkurrvvJogc2hzaHJvc2ggDQrmioTpgIHvvJogbWlmIA0K 5Li76aKY77yaIFJlOiBbbWlmXSBIb3cgdG8gaWRlbnRpZnkgYSBob3N0IHdpdGggbXVsdGlwbGUg aW50ZXJmYWNlcyANCkhpLA0KDQpHbGFkIHRvIHNlZSB5b3VyIHF1ZXN0aW9uLCBiZWNhdXNlIGl0 J3MgYSB0eXBpY2FsIHVzZXIgY2FzZSBhYm91dCBtdWx0aXBsZSBpbnRlcmZhY2UuIA0KDQpBcyBJ IGtub3csIHdoZW4gb25lIGludGVyZmFjZSBvZiBCIGhhcyBmYWlsZWQsIHRoZSBuZXR3b3JrIHNo b3VsZCBnZXQgaXQsIHRoZW4gYXNrIEIgdG8gY2hhbmdlIHRoZSBJUCBmbG93IGZyb20gdGhlIGZh aWxlZCBpbnRlcmZhY2UgdG8gYW5vdGhlci4gQXQgdGhlIHNhbWUgdGltZSwgQSBzaG91bGQga25v dyBhbGwgdHJhbnNmb3JtYXRpb24gdG8gbWFpbnRhaW4gdGhlaXIgY29tbXVuaWNhdGlvbiBmcm9t IHRoZSBuZXR3b3JrLiBJIHByZWZlciB0aGUgQU5EU0YgdG8gZG8gdGhpcyB3b3JrLg0KSWYgeW91 IHN0aWxsIGhhdmUgb3RoZXIgcXVlc3Rpb25zLCBwbGVhc2UgZmVlbCBmcmVlIHRvIHJhaXNlIHRo ZW0sIHRoYW5rcy4NCjIwMDkvMS8xOCBzaHNocm9zaCA8c2hzaHJvc2hAZ21haWwuY29tPg0KSGVs bG8sIGFsbA0KDQogICAgIEkgaGF2ZSBhIHByb2JsZW0gYWJvdXQgbXVsdGlwbGUgaW50ZXJmYWNl LiBTdXBwb3NlIGhvc3QgQSBjb21tdW5pY2F0ZXMgd2l0aCBob3N0IEIsIHdoaWNoIGhhcyBtdWx0 aXBsZSBpbnRlcmZhY2VzLiBXaGVuIG9uZSBpbnRlcmZhY2Ugb2YgQiBmYWlscywgQSBtYXkgc3dp dGNoIHRvIHRoZSBhZGRyZXNzIG9mIGFub3RoZXIgaW50ZXJmYWNlIG9mIEIgdG8gbWFpbnRhaW4g dGhlIGNvbW11bmljYXRpb24uIEJ1dCBob3cgY2FuIEEga25vdyB0aGUgdHdvIGFkZHJlc3NlcyBj b3JyZXNwb25kZSB0byB0aGUgc2FtZSBob3N0IEI/DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWlmIG1haWxpbmcgbGlzdA0KbWlmQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0K --=====003_Dragon275336428738_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5h Ow0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBTZWN0 aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5 DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05U LVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVz dGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7 DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5v cm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2Vj dGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJ TUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0N Ck9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1B UkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj5UaGFuayB5b3UhPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjxGT05UIGNvbG9yPSMwMDAwODAg c2l6ZT0yPg0KPEhSPg0KPC9GT05UPg0KPERJVj48Rk9OVCBzaXplPTI+PFNUUk9ORz7lj5Hku7bk urrvvJo8L1NUUk9ORz4gcGllcnJpY2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tIA0KPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNUUk9ORz7lj5HpgIHml7bpl7TvvJo8L1NUUk9O Rz4gMjAwOS0wMS0xOSZuYnNwOyAxNjo0NTowNCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj48U1RST05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiBzaHNocm9zaEBnbWFpbC5jb207IGp1 a2FpLnp0ZUBnbWFpbC5jb20gDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1RS T05HPuaKhOmAge+8mjwvU1RST05HPiBtaWZAY29yZTMuYW1zbC5jb20gPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gUkU6IFttaWZdSG93 IHRvIGlkZW50aWZ5IGEgaG9zdCB3aXRoIA0KbXVsdGlwbGUgaW50ZXJmYWNlcyA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ DQo8RElWPkhlbGxvLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+QU5EU0YmbmJzcDtkb2VzJm5i c3A7bm90Jm5ic3A7Y29tZSZuYnNwO2Zyb20mbmJzcDtJRVRGJm5ic3A7d29ybGQuJm5ic3A7QWN0 dWFsbHksJm5ic3A7QU5EU0YmbmJzcDtzdGFuZHMmbmJzcDtmb3ImbmJzcDsiQWNjZXNzJm5ic3A7 TmV0d29yayZuYnNwO0Rpc2NvdmVyeSZuYnNwO2FuZCZuYnNwO1NlbGVjdGlvbiZuYnNwO0Z1bmN0 aW9uIi4mbmJzcDtUaGlzJm5ic3A7ZnVuY3Rpb24mbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7aW50 cm9kdWNlZCZuYnNwO2luJm5ic3A7M0dQUCZuYnNwO2FyY2hpdGVjdHVyZSZuYnNwO2luJm5ic3A7 cmVsZWFzZSZuYnNwOzgmbmJzcDthbmQmbmJzcDthaW1zJm5ic3A7YXQmbmJzcDtwcm92aWRpbmcm bmJzcDtpbmZvcm1hdGlvbi9pbmRpY2F0aW9uL3JlY29tbWVuZGF0aW9uL2V0Yy4uLiZuYnNwO3Rv Jm5ic3A7dGhlJm5ic3A7bXVsdGktaW50ZXJmYWNlJm5ic3A7TU4mbmJzcDtmb3ImbmJzcDtkaXNj b3ZlcnkmbmJzcDthbmQmbmJzcDtzZWxlY3Rpb24mbmJzcDtvZiZuYnNwO3RoZSZuYnNwOyJiZXN0 IiZuYnNwO2FjY2Vzcy4mbmJzcDtGb3ImbmJzcDtkZXRhaWxzLCZuYnNwO3BsZWFzZSZuYnNwO3Nl ZSZuYnNwOzNHUFAmbmJzcDtUUyZuYnNwOzIzLjQwMiZuYnNwO2h0dHA6Ly93d3cuM2dwcC5vcmcv ZnRwL1NwZWNzL2h0bWwtaW5mby8yMzQwMi5odG0mbmJzcDsoc2VjdGlvbiZuYnNwOzQuOC4yLjEp PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5SZWdhcmRzLDwvRElWPg0KPERJVj5QaWVycmljazwv RElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9ESVY+ DQo8RElWPkRlJm5ic3A7OiZuYnNwO21pZi1ib3VuY2VzQGlldGYub3JnJm5ic3A7W21haWx0bzpt aWYtYm91bmNlc0BpZXRmLm9yZ10mbmJzcDtEZSZuYnNwO2xhJm5ic3A7cGFydCZuYnNwO2RlJm5i c3A7c2hzaHJvc2g8L0RJVj4NCjxESVY+RW52b3nDqSZuYnNwOzombmJzcDtkaW1hbmNoZSZuYnNw OzE4Jm5ic3A7amFudmllciZuYnNwOzIwMDkmbmJzcDswODowNzwvRElWPg0KPERJVj7DgCZuYnNw OzombmJzcDtLYWkmbmJzcDtKdTwvRElWPg0KPERJVj5DYyZuYnNwOzombmJzcDttaWY8L0RJVj4N CjxESVY+T2JqZXQmbmJzcDs6Jm5ic3A7UmU6Jm5ic3A7W21pZl1Ib3cmbmJzcDt0byZuYnNwO2lk ZW50aWZ5Jm5ic3A7YSZuYnNwO2hvc3QmbmJzcDt3aXRoJm5ic3A7bXVsdGlwbGUmbmJzcDtpbnRl cmZhY2VzPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5IZWxsbyZuYnNwO0thaUp1LDwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhh bmsmbmJzcDt5b3UmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7YWR2aWNlLjwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJJm5ic3A7a25vdyZuYnNwO2xpdHRsZSZuYnNw O2Fib3V0Jm5ic3A7QU5EU0YuJm5ic3A7SXMmbmJzcDtpdCZuYnNwO2EmbmJzcDtkcmFmdCZuYnNw O29yJm5ic3A7YW4mbmJzcDtSRkM/PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvRElWPg0KPERJVj7lj5Hku7bkurrvvJombmJzcDtLYWkmbmJzcDtKdSZu YnNwOzwvRElWPg0KPERJVj7lj5HpgIHml7bpl7TvvJombmJzcDsyMDA5LTAxLTE4Jm5ic3A7Jm5i c3A7MTQ6Mjk6NDMmbmJzcDs8L0RJVj4NCjxESVY+5pS25Lu25Lq677yaJm5ic3A7c2hzaHJvc2gm bmJzcDs8L0RJVj4NCjxESVY+5oqE6YCB77yaJm5ic3A7bWlmJm5ic3A7PC9ESVY+DQo8RElWPuS4 u+mimO+8miZuYnNwO1JlOiZuYnNwO1ttaWZdJm5ic3A7SG93Jm5ic3A7dG8mbmJzcDtpZGVudGlm eSZuYnNwO2EmbmJzcDtob3N0Jm5ic3A7d2l0aCZuYnNwO211bHRpcGxlJm5ic3A7aW50ZXJmYWNl cyZuYnNwOzwvRElWPg0KPERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkds YWQmbmJzcDt0byZuYnNwO3NlZSZuYnNwO3lvdXImbmJzcDtxdWVzdGlvbiwmbmJzcDtiZWNhdXNl Jm5ic3A7aXQncyZuYnNwO2EmbmJzcDt0eXBpY2FsJm5ic3A7dXNlciZuYnNwO2Nhc2UmbmJzcDth Ym91dCZuYnNwO211bHRpcGxlJm5ic3A7aW50ZXJmYWNlLiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+QXMmbmJzcDtJJm5ic3A7a25vdywmbmJzcDt3aGVuJm5ic3A7b25lJm5i c3A7aW50ZXJmYWNlJm5ic3A7b2YmbmJzcDtCJm5ic3A7aGFzJm5ic3A7ZmFpbGVkLCZuYnNwO3Ro ZSZuYnNwO25ldHdvcmsmbmJzcDtzaG91bGQmbmJzcDtnZXQmbmJzcDtpdCwmbmJzcDt0aGVuJm5i c3A7YXNrJm5ic3A7QiZuYnNwO3RvJm5ic3A7Y2hhbmdlJm5ic3A7dGhlJm5ic3A7SVAmbmJzcDtm bG93Jm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO2ZhaWxlZCZuYnNwO2ludGVyZmFjZSZuYnNwO3Rv Jm5ic3A7YW5vdGhlci4mbmJzcDtBdCZuYnNwO3RoZSZuYnNwO3NhbWUmbmJzcDt0aW1lLCZuYnNw O0EmbmJzcDtzaG91bGQmbmJzcDtrbm93Jm5ic3A7YWxsJm5ic3A7dHJhbnNmb3JtYXRpb24mbmJz cDt0byZuYnNwO21haW50YWluJm5ic3A7dGhlaXImbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7ZnJv bSZuYnNwO3RoZSZuYnNwO25ldHdvcmsuJm5ic3A7SSZuYnNwO3ByZWZlciZuYnNwO3RoZSZuYnNw O0FORFNGJm5ic3A7dG8mbmJzcDtkbyZuYnNwO3RoaXMmbmJzcDt3b3JrLjwvRElWPg0KPERJVj5J ZiZuYnNwO3lvdSZuYnNwO3N0aWxsJm5ic3A7aGF2ZSZuYnNwO290aGVyJm5ic3A7cXVlc3Rpb25z LCZuYnNwO3BsZWFzZSZuYnNwO2ZlZWwmbmJzcDtmcmVlJm5ic3A7dG8mbmJzcDtyYWlzZSZuYnNw O3RoZW0sJm5ic3A7dGhhbmtzLjwvRElWPg0KPERJVj4yMDA5LzEvMTgmbmJzcDtzaHNocm9zaCZu YnNwOyZsdDtzaHNocm9zaEBnbWFpbC5jb20mZ3Q7PC9ESVY+DQo8RElWPkhlbGxvLCZuYnNwO2Fs bDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7SSZuYnNwO2hhdmUmbmJzcDthJm5ic3A7cHJvYmxlbSZuYnNwO2Fib3V0Jm5ic3A7bXVs dGlwbGUmbmJzcDtpbnRlcmZhY2UuJm5ic3A7U3VwcG9zZSZuYnNwO2hvc3QmbmJzcDtBJm5ic3A7 Y29tbXVuaWNhdGVzJm5ic3A7d2l0aCZuYnNwO2hvc3QmbmJzcDtCLCZuYnNwO3doaWNoJm5ic3A7 aGFzJm5ic3A7bXVsdGlwbGUmbmJzcDtpbnRlcmZhY2VzLiZuYnNwO1doZW4mbmJzcDtvbmUmbmJz cDtpbnRlcmZhY2UmbmJzcDtvZiZuYnNwO0ImbmJzcDtmYWlscywmbmJzcDtBJm5ic3A7bWF5Jm5i c3A7c3dpdGNoJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDthZGRyZXNzJm5ic3A7b2YmbmJzcDthbm90 aGVyJm5ic3A7aW50ZXJmYWNlJm5ic3A7b2YmbmJzcDtCJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3RoZSZuYnNwO2NvbW11bmljYXRpb24uJm5ic3A7QnV0Jm5ic3A7aG93Jm5ic3A7Y2FuJm5i c3A7QSZuYnNwO2tub3cmbmJzcDt0aGUmbmJzcDt0d28mbmJzcDthZGRyZXNzZXMmbmJzcDtjb3Jy ZXNwb25kZSZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7c2FtZSZuYnNwO2hvc3QmbmJzcDtCPzwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L0RJVj4NCjxESVY+bWlmJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4N CjxESVY+bWlmQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWlmPC9ESVY+DQo8RElWPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9I VE1MPg0K --=====003_Dragon275336428738_=====-- --===============1985324445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1985324445==-- From mif-bounces@ietf.org Mon Jan 19 01:06:38 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F41E3A6B84; Mon, 19 Jan 2009 01:06:38 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E99928C19A for ; Mon, 19 Jan 2009 01:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnDFKVUTBLUV for ; Mon, 19 Jan 2009 01:06:36 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id A9B2D3A695C for ; Mon, 19 Jan 2009 01:06:35 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so1827738tib.22 for ; Mon, 19 Jan 2009 01:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:references :subject:message-id:x-mailer:mime-version:content-type; bh=eTpEtu6IvOjJDj+F1vIfyiEXMs8gDNkblhrTQYoez3g=; b=LyvRHw42EQ6GVqBmWpxl5MmcTPS6vhFLFf3ERbovQCga7CknTMf4FYfhUUglJz+6rU EMGAGC95Z2VT1VVqNYeb2B8FZm9K4CyhyAn9r3W4J41rhaTWZMegfBERCoLQO6gNYPzh 7y/yEa62MYmLZVJa+nhFSvuBJnnpm51ysXABY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=XUuvhH95gdsJNWxEcwuNmGLW659Wn2ZnW4WgtNEcGNgeKV8FhHVjlIh84IE51oZ7+G twzqklFGmhKNFgoWndl8yInJC3/Z5Oxtizl4JKAEdu6uXgSCD/FT7mTVBNsV2jDxsTyX yRvg0/H/q8rq6F4KZ0R449g7xYblmkxws9Rfc= Received: by 10.110.103.5 with SMTP id a5mr7783185tic.30.1232355979387; Mon, 19 Jan 2009 01:06:19 -0800 (PST) Received: from hwj (th024131.ip.tsinghua.edu.cn [59.66.24.131]) by mx.google.com with ESMTPS id b4sm644999tic.2.2009.01.19.01.06.17 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jan 2009 01:06:18 -0800 (PST) Date: Mon, 19 Jan 2009 17:06:49 +0800 From: "shshrosh" To: "Hui Deng" References: <200901181405165005812@gmail.com>, , <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> Message-ID: <200901191706482187921@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Cc: mif Subject: Re: [mif] =?utf-8?q?How_to_identify_a_host_with_multiple_interfaces?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022480527==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============2022480527== Content-Type: multipart/alternative; boundary="=====003_Dragon884137448442_=====" This is a multi-part message in MIME format. --=====003_Dragon884137448442_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEh1aSBEZW5nLA0KDQpNeSBtYWluIHByb2JsZW0gaXMgbm90IG9uIHRoZSBtb3ZlbWVudCBh bmQgZmFsbGJhY2suIE15IG1haW4gcG9pbnQgaXMgdGhlIGlkZW50aWZpY2F0aW9uIG9mIGEgbm9k ZSB3aXRoIG11bGl0cGxlIGludGVyZmFjZS4gU28gaWYgb3RoZXIgbm9kZXMgZ2V0IHRoZSBpZGVu dGlmaWNhdGlvbiwgdGhleSBrbm93IHRoZSBpbnRlcmZhY2VzIGNvcnJlc3BvbmRlIHRvIHRoZSBz YW1lIG5vZGUuDQoNCg0KDQoNCuWPkeS7tuS6uu+8miBIdWkgRGVuZyANCuWPkemAgeaXtumXtO+8 miAyMDA5LTAxLTE5ICAxNTo0MjoyMyANCuaUtuS7tuS6uu+8miB0ZWVtdS5zYXZvbGFpbmVuIA0K 5oqE6YCB77yaIHNoc2hyb3NoOyBtaWYgDQrkuLvpopjvvJogUmU6IFttaWZdIEhvdyB0byBpZGVu dGlmeSBhIGhvc3Qgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzIA0KSGksIFRlZW11DQoNCkkgYWdy ZWUgeW91ciBwb2ludCBoZXJlLCBmYWxsYmFjayBhbmQgbW92ZW1lbnQgdG8gdXNlIGFub3RoZXIg aW50ZXJmYWNlIGZvciB0aGUgc2FtZSBzZXNzaW9uIHdpbGwgYmUgbm90IGluIHRoZSBtaWYgc2Nv cGUuDQoNCi1IdWkNCg0KDQoyMDA5LzEvMTkgPHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPg0K DQpIaSwNCg0KSW4gbXkgb3BpbmlvbiB0aGUgZmFsbGJhY2sgKG9yIG1vdmVtZW50KSB0byB1c2Ug YW5vdGhlciBpbnRlcmZhY2Ugb2YgQiBmb3IgdGhlIHNhbWUgc2Vzc2lvbiBpcyBub3QgaW4gbWlm IHNjb3BlLCBidXQgaXQgaXMgbW9yZSB3b3JrcyBmb3Igc2hpbTYvaGlwL2V0YywgcmlnaHQ/IE9y IGV2ZW4gYXQgYXBwbGljYXRpb24gbGV2ZWwgdG8gcmVjb25uZWN0IHRvIGRpZmZlcmVudCBhZGRy ZXNzIG9mIEIgYWZ0ZXIgb25lIGZhaWxzICh0aGUgbGlzdCBvZiBhZGRyZXNzZXMgYXBwbGljYXRp b24gbGVhcm5zIGUuZy4gZnJvbSBETlMpLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCiAgICBUZWVtdQ0K DQoNCg0KDQpGcm9tOiBtaWYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pZi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IHNoc2hyb3NoDQpTZW50OiAxOCBKYW51YXJ5LCAyMDA5 IDA4OjA1DQpUbzogbWlmDQpTdWJqZWN0OiBbbWlmXSBIb3cgdG8gaWRlbnRpZnkgYSBob3N0IHdp dGggbXVsdGlwbGUgaW50ZXJmYWNlcw0KDQoNCkhlbGxvLCBhbGwNCg0KSSBoYXZlIGEgcHJvYmxl bSBhYm91dCBtdWx0aXBsZSBpbnRlcmZhY2UuIFN1cHBvc2UgaG9zdCBBIGNvbW11bmljYXRlcyB3 aXRoIGhvc3QgQiwgd2hpY2ggaGFzIG11bHRpcGxlIGludGVyZmFjZXMuIFdoZW4gb25lIGludGVy ZmFjZSBvZiBCIGZhaWxzLCBBIG1heSBzd2l0Y2ggdG8gdGhlIGFkZHJlc3Mgb2YgYW5vdGhlciBp bnRlcmZhY2Ugb2YgQiB0byBtYWludGFpbiB0aGUgY29tbXVuaWNhdGlvbi4gQnV0IGhvdyBjYW4g QSBrbm93IHRoZSB0d28gYWRkcmVzc2VzIGNvcnJlc3BvbmRlIHRvIHRoZSBzYW1lIGhvc3QgQj8N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pZiBt YWlsaW5nIGxpc3QNCm1pZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taWYNCg== --=====003_Dragon884137448442_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5h Ow0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBTZWN0 aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5 DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05U LVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVz dGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7 DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5v cm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2Vj dGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJ TUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0N Ck9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1B UkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksIEh1aSBEZW5nLDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+TXkgbWFpbiBwcm9ibGVtIGlzIG5vdCBvbiB0aGUg bW92ZW1lbnQgYW5kIGZhbGxiYWNrLiBNeSANCm1haW4gcG9pbnQgaXMgdGhlIGlkZW50aWZpY2F0 aW9uIG9mIGEgbm9kZSB3aXRoIG11bGl0cGxlIGludGVyZmFjZS4gU28gaWYgb3RoZXIgDQpub2Rl cyZuYnNwO2dldCB0aGUgaWRlbnRpZmljYXRpb24sIHRoZXkga25vdyB0aGUgaW50ZXJmYWNlcyBj b3JyZXNwb25kZSB0byB0aGUgDQpzYW1lIG5vZGUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8L0ZP TlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7lj5Hku7bkurrvvJo8 L1NUUk9ORz4gSHVpIERlbmcgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg c2l6ZT0yPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IDIwMDktMDEtMTkmbmJzcDsg MTU6NDI6MjMgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4gdGVlbXUuc2F2b2xhaW5lbiANCjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuaKhOmAge+8mjwv U1RST05HPiBzaHNocm9zaDsgbWlmIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIHNpemU9Mj48U1RST05HPuS4u+mimO+8mjwvU1RST05HPiBSZTogW21pZl0gSG93IHRvIGlk ZW50aWZ5IGEgDQpob3N0IHdpdGggbXVsdGlwbGUgaW50ZXJmYWNlcyA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj5IaSwgVGVlbXU8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkkgYWdyZWUgeW91ciZuYnNwO3BvaW50IGhlcmUsIGZhbGxiYWNrIGFuZCBtb3Zl bWVudCB0byB1c2UgYW5vdGhlciANCmludGVyZmFjZSBmb3IgdGhlIHNhbWUgc2Vzc2lvbiB3aWxs IGJlIG5vdCBpbiB0aGUgbWlmIHNjb3BlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ LUh1aTxCUj48QlI+PC9ESVY+DQo8RElWIGNsYXNzPWdtYWlsX3F1b3RlPjIwMDkvMS8xOSA8U1BB TiBkaXI9bHRyPiZsdDs8QSANCmhyZWY9Im1haWx0bzp0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNv bSI+dGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb208L0E+Jmd0OzwvU1BBTj48QlI+DQo8QkxPQ0tR VU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lO OiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4NCiAgPERJ ViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYSI+DQogIDxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOPjxGT05UIGZhY2U9dmVyZGFuYT5IaSw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTj48Rk9OVCBmYWNlPXZl cmRhbmE+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4+PEZPTlQgZmFjZT12ZXJkYW5hPkluIG15IG9waW5pb24gdGhlIGZhbGxiYWNrIA0K ICAob3IgbW92ZW1lbnQpIHRvIHVzZSBhbm90aGVyIGludGVyZmFjZSBvZiBCIGZvciB0aGUgc2Ft ZSBzZXNzaW9uIGlzIG5vdCBpbiBtaWYgDQogIHNjb3BlLCBidXQgaXQgaXMgbW9yZSB3b3JrcyBm b3Igc2hpbTYvaGlwL2V0YywgcmlnaHQ/IE9yIGV2ZW4gYXQgYXBwbGljYXRpb24gDQogIGxldmVs IHRvIHJlY29ubmVjdCB0byBkaWZmZXJlbnQgYWRkcmVzcyBvZiBCIGFmdGVyIG9uZSBmYWlscyAo dGhlIGxpc3Qgb2YgDQogIGFkZHJlc3NlcyBhcHBsaWNhdGlvbiBsZWFybnMgZS5nLiBmcm9tIERO UykuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4+ PEZPTlQgZmFjZT12ZXJkYW5hPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOPjxGT05UIGZhY2U9dmVyZGFuYT5CZXN0IA0KICByZWdhcmRz LDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOPjxG T05UIGZhY2U9dmVyZGFuYT48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTj4mbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgDQogIGZhY2U9dmVy ZGFuYT5UZWVtdTwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPg0KICA8QkxPQ0tRVU9URSBkaXI9bHRy IA0KICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1M RUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgIDxESVYgbGFu Zz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQogICAgPEhSPg0KICAgIDxGT05UIGZhY2U9VGFo b21hPjxCPkZyb206PC9CPiA8QSBocmVmPSJtYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmciIA0K ICAgIHRhcmdldD1fYmxhbms+bWlmLWJvdW5jZXNAaWV0Zi5vcmc8L0E+IFttYWlsdG86PEEgDQog ICAgaHJlZj0ibWFpbHRvOm1pZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1pZi1i b3VuY2VzQGlldGYub3JnPC9BPl0gDQogICAgPEI+T24gQmVoYWxmIE9mIDwvQj5leHQgc2hzaHJv c2g8QlI+PEI+U2VudDo8L0I+IDE4IEphbnVhcnksIDIwMDkgDQogICAgMDg6MDU8QlI+PEI+VG86 PC9CPiBtaWY8QlI+PEI+U3ViamVjdDo8L0I+IFttaWZdIEhvdyB0byBpZGVudGlmeSBhIGhvc3Qg d2l0aCANCiAgICBtdWx0aXBsZSBpbnRlcmZhY2VzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAg PERJViBjbGFzcz1JaDJFM2Q+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9 VmVyZGFuYT4NCiAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48U1BBTj48L1NQQU4+SGVsbG8s IGFsbDwvRk9OVD48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVYgc3R5bGU9 IlRFWFQtSU5ERU5UOiAyZW0iPkkgaGF2ZSBhIHByb2JsZW0gYWJvdXQgbXVsdGlwbGUgaW50ZXJm YWNlLiANCiAgICBTdXBwb3NlIGhvc3QgQSBjb21tdW5pY2F0ZXMgd2l0aCBob3N0IEIsIHdoaWNo IGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzLiBXaGVuIA0KICAgIG9uZSBpbnRlcmZhY2Ugb2YgQiBm YWlscywgQSBtYXkgc3dpdGNoIHRvIHRoZSBhZGRyZXNzIG9mIGFub3RoZXIgaW50ZXJmYWNlIA0K ICAgIG9mIEIgdG8mbmJzcDttYWludGFpbiB0aGUgY29tbXVuaWNhdGlvbi4gQnV0IGhvdyBjYW4g QSBrbm93IHRoZSB0d28gDQogICAgYWRkcmVzc2VzIGNvcnJlc3BvbmRlIHRvIHRoZSBzYW1lIGhv c3QgQj88L0RJVj48L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT1WZXJkYW5hPjwvRk9OVD48L0RJVj48 L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPm1pZiANCiAgbWFpbGluZyBsaXN0PEJSPjxBIGhyZWY9Im1h aWx0bzptaWZAaWV0Zi5vcmciPm1pZkBpZXRmLm9yZzwvQT48QlI+PEEgDQogIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmIiANCiAgdGFyZ2V0PV9ibGFuaz5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZjwvQT48QlI+PEJSPjwvQkxP Q0tRVU9URT48L0RJVj48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon884137448442_=====-- --===============2022480527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2022480527==-- From mif-bounces@ietf.org Mon Jan 19 03:47:14 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB093A693F; Mon, 19 Jan 2009 03:47:14 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE6F28C15B for ; Mon, 19 Jan 2009 03:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLxIQ9Yasb+k for ; Mon, 19 Jan 2009 03:47:12 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 23F253A686D for ; Mon, 19 Jan 2009 03:47:11 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2732635rvf.49 for ; Mon, 19 Jan 2009 03:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=osEnA1yBof0pIDievYt5Dv5m++Wf3XvJO/7uAxT551Q=; b=OEHqxX23Fudw+xnasXa1JrWRl90sk8/cFLDwe1jrdesn8geOh2CqwDnFLKiMi3Lj2j g4uYpglwmWnO++Bwhlnwn+0kiVW2barvxzDUbUbvBv+25vbrX/YMy/rwSgWQQJQU6UPI 14OZle3OecdESRQmEtcdjMi8S8bLOAodJneSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=SBnjZO5i49iUK7GlrJsa9a9+FbrF3dKHRu6qhdZr3hnE270fZ4ZQZ4YceJTDIMgJZ3 iLnL3jpML2+KGe0FoYRplN2z3iE0/sf1iHQJuqrhUM/sdbBaPrvey25xlRtRHuJvpm5y hCnpRGMbBPrEAp/J9y7V4ItG5R5SUOhkit5aI= Received: by 10.143.9.11 with SMTP id m11mr2342784wfi.44.1232365615481; Mon, 19 Jan 2009 03:46:55 -0800 (PST) Received: by 10.142.224.2 with HTTP; Mon, 19 Jan 2009 03:46:55 -0800 (PST) Message-ID: <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> Date: Mon, 19 Jan 2009 19:46:55 +0800 From: "Kai Ju" To: "Hui Deng" In-Reply-To: <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> MIME-Version: 1.0 References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1610565791==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1610565791== Content-Type: multipart/alternative; boundary="----=_Part_13714_29858003.1232365615468" ------=_Part_13714_29858003.1232365615468 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Hui and Peny Thanks for your comment. Please see the reply. [Hui]ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for 23.402 for non-3GPP access still a issue, it may need some mechanism to coordinate between two type of access entwork.what do you think? The ANSDF solution is just a sample, because there is no one type of server which is defined to provide the policy in IETF until now. So let us consider it be general, which means it's one policy server that provides the routing policy to UE when UE is connecting it. [Hui]To challenge one default link, it really takes time for mif to consider on it, current first step in mif is to consider some straight forward way which is simple to resolve some issues. Agree with you, and we'll keep working on it. 2009/1/19 Hui Deng > Hi, Peng and Kai, > > See reply inline below. thanks for the discussion. > 2009/1/19 Peny Yang > >> Hi, Kai: >> Nice point. Please check the lines below: >> >> > As you said, there are multiple way to assign the routing policy by in >> the >> > mobile access network. As viewed from the aspect of terminal, I think >> its a >> > good idea that terminal can get its routing policy from the ANDSF. >> [Peny] ANDSF may be one of the choices. But ANDSF just follows the >> assumption of generic "one default link" IP model. So, in 3GPP, even >> though ANDSF can help UE to select accesses and find the route, UE can >> only choose one of the interfaces as a result. >> Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, >> since it's a specific definition in one SDO. > > ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for > 23.402 for non-3GPP access still a issue, it may need some mechanism to > coordinate > between two type of access entwork.what do you think? > > >> >> > We think a default policy can be used, when terminal can't find >> > corresponding policy in the routing policy from the ANDSF. The default >> > policy can be sent by the network. >> [Peny] Could we give a chance to MN to change the policy (like user >> preference) ? >> >> > On another hand, I am a little confused between MIF and Multihoming, >> would >> > you please help me to clarify the difference between them? >> [Peny] I am also not clear yet. Just give some lines as a seed for >> discussion. In my personal feeling, MIF is to change the "one default >> link" feature of current generic IP model. Multi-homing is to ensure >> the reachability and reliability of IP network. Well, in multi-homing >> MN scenarios, multi-link-multi-address is also one case. But, in this >> case, MN only can choose one link as default. >> Some other comments? >> > To challenge one default link, it really takes time for mif to consider on > it, current first step in mif is to consider some straight forward way which > is simple to resolve some issues. > Regarding to multi-homing, I guess that it is more site multi-homing. > For last multi-link-multi-address mn's scenario, it will be one of MIF > scenario. > > thanks > > -Hui > > >> >> BRG >> Peny >> > > ------=_Part_13714_29858003.1232365615468 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Hui and Peny
 
Thanks for your comment. Please see the reply.
 
[Hui]ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for
23.402 for non-3GPP access still a issue, it may need some mechanism to coordinate
between two type of access entwork.what do you think?
The ANSDF solution is just a sample, because there is no one type of server which is
defined to provide the policy in IETF until now. So let us consider it be general, which
means it's one policy server that provides the routing policy to UE when UE is connecting
it.
 
[Hui]To challenge one default link, it really takes time for mif to consider on it, current first step in mif is to consider some straight forward way which is simple to resolve some issues.
Agree with you, and we'll keep working on it.

2009/1/19 Hui Deng <denghui02@gmail.com>
Hi, Peng and Kai,
 
See reply inline below. thanks for the discussion.
2009/1/19 Peny Yang <peng.yang.chn@gmail.com>

Hi, Kai:
Nice point. Please check the lines below:

> As you said, there are multiple way to assign the routing policy by in the
> mobile access network. As viewed from the aspect of terminal, I think its a
> good idea that terminal can get its routing policy from the ANDSF.
[Peny] ANDSF may be one of the choices. But ANDSF just follows the
assumption of generic "one default link" IP model. So, in 3GPP, even
though ANDSF can help UE to select accesses and find the route, UE can
only choose one of the interfaces as a result.
Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP,
since it's a specific definition in one SDO.
ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for
23.402 for non-3GPP access still a issue, it may need some mechanism to coordinate
between two type of access entwork.what do you think?
 

> We think a default policy can be used,  when terminal can't find
> corresponding policy in the routing policy from the ANDSF. The default
> policy can be sent by the network.
[Peny] Could we give a chance to MN to change the policy (like user
preference) ?

> On another hand, I am a little confused between MIF and Multihoming, would
> you please help me to clarify the difference between them?
[Peny] I am also not clear yet. Just give some lines as a seed for
discussion. In my personal feeling, MIF is to change the "one default
link" feature of current generic IP model. Multi-homing is to ensure
the reachability and reliability of IP network. Well, in multi-homing
MN scenarios, multi-link-multi-address is also one case. But, in this
case, MN only can choose one link as default.
Some other comments?
To challenge one default link, it really takes time for mif to consider on it, current first step in mif is to consider some straight forward way which is simple to resolve some issues.
Regarding to multi-homing, I guess that it is more site multi-homing.
For last multi-link-multi-address mn's scenario, it will be one of MIF scenario.
 
thanks
 
-Hui
 

BRG
Peny


------=_Part_13714_29858003.1232365615468-- --===============1610565791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1610565791==-- From mif-bounces@ietf.org Mon Jan 19 06:39:03 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AAF28C1C4; Mon, 19 Jan 2009 06:39:03 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94C53A69AC for ; Mon, 19 Jan 2009 06:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqm9cil-v1gV for ; Mon, 19 Jan 2009 06:39:01 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id E1CED28C1B7 for ; Mon, 19 Jan 2009 06:39:00 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2329099ywj.49 for ; Mon, 19 Jan 2009 06:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1yVsj5S/KMSzLuQG9WcjGE8lE+fM6+xhBXs3uV5dqsY=; b=fLvau9aHMwthup06lSwo1dTH9YKVDxqK8AK9Ag40J6yb2xcmGulzzA6ehAczih1zau FFiizHvOmNMHb/gImKJFNWSOkAfEQKGVdeBPNh7oUwSASNeDGMLJvCiz9GZKR4pCisTN wuLK5n/u/fXbB/T5o1gQB40yhgw5iBKjbsIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NHhbcpLKsuUk4c2GEROpMeWyzGJsOJ19CQ/eSRKRKjCItP/i93JKYE1/0ax9MFZevn rLFG09+aKdY9BasEXe/DaU5ffZ9uoq2akf7eSZy//flKAzpHYPlD20DGZnN4MyNVve0J zU8QWA9NUOk1puq/TyAUrU3ZP3IQ8vQWvmaT0= MIME-Version: 1.0 Received: by 10.100.138.10 with SMTP id l10mr3937439and.25.1232374207612; Mon, 19 Jan 2009 06:10:07 -0800 (PST) In-Reply-To: <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> Date: Mon, 19 Jan 2009 22:10:07 +0800 Message-ID: <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> From: Peny Yang To: Kai Ju Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Kai: > The ANSDF solution is just a sample, because there is no one type of server > which is > defined to provide the policy in IETF until now. So let us consider it be > general, which > means it's one policy server that provides the routing policy to UE when UE > is connecting > it. [Peny] Agree. 3GPP ANSDF could be a good reference when we make the MIF solutions. BRG Peny >> >> Hi, Peng and Kai, >> >> See reply inline below. thanks for the discussion. >> 2009/1/19 Peny Yang >>> >>> Hi, Kai: >>> Nice point. Please check the lines below: >>> >>> > As you said, there are multiple way to assign the routing policy by in >>> > the >>> > mobile access network. As viewed from the aspect of terminal, I think >>> > its a >>> > good idea that terminal can get its routing policy from the ANDSF. >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows the >>> assumption of generic "one default link" IP model. So, in 3GPP, even >>> though ANDSF can help UE to select accesses and find the route, UE can >>> only choose one of the interfaces as a result. >>> Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, >>> since it's a specific definition in one SDO. >> >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work for >> 23.402 for non-3GPP access still a issue, it may need some mechanism to >> coordinate >> between two type of access entwork.what do you think? >> >>> >>> > We think a default policy can be used, when terminal can't find >>> > corresponding policy in the routing policy from the ANDSF. The default >>> > policy can be sent by the network. >>> [Peny] Could we give a chance to MN to change the policy (like user >>> preference) ? >>> >>> > On another hand, I am a little confused between MIF and Multihoming, >>> > would >>> > you please help me to clarify the difference between them? >>> [Peny] I am also not clear yet. Just give some lines as a seed for >>> discussion. In my personal feeling, MIF is to change the "one default >>> link" feature of current generic IP model. Multi-homing is to ensure >>> the reachability and reliability of IP network. Well, in multi-homing >>> MN scenarios, multi-link-multi-address is also one case. But, in this >>> case, MN only can choose one link as default. >>> Some other comments? >> >> To challenge one default link, it really takes time for mif to consider on >> it, current first step in mif is to consider some straight forward way which >> is simple to resolve some issues. >> Regarding to multi-homing, I guess that it is more site multi-homing. >> For last multi-link-multi-address mn's scenario, it will be one of MIF >> scenario. >> >> thanks >> >> -Hui >> >>> >>> BRG >>> Peny >> > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Mon Jan 19 06:52:23 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2E328C1D4; Mon, 19 Jan 2009 06:52:23 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C627D3A67E4 for ; Mon, 19 Jan 2009 06:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5BM4oXKEyxa for ; Mon, 19 Jan 2009 06:52:20 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 067783A68AE for ; Mon, 19 Jan 2009 06:52:19 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Mon, 19 Jan 2009 23:52:04 +0900 X-ReadCheckMessageID: X-ReadCheckName: mif%40ietf.org From: "Hong Yong-Geun" To: "Hui Deng" Date: Mon, 19 Jan 2009 23:52:04 +0900 Priority: normal Comment: ??, u-??, Content-Class: urn:content-classes:message Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 In-Reply-To: <1d38a3350901182337k5d08a312t705622e1237f2a9b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif thread-index: Acl6CNQ5c7gTLno5Qw6wJABiymB5tgAMBz8QAAMjMvw= References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> <1d38a3350901182337k5d08a312t705622e1237f2a9b@mail.gmail.com> X-OriginalArrivalTime: 19 Jan 2009 14:52:04.0438 (UTC) FILETIME=[7E23D760:01C97A45] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2019927727==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============2019927727== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A45.25D72A80" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A45.25D72A80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C97A45.25D72A80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4NCjxESVYgbGFuZz1LTyBzdHlsZT0idGFiLWludGVydmFsOiA0MC4wcHQiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPERJViBjbGFzcz1TZWN0aW9uMT4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNp emU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFz dC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGkt dGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5IaS4uSHVpLi48 P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEu MHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsg bXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1m b250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6Dr lJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1p bm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFu c2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29s b3I6IGRhcmsyIj5UaGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QuPG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1z by1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0 aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFy azIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05U LUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNv LWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBt aW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRp LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlu b3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5JIHRoaW5rIHRoYXQgdGhlIGRpc2N1c3Np b24gb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpc3N1ZXMgd2hpY2ggaXMgbm90IHJlbGF0ZWQgdG8g TW9iaWxlIElQdjYvTkVNTyBpbiBNRVhUIFdHPEJSPmlzIG5vdCB1c2VmdWwgYmVjYXVzZSA8Rk9O VCBmYWNlPVN5c3RlbT5NRVhUPC9GT05UPiBXRyBpcyBmb2N1c2luZyBvbiB0aGUgZXh0ZW5zaW9u IG9mIE1vYmlsZSBJUHY2L05FTU8uIDxCUj5UaGUgaW50ZW5zaW9uIG9mIG15IHByZXZpb3VzIHR3 byBkcmFmdHMgaXMgbm90IGV4dGVuZGluZyBNb2JpbGUgSVB2Ni9ORU1PLjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUn OyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2kt dGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6 IGRhcmsyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7 IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9u dDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28t YmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6 IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+SW5zdGVhZCwgaWYgeW91IHdvbmRl ciB0aGUgcmVzcG9uc2Ugb2YgTW9uYW1pNiBXRyBmb3IgbXkgcHJldmlvdXMgdHdvIGRyYWZ0cywg eW91IGNhbiByZWZlciB0aGUgNjR0aCBtb25hbWk2IFdHPEJSPm1lZXRpbmcgcmVwb3J0IHdoZW4g SSBwcmVzZW50ZWQuIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsg bXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250 OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDog bWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj48QSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzA1bm92L21vbmFtaTYuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy8wNW5vdi9tb25hbWk2Lmh0bWw8L0E+PFNQQU4gc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPig2dGggcHJlc2VudGF0aW9uKTxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDq s6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6 IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28t aGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1l Y29sb3I6IGRhcmsyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAx MS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhl bWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGlu OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1l LWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+VGhhbmtzLi48bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg 6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250 OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNv LWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVt ZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMx ZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTog MTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRo ZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRp bjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVt ZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPllvbmctR2V1bi4uPG86 cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7 IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28t dGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxESVYgc3R5 bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVS LVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTogMGNt OyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBjbTsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KPERJVj4NCjxESVYgc3R5bGU9IkJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IFBBRERJTkctTEVGVDogMGNtOyBQQURESU5HLUJPVFRPTTogMGNtOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQ7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lIj4NCjxQIGNsYXNzPU1zb05vcm1hbD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPkZyb206PC9T UEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPiA8U1BBTiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFO PiBEZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGdtYWlsLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBNb25k YXksIEphbnVhcnkgMTksIDIwMDkgNDozOCBQTTxCUj48Qj5Ubzo8L0I+IDwvU1BBTj48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogVGFob21hOyBtc28t YXNjaWktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBUYWhvbWEi Pu2Zjeyaqeq3vDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxCUj48Qj5DYzo8L0I+IG1pZkBp ZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFttaWZdIG1vYmlsaXR5IGlzc3VlcyBhbmQg Z2VuZXJhbCBpc3N1ZXMgb24gbWlmPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPkhpLCBI b25nLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8 RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+Q291bGQgeW91IG1ha2Ug YSBzaG9ydCA8U1BBTiBjbGFzcz1HcmFtRT5zdW1tYXJ5ICw8L1NQQU4+IGNyb3NzLXBvc3QgdG8g dGhlIDxTUEFOIGNsYXNzPVNwZWxsRT5tZXh0PC9TUEFOPi9taWYsIGFuZCBjYyB0byBjaGFpcnMs IGFuZDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gY2xhc3M9R3JhbUU+PFNQQU4gbGFuZz1FTi1VUz5zZWU8L1NQQU4+PC9TUEFOPjxT UEFOIGxhbmc9RU4tVVM+IHRoZWlyIGNvbW1lbnRzPzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5NYW55IHRoYW5r czxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElW Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+LTxTUEFOIGNsYXNzPVNwZWxs RT5IdWk8L1NQQU4+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjIwMDkvMS8xNSBIb25nIFlvbmctR2V1biAmbHQ7 PEEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIj55Z2hvbmdAZXRyaS5yZS5rcjwvQT4m Z3Q7PG86cD48L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9u dC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7 Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFN5c3RlbSI+IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0K PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SGk8U1BBTiBjbGFzcz1HcmFtRT4uLjwvU1BBTj48U1BB TiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFOPjxTUEFOIGNsYXNzPUdyYW1FPi4uPC9TUEFOPjwvU1BB Tj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBT eXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTog U3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVt Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVtIj5ObywgSSBk aWRuJ3QgZGlzY3VzcyB3aXRoIDxTUEFOIGNsYXNzPVNwZWxsRT5tZXh0PC9TUEFOPiA8U1BBTiBj bGFzcz1TcGVsbEU+d2c8L1NQQU4+LiBJIHByZXNlbnRlZCBhbmQgZGlzY3Vzc2VkIHdpdGggbW9u YW1pNiA8U1BBTiBjbGFzcz1TcGVsbEU+d2c8L1NQQU4+IGF0IDY0dGggSUVURiBtZWV0aW5nLjwv U1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0ZW0i PkFuZCBpdCB3YXMgbm90IGFkb3B0ZWQgaW4gbW9uYW1pNiA8U1BBTiBjbGFzcz1TcGVsbEU+d2c8 L1NQQU4+IGJlY2F1c2UgaXQgd2FzIG5vdCBpbiB0aGUgc2NvcGUgb2YgbW9uYW1pNiA8U1BBTiBj bGFzcz1TcGVsbEU+d2c8L1NQQU4+LjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5 N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogU3lzdGVtIj5CZXN0IHJlZ2FyZHMuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48 L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPllvbmctR2V1bjxTUEFOIGNsYXNzPUdyYW1F Pi4uPC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2Np aS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4m bmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWIHN0eWxlPSJCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006IDBjbTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVItQk9UVE9N OiBtZWRpdW0gbm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkZyb206PC9TUEFOPjwvQj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8U1BBTiBj bGFzcz1TcGVsbEU+SHVpPC9TUEFOPiBEZW5nIFttYWlsdG86PEEgaHJlZj0ibWFpbHRvOmRlbmdo dWkwMkBnbWFpbC5jb20iIHRhcmdldD1fYmxhbms+ZGVuZ2h1aTAyQGdtYWlsLmNvbTwvQT5dIDxC Uj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEphbnVhcnkgMTUsIDIwMDkgMzo0NyBQTTxCUj48Qj5U bzo8L0I+IDwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog U3lzdGVtIj7tmY3smqnqt7wgPFNQQU4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1NQ QU4+PC9QPg0KPERJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48QlI+PEI+Q2M6 PC9CPiA8QSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1pZkBpZXRm Lm9yZzwvQT48QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbbWlmXSBtb2JpbGl0eSBpc3N1ZXMgYW5k IGdlbmVyYWwgaXNzdWVzIG9uIG1pZjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48 L0RJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0K PERJVj4NCjxQPjxTUEFOIGNsYXNzPUdyYW1FPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+eW91PC9TUEFOPjwvU1BBTj48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiBh bHJlYWR5IGhhZCBhIGRpc2N1c3Npb24gd2l0aCA8U1BBTiBjbGFzcz1TcGVsbEU+bWV4dDwvU1BB Tj4gPFNQQU4gY2xhc3M9U3BlbGxFPndnPC9TUEFOPiwgdGhleSBhcmUgbm90IGFkb3B0aW5nIHRo aXMgd29yaz88bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5 c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAxMnB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBTeXN0ZW0iPi08U1BBTiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFOPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxQPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3Rl bSI+MjAwOS8xLzE0IEhvbmcgWW9uZy1HZXVuICZsdDs8QSBocmVmPSJtYWlsdG86eWdob25nQGV0 cmkucmUua3IiIHRhcmdldD1fYmxhbms+eWdob25nQGV0cmkucmUua3I8L0E+Jmd0OzxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IDxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SGk8 U1BBTiBjbGFzcz1HcmFtRT4uLjwvU1BBTj48U1BBTiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFOPjxT UEFOIGNsYXNzPUdyYW1FPi4uPC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMx ZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZh bWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8 UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdk OyBGT05ULUZBTUlMWTogU3lzdGVtIj5UaGFuayB5b3UgZm9yIGNvbW1lbnRzLiBTZWUgYmVsb3cg aW5saW5lIHJlcGx5LjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1h c2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVt Ij4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlM WTogU3lzdGVtIj5CZXN0IHJlZ2FyZHMuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9Q Pg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFm NDk3ZDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQ PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPllvbmctR2V1bjxTUEFOIGNsYXNzPUdyYW1FPi4uPC9TUEFO PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZh bWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQ QU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog U3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWIHN0eWxlPSJCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006IDBjbTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVItQk9UVE9NOiBtZWRpdW0g bm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBTeXN0ZW0iPkZyb206PC9TUEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8U1BBTiBjbGFzcz1TcGVs bEU+SHVpPC9TUEFOPiBEZW5nIFttYWlsdG86PEEgaHJlZj0ibWFpbHRvOmRlbmdodWkwMkBnbWFp bC5jb20iIHRhcmdldD1fYmxhbms+ZGVuZ2h1aTAyQGdtYWlsLmNvbTwvQT5dIDxCUj48Qj5TZW50 OjwvQj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE0LCAyMDA5IDc6MjAgQU08QlI+PEI+VG86PC9CPiA8 L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ 7ZmN7Jqp6re8PFNQQU4gbGFuZz1FTi1VUz48QlI+PEI+Q2M6PC9CPiA8QSBocmVmPSJtYWlsdG86 bWlmQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1pZkBpZXRmLm9yZzwvQT48QlI+PEI+U3ViamVj dDo8L0I+IFJlOiBbbWlmXSBtb2JpbGl0eSBpc3N1ZXMgYW5kIGdlbmVyYWwgaXNzdWVzIG9uIG1p ZjxvOnA+PC9vOnA+PC9TUEFOPjwvU1BBTj48L1A+PC9ESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5IaSwgSG9uZyBZb25nLDxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+DQo8RElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SSByZWFkIHRocm91Z2ggeW91ciB0d28g ZHJhZnRzLCB1bmRlcnN0YW5kIHlvdSBhcmUgdGFsa2luZyB0aGUgaXNzdWU8L1NQQU4+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6 IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3Rl bSI+d2l0aG91dCBNb25hbWk8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8UCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDIxLjc1cHQ7IFRFWFQtSU5ERU5UOiAtMThwdCI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFdp bmdkaW5nczsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+PzwvU1BBTj48U1BBTiBj bGFzcz1HcmFtRT48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDdwdDsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDsgPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPlllczwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+LCB5b3UgYXJlIGNvcnJl Y3QuIDxCUj5JIHdhbnQgdG8gc29sdmUgdGhlIG11bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyB3 aXRob3V0IG1vZGlmeWluZyBNb2JpbGUgSVB2Ni9ORU1PIGNvZGUuPEJSPihJbiBNb25hbWk2LCBt dWx0aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgKHdoaWNoPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZh bWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQ QU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+YXJlIHJlbGF0ZWQgdG8gbW9iaWxpdHkgaXNzdWVzLCBz dWNoIGFzIG11bHRpcGxlIDxTUEFOIGNsYXNzPVNwZWxsRT5Db0E8L1NQQU4+LDxCUj48U1BBTiBj bGFzcz1HcmFtRT5tdWx0aXBsZTwvU1BBTj4gPFNQQU4gY2xhc3M9U3BlbGxFPkhvQTwvU1BBTj4s IGV0Yy4sICkgYXJlIHJlc29sdmluZyBieSBtb2RpZnlpbmcgTW9iaWxlIElQdjYvTkVNTyBwcm90 b2NvbCk8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFA+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48 QlI+PFNQQU4gY2xhc3M9R3JhbUU+aXQ8L1NQQU4+IHNlZW1zIE1vYmlsZSBJcHY2IGludGVybmFs IGFsc28gaGFzIHNpbWlsYXIgaXNzdWUgd2l0aCB1cyBpZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVj dGx5LCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6 IDIxLjc1cHQ7IFRFWFQtSU5ERU5UOiAtMThwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5nczsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+PzwvU1BBTj48U1BBTiBjbGFzcz1HcmFtRT48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDdwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBtc28tZmFyZWFzdC1mb250LWZh bWlseTogU3lzdGVtIj4mbmJzcDsgPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPlllczwvU1BB Tj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+LCBiZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJh c2VkIG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2NiwgTW9iaWxlIElQdjYgaW50ZXJuYWw8 QlI+PFNQQU4gY2xhc3M9R3JhbUU+aGFzPC9TUEFOPiBzaW1pbGFyIGlzc3VlcyBvZiBtaWYuIFNv LCBJIHRoaW5rIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8gc2VwYXJhdGUgbW9yZSBnZW5lcmFsIGlz c3VlcyBmcm9tPEJSPjxTUEFOIGNsYXNzPUdyYW1FPm11bHRpcGxlPC9TUEFOPiBpbnRlcmZhY2Ug aXNzdWVzIHdoaWNoIGFyZSBkaXJlY3RseSByZWxhdGVkIHRvIE1vYmlsZSBJUHY2L05FTU8uPC9T UEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5J biB0aGlzIGNhc2UgSSB3b3VsZCBsaWtlIHRvIGVuY291cmFnZSB5b3UgdG8gcHJvcG9zZSB0aGlz IGlzc3VlIHRvIG91ciB3b3JrLCBpZiBhbGxvd2VkLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj48L0RJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gY2xhc3M9R3JhbUU+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5pdDwvU1BB Tj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogU3lzdGVtIj4gPFNQQU4gY2xhc3M9U3BlbGxFPm1pZ2h0YmU8L1NQQU4+IGRvYWJsZSB3 aXRoaW4gb3VyIHNjb3BlLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxQIHN0eWxlPSJN QVJHSU4tTEVGVDogMjEuNzVwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogV2lu Z2RpbmdzOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4/PC9TUEFOPjxTUEFOIGNs YXNzPUdyYW1FPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogN3B0OyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOyA8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3Rl bSI+VGhhbmtzPC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVtIj4uIEl0IGlzIG15IHBs ZWFzdXJlPFNQQU4gY2xhc3M9R3JhbUU+Li48L1NQQU4+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48 L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQPjxTUEFOIGNsYXNzPUdyYW1FPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ bWFueTwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogU3lzdGVtIj4gdGhhbmtzPG86cD48L286cD48L1NQQU4+PC9QPjwvRElW Pg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0 ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+ DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBTeXN0ZW0iPi08U1BBTiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjIwMDkvMS83IEhvbmcgWW9uZy1HZXVuICZsdDs8 QSBocmVmPSJtYWlsdG86eWdob25nQGV0cmkucmUua3IiIHRhcmdldD1fYmxhbms+eWdob25nQGV0 cmkucmUua3I8L0E+Jmd0OzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0KPERJ Vj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IFN5c3RlbSI+SGkuIDxTUEFOIGNsYXNzPUdyYW1FPm1pZjwvU1BBTj4uLjxCUj48QlI+TGV0 IG1lIGpvaW4gdGhpcyBkaXNjdXNzaW9uLjxCUj48QlI+SXQgaXMgdmVyeSBpbnRlcmVzdGluZyB0 byBzZWUgbWlmLjxCUj48QlI+QXMgPFNQQU4gY2xhc3M9U3BlbGxFPkh1aTwvU1BBTj4gRGVuZyBz YXlzLCBJIHVuZGVyc3RhbmQgdGhhdCBtaWYgaGFzIGRpZmZlcmVudCBhcHByb2FjaDxCUj48U1BB TiBjbGFzcz1HcmFtRT5mcm9tPC9TUEFOPiBvdGhlciBXRyBzdWNoIGFzIE1FWFQgYW5kIG1vbmFt aTYgV0csIGV0Yy48QlI+PEJSPkluIE1FWFQsIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGFy ZSByZWxhdGVkIHRvIE1vYmlsZSBJUCwgPFNQQU4gY2xhc3M9R3JhbUU+TkVNTywuLjwvU1BBTj48 QlI+SW4gbWlmLCBtdWx0aXBsZSBpbnRlcmZhY2VzIGlzc3VlcyBhcmUgZGlmZmVyZW50IGZyb20g dGhvc2Ugb2YgTUVYVC48QlI+U28sIGluIG1pZiwgaXQgaXMgYmV0dGVyIHRvIGZpbmQgbW9yZSBn ZW5lcmFsIGlzc3VlcyB3aGljaCBhcmUgbm90IHJlbGF0ZWQgdG8gTW9iaWxlIElQLjxCUj48QlI+ SSB0aGluayB0aGF0IDxTUEFOIGNsYXNzPVNwZWxsRT5NLkJsYW5jaGV0J3M8L1NQQU4+ICJNdWx0 aXBsZSBJbnRlcmZhY2VzIFByb2JsZW0gU3RhdGVtZW50IiBkcmFmdCBpczxCUj48U1BBTiBjbGFz cz1HcmFtRT5hPC9TUEFOPiBnb29kIHN0YXJ0aW5nIHBvaW50IHRvIGRpc2N1c3MgZ2VuZXJhbCBp c3N1ZXMgb24gbWlmLjxCUj48QlI+SSB3b3VsZCBsaWtlIHRvIGludHJvZHVjZSA8U1BBTiBjbGFz cz1HcmFtRT5hbm90aGVyIHJlbGF0ZWQgZHJhZnRzPC9TUEFOPiB3aGljaCBJIHByZXNlbnRlZCBh dCBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nLjxCUj48QlI+PC9TUEFOPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBT eXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0i Pi0gQW5hbHlzaXMgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSA8U1BBTiBjbGFz cz1HcmFtRT5Ob2RlKDwvU1BBTj5kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50 LTAwKTxCUj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBt c28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5 c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IDxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9k cmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVs dGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50L2Ry YWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0PC9BPjxCUj48QlI+PC9T UEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZv bnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNw OzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPi0gVmlydHVhbCBuZXR3b3JrIGludGVyZmFjZSBmb3IgbXVsdGlwbGUgaW50 ZXJmYWNlcyBpbiBhIE1vYmlsZSBub2RlIHVzaW5nIE1vYmlsZSBJUHY2PEJSPjwvU1BBTj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWls eTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDsmbmJzcDs8 L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogU3lzdGVtIj4gKDxTUEFOIGNsYXNzPUdyYW1FPmRyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1p cHY2LTAwPC9TUEFOPik8QlI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiA8QSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvZHJhZnQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYvZHJhZnQtaG9uZy12 aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9kcmFmdC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZpcnR1 YWxpZi1tbi1taXB2Ni0wMC50eHQ8L0E+PEJSPjxCUj48QlI+SW4gdGhlIHNlY3Rpb24gMi4yIChH ZW5lcmFsIE5ldHdvcmsgSXNzdWVzKSBpbiB0aGUgZmlyc3QgZHJhZnQsPEJSPjxTUEFOIGNsYXNz PUdyYW1FPnRoZXJlPC9TUEFOPiBhcmUgZ2VuZXJhbCBuZXR3b3JrIGlzc3VlcyBkdWUgdG8gbXVs dGlwbGUgaW50ZXJmYWNlcy48QlI+PEJSPkluY2x1ZGluZyB0aGVzZSBkcmFmdHMsIEkgaG9wZSB0 byBlbmNvdXJhZ2UgdGhpcyBkaXNjdXNzaW9uPEJSPjxCUj48U1BBTiBjbGFzcz1HcmFtRT5Zb25n LUdldW4uPC9TUEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj4NCjxQ IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxCUj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj48U1BBTiBjbGFzcz1HcmFtRT5taWY8L1NQ QU4+IG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9 X2JsYW5rPm1pZkBpZXRmLm9yZzwvQT48QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9taWYiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9taWY8L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFA+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1m YW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9T UEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwv RElWPjwvRElWPjwvRElWPjwvRElWPg0KPFA+PEI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+7Jik66WYPFNQQU4gbGFuZz1FTi1VUz4hIDwvU1BBTj7t jIzsnbwg7J2066aE7J20IOyngOygleuQmOyWtCDsnojsp4Ag7JWK7Iq164uI64ukPFNQQU4gbGFu Zz1FTi1VUz4uPC9TUEFOPjwvU1BBTj48L0I+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2Np aS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4m bmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+ PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+7Jik66WYPFNQQU4gbGFuZz1FTi1VUz4hIDwv U1BBTj7tjIzsnbwg7J2066aE7J20IOyngOygleuQmOyWtCDsnojsp4Ag7JWK7Iq164uI64ukPFNQ QU4gbGFuZz1FTi1VUz4uPC9TUEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD48L0RJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+ Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48aW1n IHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwu ZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1taWZAaWV0Zi5vcmcmbmFt ZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25nQGV0cmkucmUua3ImbWVzc2FnZWlkPSUz Q2MyOGU0MDMyLTM1ZWUtNDk1MS1hMDQyLTlhZmU0ZDJiMTk0MUBldHJpLnJlLmtyJTNFIj4= ------_=_NextPart_001_01C97A45.25D72A80-- --===============2019927727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2019927727==-- From mif-bounces@ietf.org Tue Jan 20 00:47:49 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893B73A6A77; Tue, 20 Jan 2009 00:47:49 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43C13A6A61 for ; Tue, 20 Jan 2009 00:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghJvFD9-DC3w for ; Tue, 20 Jan 2009 00:47:47 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 4C6F73A6A41 for ; Tue, 20 Jan 2009 00:47:47 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 09:47:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 09:47:27 +0100 Message-ID: In-Reply-To: <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif Thread-Index: Acl6Q8ibRiXxH/BCSga2YobeS7Vj+AAl5Fkg References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com><4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com><1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com><3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> From: To: , X-OriginalArrivalTime: 20 Jan 2009 08:47:28.0597 (UTC) FILETIME=[B9892850:01C97ADB] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi all, I've joined recently this ML and I believe discussed topics very interestin= g (BTW thanks to MIF promoters for bringing these issues to IETF). So, plea= se let me jump into your discussion. = Regarding difference between MIF and multihoming: it seems there is confusi= on with mobility. AFAIU, MIF is only supposed to deal with routing issue at= the multi-interface MN side. The issue is to select the "best" interface f= or each outgoing IP flow and, in MIF context, access selection does not nec= essarily imply flow mobility with IP session continuity between interfaces.= Nevertheless, solution should work for terminal with several active interf= aces at the same time (multi-homed), or for terminal with a single interfac= e at a time. Am I correct? = Regarding ANDSF issue, I agree with preceding emails: I think access select= ion should rely on policy. There are a couple of selection models but the s= implest is the selection managed by the terminal and based on local policie= s and measurement on the access link. The policies may be provided/updated = by a server via out-of-band mechanism or on-demand (typically before select= ion) if policies include "dynamic" recommendation (e.g. access xx is overlo= ad and forbidden to application type yy). Now you can call the policy serve= r ANDSF, or whatever you want, it is just a generic functional entity in th= e architecture and this entity is above all access networks. Note the acces= s selection via policy server meet MIF requirement as well as selection in = inter-access mobility situation. Please do not hesitate to correct me if I misunderstood MIF issues. Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de P= eny > Yang > Envoy=E9=A0: lundi 19 janvier 2009 15:10 > =C0=A0: Kai Ju > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] mobility issues and general issues on mif > = > Hi, Kai: > > The ANSDF solution is just a sample, because there is no one type of > server > > which is > > defined to provide the policy in IETF until now. So let us consider it > be > > general, which > > means it's one policy server that provides the routing policy to UE when > UE > > is connecting > > it. > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the > MIF solutions. > = > BRG > Peny > = > = > = > >> > >> Hi, Peng and Kai, > >> > >> See reply inline below. thanks for the discussion. > >> 2009/1/19 Peny Yang > >>> > >>> Hi, Kai: > >>> Nice point. Please check the lines below: > >>> > >>> > As you said, there are multiple way to assign the routing policy by > in > >>> > the > >>> > mobile access network. As viewed from the aspect of terminal, I > think > >>> > its a > >>> > good idea that terminal can get its routing policy from the ANDSF. > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows the > >>> assumption of generic "one default link" IP model. So, in 3GPP, even > >>> though ANDSF can help UE to select accesses and find the route, UE can > >>> only choose one of the interfaces as a result. > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, > >>> since it's a specific definition in one SDO. > >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work > for > >> 23.402 for non-3GPP access still a issue, it may need some mechanism to > >> coordinate > >> between two type of access entwork.what do you think? > >> > >>> > >>> > We think a default policy can be used, when terminal can't find > >>> > corresponding policy in the routing policy from the ANDSF. The > default > >>> > policy can be sent by the network. > >>> [Peny] Could we give a chance to MN to change the policy (like user > >>> preference) ? > >>> > >>> > On another hand, I am a little confused between MIF and Multihoming, > >>> > would > >>> > you please help me to clarify the difference between them? > >>> [Peny] I am also not clear yet. Just give some lines as a seed for > >>> discussion. In my personal feeling, MIF is to change the "one default > >>> link" feature of current generic IP model. Multi-homing is to ensure > >>> the reachability and reliability of IP network. Well, in multi-homing > >>> MN scenarios, multi-link-multi-address is also one case. But, in this > >>> case, MN only can choose one link as default. > >>> Some other comments? > >> > >> To challenge one default link, it really takes time for mif to consider > on > >> it, current first step in mif is to consider some straight forward way > which > >> is simple to resolve some issues. > >> Regarding to multi-homing, I guess that it is more site multi-homing. > >> For last multi-link-multi-address mn's scenario, it will be one of MIF > >> scenario. > >> > >> thanks > >> > >> -Hui > >> > >>> > >>> BRG > >>> Peny > >> > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Tue Jan 20 01:33:14 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02833A6B21; Tue, 20 Jan 2009 01:33:14 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6FC28C0DD for ; Tue, 20 Jan 2009 01:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNDHEan8+YjF for ; Tue, 20 Jan 2009 01:33:13 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id EA8143A6B21 for ; Tue, 20 Jan 2009 01:33:11 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 10:32:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 10:32:53 +0100 Message-ID: In-Reply-To: <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] How to identify a host with multiple interfaces Thread-Index: Acl6CZ5hFOcopHXdSGKufcAUTgo1TQA0ibBw References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> From: To: , X-OriginalArrivalTime: 20 Jan 2009 09:32:54.0844 (UTC) FILETIME=[12816FC0:01C97AE2] Cc: mif@ietf.org Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746220378==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0746220378== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97AE2.1234B2E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97AE2.1234B2E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The issue is out of MIF scope but, anyway, I'd like to bring few = comments: =20 Host A does not have to know anything about host B. If host the current = interface of B goes down, the onus of selecting a new interface is on = host B and not on host A. Then if host B is changing the interface, host = B may steer a mobility protocol to maintain IP session continuity (there = are a couple of protocol for that and it is out of MIF scope) but it is = not host A which maintain session continuity on host B. =20 Regards, Pierrick =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : lundi 19 janvier 2009 08:42 =C0 : teemu.savolainen@nokia.com Cc : mif@ietf.org Objet : Re: [mif] How to identify a host with multiple interfaces =20 Hi, Teemu =20 I agree your point here, fallback and movement to use another interface = for the same session will be not in the mif scope. =20 -Hui 2009/1/19 Hi, =20 In my opinion the fallback (or movement) to use another interface of B = for the same session is not in mif scope, but it is more works for = shim6/hip/etc, right? Or even at application level to reconnect to = different address of B after one fails (the list of addresses = application learns e.g. from DNS). =20 Best regards, =20 Teemu =20 =09 ________________________________ From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = ext shshrosh Sent: 18 January, 2009 08:05 To: mif Subject: [mif] How to identify a host with multiple interfaces Hello, all =20 I have a problem about multiple interface. Suppose host A communicates = with host B, which has multiple interfaces. When one interface of B = fails, A may switch to the address of another interface of B to maintain = the communication. But how can A know the two addresses corresponde to = the same host B? _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =20 ------_=_NextPart_001_01C97AE2.1234B2E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

The issue is out of MIF scope but, anyway, I'd like to bring few = comments:

 

Host A does not have to know anything about host B. If host the current = interface of B goes down, the onus of selecting a new interface is on host B and not = on host A. Then if host B is changing the interface, host B may steer a mobility protocol to maintain IP session continuity (there are a couple of = protocol for that and it is out of MIF scope) but it is not host A which maintain = session continuity on host B.

 

Regards,

Pierrick

 

De : = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la = part de Hui Deng
Envoy=E9 : lundi 19 = janvier 2009 08:42
=C0 : teemu.savolainen@nokia.com
Cc : = mif@ietf.org
Objet : Re: [mif] = How to identify a host with multiple interfaces

 

Hi, Teemu

 

I agree your point here, fallback and movement to use = another interface for the same session will be not in the mif = scope.

 

-Hui

2009/1/19 <teemu.savolainen@nokia.com= >

Hi,

 

In my opinion the fallback (or movement) to use = another interface of B for the same session is not in mif scope, but it is more = works for shim6/hip/etc, right? Or even at application level to reconnect to different address of B after one fails (the list of addresses = application learns e.g. from DNS).

 

Best regards,

 

    = Teemu

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext = shshrosh
Sent: 18 January, 2009 = 08:05
To: mif
Subject: [mif] How to = identify a host with multiple interfaces

Hello, all

 

I have a problem about = multiple interface. Suppose host A communicates with host B, which has multiple interfaces. When one interface of B fails, A may switch to the address = of another interface of B to maintain the communication. But how can A = know the two addresses corresponde to the same host = B?


_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

 

------_=_NextPart_001_01C97AE2.1234B2E5-- --===============0746220378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0746220378==-- From mif-bounces@ietf.org Wed Jan 21 07:07:23 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CDC28C0EC; Wed, 21 Jan 2009 07:07:23 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25713A6973 for ; Wed, 21 Jan 2009 07:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+mhZFI5eD+S for ; Wed, 21 Jan 2009 07:07:20 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id A2A293A6B4C for ; Wed, 21 Jan 2009 07:07:20 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 26so4246322wfd.1 for ; Wed, 21 Jan 2009 07:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D4jnrsg0DXENxBHBaYNeolC7MstfWVTjWjRK9zb8Bmc=; b=qnwsr3ASHEV8HKw7BjvWw1/vQAFHyqaApY1NZfVnwI2iz/ZEEAvBQwyWv1j9xGzSDG MNsEHXtXHLo6l4gjgHpTCPBE6HFO+Y/++iGqCLpiDUiwmp+Y9MNFfpaveyv6ygHfWhBD upA45aHBQsCjfuxmxRzjeFrrWaysJg2xjjVV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A2FZ+nJPBB8pZKFfUb01FyoyVhRrIeXiDCNBECFz/qE7QLYfC6nYelgUVQBxkZMiew ubCTCsWXXAIfvPWcgLG6o6fo9DCN+fFW3mdlkAzljU6sKniTO84P+SYTdPXqP78ia5lM /WojcMDqxuJWi37KY2v6zWVGwZng3g35a4jq0= MIME-Version: 1.0 Received: by 10.114.148.2 with SMTP id v2mr5777592wad.169.1232550424390; Wed, 21 Jan 2009 07:07:04 -0800 (PST) In-Reply-To: <200901191706482187921@gmail.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> Date: Wed, 21 Jan 2009 23:07:04 +0800 Message-ID: <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> From: Hui Deng To: shshrosh Cc: mif Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1485859495==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1485859495== Content-Type: multipart/alternative; boundary=0016e64f809036ae8b0460ff8201 --0016e64f809036ae8b0460ff8201 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I am not clear about your proposal here, can you write down some draft about what you think? then we can discuss detail here, thanks -Hui 2009/1/19 shshrosh > Hi, Hui Deng, > > My main problem is not on the movement and fallback. My main point is the > identification of a node with mulitple interface. So if other nodes get t= he > identification, they know the interfaces corresponde to the same node. > > ------------------------------ > *=B7=A2=BC=FE=C8=CB=A3=BA* Hui Deng > *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2009-01-19 15:42:23 > *=CA=D5=BC=FE=C8=CB=A3=BA* teemu.savolainen > *=B3=AD=CB=CD=A3=BA* shshrosh; mif > *=D6=F7=CC=E2=A3=BA* Re: [mif] How to identify a host with multiple inter= faces > Hi, Teemu > > I agree your point here, fallback and movement to use another interface f= or > the same session will be not in the mif scope. > > -Hui > > 2009/1/19 > >> Hi, >> >> In my opinion the fallback (or movement) to use another interface of B f= or >> the same session is not in mif scope, but it is more works for >> shim6/hip/etc, right? Or even at application level to reconnect to diffe= rent >> address of B after one fails (the list of addresses application learns e= .g. >> from DNS). >> >> Best regards, >> >> Teemu >> >> ------------------------------ >> *From:* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *On Behalf Of >> *ext shshrosh >> *Sent:* 18 January, 2009 08:05 >> *To:* mif >> *Subject:* [mif] How to identify a host with multiple interfaces >> >> Hello, all >> >> I have a problem about multiple interface. Suppose host A communicates >> with host B, which has multiple interfaces. When one interface of B fail= s, A >> may switch to the address of another interface of B to maintain the >> communication. But how can A know the two addresses corresponde to the s= ame >> host B? >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --0016e64f809036ae8b0460ff8201 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I am not clear about your proposal here,
can you write down some draft about what you think?
then we can discuss detail here,
 
thanks
 
-Hui

2009/1/19 shshrosh <shshrosh@gmail.com>
Hi, Hui Deng,
 
My main problem is not on the movement and fal= lback. My main point is the identification of a node with mulitple interfac= e. So if other nodes get the identification, they know the interfaces = corresponde to the same node.
 
=B7=A2=BC=FE=C8=CB=A3=BA Hui Deng
=B7=A2=CB=CD=CA=B1=BC=E4=A3= =BA 2009-01-19  15:42:23
=CA=D5=BC=FE=C8=CB=A3=BA teemu.savolainen
=B3=AD=CB=CD=A3=BA = shshrosh; mif
=D6=F7=CC=E2=A3=BA = Re: [mif] How to identify a host with multiple interfaces
Hi, Teemu
 
I agree your point here, fallback and movement to use another int= erface for the same session will be not in the mif scope.
 
-Hui

2009/1/19 <teemu.savolainen@nokia.com<= /a>>
Hi,
=  
In my opinion = the fallback (or movement) to use another interface of B for the same sessi= on is not in mif scope, but it is more works for shim6/hip/etc, right? Or e= ven at application level to reconnect to different address of B after one f= ails (the list of addresses application learns e.g. from DNS).
=  
Best regards,<= /font>
=  
    Teemu

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of= ext shshrosh
Sent: 18 January, 2009 08:05
To: mif
Subject: [m= if] How to identify a host with multiple interfaces

Hello, all
 
I have a problem about multiple interface. = Suppose host A communicates with host B, which has multiple interfaces. Whe= n one interface of B fails, A may switch to the address of another interfac= e of B to maintain the communication. But how can A know the two addre= sses corresponde to the same host B?

___= ____________________________________________
mif mailing list
mif@ietf.org
https://www.iet= f.org/mailman/listinfo/mif



--0016e64f809036ae8b0460ff8201-- --===============1485859495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1485859495==-- From mif-bounces@ietf.org Wed Jan 21 07:09:35 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B132A28C145; Wed, 21 Jan 2009 07:09:35 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C57D28C145 for ; Wed, 21 Jan 2009 07:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu+1pl1yZ4Zf for ; Wed, 21 Jan 2009 07:09:34 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 6E5EC28C134 for ; Wed, 21 Jan 2009 07:09:34 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4312885wfd.31 for ; Wed, 21 Jan 2009 07:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vScyfnQEU8Ja8f8zr/CiNnTliBCdl8tg5Jve9+ibgRo=; b=iWLHvLx8+Jv216jtqtmtULyncg4ahoUd2PRexjkWrgL6ioGJYH2ICnafcsa84J5wuE ia1ZSbK/+s5fGIZa/SDic8dmILfoXbic/pqlzojchWbbDE6FR0iKHuhkDLD6tfFziuPE gg074OPtMoElB+5tF+3IVkZ5ZWnuQOPa97by0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HAlQmHFi9mn3yTD1piXvrFEzxkYJ0x7dU1u6sXHGt+SavA0Oi6CX0mug6BqVKuHhXN b3TWFswJjwos0q+tTUg0E2f50novlWF8lvgHMc0lWtrmE2NrBqRWYoMtXOjt1IykkFvH lNl9EBFTWZYao25iy4LKVf4DzlA2yt9ADb+HU= MIME-Version: 1.0 Received: by 10.115.73.20 with SMTP id a20mr52733wal.1.1232550557512; Wed, 21 Jan 2009 07:09:17 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> Date: Wed, 21 Jan 2009 23:09:17 +0800 Message-ID: <1d38a3350901210709r2c6dbe2fl4e6b24ea1d1e0c01@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] How to identify a host with multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0956646903==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0956646903== Content-Type: multipart/alternative; boundary=00163646c5a825f4a20460ff8a0c --00163646c5a825f4a20460ff8a0c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes, Pierrick made the point here, but some mobile implementation does has some connection between connection manager and mobility manager, but I don't know whether there is anybody wh= o would like to propose those in mif list here. thanks -Hui 2009/1/20 > Hello, > > > > The issue is out of MIF scope but, anyway, I'd like to bring few comments= : > > > > Host A does not have to know anything about host B. If host the current > interface of B goes down, the onus of selecting a new interface is on hos= t B > and not on host A. Then if host B is changing the interface, host B may > steer a mobility protocol to maintain IP session continuity (there are a > couple of protocol for that and it is out of MIF scope) but it is not hos= t A > which maintain session continuity on host B. > > > > Regards, > > Pierrick > > > ------------------------------ > > *De :* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *De la part de*= Hui Deng > *Envoy=E9 :* lundi 19 janvier 2009 08:42 > *=C0 :* teemu.savolainen@nokia.com > *Cc :* mif@ietf.org > *Objet :* Re: [mif] How to identify a host with multiple interfaces > > > > Hi, Teemu > > > > I agree your point here, fallback and movement to use another interface f= or > the same session will be not in the mif scope. > > > > -Hui > > 2009/1/19 > > Hi, > > > > In my opinion the fallback (or movement) to use another interface of B fo= r > the same session is not in mif scope, but it is more works for > shim6/hip/etc, right? Or even at application level to reconnect to differ= ent > address of B after one fails (the list of addresses application learns e.= g. > from DNS). > > > > Best regards, > > > > Teemu > > > ------------------------------ > > *From:* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *On Behalf Of = *ext > shshrosh > *Sent:* 18 January, 2009 08:05 > *To:* mif > *Subject:* [mif] How to identify a host with multiple interfaces > > Hello, all > > > > I have a problem about multiple interface. Suppose host A communicates wi= th > host B, which has multiple interfaces. When one interface of B fails, A m= ay > switch to the address of another interface of B to maintain the > communication. But how can A know the two addresses corresponde to the sa= me > host B? > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > --00163646c5a825f4a20460ff8a0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
yes, Pierrick made the point here,
 
but some mobile implementation does has some connection between connec= tion manager and mobility manager, but I don't know whether there = is anybody  who would like to propose those in mif list here.
 
thanks
 
-Hui

2009/1/20 <pierrick.seite@orange-ftgroup.com&= gt;

Hello,

 

The issue is out of = MIF scope but, anyway, I'd like to bring few comments:

 =

Host A does not have= to know anything about host B. If host the current interface of B goes dow= n, the onus of selecting a new interface is on host B and not on host A. Th= en if host B is changing the interface, host B may steer a mobility protoco= l to maintain IP session continuity (there are a couple of protocol for tha= t and it is out of MIF scope) but it is not host A which maintain session c= ontinuity on host B.

 =

Regards,

Pierrick

 =

De : mif-bounces@iet= f.org [mailto:mif-bounces@ietf.org] De la part = de Hui Deng
Envoy=E9 : lundi 19 ja= nvier 2009 08:42
=C0 :<= /b> teemu.s= avolainen@nokia.com
Cc : mif@ietf.org
Objet : Re: [mif] How to identify a host wit= h multiple interfaces

= -Hui

teemu.savolainen@nokia.com>

Hi,

 

In my opinion the fallback (or movement) to use another int= erface of B for the same session is not in mif scope, but it is more works = for shim6/hip/etc, right? Or even at application level to reconnect to diff= erent address of B after one fails (the list of addresses application learn= s e.g. from DNS).

 

Best regards,

 

    Teemu

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org= ] On Behalf Of ext shsh= rosh
Sent: 18 January, 2009 08:0= 5
To: mif
Subject: [mif] How to identify a host = with multiple interfaces

Hello, all

 

I have a problem about multiple= interface. Suppose host A communicates with host B, which has multiple int= erfaces. When one interface of B fails, A may switch to the address of anot= her interface of B to maintain the communication. But how can A know t= he two addresses corresponde to the same host B?

=
_______________________________________= ________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A10128C127; Wed, 21 Jan 2009 07:24:06 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3796C28C0E5 for ; Wed, 21 Jan 2009 07:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM50oTag+vxg for ; Wed, 21 Jan 2009 07:24:03 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id CE56A28C127 for ; Wed, 21 Jan 2009 07:24:03 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so2175085wag.5 for ; Wed, 21 Jan 2009 07:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Nm3i5KIVlG9ImlzSzS/DwMPaI+W8m5enajM3A79UfiY=; b=HtjcIgJr5U0nxx40cjqAkEOs3xeIBQtiiMCsVZ3VScrycmIrmRK/R4S33p+1bKfKdz VxDdzNZaYEZR9+EOUvNO7mZ6J+W20TuuJweBIM/EgOX9o4rXr0VglO7ZrbhtOg5MvJlR nZ2mCs+92Y4B9ah/DHE7NfXuNLbN0rRSheRds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lIzeElmAGSV6/hL+DrRD3DAyZ4DvPJfehAlA6693B5Kvmfe6AlXgt4tDgejRWox06I Qra8oeiSToUOBUFiqYySoqoIXwhGL1THhjf+LfueYIZeCOUmy1GWo/Evz4V2hLq/P+a6 fQufAn1MMVDIUqnhsoV1V82vLHyFPsFAOY1Q4= MIME-Version: 1.0 Received: by 10.114.72.1 with SMTP id u1mr773220waa.39.1232551426919; Wed, 21 Jan 2009 07:23:46 -0800 (PST) In-Reply-To: References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> Date: Wed, 21 Jan 2009 23:23:46 +0800 Message-ID: <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176531338==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1176531338== Content-Type: multipart/alternative; boundary=001636417c17f80c720460ffbdbf --001636417c17f80c720460ffbdbf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, pierrick, Thanks for joining the disucssion, speaking for mobile operator is quite helpful for mif's work, Your experience is appreicate, see reply inline below, 2009/1/20 > Hi all, > > I've joined recently this ML and I believe discussed topics very > interesting (BTW thanks to MIF promoters for bringing these issues to IET= F). > So, please let me jump into your discussion. Thanks again. > > Regarding difference between MIF and multihoming: it seems there is > confusion with mobility. AFAIU, MIF is only supposed to deal with routing > issue at the multi-interface MN side. The issue is to select the "best" > interface for each outgoing IP flow and, in MIF context, access selection > does not necessarily imply flow mobility with IP session continuity betwe= en > interfaces. Nevertheless, solution should work for terminal with several > active interfaces at the same time (multi-homed), or for terminal with a > single interface at a time. Am I correct? As you said here, flow mobility and IP session continuity is out of scope a= t the moment. I cann't agree with any more about your left words. > > > Regarding ANDSF issue, I agree with preceding emails: I think access > selection should rely on policy. There are a couple of selection models b= ut > the simplest is the selection managed by the terminal and based on local > policies and measurement on the access link. The policies may be > provided/updated by a server via out-of-band mechanism or on-demand > (typically before selection) if policies include "dynamic" recommendation > (e.g. access xx is overload and forbidden to application type yy). Now yo= u > can call the policy server ANDSF, or whatever you want, it is just a gene= ric > functional entity in the architecture and this entity is above all access > networks. Note the access selection via policy server meet MIF requiremen= t > as well as selection in inter-access mobility situation. Most mobile terminal has implemented the policy based selection models. Howver I would like to raise one case, sometime, if the network congested, terminal couldn't visit policy server such as ANDSF, only network side know what happen, they may re-arrange some traffic for mobile terminal, I guess that this is been discussed in 3GPP SA2 side at the moment. > > > Please do not hesitate to correct me if I misunderstood MIF issues. thanks for the discussion. -Hui > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Peny > > Yang > > Envoy=E9 : lundi 19 janvier 2009 15:10 > > =C0 : Kai Ju > > Cc : mif@ietf.org > > Objet : Re: [mif] mobility issues and general issues on mif > > > > Hi, Kai: > > > The ANSDF solution is just a sample, because there is no one type of > > server > > > which is > > > defined to provide the policy in IETF until now. So let us consider i= t > > be > > > general, which > > > means it's one policy server that provides the routing policy to UE > when > > UE > > > is connecting > > > it. > > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the > > MIF solutions. > > > > BRG > > Peny > > > > > > > > >> > > >> Hi, Peng and Kai, > > >> > > >> See reply inline below. thanks for the discussion. > > >> 2009/1/19 Peny Yang > > >>> > > >>> Hi, Kai: > > >>> Nice point. Please check the lines below: > > >>> > > >>> > As you said, there are multiple way to assign the routing policy = by > > in > > >>> > the > > >>> > mobile access network. As viewed from the aspect of terminal, I > > think > > >>> > its a > > >>> > good idea that terminal can get its routing policy from the ANDSF= . > > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows the > > >>> assumption of generic "one default link" IP model. So, in 3GPP, eve= n > > >>> though ANDSF can help UE to select accesses and find the route, UE > can > > >>> only choose one of the interfaces as a result. > > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of 3GP= P, > > >>> since it's a specific definition in one SDO. > > >> > > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF wor= k > > for > > >> 23.402 for non-3GPP access still a issue, it may need some mechanism > to > > >> coordinate > > >> between two type of access entwork.what do you think? > > >> > > >>> > > >>> > We think a default policy can be used, when terminal can't find > > >>> > corresponding policy in the routing policy from the ANDSF. The > > default > > >>> > policy can be sent by the network. > > >>> [Peny] Could we give a chance to MN to change the policy (like user > > >>> preference) ? > > >>> > > >>> > On another hand, I am a little confused between MIF and > Multihoming, > > >>> > would > > >>> > you please help me to clarify the difference between them? > > >>> [Peny] I am also not clear yet. Just give some lines as a seed for > > >>> discussion. In my personal feeling, MIF is to change the "one defau= lt > > >>> link" feature of current generic IP model. Multi-homing is to ensur= e > > >>> the reachability and reliability of IP network. Well, in multi-homi= ng > > >>> MN scenarios, multi-link-multi-address is also one case. But, in th= is > > >>> case, MN only can choose one link as default. > > >>> Some other comments? > > >> > > >> To challenge one default link, it really takes time for mif to > consider > > on > > >> it, current first step in mif is to consider some straight forward w= ay > > which > > >> is simple to resolve some issues. > > >> Regarding to multi-homing, I guess that it is more site multi-homing= . > > >> For last multi-link-multi-address mn's scenario, it will be one of M= IF > > >> scenario. > > >> > > >> thanks > > >> > > >> -Hui > > >> > > >>> > > >>> BRG > > >>> Peny > > >> > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --001636417c17f80c720460ffbdbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile operator is qui= te helpful for mif's work,
Your experience is appreicate, see reply inline below,
2009/1/20 <pierrick.seite@orange-ftgroup.com&= gt;
Hi all,

I've joined r= ecently this ML and I believe discussed topics very interesting (BTW thanks= to MIF promoters for bringing these issues to IETF). So, please let me jum= p into your discussion.
Thanks again.
 

Regarding difference between= MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF= is only supposed to deal with routing issue at the multi-interface MN side= . The issue is to select the "best" interface for each outgoing I= P flow and, in MIF context, access selection does not necessarily imply flo= w mobility with IP session continuity between interfaces. Nevertheless, sol= ution should work for terminal with several active interfaces at the same t= ime (multi-homed), or for terminal with a single interface at a time. Am I = correct?
As you said here, flow mobility and IP session continuity is out = of scope at the moment.
I cann't agree with any more about your left words.
 


Reg= arding ANDSF issue, I agree with preceding emails: I think access selection= should rely on policy. There are a couple of selection models but the simp= lest is the selection managed by the terminal and based on local policies a= nd measurement on the access link. The policies may be provided/updated by = a server via out-of-band mechanism or on-demand (typically before selection= ) if policies include "dynamic" recommendation (e.g. access xx is= overload and forbidden to application type yy). Now you can call the polic= y server ANDSF, or whatever you want, it is just a generic functional entit= y in the architecture and this entity is above all access networks. Note th= e access selection via policy server meet MIF requirement as well as select= ion in inter-access mobility situation.
Most mobile terminal has implemented the policy based selection models= .
Howver I would like to raise one case, sometime, if the network conges= ted, terminal couldn't visit policy server such as ANDSF, only network = side know what happen, they may re-arrange some traffic for mobile terminal= , I guess that this is been discussed in 3GPP SA2 side at the moment.
 


Ple= ase do not hesitate to correct me if I misunderstood MIF issues.
thanks for the discussion.
 
-Hui


Reg= ards,
Pierrick

> -----Message d'origine-----
> De&nb= sp;: mif-bounces@ietf.org [mail= to:mif-bounces@ietf.org] De la = part de Peny
> Yang
> Envoy=E9 : lundi 19 janvier 2009 15:10
> =C0&n= bsp;: Kai Ju
> Cc : mif@ietf.org=
> Objet : Re: [mif] mobility issues and general issues on m= if
>
> Hi, Kai:
> > The ANSDF solution= is just a sample, because there is no one type of
> server
> &= gt; which is
> > defined to provide the policy in IETF until now. = So let us consider it
> be
> > general, which
> > means it's one policy = server that provides the routing policy to UE when
> UE
> > = is connecting
> > it.
> [Peny] Agree. 3GPP ANSDF could be a = good reference when we make the
> MIF solutions.
>
> BRG
> Peny
>
>
>= ;
> >>
> >> Hi, Peng and Kai,
> >>
&= gt; >> See reply inline below. thanks for the discussion.
> >= ;> 2009/1/19 Peny Yang <pe= ng.yang.chn@gmail.com>
> >>>
> >>> Hi, Kai:
> >>> Nice p= oint. Please check the lines below:
> >>>
> >>&g= t; > As you said, there are multiple way to assign the routing policy by=
> in
> >>> > the
> >>> > mobile acce= ss network. As viewed from the aspect of terminal, I
> think
> = >>> > its a
> >>> > good idea that terminal c= an get its routing policy from the ANDSF.
> >>> [Peny] ANDSF may be one of the choices. But ANDSF just fo= llows the
> >>> assumption of generic "one default link= " IP model. So, in 3GPP, even
> >>> though ANDSF can he= lp UE to select accesses and find the route, UE can
> >>> only choose one of the interfaces as a result.
> &g= t;>> Personally, I'm not sure if it's a good way to rely on A= NDSF of 3GPP,
> >>> since it's a specific definition in = one SDO.
> >>
> >> ANDSF in 3GPP 23.401 do cover only 3GPP netw= ork, how could ANDSF work
> for
> >> 23.402 for non-3GPP = access still a issue, it may need some mechanism to
> >> coordi= nate
> >> between two type of access entwork.what do you think?
>= >>
> >>>
> >>> > We think a default= policy can be used,  when terminal can't find
> >>>= ; > corresponding policy in the routing policy from the ANDSF. The
> default
> >>> > policy can be sent by the network.> >>> [Peny] Could we give a chance to MN to change the polic= y (like user
> >>> preference) ?
> >>>
> >>> > On another hand, I am a little confused between MIF = and Multihoming,
> >>> > would
> >>> > = you please help me to clarify the difference between them?
> >>= > [Peny] I am also not clear yet. Just give some lines as a seed for
> >>> discussion. In my personal feeling, MIF is to change the = "one default
> >>> link" feature of current generi= c IP model. Multi-homing is to ensure
> >>> the reachability= and reliability of IP network. Well, in multi-homing
> >>> MN scenarios, multi-link-multi-address is also one case. = But, in this
> >>> case, MN only can choose one link as defa= ult.
> >>> Some other comments?
> >>
> >= ;> To challenge one default link, it really takes time for mif to consid= er
> on
> >> it, current first step in mif is to consider some = straight forward way
> which
> >> is simple to resolve so= me issues.
> >> Regarding to multi-homing, I guess that it is m= ore site multi-homing.
> >> For last multi-link-multi-address mn's scenario, it will = be one of MIF
> >> scenario.
> >>
> >> = thanks
> >>
> >> -Hui
> >>
> >= >>
> >>> BRG
> >>> Peny
> >>
> &g= t;
> >
> _______________________________________________<= br>> mif mailing list
> mif@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/l= istinfo/mif

--001636417c17f80c720460ffbdbf-- --===============1176531338== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1176531338==-- From mif-bounces@ietf.org Wed Jan 21 07:38:47 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E4A28C0F6; Wed, 21 Jan 2009 07:38:47 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445A428C0F6 for ; Wed, 21 Jan 2009 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFNbMyxa5u23 for ; Wed, 21 Jan 2009 07:38:45 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E1CF228C0F3 for ; Wed, 21 Jan 2009 07:38:44 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 16:38:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 16:38:26 +0100 Message-ID: In-Reply-To: <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif Thread-Index: Acl73EHgwEclmAyIRMSnmVvYrDKPiwAAdGUA References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> From: To: X-OriginalArrivalTime: 21 Jan 2009 15:38:27.0469 (UTC) FILETIME=[4DC82BD0:01C97BDE] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org ________________________________________ De=A0: Hui Deng [mailto:denghui02@gmail.com] = Envoy=E9=A0: mercredi 21 janvier 2009 16:24 =C0=A0: SEITE Pierrick RD-RESA-REN Cc=A0: peng.yang.chn@gmail.com; jukai.zte@gmail.com; mif@ietf.org Objet=A0: Re: [mif] mobility issues and general issues on mif Hi, pierrick, = =A0 [snip] Howver I would like to raise one case, sometime, if the network congested, = terminal couldn't visit policy server such as ANDSF, only network side know= what happen, they may re-arrange some traffic for mobile terminal, I guess= that this is been discussed in 3GPP SA2 side at the moment. = =A0 [PS] you're right, I agree. [/snip] Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de P= eny > Yang > Envoy=E9=A0: lundi 19 janvier 2009 15:10 > =C0=A0: Kai Ju > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] mobility issues and general issues on mif > > Hi, Kai: > > The ANSDF solution is just a sample, because there is no one type of > server > > which is > > defined to provide the policy in IETF until now. So let us consider it > be > > general, which > > means it's one policy server that provides the routing policy to UE when > UE > > is connecting > > it. > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the > MIF solutions. > > BRG > Peny > > > > >> > >> Hi, Peng and Kai, > >> > >> See reply inline below. thanks for the discussion. > >> 2009/1/19 Peny Yang > >>> > >>> Hi, Kai: > >>> Nice point. Please check the lines below: > >>> > >>> > As you said, there are multiple way to assign the routing policy by > in > >>> > the > >>> > mobile access network. As viewed from the aspect of terminal, I > think > >>> > its a > >>> > good idea that terminal can get its routing policy from the ANDSF. > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows the > >>> assumption of generic "one default link" IP model. So, in 3GPP, even > >>> though ANDSF can help UE to select accesses and find the route, UE can > >>> only choose one of the interfaces as a result. > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of 3GPP, > >>> since it's a specific definition in one SDO. > >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF work > for > >> 23.402 for non-3GPP access still a issue, it may need some mechanism to > >> coordinate > >> between two type of access entwork.what do you think? > >> > >>> > >>> > We think a default policy can be used, =A0when terminal can't find > >>> > corresponding policy in the routing policy from the ANDSF. The > default > >>> > policy can be sent by the network. > >>> [Peny] Could we give a chance to MN to change the policy (like user > >>> preference) ? > >>> > >>> > On another hand, I am a little confused between MIF and Multihoming, > >>> > would > >>> > you please help me to clarify the difference between them? > >>> [Peny] I am also not clear yet. Just give some lines as a seed for > >>> discussion. In my personal feeling, MIF is to change the "one default > >>> link" feature of current generic IP model. Multi-homing is to ensure > >>> the reachability and reliability of IP network. Well, in multi-homing > >>> MN scenarios, multi-link-multi-address is also one case. But, in this > >>> case, MN only can choose one link as default. > >>> Some other comments? > >> > >> To challenge one default link, it really takes time for mif to consider > on > >> it, current first step in mif is to consider some straight forward way > which > >> is simple to resolve some issues. > >> Regarding to multi-homing, I guess that it is more site multi-homing. > >> For last multi-link-multi-address mn's scenario, it will be one of MIF > >> scenario. > >> > >> thanks > >> > >> -Hui > >> > >>> > >>> BRG > >>> Peny > >> > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Wed Jan 21 15:15:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D59E28C1FF; Wed, 21 Jan 2009 15:15:08 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FEF28C1FF for ; Wed, 21 Jan 2009 15:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUQC0Tfd6YZv for ; Wed, 21 Jan 2009 15:15:06 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4F84828C204 for ; Wed, 21 Jan 2009 15:15:04 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B090819873C; Thu, 22 Jan 2009 01:14:46 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 59EAF198670; Thu, 22 Jan 2009 01:14:46 +0200 (EET) Message-ID: <4977AC28.2050702@piuha.net> Date: Thu, 22 Jan 2009 01:13:44 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: mif , Marc Blanchet References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> In-Reply-To: <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org I have comments on http://tools.ietf.org/html/draft-blanchet-mif-problem-statement I had no major objections. A couple of points, however: > In this document, the multi-homed host does not forward any packet > between its interfaces. Therefore forwarding devices are out of > scope of this document. > You might consider adding a discussion about implications of weak/strong host model here. > Some received configuration objects are > specific to an interface such as the IP address and the link prefix. > Others are typically considered by implementations as being global to > the node, such as the routing information (default gateway), DNS > servers IP addresses and address selection policies. > How well has the distinction been defined, really? Its clear for some things, but is, e.g., clear for all DHCP options? > A multi-homed host may have multiple routes to a destination. > However, by default, it does not have any hint concerning which > interface would be the best to use for that destination. For > example, as discussed in > [I-D.savolainen-6man-fqdn-based-if-selection ] and > [I-D.hui-ip-multiple-connections-ps ], a service provider might want > to influence the routing table of the host connecting to its network. > (TBD: expand) > This section really makes two separate points. First, you do not know which interface to use for a particular packet. Second, service provider routing hints are simply yet another example of configuration data that needs to be reconciled between interfaces. It might be better to keep these problems separate. > An address selection policy [RFC3484 ] is used to choose the right > source and destination address for a new connection. It is > implemented globally in the node IP stack. > > As discussed in [RFC4291 ], a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes" The received policies might be conflicting. > There is currently no standard mechanism to determine what should be > the behavior of the stack in such case. > Again, there seems to be two issues. The first issue is having a policy that tells an application which addresses to use (and indirectly which interface to use). The second issue is that if the policy comes, e.g., via DHCP on a per-interface basis, then we again have to reconcile the different policies on a per-node basis. My personal classification of problems in the multiple interface space includes the following: 1) Access selection, i.e., which network(s) to attach to using the physical interface(s) that the host has. Already covered in RFC 5113. 2) Split DNS: If a host is attached to a number of different interfaces, how does it resolve a FQDN if more than one interface has provided a DNS server address? 3) Configuration reconciliation: how do we merge and use DHCP and other configuration information in a node, when the information is received on a per-interface basis? 4) Routing: If a host is attached to a number of different interfaces, where does a particular IP packet go? 5) Address selection: If a host is attached to a number of different interfaces, which addresses should be used for a particular application flow? 6) Tunnel multihoming: If a host is attached to a number of different interfaces and runs some kind of a tunneling or mobility back to a home agent, which interface and addresses should be used for a particular packet? Already covered in existing MEXT WG work items. 7) Is there a way for the host and the network to communicate about their policies regarding all of the above? My understanding is that the proposed BOF would be looking at problems 2, 3, 4, 5, and 7. The others are covered elsewhere. Jari _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Wed Jan 21 17:47:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55FD28C0EB; Wed, 21 Jan 2009 17:47:08 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A677E28C0EB for ; Wed, 21 Jan 2009 17:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcvLNkSXysPd for ; Wed, 21 Jan 2009 17:47:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5D4703A6830 for ; Wed, 21 Jan 2009 17:47:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDU00HFPNLQK0@szxga03-in.huawei.com> for mif@ietf.org; Thu, 22 Jan 2009 09:46:38 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDU00E65NLQX3@szxga03-in.huawei.com> for mif@ietf.org; Thu, 22 Jan 2009 09:46:38 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDU009R2NLPFI@szxml05-in.huawei.com> for mif@ietf.org; Thu, 22 Jan 2009 09:46:38 +0800 (CST) Date: Thu, 22 Jan 2009 09:46:37 +0800 From: Yungui Wang To: Hui Deng , pierrick.seite@orange-ftgroup.com Message-id: <007701c97c33$43df8c30$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1322771584==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1322771584== Content-type: multipart/alternative; boundary="Boundary_(ID_eTOJvbd6EINTEWVpuLXuYw)" This is a multi-part message in MIME format. --Boundary_(ID_eTOJvbd6EINTEWVpuLXuYw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello Hui One comments, whether is the IP address model to be investigated within = MIF? For example, there are different types of IP address model for = MIF-terminal, per IP address per IF, one IP address for multiple IF(s), = etc. If considered that, mobility of application/flow over IP layer = seems impliedly to be studied (e.g. in topic of IP route changing).=20 B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: pierrick.seite@orange-ftgroup.com=20 Cc: mif@ietf.org=20 Sent: Wednesday, January 21, 2009 11:23 PM Subject: Re: [mif] mobility issues and general issues on mif Hi, pierrick,=20 Thanks for joining the disucssion, speaking for mobile operator is = quite helpful for mif's work, Your experience is appreicate, see reply inline below, 2009/1/20 Hi all, I've joined recently this ML and I believe discussed topics very = interesting (BTW thanks to MIF promoters for bringing these issues to = IETF). So, please let me jump into your discussion. Thanks again. Regarding difference between MIF and multihoming: it seems there is = confusion with mobility. AFAIU, MIF is only supposed to deal with = routing issue at the multi-interface MN side. The issue is to select the = "best" interface for each outgoing IP flow and, in MIF context, access = selection does not necessarily imply flow mobility with IP session = continuity between interfaces. Nevertheless, solution should work for = terminal with several active interfaces at the same time (multi-homed), = or for terminal with a single interface at a time. Am I correct? As you said here, flow mobility and IP session continuity is out of = scope at the moment. I cann't agree with any more about your left words. Regarding ANDSF issue, I agree with preceding emails: I think access = selection should rely on policy. There are a couple of selection models = but the simplest is the selection managed by the terminal and based on = local policies and measurement on the access link. The policies may be = provided/updated by a server via out-of-band mechanism or on-demand = (typically before selection) if policies include "dynamic" = recommendation (e.g. access xx is overload and forbidden to application = type yy). Now you can call the policy server ANDSF, or whatever you = want, it is just a generic functional entity in the architecture and = this entity is above all access networks. Note the access selection via = policy server meet MIF requirement as well as selection in inter-access = mobility situation. Most mobile terminal has implemented the policy based selection = models. Howver I would like to raise one case, sometime, if the network = congested, terminal couldn't visit policy server such as ANDSF, only = network side know what happen, they may re-arrange some traffic for = mobile terminal, I guess that this is been discussed in 3GPP SA2 side at = the moment.=20 Please do not hesitate to correct me if I misunderstood MIF issues. thanks for the discussion. -Hui Regards, Pierrick > -----Message d'origine----- > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Peny > Yang > Envoy=E9 : lundi 19 janvier 2009 15:10 > =C0 : Kai Ju > Cc : mif@ietf.org > Objet : Re: [mif] mobility issues and general issues on mif > > Hi, Kai: > > The ANSDF solution is just a sample, because there is no one = type of > server > > which is > > defined to provide the policy in IETF until now. So let us = consider it > be > > general, which > > means it's one policy server that provides the routing policy to = UE when > UE > > is connecting > > it. > [Peny] Agree. 3GPP ANSDF could be a good reference when we make = the > MIF solutions. > > BRG > Peny > > > > >> > >> Hi, Peng and Kai, > >> > >> See reply inline below. thanks for the discussion. > >> 2009/1/19 Peny Yang > >>> > >>> Hi, Kai: > >>> Nice point. Please check the lines below: > >>> > >>> > As you said, there are multiple way to assign the routing = policy by > in > >>> > the > >>> > mobile access network. As viewed from the aspect of = terminal, I > think > >>> > its a > >>> > good idea that terminal can get its routing policy from the = ANDSF. > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows = the > >>> assumption of generic "one default link" IP model. So, in = 3GPP, even > >>> though ANDSF can help UE to select accesses and find the = route, UE can > >>> only choose one of the interfaces as a result. > >>> Personally, I'm not sure if it's a good way to rely on ANDSF = of 3GPP, > >>> since it's a specific definition in one SDO. > >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could = ANDSF work > for > >> 23.402 for non-3GPP access still a issue, it may need some = mechanism to > >> coordinate > >> between two type of access entwork.what do you think? > >> > >>> > >>> > We think a default policy can be used, when terminal can't = find > >>> > corresponding policy in the routing policy from the ANDSF. = The > default > >>> > policy can be sent by the network. > >>> [Peny] Could we give a chance to MN to change the policy (like = user > >>> preference) ? > >>> > >>> > On another hand, I am a little confused between MIF and = Multihoming, > >>> > would > >>> > you please help me to clarify the difference between them? > >>> [Peny] I am also not clear yet. Just give some lines as a seed = for > >>> discussion. In my personal feeling, MIF is to change the "one = default > >>> link" feature of current generic IP model. Multi-homing is to = ensure > >>> the reachability and reliability of IP network. Well, in = multi-homing > >>> MN scenarios, multi-link-multi-address is also one case. But, = in this > >>> case, MN only can choose one link as default. > >>> Some other comments? > >> > >> To challenge one default link, it really takes time for mif to = consider > on > >> it, current first step in mif is to consider some straight = forward way > which > >> is simple to resolve some issues. > >> Regarding to multi-homing, I guess that it is more site = multi-homing. > >> For last multi-link-multi-address mn's scenario, it will be one = of MIF > >> scenario. > >> > >> thanks > >> > >> -Hui > >> > >>> > >>> BRG > >>> Peny > >> > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif -------------------------------------------------------------------------= ----- _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_eTOJvbd6EINTEWVpuLXuYw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hello Hui
 
One comments, whether is the IP = address=20 model to be investigated within MIF? For example, there are different types of IP address model for=20 MIF-terminal, per IP address per IF, = one IP address for multiple IF(s), etc. = If considered that, mobility of application/flow = over IP layer=20 seems impliedly to be studied (e.g. in topic of IP route changing).=20
 
B.R.
Yungui
 
----- Original Message -----
From:=20 Hui = Deng=20
To: pierrick.seite@orange-f= tgroup.com=20
Sent: Wednesday, January 21, = 2009 11:23=20 PM
Subject: Re: [mif] mobility = issues and=20 general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile operator = is quite=20 helpful for mif's work,
Your experience is appreicate, see reply inline below,
2009/1/20 <pierrick.seite@orange-f= tgroup.com>
Hi=20 all,

I've joined recently this ML and I believe discussed = topics very=20 interesting (BTW thanks to MIF promoters for bringing these issues = to IETF).=20 So, please let me jump into your discussion.
Thanks again.
 

Regarding=20 difference between MIF and multihoming: it seems there is confusion = with=20 mobility. AFAIU, MIF is only supposed to deal with routing issue at = the=20 multi-interface MN side. The issue is to select the "best" interface = for=20 each outgoing IP flow and, in MIF context, access selection does not = necessarily imply flow mobility with IP session continuity between=20 interfaces. Nevertheless, solution should work for terminal with = several=20 active interfaces at the same time (multi-homed), or for terminal = with a=20 single interface at a time. Am I correct?
As you said here, flow mobility and IP session continuity is = out of=20 scope at the moment.
I cann't agree with any more about your left words.
 


Regarding ANDSF issue, I agree with preceding = emails: I=20 think access selection should rely on policy. There are a couple of=20 selection models but the simplest is the selection managed by the = terminal=20 and based on local policies and measurement on the access link. The = policies=20 may be provided/updated by a server via out-of-band mechanism or = on-demand=20 (typically before selection) if policies include "dynamic" = recommendation=20 (e.g. access xx is overload and forbidden to application type yy). = Now you=20 can call the policy server ANDSF, or whatever you want, it is just a = generic=20 functional entity in the architecture and this entity is above all = access=20 networks. Note the access selection via policy server meet MIF = requirement=20 as well as selection in inter-access mobility = situation.
Most mobile terminal has implemented the policy based selection=20 models.
Howver I would like to raise one case, sometime, if the network=20 congested, terminal couldn't visit policy server such as ANDSF, only = network=20 side know what happen, they may re-arrange some traffic for mobile = terminal, I=20 guess that this is been discussed in 3GPP SA2 side at the moment. =
 


Please do not hesitate to correct me if I = misunderstood=20 MIF issues.
thanks for the discussion.
 
-Hui


Regards,
Pierrick

> -----Message = d'origine-----
> De : mif-bounces@ietf.org = [mailto:mif-bounces@ietf.org] De la = part de=20 Peny
> Yang
> Envoy=E9 : lundi 19 janvier 2009 = 15:10
>=20 =C0 : Kai Ju
> Cc : mif@ietf.org
> Objet : = Re: [mif]=20 mobility issues and general issues on mif
>
> Hi, Kai:
> > The ANSDF = solution is=20 just a sample, because there is no one type of
> = server
> >=20 which is
> > defined to provide the policy in IETF until = now. So=20 let us consider it
> be
> > general, which
> = > means=20 it's one policy server that provides the routing policy to UE = when
>=20 UE
> > is connecting
> > it.
> [Peny] Agree. = 3GPP=20 ANSDF could be a good reference when we make the
> MIF=20 solutions.
>
> BRG
> = Peny
>
>
>
>=20 >>
> >> Hi, Peng and Kai,
> >>
> = >> See reply inline below. thanks for the discussion.
> = >>=20 2009/1/19 Peny Yang <peng.yang.chn@gmail.com>>=20 >>>
> >>> Hi, Kai:
> >>> Nice = point.=20 Please check the lines below:
> >>>
> = >>> >=20 As you said, there are multiple way to assign the routing policy = by
>=20 in
> >>> > the
> >>> > mobile = access=20 network. As viewed from the aspect of terminal, I
> = think
>=20 >>> > its a
> >>> > good idea that = terminal=20 can get its routing policy from the ANDSF.
> >>> = [Peny] ANDSF=20 may be one of the choices. But ANDSF just follows the
> = >>>=20 assumption of generic "one default link" IP model. So, in 3GPP, = even
>=20 >>> though ANDSF can help UE to select accesses and find = the route,=20 UE can
> >>> only choose one of the interfaces as a=20 result.
> >>> Personally, I'm not sure if it's a good = way to=20 rely on ANDSF of 3GPP,
> >>> since it's a specific = definition=20 in one SDO.
> >>
> >> ANDSF in 3GPP 23.401 = do cover=20 only 3GPP network, how could ANDSF work
> for
> >> = 23.402=20 for non-3GPP access still a issue, it may need some mechanism = to
>=20 >> coordinate
> >> between two type of access = entwork.what=20 do you think?
> >>
> >>>
> = >>>=20 > We think a default policy can be used,  when terminal = can't=20 find
> >>> > corresponding policy in the routing = policy=20 from the ANDSF. The
> default
> >>> > policy = can be=20 sent by the network.
> >>> [Peny] Could we give a = chance to=20 MN to change the policy (like user
> >>> preference)=20 ?
> >>>
> >>> > On another hand, I = am a=20 little confused between MIF and Multihoming,
> >>> = >=20 would
> >>> > you please help me to clarify the = difference=20 between them?
> >>> [Peny] I am also not clear yet. = Just give=20 some lines as a seed for
> >>> discussion. In my = personal=20 feeling, MIF is to change the "one default
> >>> = link"=20 feature of current generic IP model. Multi-homing is to = ensure
>=20 >>> the reachability and reliability of IP network. Well, = in=20 multi-homing
> >>> MN scenarios, = multi-link-multi-address is=20 also one case. But, in this
> >>> case, MN only can = choose=20 one link as default.
> >>> Some other = comments?
>=20 >>
> >> To challenge one default link, it really = takes=20 time for mif to consider
> on
> >> it, current = first step=20 in mif is to consider some straight forward way
> = which
>=20 >> is simple to resolve some issues.
> >> = Regarding to=20 multi-homing, I guess that it is more site multi-homing.
> = >>=20 For last multi-link-multi-address mn's scenario, it will be one of=20 MIF
> >> scenario.
> >>
> >>=20 thanks
> >>
> >> -Hui
> = >>
>=20 >>>
> >>> BRG
> >>> = Peny
>=20 >>
> >
> >
>=20 _______________________________________________
> mif mailing=20 list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
________= _______________________________________
mif=20 mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing=20 = list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
--Boundary_(ID_eTOJvbd6EINTEWVpuLXuYw)-- --===============1322771584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1322771584==-- From mif-bounces@ietf.org Wed Jan 21 18:06:50 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18A83A67C0; Wed, 21 Jan 2009 18:06:50 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661193A6B63 for ; Wed, 21 Jan 2009 18:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41CNkv1H1fHM for ; Wed, 21 Jan 2009 18:06:48 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 6143A3A67C0 for ; Wed, 21 Jan 2009 18:06:48 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so3464890ywj.49 for ; Wed, 21 Jan 2009 18:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9WdVEBalxKq7WM+gXCA2mSXEL5V3MHX9/7tu0QHRrbs=; b=dfQ7555W5PPGr4YB7MbqE39t+N1T+zIKEtBAwu8a8Of5/WtqStlcNhFbu8pmtkJ/1E XjbB8XxUzpXoq1WZzFTuhccVmEzWD1mQ0hLPCvhwPphwV2Mbw6mJp80VEsjO+2nKI2hC hq47zYSk2vvk+MVlQi0yi10pGXCTVSCcUhEJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CN7kkiYG8HIasvQ7D5SfB7pipx2jmmpfR7Gbuu6/1FDaKqRztfGyhddw1O/tpo3UQ5 UN1NkBHtl1Tp8cUgav/x/p9XlmMF98YRbgDwURFscmVzzXL8PpOsxq/dFpi4wH2mJzZE ECGUp1YhbGSGYcHaN919bUHk2N94NTiJRxgPU= MIME-Version: 1.0 Received: by 10.100.152.2 with SMTP id z2mr6246603and.0.1232589991116; Wed, 21 Jan 2009 18:06:31 -0800 (PST) In-Reply-To: <4977AC28.2050702@piuha.net> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> Date: Thu, 22 Jan 2009 10:06:31 +0800 Message-ID: <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> From: Peny Yang To: Jari Arkko Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Jari: Please check my lines: On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > Again, there seems to be two issues. The first issue is having a policy that > tells an application which addresses to use (and indirectly which interface > to use). The second issue is that if the policy comes, e.g., via DHCP on a > per-interface basis, then we again have to reconcile the different policies > on a per-node basis. [Peny] Agree with you for the two issues. Another point in my mind may be a possible issue. When a peer tries to initiate flows with MIF node, we need some way to let the peer know the policies and follow the policies of MIF node. > My personal classification of problems in the multiple interface space > includes the following: > > 1) Access selection, i.e., which network(s) to attach to using the physical > interface(s) that the host has. Already covered in RFC 5113. > > 2) Split DNS: If a host is attached to a number of different interfaces, how > does it resolve a FQDN if more than one interface has provided a DNS server > address? > > 3) Configuration reconciliation: how do we merge and use DHCP and other > configuration information in a node, when the information is received on a > per-interface basis? > > 4) Routing: If a host is attached to a number of different interfaces, where > does a particular IP packet go? > > 5) Address selection: If a host is attached to a number of different > interfaces, which addresses should be used for a particular application > flow? > > 6) Tunnel multihoming: If a host is attached to a number of different > interfaces and runs some kind of a tunneling or mobility back to a home > agent, which interface and addresses should be used for a particular packet? > Already covered in existing MEXT WG work items. [Peny] Agree with you from 1 to 6. > 7) Is there a way for the host and the network to communicate about their > policies regarding all of the above? [Peny] For 7, maybe we could make the way for host/PEER/network to communicate their policies. Besides, if the policies of MIF node can not be followed by the peer node, in this sense, we need a way to communicate about the policies among host/peer/network. > My understanding is that the proposed BOF would be looking at problems 2, 3, > 4, 5, and 7. The others are covered elsewhere. [Peny] Some other points I have been thinking of: 1) MIF for IPv4 or IPv6 or Both? 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we need to do the harmonization with other protocols? 3) There is the case that one interface is connected, but the route to internet is not available (Such as WiFi Portal). How does MIF handle this case? BRG Peny > Jari > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Wed Jan 21 22:26:24 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC173A67F1; Wed, 21 Jan 2009 22:26:24 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F443A67F1 for ; Wed, 21 Jan 2009 22:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lexszd9NGo0g for ; Wed, 21 Jan 2009 22:26:21 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 8D8F13A6452 for ; Wed, 21 Jan 2009 22:26:21 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so2368074wag.5 for ; Wed, 21 Jan 2009 22:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Lvm4gWJndDBhyuiG/ErZQ9oomOn92spRMLLBEeFWcVc=; b=S7wcnlb5RfrLCLmyqKECkh/ws1T7uQl3XiPE6bW8cu4iUcwS+P/UEuvbOhpwEveHL+ yFU4ltL8HRaJy2IhIh5b8a77KEyEMyInibGkbz7ngj5FBhn4QWJM0x37hLFVY/shkHKw CeAku5CEfrYb4IcUwxtib8nYe/XiumAQZddTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fpc9j42/hAK2xEvTvQ2/3RiPc+8DLXsyKhduPcZDipXwbEdCvVd9LIytnwMeAEvDZj EMsI8U4by7TwoTGPkI3gF4+baS77sDlgZAPPJnz+/aoVCaDOrRMrCiuBAFiZ1WbPbZ9S eobIiN5NG7DW6MLMTZzmmIH1M5hMgu3Qd+l/M= MIME-Version: 1.0 Received: by 10.114.124.1 with SMTP id w1mr4022515wac.135.1232605565049; Wed, 21 Jan 2009 22:26:05 -0800 (PST) In-Reply-To: <007701c97c33$43df8c30$150ca40a@china.huawei.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> Date: Thu, 22 Jan 2009 14:26:04 +0800 Message-ID: <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> From: Hui Deng To: Yungui Wang Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0529709413==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0529709413== Content-Type: multipart/alternative; boundary=00163646c600da5cee04610c58e9 --00163646c600da5cee04610c58e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yungui, mif is targetting at multiple interface whatever it has how many ip address on each of them. I guess that you are asking more IPv6 related question. What I feel what ever per interface or per IP address, how it is related to mobility of application? we are not handling handover related issues. Thanks for the discussion. Regards, -Hui 2009/1/22 Yungui Wang > Hello Hui > > One comments, whether is the IP address model to be investigated within > MIF? For example, there are different types of IP address model for > MIF-terminal, per IP address per IF, one IP address for multiple IF(s), > etc. If considered that, mobility of application/flow over IP layer seems > impliedly to be studied (e.g. in topic of IP route changing). > > B.R. > Yungui > > > ----- Original Message ----- > *From:* Hui Deng > *To:* pierrick.seite@orange-ftgroup.com > *Cc:* mif@ietf.org > *Sent:* Wednesday, January 21, 2009 11:23 PM > *Subject:* Re: [mif] mobility issues and general issues on mif > > Hi, pierrick, > > Thanks for joining the disucssion, speaking for mobile operator is quite > helpful for mif's work, > Your experience is appreicate, see reply inline below, > 2009/1/20 > >> Hi all, >> >> I've joined recently this ML and I believe discussed topics very >> interesting (BTW thanks to MIF promoters for bringing these issues to IE= TF). >> So, please let me jump into your discussion. > > Thanks again. > > >> >> Regarding difference between MIF and multihoming: it seems there is >> confusion with mobility. AFAIU, MIF is only supposed to deal with routin= g >> issue at the multi-interface MN side. The issue is to select the "best" >> interface for each outgoing IP flow and, in MIF context, access selectio= n >> does not necessarily imply flow mobility with IP session continuity betw= een >> interfaces. Nevertheless, solution should work for terminal with several >> active interfaces at the same time (multi-homed), or for terminal with a >> single interface at a time. Am I correct? > > As you said here, flow mobility and IP session continuity is out of scope > at the moment. > I cann't agree with any more about your left words. > > >> >> >> Regarding ANDSF issue, I agree with preceding emails: I think access >> selection should rely on policy. There are a couple of selection models = but >> the simplest is the selection managed by the terminal and based on local >> policies and measurement on the access link. The policies may be >> provided/updated by a server via out-of-band mechanism or on-demand >> (typically before selection) if policies include "dynamic" recommendatio= n >> (e.g. access xx is overload and forbidden to application type yy). Now y= ou >> can call the policy server ANDSF, or whatever you want, it is just a gen= eric >> functional entity in the architecture and this entity is above all acces= s >> networks. Note the access selection via policy server meet MIF requireme= nt >> as well as selection in inter-access mobility situation. > > Most mobile terminal has implemented the policy based selection models. > Howver I would like to raise one case, sometime, if the network congested= , > terminal couldn't visit policy server such as ANDSF, only network side kn= ow > what happen, they may re-arrange some traffic for mobile terminal, I gues= s > that this is been discussed in 3GPP SA2 side at the moment. > > >> >> >> Please do not hesitate to correct me if I misunderstood MIF issues. > > thanks for the discussion. > > -Hui > >> >> >> Regards, >> Pierrick >> >> > -----Message d'origine----- >> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> Peny >> > Yang >> > Envoy=E9 : lundi 19 janvier 2009 15:10 >> > =C0 : Kai Ju >> > Cc : mif@ietf.org >> > Objet : Re: [mif] mobility issues and general issues on mif >> > >> > Hi, Kai: >> > > The ANSDF solution is just a sample, because there is no one type of >> > server >> > > which is >> > > defined to provide the policy in IETF until now. So let us consider = it >> > be >> > > general, which >> > > means it's one policy server that provides the routing policy to UE >> when >> > UE >> > > is connecting >> > > it. >> > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the >> > MIF solutions. >> > >> > BRG >> > Peny >> > >> > >> > >> > >> >> > >> Hi, Peng and Kai, >> > >> >> > >> See reply inline below. thanks for the discussion. >> > >> 2009/1/19 Peny Yang >> > >>> >> > >>> Hi, Kai: >> > >>> Nice point. Please check the lines below: >> > >>> >> > >>> > As you said, there are multiple way to assign the routing policy >> by >> > in >> > >>> > the >> > >>> > mobile access network. As viewed from the aspect of terminal, I >> > think >> > >>> > its a >> > >>> > good idea that terminal can get its routing policy from the ANDS= F. >> > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows the >> > >>> assumption of generic "one default link" IP model. So, in 3GPP, ev= en >> > >>> though ANDSF can help UE to select accesses and find the route, UE >> can >> > >>> only choose one of the interfaces as a result. >> > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of >> 3GPP, >> > >>> since it's a specific definition in one SDO. >> > >> >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF wo= rk >> > for >> > >> 23.402 for non-3GPP access still a issue, it may need some mechanis= m >> to >> > >> coordinate >> > >> between two type of access entwork.what do you think? >> > >> >> > >>> >> > >>> > We think a default policy can be used, when terminal can't find >> > >>> > corresponding policy in the routing policy from the ANDSF. The >> > default >> > >>> > policy can be sent by the network. >> > >>> [Peny] Could we give a chance to MN to change the policy (like use= r >> > >>> preference) ? >> > >>> >> > >>> > On another hand, I am a little confused between MIF and >> Multihoming, >> > >>> > would >> > >>> > you please help me to clarify the difference between them? >> > >>> [Peny] I am also not clear yet. Just give some lines as a seed for >> > >>> discussion. In my personal feeling, MIF is to change the "one >> default >> > >>> link" feature of current generic IP model. Multi-homing is to ensu= re >> > >>> the reachability and reliability of IP network. Well, in >> multi-homing >> > >>> MN scenarios, multi-link-multi-address is also one case. But, in >> this >> > >>> case, MN only can choose one link as default. >> > >>> Some other comments? >> > >> >> > >> To challenge one default link, it really takes time for mif to >> consider >> > on >> > >> it, current first step in mif is to consider some straight forward >> way >> > which >> > >> is simple to resolve some issues. >> > >> Regarding to multi-homing, I guess that it is more site multi-homin= g. >> > >> For last multi-link-multi-address mn's scenario, it will be one of >> MIF >> > >> scenario. >> > >> >> > >> thanks >> > >> >> > >> -Hui >> > >> >> > >>> >> > >>> BRG >> > >>> Peny >> > >> >> > > >> > > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > ------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --00163646c600da5cee04610c58e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yungui,
 
mif is targetting at multiple interface whatever it has how many ip ad= dress on each of them.
I guess that you are asking more IPv6 related question.
 
What I feel what ever per interface or per IP address, how it is relat= ed to mobility of application?
we are not handling handover related issues.
 
Thanks for the discussion.
Regards,
 
-Hui


 
2009/1/22 Yungui Wang <w52006@huawei.com>
Hello Hui
 
One comments, whether is the IP a= ddress model to be investigated within MIF? For example, there are different types of IP address= model for MIF-terminal, per IP addr= ess per IF, one IP address for = multiple IF(s), etc. If considered t= hat, mobility of application/flow over IP layer seems impliedly to be studi= ed (e.g. in topic of IP route changing).
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Wednesday, January 21, 2009 11= :23 PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile operator is qui= te helpful for mif's work,
Your experience is appreicate, see reply inline below,
2009/1/20 <pierrick.seite@orang= e-ftgroup.com>
Hi all,

I've joined r= ecently this ML and I believe discussed topics very interesting (BTW thanks= to MIF promoters for bringing these issues to IETF). So, please let me jum= p into your discussion.
Thanks again.
 

Regarding difference between= MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF= is only supposed to deal with routing issue at the multi-interface MN side= . The issue is to select the "best" interface for each outgoing I= P flow and, in MIF context, access selection does not necessarily imply flo= w mobility with IP session continuity between interfaces. Nevertheless, sol= ution should work for terminal with several active interfaces at the same t= ime (multi-homed), or for terminal with a single interface at a time. Am I = correct?
As you said here, flow mobility and IP session continuity is out = of scope at the moment.
I cann't agree with any more about your left words.
 


Regarding A= NDSF issue, I agree with preceding emails: I think access selection should = rely on policy. There are a couple of selection models but the simplest is = the selection managed by the terminal and based on local policies and measu= rement on the access link. The policies may be provided/updated by a server= via out-of-band mechanism or on-demand (typically before selection) if pol= icies include "dynamic" recommendation (e.g. access xx is overloa= d and forbidden to application type yy). Now you can call the policy server= ANDSF, or whatever you want, it is just a generic functional entity in the= architecture and this entity is above all access networks. Note the access= selection via policy server meet MIF requirement as well as selection in i= nter-access mobility situation.
Most mobile terminal has implemented the policy based selection models= .
Howver I would like to raise one case, sometime, if the network conges= ted, terminal couldn't visit policy server such as ANDSF, only network = side know what happen, they may re-arrange some traffic for mobile terminal= , I guess that this is been discussed in 3GPP SA2 side at the moment.
 


Please do n= ot hesitate to correct me if I misunderstood MIF issues.
thanks for the discussion.
 
-Hui


Regards,Pierrick

> -----Message d'origine-----
> De : mif-bounces@ietf.org= [mailto:mif-= bounces@ietf.org] De la part de Peny
> Yang
> Envoy=E9 : lundi 19 janvier 2009 15:10
> =C0&n= bsp;: Kai Ju
> Cc : mif@ietf.org
> Objet : Re: [mif] mobility issues and g= eneral issues on mif
>
> Hi, Kai:
> > The ANSDF solution is just a sample= , because there is no one type of
> server
> > which is
&= gt; > defined to provide the policy in IETF until now. So let us conside= r it
> be
> > general, which
> > means it's one policy = server that provides the routing policy to UE when
> UE
> > = is connecting
> > it.
> [Peny] Agree. 3GPP ANSDF could be a = good reference when we make the
> MIF solutions.
>
> BRG
> Peny
>
>
>= ;
> >>
> >> Hi, Peng and Kai,
> >>
&= gt; >> See reply inline below. thanks for the discussion.
> >= ;> 2009/1/19 Peny Yang <peng.yang.chn@gmail.com>
> >>>
> >>> Hi, Kai:
> >>> Nice p= oint. Please check the lines below:
> >>>
> >>&g= t; > As you said, there are multiple way to assign the routing policy by=
> in
> >>> > the
> >>> > mobile acce= ss network. As viewed from the aspect of terminal, I
> think
> = >>> > its a
> >>> > good idea that terminal c= an get its routing policy from the ANDSF.
> >>> [Peny] ANDSF may be one of the choices. But ANDSF just fo= llows the
> >>> assumption of generic "one default link= " IP model. So, in 3GPP, even
> >>> though ANDSF can he= lp UE to select accesses and find the route, UE can
> >>> only choose one of the interfaces as a result.
> &g= t;>> Personally, I'm not sure if it's a good way to rely on A= NDSF of 3GPP,
> >>> since it's a specific definition in = one SDO.
> >>
> >> ANDSF in 3GPP 23.401 do cover only 3GPP netw= ork, how could ANDSF work
> for
> >> 23.402 for non-3GPP = access still a issue, it may need some mechanism to
> >> coordi= nate
> >> between two type of access entwork.what do you think?
>= >>
> >>>
> >>> > We think a default= policy can be used,  when terminal can't find
> >>>= ; > corresponding policy in the routing policy from the ANDSF. The
> default
> >>> > policy can be sent by the network.> >>> [Peny] Could we give a chance to MN to change the polic= y (like user
> >>> preference) ?
> >>>
> >>> > On another hand, I am a little confused between MIF = and Multihoming,
> >>> > would
> >>> > = you please help me to clarify the difference between them?
> >>= > [Peny] I am also not clear yet. Just give some lines as a seed for
> >>> discussion. In my personal feeling, MIF is to change the = "one default
> >>> link" feature of current generi= c IP model. Multi-homing is to ensure
> >>> the reachability= and reliability of IP network. Well, in multi-homing
> >>> MN scenarios, multi-link-multi-address is also one case. = But, in this
> >>> case, MN only can choose one link as defa= ult.
> >>> Some other comments?
> >>
> >= ;> To challenge one default link, it really takes time for mif to consid= er
> on
> >> it, current first step in mif is to consider some = straight forward way
> which
> >> is simple to resolve so= me issues.
> >> Regarding to multi-homing, I guess that it is m= ore site multi-homing.
> >> For last multi-link-multi-address mn's scenario, it will = be one of MIF
> >> scenario.
> >>
> >> = thanks
> >>
> >> -Hui
> >>
> >= >>
> >>> BRG
> >>> Peny
> >>
> &g= t;
> >
> _______________________________________________
> mif maili= ng list
> mif@ietf.= org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing list<= br>mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif


--00163646c600da5cee04610c58e9-- --===============0529709413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0529709413==-- From mif-bounces@ietf.org Thu Jan 22 01:15:20 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB1528C149; Thu, 22 Jan 2009 01:15:20 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BD428C149 for ; Thu, 22 Jan 2009 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wcix3BbIeAz for ; Thu, 22 Jan 2009 01:15:18 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C6A9C28C129 for ; Thu, 22 Jan 2009 01:15:17 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 10:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 10:14:49 +0100 Message-ID: In-Reply-To: <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet Thread-Index: Acl8Ng+5HqdU5wjDSS29B0S9WaasWwANSqpw References: <200901181405165005812@gmail.com><1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com><200901191706482187921@gmail.com><1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com><4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> From: To: , X-OriginalArrivalTime: 22 Jan 2009 09:14:50.0358 (UTC) FILETIME=[E0ED8160:01C97C71] Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi Peny, Please see inline comment. Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de P= eny > Yang > Envoy=E9=A0: jeudi 22 janvier 2009 03:07 > =C0=A0: Jari Arkko > Cc=A0: mif > Objet=A0: Re: [mif] draft-blanchet > = > Hi, Jari: > = > Please check my lines: > = > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > > Again, there seems to be two issues. The first issue is having a policy > that > > tells an application which addresses to use (and indirectly which > interface > > to use). The second issue is that if the policy comes, e.g., via DHCP on > a > > per-interface basis, then we again have to reconcile the different > policies > > on a per-node basis. > [Peny] Agree with you for the two issues. Another point in my mind may > be a possible issue. When a peer tries to initiate flows with MIF > node, we need some way to let the peer know the policies and follow > the policies of MIF node. > = > > My personal classification of problems in the multiple interface space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > physical > > interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different interfaces, > how > > does it resolve a FQDN if more than one interface has provided a DNS > server > > address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and other > > configuration information in a node, when the information is received on > a > > per-interface basis? > > > > 4) Routing: If a host is attached to a number of different interfaces, > where > > does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > interfaces and runs some kind of a tunneling or mobility back to a home > > agent, which interface and addresses should be used for a particular > packet? > > Already covered in existing MEXT WG work items. > [Peny] Agree with you from 1 to 6. > = > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > = > > My understanding is that the proposed BOF would be looking at problems = 2, > 3, > > 4, 5, and 7. The others are covered elsewhere. > [Peny] Some other points I have been thinking of: > 1) MIF for IPv4 or IPv6 or Both? > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? IMHO, MIF management should be independent from mobility protocol. Actually= , multi-interface management can be described in 4 steps: 1. Initiation: management of events which are expected to start multi-inter= face management process (detection of new access network, loss of interface= , user launch an application, etc....) 2. Decision: The terminal selects the "best" interface to use. 3. Preparation - e.g. acquisition of IP address on selected interface, AAA,= and so on. 4. Mobility execution - IP session continuity with MIP or derived IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or may n= ot, steer mobility protocol (step 4). If so, mobility protocol runs as spec= ified in RFCs (3775, 5213,...), without interaction with MIF mechanisms. Comments are welcome. Regards, Pierrick > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? > = > BRG > Peny > = > = > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 22 06:40:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734B83A684B; Thu, 22 Jan 2009 06:40:08 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE9E3A6A38 for ; Thu, 22 Jan 2009 06:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD5AhvZ6De2R for ; Thu, 22 Jan 2009 06:39:59 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 48DFE3A6985 for ; Thu, 22 Jan 2009 06:39:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4885327wfd.31 for ; Thu, 22 Jan 2009 06:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SqGQdmZ3mPjutHNxdY624rph62FTlaEfc5Qaf7bBCms=; b=jF5q9VqgmPOIVgMxjYZUJkTXoUkcH/c35PUOTjfUqESEJ6xSenfQR5mBrW8JhfliGM Lm9cWPox/Q6FJdal98LhkYYSHL1dHmPfDiHU5imEjZpV7t12M+nnJiFUsZI94qmb2Tzv i/7WMi1GHv1CypAUWRhZ5NrMIZs+w9cC3g8bI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rePG1Q8GJXCPH5F3IScKcFygMNsuFJ/o5YENDD/y5xNQ9oTubb2+E/lBUcvpKR5BdU 57YDVWdx3cbBoHn2cm3tsjW2BB7FN0nWaMDioIuSkvddPhl339nIh4Db9ccbf9R2DM6d xrWtz4rlUA9m3ituHd/zSDaxtPT2Mqa3snlnw= MIME-Version: 1.0 Received: by 10.114.177.1 with SMTP id z1mr3847385wae.68.1232635181661; Thu, 22 Jan 2009 06:39:41 -0800 (PST) In-Reply-To: References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> <1d38a3350901182337k5d08a312t705622e1237f2a9b@mail.gmail.com> Date: Thu, 22 Jan 2009 22:39:41 +0800 Message-ID: <1d38a3350901220639i42eab505w9e40a6e9c02aedbf@mail.gmail.com> From: Hui Deng To: Hong Yong-Geun Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0839543586==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0839543586== Content-Type: multipart/alternative; boundary=001636456e5a23fd7d0461133e57 --001636456e5a23fd7d0461133e57 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Hi, Hong, I encourage to clarify the difference between your proposal and Jari's comments 6, or which todo work is the same as your proposal. since your draft name is quite related to mext wg, that's the reason asking you to do consult work with mext, to avoid future interconnection work. thanks again. -Hui 2009/1/19 Hong Yong-Geun > Hi..Hui.. > > > > Thank you for your interest. > > > > I think that the discussion of multiple interfaces issues which is not > related to Mobile IPv6/NEMO in MEXT WG > is not useful because MEXT WG is focusing on the extension of Mobile > IPv6/NEMO. > The intension of my previous two drafts is not extending Mobile IPv6/NEMO= . > > > > Instead, if you wonder the response of Monami6 WG for my previous two > drafts, you can refer the 64th monami6 WG > meeting report when I presented. > > http://www.ietf.org/proceedings/05nov/monami6.html (6th presentation) > > > > Thanks.. > > > > Yong-Geun.. > > > > *From:* Hui Deng [mailto:denghui02@gmail.com] > *Sent:* Monday, January 19, 2009 4:38 PM > *To:* =C8=AB=BF=EB=B1=D9 > > *Cc:* mif@ietf.org > *Subject:* Re: [mif] mobility issues and general issues on mif > > > > Hi, Hong, > > > > Could you make a short summary , cross-post to the mext/mif, and cc to > chairs, and > > see their comments? > > Many thanks > > > > -Hui > > 2009/1/15 Hong Yong-Geun > > > > Hi..Hui.. > > > > No, I didn't discuss with mext wg. I presented and discussed with monami6 > wg at 64th IETF meeting. > > And it was not adopted in monami6 wg because it was not in the scope of > monami6 wg. > > > > Best regards. > > > > Yong-Geun.. > > > > *From:* Hui Deng [mailto:denghui02@gmail.com] > *Sent:* Thursday, January 15, 2009 3:47 PM > *To:* =C8=AB=BF=EB=B1=D9 > > > *Cc:* mif@ietf.org > *Subject:* Re: [mif] mobility issues and general issues on mif > > > > you already had a discussion with mext wg, they are not adopting this > work? > > > > -Hui > > 2009/1/14 Hong Yong-Geun > > > > Hi..Hui.. > > > > Thank you for comments. See below inline reply. > > > > Best regards. > > > > Yong-Geun.. > > > > *From:* Hui Deng [mailto:denghui02@gmail.com] > *Sent:* Wednesday, January 14, 2009 7:20 AM > *To:* =C8=AB=BF=EB=B1=D9 > *Cc:* mif@ietf.org > *Subject:* Re: [mif] mobility issues and general issues on mif > > > > Hi, Hong Yong, > > > > I read through your two drafts, understand you are talking the issue with= out > Monami > > ? Yes, you are correct. > I want to solve the multiple interface problems without modifying Mobile > IPv6/NEMO code. > (In Monami6, multiple interface problems (which are related to mobility > issues, such as multiple CoA, > multiple HoA, etc., ) are resolving by modifying Mobile IPv6/NEMO > protocol) > > > it seems Mobile Ipv6 internal also has similar issue with us if I > understand it correctly, > > ? Yes, because Mobile IPv6 is based on the basic operation of IPv6, > Mobile IPv6 internal > has similar issues of mif. So, I think that it is valuable to separate > more general issues from > multiple interface issues which are directly related to Mobile IPv6/NEMO. > > > > In this case I would like to encourage you to propose this issue to our > work, if allowed, > > it mightbe doable within our scope, > > ? Thanks. It is my pleasure.. > > > > many thanks > > > > -Hui > > 2009/1/7 Hong Yong-Geun > > Hi. mif.. > > Let me join this discussion. > > It is very interesting to see mif. > > As Hui Deng says, I understand that mif has different approach > from other WG such as MEXT and monami6 WG, etc. > > In MEXT, multiple interfaces issues are related to Mobile IP, NEMO,.. > In mif, multiple interfaces issues are different from those of MEXT. > So, in mif, it is better to find more general issues which are not relate= d > to Mobile IP. > > I think that M.Blanchet's "Multiple Interfaces Problem Statement" draft i= s > a good starting point to discuss general issues on mif. > > I would like to introduce another related drafts which I presented at > monami6 WG at 64th IETF meeting. > > - Analysis of multiple interfaces in a Mobile Node( > draft-hong-multipleif-mn-pb-statement-00) > > http://tools.ietf.org/draft/draft-hong-multipleif-mn-pb-statement/draft-h= ong-multipleif-mn-pb-statement-00.txt > > - Virtual network interface for multiple interfaces in a Mobile node > using Mobile IPv6 > (draft-hong-virtualif-mn-mipv6-00) > > http://tools.ietf.org/draft/draft-hong-virtualif-mn-mipv6/draft-hong-virt= ualif-mn-mipv6-00.txt > > > In the section 2.2 (General Network Issues) in the first draft, > there are general network issues due to multiple interfaces. > > Including these drafts, I hope to encourage this discussion > > Yong-Geun. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > > *=BF=C0=B7=F9! =C6=C4=C0=CF =C0=CC=B8=A7=C0=CC =C1=F6=C1=A4=B5=C7=BE=EE = =C0=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.* > > > > *=BF=C0=B7=F9! =C6=C4=C0=CF =C0=CC=B8=A7=C0=CC =C1=F6=C1=A4=B5=C7=BE=EE = =C0=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.* > > > --001636456e5a23fd7d0461133e57 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi, Hong,
 
I encourage to clarify the difference between your proposal and J= ari's comments 6, or which todo work is the same as your proposal.=
 
since your draft name is quite related to mext wg, that's the= reason asking you to do consult work with mext, to avoid future = interconnection work.
 
thanks again.
 
-Hui

--001636456e5a23fd7d0461133e57-- --===============0839543586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0839543586==-- From mif-bounces@ietf.org Thu Jan 22 09:09:52 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22FE28C23A; Thu, 22 Jan 2009 09:09:52 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FF53A692F for ; Wed, 21 Jan 2009 19:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ov4AERKiLEH for ; Wed, 21 Jan 2009 19:32:24 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id 6A2C53A68B1 for ; Wed, 21 Jan 2009 19:32:24 -0800 (PST) Received: by gxk14 with SMTP id 14so3709510gxk.13 for ; Wed, 21 Jan 2009 19:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ztG0nwS3BEZ2HpMJaWaT5Wytq61uDHXrhby6oHFgcBI=; b=jw9Eluf11mHgN4cKT+YMjpmdqShfKmbC5httSH/YZT0Y5dKHHUY7csBeVL9wnY9Hz+ JK1d1W3XJYtnQn36EJ0yOnzDTCxflIdYzc4HXRrMGvDhTcA+hbCrQOAXsS6zjq9LVOS6 SK53dCAMATpBN+jUNWxpRlPNgln94fL2M2G8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DuCtHvF2uac8+0s5SgqcC75/Ejt09wbRMGcWMnjmebNMZkxuL9eEKvoSaujFfnuULw wFbZytwyi5G570ckp83MSAB+UWg3FD/DGbTjFwmzn4dTYyZnsKHe7h3i3XbI18ijDobP cZ+MLT/rpOn5kk6QE9ERYHybBFHQMxTGzGxiw= MIME-Version: 1.0 Received: by 10.151.38.11 with SMTP id q11mr984874ybj.207.1232595126775; Wed, 21 Jan 2009 19:32:06 -0800 (PST) In-Reply-To: <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Wed, 21 Jan 2009 19:32:06 -0800 Message-ID: From: Kevin Chin To: Peny Yang Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1331920288==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1331920288== Content-Type: multipart/alternative; boundary=00151743f9e8aef1e8046109ea88 --00151743f9e8aef1e8046109ea88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > 1) MIF for IPv4 or IPv6 or Both? > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? > > 7) Is there a way for the host and the network to communicate about their > policies regarding all of the above? Very interesting topic. I assume MIF is optional "should" v. "must" w.r.t policies from the network (e.g. guidance not directive). The MS may have lots of policies which can make an informed decision. As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. This would imply MS pushing characteristics up to the network so the network can push device-specific directives down. It should not be the case that the device needs to push capabilties upstream for the network to provide MIF-based guidance. Furthermore there may be different networks on each interface necessitating conflict resolution protocols, let alone issues that occur sporadically (e.g. WiFI portal, network roaming policies, access-based policy) .... Can't device based provisioning with (optional) input from network address most of the stated issues? thanks- Kevin On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: > Hi, Jari: > > Please check my lines: > > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > > Again, there seems to be two issues. The first issue is having a policy > that > > tells an application which addresses to use (and indirectly which > interface > > to use). The second issue is that if the policy comes, e.g., via DHCP on > a > > per-interface basis, then we again have to reconcile the different > policies > > on a per-node basis. > [Peny] Agree with you for the two issues. Another point in my mind may > be a possible issue. When a peer tries to initiate flows with MIF > node, we need some way to let the peer know the policies and follow > the policies of MIF node. > > > My personal classification of problems in the multiple interface space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > physical > > interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different interfaces, > how > > does it resolve a FQDN if more than one interface has provided a DNS > server > > address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and other > > configuration information in a node, when the information is received on > a > > per-interface basis? > > > > 4) Routing: If a host is attached to a number of different interfaces, > where > > does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > interfaces and runs some kind of a tunneling or mobility back to a home > > agent, which interface and addresses should be used for a particular > packet? > > Already covered in existing MEXT WG work items. > [Peny] Agree with you from 1 to 6. > > > 7) Is there a way for the host and the network to communicate about their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > > > My understanding is that the proposed BOF would be looking at problems 2, > 3, > > 4, 5, and 7. The others are covered elsewhere. > [Peny] Some other points I have been thinking of: > 1) MIF for IPv4 or IPv6 or Both? > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? > > BRG > Peny > > > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --00151743f9e8aef1e8046109ea88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
1) MIF for IPv4 or IPv6 or Both?=
 

2) &nbs= p;Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to= do the harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@g= mail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <<= a href=3D"mailto:jari.arkko@piuha.net">jari.arkko@piuha.net> wrote:<= br>> Again, there seems to be two issues. The first issue is having a po= licy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in th= e multiple interface space
> includes the following:
>
> = 1) Access selection, i.e., which network(s) to attach to using the physical=
> interface(s) that the host has. Already covered in RFC 5113.
>> 2) Split DNS: If a host is attached to a number of different interfa= ces, how
> does it resolve a FQDN if more than one interface has prov= ided a DNS server
> address?
>
> 3) Configuration reconciliation: how do we me= rge and use DHCP and other
> configuration information in a node, whe= n the information is received on a
> per-interface basis?
>
> 4) Routing: If a host is attached to a number of different interfaces,= where
> does a particular IP packet go?
>
> 5) Address s= election: If a host is attached to a number of different
> interfaces= , which addresses should be used for a particular application
> flow?
>
> 6) Tunnel multihoming: If a host is attached to = a number of different
> interfaces and runs some kind of a tunneling = or mobility back to a home
> agent, which interface and addresses sho= uld be used for a particular packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree = with you from 1 to 6.

> 7) Is there a way for the host and the netwo= rk to communicate about their
> policies regarding all of the above?<= br>
[Peny] For 7, maybe we could make the way for host/PEER/network to=
communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.

> My understanding is that the proposed BOF wo= uld be looking at problems 2, 3,
> 4, 5, and 7. The others are covere= d elsewhere.
[Peny] Some other points I have been thinking of:
1) MIF for IPv4 or IPv6 or Both?
2)  Will MIF need to co-work with = (P)MIP, DSMIP, etc? If so, do we
need to do the harmonization with other= protocols?
3) There is the case that one interface is connected, but th= e route to
internet is not available (Such as WiFi Portal).  How does MIF handle<= br>this case?

BRG
Peny


> Jari
>
> ___________________= ____________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listi= nfo/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
https://www.ietf.org/m= ailman/listinfo/mif

--00151743f9e8aef1e8046109ea88-- --===============1331920288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1331920288==-- From mif-bounces@ietf.org Thu Jan 22 14:23:00 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5033A67F5; Thu, 22 Jan 2009 14:23:00 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFCD3A68AF for ; Thu, 22 Jan 2009 14:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.722 X-Spam-Level: X-Spam-Status: No, score=-103.722 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrsMOS1SoaH6 for ; Thu, 22 Jan 2009 14:22:53 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 43D563A67F5 for ; Thu, 22 Jan 2009 14:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1232662957; x=1264198957; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Jari=20Arkko=20,=20mif=20,=0D=0A=20=20=20=20=20=20=20=20Marc=20Blanchet =0D=0A=09|Date:=20Thu,=2022=20 Jan=202009=2014:22:26=20-0800|Subject:=20RE:=20[mif]=20dr aft-blanchet|Thread-Topic:=20[mif]=20draft-blanchet |Thread-Index:=20Acl8HibcQ/t2q+RgQESHBBWwH5NbQwAwXbLg |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@ NASANEXMB08.na.qualcomm.com>|References:=20<2009011814051 65005812@gmail.com>=0D=0A=09=0D=0A=09<1d38a335090 1182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com>=0D=0A =09<200901191706482187921@gmail.com>=0D=0A=09<1d38a335090 1210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com>=0D=0A=20 <4977AC28.2050702@piuha.net>|In-Reply-To:=20<4977AC28.205 0702@piuha.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5503"=3B=20a=3D"14871529"; bh=Ruu2DTllN28nPxgWkebfdU/qsDEGS98B6/CjJmhPkAE=; b=e2Q5/qz9jiGKeJb1Sc+47Rs6qHsPdx9OfASbh5Xded17EmufxnUebFcS HSe2GqyPDQGHy0J2lMAG/RzyP/e8PwYFdn1KDToTYunf2i7GK0gZc2ga8 IetCv63oFeKmxu3APbDMcRnoTi1TYvdVRwWoq2kp8zAYVaVVp9WyPKYN8 g=; X-IronPort-AV: E=McAfee;i="5100,188,5503"; a="14871529" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2009 14:22:36 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0MMMaBV031604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jan 2009 14:22:36 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0MMMTk1012789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Jan 2009 14:22:33 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 22 Jan 2009 14:22:29 -0800 From: "Giaretta, Gerardo" To: Jari Arkko , mif , Marc Blanchet Date: Thu, 22 Jan 2009 14:22:26 -0800 Thread-Topic: [mif] draft-blanchet Thread-Index: Acl8HibcQ/t2q+RgQESHBBWwH5NbQwAwXbLg Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@NASANEXMB08.na.qualcomm.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> In-Reply-To: <4977AC28.2050702@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi Jari, One question at the end of the email > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Jari > Arkko > Sent: Wednesday, January 21, 2009 3:14 PM > To: mif; Marc Blanchet > Subject: [mif] draft-blanchet > > I have comments on > http://tools.ietf.org/html/draft-blanchet-mif-problem-statement > > I had no major objections. A couple of points, however: > > > In this document, the multi-homed host does not forward any packet > > between its interfaces. Therefore forwarding devices are out of > > scope of this document. > > > > You might consider adding a discussion about implications of weak/strong > host model here. > > > Some received configuration objects are > > specific to an interface such as the IP address and the link prefix. > > Others are typically considered by implementations as being global to > > the node, such as the routing information (default gateway), DNS > > servers IP addresses and address selection policies. > > > > How well has the distinction been defined, really? Its clear for some > things, but is, e.g., clear for all DHCP options? > > > A multi-homed host may have multiple routes to a destination. > > However, by default, it does not have any hint concerning which > > interface would be the best to use for that destination. For > > example, as discussed in > > [I-D.savolainen-6man-fqdn-based-if-selection > D.savolainen-6man-fqdn-based-if-selection>] and > > [I-D.hui-ip-multiple-connections-ps blanchet-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], a > service provider might want > > to influence the routing table of the host connecting to its network. > > (TBD: expand) > > > This section really makes two separate points. First, you do not know > which interface to use for a particular packet. Second, service provider > routing hints are simply yet another example of configuration data that > needs to be reconciled between interfaces. It might be better to keep > these problems separate. > > > An address selection policy [RFC3484 ] > is used to choose the right > > source and destination address for a new connection. It is > > implemented globally in the node IP stack. > > > > As discussed in [RFC4291 ], a multi- > homed host with IPv4 and IPv6 > > connectivity might need to receive an update of its default address > > selection policy. However, that policy is only valid within the > > context of the interface it received it from. Each network on which > > the node is connected might have a different address policy to push > > to the connecting nodes" The received policies might be conflicting. > > There is currently no standard mechanism to determine what should be > > the behavior of the stack in such case. > > > > Again, there seems to be two issues. The first issue is having a policy > that tells an application which addresses to use (and indirectly which > interface to use). The second issue is that if the policy comes, e.g., > via DHCP on a per-interface basis, then we again have to reconcile the > different policies on a per-node basis. > > My personal classification of problems in the multiple interface space > includes the following: > > 1) Access selection, i.e., which network(s) to attach to using the > physical interface(s) that the host has. Already covered in RFC 5113. > > 2) Split DNS: If a host is attached to a number of different interfaces, > how does it resolve a FQDN if more than one interface has provided a DNS > server address? > > 3) Configuration reconciliation: how do we merge and use DHCP and other > configuration information in a node, when the information is received on > a per-interface basis? > > 4) Routing: If a host is attached to a number of different interfaces, > where does a particular IP packet go? > > 5) Address selection: If a host is attached to a number of different > interfaces, which addresses should be used for a particular application > flow? > > 6) Tunnel multihoming: If a host is attached to a number of different > interfaces and runs some kind of a tunneling or mobility back to a home > agent, which interface and addresses should be used for a particular > packet? Already covered in existing MEXT WG work items. > > 7) Is there a way for the host and the network to communicate about > their policies regarding all of the above? > > My understanding is that the proposed BOF would be looking at problems > 2, 3, 4, 5, and 7. The others are covered elsewhere. > How is it 4 different from 6? My understanding is 6 already covers how routing is performed as you indicated. Or is the intention of 4 to provide hints to e.g. MIPv6 extensions so that a certain interface/CoA is registered for a given IP flow? Thanks Gerardo > Jari > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 22 23:06:15 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5DF3A68F7; Thu, 22 Jan 2009 23:06:15 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392BA3A6941 for ; Thu, 22 Jan 2009 23:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo4LFyYcaWoc for ; Thu, 22 Jan 2009 23:06:12 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id C21D73A68F7 for ; Thu, 22 Jan 2009 23:06:12 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4643622rvf.49 for ; Thu, 22 Jan 2009 23:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BdOSK8f3anrKFAfB9mPzix4Xiw6YqbBDzfvlwxif4q0=; b=HtOyd+wnrAKauKMG2FS9WqBa285JBQyUFXPqoyxuDLsfDGiWiMpwG9QQOQKD33p0IQ QMJLKdWoEYoh/TI6diiJ8iPDeXz+hh+7d9kNk6CMs71T0DPsJhYNL3eV3SfOQdZQhY8s apUUJcJDuUIWPotNFMI+ErzuOr0PGo1FJhyCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GW3pJ4R8WOOKJ+5+wgD8zGXfEIcuSXdcSX9qI3uM9+Nt26ISDyUZ6ceLDHjdHX6SA2 jCGppEpMyjwB7sRADlSTM0D1Tz5/lQIUuNiBlWitxJVWdOcbjhP+c5NMPKyUoyOzxPPI 1azsoQ3GWJdfFwqWm7E/ZKUMv9bm27Km/6Rr4= MIME-Version: 1.0 Received: by 10.141.48.10 with SMTP id a10mr1982388rvk.71.1232694355019; Thu, 22 Jan 2009 23:05:55 -0800 (PST) In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@NASANEXMB08.na.qualcomm.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@NASANEXMB08.na.qualcomm.com> Date: Fri, 23 Jan 2009 15:05:54 +0800 Message-ID: From: Tao Sun To: "Giaretta, Gerardo" Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443816565==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1443816565== Content-Type: multipart/alternative; boundary=000e0cd2bd0025c9dd0461210504 --000e0cd2bd0025c9dd0461210504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Gerardo, Allow me to chime in here, I guess 4 is not related MIPv6 stuff, that is the basic difference thanks -Tao On Fri, Jan 23, 2009 at 6:22 AM, Giaretta, Gerardo wrote: > Hi Jari, > > One question at the end of the email > > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Jari > > Arkko > > Sent: Wednesday, January 21, 2009 3:14 PM > > To: mif; Marc Blanchet > > Subject: [mif] draft-blanchet > > > > I have comments on > > http://tools.ietf.org/html/draft-blanchet-mif-problem-statement > > > > I had no major objections. A couple of points, however: > > > > > In this document, the multi-homed host does not forward any packet > > > between its interfaces. Therefore forwarding devices are out of > > > scope of this document. > > > > > > > You might consider adding a discussion about implications of weak/strong > > host model here. > > > > > Some received configuration objects are > > > specific to an interface such as the IP address and the link prefix. > > > Others are typically considered by implementations as being global to > > > the node, such as the routing information (default gateway), DNS > > > servers IP addresses and address selection policies. > > > > > > > How well has the distinction been defined, really? Its clear for some > > things, but is, e.g., clear for all DHCP options? > > > > > A multi-homed host may have multiple routes to a destination. > > > However, by default, it does not have any hint concerning which > > > interface would be the best to use for that destination. For > > > example, as discussed in > > > [I-D.savolainen-6man-fqdn-based-if-selection > > < > http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I- > > D.savolainen-6man-fqdn-based-if-selection>] and > > > [I-D.hui-ip-multiple-connections-ps > > blanchet-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], > a > > service provider might want > > > to influence the routing table of the host connecting to its network. > > > (TBD: expand) > > > > > This section really makes two separate points. First, you do not know > > which interface to use for a particular packet. Second, service provider > > routing hints are simply yet another example of configuration data that > > needs to be reconciled between interfaces. It might be better to keep > > these problems separate. > > > > > An address selection policy [RFC3484 < > http://tools.ietf.org/html/rfc3484>] > > is used to choose the right > > > source and destination address for a new connection. It is > > > implemented globally in the node IP stack. > > > > > > As discussed in [RFC4291 ], a > multi- > > homed host with IPv4 and IPv6 > > > connectivity might need to receive an update of its default address > > > selection policy. However, that policy is only valid within the > > > context of the interface it received it from. Each network on which > > > the node is connected might have a different address policy to push > > > to the connecting nodes" The received policies might be conflicting. > > > There is currently no standard mechanism to determine what should be > > > the behavior of the stack in such case. > > > > > > > Again, there seems to be two issues. The first issue is having a policy > > that tells an application which addresses to use (and indirectly which > > interface to use). The second issue is that if the policy comes, e.g., > > via DHCP on a per-interface basis, then we again have to reconcile the > > different policies on a per-node basis. > > > > My personal classification of problems in the multiple interface space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > > physical interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different interfaces, > > how does it resolve a FQDN if more than one interface has provided a DNS > > server address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and other > > configuration information in a node, when the information is received on > > a per-interface basis? > > > > 4) Routing: If a host is attached to a number of different interfaces, > > where does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > interfaces and runs some kind of a tunneling or mobility back to a home > > agent, which interface and addresses should be used for a particular > > packet? Already covered in existing MEXT WG work items. > > > > 7) Is there a way for the host and the network to communicate about > > their policies regarding all of the above? > > > > My understanding is that the proposed BOF would be looking at problems > > 2, 3, 4, 5, and 7. The others are covered elsewhere. > > > > How is it 4 different from 6? My understanding is 6 already covers how > routing is performed as you indicated. Or is the intention of 4 to provide > hints to e.g. MIPv6 extensions so that a certain interface/CoA is registered > for a given IP flow? > > Thanks > Gerardo > > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd2bd0025c9dd0461210504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Gerardo,
 
Allow me to chime in here,
I guess 4 is not related MIPv6 stuff, that is the basic difference
=
thanks
 
-Tao
On Fri, Jan 23, 2009 at 6:22 AM, Giaretta, Gerar= do <gerardog@= qualcomm.com> wrote:
Hi Jari,

One question at = the end of the email

> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of J= ari
> Arkko
> Sent: Wednesday, January 21, 2009 3:14 PM
> To: mi= f; Marc Blanchet
> Subject: [mif] draft-blanchet
>
> I ha= ve comments on
> http://tools.ietf.org/html/draft-= blanchet-mif-problem-statement
>
> I had no major objections. A couple of points, however:
>= ;
> > In this document, the multi-homed host does not forward any = packet
> > between its interfaces.  Therefore forwarding devi= ces are out of
> > scope of this document.
> >
>
> You might co= nsider adding a discussion about implications of weak/strong
> host m= odel here.
>
> > Some received configuration objects are
> > specific to an interface such as the IP address and the link pref= ix.
> > Others are typically considered by implementations as bein= g global to
> > the node, such as the routing information (default= gateway), DNS
> > servers IP addresses and address selection policies.
> >=
>
> How well has the distinction been defined, really? Its cle= ar for some
> things, but is, e.g., clear for all DHCP options?
>
> > A multi-homed host may have multiple routes to a destinat= ion.
> > However, by default, it does not have any hint concerning= which
> > interface would be the best to use for that destination= .  For
> > example, as discussed in
> > [I-D.savolainen-6man-fqdn-b= ased-if-selection
> <http://tools.iet= f.org/html/draft-blanchet-mif-problem-statement-00#ref-I-
> D.savolainen-6man-fqdn-based-if-selection>] and
> > [I-D.h= ui-ip-multiple-connections-ps <http://tools.ietf.org/html/draft-
> blanch= et-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], a<= br> > service provider might want
> > to influence the routing tabl= e of the host connecting to its network.
> > (TBD: expand)
>= >
> This section really makes two separate points. First, you do = not know
> which interface to use for a particular packet. Second, service provid= er
> routing hints are simply yet another example of configuration da= ta that
> needs to be reconciled between interfaces. It might be bett= er to keep
> these problems separate.
>
> > An address selection pol= icy [RFC3484 <http://tools.ietf.org/html/rfc3484>]
> is used to choos= e the right
> > source and destination address for a new connection.  It is<= br>> > implemented globally in the node IP stack.
> >
>= ; > As discussed in [RFC4291 <http://tools.ietf.org/html/rfc4291>], a mu= lti-
> homed host with IPv4 and IPv6
> > connectivity might need to = receive an update of its default address
> > selection policy. &nb= sp;However, that policy is only valid within the
> > context of th= e interface it received it from.  Each network on which
> > the node is connected might have a different address policy to pu= sh
> > to the connecting nodes" The received policies might b= e conflicting.
> > There is currently no standard mechanism to det= ermine what should be
> > the behavior of the stack in such case.
> >
>
&= gt; Again, there seems to be two issues. The first issue is having a policy=
> that tells an application which addresses to use (and indirectly w= hich
> interface to use). The second issue is that if the policy comes, e.g.,=
> via DHCP on a per-interface basis, then we again have to reconcile= the
> different policies on a per-node basis.
>
> My per= sonal classification of problems in the multiple interface space
> includes the following:
>
> 1) Access selection, i.e., whi= ch network(s) to attach to using the
> physical interface(s) that the= host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a = host is attached to a number of different interfaces,
> how does it resolve a FQDN if more than one interface has provided a D= NS
> server address?
>
> 3) Configuration reconciliation:= how do we merge and use DHCP and other
> configuration information i= n a node, when the information is received on
> a per-interface basis?
>
> 4) Routing: If a host is attach= ed to a number of different interfaces,
> where does a particular IP = packet go?
>
> 5) Address selection: If a host is attached to a= number of different
> interfaces, which addresses should be used for a particular applicatio= n
> flow?
>
> 6) Tunnel multihoming: If a host is attache= d to a number of different
> interfaces and runs some kind of a tunne= ling or mobility back to a home
> agent, which interface and addresses should be used for a particular> packet? Already covered in existing MEXT WG work items.
>
&= gt; 7) Is there a way for the host and the network to communicate about
> their policies regarding all of the above?
>
> My understa= nding is that the proposed BOF would be looking at problems
> 2, 3, 4= , 5, and 7. The others are covered elsewhere.
>

How is it 4 different from 6? My understanding is 6 already covers how rout= ing is performed as you indicated. Or is the intention of 4 to provide hint= s to e.g. MIPv6 extensions so that a certain interface/CoA is registered fo= r a given IP flow?

Thanks
Gerardo

> Jari
>
> _______________________= ________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/= mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/l= istinfo/mif

--000e0cd2bd0025c9dd0461210504-- --===============1443816565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1443816565==-- From mif-bounces@ietf.org Thu Jan 22 23:16:31 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A993A6A3F; Thu, 22 Jan 2009 23:16:31 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1823A6A3F for ; Thu, 22 Jan 2009 23:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9u16hcxQBJ0 for ; Thu, 22 Jan 2009 23:16:28 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 115A33A6941 for ; Thu, 22 Jan 2009 23:16:27 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4646754rvf.49 for ; Thu, 22 Jan 2009 23:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MQgUoqnjrhr82LAZ1XyejAafWLq36/lRkPgPQwLQws0=; b=iJ0AvNyLRPFHPq2ibdi+x3BIOYp9LNQUFW7WWsnkwK0ptsRRYkTkfH6msUJo5R42Qm dfV5PiFjMU0ETjfNXgRPHDSeAsFVQJpD7TlZqL9E0I+s+DAI7hCRS0oURVNOxDZmQgJ/ Toi2/FfSPAYQ3E2+vhaUb8dI8XO3C75au4ErI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G0SbUKAY1kg6BvfVuyyQ6SmggH/4IFmP/MGvPgTSJ/xxn7BWPAAE1r9oIrXoXpRzri Vi1qVLlUyJZlW0kM55LkKUNZNp3tMMw6eEoiYilWhrk2Clg/rqzYvRjbeNpuJ1Ya/xE3 PbNrk1AiIYxrvlQfS5gMn0brEYl2UcXElafDw= MIME-Version: 1.0 Received: by 10.141.66.16 with SMTP id t16mr2390062rvk.103.1232694971352; Thu, 22 Jan 2009 23:16:11 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Fri, 23 Jan 2009 15:16:11 +0800 Message-ID: From: Tao Sun To: Kevin Chin Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651956521==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0651956521== Content-Type: multipart/alternative; boundary=000e0cd156a4e248220461212971 --000e0cd156a4e248220461212971 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Kevin, I tend to agree with you here that the terminal may not need to upstream the capability to the network. but do you see any proposal here doing that? but sometime, MS made some decision on the interface and route, but what happen if network congested, how to handle that? just waiting for the fall back. For confliction of policy, I guess that it could be categorized by two case, one operator, then it should be avoided by offline arrangement, for two ISPs, FIFO still work there, cause no problem for user's traffic. thanks for the discussion. -Tao On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: > > >> 1) MIF for IPv4 or IPv6 or Both? > > > >> >> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >> need to do the harmonization with other protocols? >> 3) There is the case that one interface is connected, but the route to >> internet is not available (Such as WiFi Portal). How does MIF handle >> this case? >> > > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > > Very interesting topic. > > I assume MIF is optional "should" v. "must" w.r.t policies from the network > (e.g. guidance not directive). > The MS may have lots of policies which can make an informed decision. > > As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. > This would imply MS pushing characteristics up to the network so the > network can push device-specific directives down. > It should not be the case that the device needs to push capabilties > upstream for the network to provide MIF-based guidance. > > Furthermore there may be different networks on each interface necessitating > conflict resolution protocols, let alone issues that occur sporadically > (e.g. WiFI portal, network roaming policies, access-based policy) .... > > Can't device based provisioning with (optional) input from network address > most of the stated issues? > > thanks- > Kevin > > On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: > >> Hi, Jari: >> >> Please check my lines: >> >> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: >> > Again, there seems to be two issues. The first issue is having a policy >> that >> > tells an application which addresses to use (and indirectly which >> interface >> > to use). The second issue is that if the policy comes, e.g., via DHCP on >> a >> > per-interface basis, then we again have to reconcile the different >> policies >> > on a per-node basis. >> [Peny] Agree with you for the two issues. Another point in my mind may >> be a possible issue. When a peer tries to initiate flows with MIF >> node, we need some way to let the peer know the policies and follow >> the policies of MIF node. >> >> > My personal classification of problems in the multiple interface space >> > includes the following: >> > >> > 1) Access selection, i.e., which network(s) to attach to using the >> physical >> > interface(s) that the host has. Already covered in RFC 5113. >> > >> > 2) Split DNS: If a host is attached to a number of different interfaces, >> how >> > does it resolve a FQDN if more than one interface has provided a DNS >> server >> > address? >> > >> > 3) Configuration reconciliation: how do we merge and use DHCP and other >> > configuration information in a node, when the information is received on >> a >> > per-interface basis? >> > >> > 4) Routing: If a host is attached to a number of different interfaces, >> where >> > does a particular IP packet go? >> > >> > 5) Address selection: If a host is attached to a number of different >> > interfaces, which addresses should be used for a particular application >> > flow? >> > >> > 6) Tunnel multihoming: If a host is attached to a number of different >> > interfaces and runs some kind of a tunneling or mobility back to a home >> > agent, which interface and addresses should be used for a particular >> packet? >> > Already covered in existing MEXT WG work items. >> [Peny] Agree with you from 1 to 6. >> >> > 7) Is there a way for the host and the network to communicate about >> their >> > policies regarding all of the above? >> [Peny] For 7, maybe we could make the way for host/PEER/network to >> communicate their policies. Besides, if the policies of MIF node can >> not be followed by the peer node, in this sense, we need a way to >> communicate about the policies among host/peer/network. >> >> > My understanding is that the proposed BOF would be looking at problems >> 2, 3, >> > 4, 5, and 7. The others are covered elsewhere. >> [Peny] Some other points I have been thinking of: >> 1) MIF for IPv4 or IPv6 or Both? >> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >> need to do the harmonization with other protocols? >> 3) There is the case that one interface is connected, but the route to >> internet is not available (Such as WiFi Portal). How does MIF handle >> this case? >> >> BRG >> Peny >> >> >> > Jari >> > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd156a4e248220461212971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Kevin,
 
I tend to agree with you here that the terminal may not need to&n= bsp;upstream the capability to the network. but do you see any proposal her= e doing that?

but sometime, MS made some decision on the interface a= nd route, but what happen if network congested, how to handle that? just wa= iting for the fall back.
 
For confliction of policy, I guess that it could be categorized by two= case,
one operator, then it should be avoided by offline arrangement,
for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
 
thanks for the discussion.
 
-Tao
 
 
On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.c= om> wrote:
 
1) MIF for IPv4 or IPv6 or Both?=
 

2)  Will M= IF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the = harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:=
> Again, there seems to be two issues. The first issue is having a p= olicy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate= about their
> policies regarding all of the above?
[Peny] F= or 7, maybe we could make the way for host/PEER/network to
communicate t= heir policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at= problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
<= /div>[Peny] Some other points I have been thinking of:
1) MIF for IPv4 o= r IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
= need to do the harmonization with other protocols?
3) There is the case = that one interface is connected, but the route to
internet is not availa= ble (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny


> Jari
>
> ____________________________________= ___________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/list= info/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mif" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


--000e0cd156a4e248220461212971-- --===============0651956521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0651956521==-- From mif-bounces@ietf.org Thu Jan 22 23:19:48 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319333A6A3F; Thu, 22 Jan 2009 23:19:48 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8913A6A3F for ; Thu, 22 Jan 2009 23:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLbrwVroOeFK for ; Thu, 22 Jan 2009 23:19:45 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id D31963A6941 for ; Thu, 22 Jan 2009 23:19:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4647728rvf.49 for ; Thu, 22 Jan 2009 23:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9P35kq+ooWdBabboyUeWQG7ybOVAtwLZgSfhiWXbXDc=; b=GnKA1wiy2Q0nWhWvjJ5JY0sOWnxnrzdg5OhCq48V31ol7gChp0a3QzV4T/qbVolQPr zKx1u7Nk62rFn3JmOwbpwgDkCJPRWibtG90pcTXXTc0o6r0oIqrCLRwspw6T3/mn/Lnc du2nanAiMY73i7BjcWDWjHguoeO39IvxIfHM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A5orNz2pPy+pIpbm4+fRDNKlOOcJNy3xuTAUk67tssUXyiNMUpkaUlcgvtK3NeBH9Q JpoKwVa96TsvXCH2KkQ0qJ/Nvn/FeIKJU4oogIvgY9g39Hus6Xrm//aImH48C03ww3g4 yrxuVKFxSv3QHfmZH6wui8CjUA1oSBZNJbIzU= MIME-Version: 1.0 Received: by 10.140.207.2 with SMTP id e2mr1145943rvg.65.1232695168414; Thu, 22 Jan 2009 23:19:28 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Fri, 23 Jan 2009 15:19:28 +0800 Message-ID: From: Tao Sun To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086163450==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0086163450== Content-Type: multipart/alternative; boundary=000e0cd25088a1360404612135e5 --000e0cd25088a1360404612135e5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Pierrick I guess that you point out the key issue here, normally, I guess the steps like this: 1) appliation goes to socket, 2) socket may need to consult connection manager 3) Connection manager need consult mobility manager, normally, step 3 is not necessary to do it. so step 2 is the result of what MIF is working out. thanks -Tao On Thu, Jan 22, 2009 at 5:14 PM, wrote: > Hi Peny, > > Please see inline comment. > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Peny > > Yang > > Envoy=E9 : jeudi 22 janvier 2009 03:07 > > =C0 : Jari Arkko > > Cc : mif > > Objet : Re: [mif] draft-blanchet > > > > Hi, Jari: > > > > Please check my lines: > > > > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko > wrote: > > > Again, there seems to be two issues. The first issue is having a poli= cy > > that > > > tells an application which addresses to use (and indirectly which > > interface > > > to use). The second issue is that if the policy comes, e.g., via DHCP > on > > a > > > per-interface basis, then we again have to reconcile the different > > policies > > > on a per-node basis. > > [Peny] Agree with you for the two issues. Another point in my mind may > > be a possible issue. When a peer tries to initiate flows with MIF > > node, we need some way to let the peer know the policies and follow > > the policies of MIF node. > > > > > My personal classification of problems in the multiple interface spac= e > > > includes the following: > > > > > > 1) Access selection, i.e., which network(s) to attach to using the > > physical > > > interface(s) that the host has. Already covered in RFC 5113. > > > > > > 2) Split DNS: If a host is attached to a number of different > interfaces, > > how > > > does it resolve a FQDN if more than one interface has provided a DNS > > server > > > address? > > > > > > 3) Configuration reconciliation: how do we merge and use DHCP and oth= er > > > configuration information in a node, when the information is received > on > > a > > > per-interface basis? > > > > > > 4) Routing: If a host is attached to a number of different interfaces= , > > where > > > does a particular IP packet go? > > > > > > 5) Address selection: If a host is attached to a number of different > > > interfaces, which addresses should be used for a particular applicati= on > > > flow? > > > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > > interfaces and runs some kind of a tunneling or mobility back to a ho= me > > > agent, which interface and addresses should be used for a particular > > packet? > > > Already covered in existing MEXT WG work items. > > [Peny] Agree with you from 1 to 6. > > > > > 7) Is there a way for the host and the network to communicate about > > their > > > policies regarding all of the above? > > [Peny] For 7, maybe we could make the way for host/PEER/network to > > communicate their policies. Besides, if the policies of MIF node can > > not be followed by the peer node, in this sense, we need a way to > > communicate about the policies among host/peer/network. > > > > > My understanding is that the proposed BOF would be looking at problem= s > 2, > > 3, > > > 4, 5, and 7. The others are covered elsewhere. > > [Peny] Some other points I have been thinking of: > > 1) MIF for IPv4 or IPv6 or Both? > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > > need to do the harmonization with other protocols? > > IMHO, MIF management should be independent from mobility protocol. > Actually, multi-interface management can be described in 4 steps: > > 1. Initiation: management of events which are expected to start > multi-interface management process (detection of new access network, loss= of > interface, user launch an application, etc....) > 2. Decision: The terminal selects the "best" interface to use. > 3. Preparation - e.g. acquisition of IP address on selected interface, AA= A, > and so on. > 4. Mobility execution - IP session continuity with MIP or derived > > IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or may > not, steer mobility protocol (step 4). If so, mobility protocol runs as > specified in RFCs (3775, 5213,...), without interaction with MIF mechanis= ms. > > Comments are welcome. > > Regards, > Pierrick > > > 3) There is the case that one interface is connected, but the route to > > internet is not available (Such as WiFi Portal). How does MIF handle > > this case? > > > > BRG > > Peny > > > > > > > Jari > > > > > > _______________________________________________ > > > mif mailing list > > > mif@ietf.org > > > https://www.ietf.org/mailman/listinfo/mif > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd25088a1360404612135e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick
 
I guess that you point out the key issue here,
normally, I guess the steps like this:
1) appliation goes to socket,
2) socket may need to consult connection manager
3) Connection manager need consult mobility manager,
 
normally, step 3 is not necessary to do it.
so step 2 is the result of what MIF is working out.
 
thanks
 
-Tao

On Thu, Jan 22, 2009 at 5:14 PM, <pierrick.seite@= orange-ftgroup.com> wrote:
Hi Peny,

Please see inlin= e comment.

Regards,
Pierrick

> -----Message d'origi= ne-----
> De : mif-bounces@ietf.org= [mailto:mif-bounces@ietf.org] De la part de Peny
> Yang
> Envoy=E9 : jeudi 22 janvie= r 2009 03:07
> =C0 : Jari Arkko
> Cc : mif
> Objet : Re: [= mif] draft-blanchet
>
> Hi, Jari:
>
> Please check m= y lines:
>
> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote: > > Again, there seems to be two issues. The first issue is having a = policy
> that
> > tells an application which addresses to us= e (and indirectly which
> interface
> > to use). The second = issue is that if the policy comes, e.g., via DHCP on
> a
> > per-interface basis, then we again have to reconcile th= e different
> policies
> > on a per-node basis.
> [Pen= y] Agree with you for the two issues. Another point in my mind may
> = be a possible issue. When a peer tries to initiate flows with MIF
> node, we need some way to let the peer know the policies and follow> the policies of MIF node.
>
> > My personal classifica= tion of problems in the multiple interface space
> > includes the = following:
> >
> > 1) Access selection, i.e., which network(s) to attac= h to using the
> physical
> > interface(s) that the host has= . Already covered in RFC 5113.
> >
> > 2) Split DNS: If a= host is attached to a number of different interfaces,
> how
> > does it resolve a FQDN if more than one interface has= provided a DNS
> server
> > address?
> >
> &= gt; 3) Configuration reconciliation: how do we merge and use DHCP and other=
> > configuration information in a node, when the information is rece= ived on
> a
> > per-interface basis?
> >
> &g= t; 4) Routing: If a host is attached to a number of different interfaces, > where
> > does a particular IP packet go?
> >
>= ; > 5) Address selection: If a host is attached to a number of different=
> > interfaces, which addresses should be used for a particular a= pplication
> > flow?
> >
> > 6) Tunnel multihoming: If a host = is attached to a number of different
> > interfaces and runs some = kind of a tunneling or mobility back to a home
> > agent, which in= terface and addresses should be used for a particular
> packet?
> > Already covered in existing MEXT WG work items.> [Peny] Agree with you from 1 to 6.
>
> > 7) Is there = a way for the host and the network to communicate about
> their
> > policies regarding all of the above?
> [Peny] For 7, maybe = we could make the way for host/PEER/network to
> communicate their po= licies. Besides, if the policies of MIF node can
> not be followed by= the peer node, in this sense, we need a way to
> communicate about the policies among host/peer/network.
>
>= ; > My understanding is that the proposed BOF would be looking at proble= ms 2,
> 3,
> > 4, 5, and 7. The others are covered elsewhere= .
> [Peny] Some other points I have been thinking of:
> 1) MIF for I= Pv4 or IPv6 or Both?
> 2)  Will MIF need to co-work with (P)MIP,= DSMIP, etc? If so, do we
> need to do the harmonization with other p= rotocols?

IMHO, MIF management should be independent from mobility pr= otocol. Actually, multi-interface management can be described in 4 steps:
1. Initiation: management of events which are expected to start multi= -interface management process (detection of new access network, loss of int= erface, user launch an application, etc....)
2. Decision: The terminal selects the "best" interface to use.3. Preparation - e.g. acquisition of IP address on selected interface, AAA= , and so on.
4. Mobility execution - IP session continuity with MIP or d= erived

IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or m= ay not, steer mobility protocol (step 4). If so, mobility protocol runs as = specified in RFCs (3775, 5213,...), without interaction with MIF mechanisms= .

Comments are welcome.

Regards,
Pierrick

> 3) There is the case that one interface is c= onnected, but the route to
> internet is not available (Such as WiFi = Portal).  How does MIF handle
> this case?
>
> BRG > Peny
>
>
> > Jari
> >
> > _____= __________________________________________
> > mif mailing list> > mif@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/mif
> >
> _______________________________________________
> m= if mailing list
> mif@ietf.org> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/l= istinfo/mif

--000e0cd25088a1360404612135e5-- --===============0086163450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0086163450==-- From mif-bounces@ietf.org Thu Jan 22 23:25:53 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641BA3A6A48; Thu, 22 Jan 2009 23:25:53 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB663A6A48 for ; Thu, 22 Jan 2009 23:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYti7frquxb3 for ; Thu, 22 Jan 2009 23:25:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 9D6A73A68F7 for ; Thu, 22 Jan 2009 23:25:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4649722rvf.49 for ; Thu, 22 Jan 2009 23:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8ypRPBdLhOnoLZ9+WULHrB+2CGdqTYCEg/Lp+J4hf2o=; b=GyoK4XkqVW4lJWFA+9vAH7cF1K2zNlpg25ENHydWEGO2mApwzGZoFqWK0bM8PjTIZk hJxvmr/zk8PtOgrf+oLhy+bG5uEwG6GXNe9bUDt8yE6vxZxrxv3HKI9qzn06Rk9pPYFk UrM1GGT+QHCYn1W5qcH05lY8qiesBQIonwrxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kIpNq02T1bn97vyRkyV85mRCvpspwkFlTl4s1+pNKuZFYdiOUN20lyd4YjEH16pFE/ 0gHCjzSYHjcPQ7LnvBRMK4VJHN6D9G3uEbYGfD5dkLNpnIjUNy6gDMKmvNECC6eLFrCP EFWH2RIzOF+cTIJ3vmgUMCxi6PljNjHOg7PHw= MIME-Version: 1.0 Received: by 10.141.4.3 with SMTP id g3mr2143073rvi.124.1232695533035; Thu, 22 Jan 2009 23:25:33 -0800 (PST) In-Reply-To: <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Fri, 23 Jan 2009 15:25:32 +0800 Message-ID: From: Tao Sun To: Peny Yang Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1859724267==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1859724267== Content-Type: multipart/alternative; boundary=000e0cd112325ce5d00461214be9 --000e0cd112325ce5d00461214be9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Peny, comments inline below On Thu, Jan 22, 2009 at 10:06 AM, Peny Yang wrote: > Hi, Jari: > > Please check my lines: > > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > > Again, there seems to be two issues. The first issue is having a policy > that > > tells an application which addresses to use (and indirectly which > interface > > to use). The second issue is that if the policy comes, e.g., via DHCP on > a > > per-interface basis, then we again have to reconcile the different > policies > > on a per-node basis. > [Peny] Agree with you for the two issues. Another point in my mind may > be a possible issue. When a peer tries to initiate flows with MIF > node, we need some way to let the peer know the policies and follow > the policies of MIF node. ==> let peer know the MIF node, it will break IP model of Internet or have to be involved in mobility protocol, so I would recommend MIF not working on that. > > > > My personal classification of problems in the multiple interface space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > physical > > interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different interfaces, > how > > does it resolve a FQDN if more than one interface has provided a DNS > server > > address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and other > > configuration information in a node, when the information is received on > a > > per-interface basis? > > > > 4) Routing: If a host is attached to a number of different interfaces, > where > > does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > interfaces and runs some kind of a tunneling or mobility back to a home > > agent, which interface and addresses should be used for a particular > packet? > > Already covered in existing MEXT WG work items. > [Peny] Agree with you from 1 to 6. > > > 7) Is there a way for the host and the network to communicate about their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. ==> it is possible to allow network to communiate the policy, but it will be diffcult to allow host and node to communicate with each other about policy, right? > > > > My understanding is that the proposed BOF would be looking at problems 2, > 3, > > 4, 5, and 7. The others are covered elsewhere. > [Peny] Some other points I have been thinking of: > 1) MIF for IPv4 or IPv6 or Both? ==> IPv4 might be diffculty in RFC 1918 scenario. but still can work in most cases. IPv6 would be better? > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? ==> I agree Pierrick's point here. > > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? ==> I guess that user should judge and decide how to handle this case. what do you think? thanks for the discussion -Tao > > > BRG > Peny > > > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd112325ce5d00461214be9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Peny,
 
comments inline below

On Thu, Jan 22, 2009 at 10:06 AM, Peny Yang <peng.yang.chn@= gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <<= a href=3D"mailto:jari.arkko@piuha.net">jari.arkko@piuha.net> wrote:<= br>> Again, there seems to be two issues. The first issue is having a po= licy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.
=3D=3D> let peer know the MIF node, it will break IP model of Inter= net
or have to be involved in mobility protocol, so I would recommend MIF = not working on that.
 


> My personal classification of problems in th= e multiple interface space
> includes the following:
>
> = 1) Access selection, i.e., which network(s) to attach to using the physical=
> interface(s) that the host has. Already covered in RFC 5113.
>> 2) Split DNS: If a host is attached to a number of different interfa= ces, how
> does it resolve a FQDN if more than one interface has prov= ided a DNS server
> address?
>
> 3) Configuration reconciliation: how do we me= rge and use DHCP and other
> configuration information in a node, whe= n the information is received on a
> per-interface basis?
>
> 4) Routing: If a host is attached to a number of different interfaces,= where
> does a particular IP packet go?
>
> 5) Address s= election: If a host is attached to a number of different
> interfaces= , which addresses should be used for a particular application
> flow?
>
> 6) Tunnel multihoming: If a host is attached to = a number of different
> interfaces and runs some kind of a tunneling = or mobility back to a home
> agent, which interface and addresses sho= uld be used for a particular packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree = with you from 1 to 6.

> 7) Is there a way for the host and the netwo= rk to communicate about their
> policies regarding all of the above?<= br>
[Peny] For 7, maybe we could make the way for host/PEER/network to=
communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.
=3D=3D> it is possible to allow network to communiate the policy, <= /div>
but it will be diffcult to allow host and node to communicate with eac= h other about policy, right?
 


> My understanding is that the proposed BOF wo= uld be looking at problems 2, 3,
> 4, 5, and 7. The others are covere= d elsewhere.
[Peny] Some other points I have been thinking of:
1) MIF for IPv4 or IPv6 or Both?
=3D=3D> IPv4 might be diffculty in RFC 1918 scenario.
but still can work in most cases.
IPv6 would be better?
 

2) &nbs= p;Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to= do the harmonization with other protocols?
=3D=3D> I agree Pierrick's point here.
 

3) Ther= e is the case that one interface is connected, but the route to
internet= is not available (Such as WiFi Portal).  How does MIF handle
this case?
=3D=3D> I guess that user should judge and decide how to handle thi= s case.
what do you think?
 
thanks for the discussion
 
-Tao
 
 


BRG=
Peny


> Jari
>
> ___________________= ____________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listi= nfo/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
https://www.ietf.org/m= ailman/listinfo/mif

--000e0cd112325ce5d00461214be9-- --===============1859724267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1859724267==-- From mif-bounces@ietf.org Thu Jan 22 23:38:37 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3C93A6820; Thu, 22 Jan 2009 23:38:37 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADB83A6A3F for ; Thu, 22 Jan 2009 23:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZLAhm43Bohy for ; Thu, 22 Jan 2009 23:38:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id CE3D93A6820 for ; Thu, 22 Jan 2009 23:38:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4653965rvf.49 for ; Thu, 22 Jan 2009 23:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OnyBxyxPmQi7qKfvsuRFrqdOlX9PPv5pweXnU0nqHrA=; b=NEdea4LzOkNTF1xJVX+UC7PaAy04uZ14sM03xQCteoSjIo0DhzgmyxZFjL1Cq9c6nf RBUNdYyn/DDPv7RvqRNo4DMpYVXWR2gWP1//wNihT6uvbRla/PPigm58BC5eI4SYucMT mLj68ik47gRQF3zGQ0IpefMU7LKhP8HFG/v8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r6GANTFpzWktSNdru9hhmy/vdQ64eyXtTeE3KLU3xEeJuASBMvxrIwM+3L5WoK3/Xu NrdSAG07leC0jgj4YesIdNNQK4Uu4wClHclb9USNXFRO17Ke+VaEhZ5i1yPGtHqtaKvd 4kBbhel3O4G7RPWicwBVgD9bQE70GYOuFtHMM= MIME-Version: 1.0 Received: by 10.140.125.19 with SMTP id x19mr3231162rvc.187.1232696293464; Thu, 22 Jan 2009 23:38:13 -0800 (PST) In-Reply-To: <4977AC28.2050702@piuha.net> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> Date: Fri, 23 Jan 2009 15:38:13 +0800 Message-ID: From: Tao Sun To: Jari Arkko , suntao@chinamobile.com Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1833182413==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1833182413== Content-Type: multipart/alternative; boundary=000e0cd22946b01a7e0461217846 --000e0cd22946b01a7e0461217846 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Marc and Jari, On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > I have comments on > http://tools.ietf.org/html/draft-blanchet-mif-problem-statement > > I had no major objections. A couple of points, however: > > In this document, the multi-homed host does not forward any packet >> between its interfaces. Therefore forwarding devices are out of >> scope of this document. >> >> > > You might consider adding a discussion about implications of weak/strong > host model here. > snip here how about this *Weak and Strong Host Model* There exists two different host model today, which are weak host model and strong host model, described in RFC 1122. The weak host model treats the destination and the source as a host rather than an interface, so the default gateway mechanism chooses only one connection as the default one. Reversely, the strong host model divides the host to several separated hosts logically, what means the flow can only use the specific interface. The problem is current host most operating system all apply weak host model on its network interface, so the host can not differ the flow to different interfaces, only the default gateway is applied. thanks -Tao --000e0cd22946b01a7e0461217846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Marc and Jari,

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.= net> wrote:
I have comments on http://tools.ietf.org/html/draft-blanchet-mif-problem-statement
I had no major objections. A couple of points, however:

In this document, the multi-home= d host does not forward any packet
between its interfaces.  Therefo= re forwarding devices are out of
scope of this document.
 

You might consider ad= ding a discussion about implications of weak/strong host model here.
 
snip here
 
how about this
 
Weak and Strong Host Model<= br>
   There exists two different host model today, which are = weak host
   model and strong host model, described in RFC 1122.  The weak host    model treats the destination and the source as a host rather t= han an
   interface, so the default gateway mechanism chooses = only one
   connection as the default one. Reversely, the stro= ng host model
   divides the host to several separated hosts l= ogically, what means the
   flow can only use the specific interface.

   = The problem is current host most operating system all apply weak host<= /div>
   model on its network interface, so the host can
 =   not differ the flow to different interfaces, only the default gatewa= y
   is applied.

thanks
 
-Tao
--000e0cd22946b01a7e0461217846-- --===============1833182413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1833182413==-- From mif-bounces@ietf.org Thu Jan 22 23:55:43 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CDC3A68F7; Thu, 22 Jan 2009 23:55:43 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50F93A68F7 for ; Thu, 22 Jan 2009 23:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=1.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4x8wGczaBZj for ; Thu, 22 Jan 2009 23:55:39 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F08033A68DC for ; Thu, 22 Jan 2009 23:55:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDW007DSZC848@szxga04-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 15:55:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDW00DJVZC8SC@szxga04-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 15:55:20 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDW00LHJZC8SE@szxml04-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 15:55:20 +0800 (CST) Date: Fri, 23 Jan 2009 15:55:17 +0800 From: Yungui Wang To: Hui Deng Message-id: <011301c97d2f$eeba9530$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0104401631==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0104401631== Content-type: multipart/alternative; boundary="Boundary_(ID_lPJxa24zh3Bri7XQ9ykrfQ)" This is a multi-part message in MIME format. --Boundary_(ID_lPJxa24zh3Bri7XQ9ykrfQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello Hui Sorry for late response. In my understanding, one issue of MIF is = interface selection (or named access selection). However, interface = selection of a MIF-node is serving for its up-layer app/flow. When one = link associated with one interface of MIF-node is down or congested, = interface re-selection is needed. That's one type of mobility of = app/flow between different interfaces I wanted to address.=20 Maybe IP address model is related to how to do. Please forget it.=20 B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: Yungui Wang=20 Cc: pierrick.seite@orange-ftgroup.com ; mif@ietf.org=20 Sent: Thursday, January 22, 2009 2:26 PM Subject: Re: [mif] mobility issues and general issues on mif Hi, Yungui, mif is targetting at multiple interface whatever it has how many ip = address on each of them. I guess that you are asking more IPv6 related question. What I feel what ever per interface or per IP address, how it is = related to mobility of application? we are not handling handover related issues. Thanks for the discussion. Regards, -Hui =20 2009/1/22 Yungui Wang Hello Hui One comments, whether is the IP address model to be investigated = within MIF? For example, there are different types of IP address model = for MIF-terminal, per IP address per IF, one IP address for multiple = IF(s), etc. If considered that, mobility of application/flow over IP = layer seems impliedly to be studied (e.g. in topic of IP route = changing).=20 B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: pierrick.seite@orange-ftgroup.com=20 Cc: mif@ietf.org=20 Sent: Wednesday, January 21, 2009 11:23 PM Subject: Re: [mif] mobility issues and general issues on mif Hi, pierrick,=20 Thanks for joining the disucssion, speaking for mobile operator is = quite helpful for mif's work, Your experience is appreicate, see reply inline below, 2009/1/20 Hi all, I've joined recently this ML and I believe discussed topics very = interesting (BTW thanks to MIF promoters for bringing these issues to = IETF). So, please let me jump into your discussion. Thanks again. Regarding difference between MIF and multihoming: it seems there = is confusion with mobility. AFAIU, MIF is only supposed to deal with = routing issue at the multi-interface MN side. The issue is to select the = "best" interface for each outgoing IP flow and, in MIF context, access = selection does not necessarily imply flow mobility with IP session = continuity between interfaces. Nevertheless, solution should work for = terminal with several active interfaces at the same time (multi-homed), = or for terminal with a single interface at a time. Am I correct? As you said here, flow mobility and IP session continuity is out = of scope at the moment. I cann't agree with any more about your left words. Regarding ANDSF issue, I agree with preceding emails: I think = access selection should rely on policy. There are a couple of selection = models but the simplest is the selection managed by the terminal and = based on local policies and measurement on the access link. The policies = may be provided/updated by a server via out-of-band mechanism or = on-demand (typically before selection) if policies include "dynamic" = recommendation (e.g. access xx is overload and forbidden to application = type yy). Now you can call the policy server ANDSF, or whatever you = want, it is just a generic functional entity in the architecture and = this entity is above all access networks. Note the access selection via = policy server meet MIF requirement as well as selection in inter-access = mobility situation. Most mobile terminal has implemented the policy based selection = models. Howver I would like to raise one case, sometime, if the network = congested, terminal couldn't visit policy server such as ANDSF, only = network side know what happen, they may re-arrange some traffic for = mobile terminal, I guess that this is been discussed in 3GPP SA2 side at = the moment.=20 Please do not hesitate to correct me if I misunderstood MIF = issues. thanks for the discussion. -Hui Regards, Pierrick > -----Message d'origine----- > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la = part de Peny > Yang > Envoy=E9 : lundi 19 janvier 2009 15:10 > =C0 : Kai Ju > Cc : mif@ietf.org > Objet : Re: [mif] mobility issues and general issues on mif > > Hi, Kai: > > The ANSDF solution is just a sample, because there is no one = type of > server > > which is > > defined to provide the policy in IETF until now. So let us = consider it > be > > general, which > > means it's one policy server that provides the routing = policy to UE when > UE > > is connecting > > it. > [Peny] Agree. 3GPP ANSDF could be a good reference when we = make the > MIF solutions. > > BRG > Peny > > > > >> > >> Hi, Peng and Kai, > >> > >> See reply inline below. thanks for the discussion. > >> 2009/1/19 Peny Yang > >>> > >>> Hi, Kai: > >>> Nice point. Please check the lines below: > >>> > >>> > As you said, there are multiple way to assign the = routing policy by > in > >>> > the > >>> > mobile access network. As viewed from the aspect of = terminal, I > think > >>> > its a > >>> > good idea that terminal can get its routing policy from = the ANDSF. > >>> [Peny] ANDSF may be one of the choices. But ANDSF just = follows the > >>> assumption of generic "one default link" IP model. So, in = 3GPP, even > >>> though ANDSF can help UE to select accesses and find the = route, UE can > >>> only choose one of the interfaces as a result. > >>> Personally, I'm not sure if it's a good way to rely on = ANDSF of 3GPP, > >>> since it's a specific definition in one SDO. > >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could = ANDSF work > for > >> 23.402 for non-3GPP access still a issue, it may need some = mechanism to > >> coordinate > >> between two type of access entwork.what do you think? > >> > >>> > >>> > We think a default policy can be used, when terminal = can't find > >>> > corresponding policy in the routing policy from the = ANDSF. The > default > >>> > policy can be sent by the network. > >>> [Peny] Could we give a chance to MN to change the policy = (like user > >>> preference) ? > >>> > >>> > On another hand, I am a little confused between MIF and = Multihoming, > >>> > would > >>> > you please help me to clarify the difference between = them? > >>> [Peny] I am also not clear yet. Just give some lines as a = seed for > >>> discussion. In my personal feeling, MIF is to change the = "one default > >>> link" feature of current generic IP model. Multi-homing is = to ensure > >>> the reachability and reliability of IP network. Well, in = multi-homing > >>> MN scenarios, multi-link-multi-address is also one case. = But, in this > >>> case, MN only can choose one link as default. > >>> Some other comments? > >> > >> To challenge one default link, it really takes time for mif = to consider > on > >> it, current first step in mif is to consider some straight = forward way > which > >> is simple to resolve some issues. > >> Regarding to multi-homing, I guess that it is more site = multi-homing. > >> For last multi-link-multi-address mn's scenario, it will be = one of MIF > >> scenario. > >> > >> thanks > >> > >> -Hui > >> > >>> > >>> BRG > >>> Peny > >> > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif -------------------------------------------------------------------------= - _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_lPJxa24zh3Bri7XQ9ykrfQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hello Hui
 
Sorry for late response. In my = understanding, one=20 issue of MIF is interface selection (or named access = selection). However,=20 interface selection of a MIF-node is serving for its up-layer=20 app/flow. When one link associated with one interface of = MIF-node is down=20 or congested, interface re-selection is needed. = That's one type=20 of mobility of app/flow between different interfaces I wanted to=20 address. 
Maybe IP address model is related to = how to do.=20 Please forget it.
 
B.R.
Yungui
 
----- Original Message -----
From:=20 Hui = Deng=20
Cc: pierrick.seite@orange-f= tgroup.com=20 ; mif@ietf.org
Sent: Thursday, January 22, = 2009 2:26=20 PM
Subject: Re: [mif] mobility = issues and=20 general issues on mif

Hi, Yungui,
 
mif is targetting at multiple interface whatever it has how many = ip=20 address on each of them.
I guess that you are asking more IPv6 related question.
 
What I feel what ever per interface or per IP address, how it is = related=20 to mobility of application?
we are not handling handover related issues.
 
Thanks for the discussion.
Regards,
 
-Hui


 
2009/1/22 Yungui Wang <w52006@huawei.com>
Hello Hui
 
One comments, whether is the = IP address=20 model to be investigated within MIF? For example, there are different types of IP address model = for=20 MIF-terminal, per IP address per = IF,=20 one IP address for multiple = IF(s), etc.=20 If considered that, mobility of=20 application/flow over IP layer seems impliedly to be studied (e.g. = in topic=20 of IP route changing).
 
B.R.
Yungui
 
----- Original Message ----- =
From: = Hui Deng
To: pierrick.seite@orange-ftgroup.com
Sent: Wednesday, January = 21, 2009=20 11:23 PM
Subject: Re: [mif] mobility = issues=20 and general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile = operator is=20 quite helpful for mif's work,
Your experience is appreicate, see reply inline = below,
2009/1/20 <pierrick.seite@orange-ftgroup.com>
Hi=20 all,

I've joined recently this ML and I believe discussed = topics=20 very interesting (BTW thanks to MIF promoters for bringing these = issues=20 to IETF). So, please let me jump into your = discussion.
Thanks again.
 

Regarding=20 difference between MIF and multihoming: it seems there is = confusion with=20 mobility. AFAIU, MIF is only supposed to deal with routing issue = at the=20 multi-interface MN side. The issue is to select the "best" = interface for=20 each outgoing IP flow and, in MIF context, access selection does = not=20 necessarily imply flow mobility with IP session continuity = between=20 interfaces. Nevertheless, solution should work for terminal with = several=20 active interfaces at the same time (multi-homed), or for = terminal with a=20 single interface at a time. Am I correct?
As you said here, flow mobility and IP session = continuity is out=20 of scope at the moment.
I cann't agree with any more about your left words.
 


Regarding=20 ANDSF issue, I agree with preceding emails: I think access = selection=20 should rely on policy. There are a couple of selection models = but the=20 simplest is the selection managed by the terminal and based on = local=20 policies and measurement on the access link. The policies may be = provided/updated by a server via out-of-band mechanism or = on-demand=20 (typically before selection) if policies include "dynamic"=20 recommendation (e.g. access xx is overload and forbidden to = application=20 type yy). Now you can call the policy server ANDSF, or whatever = you=20 want, it is just a generic functional entity in the architecture = and=20 this entity is above all access networks. Note the access = selection via=20 policy server meet MIF requirement as well as selection in = inter-access=20 mobility situation.
Most mobile terminal has implemented the policy based = selection=20 models.
Howver I would like to raise one case, sometime, if the = network=20 congested, terminal couldn't visit policy server such as ANDSF, = only=20 network side know what happen, they may re-arrange some traffic = for mobile=20 terminal, I guess that this is been discussed in 3GPP SA2 side at = the=20 moment.
 


Please=20 do not hesitate to correct me if I misunderstood MIF = issues.
thanks for the discussion.
 
-Hui


Regards,
Pierrick

>=20 -----Message d'origine-----
> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Peny
>=20 Yang
> Envoy=E9 : lundi 19 janvier 2009 15:10
> = =C0 :=20 Kai Ju
> Cc : mif@ietf.org
> Objet : Re: [mif] = mobility=20 issues and general issues on mif
>
> Hi, Kai:
> > The ANSDF solution is = just a=20 sample, because there is no one type of
> server
> = >=20 which is
> > defined to provide the policy in IETF = until now.=20 So let us consider it
> be
> > general, = which
>=20 > means it's one policy server that provides the routing = policy to UE=20 when
> UE
> > is connecting
> > = it.
>=20 [Peny] Agree. 3GPP ANSDF could be a good reference when we make=20 the
> MIF solutions.
>
> BRG
>=20 Peny
>
>
>
> >>
> >> = Hi, Peng=20 and Kai,
> >>
> >> See reply inline = below.=20 thanks for the discussion.
> >> 2009/1/19 Peny Yang = <peng.yang.chn@gmail.com>
>=20 >>>
> >>> Hi, Kai:
> >>> = Nice=20 point. Please check the lines below:
> = >>>
>=20 >>> > As you said, there are multiple way to assign = the=20 routing policy by
> in
> >>> > = the
>=20 >>> > mobile access network. As viewed from the = aspect of=20 terminal, I
> think
> >>> > its = a
>=20 >>> > good idea that terminal can get its routing = policy=20 from the ANDSF.
> >>> [Peny] ANDSF may be one of = the=20 choices. But ANDSF just follows the
> >>> = assumption of=20 generic "one default link" IP model. So, in 3GPP, even
>=20 >>> though ANDSF can help UE to select accesses and = find the=20 route, UE can
> >>> only choose one of the = interfaces as=20 a result.
> >>> Personally, I'm not sure if it's = a good=20 way to rely on ANDSF of 3GPP,
> >>> since it's a = specific=20 definition in one SDO.
> >>
> >> ANDSF = in 3GPP=20 23.401 do cover only 3GPP network, how could ANDSF work
>=20 for
> >> 23.402 for non-3GPP access still a issue, = it may=20 need some mechanism to
> >> coordinate
> = >>=20 between two type of access entwork.what do you think?
>=20 >>
> >>>
> >>> > We think = a=20 default policy can be used,  when terminal can't = find
>=20 >>> > corresponding policy in the routing policy = from the=20 ANDSF. The
> default
> >>> > policy can = be sent=20 by the network.
> >>> [Peny] Could we give a = chance to MN=20 to change the policy (like user
> >>> preference) = ?
> >>>
> >>> > On another = hand, I am a=20 little confused between MIF and Multihoming,
> = >>> >=20 would
> >>> > you please help me to clarify = the=20 difference between them?
> >>> [Peny] I am also = not clear=20 yet. Just give some lines as a seed for
> >>> = discussion.=20 In my personal feeling, MIF is to change the "one = default
>=20 >>> link" feature of current generic IP model. = Multi-homing is=20 to ensure
> >>> the reachability and reliability = of IP=20 network. Well, in multi-homing
> >>> MN = scenarios,=20 multi-link-multi-address is also one case. But, in this
>=20 >>> case, MN only can choose one link as = default.
>=20 >>> Some other comments?
> >>
> = >> To=20 challenge one default link, it really takes time for mif to=20 consider
> on
> >> it, current first step in = mif is to=20 consider some straight forward way
> which
> = >> is=20 simple to resolve some issues.
> >> Regarding to=20 multi-homing, I guess that it is more site multi-homing.
> = >> For last multi-link-multi-address mn's scenario, it = will be one=20 of MIF
> >> scenario.
> >>
> = >>=20 thanks
> >>
> >> -Hui
> = >>
>=20 >>>
> >>> BRG
> >>> = Peny
>=20 >>
> >
> >
> = _______________________________________________
> mif=20 mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
________= _______________________________________
mif=20 mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

_______________________________________________
mif = mailing=20 list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

=

2009/1/19 Hong Yong-Geun <<= a href=3D"mailto:yghong@etri.re.kr">yghong@etri.re.kr>

Hi..Hui..=

 

Thank you= for your interest.

 

I think t= hat the discussion of multiple interfaces issues which is not related to Mo= bile IPv6/NEMO in MEXT WG
is not useful because ME= XT WG is focusing on the extension of Mobile IPv6/NEMO.
The intension of my previous two drafts is not extending Mobile IPv6/NEMO.<= /span>

 

Instead, = if you wonder the response of Monami6 WG for my previous two drafts, you ca= n refer the 64th monami6 WG
meeting report when I presented.

h= ttp://www.ietf.org/proceedings/05nov/monami6.html   (6th presentation)

 

Thanks..<= /span>

 

Yong-Geun= ..

 

From: Hui Deng [mailto:denghui02@gmail.com]
Sent: Monday, January 19, 2009 4:38 PM
To: =C8=AB=BF=EB=B1=D9=20


Cc: mif@ietf.org=
Subject: Re: [mif] mobility issues and general issues on mif

 

Hi, Hong,

 

Could you make a short summary , cross= -post to the mext/mif, and cc to chairs, and

see their = comments?

Many thanks

 

-Hui

2009/1/15 Hong Yong-Geun <yghong@etri.re.kr>

  

Hi..Hui..

 

No, I didn't discuss with mext wg= . I presented and discussed with monami6 wg at 64th IETF meeti= ng.

And it was not adopted in monami6 wg because it wa= s not in the scope of monami6 wg.

 

Best regards.

 

Yong-Geun..

 

F= rom: Hui Deng [mailto:denghui02@gmail.com]
Sent: Thursday, January 15, 2009 3:47 PM
To: =C8=AB=BF=EB=B1=D9

 

already had a discussion with mext wg, they are not adopting this work?

 

-Hui

2009= /1/14 Hong Yong-Geun <yghong@etri.re.kr>

  

Hi..Hui..

 

Thank you for comments. See below inline reply.

 

Best regards.

 

Yong-Geun..

 

F= rom: Hui Deng [mailto:denghui02@gmail.com]
Sent: Wednesday, January 14, 2009 7:20 AM
To: =C8=AB=BF=EB=B1=D9
Cc: mif@ietf.org
Subject: Re: [mif] mobility issues and general issues on mif<= /span>

 

Hi, = Hong Yong,

 

I re= ad through your two drafts, understand you are talking the issue without Monami

?<= span>  Yes<= /span>, you are correct.
I want to solve the multiple interface problems without modifying Mobile IP= v6/NEMO code.
(In Monami6, multiple interface problems (which are related to mobility issues, such as multiple CoA, multiple HoA, etc., ) are resolving by modifying = Mobile IPv6/NEMO protocol)


= it seems Mobile Ipv6 internal also has similar issue with us i= f I understand it correctly,

?<= span>  Yes<= /span>, because Mobile IPv6 is based on the basic operation= of IPv6, Mobile IPv6 internal
has similar issues of mif. So, I think that it is valuable to = separate more general issues from
multiple interface issues= which are directly related to Mobile IPv6/NEMO.

 

In t= his case I would like to encourage you to propose this issue to our work, i= f allowed,

mightbe doable within our scope,

?<= span>  Than= ks. It is my pleasure..

 

thanks

 

-Hui

2009= /1/7 Hong Yong-Geun <yghong@etri.re.kr>

Hi. = mif..

Let me join this discussion.

It is very in= teresting to see mif.

As Hui Deng says, I understand th= at mif has different approach
from other WG such as MEXT and monami6 WG, etc.

In MEXT= , multiple interfaces issues are related to Mobile IP, NEMO,..=
In mif, multiple interfaces issues are different from those of MEXT. So, in mif, it is better to find more general issues which are not related = to Mobile IP.

I think that M.Blanchet's "Multi= ple Interfaces Problem Statement" draft is
a good star= ting point to discuss general issues on mif.

I would like to introduce another related drafts which I p= resented at monami6 WG at 64th IETF meeting.

 - Analysis of multiple interfaces in a= Mobile Node(draft-hong-multipleif-mn-pb-statement-00)
  http://tools.ietf.org/d= raft/draft-hong-multipleif-mn-pb-statement/draft-hong-multipleif-mn-pb-stat= ement-00.txt

 - Virtual n= etwork interface for multiple interfaces in a Mobile node using Mobile IPv6=
   (draft-hong-virtualif-mn-mipv6-00)
  http://tools.ietf.org/draft/draft-hong-= virtualif-mn-mipv6/draft-hong-virtualif-mn-mipv6-00.txt


In the section 2.2 (General Network Issues) in the first draft,
= there are general network issues due to multiple interfaces.
Including these drafts, I hope to encourage this discussion

Yong-Geun.


_____________________________________________= __
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

 

=

=BF=C0=B7=F9! =C6=C4=C0=CF =C0=CC=B8=A7=C0=CC =C1=F6=C1=A4=B5= =C7=BE=EE =C0=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.

 

=

=BF=C0=B7=F9! =C6=C4=C0=CF =C0=CC=B8=A7= =C0=CC =C1=F6=C1=A4=B5=C7=BE=EE =C0=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.

 


--Boundary_(ID_lPJxa24zh3Bri7XQ9ykrfQ)-- --===============0104401631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0104401631==-- From mif-bounces@ietf.org Fri Jan 23 00:32:44 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAAC3A6920; Fri, 23 Jan 2009 00:32:44 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF903A6920 for ; Fri, 23 Jan 2009 00:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozrA+pB-d2IJ for ; Fri, 23 Jan 2009 00:32:41 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 954D53A67FB for ; Fri, 23 Jan 2009 00:32:41 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so2692960wag.5 for ; Fri, 23 Jan 2009 00:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cqmJx4qkVeWqhynw0BpnNF0vU00gmKJgfshRUjfW1kM=; b=f1Nay6bXx7BW5ei3iIUb0cfC2/vxOBAUaHddctpMGRB1wM1tMKC8afJv4czQ0yXwU3 IAbI8qKxnzD8A+KwCtKthSDMXtJgzmr7p1ZMYpgZ3GOaytqlh7cjaW2Kk/8Ocla/nSGO V8zQZbbzNBLJj0XTwhiz2UdKx+0Vd2wIFLuUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rLtMiXwlKk7aPNocXWi25mnEEpUzmwg4c8hOdJDwMsgmDra/asqhYl0mdgNbLt7Ezq 4BKmqQgZte9kp3lSHMRj4ZXVt0ZYblOrjAj7/GaNnnvM+9eYmFdb9CAosDf1DaoMvaZ+ 7zAH3A8/rR4FJekkH77O+itvIDQgYdf3bSqBo= MIME-Version: 1.0 Received: by 10.115.92.2 with SMTP id u2mr2167973wal.137.1232699543824; Fri, 23 Jan 2009 00:32:23 -0800 (PST) In-Reply-To: <011301c97d2f$eeba9530$150ca40a@china.huawei.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> Date: Fri, 23 Jan 2009 16:32:23 +0800 Message-ID: <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> From: Hui Deng To: Yungui Wang Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1671459358==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1671459358== Content-Type: multipart/alternative; boundary=00163646c5a46cab330461223a2f --00163646c5a46cab330461223a2f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Yungui, Excuse me for misunderstanding your point, reply inline below. 2009/1/23 Yungui Wang > Hello Hui > > Sorry for late response. In my understanding, one issue of MIF is interfa= ce > selection (or named access selection). However, interface selection of a > MIF-node is serving for its up-layer app/flow. > some mobile phone can do it, but normally, like PC application don't do it, it is up to network socket to choose source address, then interface is automatically selected. > When one link associated with one interface of MIF-node is down or > congested, interface re-selection is needed. That's one type of mobility = of > app/flow between different interfaces I wanted to address. > If one interface is down or congested, then application will be down as well, this socket will close as well, and you would like to move some application, then you have to restart to do it. thanks for the discussion. -Hui > Maybe IP address model is related to how to do. Please forget it. > > B.R. > Yungui > > > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com ; mif@ietf.org > *Sent:* Thursday, January 22, 2009 2:26 PM > *Subject:* Re: [mif] mobility issues and general issues on mif > > Hi, Yungui, > > mif is targetting at multiple interface whatever it has how many ip addre= ss > on each of them. > I guess that you are asking more IPv6 related question. > > What I feel what ever per interface or per IP address, how it is related = to > mobility of application? > we are not handling handover related issues. > > Thanks for the discussion. > Regards, > > -Hui > > > > 2009/1/22 Yungui Wang > >> Hello Hui >> >> One comments, whether is the IP address model to be investigated within >> MIF? For example, there are different types of IP address model for >> MIF-terminal, per IP address per IF, one IP address for multiple IF(s), >> etc. If considered that, mobility of application/flow over IP layer seem= s >> impliedly to be studied (e.g. in topic of IP route changing). >> >> B.R. >> Yungui >> >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* pierrick.seite@orange-ftgroup.com >> *Cc:* mif@ietf.org >> *Sent:* Wednesday, January 21, 2009 11:23 PM >> *Subject:* Re: [mif] mobility issues and general issues on mif >> >> Hi, pierrick, >> >> Thanks for joining the disucssion, speaking for mobile operator is quite >> helpful for mif's work, >> Your experience is appreicate, see reply inline below, >> 2009/1/20 >> >>> Hi all, >>> >>> I've joined recently this ML and I believe discussed topics very >>> interesting (BTW thanks to MIF promoters for bringing these issues to I= ETF). >>> So, please let me jump into your discussion. >> >> Thanks again. >> >> >>> >>> Regarding difference between MIF and multihoming: it seems there is >>> confusion with mobility. AFAIU, MIF is only supposed to deal with routi= ng >>> issue at the multi-interface MN side. The issue is to select the "best" >>> interface for each outgoing IP flow and, in MIF context, access selecti= on >>> does not necessarily imply flow mobility with IP session continuity bet= ween >>> interfaces. Nevertheless, solution should work for terminal with severa= l >>> active interfaces at the same time (multi-homed), or for terminal with = a >>> single interface at a time. Am I correct? >> >> As you said here, flow mobility and IP session continuity is out of scop= e >> at the moment. >> I cann't agree with any more about your left words. >> >> >>> >>> >>> Regarding ANDSF issue, I agree with preceding emails: I think access >>> selection should rely on policy. There are a couple of selection models= but >>> the simplest is the selection managed by the terminal and based on loca= l >>> policies and measurement on the access link. The policies may be >>> provided/updated by a server via out-of-band mechanism or on-demand >>> (typically before selection) if policies include "dynamic" recommendati= on >>> (e.g. access xx is overload and forbidden to application type yy). Now = you >>> can call the policy server ANDSF, or whatever you want, it is just a ge= neric >>> functional entity in the architecture and this entity is above all acce= ss >>> networks. Note the access selection via policy server meet MIF requirem= ent >>> as well as selection in inter-access mobility situation. >> >> Most mobile terminal has implemented the policy based selection models. >> Howver I would like to raise one case, sometime, if the network congeste= d, >> terminal couldn't visit policy server such as ANDSF, only network side k= now >> what happen, they may re-arrange some traffic for mobile terminal, I gue= ss >> that this is been discussed in 3GPP SA2 side at the moment. >> >> >>> >>> >>> Please do not hesitate to correct me if I misunderstood MIF issues. >> >> thanks for the discussion. >> >> -Hui >> >>> >>> >>> Regards, >>> Pierrick >>> >>> > -----Message d'origine----- >>> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >>> Peny >>> > Yang >>> > Envoy=E9 : lundi 19 janvier 2009 15:10 >>> > =C0 : Kai Ju >>> > Cc : mif@ietf.org >>> > Objet : Re: [mif] mobility issues and general issues on mif >>> > >>> > Hi, Kai: >>> > > The ANSDF solution is just a sample, because there is no one type o= f >>> > server >>> > > which is >>> > > defined to provide the policy in IETF until now. So let us consider >>> it >>> > be >>> > > general, which >>> > > means it's one policy server that provides the routing policy to UE >>> when >>> > UE >>> > > is connecting >>> > > it. >>> > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the >>> > MIF solutions. >>> > >>> > BRG >>> > Peny >>> > >>> > >>> > >>> > >> >>> > >> Hi, Peng and Kai, >>> > >> >>> > >> See reply inline below. thanks for the discussion. >>> > >> 2009/1/19 Peny Yang >>> > >>> >>> > >>> Hi, Kai: >>> > >>> Nice point. Please check the lines below: >>> > >>> >>> > >>> > As you said, there are multiple way to assign the routing polic= y >>> by >>> > in >>> > >>> > the >>> > >>> > mobile access network. As viewed from the aspect of terminal, I >>> > think >>> > >>> > its a >>> > >>> > good idea that terminal can get its routing policy from the >>> ANDSF. >>> > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows th= e >>> > >>> assumption of generic "one default link" IP model. So, in 3GPP, >>> even >>> > >>> though ANDSF can help UE to select accesses and find the route, U= E >>> can >>> > >>> only choose one of the interfaces as a result. >>> > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of >>> 3GPP, >>> > >>> since it's a specific definition in one SDO. >>> > >> >>> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF >>> work >>> > for >>> > >> 23.402 for non-3GPP access still a issue, it may need some mechani= sm >>> to >>> > >> coordinate >>> > >> between two type of access entwork.what do you think? >>> > >> >>> > >>> >>> > >>> > We think a default policy can be used, when terminal can't fin= d >>> > >>> > corresponding policy in the routing policy from the ANDSF. The >>> > default >>> > >>> > policy can be sent by the network. >>> > >>> [Peny] Could we give a chance to MN to change the policy (like us= er >>> > >>> preference) ? >>> > >>> >>> > >>> > On another hand, I am a little confused between MIF and >>> Multihoming, >>> > >>> > would >>> > >>> > you please help me to clarify the difference between them? >>> > >>> [Peny] I am also not clear yet. Just give some lines as a seed fo= r >>> > >>> discussion. In my personal feeling, MIF is to change the "one >>> default >>> > >>> link" feature of current generic IP model. Multi-homing is to >>> ensure >>> > >>> the reachability and reliability of IP network. Well, in >>> multi-homing >>> > >>> MN scenarios, multi-link-multi-address is also one case. But, in >>> this >>> > >>> case, MN only can choose one link as default. >>> > >>> Some other comments? >>> > >> >>> > >> To challenge one default link, it really takes time for mif to >>> consider >>> > on >>> > >> it, current first step in mif is to consider some straight forward >>> way >>> > which >>> > >> is simple to resolve some issues. >>> > >> Regarding to multi-homing, I guess that it is more site >>> multi-homing. >>> > >> For last multi-link-multi-address mn's scenario, it will be one of >>> MIF >>> > >> scenario. >>> > >> >>> > >> thanks >>> > >> >>> > >> -Hui >>> > >> >>> > >>> >>> > >>> BRG >>> > >>> Peny >>> > >> >>> > > >>> > > >>> > _______________________________________________ >>> > mif mailing list >>> > mif@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mif >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> >> ------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --00163646c5a46cab330461223a2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, Yungui,
 
Excuse me for misunderstanding your point,
reply inline below.

2009/1/23 Yungui Wang <w52006@huawei.com>
Hello Hui
 
Sorry for late response. In my underst= anding, one issue of MIF is interface selection (or named access selection)= . However, interface selection of a MIF-node is serving for = its up-layer app/flow.
some mobile phone can do it, but normally, like PC application don'= ;t do it, it is up to network
socket to choose source address, then interface is automatically selec= ted.
 
When one link ass= ociated with one interface of MIF-node is down or congested, interface=  re-selection is needed. That's one type of mobilit= y of app/flow between different interfaces I wanted to address. 
If one interface is down or congested, then application will be down a= s well, this socket will close as well, and you would like to move some app= lication, then you have to restart to do it.
 
thanks for the discussion.
 
-Hui
Maybe IP address model is related to h= ow to do. Please forget it.
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Thursday, January 22, 2009 2:2= 6 PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hi, Yungui,
 
mif is targetting at multiple interface whatever it has how many ip ad= dress on each of them.
I guess that you are asking more IPv6 related question.
 
What I feel what ever per interface or per IP address, how it is relat= ed to mobility of application?
we are not handling handover related issues.
 
Thanks for the discussion.
Regards,
 
-Hui


 
2009/1/22 Yungui Wang <w52006@huawei.com>= ;
Hello Hui
 
One comments, whether is the IP a= ddress model to be investigated within MIF? For example, there are different types of IP address= model for MIF-terminal, per IP addr= ess per IF, one IP address for = multiple IF(s), etc. If considered t= hat, mobility of application/flow over IP layer seems impliedly to be studi= ed (e.g. in topic of IP route changing).
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Wednesday, January 21, 2009 11= :23 PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile operator is qui= te helpful for mif's work,
Your experience is appreicate, see reply inline below,
2009/1/20 <pierrick.seite@orang= e-ftgroup.com>
Hi all,

I've joined r= ecently this ML and I believe discussed topics very interesting (BTW thanks= to MIF promoters for bringing these issues to IETF). So, please let me jum= p into your discussion.
Thanks again.
 

Regarding difference between= MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF= is only supposed to deal with routing issue at the multi-interface MN side= . The issue is to select the "best" interface for each outgoing I= P flow and, in MIF context, access selection does not necessarily imply flo= w mobility with IP session continuity between interfaces. Nevertheless, sol= ution should work for terminal with several active interfaces at the same t= ime (multi-homed), or for terminal with a single interface at a time. Am I = correct?
As you said here, flow mobility and IP session continuity is out = of scope at the moment.
I cann't agree with any more about your left words.
 


Regarding A= NDSF issue, I agree with preceding emails: I think access selection should = rely on policy. There are a couple of selection models but the simplest is = the selection managed by the terminal and based on local policies and measu= rement on the access link. The policies may be provided/updated by a server= via out-of-band mechanism or on-demand (typically before selection) if pol= icies include "dynamic" recommendation (e.g. access xx is overloa= d and forbidden to application type yy). Now you can call the policy server= ANDSF, or whatever you want, it is just a generic functional entity in the= architecture and this entity is above all access networks. Note the access= selection via policy server meet MIF requirement as well as selection in i= nter-access mobility situation.
Most mobile terminal has implemented the policy based selection models= .
Howver I would like to raise one case, sometime, if the network conges= ted, terminal couldn't visit policy server such as ANDSF, only network = side know what happen, they may re-arrange some traffic for mobile terminal= , I guess that this is been discussed in 3GPP SA2 side at the moment.
 


Please do n= ot hesitate to correct me if I misunderstood MIF issues.
thanks for the discussion.
 
-Hui


Regards,Pierrick

> -----Message d'origine-----
> De : mif-bounces@ietf.org= [mailto:mif-= bounces@ietf.org] De la part de Peny
> Yang
> Envoy=E9 : lundi 19 janvier 2009 15:10
> =C0&n= bsp;: Kai Ju
> Cc : mif@ietf.org
> Objet : Re: [mif] mobility issues and g= eneral issues on mif
>
> Hi, Kai:
> > The ANSDF solution is just a sample= , because there is no one type of
> server
> > which is
&= gt; > defined to provide the policy in IETF until now. So let us conside= r it
> be
> > general, which
> > means it's one policy = server that provides the routing policy to UE when
> UE
> > = is connecting
> > it.
> [Peny] Agree. 3GPP ANSDF could be a = good reference when we make the
> MIF solutions.
>
> BRG
> Peny
>
>
>= ;
> >>
> >> Hi, Peng and Kai,
> >>
&= gt; >> See reply inline below. thanks for the discussion.
> >= ;> 2009/1/19 Peny Yang <peng.yang.chn@gmail.com>
> >>>
> >>> Hi, Kai:
> >>> Nice p= oint. Please check the lines below:
> >>>
> >>&g= t; > As you said, there are multiple way to assign the routing policy by=
> in
> >>> > the
> >>> > mobile acce= ss network. As viewed from the aspect of terminal, I
> think
> = >>> > its a
> >>> > good idea that terminal c= an get its routing policy from the ANDSF.
> >>> [Peny] ANDSF may be one of the choices. But ANDSF just fo= llows the
> >>> assumption of generic "one default link= " IP model. So, in 3GPP, even
> >>> though ANDSF can he= lp UE to select accesses and find the route, UE can
> >>> only choose one of the interfaces as a result.
> &g= t;>> Personally, I'm not sure if it's a good way to rely on A= NDSF of 3GPP,
> >>> since it's a specific definition in = one SDO.
> >>
> >> ANDSF in 3GPP 23.401 do cover only 3GPP netw= ork, how could ANDSF work
> for
> >> 23.402 for non-3GPP = access still a issue, it may need some mechanism to
> >> coordi= nate
> >> between two type of access entwork.what do you think?
>= >>
> >>>
> >>> > We think a default= policy can be used,  when terminal can't find
> >>>= ; > corresponding policy in the routing policy from the ANDSF. The
> default
> >>> > policy can be sent by the network.> >>> [Peny] Could we give a chance to MN to change the polic= y (like user
> >>> preference) ?
> >>>
> >>> > On another hand, I am a little confused between MIF = and Multihoming,
> >>> > would
> >>> > = you please help me to clarify the difference between them?
> >>= > [Peny] I am also not clear yet. Just give some lines as a seed for
> >>> discussion. In my personal feeling, MIF is to change the = "one default
> >>> link" feature of current generi= c IP model. Multi-homing is to ensure
> >>> the reachability= and reliability of IP network. Well, in multi-homing
> >>> MN scenarios, multi-link-multi-address is also one case. = But, in this
> >>> case, MN only can choose one link as defa= ult.
> >>> Some other comments?
> >>
> >= ;> To challenge one default link, it really takes time for mif to consid= er
> on
> >> it, current first step in mif is to consider some = straight forward way
> which
> >> is simple to resolve so= me issues.
> >> Regarding to multi-homing, I guess that it is m= ore site multi-homing.
> >> For last multi-link-multi-address mn's scenario, it will = be one of MIF
> >> scenario.
> >>
> >> = thanks
> >>
> >> -Hui
> >>
> >= >>
> >>> BRG
> >>> Peny
> >>
> &g= t;
> >
> _______________________________________________
> mif maili= ng list
> mif@ietf.= org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing list<= br>mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif



--00163646c5a46cab330461223a2f-- --===============1671459358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1671459358==-- From mif-bounces@ietf.org Fri Jan 23 01:30:24 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BB33A6A41; Fri, 23 Jan 2009 01:30:24 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C493A6A29 for ; Fri, 23 Jan 2009 01:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPEyH8VcYn6r for ; Fri, 23 Jan 2009 01:30:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 69B463A6A41 for ; Fri, 23 Jan 2009 01:30:12 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDX0049S3PKH5@szxga03-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 17:29:45 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDX008ZC3PKTJ@szxga03-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 17:29:44 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDX0014O3PKIH@szxml05-in.huawei.com> for mif@ietf.org; Fri, 23 Jan 2009 17:29:44 +0800 (CST) Date: Fri, 23 Jan 2009 17:29:43 +0800 From: Yungui Wang To: Hui Deng Message-id: <000d01c97d3d$203633f0$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0553591479==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0553591479== Content-type: multipart/alternative; boundary="Boundary_(ID_ZzuHkfLq9UQ9LDAxaMKQIg)" This is a multi-part message in MIME format. --Boundary_(ID_ZzuHkfLq9UQ9LDAxaMKQIg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hello, Hui Agree with your statement. However, it (the app/flow has to be = restarted when interface-handoff happens) is actually an app/flow = mobility issue related to multiple interfaces. Thus, it seems the = working item MIF is the just place to resolve it. Hope it make sense. = :_) B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: Yungui Wang=20 Cc: pierrick.seite@orange-ftgroup.com ; mif@ietf.org=20 Sent: Friday, January 23, 2009 4:32 PM Subject: Re: [mif] mobility issues and general issues on mif Hello, Yungui, Excuse me for misunderstanding your point,=20 reply inline below. 2009/1/23 Yungui Wang Hello Hui Sorry for late response. In my understanding, one issue of MIF is = interface selection (or named access selection). However, interface = selection of a MIF-node is serving for its up-layer app/flow.=20 some mobile phone can do it, but normally, like PC application don't = do it, it is up to network socket to choose source address, then interface is automatically = selected. When one link associated with one interface of MIF-node is down or = congested, interface re-selection is needed. That's one type of mobility = of app/flow between different interfaces I wanted to address.=20 If one interface is down or congested, then application will be down = as well, this socket will close as well, and you would like to move some = application, then you have to restart to do it. thanks for the discussion. -Hui Maybe IP address model is related to how to do. Please forget it.=20 B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: Yungui Wang=20 Cc: pierrick.seite@orange-ftgroup.com ; mif@ietf.org=20 Sent: Thursday, January 22, 2009 2:26 PM Subject: Re: [mif] mobility issues and general issues on mif Hi, Yungui, mif is targetting at multiple interface whatever it has how many = ip address on each of them. I guess that you are asking more IPv6 related question. What I feel what ever per interface or per IP address, how it is = related to mobility of application? we are not handling handover related issues. Thanks for the discussion. Regards, -Hui =20 2009/1/22 Yungui Wang Hello Hui One comments, whether is the IP address model to be investigated = within MIF? For example, there are different types of IP address model = for MIF-terminal, per IP address per IF, one IP address for multiple = IF(s), etc. If considered that, mobility of application/flow over IP = layer seems impliedly to be studied (e.g. in topic of IP route = changing).=20 B.R. Yungui ----- Original Message -----=20 From: Hui Deng=20 To: pierrick.seite@orange-ftgroup.com=20 Cc: mif@ietf.org=20 Sent: Wednesday, January 21, 2009 11:23 PM Subject: Re: [mif] mobility issues and general issues on mif Hi, pierrick,=20 Thanks for joining the disucssion, speaking for mobile = operator is quite helpful for mif's work, Your experience is appreicate, see reply inline below, 2009/1/20 Hi all, I've joined recently this ML and I believe discussed topics = very interesting (BTW thanks to MIF promoters for bringing these issues = to IETF). So, please let me jump into your discussion. Thanks again. Regarding difference between MIF and multihoming: it seems = there is confusion with mobility. AFAIU, MIF is only supposed to deal = with routing issue at the multi-interface MN side. The issue is to = select the "best" interface for each outgoing IP flow and, in MIF = context, access selection does not necessarily imply flow mobility with = IP session continuity between interfaces. Nevertheless, solution should = work for terminal with several active interfaces at the same time = (multi-homed), or for terminal with a single interface at a time. Am I = correct? As you said here, flow mobility and IP session continuity is = out of scope at the moment. I cann't agree with any more about your left words. Regarding ANDSF issue, I agree with preceding emails: I = think access selection should rely on policy. There are a couple of = selection models but the simplest is the selection managed by the = terminal and based on local policies and measurement on the access link. = The policies may be provided/updated by a server via out-of-band = mechanism or on-demand (typically before selection) if policies include = "dynamic" recommendation (e.g. access xx is overload and forbidden to = application type yy). Now you can call the policy server ANDSF, or = whatever you want, it is just a generic functional entity in the = architecture and this entity is above all access networks. Note the = access selection via policy server meet MIF requirement as well as = selection in inter-access mobility situation. Most mobile terminal has implemented the policy based = selection models. Howver I would like to raise one case, sometime, if the = network congested, terminal couldn't visit policy server such as ANDSF, = only network side know what happen, they may re-arrange some traffic for = mobile terminal, I guess that this is been discussed in 3GPP SA2 side at = the moment.=20 Please do not hesitate to correct me if I misunderstood MIF = issues. thanks for the discussion. -Hui Regards, Pierrick > -----Message d'origine----- > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De = la part de Peny > Yang > Envoy=E9 : lundi 19 janvier 2009 15:10 > =C0 : Kai Ju > Cc : mif@ietf.org > Objet : Re: [mif] mobility issues and general issues on = mif > > Hi, Kai: > > The ANSDF solution is just a sample, because there is no = one type of > server > > which is > > defined to provide the policy in IETF until now. So let = us consider it > be > > general, which > > means it's one policy server that provides the routing = policy to UE when > UE > > is connecting > > it. > [Peny] Agree. 3GPP ANSDF could be a good reference when we = make the > MIF solutions. > > BRG > Peny > > > > >> > >> Hi, Peng and Kai, > >> > >> See reply inline below. thanks for the discussion. > >> 2009/1/19 Peny Yang > >>> > >>> Hi, Kai: > >>> Nice point. Please check the lines below: > >>> > >>> > As you said, there are multiple way to assign the = routing policy by > in > >>> > the > >>> > mobile access network. As viewed from the aspect of = terminal, I > think > >>> > its a > >>> > good idea that terminal can get its routing policy = from the ANDSF. > >>> [Peny] ANDSF may be one of the choices. But ANDSF just = follows the > >>> assumption of generic "one default link" IP model. So, = in 3GPP, even > >>> though ANDSF can help UE to select accesses and find = the route, UE can > >>> only choose one of the interfaces as a result. > >>> Personally, I'm not sure if it's a good way to rely on = ANDSF of 3GPP, > >>> since it's a specific definition in one SDO. > >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how = could ANDSF work > for > >> 23.402 for non-3GPP access still a issue, it may need = some mechanism to > >> coordinate > >> between two type of access entwork.what do you think? > >> > >>> > >>> > We think a default policy can be used, when = terminal can't find > >>> > corresponding policy in the routing policy from the = ANDSF. The > default > >>> > policy can be sent by the network. > >>> [Peny] Could we give a chance to MN to change the = policy (like user > >>> preference) ? > >>> > >>> > On another hand, I am a little confused between MIF = and Multihoming, > >>> > would > >>> > you please help me to clarify the difference between = them? > >>> [Peny] I am also not clear yet. Just give some lines = as a seed for > >>> discussion. In my personal feeling, MIF is to change = the "one default > >>> link" feature of current generic IP model. = Multi-homing is to ensure > >>> the reachability and reliability of IP network. Well, = in multi-homing > >>> MN scenarios, multi-link-multi-address is also one = case. But, in this > >>> case, MN only can choose one link as default. > >>> Some other comments? > >> > >> To challenge one default link, it really takes time for = mif to consider > on > >> it, current first step in mif is to consider some = straight forward way > which > >> is simple to resolve some issues. > >> Regarding to multi-homing, I guess that it is more site = multi-homing. > >> For last multi-link-multi-address mn's scenario, it = will be one of MIF > >> scenario. > >> > >> thanks > >> > >> -Hui > >> > >>> > >>> BRG > >>> Peny > >> > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif ---------------------------------------------------------------------- _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_ZzuHkfLq9UQ9LDAxaMKQIg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hello, Hui
 
Agree with your statement.  However, it (the app/flow has to = be=20 restarted when interface-handoff happens) is actually an app/flow = mobility=20 issue related to multiple interfaces.  Thus,=20 it seems the working item MIF is the just place to = resolve=20 it.  Hope it make sense. :_)
 
B.R.
Yungui
 
----- Original Message -----
From:=20 Hui = Deng=20
Cc: pierrick.seite@orange-f= tgroup.com=20 ; mif@ietf.org
Sent: Friday, January 23, 2009 = 4:32=20 PM
Subject: Re: [mif] mobility = issues and=20 general issues on mif

Hello, Yungui,
 
Excuse me for misunderstanding your point,
reply inline below.

2009/1/23 Yungui Wang <w52006@huawei.com>
Hello Hui
 
Sorry for late response. In my = understanding,=20 one issue of MIF is interface selection (or named access=20 selection). However, interface selection of a MIF-node is = serving=20 for its up-layer app/flow.
some mobile phone can do it, but normally, like PC application = don't do=20 it, it is up to network
socket to choose source address, then interface is automatically=20 selected.
 
When one link = associated=20 with one interface of MIF-node is down or congested,=20 interface re-selection is needed. That's one type=20 of mobility of app/flow between different interfaces I wanted = to=20 address. 
If one interface is down or congested, then application will be = down as=20 well, this socket will close as well, and you would like to move some=20 application, then you have to restart to do it.
 
thanks for the discussion.
 
-Hui
Maybe IP address model is related = to how to do.=20 Please forget it.
 
B.R.
Yungui
 
----- Original Message ----- =
From: = Hui Deng
Cc: pierrick.seite@orange-ftgroup.com ; mif@ietf.org
Sent: Thursday, January 22, = 2009 2:26=20 PM
Subject: Re: [mif] mobility = issues=20 and general issues on mif

Hi, Yungui,
 
mif is targetting at multiple interface whatever it has how = many ip=20 address on each of them.
I guess that you are asking more IPv6 related question.
 
What I feel what ever per interface or per IP address, how it = is=20 related to mobility of application?
we are not handling handover related issues.
 
Thanks for the discussion.
Regards,
 
-Hui


 
2009/1/22 Yungui Wang <w52006@huawei.com>
Hello Hui
 
One comments, whether is = the IP=20 address model to be investigated within MIF? = For example, there are different types of = IP address=20 model for MIF-terminal, per = IP address=20 per IF, one IP address = for multiple=20 IF(s), etc. If considered = that, mobility=20 of application/flow over IP layer seems impliedly to be studied = (e.g. in=20 topic of IP route changing).
 
B.R.
Yungui
 
----- Original Message ----- =
From: Hui Deng
To: pierrick.seite@orange-ftgroup.com
Sent: Wednesday, = January 21, 2009=20 11:23 PM
Subject: Re: [mif] = mobility=20 issues and general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile = operator=20 is quite helpful for mif's work,
Your experience is appreicate, see reply inline = below,
2009/1/20 <pierrick.seite@orange-ftgroup.com>
Hi=20 all,

I've joined recently this ML and I believe = discussed=20 topics very interesting (BTW thanks to MIF promoters for = bringing=20 these issues to IETF). So, please let me jump into your=20 discussion.
Thanks again.
 

Regarding=20 difference between MIF and multihoming: it seems there is = confusion=20 with mobility. AFAIU, MIF is only supposed to deal with = routing=20 issue at the multi-interface MN side. The issue is to select = the=20 "best" interface for each outgoing IP flow and, in MIF = context,=20 access selection does not necessarily imply flow mobility = with IP=20 session continuity between interfaces. Nevertheless, = solution should=20 work for terminal with several active interfaces at the same = time=20 (multi-homed), or for terminal with a single interface at a = time. Am=20 I correct?
As you said here, flow mobility and IP session = continuity is=20 out of scope at the moment.
I cann't agree with any more about your left words.
 


Regarding=20 ANDSF issue, I agree with preceding emails: I think access = selection=20 should rely on policy. There are a couple of selection = models but=20 the simplest is the selection managed by the terminal and = based on=20 local policies and measurement on the access link. The = policies may=20 be provided/updated by a server via out-of-band mechanism or = on-demand (typically before selection) if policies include = "dynamic"=20 recommendation (e.g. access xx is overload and forbidden to=20 application type yy). Now you can call the policy server = ANDSF, or=20 whatever you want, it is just a generic functional entity in = the=20 architecture and this entity is above all access networks. = Note the=20 access selection via policy server meet MIF requirement as = well as=20 selection in inter-access mobility situation.
Most mobile terminal has implemented the policy based = selection=20 models.
Howver I would like to raise one case, sometime, if the = network=20 congested, terminal couldn't visit policy server such as = ANDSF, only=20 network side know what happen, they may re-arrange some = traffic for=20 mobile terminal, I guess that this is been discussed in 3GPP = SA2 side=20 at the moment.
 


Please=20 do not hesitate to correct me if I misunderstood MIF=20 issues.
thanks for the discussion.
 
-Hui


Regards,
Pierrick

>=20 -----Message d'origine-----
> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Peny
>=20 Yang
> Envoy=E9 : lundi 19 janvier 2009 = 15:10
>=20 =C0 : Kai Ju
> Cc : mif@ietf.org
> Objet : Re: = [mif]=20 mobility issues and general issues on mif
>
> Hi, Kai:
> > The ANSDF solution = is just a=20 sample, because there is no one type of
> = server
> >=20 which is
> > defined to provide the policy in IETF = until=20 now. So let us consider it
> be
> > general,=20 which
> > means it's one policy server that = provides the=20 routing policy to UE when
> UE
> > is=20 connecting
> > it.
> [Peny] Agree. 3GPP ANSDF = could=20 be a good reference when we make the
> MIF=20 solutions.
>
> BRG
>=20 Peny
>
>
>
> >>
> = >> Hi,=20 Peng and Kai,
> >>
> >> See reply = inline=20 below. thanks for the discussion.
> >> 2009/1/19 = Peny=20 Yang <peng.yang.chn@gmail.com>
>=20 >>>
> >>> Hi, Kai:
> = >>> Nice=20 point. Please check the lines below:
> = >>>
>=20 >>> > As you said, there are multiple way to = assign the=20 routing policy by
> in
> >>> > = the
>=20 >>> > mobile access network. As viewed from the = aspect=20 of terminal, I
> think
> >>> > its = a
>=20 >>> > good idea that terminal can get its = routing policy=20 from the ANDSF.
> >>> [Peny] ANDSF may be one = of the=20 choices. But ANDSF just follows the
> >>> = assumption=20 of generic "one default link" IP model. So, in 3GPP, = even
>=20 >>> though ANDSF can help UE to select accesses and = find=20 the route, UE can
> >>> only choose one of = the=20 interfaces as a result.
> >>> Personally, I'm = not=20 sure if it's a good way to rely on ANDSF of 3GPP,
>=20 >>> since it's a specific definition in one = SDO.
>=20 >>
> >> ANDSF in 3GPP 23.401 do cover only = 3GPP=20 network, how could ANDSF work
> for
> >> = 23.402=20 for non-3GPP access still a issue, it may need some = mechanism=20 to
> >> coordinate
> >> between two = type of=20 access entwork.what do you think?
> >>
>=20 >>>
> >>> > We think a default = policy can=20 be used,  when terminal can't find
> >>> = >=20 corresponding policy in the routing policy from the ANDSF.=20 The
> default
> >>> > policy can be = sent by=20 the network.
> >>> [Peny] Could we give a = chance to=20 MN to change the policy (like user
> >>> = preference)=20 ?
> >>>
> >>> > On another = hand, I=20 am a little confused between MIF and Multihoming,
>=20 >>> > would
> >>> > you please = help me=20 to clarify the difference between them?
> >>> = [Peny]=20 I am also not clear yet. Just give some lines as a seed = for
>=20 >>> discussion. In my personal feeling, MIF is to = change=20 the "one default
> >>> link" feature of = current=20 generic IP model. Multi-homing is to ensure
> = >>> the=20 reachability and reliability of IP network. Well, in=20 multi-homing
> >>> MN scenarios,=20 multi-link-multi-address is also one case. But, in = this
>=20 >>> case, MN only can choose one link as = default.
>=20 >>> Some other comments?
> >>
> = >>=20 To challenge one default link, it really takes time for mif = to=20 consider
> on
> >> it, current first step = in mif=20 is to consider some straight forward way
> = which
>=20 >> is simple to resolve some issues.
> >>=20 Regarding to multi-homing, I guess that it is more site=20 multi-homing.
> >> For last = multi-link-multi-address=20 mn's scenario, it will be one of MIF
> >>=20 scenario.
> >>
> >> thanks
>=20 >>
> >> -Hui
> >>
>=20 >>>
> >>> BRG
> >>>=20 Peny
> >>
> >
> = >
> = _______________________________________________
>=20 mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
________= _______________________________________
mif=20 mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

_______________________________________________
mif = mailing=20 list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

=



--Boundary_(ID_ZzuHkfLq9UQ9LDAxaMKQIg)-- --===============0553591479== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0553591479==-- From mif-bounces@ietf.org Fri Jan 23 02:50:45 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E033A6A84; Fri, 23 Jan 2009 02:50:45 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C2628C191 for ; Fri, 23 Jan 2009 02:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ6k1SZ2MvIN for ; Fri, 23 Jan 2009 02:50:43 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 4A8373A69DE for ; Fri, 23 Jan 2009 02:50:43 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so5377859wfd.31 for ; Fri, 23 Jan 2009 02:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AMVzf6wvtS21M7JcNRLRmayX/Y5WYJ+U6JNDvpW9NW4=; b=PdwUBNStcXDTHXpiZj4VT+HK/qoizzUF7RlBU9nX5e7+niguvg/o+rV7UECt7UILmN 18mFpTCe9rL4xeLoqvkO1JovVx/wNNeNndOkOiD/beuCquAaIuqDzocwvzvLAvuGeaMB 8XwbGYFGgFRs6rtrXBx4AFiPWtqJYf7qtynPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TdYAM124S7eMKM1Natbal5uzAAl+tTQ2g7Px4MuL7oPO/jwKIN252YaaJ4ohI3ptVv OG/DZR52mT2V7PPDt6mh108Kq0H7aUkct77ap3CrVAyBJw9mnu25686VGrHgUHtIOYHi j4vBPoiPNlzKmIkmzNJIVV7juTdRVtbWGYbpU= MIME-Version: 1.0 Received: by 10.142.241.10 with SMTP id o10mr609003wfh.174.1232707825818; Fri, 23 Jan 2009 02:50:25 -0800 (PST) In-Reply-To: <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Fri, 23 Jan 2009 18:50:25 +0800 Message-ID: <3db7b9d60901230250v5a9e143bmdaa0e1ed131a3002@mail.gmail.com> From: Kai Ju To: Peny Yang Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0103337834==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0103337834== Content-Type: multipart/alternative; boundary=000e0cd144b611de8404612428ee --000e0cd144b611de8404612428ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Hi, Peny and Jari > Please see the reply inline. > My personal classification of problems in the multiple interface space > includes the following: > > 1) Access selection, i.e., which network(s) to attach to using the physical > interface(s) that the host has. Already covered in RFC 5113. > > 2) Split DNS: If a host is attached to a number of different interfaces, how > does it resolve a FQDN if more than one interface has provided a DNS server > address? > > 3) Configuration reconciliation: how do we merge and use DHCP and other > configuration information in a node, when the information is received on a > per-interface basis? > > 4) Routing: If a host is attached to a number of different interfaces, where > does a particular IP packet go? > > 5) Address selection: If a host is attached to a number of different > interfaces, which addresses should be used for a particular application > flow? > > 6) Tunnel multihoming: If a host is attached to a number of different > interfaces and runs some kind of a tunneling or mobility back to a home > agent, which interface and addresses should be used for a particular packet? > Already covered in existing MEXT WG work items. [Peny] Agree with you from 1 to 6. Agree from 1 to 6 > 7) Is there a way for the host and the network to communicate about their > policies regarding all of the above? [Peny] For 7, maybe we could make the way for host/PEER/network to communicate their policies. Besides, if the policies of MIF node can not be followed by the peer node, in this sense, we need a way to communicate about the policies among host/peer/network. One is that network should have ability to assign policy to host, the other is that host can send its own policy to network. We consider MIF should support both of them. We prefer that policy assigned by network has higher priority than host its own, when they conflict. > My understanding is that the proposed BOF would be looking at problems 2, 3, > 4, 5, and 7. The others are covered elsewhere. [Peny] Some other points I have been thinking of: 1) MIF for IPv4 or IPv6 or Both? We consider MIF for both IPv4 and IPv6. 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we need to do the harmonization with other protocols? We consider MIF should solve general scenario problems now. In some particular cases, maybe need to co-work with (P)MIP or DSMIP, etc. I suggest we could discuss it later. 3) There is the case that one interface is connected, but the route to internet is not available (Such as WiFi Portal). How does MIF handle this case? If the interface is not available, host should know and handle it correspondly. We don't consider it's in MIF scope. If there is any question, correct me any minute pls, many thanks. --000e0cd144b611de8404612428ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Peny and Jari
 
      Please see the reply inline.
 

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.
Agree from 1 to 6
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
[Peny] For 7, mayb= e we could make the way for host/PEER/network to
communicate their polic= ies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

One is that network should have ability to assign policy to host, = the other
is that host can send its own policy to network. We consider M= IF should
support both of them. We prefer that policy assigned by networ= k has higher
priority than host its own, when they conflict.
 
> My understanding is that the proposed BOF would be looking at pro= blems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
[Peny= ] Some other points I have been thinking of:
1) MIF for IPv4 or IPv6 or = Both?
We consider MIF for both IPv4 and IPv6.

2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, = do we
need to do the harmonization with other protocols?
We consider = MIF should solve general scenario problems now. In some particular
cases= , maybe need to co-work with (P)MIP or DSMIP, etc. I suggest we
could discuss it later.

3) There is the case that one interface is connected, but the rout= e to
internet is not available (Such as WiFi Portal).  How does MIF= handle
this case?
If the interface is not available, host should kno= w and handle it correspondly.
We don't consider it's in MIF scope.
 
If there is any question, correct me any minute pls, many thanks.

--000e0cd144b611de8404612428ee-- --===============0103337834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0103337834==-- From mif-bounces@ietf.org Fri Jan 23 10:02:13 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494513A6AF6; Fri, 23 Jan 2009 10:02:13 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01123A68E6 for ; Fri, 23 Jan 2009 10:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXk8koqiWvqB for ; Fri, 23 Jan 2009 10:02:10 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 447353A6AF6 for ; Fri, 23 Jan 2009 10:02:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CCE491C4030D for ; Fri, 23 Jan 2009 10:01:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 875151C402FD for ; Fri, 23 Jan 2009 10:01:53 -0800 (PST) Message-ID: <497A0612.4060702@joelhalpern.com> Date: Fri, 23 Jan 2009 13:01:54 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mif@ietf.org References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> In-Reply-To: <000d01c97d3d$203633f0$150ca40a@china.huawei.com> Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Reading the discussion on this list, and the problem statement draft, I = want to call attention to the fact that you are getting into a = significant amount of mission creep (extending the target scope well = beyond the problem statement. In particular, this discussion leads to issues that would require = changes to transport behavior, host stack structure, and routing = structure. All of the issues that lead to that are valid issues. = However, they are also under investigation in other parts of the = community (Transport area, Internet Area, and Routing Research Group.) = Resolving those problems is going to take significant time. Please, = help with all of those issues. But if you want to make progress on the = issues called out in the problem statement draft, it would be a good = idea to narrow the scope, not expand it. As a final caveat, while it is tempting it is an extremely bad idea to = try to add all of the system routing intelligence to the local node. = Even the system does not have good visibility to many of the properties = (actual path availability is only approximated, for example). Using = information the host / node already has is a very good idea. Trying to = get all the routing information (so as, for example, to have a better = guess as to which interface can actually reach a given destination) = would be a very bad idea. To restate, there are real problems, identified in the base draft, which = are tricky to solve. If we want to solve them in a timely fashion, we = need to keep to a small set of problems. Yours, Joel M. Halpern Yungui Wang wrote: > = > Hello, Hui > = > Agree with your statement. However, it (the app/flow has to be = > restarted when interface-handoff happens) is actually an app/flow = > mobility issue related to multiple interfaces. Thus, it seems the = > working item MIF is the just place to resolve it. Hope it make sense. :_) > = > B.R. > Yungui > = > = > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com > ; mif@ietf.org > > *Sent:* Friday, January 23, 2009 4:32 PM > *Subject:* Re: [mif] mobility issues and general issues on mif > = > Hello, Yungui, > = > Excuse me for misunderstanding your point, > reply inline below. > = > 2009/1/23 Yungui Wang > > = > Hello Hui > = > Sorry for late response. In my understanding, one issue of MIF > is interface selection (or named access selection). However, > interface selection of a MIF-node is serving for its up-layer > app/flow. = > = > some mobile phone can do it, but normally, like PC application don't > do it, it is up to network > socket to choose source address, then interface is automatically > selected. > = > = > When one link associated with one interface of MIF-node is down > or congested, interface re-selection is needed. That's one type > of mobility of app/flow between different interfaces I wanted to > address. = > = > If one interface is down or congested, then application will be down > as well, this socket will close as well, and you would like to move > some application, then you have to restart to do it. > = > thanks for the discussion. > = > -Hui > = > Maybe IP address model is related to how to do. Please forget it. > = > B.R. > Yungui > = > = > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com > ; mif@ietf.org > > *Sent:* Thursday, January 22, 2009 2:26 PM > *Subject:* Re: [mif] mobility issues and general issues on mif > = > Hi, Yungui, > = > mif is targetting at multiple interface whatever it has how > many ip address on each of them. > I guess that you are asking more IPv6 related question. > = > What I feel what ever per interface or per IP address, how > it is related to mobility of application? > we are not handling handover related issues. > = > Thanks for the discussion. > Regards, > = > -Hui > = > = > = > 2009/1/22 Yungui Wang > > = > Hello Hui > = > One comments, whether is the IP address > model to be investigated within MIF? For example, there > are different types of IP address model for > MIF-terminal, per IP address per IF, one IP address > for multiple IF(s), etc. If considered that, mobility of > application/flow over IP layer seems impliedly to be > studied (e.g. in topic of IP route changing). > = > B.R. > Yungui > = > = > ----- Original Message ----- > *From:* Hui Deng > *To:* pierrick.seite@orange-ftgroup.com > > *Cc:* mif@ietf.org > *Sent:* Wednesday, January 21, 2009 11:23 PM > *Subject:* Re: [mif] mobility issues and general > issues on mif > = > Hi, pierrick, > = > Thanks for joining the disucssion, speaking for > mobile operator is quite helpful for mif's work, > Your experience is appreicate, see reply inline below, > 2009/1/20 > > = > Hi all, > = > I've joined recently this ML and I believe > discussed topics very interesting (BTW thanks to > MIF promoters for bringing these issues to > IETF). So, please let me jump into your discussio= n. > = > Thanks again. > = > = > = > Regarding difference between MIF and > multihoming: it seems there is confusion with > mobility. AFAIU, MIF is only supposed to deal > with routing issue at the multi-interface MN > side. The issue is to select the "best" > interface for each outgoing IP flow and, in MIF > context, access selection does not necessarily > imply flow mobility with IP session continuity > between interfaces. Nevertheless, solution > should work for terminal with several active > interfaces at the same time (multi-homed), or > for terminal with a single interface at a time. > Am I correct? > = > As you said here, flow mobility and IP session > continuity is out of scope at the moment. > I cann't agree with any more about your left words. > = > = > = > = > Regarding ANDSF issue, I agree with preceding > emails: I think access selection should rely on > policy. There are a couple of selection models > but the simplest is the selection managed by the > terminal and based on local policies and > measurement on the access link. The policies may > be provided/updated by a server via out-of-band > mechanism or on-demand (typically before > selection) if policies include "dynamic" > recommendation (e.g. access xx is overload and > forbidden to application type yy). Now you can > call the policy server ANDSF, or whatever you > want, it is just a generic functional entity in > the architecture and this entity is above all > access networks. Note the access selection via > policy server meet MIF requirement as well as > selection in inter-access mobility situation. > = > Most mobile terminal has implemented the policy > based selection models. > Howver I would like to raise one case, sometime, if > the network congested, terminal couldn't visit > policy server such as ANDSF, only network side know > what happen, they may re-arrange some traffic for > mobile terminal, I guess that this is been discussed > in 3GPP SA2 side at the moment. > = > = > = > = > Please do not hesitate to correct me if I > misunderstood MIF issues. > = > thanks for the discussion. > = > -Hui > = > = > = > Regards, > Pierrick > = > > -----Message d'origine----- > > De : mif-bounces@ietf.org > > [mailto:mif-bounces@ietf.org > ] De la part de Peny > > Yang > > Envoy=E9 : lundi 19 janvier 2009 15:10 > > =C0 : Kai Ju > > Cc : mif@ietf.org > > Objet : Re: [mif] mobility issues and general > issues on mif > > > > Hi, Kai: > > > The ANSDF solution is just a sample, > because there is no one type of > > server > > > which is > > > defined to provide the policy in IETF until > now. So let us consider it > > be > > > general, which > > > means it's one policy server that provides > the routing policy to UE when > > UE > > > is connecting > > > it. > > [Peny] Agree. 3GPP ANSDF could be a good > reference when we make the > > MIF solutions. > > > > BRG > > Peny > > > > > > > > >> > > >> Hi, Peng and Kai, > > >> > > >> See reply inline below. thanks for the > discussion. > > >> 2009/1/19 Peny Yang > > > > >>> > > >>> Hi, Kai: > > >>> Nice point. Please check the lines below: > > >>> > > >>> > As you said, there are multiple way to > assign the routing policy by > > in > > >>> > the > > >>> > mobile access network. As viewed from > the aspect of terminal, I > > think > > >>> > its a > > >>> > good idea that terminal can get its > routing policy from the ANDSF. > > >>> [Peny] ANDSF may be one of the choices. > But ANDSF just follows the > > >>> assumption of generic "one default link" > IP model. So, in 3GPP, even > > >>> though ANDSF can help UE to select > accesses and find the route, UE can > > >>> only choose one of the interfaces as a > result. > > >>> Personally, I'm not sure if it's a good > way to rely on ANDSF of 3GPP, > > >>> since it's a specific definition in one SD= O. > > >> > > >> ANDSF in 3GPP 23.401 do cover only 3GPP > network, how could ANDSF work > > for > > >> 23.402 for non-3GPP access still a issue, > it may need some mechanism to > > >> coordinate > > >> between two type of access entwork.what do > you think? > > >> > > >>> > > >>> > We think a default policy can be used, > when terminal can't find > > >>> > corresponding policy in the routing > policy from the ANDSF. The > > default > > >>> > policy can be sent by the network. > > >>> [Peny] Could we give a chance to MN to > change the policy (like user > > >>> preference) ? > > >>> > > >>> > On another hand, I am a little confused > between MIF and Multihoming, > > >>> > would > > >>> > you please help me to clarify the > difference between them? > > >>> [Peny] I am also not clear yet. Just give > some lines as a seed for > > >>> discussion. In my personal feeling, MIF > is to change the "one default > > >>> link" feature of current generic IP > model. Multi-homing is to ensure > > >>> the reachability and reliability of IP > network. Well, in multi-homing > > >>> MN scenarios, multi-link-multi-address is > also one case. But, in this > > >>> case, MN only can choose one link as defau= lt. > > >>> Some other comments? > > >> > > >> To challenge one default link, it really > takes time for mif to consider > > on > > >> it, current first step in mif is to > consider some straight forward way > > which > > >> is simple to resolve some issues. > > >> Regarding to multi-homing, I guess that it > is more site multi-homing. > > >> For last multi-link-multi-address mn's > scenario, it will be one of MIF > > >> scenario. > > >> > > >> thanks > > >> > > >> -Hui > > >> > > >>> > > >>> BRG > > >>> Peny > > >> > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = > = > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = > = > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Fri Jan 23 10:20:45 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24673A6AC5; Fri, 23 Jan 2009 10:20:45 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD99E3A6AC5 for ; Fri, 23 Jan 2009 10:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJe3VfD7eXSD for ; Fri, 23 Jan 2009 10:20:37 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by core3.amsl.com (Postfix) with ESMTP id 868803A691B for ; Fri, 23 Jan 2009 10:20:37 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so1035149ele.13 for ; Fri, 23 Jan 2009 10:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Vv16vCMLaGqMBdNr5DGWWrxgNuzCBcdXaSuswR/1+mg=; b=V88lOEbNCtUXf7kSJX4uX5vhG5uny0NDUWjqX5jno7CBv9LxPsAFMwIspdi6ae4MCU O8006qBpTprhhgMB61Fm4RDIHEcJe5XlCGJ2xhn/u9Junvt5vLrW2aDSqRM46CXfi1zc +IiW7cnol5B6e/PYRq9rO2Xh4I51oK8Z8xpJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SNcHIsNmulj66MPh7x7Z3350cl7483//uSfQGjJyDrHMTfOSgIdRBVNJmYoqsHFixm ADlpfFLleu7GdQI2ekyby0nGfsjq/u6Ms6f8HwC2QhIvEtmYLk8lcxVyw1aq2v71lGqP xTjXISVcHtHzw4OYjPFQSMlwLLlm+W/YtbIhE= MIME-Version: 1.0 Received: by 10.150.137.8 with SMTP id k8mr3681494ybd.79.1232734819391; Fri, 23 Jan 2009 10:20:19 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Fri, 23 Jan 2009 10:20:19 -0800 Message-ID: From: Kevin Chin To: Tao Sun Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092518402==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0092518402== Content-Type: multipart/alternative; boundary=000e0cd56af00318a004612a7128 --000e0cd56af00318a004612a7128 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > 7) Is there a way for the host and the network to communicate about their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > "communicate their policies among host/peer/network" seems to imply more message intensive transfer of state from MS. Privacy concerns are also legitimate if network needs information from MS to support MIF. "policy conflict when >1 operator/network" can not optimize for device specific policies, there are trade-offs between "monetary cost" and speed/access/convenience. thanks On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: > Hi, Kevin, > > I tend to agree with you here that the terminal may not need to upstream > the capability to the network. but do you see any proposal here doing that? > > but sometime, MS made some decision on the interface and route, but what > happen if network congested, how to handle that? just waiting for the fall > back. > > For confliction of policy, I guess that it could be categorized by two > case, > one operator, then it should be avoided by offline arrangement, > for two ISPs, FIFO still work there, cause no problem for user's traffic. > > thanks for the discussion. > > -Tao > > > On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: > >> >> >>> 1) MIF for IPv4 or IPv6 or Both? >> >> >> >>> >>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>> need to do the harmonization with other protocols? >>> 3) There is the case that one interface is connected, but the route to >>> internet is not available (Such as WiFi Portal). How does MIF handle >>> this case? >>> >> >> > 7) Is there a way for the host and the network to communicate about >> their >> > policies regarding all of the above? >> >> Very interesting topic. >> >> I assume MIF is optional "should" v. "must" w.r.t policies from the >> network (e.g. guidance not directive). >> The MS may have lots of policies which can make an informed decision. >> >> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. >> This would imply MS pushing characteristics up to the network so the >> network can push device-specific directives down. >> It should not be the case that the device needs to push capabilties >> upstream for the network to provide MIF-based guidance. >> >> Furthermore there may be different networks on each interface >> necessitating conflict resolution protocols, let alone issues that occur >> sporadically (e.g. WiFI portal, network roaming policies, access-based >> policy) .... >> >> Can't device based provisioning with (optional) input from network address >> most of the stated issues? >> >> thanks- >> Kevin >> >> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: >> >>> Hi, Jari: >>> >>> Please check my lines: >>> >>> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko >>> wrote: >>> > Again, there seems to be two issues. The first issue is having a policy >>> that >>> > tells an application which addresses to use (and indirectly which >>> interface >>> > to use). The second issue is that if the policy comes, e.g., via DHCP >>> on a >>> > per-interface basis, then we again have to reconcile the different >>> policies >>> > on a per-node basis. >>> [Peny] Agree with you for the two issues. Another point in my mind may >>> be a possible issue. When a peer tries to initiate flows with MIF >>> node, we need some way to let the peer know the policies and follow >>> the policies of MIF node. >>> >>> > My personal classification of problems in the multiple interface space >>> > includes the following: >>> > >>> > 1) Access selection, i.e., which network(s) to attach to using the >>> physical >>> > interface(s) that the host has. Already covered in RFC 5113. >>> > >>> > 2) Split DNS: If a host is attached to a number of different >>> interfaces, how >>> > does it resolve a FQDN if more than one interface has provided a DNS >>> server >>> > address? >>> > >>> > 3) Configuration reconciliation: how do we merge and use DHCP and other >>> > configuration information in a node, when the information is received >>> on a >>> > per-interface basis? >>> > >>> > 4) Routing: If a host is attached to a number of different interfaces, >>> where >>> > does a particular IP packet go? >>> > >>> > 5) Address selection: If a host is attached to a number of different >>> > interfaces, which addresses should be used for a particular application >>> > flow? >>> > >>> > 6) Tunnel multihoming: If a host is attached to a number of different >>> > interfaces and runs some kind of a tunneling or mobility back to a home >>> > agent, which interface and addresses should be used for a particular >>> packet? >>> > Already covered in existing MEXT WG work items. >>> [Peny] Agree with you from 1 to 6. >>> >>> > 7) Is there a way for the host and the network to communicate about >>> their >>> > policies regarding all of the above? >>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>> communicate their policies. Besides, if the policies of MIF node can >>> not be followed by the peer node, in this sense, we need a way to >>> communicate about the policies among host/peer/network. >>> >>> > My understanding is that the proposed BOF would be looking at problems >>> 2, 3, >>> > 4, 5, and 7. The others are covered elsewhere. >>> [Peny] Some other points I have been thinking of: >>> 1) MIF for IPv4 or IPv6 or Both? >>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>> need to do the harmonization with other protocols? >>> 3) There is the case that one interface is connected, but the route to >>> internet is not available (Such as WiFi Portal). How does MIF handle >>> this case? >>> >>> BRG >>> Peny >>> >>> >>> > Jari >>> > >>> > _______________________________________________ >>> > mif mailing list >>> > mif@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mif >>> > >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --000e0cd56af00318a004612a7128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
[Peny] For 7, maybe we could make the way for host/PEER/network to
= communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.
 
"communicate their policies among host/peer/network" seems t= o imply more message intensive transfer of state from MS.
Privacy concerns are also legitimate if network needs information from= MS to support MIF.

"policy conflict when >1 operator/network" can not op= timize for device specific policies, there are trade-offs between "mon= etary cost" and speed/access/convenience.
 
thanks

 
On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <hisuntao@gmail.com> wrote:
Hi, Kevin,
 
I tend to agree with you here that the terminal may not need to&n= bsp;upstream the capability to the network. but do you see any proposal her= e doing that?

but sometime, MS made some decision on the interface a= nd route, but what happen if network congested, how to handle that? just wa= iting for the fall back.
 
For confliction of policy, I guess that it could be categorized by two= case,
one operator, then it should be avoided by offline arrangement,
for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
 
thanks for the discussion.
 
-Tao
 
 
On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.com> wrote:
 
1) MIF for IPv4 or IPv6 or Both?=
 

2)  Will M= IF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the = harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:=
> Again, there seems to be two issues. The first issue is having a p= olicy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate= about their
> policies regarding all of the above?
[Peny] F= or 7, maybe we could make the way for host/PEER/network to
communicate t= heir policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at= problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
<= /div>[Peny] Some other points I have been thinking of:
1) MIF for IPv4 o= r IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
= need to do the harmonization with other protocols?
3) There is the case = that one interface is connected, but the route to
internet is not availa= ble (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny


> Jari
>
> ____________________________________= ___________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/list= info/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mif" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinf= o/mif



--000e0cd56af00318a004612a7128-- --===============0092518402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0092518402==-- From mif-bounces@ietf.org Fri Jan 23 17:35:12 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16833A694D; Fri, 23 Jan 2009 17:35:12 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6913A67F3 for ; Fri, 23 Jan 2009 17:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjdPvgljADbJ for ; Fri, 23 Jan 2009 17:35:09 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 6A9273A694D for ; Fri, 23 Jan 2009 17:35:08 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so4320979ywj.49 for ; Fri, 23 Jan 2009 17:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pL37vklDqbmz4hAeefD/Wqd53RdLBELCIoGH3kTRW/U=; b=RjuV8UF371oJy6TmhS+LBDHJD3DuNSgFft0Fov5r/aWXINTMQn9BkCe6Qk9VOsrtYT q9giYEtAWxeoPaW/352vwHG1HrsUTm+WnL/15f4qJuC0/RoS09A/9Hb7vzKyaPmGOlct ZYz9xo1t+QBeELYJ64yRai2ap7IuarCMfsaho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E3foRjBWihTDlsMojJfZ7yDAD0sc8kw/qqR0H3HnEHt9UfGfApc/BZKgHXIt9uVSSN Mm8MOJ9X21FBYyFEGMDksX8AhRbg3kwpZCYnFGvadfWobaF+3YKO28xTAEG6H8hVPLpj drNZw4wjZhm1cMekYhGWQ2/ja6haUhsNrm6Ho= MIME-Version: 1.0 Received: by 10.151.110.14 with SMTP id n14mr774827ybm.175.1232760890059; Fri, 23 Jan 2009 17:34:50 -0800 (PST) In-Reply-To: <497A0612.4060702@joelhalpern.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> <497A0612.4060702@joelhalpern.com> Date: Fri, 23 Jan 2009 17:34:49 -0800 Message-ID: From: Kevin Chin To: "Joel M. Halpern" Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0494352708==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0494352708== Content-Type: multipart/alternative; boundary=00151757357cf1ec07046130820f --00151757357cf1ec07046130820f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > > As a final caveat, while it is tempting it is an extremely bad idea to tr= y > to add all of the system routing intelligence to the local node. Even the > system does not have good visibility to many of the properties (actual pa= th > availability is only approximated, for example). Using information the h= ost > / node already has is a very good idea. Trying to get all the routing > information (so as, for example, to have a better guess as to which > interface can actually reach a given destination) would be a very bad ide= a. > Agree - Using information the host/node already has is a very good idea. Th= e host already has a set of tools and incentive to get it right. > To restate, there are real problems, identified in the base draft, which > are tricky to solve. If we want to solve them in a timely fashion, we ne= ed > to keep to a small set of problems. > > Yours, > Joel M. Halpern > I second this view. Let's define small set of issues to investigate. regards, Kevin On Fri, Jan 23, 2009 at 10:01 AM, Joel M. Halpern wrot= e: > Reading the discussion on this list, and the problem statement draft, I > want to call attention to the fact that you are getting into a significan= t > amount of mission creep (extending the target scope well beyond the probl= em > statement. > > In particular, this discussion leads to issues that would require changes > to transport behavior, host stack structure, and routing structure. All = of > the issues that lead to that are valid issues. However, they are also und= er > investigation in other parts of the community (Transport area, Internet > Area, and Routing Research Group.) Resolving those problems is going to t= ake > significant time. Please, help with all of those issues. But if you wan= t > to make progress on the issues called out in the problem statement draft,= it > would be a good idea to narrow the scope, not expand it. > > As a final caveat, while it is tempting it is an extremely bad idea to tr= y > to add all of the system routing intelligence to the local node. Even the > system does not have good visibility to many of the properties (actual pa= th > availability is only approximated, for example). Using information the h= ost > / node already has is a very good idea. Trying to get all the routing > information (so as, for example, to have a better guess as to which > interface can actually reach a given destination) would be a very bad ide= a. > > To restate, there are real problems, identified in the base draft, which > are tricky to solve. If we want to solve them in a timely fashion, we ne= ed > to keep to a small set of problems. > > Yours, > Joel M. Halpern > > Yungui Wang wrote: > >> >> Hello, Hui >> Agree with your statement. However, it (the app/flow has to be restart= ed >> when interface-handoff happens) is actually an app/flow mobility issue >> related to multiple interfaces. Thus, it seems the working item MIF is = the >> just place to resolve it. Hope it make sense. :_) >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* Yungui Wang >> *Cc:* pierrick.seite@orange-ftgroup.com >> ; mif@ietf.org >> >> *Sent:* Friday, January 23, 2009 4:32 PM >> *Subject:* Re: [mif] mobility issues and general issues on mif >> >> Hello, Yungui, >> Excuse me for misunderstanding your point, >> reply inline below. >> >> 2009/1/23 Yungui Wang > >> >> Hello Hui >> Sorry for late response. In my understanding, one issue o= f >> MIF >> is interface selection (or named access selection). However, >> interface selection of a MIF-node is serving for its up-layer >> app/flow. >> some mobile phone can do it, but normally, like PC application don't >> do it, it is up to network >> socket to choose source address, then interface is automatically >> selected. >> >> When one link associated with one interface of MIF-node is down >> or congested, interface re-selection is needed. That's one type >> of mobility of app/flow between different interfaces I wanted to >> address. >> If one interface is down or congested, then application will be down >> as well, this socket will close as well, and you would like to move >> some application, then you have to restart to do it. >> thanks for the discussion. >> -Hui >> >> Maybe IP address model is related to how to do. Please forget it. >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* Yungui Wang >> *Cc:* pierrick.seite@orange-ftgroup.com >> ; mif@ietf.org >> >> *Sent:* Thursday, January 22, 2009 2:26 PM >> *Subject:* Re: [mif] mobility issues and general issues on mi= f >> >> Hi, Yungui, >> mif is targetting at multiple interface whatever = it >> has how >> many ip address on each of them. >> I guess that you are asking more IPv6 related question. >> What I feel what ever per interface or per IP >> address, how >> it is related to mobility of application? >> we are not handling handover related issues. >> Thanks for the discussion. >> Regards, >> -Hui >> >> >> 2009/1/22 Yungui Wang > > >> >> Hello Hui >> One comments, whether is the IP address >> model to be investigated within MIF? For example, there >> are different types of IP address model for >> MIF-terminal, per IP address per IF, one IP address >> for multiple IF(s), etc. If considered that, mobility of >> application/flow over IP layer seems impliedly to be >> studied (e.g. in topic of IP route changing). >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* pierrick.seite@orange-ftgroup.com >> >> *Cc:* mif@ietf.org >> *Sent:* Wednesday, January 21, 2009 11:23 PM >> *Subject:* Re: [mif] mobility issues and general >> issues on mif >> >> Hi, pierrick, >> Thanks for joining the disucssion= , >> speaking for >> mobile operator is quite helpful for mif's work, >> Your experience is appreicate, see reply inline below= , >> 2009/1/20 > > >> >> >> Hi all, >> >> I've joined recently this ML and I believe >> discussed topics very interesting (BTW thanks to >> MIF promoters for bringing these issues to >> IETF). So, please let me jump into your discussio= n. >> >> Thanks again. >> >> >> Regarding difference between MIF and >> multihoming: it seems there is confusion with >> mobility. AFAIU, MIF is only supposed to deal >> with routing issue at the multi-interface MN >> side. The issue is to select the "best" >> interface for each outgoing IP flow and, in MIF >> context, access selection does not necessarily >> imply flow mobility with IP session continuity >> between interfaces. Nevertheless, solution >> should work for terminal with several active >> interfaces at the same time (multi-homed), or >> for terminal with a single interface at a time. >> Am I correct? >> >> As you said here, flow mobility and IP session >> continuity is out of scope at the moment. >> I cann't agree with any more about your left words. >> >> >> >> Regarding ANDSF issue, I agree with preceding >> emails: I think access selection should rely on >> policy. There are a couple of selection models >> but the simplest is the selection managed by the >> terminal and based on local policies and >> measurement on the access link. The policies may >> be provided/updated by a server via out-of-band >> mechanism or on-demand (typically before >> selection) if policies include "dynamic" >> recommendation (e.g. access xx is overload and >> forbidden to application type yy). Now you can >> call the policy server ANDSF, or whatever you >> want, it is just a generic functional entity in >> the architecture and this entity is above all >> access networks. Note the access selection via >> policy server meet MIF requirement as well as >> selection in inter-access mobility situation. >> >> Most mobile terminal has implemented the policy >> based selection models. >> Howver I would like to raise one case, sometime, if >> the network congested, terminal couldn't visit >> policy server such as ANDSF, only network side know >> what happen, they may re-arrange some traffic for >> mobile terminal, I guess that this is been discussed >> in 3GPP SA2 side at the moment. >> >> >> >> Please do not hesitate to correct me if I >> misunderstood MIF issues. >> >> thanks for the discussion. >> -Hui >> >> >> >> Regards, >> Pierrick >> >> > -----Message d'origine----- >> > De : mif-bounces@ietf.org >> >> [mailto:mif-bounces@ietf.org >> ] De la part de Peny >> > Yang >> > Envoy=E9 : lundi 19 janvier 2009 15:10 >> > =C0 : Kai Ju >> > Cc : mif@ietf.org >> >> > Objet : Re: [mif] mobility issues and general >> issues on mif >> > >> > Hi, Kai: >> > > The ANSDF solution is just a sample, >> because there is no one type of >> > server >> > > which is >> > > defined to provide the policy in IETF until >> now. So let us consider it >> > be >> > > general, which >> > > means it's one policy server that provides >> the routing policy to UE when >> > UE >> > > is connecting >> > > it. >> > [Peny] Agree. 3GPP ANSDF could be a good >> reference when we make the >> > MIF solutions. >> > >> > BRG >> > Peny >> > >> > >> > >> > >> >> > >> Hi, Peng and Kai, >> > >> >> > >> See reply inline below. thanks for the >> discussion. >> > >> 2009/1/19 Peny Yang >> > > >> >> > >>> >> > >>> Hi, Kai: >> > >>> Nice point. Please check the lines below: >> > >>> >> > >>> > As you said, there are multiple way to >> assign the routing policy by >> > in >> > >>> > the >> > >>> > mobile access network. As viewed from >> the aspect of terminal, I >> > think >> > >>> > its a >> > >>> > good idea that terminal can get its >> routing policy from the ANDSF. >> > >>> [Peny] ANDSF may be one of the choices. >> But ANDSF just follows the >> > >>> assumption of generic "one default link" >> IP model. So, in 3GPP, even >> > >>> though ANDSF can help UE to select >> accesses and find the route, UE can >> > >>> only choose one of the interfaces as a >> result. >> > >>> Personally, I'm not sure if it's a good >> way to rely on ANDSF of 3GPP, >> > >>> since it's a specific definition in one SD= O. >> > >> >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP >> network, how could ANDSF work >> > for >> > >> 23.402 for non-3GPP access still a issue, >> it may need some mechanism to >> > >> coordinate >> > >> between two type of access entwork.what do >> you think? >> > >> >> > >>> >> > >>> > We think a default policy can be used, >> when terminal can't find >> > >>> > corresponding policy in the routing >> policy from the ANDSF. The >> > default >> > >>> > policy can be sent by the network. >> > >>> [Peny] Could we give a chance to MN to >> change the policy (like user >> > >>> preference) ? >> > >>> >> > >>> > On another hand, I am a little confused >> between MIF and Multihoming, >> > >>> > would >> > >>> > you please help me to clarify the >> difference between them? >> > >>> [Peny] I am also not clear yet. Just give >> some lines as a seed for >> > >>> discussion. In my personal feeling, MIF >> is to change the "one default >> > >>> link" feature of current generic IP >> model. Multi-homing is to ensure >> > >>> the reachability and reliability of IP >> network. Well, in multi-homing >> > >>> MN scenarios, multi-link-multi-address is >> also one case. But, in this >> > >>> case, MN only can choose one link as >> default. >> > >>> Some other comments? >> > >> >> > >> To challenge one default link, it really >> takes time for mif to consider >> > on >> > >> it, current first step in mif is to >> consider some straight forward way >> > which >> > >> is simple to resolve some issues. >> > >> Regarding to multi-homing, I guess that it >> is more site multi-homing. >> > >> For last multi-link-multi-address mn's >> scenario, it will be one of MIF >> > >> scenario. >> > >> >> > >> thanks >> > >> >> > >> -Hui >> > >> >> > >>> >> > >>> BRG >> > >>> Peny >> > >> >> > > >> > > >> > ______________________________________________= _ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --00151757357cf1ec07046130820f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a final caveat, while it is t= empting it is an extremely bad idea to try to add all of the system routing= intelligence to the local node. Even the system does not have good visibil= ity to many of the properties (actual path availability is only approximate= d, for example).  Using information the host / node already has is a v= ery good idea.  Trying to get all the routing information (so as, for = example, to have a better guess as to which interface can actually reach a = given destination) would be a very bad idea.

Agree - Using information the host/node already has is a very good idea.= The host already has a set of tools and incentive to get it right.

 
 
To restate, there are real probl= ems, identified in the base draft, which are tricky to solve.  If we w= ant to solve them in a timely fashion, we need to keep to a small set of pr= oblems.

Yours,
Joel M. Halpern
 
I second this view. Let's define small set of issues to investigat= e.
 
regards,
Kevin

On Fri, Jan 23, 2009 at 10:01 AM, Joel M. Halper= n <jmh@joelhalp= ern.com> wrote:
Reading the discussion on this l= ist, and the problem statement draft, I want to call attention to the fact = that you are getting into a significant amount of mission creep (extending = the target scope well beyond the problem statement.

In particular, this discussion leads to issues that would require chang= es to transport behavior, host stack structure, and routing structure. &nbs= p;All of the issues that lead to that are valid issues. However, they are a= lso under investigation in other parts of the community (Transport area, In= ternet Area, and Routing Research Group.) Resolving those problems is going= to take significant time.  Please, help with all of those issues. &nb= sp;But if you want to make progress on the issues called out in the problem= statement draft, it would be a good idea to narrow the scope, not expand i= t.

As a final caveat, while it is tempting it is an extremely bad idea to = try to add all of the system routing intelligence to the local node. Even t= he system does not have good visibility to many of the properties (actual p= ath availability is only approximated, for example).  Using informatio= n the host / node already has is a very good idea.  Trying to get all = the routing information (so as, for example, to have a better guess as to w= hich interface can actually reach a given destination) would be a very bad = idea.

To restate, there are real problems, identified in the base draft, whic= h are tricky to solve.  If we want to solve them in a timely fashion, = we need to keep to a small set of problems.

Yours,
Joel M. Halper= n

Yungui Wang wrote:

Hello, Hui
 Agree with your statement. &n= bsp;However, it (the app/flow has to be restarted when interface-handoff ha= ppens) is actually an app/flow mobility issue related to multiple interface= s.  Thus, it seems the working item MIF is the just place to resolve i= t.  Hope it make sense. :_)
 B.R.
Yungui
 
   ----- Original Message -----=
   *From:* Hui Deng <mailto:denghui02@gmail.com>   *To:* Yungui Wang <mailto:w52006@huawei.com>
   *Cc:* pierrick.seite@orange-ftgroup.com
   <ma= ilto:pierrick.seite@orange-ftgroup.com> ; mif@ietf.org
   <mailto:m= if@ietf.org>
   *Sent:* Friday, January 23, 2009 4:32 P= M
   *Subject:* Re: [mif] mobility issues and general issues o= n mif

   Hello, Yungui,
       Excuse me for misunderstanding your point,
&n= bsp;  reply inline below.

   2009/1/23 Yungui W= ang <w52006@huawe= i.com <mailto:w52006@huawei.com>>=20


       Hello Hui
 = ;              Sorry for late response. = In my understanding, one issue of MIF
       is inte= rface selection (or named access selection). However,
    &nbs= p;  interface selection of a MIF-node is serving for its up-layer
       app/flow.
   some mobile phone can= do it, but normally, like PC application don't
   do it, = it is up to network
   socket to choose source address, then i= nterface is automatically
   selected.
   
       When one link associated with one interface of M= IF-node is down
       or congested, interface re-se= lection is needed. That's one type
       of mob= ility of app/flow between different interfaces I wanted to
       address.  
   If one interface= is down or congested, then application will be down
   as wel= l, this socket will close as well, and you would like to move
  &nb= sp;some application, then you have to restart to do it.
       thanks for the discussion.
    &nbs= p;  -Hui

       Maybe IP address model is r= elated to how to do. Please forget it.
         = ;      B.R.
       Yungui
  &= nbsp;    
           ----- Orig= inal Message -----
           *From:* Hui = Deng <mailto:de= nghui02@gmail.com>
           *To:*= Yungui Wang <mailto:w52006@huawei.com>
           *Cc:* pierrick.seite@orange-ftgroup.co= m
           <mailto:pierrick.seite@ora= nge-ftgroup.com> ; mif@ietf.org
           <mailto:mif@ietf.org>
      &nb= sp;    *Sent:* Thursday, January 22, 2009 2:26 PM
   = ;        *Subject:* Re: [mif] mobility issues and gener= al issues on mif

           Hi, Yungui,
    &= nbsp;                  mif is = targetting at multiple interface whatever it has how
     = ;      many ip address on each of them.
    &nb= sp;      I guess that you are asking more IPv6 related quest= ion.
                     = ;  What I feel what ever per interface or per IP address, how
 = ;          it is related to mobility of applicatio= n?
           we are not handling handover= related issues.
               =        Thanks for the discussion.
           Regards,
      &= nbsp;                -Hui

                    &nb= sp;  2009/1/22 Yungui Wang <w52006@huawei.com
        =    <mailto:w52006@huawei.com>>=20


            &nb= sp;  Hello Hui
              &nb= sp;                One comments, wh= ether is the IP address
             =  model to be investigated within MIF? For example, there
  &n= bsp;            are different types of IP add= ress model for
               MIF-terminal, per IP= address per IF, one IP address
           = ;    for multiple IF(s), etc. If considered that, mobility of
=                application/flow ove= r IP layer seems impliedly to be
          &nbs= p;    studied (e.g. in topic of IP route changing).
                     = ;          B.R.
        &nb= sp;      Yungui
           =    
                =    ----- Original Message -----
              &nbs= p;    *From:* Hui Deng <mailto:denghui02@gmail.com>
    &nbs= p;              *To:* pierrick.seite@orange-= ftgroup.com
                   <ma= ilto:pierrick.seite@orange-ftgroup.com>
        &= nbsp;          *Cc:* mif@ietf.org <mailto:mif@ietf.org>
                   *Sent:= * Wednesday, January 21, 2009 11:23 PM
         = ;          *Subject:* Re: [mif] mobility issues an= d general
                 =  issues on mif

             = ;      Hi, pierrick,
          &= nbsp;                    =        Thanks for joining the disucssion, speaking for=
                   mobile= operator is quite helpful for mif's work,
      &nbs= p;            Your experience is appreicate, = see reply inline below,
             =      2009/1/20 <pierrick.seite@orange-ftgroup.com
                   = <mailto:pierrick.seite@orange-ftgroup.com>>=20


            &nb= sp;          Hi all,

      &= nbsp;                I've joine= d recently this ML and I believe
          &nbs= p;            discussed topics very interesti= ng (BTW thanks to
               = ;        MIF promoters for bringing these issues to
                     = ;  IETF). So, please let me jump into your discussion.

  &= nbsp;                Thanks again.<= br>                   
                   =    Regarding difference between MIF and
      =                  multihoming: = it seems there is confusion with
                     = ;  mobility. AFAIU, MIF is only supposed to deal
    &nbs= p;                  with routi= ng issue at the multi-interface MN
          &n= bsp;            side. The issue is to select = the "best"
              &n= bsp;        interface for each outgoing IP flow and, in= MIF
                     = ;  context, access selection does not necessarily
    &nb= sp;                  imply flo= w mobility with IP session continuity
         =              between interfaces. Nevert= heless, solution
               =        should work for terminal with several active                      = ;  interfaces at the same time (multi-homed), or
    &nbs= p;                  for termin= al with a single interface at a time.
         =              Am I correct?

 = ;                  As you said= here, flow mobility and IP session
                   contin= uity is out of scope at the moment.
          &= nbsp;        I cann't agree with any more about you= r left words.
                &n= bsp;  


              &n= bsp;        Regarding ANDSF issue, I agree with precedi= ng
                     = ;  emails: I think access selection should rely on
    &n= bsp;                  policy. = There are a couple of selection models
         = ;              but the simplest is the s= election managed by the
                     = ;  terminal and based on local policies and
      &n= bsp;                measurement on = the access link. The policies may
          &nb= sp;            be provided/updated by a serve= r via out-of-band
               = ;        mechanism or on-demand (typically before
                     = ;  selection) if policies include "dynamic"
   =                    recom= mendation (e.g. access xx is overload and
        &n= bsp;              forbidden to applicati= on type yy). Now you can
                     = ;  call the policy server ANDSF, or whatever you
    &nbs= p;                  want, it i= s just a generic functional entity in
         =              the architecture and this = entity is above all
              &nb= sp;        access networks. Note the access selection v= ia
                     = ;  policy server meet MIF requirement as well as
    &nbs= p;                  selection = in inter-access mobility situation.

        &nbs= p;          Most mobile terminal has implemented t= he policy
                 =  based selection models.
                   Howver= I would like to raise one case, sometime, if
       = ;            the network congested, terminal = couldn't visit
              &nbs= p;    policy server such as ANDSF, only network side know
                   what h= appen, they may re-arrange some traffic for
        =            mobile terminal, I guess that this= is been discussed
              &nbs= p;    in 3GPP SA2 side at the moment.
      &nb= sp;            


                  &nbs= p;    Please do not hesitate to correct me if I
    =                    misund= erstood MIF issues.

             =      thanks for the discussion.
      &nb= sp;                     &= nbsp;          -Hui



                  =      Regards,
            &= nbsp;          Pierrick

     = ;                   > -----= Message d'origine-----
            &nb= sp;           > De : mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>
           =            [mailto:mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>] De la part de Peny
      =                   > Yang                    &nbs= p;   > Envoy=E9 : lundi 19 janvier 2009 15:10
                     = ;   > =C0 : Kai Ju
         = ;               > Cc : mif@ietf.org <mailto:mif@ietf.org>=20

              =           > Objet : Re: [mif] mobility issues a= nd general
                 = ;      issues on mif
          &= nbsp;             >
     = ;                   > Hi, K= ai:
                   = ;     > > The ANSDF solution is just a sample,
                     = ;  because there is no one type of
        &nbs= p;               > server
  &= nbsp;                    = > > which is
              &nb= sp;         > > defined to provide the policy in = IETF until
                     = ;  now. So let us consider it
          &n= bsp;             > be
    &nb= sp;                   > >= ; general, which
               =         > > means it's one policy server tha= t provides
                     = ;  the routing policy to UE when
         =               > UE
    =                     > = > is connecting
              &nbs= p;         > > it.
       =                 > [Peny] Agree.= 3GPP ANSDF could be a good
                     = ;  reference when we make the
          &n= bsp;             > MIF solutions.
 = ;                     &nb= sp; >
                  =       > BRG
            =             > Peny
     =                   >
                     = ;   >
                &n= bsp;       >
           =             > >>
    &= nbsp;                   > &= gt;> Hi, Peng and Kai,
            &nbs= p;           > >>
     =                   > >&g= t; See reply inline below. thanks for the
                     = ;  discussion.
              &nb= sp;         > >> 2009/1/19 Peny Yang
 =                     &nbs= p;<peng.yan= g.chn@gmail.com
                     = ;  <mailto:peng.yang.chn@gmail.com>>=20

              =           > >>>
     = ;                   > >&= gt;> Hi, Kai:
               =         > >>> Nice point. Please check the= lines below:
                &n= bsp;       > >>>
                     = ;   > >>> > As you said, there are multiple way to
&= nbsp;                    =  assign the routing policy by
          &= nbsp;             > in
    &n= bsp;                   > &g= t;>> > the
                     = ;   > >>> > mobile access network. As viewed from
&n= bsp;                     =  the aspect of terminal, I
           = ;             > think
    &nb= sp;                   > >= ;>> > its a
                     = ;   > >>> > good idea that terminal can get its
&nbs= p;                     &n= bsp;routing policy from the ANDSF.
          &n= bsp;             > >>> [Peny] AND= SF may be one of the choices.
                     = ;  But ANDSF just follows the
          &n= bsp;             > >>> assumption= of generic "one default link"
        &nb= sp;              IP model. So, in 3GPP, = even
                  &nbs= p;     > >>> though ANDSF can help UE to select
                     = ;  accesses and find the route, UE can
        =                 > >>> o= nly choose one of the interfaces as a
         =              result.
    &= nbsp;                   > &= gt;>> Personally, I'm not sure if it's a good
                     = ;  way to rely on ANDSF of 3GPP,
         =               > >>> since i= t's a specific definition in one SDO.
        &n= bsp;               > >>
&nbs= p;                     &n= bsp; > >> ANDSF in 3GPP 23.401 do cover only 3GPP
                     = ;  network, how could ANDSF work
         =               > for
   =                     >= >> 23.402 for non-3GPP access still a issue,
     =                  it may need = some mechanism to
                     = ;   > >> coordinate
          &nb= sp;             > >> between two typ= e of access entwork.what do
            &n= bsp;          you think?
      &= nbsp;                 > >>=
                    &= nbsp;   > >>>
                     = ;   > >>> > We think a default policy can be used,
&= nbsp;                    =   when terminal can't find
          =               > >>> > cor= responding policy in the routing
                     = ;  policy from the ANDSF. The
          &n= bsp;             > default
   = ;                     >= ; >>> > policy can be sent by the network.
    &nb= sp;                   > >= ;>> [Peny] Could we give a chance to MN to
                     = ;  change the policy (like user
          =               > >>> preferen= ce) ?
                  &nb= sp;     > >>>
          &= nbsp;             > >>> > On a= nother hand, I am a little confused
                     = ;  between MIF and Multihoming,
          =               > >>> > wou= ld
                   =     > >>> > you please help me to clarify the
=                      = ;  difference between them?
                     = ;   > >>> [Peny] I am also not clear yet. Just give
&nb= sp;                     &= nbsp;some lines as a seed for
            =             > >>> discussion. In = my personal feeling, MIF
                     = ;  is to change the "one default
        &= nbsp;               > >>> li= nk" feature of current generic IP
         = ;              model. Multi-homing is to= ensure
                  &= nbsp;     > >>> the reachability and reliability of I= P
                     = ;  network. Well, in multi-homing
         = ;               > >>> MN sce= narios, multi-link-multi-address is
          &= nbsp;            also one case. But, in this<= br>                    &n= bsp;   > >>> case, MN only can choose one link as default.=
                     = ;   > >>> Some other comments?
      &nb= sp;                 > >>                    &nb= sp;   > >> To challenge one default link, it really
 =                     &nbs= p;takes time for mif to consider
                     = ;   > on
               =         > >> it, current first step in mif is= to
                   = ;    consider some straight forward way
      &= nbsp;                 > which                    &nbs= p;   > >> is simple to resolve some issues.
                     = ;   > >> Regarding to multi-homing, I guess that it
 =                     &nbs= p;is more site multi-homing.
            &= nbsp;           > >> For last multi-link-= multi-address mn's
                     = ;  scenario, it will be one of MIF
        &nbs= p;               > >> scenario.=
                    &= nbsp;   > >>
            &nb= sp;           > >> thanks
   = ;                     >= ; >>
                     = ;   > >> -Hui
            &n= bsp;           > >>
    &nbs= p;                   > >= >>
                  =       > >>> BRG
        &= nbsp;               > >>> Pe= ny
                     = ;   > >>
              =           > >
       =                 > >
 = ;                     &nb= sp; > _______________________________________________
    &= nbsp;                   > m= if mailing list
                  =       > mif@ietf.org <mailto:mif@ietf.org>=20

              =           > https://www.ietf.org/mailman/listinfo/= mif
                  &= nbsp;    _______________________________________________
                     = ;  mif mailing list
           =            mif@ietf.org <mailto:mif@ietf.org>=20

              =          https://www.ietf.org/mailman/listinfo/mif


                 =  _______________________________________________
                   mif ma= iling list
               =    mif@ietf.or= g <mailto:mif@ietf= .org>=20

              =      https://www.ietf.org/mailman/listinfo/mif


<= br>
--------------------------------------------------------------------= ----

_______________________________________________
mif mailing list
= mif@ietf.org
https://= www.ietf.org/mailman/listinfo/mif
_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif

--00151757357cf1ec07046130820f-- --===============0494352708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0494352708==-- From mif-bounces@ietf.org Fri Jan 23 17:55:53 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250A63A696D; Fri, 23 Jan 2009 17:55:53 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D75D3A696D for ; Fri, 23 Jan 2009 17:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKfLa6XudhDi for ; Fri, 23 Jan 2009 17:55:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 5A60B3A67C1 for ; Fri, 23 Jan 2009 17:55:48 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY00A3VDC8GY@szxga01-in.huawei.com> for mif@ietf.org; Sat, 24 Jan 2009 09:55:21 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDY00GPQDC8T6@szxga01-in.huawei.com> for mif@ietf.org; Sat, 24 Jan 2009 09:55:20 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDY004BADC7EK@szxml05-in.huawei.com> for mif@ietf.org; Sat, 24 Jan 2009 09:55:20 +0800 (CST) Date: Sat, 24 Jan 2009 09:55:19 +0800 From: Yungui Wang To: "Joel M. Halpern" , mif@ietf.org Message-id: <005901c97dc6$cfdbb990$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901181847m267dc298p851fbc77447390a3@mail.gmail.com> <1d38a3350901182305p7c17b710kd05da64e0ebad42@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> <497A0612.4060702@joelhalpern.com> Cc: gongxiaoyu Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887644943==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0887644943== Content-type: multipart/alternative; boundary="Boundary_(ID_QrTadTvyA+/+Nl+WpeWiRQ)" This is a multi-part message in MIME format. --Boundary_(ID_QrTadTvyA+/+Nl+WpeWiRQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hello Please see inline... ----- Original Message -----=20 From: Joel M. Halpern=20 To: mif@ietf.org=20 Sent: Saturday, January 24, 2009 2:01 AM Subject: Re: [mif] mobility issues and general issues on mif Reading the discussion on this list, and the problem statement draft, = I=20 want to call attention to the fact that you are getting into a=20 significant amount of mission creep (extending the target scope well=20 beyond the problem statement. [Yungui] In this phase, I think, the mission is not very clear yet. I = was just shooting out a bullet related to MIF. It can be droped/picked = up if we can justify something pointless or senseful.=20 In particular, this discussion leads to issues that would require=20 changes to transport behavior, host stack structure, and routing=20 structure. All of the issues that lead to that are valid issues.=20 However, they are also under investigation in other parts of the=20 community (Transport area, Internet Area, and Routing Research Group.) = [Yungui] I just want to clarify whether MIF is concerning that issue. = Nothing of solution is. =20 Resolving those problems is going to take significant time. Please,=20 help with all of those issues. But if you want to make progress on = the=20 issues called out in the problem statement draft, it would be a good=20 idea to narrow the scope, not expand it. [Yungui] Something reasonable. However, I am trying to clarify the = concrete issue whether is in the scope of MIF. Do you mean the scope has = been identified (e.g. in the base ps draft) and can be closed now? As a final caveat, while it is tempting it is an extremely bad idea to = try to add all of the system routing intelligence to the local node.=20 Even the system does not have good visibility to many of the = properties=20 (actual path availability is only approximated, for example). Using=20 information the host / node already has is a very good idea. Trying = to=20 get all the routing information (so as, for example, to have a better=20 guess as to which interface can actually reach a given destination)=20 would be a very bad idea. [Yungui] Do nothing is the best news. But it (routing, etc.) should be = guaranteed fine-tuned.=20 B.R. Yungui To restate, there are real problems, identified in the base draft, = which=20 are tricky to solve. If we want to solve them in a timely fashion, we = need to keep to a small set of problems. Yours, Joel M. Halpern Yungui Wang wrote: >=20 > Hello, Hui > =20 > Agree with your statement. However, it (the app/flow has to be=20 > restarted when interface-handoff happens) is actually an app/flow=20 > mobility issue related to multiple interfaces. Thus, it seems the=20 > working item MIF is the just place to resolve it. Hope it make = sense. :_) > =20 > B.R. > Yungui > =20 >=20 > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com > ; mif@ietf.org > > *Sent:* Friday, January 23, 2009 4:32 PM > *Subject:* Re: [mif] mobility issues and general issues on mif >=20 > Hello, Yungui, > =20 > Excuse me for misunderstanding your point, > reply inline below. >=20 > 2009/1/23 Yungui Wang > >=20 > Hello Hui > =20 > Sorry for late response. In my understanding, one issue of = MIF > is interface selection (or named access selection). However, > interface selection of a MIF-node is serving for its = up-layer > app/flow.=20 >=20 > some mobile phone can do it, but normally, like PC application = don't > do it, it is up to network > socket to choose source address, then interface is automatically > selected. > =20 >=20 > When one link associated with one interface of MIF-node is = down > or congested, interface re-selection is needed. That's one = type > of mobility of app/flow between different interfaces I = wanted to > address. =20 >=20 > If one interface is down or congested, then application will be = down > as well, this socket will close as well, and you would like to = move > some application, then you have to restart to do it. > =20 > thanks for the discussion. > =20 > -Hui >=20 > Maybe IP address model is related to how to do. Please = forget it. > =20 > B.R. > Yungui > =20 >=20 > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com > ; = mif@ietf.org > > *Sent:* Thursday, January 22, 2009 2:26 PM > *Subject:* Re: [mif] mobility issues and general issues = on mif >=20 > Hi, Yungui, > =20 > mif is targetting at multiple interface whatever it has = how > many ip address on each of them. > I guess that you are asking more IPv6 related question. > =20 > What I feel what ever per interface or per IP address, = how > it is related to mobility of application? > we are not handling handover related issues. > =20 > Thanks for the discussion. > Regards, > =20 > -Hui >=20 >=20 > =20 > 2009/1/22 Yungui Wang > >=20 > Hello Hui > =20 > One comments, whether is the IP address > model to be investigated within MIF? For example, = there > are different types of IP address model for > MIF-terminal, per IP address per IF, one IP address > for multiple IF(s), etc. If considered that, = mobility of > application/flow over IP layer seems impliedly to be > studied (e.g. in topic of IP route changing). > =20 > B.R. > Yungui > =20 >=20 > ----- Original Message ----- > *From:* Hui Deng > *To:* pierrick.seite@orange-ftgroup.com > > *Cc:* mif@ietf.org > *Sent:* Wednesday, January 21, 2009 11:23 PM > *Subject:* Re: [mif] mobility issues and general > issues on mif >=20 > Hi, pierrick, > =20 > Thanks for joining the disucssion, speaking for > mobile operator is quite helpful for mif's work, > Your experience is appreicate, see reply inline = below, > 2009/1/20 > >=20 > Hi all, >=20 > I've joined recently this ML and I believe > discussed topics very interesting (BTW = thanks to > MIF promoters for bringing these issues to > IETF). So, please let me jump into your = discussion. >=20 > Thanks again. > =20 >=20 >=20 > Regarding difference between MIF and > multihoming: it seems there is confusion = with > mobility. AFAIU, MIF is only supposed to = deal > with routing issue at the multi-interface MN > side. The issue is to select the "best" > interface for each outgoing IP flow and, in = MIF > context, access selection does not = necessarily > imply flow mobility with IP session = continuity > between interfaces. Nevertheless, solution > should work for terminal with several active > interfaces at the same time (multi-homed), = or > for terminal with a single interface at a = time. > Am I correct? >=20 > As you said here, flow mobility and IP session > continuity is out of scope at the moment. > I cann't agree with any more about your left = words. > =20 >=20 >=20 >=20 > Regarding ANDSF issue, I agree with = preceding > emails: I think access selection should rely = on > policy. There are a couple of selection = models > but the simplest is the selection managed by = the > terminal and based on local policies and > measurement on the access link. The policies = may > be provided/updated by a server via = out-of-band > mechanism or on-demand (typically before > selection) if policies include "dynamic" > recommendation (e.g. access xx is overload = and > forbidden to application type yy). Now you = can > call the policy server ANDSF, or whatever = you > want, it is just a generic functional entity = in > the architecture and this entity is above = all > access networks. Note the access selection = via > policy server meet MIF requirement as well = as > selection in inter-access mobility = situation. >=20 > Most mobile terminal has implemented the policy > based selection models. > Howver I would like to raise one case, sometime, = if > the network congested, terminal couldn't visit > policy server such as ANDSF, only network side = know > what happen, they may re-arrange some traffic = for > mobile terminal, I guess that this is been = discussed > in 3GPP SA2 side at the moment. > =20 >=20 >=20 >=20 > Please do not hesitate to correct me if I > misunderstood MIF issues. >=20 > thanks for the discussion. > =20 > -Hui >=20 >=20 >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De : mif-bounces@ietf.org > > [mailto:mif-bounces@ietf.org > ] De la part de = Peny > > Yang > > Envoy=E9 : lundi 19 janvier 2009 15:10 > > =C0 : Kai Ju > > Cc : mif@ietf.org > > Objet : Re: [mif] mobility issues and = general > issues on mif > > > > Hi, Kai: > > > The ANSDF solution is just a sample, > because there is no one type of > > server > > > which is > > > defined to provide the policy in IETF = until > now. So let us consider it > > be > > > general, which > > > means it's one policy server that = provides > the routing policy to UE when > > UE > > > is connecting > > > it. > > [Peny] Agree. 3GPP ANSDF could be a good > reference when we make the > > MIF solutions. > > > > BRG > > Peny > > > > > > > > >> > > >> Hi, Peng and Kai, > > >> > > >> See reply inline below. thanks for the > discussion. > > >> 2009/1/19 Peny Yang > > > > >>> > > >>> Hi, Kai: > > >>> Nice point. Please check the lines = below: > > >>> > > >>> > As you said, there are multiple way = to > assign the routing policy by > > in > > >>> > the > > >>> > mobile access network. As viewed = from > the aspect of terminal, I > > think > > >>> > its a > > >>> > good idea that terminal can get its > routing policy from the ANDSF. > > >>> [Peny] ANDSF may be one of the = choices. > But ANDSF just follows the > > >>> assumption of generic "one default = link" > IP model. So, in 3GPP, even > > >>> though ANDSF can help UE to select > accesses and find the route, UE can > > >>> only choose one of the interfaces as = a > result. > > >>> Personally, I'm not sure if it's a = good > way to rely on ANDSF of 3GPP, > > >>> since it's a specific definition in = one SDO. > > >> > > >> ANDSF in 3GPP 23.401 do cover only = 3GPP > network, how could ANDSF work > > for > > >> 23.402 for non-3GPP access still a = issue, > it may need some mechanism to > > >> coordinate > > >> between two type of access = entwork.what do > you think? > > >> > > >>> > > >>> > We think a default policy can be = used, > when terminal can't find > > >>> > corresponding policy in the routing > policy from the ANDSF. The > > default > > >>> > policy can be sent by the network. > > >>> [Peny] Could we give a chance to MN = to > change the policy (like user > > >>> preference) ? > > >>> > > >>> > On another hand, I am a little = confused > between MIF and Multihoming, > > >>> > would > > >>> > you please help me to clarify the > difference between them? > > >>> [Peny] I am also not clear yet. Just = give > some lines as a seed for > > >>> discussion. In my personal feeling, = MIF > is to change the "one default > > >>> link" feature of current generic IP > model. Multi-homing is to ensure > > >>> the reachability and reliability of = IP > network. Well, in multi-homing > > >>> MN scenarios, = multi-link-multi-address is > also one case. But, in this > > >>> case, MN only can choose one link as = default. > > >>> Some other comments? > > >> > > >> To challenge one default link, it = really > takes time for mif to consider > > on > > >> it, current first step in mif is to > consider some straight forward way > > which > > >> is simple to resolve some issues. > > >> Regarding to multi-homing, I guess = that it > is more site multi-homing. > > >> For last multi-link-multi-address mn's > scenario, it will be one of MIF > > >> scenario. > > >> > > >> thanks > > >> > > >> -Hui > > >> > > >>> > > >>> BRG > > >>> Peny > > >> > > > > > > > > = _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > = _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif= --Boundary_(ID_QrTadTvyA+/+Nl+WpeWiRQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hello
 
Please see inline...
 
----- Original Message -----
From:=20 Joel M.=20 Halpern
Sent: Saturday, January 24, = 2009 2:01=20 AM
Subject: Re: [mif] mobility = issues and=20 general issues on mif

Reading the discussion on this list, and the problem statement = draft, I=20
want to call attention to the fact that you are getting into a=20
significant amount of mission creep (extending the target scope = well=20
beyond the problem statement.
[Yungui] In this phase, I think, the = mission is=20 not very clear yet. I was just shooting out a bullet=20 related to MIF. It can be droped/picked up if we can justify something pointless or=20 senseful. 

In particular, this discussion leads = to issues=20 that would require
changes to transport behavior, host stack = structure,=20 and routing
structure.  All of the issues that lead to that = are valid=20 issues.
However, they are also under investigation in other parts = of the=20
community (Transport area, Internet Area, and Routing Research = Group.)=20
[Yungui] I just want = to clarify whether=20 MIF is concerning that issue. Nothing of=20 solution is. 
 
Resolving those problems is going to take significant time.  = Please,=20
help with all of those issues.  But if you want to make = progress on=20 the
issues called out in the problem statement draft, it would be = a good=20
idea to narrow the scope, not expand it.
[Yungui] Something=20 reasonable. However, I am trying to clarify the = concrete issue=20 whether is in the scope of MIF. Do you mean the scope has been = identified=20 (e.g. in the base ps draft) and can be closed=20 now?

As a final = caveat, while it=20 is tempting it is an extremely bad idea to
try to add all of the = system=20 routing intelligence to the local node.
Even the system does not = have good=20 visibility to many of the properties
(actual path availability is = only=20 approximated, for example).  Using
information the host / = node=20 already has is a very good idea.  Trying to
get all the = routing=20 information (so as, for example, to have a better
guess as to = which=20 interface can actually reach a given destination)
would be a very = bad=20 idea.
[Yungui] Do nothing is the best news. = But it=20 (routing, etc.) should be guaranteed fine-tuned.
 
B.R.
Yungui
 
 
To restate, there are real problems, identified in the base = draft, which=20
are tricky to solve.  If we want to solve them in a timely = fashion,=20 we
need to keep to a small set of problems.
 
Yours,
Joel M. Halpern

Yungui Wang wrote:
> =
>=20 Hello, Hui
> 
> Agree with your statement.  = However, it=20 (the app/flow has to be
> restarted when interface-handoff = happens) is=20 actually an app/flow
> mobility issue related to multiple=20 interfaces.  Thus, it seems the
> working item MIF is the = just=20 place to resolve it.  Hope it make sense. :_)
>  =
>=20 B.R.
> Yungui
> 
> =
>    =20 ----- Original Message -----
>     *From:* = Hui Deng=20 <mailto:denghui02@gmail.com>>    =20 *To:* Yungui Wang <mailto:w52006@huawei.com>
>= ;    =20 *Cc:* pierrick.seite@orange-f= tgroup.com
>    =20 <mailto:pierrick.seite@o= range-ftgroup.com>=20 ; mif@ietf.org
>   &n= bsp;=20 <mailto:mif@ietf.org>
> &nb= sp;  =20 *Sent:* Friday, January 23, 2009 4:32 = PM
>    =20 *Subject:* Re: [mif] mobility issues and general issues on mif
> =
>     Hello,=20 Yungui,
>      =
>    =20 Excuse me for misunderstanding your = point,
>    =20 reply inline below.
>
>     2009/1/23 = Yungui=20 Wang <w52006@huawei.com = <mailto:w52006@huawei.com>>>=20
>         Hello=20 Hui
>         =20
>         Sorry for = late=20 response. In my understanding, one issue of=20 MIF
>         is = interface=20 selection (or named access selection).=20 However,
>         = interface=20 selection of a MIF-node is serving for its=20 up-layer
>         = app/flow.=20
>
>     some mobile phone can do it, = but=20 normally, like PC application don't
>     do = it, it=20 is up to network
>     socket to choose = source=20 address, then interface is = automatically
>    =20 selected.
>     
>=20
>         When one link = associated with one interface of MIF-node is=20 down
>         or = congested,=20 interface re-selection is needed. That's one=20 type
>         of = mobility of=20 app/flow between different interfaces I wanted=20 to
>         = address. =20
>
>     If one interface is down or=20 congested, then application will be = down
>     as=20 well, this socket will close as well, and you would like to=20 move
>     some application, then you have = to=20 restart to do it.
>     =20
>     thanks for the=20 discussion.
>     =20
>     -Hui
>=20
>         Maybe IP = address=20 model is related to how to do. Please forget=20 it.
>         =20
>        =20 B.R.
>        =20 Yungui
>          =
>=20 =
>           = ; =20 ----- Original Message=20 = -----
>          =   =20 *From:* Hui Deng <mailto:denghui02@gmail.com>>           &n= bsp;=20 *To:* Yungui Wang <mailto:w52006@huawei.com>
>= ;            = =20 *Cc:* pierrick.seite@orange-f= tgroup.com
>        &nb= sp;   =20 <mailto:pierrick.seite@o= range-ftgroup.com>=20 ; mif@ietf.org
>   &n= bsp;        =20 <mailto:mif@ietf.org>
> &nb= sp;          =20 *Sent:* Thursday, January 22, 2009 2:26=20 = PM
>          &nb= sp; =20 *Subject:* Re: [mif] mobility issues and general issues on mif
> = =
>           = ; =20 Hi,=20 = Yungui,
>         &nbs= p;   =20 =
>           = ; =20 mif is targetting at multiple interface whatever it has=20 = how
>          &n= bsp; =20 many ip address on each of=20 = them.
>          =   =20 I guess that you are asking more IPv6 related=20 = question.
>         &n= bsp;   =20 =
>           = ; =20 What I feel what ever per interface or per IP address,=20 = how
>          &n= bsp; =20 it is related to mobility of=20 = application?
>         = ;   =20 we are not handling handover related=20 = issues.
>         &nbs= p;   =20 =
>           = ; =20 Thanks for the=20 = discussion.
>         =    =20 = Regards,
>         &nb= sp;   =20 =
>           = ; =20 -Hui
>
>=20 =
>           = ;  =20 =
>           = ; =20 2009/1/22 Yungui Wang <w52006@huawei.com
> &nbs= p;          =20 <mailto:w52006@huawei.com>>>=20 =
>           = ;     =20 Hello=20 = Hui
>          &n= bsp;      =20 =
>           = ;     =20 One comments, whether is the IP=20 = address
>         &nbs= p;      =20 model to be investigated within MIF? For example,=20 = there
>          =       =20 are different types of IP address model=20 = for
>          &n= bsp;     =20 MIF-terminal, per IP address per IF, one IP=20 = address
>         &nbs= p;      =20 for multiple IF(s), etc. If considered that, mobility=20 = of
>          &nb= sp;     =20 application/flow over IP layer seems impliedly to=20 = be
>          &nb= sp;     =20 studied (e.g. in topic of IP route=20 = changing).
>         &= nbsp;       =20 =
>           = ;     =20 = B.R.
>          &= nbsp;     =20 = Yungui
>          = ;       =20
>=20 =
>           = ;         =20 ----- Original Message=20 = -----
>          =           =20 *From:* Hui Deng <mailto:denghui02@gmail.com>>           &n= bsp;        =20 *To:* pierrick.seite@orange-f= tgroup.com
>        &nb= sp;           =20 <mailto:pierrick.seite@o= range-ftgroup.com>
>      &nbs= p;            = ; =20 *Cc:* mif@ietf.org <mailto:mif@ietf.org>
> &nb= sp;           &nbs= p;      =20 *Sent:* Wednesday, January 21, 2009 11:23=20 = PM
>          &nb= sp;         =20 *Subject:* Re: [mif] mobility issues and=20 = general
>         &nbs= p;          =20 issues on mif
>=20 =
>           = ;         =20 Hi,=20 = pierrick,
>         &n= bsp;           =20 =
>           = ;         =20 Thanks for joining the disucssion, speaking=20 = for
>          &n= bsp;         =20 mobile operator is quite helpful for mif's=20 = work,
>          =           =20 Your experience is appreicate, see reply inline=20 = below,
>          = ;          =20 2009/1/20 <pierrick.seite@orange-f= tgroup.com
>        &nb= sp;           =20 <mailto:pierrick.seite@o= range-ftgroup.com>>
>=20 =
>           = ;            =  =20 Hi all,
>=20 =
>           = ;            =  =20 I've joined recently this ML and I=20 = believe
>         &nbs= p;            = ;  =20 discussed topics very interesting (BTW thanks=20 = to
>          &nb= sp;           &nbs= p; =20 MIF promoters for bringing these issues=20 = to
>          &nb= sp;           &nbs= p; =20 IETF). So, please let me jump into your discussion.
>=20 =
>           = ;         =20 Thanks=20 = again.
>          = ;           =20
>
>=20 =
>           = ;            =  =20 Regarding difference between MIF=20 = and
>          &n= bsp;           &nb= sp; =20 multihoming: it seems there is confusion=20 = with
>          &= nbsp;           &n= bsp; =20 mobility. AFAIU, MIF is only supposed to=20 = deal
>          &= nbsp;           &n= bsp; =20 with routing issue at the multi-interface=20 = MN
>          &nb= sp;           &nbs= p; =20 side. The issue is to select the=20 = "best"
>          = ;            =   =20 interface for each outgoing IP flow and, in=20 = MIF
>          &n= bsp;           &nb= sp; =20 context, access selection does not=20 = necessarily
>         =             &= nbsp;  =20 imply flow mobility with IP session=20 = continuity
>         &= nbsp;           &n= bsp;  =20 between interfaces. Nevertheless,=20 = solution
>         &nb= sp;           &nbs= p;  =20 should work for terminal with several=20 = active
>          = ;            =   =20 interfaces at the same time (multi-homed),=20 = or
>          &nb= sp;           &nbs= p; =20 for terminal with a single interface at a=20 = time.
>          =             &= nbsp; =20 Am I correct?
>=20 =
>           = ;         =20 As you said here, flow mobility and IP=20 = session
>         &nbs= p;          =20 continuity is out of scope at the=20 = moment.
>         &nbs= p;          =20 I cann't agree with any more about your left=20 = words.
>          = ;           =20
>
>
>=20 =
>           = ;            =  =20 Regarding ANDSF issue, I agree with=20 = preceding
>         &n= bsp;           &nb= sp;  =20 emails: I think access selection should rely=20 = on
>          &nb= sp;           &nbs= p; =20 policy. There are a couple of selection=20 = models
>          = ;            =   =20 but the simplest is the selection managed by=20 = the
>          &n= bsp;           &nb= sp; =20 terminal and based on local policies=20 = and
>          &n= bsp;           &nb= sp; =20 measurement on the access link. The policies=20 = may
>          &n= bsp;           &nb= sp; =20 be provided/updated by a server via=20 = out-of-band
>         =             &= nbsp;  =20 mechanism or on-demand (typically=20 = before
>          = ;            =   =20 selection) if policies include=20 = "dynamic"
>         &n= bsp;           &nb= sp;  =20 recommendation (e.g. access xx is overload=20 = and
>          &n= bsp;           &nb= sp; =20 forbidden to application type yy). Now you=20 = can
>          &n= bsp;           &nb= sp; =20 call the policy server ANDSF, or whatever=20 = you
>          &n= bsp;           &nb= sp; =20 want, it is just a generic functional entity=20 = in
>          &nb= sp;           &nbs= p; =20 the architecture and this entity is above=20 = all
>          &n= bsp;           &nb= sp; =20 access networks. Note the access selection=20 = via
>          &n= bsp;           &nb= sp; =20 policy server meet MIF requirement as well=20 = as
>          &nb= sp;           &nbs= p; =20 selection in inter-access mobility situation.
>=20 =
>           = ;         =20 Most mobile terminal has implemented the=20 = policy
>          = ;          =20 based selection=20 = models.
>         &nbs= p;          =20 Howver I would like to raise one case, sometime,=20 = if
>          &nb= sp;         =20 the network congested, terminal couldn't=20 = visit
>          =           =20 policy server such as ANDSF, only network side=20 = know
>          &= nbsp;         =20 what happen, they may re-arrange some traffic=20 = for
>          &n= bsp;         =20 mobile terminal, I guess that this is been=20 = discussed
>         &n= bsp;          =20 in 3GPP SA2 side at the=20 = moment.
>         &nbs= p;           =20
>
>
>=20 =
>           = ;            =  =20 Please do not hesitate to correct me if=20 = I
>          &nbs= p;            = ; =20 misunderstood MIF issues.
>=20 =
>           = ;         =20 thanks for the=20 = discussion.
>         =              = =
>           = ;         =20 -Hui
>
>
>=20 =
>           = ;            =  =20 = Regards,
>         &nb= sp;           &nbs= p;  =20 Pierrick
>=20 =
>           = ;            =   =20 > -----Message=20 = d'origine-----
>        &nb= sp;           &nbs= p;    =20 > De : mif-bounces@ietf.org
>&nbs= p;            = ;           =20 <mailto:mif-bounces@ietf.org><= BR>>           =             &= nbsp;=20 = [mailto:mif-bounces@ietf.org
>      &= nbsp;           &n= bsp;     =20 <mailto:mif-bounces@ietf.org>]= =20 De la part de=20 = Peny
>          &= nbsp;           &n= bsp;  =20 >=20 = Yang
>          &= nbsp;           &n= bsp;  =20 > Envoy=E9 : lundi 19 janvier 2009=20 = 15:10
>          =             &= nbsp;  =20 > =C0 : Kai=20 = Ju
>          &nb= sp;           &nbs= p;  =20 > Cc : mif@ietf.org <mailto:mif@ietf.org>
> &nb= sp;           &nbs= p;           =20 > Objet : Re: [mif] mobility issues and=20 = general
>         &nbs= p;            = ;  =20 issues on=20 = mif
>          &n= bsp;           &nb= sp;  =20 = >
>          &= nbsp;           &n= bsp;  =20 > Hi,=20 = Kai:
>          &= nbsp;           &n= bsp;  =20 > > The ANSDF solution is just a=20 = sample,
>         &nbs= p;            = ;  =20 because there is no one type=20 = of
>          &nb= sp;           &nbs= p;  =20 >=20 = server
>          = ;            =    =20 > > which=20 = is
>          &nb= sp;           &nbs= p;  =20 > > defined to provide the policy in IETF=20 = until
>          =             &= nbsp; =20 now. So let us consider=20 = it
>          &nb= sp;           &nbs= p;  =20 >=20 = be
>          &nb= sp;           &nbs= p;  =20 > > general,=20 = which
>          =             &= nbsp;  =20 > > means it's one policy server that=20 = provides
>         &nb= sp;           &nbs= p;  =20 the routing policy to UE=20 = when
>          &= nbsp;           &n= bsp;  =20 >=20 = UE
>          &nb= sp;           &nbs= p;  =20 > > is=20 = connecting
>         &= nbsp;           &n= bsp;   =20 > >=20 = it.
>          &n= bsp;           &nb= sp;  =20 > [Peny] Agree. 3GPP ANSDF could be a=20 = good
>          &= nbsp;           &n= bsp; =20 reference when we make=20 = the
>          &n= bsp;           &nb= sp;  =20 > MIF=20 = solutions.
>         &= nbsp;           &n= bsp;   =20 = >
>          &= nbsp;           &n= bsp;  =20 >=20 = BRG
>          &n= bsp;           &nb= sp;  =20 >=20 = Peny
>          &= nbsp;           &n= bsp;  =20 = >
>          &= nbsp;           &n= bsp;  =20 = >
>          &= nbsp;           &n= bsp;  =20 = >
>          &= nbsp;           &n= bsp;  =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >> Hi, Peng and=20 = Kai,
>          &= nbsp;           &n= bsp;  =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >> See reply inline below. thanks for=20 = the
>          &n= bsp;           &nb= sp; =20 = discussion.
>         =             &= nbsp;   =20 > >> 2009/1/19 Peny=20 = Yang
>          &= nbsp;           &n= bsp; =20 <peng.yang.chn@gmail.com
&g= t;            = ;            = =20 <mailto:peng.yang.chn@gmail.com>>
>         &n= bsp;           &nb= sp;   =20 >=20 = >>>
>         = ;            =     =20 > >>> Hi,=20 = Kai:
>          &= nbsp;           &n= bsp;  =20 > >>> Nice point. Please check the lines=20 = below:
>          = ;            =    =20 >=20 = >>>
>         = ;            =     =20 > >>> > As you said, there are multiple way=20 = to
>          &nb= sp;           &nbs= p; =20 assign the routing policy=20 = by
>          &nb= sp;           &nbs= p;  =20 >=20 = in
>          &nb= sp;           &nbs= p;  =20 > >>> >=20 = the
>          &n= bsp;           &nb= sp;  =20 > >>> > mobile access network. As viewed=20 = from
>          &= nbsp;           &n= bsp; =20 the aspect of terminal,=20 = I
>          &nbs= p;            = ;  =20 >=20 = think
>          =             &= nbsp;  =20 > >>> > its=20 = a
>          &nbs= p;            = ;  =20 > >>> > good idea that terminal can get=20 = its
>          &n= bsp;           &nb= sp; =20 routing policy from the=20 = ANDSF.
>          = ;            =    =20 > >>> [Peny] ANDSF may be one of the=20 = choices.
>         &nb= sp;           &nbs= p;  =20 But ANDSF just follows=20 = the
>          &n= bsp;           &nb= sp;  =20 > >>> assumption of generic "one default=20 = link"
>          =             &= nbsp; =20 IP model. So, in 3GPP,=20 = even
>          &= nbsp;           &n= bsp;  =20 > >>> though ANDSF can help UE to=20 = select
>          = ;            =   =20 accesses and find the route, UE=20 = can
>          &n= bsp;           &nb= sp;  =20 > >>> only choose one of the interfaces as=20 = a
>          &nbs= p;            = ; =20 = result.
>         &nbs= p;            = ;   =20 > >>> Personally, I'm not sure if it's a=20 = good
>          &= nbsp;           &n= bsp; =20 way to rely on ANDSF of=20 = 3GPP,
>          =             &= nbsp;  =20 > >>> since it's a specific definition in one=20 = SDO.
>          &= nbsp;           &n= bsp;  =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >> ANDSF in 3GPP 23.401 do cover only=20 = 3GPP
>          &= nbsp;           &n= bsp; =20 network, how could ANDSF=20 = work
>          &= nbsp;           &n= bsp;  =20 >=20 = for
>          &n= bsp;           &nb= sp;  =20 > >> 23.402 for non-3GPP access still a=20 = issue,
>          = ;            =   =20 it may need some mechanism=20 = to
>          &nb= sp;           &nbs= p;  =20 > >>=20 = coordinate
>         &= nbsp;           &n= bsp;   =20 > >> between two type of access entwork.what=20 = do
>          &nb= sp;           &nbs= p; =20 you=20 = think?
>          = ;            =    =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 >=20 = >>>
>         = ;            =     =20 > >>> > We think a default policy can be=20 = used,
>          =             &= nbsp;  =20 when terminal can't=20 = find
>          &= nbsp;           &n= bsp;  =20 > >>> > corresponding policy in the=20 = routing
>         &nbs= p;            = ;  =20 policy from the ANDSF.=20 = The
>          &n= bsp;           &nb= sp;  =20 >=20 = default
>         &nbs= p;            = ;   =20 > >>> > policy can be sent by the=20 = network.
>         &nb= sp;           &nbs= p;   =20 > >>> [Peny] Could we give a chance to MN=20 = to
>          &nb= sp;           &nbs= p; =20 change the policy (like=20 = user
>          &= nbsp;           &n= bsp;  =20 > >>> preference)=20 = ?
>          &nbs= p;            = ;  =20 >=20 = >>>
>         = ;            =     =20 > >>> > On another hand, I am a little=20 = confused
>         &nb= sp;           &nbs= p;  =20 between MIF and=20 = Multihoming,
>         = ;            =     =20 > >>> >=20 = would
>          =             &= nbsp;  =20 > >>> > you please help me to clarify=20 = the
>          &n= bsp;           &nb= sp; =20 difference between=20 = them?
>          =             &= nbsp;  =20 > >>> [Peny] I am also not clear yet. Just=20 = give
>          &= nbsp;           &n= bsp; =20 some lines as a seed=20 = for
>          &n= bsp;           &nb= sp;  =20 > >>> discussion. In my personal feeling,=20 = MIF
>          &n= bsp;           &nb= sp; =20 is to change the "one=20 = default
>         &nbs= p;            = ;   =20 > >>> link" feature of current generic=20 = IP
>          &nb= sp;           &nbs= p; =20 model. Multi-homing is to=20 = ensure
>          = ;            =    =20 > >>> the reachability and reliability of=20 = IP
>          &nb= sp;           &nbs= p; =20 network. Well, in=20 = multi-homing
>         = ;            =     =20 > >>> MN scenarios, multi-link-multi-address=20 = is
>          &nb= sp;           &nbs= p; =20 also one case. But, in=20 = this
>          &= nbsp;           &n= bsp;  =20 > >>> case, MN only can choose one link as=20 = default.
>         &nb= sp;           &nbs= p;   =20 > >>> Some other=20 = comments?
>         &n= bsp;           &nb= sp;   =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >> To challenge one default link, it=20 = really
>          = ;            =   =20 takes time for mif to=20 = consider
>         &nb= sp;           &nbs= p;   =20 >=20 = on
>          &nb= sp;           &nbs= p;  =20 > >> it, current first step in mif is=20 = to
>          &nb= sp;           &nbs= p; =20 consider some straight forward=20 = way
>          &n= bsp;           &nb= sp;  =20 >=20 = which
>          =             &= nbsp;  =20 > >> is simple to resolve some=20 = issues.
>         &nbs= p;            = ;   =20 > >> Regarding to multi-homing, I guess that=20 = it
>          &nb= sp;           &nbs= p; =20 is more site=20 = multi-homing.
>        &nbs= p;            = ;    =20 > >> For last multi-link-multi-address=20 = mn's
>          &= nbsp;           &n= bsp; =20 scenario, it will be one of=20 = MIF
>          &n= bsp;           &nb= sp;  =20 > >>=20 = scenario.
>         &n= bsp;           &nb= sp;   =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >>=20 = thanks
>          = ;            =    =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 > >>=20 = -Hui
>          &= nbsp;           &n= bsp;  =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 >=20 = >>>
>         = ;            =     =20 > >>>=20 = BRG
>          &n= bsp;           &nb= sp;  =20 > >>>=20 = Peny
>          &= nbsp;           &n= bsp;  =20 >=20 = >>
>         &nb= sp;           &nbs= p;   =20 >=20 = >
>          &= nbsp;           &n= bsp;  =20 >=20 = >
>          &= nbsp;           &n= bsp;  =20 >=20 = _______________________________________________
>   =             &= nbsp;         =20 > mif mailing=20 = list
>          &= nbsp;           &n= bsp;  =20 > mif@ietf.org <mailto:mif@ietf.org>
> &nb= sp;           &nbs= p;           =20 > https://www.ietf.org/m= ailman/listinfo/mif
>       =             &= nbsp;    =20 = _______________________________________________
>   =             &= nbsp;        =20 mif mailing=20 = list
>          &= nbsp;           &n= bsp; =20 mif@ietf.org <mailto:mif@ietf.org>
> &nb= sp;           &nbs= p;          =20 https://www.ietf.org/m= ailman/listinfo/mif
>=20
>=20 =
>           = ;         =20 = _______________________________________________
>   =             &= nbsp;    =20 mif mailing=20 = list
>          &= nbsp;         =20 mif@ietf.org <mailto:mif@ietf.org>
> &nb= sp;           &nbs= p;      =20 https://www.ietf.org/m= ailman/listinfo/mif
>=20
>
>
>
>=20 = ------------------------------------------------------------------------<= BR>>=20
> _______________________________________________
> mif = mailing=20 list
> mif@ietf.org
> = https://www.ietf.org/m= ailman/listinfo/mif
______________________________________________= _
mif=20 mailing list
mif@ietf.org
https://www.ietf.org/m= ailman/listinfo/mif
--Boundary_(ID_QrTadTvyA+/+Nl+WpeWiRQ)-- --===============0887644943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0887644943==-- From mif-bounces@ietf.org Fri Jan 23 19:16:56 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0A728C1B2; Fri, 23 Jan 2009 19:16:56 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C68528C1B2 for ; Fri, 23 Jan 2009 19:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwkdohoqrwyM for ; Fri, 23 Jan 2009 19:16:55 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 727F128C1A3 for ; Fri, 23 Jan 2009 19:16:54 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sat, 24 Jan 2009 12:16:36 +0900 X-ReadCheckMessageID: <222c5664-1427-48f7-9b5a-bc1b1da08df5@etri.re.kr> X-ReadCheckName: mif%40ietf.org Priority: normal From: "Hong Yong-Geun" To: "Hui Deng" Content-Class: urn:content-classes:message Date: Sat, 24 Jan 2009 12:16:36 +0900 MIME-Version: 1.0 Comment: ??, u-??, X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <040801c97dd2$2a851a20$8310fe81@etri.info> X-Mailer: Microsoft CDO for Exchange 2000 in-reply-to: <1d38a3350901220639i42eab505w9e40a6e9c02aedbf@mail.gmail.com> X-MS-Has-Attach: Importance: normal X-MS-TNEF-Correlator: Thread-Topic: [mif] mobility issues and general issues on mif thread-index: Acl8n0Ujh+DYCpZ9QtWvgZjAOA0lUwBKMcgAAAKHjn4= References: <8ba101c97154$1dbae930$8310fe81@etri.info> <1d38a3350901131420p6555d18dmb61f885ac3c2a533@mail.gmail.com> <1d38a3350901142247p5cb940e5nd7423f4441c7925e@mail.gmail.com> <1d38a3350901182337k5d08a312t705622e1237f2a9b@mail.gmail.com> <1d38a3350901220639i42eab505w9e40a6e9c02aedbf@mail.gmail.com> X-OriginalArrivalTime: 24 Jan 2009 03:16:36.0877 (UTC) FILETIME=[2AA413D0:01C97DD2] Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590119029==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1590119029== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97DD1.E15CEC10" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C97DD1.E15CEC10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C97DD1.E15CEC10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDsmbmJzcDsgPCEtLSBzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTeXN0ZW07DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1w aXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDE1MTM4ODE2MCAxNiAwIDUyNDI4OCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk66rW066a8Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxOw0KCW1zby1mb250 LWFsdDpHdWxpbTsNCgltc28tZm9udC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFu Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTYxMDYx MTk4NSAxMTA3MzA0NjgzIDAgMCAxNTkgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLr p5HsnYAg6rOg65SVIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDsNCgltc28tZm9u dC1jaGFyc2V0OjEyOTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xODc5MDQ3NTA1IDE2NTEx NzE3OSAxOCAwIDUyNDI4OSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA6rW066a8 IjsNCglwYW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEy OTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6dmFy aWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xMzQyMTc2NTkzIDE3NzU3Mjk5MTUgNDggMCA1 MjQ0NDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOunkeydgCDqs6DrlJUiOw0K CXBhbm9zZS0xOjIgMTEgNSAzIDIgMCAwIDIgMCA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTI5Ow0K CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTE4NzkwNDc1MDUgMTY1MTE3MTc5IDE4IDAgNTI0Mjg5 IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25h dHVyZToxNjI3NDAwODM5IC0yMTQ3NDgzNjQ4IDggMCA2NjA0NyAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU3lzdGVtIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0K CW1zby1mb250LWNoYXJzZXQ6MTI5Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJ bXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmF1dG87DQoJbXNvLWZvbnQt c2lnbmF0dXJlOjEgMTUxMzg4MTYwIDE2IDAgNTI0Mjg4IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFy ZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5Ouq1 tOumvDsNCgltc28tYmlkaS1mb250LWZhbWlseTrqtbTrprw7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJs aW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9 DQpwDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRv dy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrqtbTrprw7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk66rW066a8O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHls ZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28tYXNjaWkt Zm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9y LWxhdGluOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiLrp5HsnYAg6rOg65SVIjsNCgltc28t ZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWZhcmVhc3Q7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiLrp5HsnYAg6rOg65SVIjsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1m b250Om1pbm9yLWJpZGk7DQoJY29sb3I6IzFGNDk3RDsNCgltc28tdGhlbWVjb2xvcjpkYXJrMjt9 DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCnNw YW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJv cHM6eWVzOw0KCW1zby1hc2NpaS1mb250LWZhbWlseToi66eR7J2AIOqzoOuUlSI7DQoJbXNvLWFz Y2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktdGhlbWUtZm9udDptaW5vci1iaWRpO30NCkBwYWdlIFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjozLjBjbSA3Mi4wcHQgNzIu MHB0IDcyLjBwdDsNCgltc28taGVhZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJn aW46MzYuMHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT48L1NUWUxFIC0tPg0KPERJViBsYW5nPUtPIHN0eWxlPSJ0YWItaW50ZXJ2 YWw6IDQwLjBwdCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8RElWIGNsYXNzPVNlY3Rp b24xPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1z by1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0 aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFy azIiPkhpLCA8U1BBTiBjbGFzcz1TcGVsbEU+SHVpPC9TUEFOPi48P3htbDpuYW1lc3BhY2UgcHJl Zml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+ PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn 66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhl bWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVh c3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBt c28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250 LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFy ZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlu b3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJp ZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5UaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEu MHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsg bXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1m b250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6Dr lJUnOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1p bm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFu c2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29s b3I6IGRhcmsyIj5JIGFncmVlIHRvIHlvdXIgc3VnZ2VzdGVkIGFwcHJvYWNoIHRvIGNsYXJpZnkg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBteSBwcm9wb3NhbCBhbmQ8QlI+SmFyaeKAmXMgY29tbWVu dHMgNiAoVHVubmVsIG11bHRpaG9taW5nKS48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1z aXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJz cDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7 IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28t dGhlbWVjb2xvcjogZGFyazIiPkkgd2lsbCBtYWtlIGEgc3VtbWFyeSBhbmQgY3Jvc3MtcG9zdCB0 byB0aGUgbWV4dC9taWYgYm90aC48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAx MS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhl bWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGlu OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1l LWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqz oOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDog bWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1o YW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVj b2xvcjogZGFyazIiPkFsdGhvdWdoIGl0IHNlZW1zIHRoYXQgbXkgZHJhZnQgbmFtZSB3YXMgcXVp dGUgcmVsYXRlZCB0byBtZXh0IHdnLCBJIHRoaW5rIHRoYXQgdGhlIHB1cnBvc2Ugb2YgbXkgZHJh ZnRzPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZ OiAn66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWkt dGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZh cmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRp OyBtc28tdGhlbWVjb2xvcjogZGFyazIiPmFyZSBkaWZmZXJlbnQgdG8gdGhlIHNjb3BlIG9mIG1l eHQuIEkgdW5kZXJzdGFuZCB0aGF0IG1leHQgd2cgaXMgdGFyZ2V0aW5nIG9uIHRoZSBleHRlbmRp bmcgb2YgTW9iaWxlIElQdjYvTkVNTzxCUj48U1BBTiBjbGFzcz1HcmFtRT5hbmQ8L1NQQU4+IG15 IHB1cnBvc2UgaXMgdG8gc3VwcG9ydCBtdWx0aXBsZSBpbnRlcmZhY2VzIHdpdGhvdXQgZXh0ZW5k aW5nIG9mIE1vYmlsZSBJUHY2L05FTU8uIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNp emU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFz dC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGkt dGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5Hs nYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1m b250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsg bXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10 aGVtZWNvbG9yOiBkYXJrMiI+VGhhbmtzIGZvciB5b3VyIGVuY291cmFnZW1lbnQuPG86cD48L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR7J2AIOqz oOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDog bWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1o YW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tdGhlbWVj b2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0 OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNpemU6IDEx LjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC10aGVt ZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47 IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUt Zm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5CZXN0IHJlZ2FyZHMuPG86 cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAn66eR 7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7 IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28t dGhlbWVjb2xvcjogZGFyazIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LXNp emU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFz dC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3It bGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGkt dGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLXRoZW1lY29sb3I6IGRhcmsyIj5Zb25nLUdldW48 U1BBTiBjbGFzcz1HcmFtRT4uLjwvU1BBTj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9udC1z aXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby10aGVtZWNvbG9yOiBkYXJrMiI+PG86cD4mbmJz cDs8L286cD48L1NQQU4+PC9QPg0KPERJViBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1M RUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwY207IEJPUkRFUi1MRUZUOiBibHVlIDEuNXB0IHNv bGlkOyBQQURESU5HLVRPUDogMGNtOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+DQo8RElW Pg0KPERJViBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDog MGNtOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFERElORy1MRUZUOiAwY207IFBB RERJTkctQk9UVE9NOiAwY207IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6 IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxC PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L1NQQU4+PC9CPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+ IEh1aSBEZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGdtYWlsLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBU aHVyc2RheSwgSmFudWFyeSAyMiwgMjAwOSAxMTo0MCBQTTxCUj48Qj5Ubzo8L0I+IDwvU1BBTj48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogVGFob21h OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFRhaG9tYTsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBU YWhvbWEiPu2Zjeyaqeq3vDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxCUj48Qj5DYzo8L0I+ IG1pZkBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFttaWZdIG1vYmlsaXR5IGlzc3Vl cyBhbmQgZ2VuZXJhbCBpc3N1ZXMgb24gbWlmPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwv RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT PkhpLCBIb25nLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+SSBlbmNvdXJh Z2UgdG8gY2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHlvdXIgcHJvcG9zYWwmbmJzcDth bmQgSmFyaSdzIGNvbW1lbnRzJm5ic3A7Niwgb3Igd2hpY2ggdG9kbyB3b3JrIGlzIHRoZSBzYW1l IGFzIHlvdXIgcHJvcG9zYWwuPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQ IGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5z aW5jZSB5b3VyJm5ic3A7ZHJhZnQgbmFtZSBpcyBxdWl0ZSByZWxhdGVkIHRvIG1leHQgd2csIHRo YXQncyB0aGUgcmVhc29uJm5ic3A7YXNraW5nIHlvdSB0byBkbyBjb25zdWx0IHdvcmsgd2l0aCBt ZXh0LCB0byBhdm9pZCBmdXR1cmUmbmJzcDtpbnRlcmNvbm5lY3Rpb24gd29yay48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9 RU4tVVM+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPnRoYW5rcyBhZ2Fpbi48bzpwPjwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+ Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiBsYW5nPUVOLVVTPi1IdWk8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8 RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+MjAwOS8xLzE5IEhvbmcg WW9uZy1HZXVuICZsdDs8QSBocmVmPSJtYWlsdG86eWdob25nQGV0cmkucmUua3IiPnlnaG9uZ0Bl dHJpLnJlLmtyPC9BPiZndDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPERJVj4NCjxE SVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SGkuLkh1aS4uPC9TUEFOPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPlRoYW5rIHlvdSBmb3Ig eW91ciBpbnRlcmVzdC48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBtc28t YXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3Rl bSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1J TFk6IFN5c3RlbSI+SSB0aGluayB0aGF0IHRoZSBkaXNjdXNzaW9uIG9mIG11bHRpcGxlIGludGVy ZmFjZXMgaXNzdWVzIHdoaWNoIGlzIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUHY2L05FTU8gaW4g TUVYVCBXRzxCUj5pcyBub3QgdXNlZnVsIGJlY2F1c2UgTUVYVCBXRyBpcyBmb2N1c2luZyBvbiB0 aGUgZXh0ZW5zaW9uIG9mIE1vYmlsZSBJUHY2L05FTU8uIDxCUj5UaGUgaW50ZW5zaW9uIG9mIG15 IHByZXZpb3VzIHR3byBkcmFmdHMgaXMgbm90IGV4dGVuZGluZyBNb2JpbGUgSVB2Ni9ORU1PLjwv U1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZhbWls eTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lz dGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVtIj5JbnN0 ZWFkLCBpZiB5b3Ugd29uZGVyIHRoZSByZXNwb25zZSBvZiBNb25hbWk2IFdHIGZvciBteSBwcmV2 aW91cyB0d28gZHJhZnRzLCB5b3UgY2FuIHJlZmVyIHRoZSA2NHRoIG1vbmFtaTYgV0c8QlI+bWVl dGluZyByZXBvcnQgd2hlbiBJIHByZXNlbnRlZC4gPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQ QU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PEEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy8wNW5vdi9tb25hbWk2Lmh0bWwiIHRhcmdldD1fYmxhbms+aHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wNW5vdi9tb25hbWk2Lmh0bWw8L0E+PC9TUEFOPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1z by1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lz dGVtIj4mbmJzcDsmbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ICg2dGggcHJlc2Vu dGF0aW9uKTwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1m b250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJz cDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lz dGVtIj5UaGFua3MuLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1h c2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVt Ij4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlM WTogU3lzdGVtIj5Zb25nLUdldW4uLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5 N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElW IHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJP UkRFUi1UT1A6IG1lZGl1bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006 IDBjbTsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwY207IEJP UkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCjxESVY+DQo8RElWIHN0eWxlPSJCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYg MXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006IDBjbTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkZyb206PC9TUEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiBIdWkgRGVuZyBbbWFp bHRvOjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29tIiB0YXJnZXQ9X2JsYW5rPmRl bmdodWkwMkBnbWFpbC5jb208L0E+XSA8QlI+PEI+U2VudDo8L0I+IE1vbmRheSwgSmFudWFyeSAx OSwgMjAwOSA0OjM4IFBNPEJSPjxCPlRvOjwvQj4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPu2Zjeyaqeq3vCA8U1BBTiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9TUEFOPjwvU1BBTj48L1A+DQo8RElWPg0KPERJVj4NCjxQIGNsYXNzPU1z b05vcm1hbD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPjxCUj48Qj5DYzo8L0I+IDxBIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmci IHRhcmdldD1fYmxhbms+bWlmQGlldGYub3JnPC9BPjxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtt aWZdIG1vYmlsaXR5IGlzc3VlcyBhbmQgZ2VuZXJhbCBpc3N1ZXMgb24gbWlmPG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPjwvRElWPjwvRElWPjwvRElWPg0KPERJVj4NCjxESVY+DQo8UD48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWls eTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lz dGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5IaSwgSG9uZyw8bzpw PjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48 L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+Q291bGQgeW91IG1ha2UgYSBzaG9ydCBz dW1tYXJ5ICwgY3Jvc3MtcG9zdCB0byB0aGUgbWV4dC9taWYsIGFuZCBjYyB0byBjaGFpcnMsIGFu ZDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPnNlZSB0aGVpciBj b21tZW50cz88bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj5NYW55 IHRoYW5rczxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lz dGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48 bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4tSHVpPG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+MjAwOS8xLzE1IEhvbmcgWW9uZy1H ZXVuICZsdDs8QSBocmVmPSJtYWlsdG86eWdob25nQGV0cmkucmUua3IiIHRhcmdldD1fYmxhbms+ eWdob25nQGV0cmkucmUua3I8L0E+Jmd0OzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8 RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNj aWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+ Jm5ic3A7Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxESVY+DQo8 RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SGkuLkh1aS4uPC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48 L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogIzFmNDk3ZDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPk5vLCBJIGRpZG4ndCBkaXNjdXNz IHdpdGggbWV4dCB3Zy4gSSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCB3aXRoIG1vbmFtaTYgd2cg YXQgNjR0aCBJRVRGIG1lZXRpbmcuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0K PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+QW5kIGl0IHdhcyBub3QgYWRvcHRlZCBpbiBtb25hbWk2 IHdnIGJlY2F1c2UgaXQgd2FzIG5vdCBpbiB0aGUgc2NvcGUgb2YgbW9uYW1pNiB3Zy48L1NQQU4+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lz dGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5 c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+ PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+QmVzdCByZWdh cmRzLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250 LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8 L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVt Ij5Zb25nLUdldW4uLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1h c2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVt Ij4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWIHN0eWxlPSJC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6 ICNiNWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1CT1RUT006IDBj bTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0OyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkZyb206PC9TUEFOPjwvQj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPiBIdWkg RGVuZyBbbWFpbHRvOjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29tIiB0YXJnZXQ9 X2JsYW5rPmRlbmdodWkwMkBnbWFpbC5jb208L0E+XSA8QlI+PEI+U2VudDo8L0I+IFRodXJzZGF5 LCBKYW51YXJ5IDE1LCAyMDA5IDM6NDcgUE08QlI+PEI+VG86PC9CPiA8L1NQQU4+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+7ZmN7Jqp6re8IDxTUEFO IGxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9TUEFOPjwvUD4NCjxESVY+DQo8RElWPg0K PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog U3lzdGVtIj48QlI+PEI+Q2M6PC9CPiA8QSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJn ZXQ9X2JsYW5rPm1pZkBpZXRmLm9yZzwvQT48QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbbWlmXSBt b2JpbGl0eSBpc3N1ZXMgYW5kIGdlbmVyYWwgaXNzdWVzIG9uIG1pZjxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj48L0RJVj48L0RJVj4NCjxESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48 L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+eW91IGFscmVhZHkgaGFkIGEgZGlzY3Vz c2lvbiB3aXRoIG1leHQgd2csIHRoZXkgYXJlIG5vdCBhZG9wdGluZyB0aGlzIHdvcms/PG86cD48 L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVt Ij4tSHVpPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPjwvRElWPg0KPERJVj4NCjxE SVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogU3lzdGVtIj4yMDA5LzEvMTQgSG9uZyBZb25nLUdldW4gJmx0OzxBIGhyZWY9 Im1haWx0bzp5Z2hvbmdAZXRyaS5yZS5rciIgdGFyZ2V0PV9ibGFuaz55Z2hvbmdAZXRyaS5yZS5r cjwvQT4mZ3Q7PG86cD48L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxESVY+DQo8UD48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTog U3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDsmbmJzcDs8L1NQ QU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog U3lzdGVtIj4gPG86cD48L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxESVY+DQo8UD48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZB TUlMWTogU3lzdGVtIj5IaS4uSHVpLi48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0 OTdkOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1GQU1JTFk6IFN5c3RlbSI+VGhhbmsgeW91IGZvciBjb21tZW50cy4gU2VlIGJlbG93IGlu bGluZSByZXBseS48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBtc28tYXNj aWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+ Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6 IFN5c3RlbSI+QmVzdCByZWdhcmRzLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5 N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogU3lzdGVtIj5Zb25nLUdldW4uLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48 L1A+DQo8RElWIHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hU OiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBjbTsg UEFERElORy1CT1RUT006IDBjbTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRP UDogM3B0OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+DQo8UD48Qj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkZyb206PC9T UEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPiBIdWkgRGVuZyBbbWFpbHRvOjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJA Z21haWwuY29tIiB0YXJnZXQ9X2JsYW5rPmRlbmdodWkwMkBnbWFpbC5jb208L0E+XSA8QlI+PEI+ U2VudDo8L0I+IFdlZG5lc2RheSwgSmFudWFyeSAxNCwgMjAwOSA3OjIwIEFNPEJSPjxCPlRvOjwv Qj4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPu2Zjeyaqeq3vDxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCPkNjOjwvQj4gPEEgaHJlZj0ibWFp bHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5taWZAaWV0Zi5vcmc8L0E+PEJSPjxCPlN1 YmplY3Q6PC9CPiBSZTogW21pZl0gbW9iaWxpdHkgaXNzdWVzIGFuZCBnZW5lcmFsIGlzc3VlcyBv biBtaWY8bzpwPjwvbzpwPjwvU1BBTj48L1NQQU4+PC9QPjwvRElWPg0KPFA+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3Rl bTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86 cD48L286cD48L1NQQU4+PC9QPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SGksIEhvbmcgWW9uZyw8bzpwPjwv bzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPg0KPERJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPkkgcmVhZCB0aHJvdWdoIHlvdXIg dHdvIGRyYWZ0cywgdW5kZXJzdGFuZCB5b3UgYXJlIHRhbGtpbmcgdGhlIGlzc3VlPC9TUEFOPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFt aWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BB Tj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBT eXN0ZW0iPndpdGhvdXQgTW9uYW1pPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAyMS43NXB0OyBURVhULUlOREVOVDogLTE4cHQiPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZ OiBXaW5nZGluZ3M7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPj88L1NQQU4+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiA3cHQ7IENPTE9SOiAjMWY0OTdkOyBGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IFN5c3RlbSI+Jm5ic3A7IDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVtIj5ZZXMsIHlvdSBh cmUgY29ycmVjdC4gPEJSPkkgd2FudCB0byBzb2x2ZSB0aGUgbXVsdGlwbGUgaW50ZXJmYWNlIHBy b2JsZW1zIHdpdGhvdXQgbW9kaWZ5aW5nIE1vYmlsZSBJUHY2L05FTU8gY29kZS48QlI+KEluIE1v bmFtaTYsIG11bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyAod2hpY2g8L1NQQU4+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgbXNvLWFzY2lp LWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZu YnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMWY0OTdkOyBGT05ULUZBTUlMWTogU3lzdGVtIj5hcmUgcmVsYXRlZCB0byBtb2JpbGl0eSBp c3N1ZXMsIHN1Y2ggYXMgbXVsdGlwbGUgQ29BLDxCUj5tdWx0aXBsZSBIb0EsIGV0Yy4sICkgYXJl IHJlc29sdmluZyBieSBtb2RpZnlpbmcgTW9iaWxlIElQdjYvTkVNTyBwcm90b2NvbCk8L1NQQU4+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lz dGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48QlI+aXQgc2VlbXMg TW9iaWxlIElwdjYgaW50ZXJuYWwgYWxzbyBoYXMgc2ltaWxhciBpc3N1ZSB3aXRoIHVzIGlmIEkg dW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxQ IHN0eWxlPSJNQVJHSU4tTEVGVDogMjEuNzVwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZB TUlMWTogV2luZ2RpbmdzOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4/PC9TUEFO PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogN3B0OyBDT0xPUjogIzFmNDk3ZDsg Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOyA8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+WWVzLCBi ZWNhdXNlIE1vYmlsZSBJUHY2IGlzIGJhc2VkIG9uIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgSVB2 NiwgTW9iaWxlIElQdjYgaW50ZXJuYWw8QlI+aGFzIHNpbWlsYXIgaXNzdWVzIG9mIG1pZi4gU28s IEkgdGhpbmsgdGhhdCBpdCBpcyB2YWx1YWJsZSB0byBzZXBhcmF0ZSBtb3JlIGdlbmVyYWwgaXNz dWVzIGZyb208QlI+bXVsdGlwbGUgaW50ZXJmYWNlIGlzc3VlcyB3aGljaCBhcmUgZGlyZWN0bHkg cmVsYXRlZCB0byBNb2JpbGUgSVB2Ni9ORU1PLjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 ICMxZjQ5N2Q7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQo8RElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+SW4gdGhpcyBjYXNlIEkgd291bGQgbGlrZSB0 byBlbmNvdXJhZ2UgeW91IHRvIHByb3Bvc2UgdGhpcyBpc3N1ZSB0byBvdXIgd29yaywgaWYgYWxs b3dlZCw8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQo8RElWPg0KPERJVj4NCjxQ PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5 c3RlbSI+aXQgbWlnaHRiZSBkb2FibGUgd2l0aGluIG91ciBzY29wZSw8bzpwPjwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDIxLjc1cHQ7IFRFWFQtSU5ERU5U OiAtMThwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5nczsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IFN5c3RlbSI+PzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDdwdDsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDsgPC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZ OiBTeXN0ZW0iPlRoYW5rcy4gSXQgaXMgbXkgcGxlYXN1cmUuLjwvU1BBTj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9v OnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0 ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPm1hbnkgdGhhbmtzPG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCjxESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPi1IdWk8bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+DQo8RElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4yMDA5LzEvNyBIb25nIFlvbmctR2V1biAmbHQ7PEEg aHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJnZXQ9X2JsYW5rPnlnaG9uZ0BldHJp LnJlLmtyPC9BPiZndDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPERJVj4NCjxESVY+ DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBTeXN0ZW0iPkhpLiBtaWYuLjxCUj48QlI+TGV0IG1lIGpvaW4gdGhpcyBkaXNjdXNzaW9uLjxC Uj48QlI+SXQgaXMgdmVyeSBpbnRlcmVzdGluZyB0byBzZWUgbWlmLjxCUj48QlI+QXMgSHVpIERl bmcgc2F5cywgSSB1bmRlcnN0YW5kIHRoYXQgbWlmIGhhcyBkaWZmZXJlbnQgYXBwcm9hY2g8QlI+ ZnJvbSBvdGhlciBXRyBzdWNoIGFzIE1FWFQgYW5kIG1vbmFtaTYgV0csIGV0Yy48QlI+PEJSPklu IE1FWFQsIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGFyZSByZWxhdGVkIHRvIE1vYmlsZSBJ UCwgTkVNTywuLjxCUj5JbiBtaWYsIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGFyZSBkaWZm ZXJlbnQgZnJvbSB0aG9zZSBvZiBNRVhULjxCUj5TbywgaW4gbWlmLCBpdCBpcyBiZXR0ZXIgdG8g ZmluZCBtb3JlIGdlbmVyYWwgaXNzdWVzIHdoaWNoIGFyZSBub3QgcmVsYXRlZCB0byBNb2JpbGUg SVAuPEJSPjxCUj5JIHRoaW5rIHRoYXQgTS5CbGFuY2hldCdzICJNdWx0aXBsZSBJbnRlcmZhY2Vz IFByb2JsZW0gU3RhdGVtZW50IiBkcmFmdCBpczxCUj5hIGdvb2Qgc3RhcnRpbmcgcG9pbnQgdG8g ZGlzY3VzcyBnZW5lcmFsIGlzc3VlcyBvbiBtaWYuPEJSPjxCUj5JIHdvdWxkIGxpa2UgdG8gaW50 cm9kdWNlIGFub3RoZXIgcmVsYXRlZCBkcmFmdHMgd2hpY2ggSSBwcmVzZW50ZWQgYXQgbW9uYW1p NiBXRyBhdCA2NHRoIElFVEYgbWVldGluZy48QlI+PEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4tIEFuYWx5 c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZShkcmFmdC1ob25nLW11 bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwKTxCUj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IDxBIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGIt c3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0IiB0 YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLW11bHRp cGxlaWYtbW4tcGItc3RhdGVtZW50L2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1l bnQtMDAudHh0PC9BPjxCUj48QlI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0ZW07IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPi0gVmlydHVhbCBuZXR3b3JrIGlu dGVyZmFjZSBmb3IgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBub2RlIHVzaW5nIE1v YmlsZSBJUHY2PEJSPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogU3lzdGVtIj4mbmJzcDsmbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj4gKGRyYWZ0LWhvbmctdmlydHVhbGlm LW1uLW1pcHY2LTAwKTxCUj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+IDxBIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9kcmFmdC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni9kcmFmdC1ob25nLXZp cnR1YWxpZi1tbi1taXB2Ni0wMC50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2RyYWZ0L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2L2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2LTAwLnR4dDwvQT48QlI+PEJSPjxCUj5JbiB0aGUgc2VjdGlvbiAyLjIgKEdl bmVyYWwgTmV0d29yayBJc3N1ZXMpIGluIHRoZSBmaXJzdCBkcmFmdCw8QlI+dGhlcmUgYXJlIGdl bmVyYWwgbmV0d29yayBpc3N1ZXMgZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMuPEJSPjxCUj5J bmNsdWRpbmcgdGhlc2UgZHJhZnRzLCBJIGhvcGUgdG8gZW5jb3VyYWdlIHRoaXMgZGlzY3Vzc2lv bjxCUj48QlI+WW9uZy1HZXVuLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJ Vj4NCjxQIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxCUj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5taWYgbWFpbGluZyBsaXN0PEJS PjxBIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+bWlmQGlldGYub3Jn PC9BPjxCUj48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p ZiIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p ZjwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8UD48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogU3lzdGVtOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogU3lzdGVtIj4mbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lzdGVtIj48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9E SVY+DQo8UD48Qj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3lz dGVtIj7smKTrpZg8U1BBTiBsYW5nPUVOLVVTPiEgPC9TUEFOPu2MjOydvCDsnbTrpoTsnbQg7KeA 7KCV65CY7Ja0IOyeiOyngCDslYrsirXri4jri6Q8U1BBTiBsYW5nPUVOLVVTPi48L1NQQU4+PC9T UEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeXN0ZW0iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxQPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBTeXN0 ZW07IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeXN0ZW0iPiZuYnNwOzwvU1BBTj48U1BBTiBs YW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPjxv OnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj48L0RJVj4NCjxQPjxCPjxTUEFO IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0ZW0iPuyYpOulmDxTUEFO IGxhbmc9RU4tVVM+ISA8L1NQQU4+7YyM7J28IOydtOumhOydtCDsp4DsoJXrkJjslrQg7J6I7KeA IOyViuyKteuLiOuLpDxTUEFOIGxhbmc9RU4tVVM+LjwvU1BBTj48L1NQQU4+PC9CPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IFN5c3RlbTsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IFN5c3RlbSI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5c3RlbSI+PG86cD48L286cD48L1NQQU4+ PC9QPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPjxCPuyYpOulmDxTUEFOIGxhbmc9RU4tVVM+ISA8L1NQQU4+7YyM7J28IOydtOum hOydtCDsp4DsoJXrkJjslrQg7J6I7KeAIOyViuyKteuLiOuLpDxTUEFOIGxhbmc9RU4tVVM+Ljwv U1BBTj48L0I+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpu b25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJu YWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9bWlmQGlldGYub3JnJm5hbWU9bWlmJTQwaWV0Zi5vcmcm ZnJvbWVtYWlsPXlnaG9uZ0BldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0MyMjJjNTY2NC0xNDI3LTQ4 ZjctOWI1YS1iYzFiMWRhMDhkZjVAZXRyaS5yZS5rciUzRSI+ ------_=_NextPart_001_01C97DD1.E15CEC10-- --===============1590119029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1590119029==-- From mif-bounces@ietf.org Mon Jan 26 07:33:52 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE423A697B; Mon, 26 Jan 2009 07:33:52 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFE528C1CF for ; Mon, 26 Jan 2009 07:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC9u+k5GHEJk for ; Mon, 26 Jan 2009 07:33:49 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 353C328C20E for ; Mon, 26 Jan 2009 07:33:49 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so566669wag.5 for ; Mon, 26 Jan 2009 07:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/VYPnoXx7V512B0UPPcfY/7BYeaGCtXE/HdnWR6n3aM=; b=YEwDMDT7/6e4Hmgz5EO74Udl5ZWdqmHT9beZY4FMjuDNUkzoIkQtampUc2fBBJebg2 S19drNBkGid7H4LcA3bzGtW/cpzaVUlH8q8g11hOpbN5ug1LltxD1uOmgP5NywZ+UQTh cvM/BoLICiuklZaezrEpbHgX3cczzVSbwWvXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i8k22k9u/qC3z2UVDaxkIvpWLVbtOK8/JwRSrYYN2ZNtZUdmLH8nkmE4lDcCXYAmC+ M2lalJ/rKqE4zvL/YCUVUDqVb5ZkvQ1YJbYh0N0a75B9/74a1sT1Jp7D1Alb6B8Pez+v eTmD/lxvQ9MV/Uk7tboGzvuNPtlsJWeUBN/i4= MIME-Version: 1.0 Received: by 10.114.170.1 with SMTP id s1mr1754849wae.57.1232984011280; Mon, 26 Jan 2009 07:33:31 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Mon, 26 Jan 2009 23:33:31 +0800 Message-ID: <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> From: Hui Deng To: Kevin Chin Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0267568089==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0267568089== Content-Type: multipart/alternative; boundary=0016364c716b0193660461647695 --0016364c716b0193660461647695 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Kevin, I feel that you give two good advice here, Please allow me more clarification inline below: 2009/1/24 Kevin Chin kchin.xor@gmail.com > > 7) Is there a way for the host and the network to communicate about >> their >> > policies regarding all of the above? >> [Peny] For 7, maybe we could make the way for host/PEER/network to >> communicate their policies. Besides, if the policies of MIF node can >> not be followed by the peer node, in this sense, we need a way to >> communicate about the policies among host/peer/network. >> > > "communicate their policies among host/peer/network" seems to imply more > message intensive transfer of state from MS. > Privacy concerns are also legitimate if network needs information from MS > to support MIF. > Are you saying that sending information from MS to network is a kind of disclose privacy concern? can you help to elaborate more on that? > > "policy conflict when >1 operator/network" can not optimize for device > specific policies, there are trade-offs between "monetary cost" and > speed/access/convenience. > I could fee that it will be hard if there is policy confliction.but we can do sth in some scale. for what you said here, convenience and cost can't be achieved simultaneously, what do you mean about "monetary cost" here? thanks for your explanation. -Hui > > thanks > > > On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: > >> Hi, Kevin, >> >> I tend to agree with you here that the terminal may not need to upstream >> the capability to the network. but do you see any proposal here doing that? >> >> but sometime, MS made some decision on the interface and route, but what >> happen if network congested, how to handle that? just waiting for the fall >> back. >> >> For confliction of policy, I guess that it could be categorized by two >> case, >> one operator, then it should be avoided by offline arrangement, >> for two ISPs, FIFO still work there, cause no problem for user's traffic. >> >> thanks for the discussion. >> >> -Tao >> >> >> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: >> >>> >>> >>>> 1) MIF for IPv4 or IPv6 or Both? >>> >>> >>> >>>> >>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>> need to do the harmonization with other protocols? >>>> 3) There is the case that one interface is connected, but the route to >>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>> this case? >>>> >>> >>> > 7) Is there a way for the host and the network to communicate about >>> their >>> > policies regarding all of the above? >>> >>> Very interesting topic. >>> >>> I assume MIF is optional "should" v. "must" w.r.t policies from the >>> network (e.g. guidance not directive). >>> The MS may have lots of policies which can make an informed decision. >>> >>> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. >>> This would imply MS pushing characteristics up to the network so the >>> network can push device-specific directives down. >>> It should not be the case that the device needs to push capabilties >>> upstream for the network to provide MIF-based guidance. >>> >>> Furthermore there may be different networks on each interface >>> necessitating conflict resolution protocols, let alone issues that occur >>> sporadically (e.g. WiFI portal, network roaming policies, access-based >>> policy) .... >>> >>> Can't device based provisioning with (optional) input from network >>> address most of the stated issues? >>> >>> thanks- >>> Kevin >>> >>> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: >>> >>>> Hi, Jari: >>>> >>>> Please check my lines: >>>> >>>> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko >>>> wrote: >>>> > Again, there seems to be two issues. The first issue is having a >>>> policy that >>>> > tells an application which addresses to use (and indirectly which >>>> interface >>>> > to use). The second issue is that if the policy comes, e.g., via DHCP >>>> on a >>>> > per-interface basis, then we again have to reconcile the different >>>> policies >>>> > on a per-node basis. >>>> [Peny] Agree with you for the two issues. Another point in my mind may >>>> be a possible issue. When a peer tries to initiate flows with MIF >>>> node, we need some way to let the peer know the policies and follow >>>> the policies of MIF node. >>>> >>>> > My personal classification of problems in the multiple interface space >>>> > includes the following: >>>> > >>>> > 1) Access selection, i.e., which network(s) to attach to using the >>>> physical >>>> > interface(s) that the host has. Already covered in RFC 5113. >>>> > >>>> > 2) Split DNS: If a host is attached to a number of different >>>> interfaces, how >>>> > does it resolve a FQDN if more than one interface has provided a DNS >>>> server >>>> > address? >>>> > >>>> > 3) Configuration reconciliation: how do we merge and use DHCP and >>>> other >>>> > configuration information in a node, when the information is received >>>> on a >>>> > per-interface basis? >>>> > >>>> > 4) Routing: If a host is attached to a number of different interfaces, >>>> where >>>> > does a particular IP packet go? >>>> > >>>> > 5) Address selection: If a host is attached to a number of different >>>> > interfaces, which addresses should be used for a particular >>>> application >>>> > flow? >>>> > >>>> > 6) Tunnel multihoming: If a host is attached to a number of different >>>> > interfaces and runs some kind of a tunneling or mobility back to a >>>> home >>>> > agent, which interface and addresses should be used for a particular >>>> packet? >>>> > Already covered in existing MEXT WG work items. >>>> [Peny] Agree with you from 1 to 6. >>>> >>>> > 7) Is there a way for the host and the network to communicate about >>>> their >>>> > policies regarding all of the above? >>>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>>> communicate their policies. Besides, if the policies of MIF node can >>>> not be followed by the peer node, in this sense, we need a way to >>>> communicate about the policies among host/peer/network. >>>> >>>> > My understanding is that the proposed BOF would be looking at problems >>>> 2, 3, >>>> > 4, 5, and 7. The others are covered elsewhere. >>>> [Peny] Some other points I have been thinking of: >>>> 1) MIF for IPv4 or IPv6 or Both? >>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>> need to do the harmonization with other protocols? >>>> 3) There is the case that one interface is connected, but the route to >>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>> this case? >>>> >>>> BRG >>>> Peny >>>> >>>> >>>> > Jari >>>> > >>>> > _______________________________________________ >>>> > mif mailing list >>>> > mif@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mif >>>> > >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >> > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --0016364c716b0193660461647695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Kevin,
 
I feel that you give two good advice here,
Please allow me more clarification inline below:

2009/1/24 Kevi= n Chin kchin.xor@g= mail.com
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
[Peny] For 7, maybe we could make the way for host/PEER/network to
= communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.
 
"communicate their policies among host/peer/network" seems t= o imply more message intensive transfer of state from MS.
Privacy concerns are also legitimate if network needs information from= MS to support MIF.
Are you saying that sending information from MS to network is a kind o= f disclose privacy concern? can you help to elaborate more on that?

"policy conflict when >1 operator/network" can not op= timize for device specific policies, there are trade-offs between "mon= etary cost" and speed/access/convenience.
I could fee that it will be hard if there is policy confliction.but we= can do sth in some scale.
for what you said here, convenience and cost can't be achieve= d simultaneously, what do you
mean about "monetary cost" here?
 
thanks for your explanation.
 
-Hui
 
thanks

 
On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <his= untao@gmail.com> wrote:
Hi, Kevin,
 
I tend to agree with you here that the terminal may not need to&n= bsp;upstream the capability to the network. but do you see any proposal her= e doing that?

but sometime, MS made some decision on the interface a= nd route, but what happen if network congested, how to handle that? just wa= iting for the fall back.
 
For confliction of policy, I guess that it could be categorized by two= case,
one operator, then it should be avoided by offline arrangement,
for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
 
thanks for the discussion.
 
-Tao
 
 
On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.com> wrote:
 
1) MIF for IPv4 or IPv6 or Both?=
 

2)  Will M= IF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the = harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:=
> Again, there seems to be two issues. The first issue is having a p= olicy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate= about their
> policies regarding all of the above?
[Peny] F= or 7, maybe we could make the way for host/PEER/network to
communicate t= heir policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at= problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
<= /div>[Peny] Some other points I have been thinking of:
1) MIF for IPv4 o= r IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
= need to do the harmonization with other protocols?
3) There is the case = that one interface is connected, but the route to
internet is not availa= ble (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny


> Jari
>
> ____________________________________= ___________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/list= info/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mif" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinf= o/mif



<= br>_______________________________________________
mif mailing list
<= a href=3D"mailto:mif@ietf.org">mif@ietf.org
https://www.ietf.org/mailma= n/listinfo/mif


--0016364c716b0193660461647695-- --===============0267568089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0267568089==-- From mif-bounces@ietf.org Mon Jan 26 07:38:43 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9306628C234; Mon, 26 Jan 2009 07:38:43 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871D128C235 for ; Mon, 26 Jan 2009 07:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JgQl1feKI2k for ; Mon, 26 Jan 2009 07:38:40 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id A1EC428C215 for ; Mon, 26 Jan 2009 07:38:40 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so567646wag.5 for ; Mon, 26 Jan 2009 07:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vFXaK/F3eM8iiYdNDpvrprxePf3QwWQQ97wlOmOD3p8=; b=Vf05VmfdnCrv3Ax1J0wvKlIN/c4XrJvZOdrTLU77nDVxiw6HfEz6qHFAE0PFRGtV6G qBLJ7ng9mXXqCalDtjnCbCqL1Dajaw1XPCFyW3PCeF/8OGv2WYCM0PColkIZs0JRtWZ2 EoouMRO/WvHuOWSWgrViVyRRyRjDFTAT4t1e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w/AlBGsWOKEjuhmNzK6bqNAie/WTPdpvbvA2VX/u5/tpzJT3TGizrC41s/WjHTM4S/ oyPNun63NvT0D+VS6102JWryIlJiEX6c21a0RClGg7xEyBK4M9Rmqi8GM8bf+UJhX8aG Q5rHp0HyR2M0fdFqHOUjgPo0LvJdpS5HROr84= MIME-Version: 1.0 Received: by 10.115.110.15 with SMTP id n15mr1356832wam.16.1232984302691; Mon, 26 Jan 2009 07:38:22 -0800 (PST) In-Reply-To: <000d01c97d3d$203633f0$150ca40a@china.huawei.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <3db7b9d60901190346y1768d950wec525aed8155a960@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> Date: Mon, 26 Jan 2009 23:38:22 +0800 Message-ID: <1d38a3350901260738g7bf7c7et40c4cf926a2c30d1@mail.gmail.com> From: Hui Deng To: Yungui Wang Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599860878==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1599860878== Content-Type: multipart/alternative; boundary=00163641792b6024d70461648777 --00163641792b6024d70461648777 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yungui, Based on current IP model (RFC 1122 strong and weak model ), without IP mobility involvement, what the operator could do at the moment is crueily stop and restart the service. :) thanks for the disucssion. -Hui 2009/1/23 Yungui Wang > Hello, Hui > > Agree with your statement. However, it (the app/flow has to be restarted > when interface-handoff happens) is actually an app/flow mobility > issue related to multiple interfaces. Thus, it seems the working item > MIF is the just place to resolve it. Hope it make sense. :_) > > B.R. > Yungui > > > ----- Original Message ----- > *From:* Hui Deng > *To:* Yungui Wang > *Cc:* pierrick.seite@orange-ftgroup.com ; mif@ietf.org > *Sent:* Friday, January 23, 2009 4:32 PM > *Subject:* Re: [mif] mobility issues and general issues on mif > > Hello, Yungui, > > Excuse me for misunderstanding your point, > reply inline below. > > 2009/1/23 Yungui Wang > >> Hello Hui >> >> Sorry for late response. In my understanding, one issue of MIF is >> interface selection (or named access selection). However, interface >> selection of a MIF-node is serving for its up-layer app/flow. >> > some mobile phone can do it, but normally, like PC application don't do i= t, > it is up to network > socket to choose source address, then interface is automatically selected= . > > >> When one link associated with one interface of MIF-node is down or >> congested, interface re-selection is needed. That's one type of mobility= of >> app/flow between different interfaces I wanted to address. >> > If one interface is down or congested, then application will be down as > well, this socket will close as well, and you would like to move some > application, then you have to restart to do it. > > thanks for the discussion. > > -Hui > >> Maybe IP address model is related to how to do. Please forget it. >> >> B.R. >> Yungui >> >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* Yungui Wang >> *Cc:* pierrick.seite@orange-ftgroup.com ; mif@ietf.org >> *Sent:* Thursday, January 22, 2009 2:26 PM >> *Subject:* Re: [mif] mobility issues and general issues on mif >> >> Hi, Yungui, >> >> mif is targetting at multiple interface whatever it has how many ip >> address on each of them. >> I guess that you are asking more IPv6 related question. >> >> What I feel what ever per interface or per IP address, how it is related >> to mobility of application? >> we are not handling handover related issues. >> >> Thanks for the discussion. >> Regards, >> >> -Hui >> >> >> >> 2009/1/22 Yungui Wang >> >>> Hello Hui >>> >>> One comments, whether is the IP address model to be investigated within >>> MIF? For example, there are different types of IP address model for >>> MIF-terminal, per IP address per IF, one IP address for multiple IF(s), >>> etc. If considered that, mobility of application/flow over IP layer >>> seems impliedly to be studied (e.g. in topic of IP route changing). >>> >>> B.R. >>> Yungui >>> >>> >>> ----- Original Message ----- >>> *From:* Hui Deng >>> *To:* pierrick.seite@orange-ftgroup.com >>> *Cc:* mif@ietf.org >>> *Sent:* Wednesday, January 21, 2009 11:23 PM >>> *Subject:* Re: [mif] mobility issues and general issues on mif >>> >>> Hi, pierrick, >>> >>> Thanks for joining the disucssion, speaking for mobile operator is quit= e >>> helpful for mif's work, >>> Your experience is appreicate, see reply inline below, >>> 2009/1/20 >>> >>>> Hi all, >>>> >>>> I've joined recently this ML and I believe discussed topics very >>>> interesting (BTW thanks to MIF promoters for bringing these issues to = IETF). >>>> So, please let me jump into your discussion. >>> >>> Thanks again. >>> >>> >>>> >>>> Regarding difference between MIF and multihoming: it seems there is >>>> confusion with mobility. AFAIU, MIF is only supposed to deal with rout= ing >>>> issue at the multi-interface MN side. The issue is to select the "best= " >>>> interface for each outgoing IP flow and, in MIF context, access select= ion >>>> does not necessarily imply flow mobility with IP session continuity be= tween >>>> interfaces. Nevertheless, solution should work for terminal with sever= al >>>> active interfaces at the same time (multi-homed), or for terminal with= a >>>> single interface at a time. Am I correct? >>> >>> As you said here, flow mobility and IP session continuity is out of sco= pe >>> at the moment. >>> I cann't agree with any more about your left words. >>> >>> >>>> >>>> >>>> Regarding ANDSF issue, I agree with preceding emails: I think access >>>> selection should rely on policy. There are a couple of selection model= s but >>>> the simplest is the selection managed by the terminal and based on loc= al >>>> policies and measurement on the access link. The policies may be >>>> provided/updated by a server via out-of-band mechanism or on-demand >>>> (typically before selection) if policies include "dynamic" recommendat= ion >>>> (e.g. access xx is overload and forbidden to application type yy). Now= you >>>> can call the policy server ANDSF, or whatever you want, it is just a g= eneric >>>> functional entity in the architecture and this entity is above all acc= ess >>>> networks. Note the access selection via policy server meet MIF require= ment >>>> as well as selection in inter-access mobility situation. >>> >>> Most mobile terminal has implemented the policy based selection models. >>> Howver I would like to raise one case, sometime, if the network >>> congested, terminal couldn't visit policy server such as ANDSF, only ne= twork >>> side know what happen, they may re-arrange some traffic for mobile term= inal, >>> I guess that this is been discussed in 3GPP SA2 side at the moment. >>> >>> >>>> >>>> >>>> Please do not hesitate to correct me if I misunderstood MIF issues. >>> >>> thanks for the discussion. >>> >>> -Hui >>> >>>> >>>> >>>> Regards, >>>> Pierrick >>>> >>>> > -----Message d'origine----- >>>> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part d= e >>>> Peny >>>> > Yang >>>> > Envoy=E9 : lundi 19 janvier 2009 15:10 >>>> > =C0 : Kai Ju >>>> > Cc : mif@ietf.org >>>> > Objet : Re: [mif] mobility issues and general issues on mif >>>> > >>>> > Hi, Kai: >>>> > > The ANSDF solution is just a sample, because there is no one type = of >>>> > server >>>> > > which is >>>> > > defined to provide the policy in IETF until now. So let us conside= r >>>> it >>>> > be >>>> > > general, which >>>> > > means it's one policy server that provides the routing policy to U= E >>>> when >>>> > UE >>>> > > is connecting >>>> > > it. >>>> > [Peny] Agree. 3GPP ANSDF could be a good reference when we make the >>>> > MIF solutions. >>>> > >>>> > BRG >>>> > Peny >>>> > >>>> > >>>> > >>>> > >> >>>> > >> Hi, Peng and Kai, >>>> > >> >>>> > >> See reply inline below. thanks for the discussion. >>>> > >> 2009/1/19 Peny Yang >>>> > >>> >>>> > >>> Hi, Kai: >>>> > >>> Nice point. Please check the lines below: >>>> > >>> >>>> > >>> > As you said, there are multiple way to assign the routing poli= cy >>>> by >>>> > in >>>> > >>> > the >>>> > >>> > mobile access network. As viewed from the aspect of terminal, = I >>>> > think >>>> > >>> > its a >>>> > >>> > good idea that terminal can get its routing policy from the >>>> ANDSF. >>>> > >>> [Peny] ANDSF may be one of the choices. But ANDSF just follows t= he >>>> > >>> assumption of generic "one default link" IP model. So, in 3GPP, >>>> even >>>> > >>> though ANDSF can help UE to select accesses and find the route, = UE >>>> can >>>> > >>> only choose one of the interfaces as a result. >>>> > >>> Personally, I'm not sure if it's a good way to rely on ANDSF of >>>> 3GPP, >>>> > >>> since it's a specific definition in one SDO. >>>> > >> >>>> > >> ANDSF in 3GPP 23.401 do cover only 3GPP network, how could ANDSF >>>> work >>>> > for >>>> > >> 23.402 for non-3GPP access still a issue, it may need some >>>> mechanism to >>>> > >> coordinate >>>> > >> between two type of access entwork.what do you think? >>>> > >> >>>> > >>> >>>> > >>> > We think a default policy can be used, when terminal can't fi= nd >>>> > >>> > corresponding policy in the routing policy from the ANDSF. The >>>> > default >>>> > >>> > policy can be sent by the network. >>>> > >>> [Peny] Could we give a chance to MN to change the policy (like >>>> user >>>> > >>> preference) ? >>>> > >>> >>>> > >>> > On another hand, I am a little confused between MIF and >>>> Multihoming, >>>> > >>> > would >>>> > >>> > you please help me to clarify the difference between them? >>>> > >>> [Peny] I am also not clear yet. Just give some lines as a seed f= or >>>> > >>> discussion. In my personal feeling, MIF is to change the "one >>>> default >>>> > >>> link" feature of current generic IP model. Multi-homing is to >>>> ensure >>>> > >>> the reachability and reliability of IP network. Well, in >>>> multi-homing >>>> > >>> MN scenarios, multi-link-multi-address is also one case. But, in >>>> this >>>> > >>> case, MN only can choose one link as default. >>>> > >>> Some other comments? >>>> > >> >>>> > >> To challenge one default link, it really takes time for mif to >>>> consider >>>> > on >>>> > >> it, current first step in mif is to consider some straight forwar= d >>>> way >>>> > which >>>> > >> is simple to resolve some issues. >>>> > >> Regarding to multi-homing, I guess that it is more site >>>> multi-homing. >>>> > >> For last multi-link-multi-address mn's scenario, it will be one o= f >>>> MIF >>>> > >> scenario. >>>> > >> >>>> > >> thanks >>>> > >> >>>> > >> -Hui >>>> > >> >>>> > >>> >>>> > >>> BRG >>>> > >>> Peny >>>> > >> >>>> > > >>>> > > >>>> > _______________________________________________ >>>> > mif mailing list >>>> > mif@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mif >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >> > --00163641792b6024d70461648777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yungui,
 
Based on current IP model (RFC 1122 strong and weak model ), with= out IP mobility involvement, what the operator could do at the moment is cr= ueily stop and restart the service. :)
 
thanks for the disucssion.
 
-Hui

2009/1/23 Yungui Wang <w52006@huawei.com>
Hello, Hui
 
Agree with your statement.  However, it (the app/flow has to be r= estarted when interface-handoff happens) is actually an app/flow mobility i= ssue related to multiple interfaces.  Thus, it see= ms the working item MIF is the just place to resolve it.  Ho= pe it make sense. :_)
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Friday, January 23, 2009 4:32 = PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hello, Yungui,
 
Excuse me for misunderstanding your point,
reply inline below.

2009/1/23 Yungui Wang <w52006@huawei.com>= ;
Hello Hui
 
Sorry for late response. In my underst= anding, one issue of MIF is interface selection (or named access selection)= . However, interface selection of a MIF-node is serving for = its up-layer app/flow.
some mobile phone can do it, but normally, like PC application don'= ;t do it, it is up to network
socket to choose source address, then interface is automatically selec= ted.
 
When one link associated = with one interface of MIF-node is down or congested, interface re= -selection is needed. That's one type of mobility of app= /flow between different interfaces I wanted to address. 
If one interface is down or congested, then application will be down a= s well, this socket will close as well, and you would like to move some app= lication, then you have to restart to do it.
 
thanks for the discussion.
 
-Hui
Maybe IP address model is related to h= ow to do. Please forget it.
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Thursday, January 22, 2009 2:2= 6 PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hi, Yungui,
 
mif is targetting at multiple interface whatever it has how many ip ad= dress on each of them.
I guess that you are asking more IPv6 related question.
 
What I feel what ever per interface or per IP address, how it is relat= ed to mobility of application?
we are not handling handover related issues.
 
Thanks for the discussion.
Regards,
 
-Hui


 
2009/1/22 Yungui Wang <w52006@huawei.com>= ;
Hello Hui
 
One comments, whether is the IP a= ddress model to be investigated within MIF? For example, there are different types of IP address= model for MIF-terminal, per IP addr= ess per IF, one IP address for = multiple IF(s), etc. If considered t= hat, mobility of application/flow over IP layer seems impliedly to be studi= ed (e.g. in topic of IP route changing).
 
B.R.
Yungui
 
----- Original Message -----
From: Hui Deng
Sent: Wednesday, January 21, 2009 11= :23 PM
Subject: Re: [mif] mobility issues a= nd general issues on mif

Hi, pierrick,
 
Thanks for joining the disucssion, speaking for mobile operator is qui= te helpful for mif's work,
Your experience is appreicate, see reply inline below,
2009/1/20 <pierrick.seite@orang= e-ftgroup.com>
Hi all,

I've joined r= ecently this ML and I believe discussed topics very interesting (BTW thanks= to MIF promoters for bringing these issues to IETF). So, please let me jum= p into your discussion.
Thanks again.
 

Regarding difference between= MIF and multihoming: it seems there is confusion with mobility. AFAIU, MIF= is only supposed to deal with routing issue at the multi-interface MN side= . The issue is to select the "best" interface for each outgoing I= P flow and, in MIF context, access selection does not necessarily imply flo= w mobility with IP session continuity between interfaces. Nevertheless, sol= ution should work for terminal with several active interfaces at the same t= ime (multi-homed), or for terminal with a single interface at a time. Am I = correct?
As you said here, flow mobility and IP session continuity is out = of scope at the moment.
I cann't agree with any more about your left words.
 


Regarding A= NDSF issue, I agree with preceding emails: I think access selection should = rely on policy. There are a couple of selection models but the simplest is = the selection managed by the terminal and based on local policies and measu= rement on the access link. The policies may be provided/updated by a server= via out-of-band mechanism or on-demand (typically before selection) if pol= icies include "dynamic" recommendation (e.g. access xx is overloa= d and forbidden to application type yy). Now you can call the policy server= ANDSF, or whatever you want, it is just a generic functional entity in the= architecture and this entity is above all access networks. Note the access= selection via policy server meet MIF requirement as well as selection in i= nter-access mobility situation.
Most mobile terminal has implemented the policy based selection models= .
Howver I would like to raise one case, sometime, if the network conges= ted, terminal couldn't visit policy server such as ANDSF, only network = side know what happen, they may re-arrange some traffic for mobile terminal= , I guess that this is been discussed in 3GPP SA2 side at the moment.
 


Please do n= ot hesitate to correct me if I misunderstood MIF issues.
thanks for the discussion.
 
-Hui


Regards,Pierrick

> -----Message d'origine-----
> De : mif-bounces@ietf.org= [mailto:mif-= bounces@ietf.org] De la part de Peny
> Yang
> Envoy=E9 : lundi 19 janvier 2009 15:10
> =C0&n= bsp;: Kai Ju
> Cc : mif@ietf.org
> Objet : Re: [mif] mobility issues and g= eneral issues on mif
>
> Hi, Kai:
> > The ANSDF solution is just a sample= , because there is no one type of
> server
> > which is
&= gt; > defined to provide the policy in IETF until now. So let us conside= r it
> be
> > general, which
> > means it's one policy = server that provides the routing policy to UE when
> UE
> > = is connecting
> > it.
> [Peny] Agree. 3GPP ANSDF could be a = good reference when we make the
> MIF solutions.
>
> BRG
> Peny
>
>
>= ;
> >>
> >> Hi, Peng and Kai,
> >>
&= gt; >> See reply inline below. thanks for the discussion.
> >= ;> 2009/1/19 Peny Yang <peng.yang.chn@gmail.com>
> >>>
> >>> Hi, Kai:
> >>> Nice p= oint. Please check the lines below:
> >>>
> >>&g= t; > As you said, there are multiple way to assign the routing policy by=
> in
> >>> > the
> >>> > mobile acce= ss network. As viewed from the aspect of terminal, I
> think
> = >>> > its a
> >>> > good idea that terminal c= an get its routing policy from the ANDSF.
> >>> [Peny] ANDSF may be one of the choices. But ANDSF just fo= llows the
> >>> assumption of generic "one default link= " IP model. So, in 3GPP, even
> >>> though ANDSF can he= lp UE to select accesses and find the route, UE can
> >>> only choose one of the interfaces as a result.
> &g= t;>> Personally, I'm not sure if it's a good way to rely on A= NDSF of 3GPP,
> >>> since it's a specific definition in = one SDO.
> >>
> >> ANDSF in 3GPP 23.401 do cover only 3GPP netw= ork, how could ANDSF work
> for
> >> 23.402 for non-3GPP = access still a issue, it may need some mechanism to
> >> coordi= nate
> >> between two type of access entwork.what do you think?
>= >>
> >>>
> >>> > We think a default= policy can be used,  when terminal can't find
> >>>= ; > corresponding policy in the routing policy from the ANDSF. The
> default
> >>> > policy can be sent by the network.> >>> [Peny] Could we give a chance to MN to change the polic= y (like user
> >>> preference) ?
> >>>
> >>> > On another hand, I am a little confused between MIF = and Multihoming,
> >>> > would
> >>> > = you please help me to clarify the difference between them?
> >>= > [Peny] I am also not clear yet. Just give some lines as a seed for
> >>> discussion. In my personal feeling, MIF is to change the = "one default
> >>> link" feature of current generi= c IP model. Multi-homing is to ensure
> >>> the reachability= and reliability of IP network. Well, in multi-homing
> >>> MN scenarios, multi-link-multi-address is also one case. = But, in this
> >>> case, MN only can choose one link as defa= ult.
> >>> Some other comments?
> >>
> >= ;> To challenge one default link, it really takes time for mif to consid= er
> on
> >> it, current first step in mif is to consider some = straight forward way
> which
> >> is simple to resolve so= me issues.
> >> Regarding to multi-homing, I guess that it is m= ore site multi-homing.
> >> For last multi-link-multi-address mn's scenario, it will = be one of MIF
> >> scenario.
> >>
> >> = thanks
> >>
> >> -Hui
> >>
> >= >>
> >>> BRG
> >>> Peny
> >>
> &g= t;
> >
> _______________________________________________
> mif maili= ng list
> mif@ietf.= org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing list<= br>mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif




--00163641792b6024d70461648777-- --===============1599860878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1599860878==-- From mif-bounces@ietf.org Mon Jan 26 07:59:38 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C2228C17C; Mon, 26 Jan 2009 07:59:37 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE14428C17C for ; Mon, 26 Jan 2009 07:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g39HXvq9NFXW for ; Mon, 26 Jan 2009 07:59:31 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 5FC4A3A689F for ; Mon, 26 Jan 2009 07:59:31 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so6750294wfd.31 for ; Mon, 26 Jan 2009 07:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=m7d7RLErwOyrK9GvmxbokFsFljZLLbLV8re9K//afw0=; b=sw0Ins6Wa9UlKWv9sK48RgxWX9++a51XZr699iKmvC2JUlYaKy3X6an0qaE/aKaJAn My2+XlyaX6+E9UNriyfXavWwO9b5ezYzUP5bg5+zAbqdnMsPooSAfNrYJC/Q9twbete1 sM/82Rmm8cfRVVOf9jsHQp9q/rMtq1sCkxJ+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mcmTPa7w22ohdcq2PZ7x6CpxbAKvc6D7wmA53gdkNlcdq1HDLXjiNMlTyzWok72oNS qXNu7fRpWi2XX2Nm0xJjLqucdn7qJyg748s3wtzbC4g9g3rHBx2hgfu200o2M6d01GB9 ahS1ODUolMJb4Hx0qZlWRaS5s1c1yllgiRZTo= MIME-Version: 1.0 Received: by 10.114.152.17 with SMTP id z17mr469044wad.91.1232985552974; Mon, 26 Jan 2009 07:59:12 -0800 (PST) In-Reply-To: <497A0612.4060702@joelhalpern.com> References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <4c5c7a6d0901190610h72e5ba29kdd0cb137180aa53c@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> <497A0612.4060702@joelhalpern.com> Date: Mon, 26 Jan 2009 23:59:12 +0800 Message-ID: <1d38a3350901260759v399fcebbwea84aba2508d5dd5@mail.gmail.com> From: Hui Deng To: "Joel M. Halpern" Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1499537353==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1499537353== Content-Type: multipart/alternative; boundary=00163646d566e5f5a7046164d129 --00163646d566e5f5a7046164d129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Joel, I saw your attentions are very good advice here. we will avoid to overlap with multipath transport and Multihoming site et al. To finish the timeline work is our top focus, it implies that current PS drafts will our main target. Regarding to your caveat, to better use information host already has will b= e good idea, other than let host be a wisdom. Thanks for your suggestions. Regards, -Hui 2009/1/24 Joel M. Halpern > Reading the discussion on this list, and the problem statement draft, I > want to call attention to the fact that you are getting into a significan= t > amount of mission creep (extending the target scope well beyond the probl= em > statement. > > In particular, this discussion leads to issues that would require changes > to transport behavior, host stack structure, and routing structure. All = of > the issues that lead to that are valid issues. However, they are also und= er > investigation in other parts of the community (Transport area, Internet > Area, and Routing Research Group.) Resolving those problems is going to t= ake > significant time. Please, help with all of those issues. But if you wan= t > to make progress on the issues called out in the problem statement draft,= it > would be a good idea to narrow the scope, not expand it. > > As a final caveat, while it is tempting it is an extremely bad idea to tr= y > to add all of the system routing intelligence to the local node. Even the > system does not have good visibility to many of the properties (actual pa= th > availability is only approximated, for example). Using information the h= ost > / node already has is a very good idea. Trying to get all the routing > information (so as, for example, to have a better guess as to which > interface can actually reach a given destination) would be a very bad ide= a. > > To restate, there are real problems, identified in the base draft, which > are tricky to solve. If we want to solve them in a timely fashion, we ne= ed > to keep to a small set of problems. > > Yours, > Joel M. Halpern > > Yungui Wang wrote: > >> >> Hello, Hui >> Agree with your statement. However, it (the app/flow has to be restart= ed >> when interface-handoff happens) is actually an app/flow mobility issue >> related to multiple interfaces. Thus, it seems the working item MIF is = the >> just place to resolve it. Hope it make sense. :_) >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* Yungui Wang >> *Cc:* pierrick.seite@orange-ftgroup.com >> ; mif@ietf.org >> >> *Sent:* Friday, January 23, 2009 4:32 PM >> *Subject:* Re: [mif] mobility issues and general issues on mif >> >> Hello, Yungui, >> Excuse me for misunderstanding your point, >> reply inline below. >> >> 2009/1/23 Yungui Wang > >> >> Hello Hui >> Sorry for late response. In my understanding, one issue o= f >> MIF >> is interface selection (or named access selection). However, >> interface selection of a MIF-node is serving for its up-layer >> app/flow. >> some mobile phone can do it, but normally, like PC application don't >> do it, it is up to network >> socket to choose source address, then interface is automatically >> selected. >> >> When one link associated with one interface of MIF-node is down >> or congested, interface re-selection is needed. That's one type >> of mobility of app/flow between different interfaces I wanted to >> address. >> If one interface is down or congested, then application will be down >> as well, this socket will close as well, and you would like to move >> some application, then you have to restart to do it. >> thanks for the discussion. >> -Hui >> >> Maybe IP address model is related to how to do. Please forget it. >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* Yungui Wang >> *Cc:* pierrick.seite@orange-ftgroup.com >> ; mif@ietf.org >> >> *Sent:* Thursday, January 22, 2009 2:26 PM >> *Subject:* Re: [mif] mobility issues and general issues on mi= f >> >> Hi, Yungui, >> mif is targetting at multiple interface whatever = it >> has how >> many ip address on each of them. >> I guess that you are asking more IPv6 related question. >> What I feel what ever per interface or per IP >> address, how >> it is related to mobility of application? >> we are not handling handover related issues. >> Thanks for the discussion. >> Regards, >> -Hui >> >> >> 2009/1/22 Yungui Wang > > >> >> Hello Hui >> One comments, whether is the IP address >> model to be investigated within MIF? For example, there >> are different types of IP address model for >> MIF-terminal, per IP address per IF, one IP address >> for multiple IF(s), etc. If considered that, mobility of >> application/flow over IP layer seems impliedly to be >> studied (e.g. in topic of IP route changing). >> B.R. >> Yungui >> >> ----- Original Message ----- >> *From:* Hui Deng >> *To:* pierrick.seite@orange-ftgroup.com >> >> *Cc:* mif@ietf.org >> *Sent:* Wednesday, January 21, 2009 11:23 PM >> *Subject:* Re: [mif] mobility issues and general >> issues on mif >> >> Hi, pierrick, >> Thanks for joining the disucssion= , >> speaking for >> mobile operator is quite helpful for mif's work, >> Your experience is appreicate, see reply inline below= , >> 2009/1/20 > > >> >> >> Hi all, >> >> I've joined recently this ML and I believe >> discussed topics very interesting (BTW thanks to >> MIF promoters for bringing these issues to >> IETF). So, please let me jump into your discussio= n. >> >> Thanks again. >> >> >> Regarding difference between MIF and >> multihoming: it seems there is confusion with >> mobility. AFAIU, MIF is only supposed to deal >> with routing issue at the multi-interface MN >> side. The issue is to select the "best" >> interface for each outgoing IP flow and, in MIF >> context, access selection does not necessarily >> imply flow mobility with IP session continuity >> between interfaces. Nevertheless, solution >> should work for terminal with several active >> interfaces at the same time (multi-homed), or >> for terminal with a single interface at a time. >> Am I correct? >> >> As you said here, flow mobility and IP session >> continuity is out of scope at the moment. >> I cann't agree with any more about your left words. >> >> >> >> Regarding ANDSF issue, I agree with preceding >> emails: I think access selection should rely on >> policy. There are a couple of selection models >> but the simplest is the selection managed by the >> terminal and based on local policies and >> measurement on the access link. The policies may >> be provided/updated by a server via out-of-band >> mechanism or on-demand (typically before >> selection) if policies include "dynamic" >> recommendation (e.g. access xx is overload and >> forbidden to application type yy). Now you can >> call the policy server ANDSF, or whatever you >> want, it is just a generic functional entity in >> the architecture and this entity is above all >> access networks. Note the access selection via >> policy server meet MIF requirement as well as >> selection in inter-access mobility situation. >> >> Most mobile terminal has implemented the policy >> based selection models. >> Howver I would like to raise one case, sometime, if >> the network congested, terminal couldn't visit >> policy server such as ANDSF, only network side know >> what happen, they may re-arrange some traffic for >> mobile terminal, I guess that this is been discussed >> in 3GPP SA2 side at the moment. >> >> >> >> Please do not hesitate to correct me if I >> misunderstood MIF issues. >> >> thanks for the discussion. >> -Hui >> >> >> >> Regards, >> Pierrick >> >> > -----Message d'origine----- >> > De : mif-bounces@ietf.org >> >> [mailto:mif-bounces@ietf.org >> ] De la part de Peny >> > Yang >> > Envoy=E9 : lundi 19 janvier 2009 15:10 >> > =C0 : Kai Ju >> > Cc : mif@ietf.org >> >> > Objet : Re: [mif] mobility issues and general >> issues on mif >> > >> > Hi, Kai: >> > > The ANSDF solution is just a sample, >> because there is no one type of >> > server >> > > which is >> > > defined to provide the policy in IETF until >> now. So let us consider it >> > be >> > > general, which >> > > means it's one policy server that provides >> the routing policy to UE when >> > UE >> > > is connecting >> > > it. >> > [Peny] Agree. 3GPP ANSDF could be a good >> reference when we make the >> > MIF solutions. >> > >> > BRG >> > Peny >> > >> > >> > >> > >> >> > >> Hi, Peng and Kai, >> > >> >> > >> See reply inline below. thanks for the >> discussion. >> > >> 2009/1/19 Peny Yang >> > > >> >> > >>> >> > >>> Hi, Kai: >> > >>> Nice point. Please check the lines below: >> > >>> >> > >>> > As you said, there are multiple way to >> assign the routing policy by >> > in >> > >>> > the >> > >>> > mobile access network. As viewed from >> the aspect of terminal, I >> > think >> > >>> > its a >> > >>> > good idea that terminal can get its >> routing policy from the ANDSF. >> > >>> [Peny] ANDSF may be one of the choices. >> But ANDSF just follows the >> > >>> assumption of generic "one default link" >> IP model. So, in 3GPP, even >> > >>> though ANDSF can help UE to select >> accesses and find the route, UE can >> > >>> only choose one of the interfaces as a >> result. >> > >>> Personally, I'm not sure if it's a good >> way to rely on ANDSF of 3GPP, >> > >>> since it's a specific definition in one SD= O. >> > >> >> > >> ANDSF in 3GPP 23.401 do cover only 3GPP >> network, how could ANDSF work >> > for >> > >> 23.402 for non-3GPP access still a issue, >> it may need some mechanism to >> > >> coordinate >> > >> between two type of access entwork.what do >> you think? >> > >> >> > >>> >> > >>> > We think a default policy can be used, >> when terminal can't find >> > >>> > corresponding policy in the routing >> policy from the ANDSF. The >> > default >> > >>> > policy can be sent by the network. >> > >>> [Peny] Could we give a chance to MN to >> change the policy (like user >> > >>> preference) ? >> > >>> >> > >>> > On another hand, I am a little confused >> between MIF and Multihoming, >> > >>> > would >> > >>> > you please help me to clarify the >> difference between them? >> > >>> [Peny] I am also not clear yet. Just give >> some lines as a seed for >> > >>> discussion. In my personal feeling, MIF >> is to change the "one default >> > >>> link" feature of current generic IP >> model. Multi-homing is to ensure >> > >>> the reachability and reliability of IP >> network. Well, in multi-homing >> > >>> MN scenarios, multi-link-multi-address is >> also one case. But, in this >> > >>> case, MN only can choose one link as >> default. >> > >>> Some other comments? >> > >> >> > >> To challenge one default link, it really >> takes time for mif to consider >> > on >> > >> it, current first step in mif is to >> consider some straight forward way >> > which >> > >> is simple to resolve some issues. >> > >> Regarding to multi-homing, I guess that it >> is more site multi-homing. >> > >> For last multi-link-multi-address mn's >> scenario, it will be one of MIF >> > >> scenario. >> > >> >> > >> thanks >> > >> >> > >> -Hui >> > >> >> > >>> >> > >>> BRG >> > >>> Peny >> > >> >> > > >> > > >> > ______________________________________________= _ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --00163646d566e5f5a7046164d129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Joel,
 
I saw your attentions are very good advice here.
we will avoid to&n= bsp;overlap with multipath transport and Multihoming site et al.
To= finish the timeline work is our top focus, it implies that curre= nt PS drafts will our main target.
 
Regarding to your caveat, to better use information host already has w= ill be good idea, other than let host be a wisdom.
 
Thanks for your suggestions.
Regards,
 
-Hui
 
2009/1/24 Joel M. Halpern <= jmh@joelhalpern.com>
Reading the discussion on this l= ist, and the problem statement draft, I want to call attention to the fact = that you are getting into a significant amount of mission creep (extending = the target scope well beyond the problem statement.

In particular, this discussion leads to issues that would require chang= es to transport behavior, host stack structure, and routing structure. &nbs= p;All of the issues that lead to that are valid issues. However, they are a= lso under investigation in other parts of the community (Transport area, In= ternet Area, and Routing Research Group.) Resolving those problems is going= to take significant time.  Please, help with all of those issues. &nb= sp;But if you want to make progress on the issues called out in the problem= statement draft, it would be a good idea to narrow the scope, not expand i= t.

As a final caveat, while it is tempting it is an extremely bad idea to = try to add all of the system routing intelligence to the local node. Even t= he system does not have good visibility to many of the properties (actual p= ath availability is only approximated, for example).  Using informatio= n the host / node already has is a very good idea.  Trying to get all = the routing information (so as, for example, to have a better guess as to w= hich interface can actually reach a given destination) would be a very bad = idea.

To restate, there are real problems, identified in the base draft, whic= h are tricky to solve.  If we want to solve them in a timely fashion, = we need to keep to a small set of problems.

Yours,
Joel M. Halper= n

Yungui Wang wrote:

Hello, Hui
 Agree with your statement. &n= bsp;However, it (the app/flow has to be restarted when interface-handoff ha= ppens) is actually an app/flow mobility issue related to multiple interface= s.  Thus, it seems the working item MIF is the just place to resolve i= t.  Hope it make sense. :_)
 B.R.
Yungui
 
   ----- Original Message -----=
   *From:* Hui Deng <mailto:denghui02@gmail.com>   *To:* Yungui Wang <mailto:w52006@huawei.com>
   *Cc:* pierrick.seite@orange-ftgroup.com
   <ma= ilto:pierrick.seite@orange-ftgroup.com> ; mif@ietf.org
   <mailto:m= if@ietf.org>
   *Sent:* Friday, January 23, 2009 4:32 P= M
   *Subject:* Re: [mif] mobility issues and general issues o= n mif

   Hello, Yungui,
       Excuse me for misunderstanding your point,
&n= bsp;  reply inline below.

   2009/1/23 Yungui W= ang <w52006@huawe= i.com <mailto:w52006@huawei.com>>=20


       Hello Hui
 = ;              Sorry for late response. = In my understanding, one issue of MIF
       is inte= rface selection (or named access selection). However,
    &nbs= p;  interface selection of a MIF-node is serving for its up-layer
       app/flow.
   some mobile phone can= do it, but normally, like PC application don't
   do it, = it is up to network
   socket to choose source address, then i= nterface is automatically
   selected.
   
       When one link associated with one interface of M= IF-node is down
       or congested, interface re-se= lection is needed. That's one type
       of mob= ility of app/flow between different interfaces I wanted to
       address.  
   If one interface= is down or congested, then application will be down
   as wel= l, this socket will close as well, and you would like to move
  &nb= sp;some application, then you have to restart to do it.
       thanks for the discussion.
    &nbs= p;  -Hui

       Maybe IP address model is r= elated to how to do. Please forget it.
         = ;      B.R.
       Yungui
  &= nbsp;    
           ----- Orig= inal Message -----
           *From:* Hui = Deng <mailto:de= nghui02@gmail.com>
           *To:*= Yungui Wang <mailto:w52006@huawei.com>
           *Cc:* pierrick.seite@orange-ftgroup.co= m
           <mailto:pierrick.seite@ora= nge-ftgroup.com> ; mif@ietf.org
           <mailto:mif@ietf.org>
      &nb= sp;    *Sent:* Thursday, January 22, 2009 2:26 PM
   = ;        *Subject:* Re: [mif] mobility issues and gener= al issues on mif

           Hi, Yungui,
    &= nbsp;                  mif is = targetting at multiple interface whatever it has how
     = ;      many ip address on each of them.
    &nb= sp;      I guess that you are asking more IPv6 related quest= ion.
                     = ;  What I feel what ever per interface or per IP address, how
 = ;          it is related to mobility of applicatio= n?
           we are not handling handover= related issues.
               =        Thanks for the discussion.
           Regards,
      &= nbsp;                -Hui

                    &nb= sp;  2009/1/22 Yungui Wang <w52006@huawei.com
        =    <mailto:w52006@huawei.com>>=20


            &nb= sp;  Hello Hui
              &nb= sp;                One comments, wh= ether is the IP address
             =  model to be investigated within MIF? For example, there
  &n= bsp;            are different types of IP add= ress model for
               MIF-terminal, per IP= address per IF, one IP address
           = ;    for multiple IF(s), etc. If considered that, mobility of
=                application/flow ove= r IP layer seems impliedly to be
          &nbs= p;    studied (e.g. in topic of IP route changing).
                     = ;          B.R.
        &nb= sp;      Yungui
           =    
                =    ----- Original Message -----
              &nbs= p;    *From:* Hui Deng <mailto:denghui02@gmail.com>
    &nbs= p;              *To:* pierrick.seite@orange-= ftgroup.com
                   <ma= ilto:pierrick.seite@orange-ftgroup.com>
        &= nbsp;          *Cc:* mif@ietf.org <mailto:mif@ietf.org>
                   *Sent:= * Wednesday, January 21, 2009 11:23 PM
         = ;          *Subject:* Re: [mif] mobility issues an= d general
                 =  issues on mif

             = ;      Hi, pierrick,
          &= nbsp;                    =        Thanks for joining the disucssion, speaking for=
                   mobile= operator is quite helpful for mif's work,
      &nbs= p;            Your experience is appreicate, = see reply inline below,
             =      2009/1/20 <pierrick.seite@orange-ftgroup.com
                   = <mailto:pierrick.seite@orange-ftgroup.com>>=20


            &nb= sp;          Hi all,

      &= nbsp;                I've joine= d recently this ML and I believe
          &nbs= p;            discussed topics very interesti= ng (BTW thanks to
               = ;        MIF promoters for bringing these issues to
                     = ;  IETF). So, please let me jump into your discussion.

  &= nbsp;                Thanks again.<= br>                   
                   =    Regarding difference between MIF and
      =                  multihoming: = it seems there is confusion with
                     = ;  mobility. AFAIU, MIF is only supposed to deal
    &nbs= p;                  with routi= ng issue at the multi-interface MN
          &n= bsp;            side. The issue is to select = the "best"
              &n= bsp;        interface for each outgoing IP flow and, in= MIF
                     = ;  context, access selection does not necessarily
    &nb= sp;                  imply flo= w mobility with IP session continuity
         =              between interfaces. Nevert= heless, solution
               =        should work for terminal with several active                      = ;  interfaces at the same time (multi-homed), or
    &nbs= p;                  for termin= al with a single interface at a time.
         =              Am I correct?

 = ;                  As you said= here, flow mobility and IP session
                   contin= uity is out of scope at the moment.
          &= nbsp;        I cann't agree with any more about you= r left words.
                &n= bsp;  


              &n= bsp;        Regarding ANDSF issue, I agree with precedi= ng
                     = ;  emails: I think access selection should rely on
    &n= bsp;                  policy. = There are a couple of selection models
         = ;              but the simplest is the s= election managed by the
                     = ;  terminal and based on local policies and
      &n= bsp;                measurement on = the access link. The policies may
          &nb= sp;            be provided/updated by a serve= r via out-of-band
               = ;        mechanism or on-demand (typically before
                     = ;  selection) if policies include "dynamic"
   =                    recom= mendation (e.g. access xx is overload and
        &n= bsp;              forbidden to applicati= on type yy). Now you can
                     = ;  call the policy server ANDSF, or whatever you
    &nbs= p;                  want, it i= s just a generic functional entity in
         =              the architecture and this = entity is above all
              &nb= sp;        access networks. Note the access selection v= ia
                     = ;  policy server meet MIF requirement as well as
    &nbs= p;                  selection = in inter-access mobility situation.

        &nbs= p;          Most mobile terminal has implemented t= he policy
                 =  based selection models.
                   Howver= I would like to raise one case, sometime, if
       = ;            the network congested, terminal = couldn't visit
              &nbs= p;    policy server such as ANDSF, only network side know
                   what h= appen, they may re-arrange some traffic for
        =            mobile terminal, I guess that this= is been discussed
              &nbs= p;    in 3GPP SA2 side at the moment.
      &nb= sp;            


                  &nbs= p;    Please do not hesitate to correct me if I
    =                    misund= erstood MIF issues.

             =      thanks for the discussion.
      &nb= sp;                     &= nbsp;          -Hui



                  =      Regards,
            &= nbsp;          Pierrick

     = ;                   > -----= Message d'origine-----
            &nb= sp;           > De : mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>
           =            [mailto:mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>] De la part de Peny
      =                   > Yang                    &nbs= p;   > Envoy=E9 : lundi 19 janvier 2009 15:10
                     = ;   > =C0 : Kai Ju
         = ;               > Cc : mif@ietf.org <mailto:mif@ietf.org>=20

              =           > Objet : Re: [mif] mobility issues a= nd general
                 = ;      issues on mif
          &= nbsp;             >
     = ;                   > Hi, K= ai:
                   = ;     > > The ANSDF solution is just a sample,
                     = ;  because there is no one type of
        &nbs= p;               > server
  &= nbsp;                    = > > which is
              &nb= sp;         > > defined to provide the policy in = IETF until
                     = ;  now. So let us consider it
          &n= bsp;             > be
    &nb= sp;                   > >= ; general, which
               =         > > means it's one policy server tha= t provides
                     = ;  the routing policy to UE when
         =               > UE
    =                     > = > is connecting
              &nbs= p;         > > it.
       =                 > [Peny] Agree.= 3GPP ANSDF could be a good
                     = ;  reference when we make the
          &n= bsp;             > MIF solutions.
 = ;                     &nb= sp; >
                  =       > BRG
            =             > Peny
     =                   >
                     = ;   >
                &n= bsp;       >
           =             > >>
    &= nbsp;                   > &= gt;> Hi, Peng and Kai,
            &nbs= p;           > >>
     =                   > >&g= t; See reply inline below. thanks for the
                     = ;  discussion.
              &nb= sp;         > >> 2009/1/19 Peny Yang
 =                     &nbs= p;<peng.yan= g.chn@gmail.com
                     = ;  <mailto:peng.yang.chn@gmail.com>>=20

              =           > >>>
     = ;                   > >&= gt;> Hi, Kai:
               =         > >>> Nice point. Please check the= lines below:
                &n= bsp;       > >>>
                     = ;   > >>> > As you said, there are multiple way to
&= nbsp;                    =  assign the routing policy by
          &= nbsp;             > in
    &n= bsp;                   > &g= t;>> > the
                     = ;   > >>> > mobile access network. As viewed from
&n= bsp;                     =  the aspect of terminal, I
           = ;             > think
    &nb= sp;                   > >= ;>> > its a
                     = ;   > >>> > good idea that terminal can get its
&nbs= p;                     &n= bsp;routing policy from the ANDSF.
          &n= bsp;             > >>> [Peny] AND= SF may be one of the choices.
                     = ;  But ANDSF just follows the
          &n= bsp;             > >>> assumption= of generic "one default link"
        &nb= sp;              IP model. So, in 3GPP, = even
                  &nbs= p;     > >>> though ANDSF can help UE to select
                     = ;  accesses and find the route, UE can
        =                 > >>> o= nly choose one of the interfaces as a
         =              result.
    &= nbsp;                   > &= gt;>> Personally, I'm not sure if it's a good
                     = ;  way to rely on ANDSF of 3GPP,
         =               > >>> since i= t's a specific definition in one SDO.
        &n= bsp;               > >>
&nbs= p;                     &n= bsp; > >> ANDSF in 3GPP 23.401 do cover only 3GPP
                     = ;  network, how could ANDSF work
         =               > for
   =                     >= >> 23.402 for non-3GPP access still a issue,
     =                  it may need = some mechanism to
                     = ;   > >> coordinate
          &nb= sp;             > >> between two typ= e of access entwork.what do
            &n= bsp;          you think?
      &= nbsp;                 > >>=
                    &= nbsp;   > >>>
                     = ;   > >>> > We think a default policy can be used,
&= nbsp;                    =   when terminal can't find
          =               > >>> > cor= responding policy in the routing
                     = ;  policy from the ANDSF. The
          &n= bsp;             > default
   = ;                     >= ; >>> > policy can be sent by the network.
    &nb= sp;                   > >= ;>> [Peny] Could we give a chance to MN to
                     = ;  change the policy (like user
          =               > >>> preferen= ce) ?
                  &nb= sp;     > >>>
          &= nbsp;             > >>> > On a= nother hand, I am a little confused
                     = ;  between MIF and Multihoming,
          =               > >>> > wou= ld
                   =     > >>> > you please help me to clarify the
=                      = ;  difference between them?
                     = ;   > >>> [Peny] I am also not clear yet. Just give
&nb= sp;                     &= nbsp;some lines as a seed for
            =             > >>> discussion. In = my personal feeling, MIF
                     = ;  is to change the "one default
        &= nbsp;               > >>> li= nk" feature of current generic IP
         = ;              model. Multi-homing is to= ensure
                  &= nbsp;     > >>> the reachability and reliability of I= P
                     = ;  network. Well, in multi-homing
         = ;               > >>> MN sce= narios, multi-link-multi-address is
          &= nbsp;            also one case. But, in this<= br>                    &n= bsp;   > >>> case, MN only can choose one link as default.=
                     = ;   > >>> Some other comments?
      &nb= sp;                 > >>                    &nb= sp;   > >> To challenge one default link, it really
 =                     &nbs= p;takes time for mif to consider
                     = ;   > on
               =         > >> it, current first step in mif is= to
                   = ;    consider some straight forward way
      &= nbsp;                 > which                    &nbs= p;   > >> is simple to resolve some issues.
                     = ;   > >> Regarding to multi-homing, I guess that it
 =                     &nbs= p;is more site multi-homing.
            &= nbsp;           > >> For last multi-link-= multi-address mn's
                     = ;  scenario, it will be one of MIF
        &nbs= p;               > >> scenario.=
                    &= nbsp;   > >>
            &nb= sp;           > >> thanks
   = ;                     >= ; >>
                     = ;   > >> -Hui
            &n= bsp;           > >>
    &nbs= p;                   > >= >>
                  =       > >>> BRG
        &= nbsp;               > >>> Pe= ny
                     = ;   > >>
              =           > >
       =                 > >
 = ;                     &nb= sp; > _______________________________________________
    &= nbsp;                   > m= if mailing list
                  =       > mif@ietf.org <mailto:mif@ietf.org>=20

              =           > https://www.ietf.org/mailman/listinfo/= mif
                  &= nbsp;    _______________________________________________
                     = ;  mif mailing list
           =            mif@ietf.org <mailto:mif@ietf.org>=20

              =          https://www.ietf.org/mailman/listinfo/mif


                 =  _______________________________________________
                   mif ma= iling list
               =    mif@ietf.or= g <mailto:mif@ietf= .org>=20

              =      https://www.ietf.org/mailman/listinfo/mif


<= br>
--------------------------------------------------------------------= ----

_______________________________________________
mif mailing list
= mif@ietf.org
https://= www.ietf.org/mailman/listinfo/mif
_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif

--00163646d566e5f5a7046164d129-- --===============1499537353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1499537353==-- From mif-bounces@ietf.org Mon Jan 26 08:01:45 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C093A6A2E; Mon, 26 Jan 2009 08:01:45 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DB53A689F for ; Mon, 26 Jan 2009 08:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgpegJm45zZr for ; Mon, 26 Jan 2009 08:01:38 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 700BB3A6AAA for ; Mon, 26 Jan 2009 08:01:38 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so6751197wfd.31 for ; Mon, 26 Jan 2009 08:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TbNzarKu/rBWBQ99OmMp3+qsZLpJQ+dYTOgINaTpCA4=; b=E6TCcTiUPXAYl+BCZR5a4qMYnwbTIK7wGD1m2o9elTMgKIjzFxFhPq3tXwYsddvi2S yWqT6PFl8yJ6I7wBGtIQwH+4FRhX4SWEXVnc9W7/uvGu51WjlZG1iV1elG02YpiDAOsB TJSHxs0S4CNqp+a6abcyYBtV+GSvQVtgh9FgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ObqmV22K2LYXVCgUEr3LiVrH/8MJ4pzzeX5LtdEaTL+BkzqWm5R1/5P8QLQ4i1aEQG pEOCXNFNsaVTQSRt65P6ccU/f/oV2yqBwbrRvR+scDR7CsiEqWsQAOV8YOkR2s7YZzlk R6W1qSxe5qvv5mXtDPInyL7hAn0TW662D4YgY= MIME-Version: 1.0 Received: by 10.114.53.1 with SMTP id b1mr684139waa.29.1232985680002; Mon, 26 Jan 2009 08:01:20 -0800 (PST) In-Reply-To: References: <3db7b9d60901170955j7c048deaq21c1ac70f8a6c25e@mail.gmail.com> <1d38a3350901210723t73c500b9g183c04123446a091@mail.gmail.com> <007701c97c33$43df8c30$150ca40a@china.huawei.com> <1d38a3350901212226o6cbead92r7bf7c3ea46954ef4@mail.gmail.com> <011301c97d2f$eeba9530$150ca40a@china.huawei.com> <1d38a3350901230032l2fffd496me8c53bddd3c7f3f7@mail.gmail.com> <000d01c97d3d$203633f0$150ca40a@china.huawei.com> <497A0612.4060702@joelhalpern.com> Date: Tue, 27 Jan 2009 00:01:19 +0800 Message-ID: <1d38a3350901260801m2a9c2405n81cd7515be615ea0@mail.gmail.com> From: Hui Deng To: Kevin Chin Cc: mif@ietf.org Subject: Re: [mif] mobility issues and general issues on mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811620833==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0811620833== Content-Type: multipart/alternative; boundary=001636458206783f3b046164d9c0 --001636458206783f3b046164d9c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Kevin, I agree with your all here, small set of issues will be a good start. Can you give more detail information about what host already has? such as what kind set of tools and incentives? thanks again. -Hui 2009/1/24 Kevin Chin > As a final caveat, while it is tempting it is an extremely bad idea to >> try to add all of the system routing intelligence to the local node. Eve= n >> the system does not have good visibility to many of the properties (actu= al >> path availability is only approximated, for example). Using information= the >> host / node already has is a very good idea. Trying to get all the rout= ing >> information (so as, for example, to have a better guess as to which >> interface can actually reach a given destination) would be a very bad id= ea. >> > Agree - Using information the host/node already has is a very good idea. > The host already has a set of tools and incentive to get it right. > > > >> To restate, there are real problems, identified in the base draft, which >> are tricky to solve. If we want to solve them in a timely fashion, we n= eed >> to keep to a small set of problems. >> >> Yours, >> Joel M. Halpern >> > > I second this view. Let's define small set of issues to investigate. > > regards, > Kevin > > On Fri, Jan 23, 2009 at 10:01 AM, Joel M. Halpern = wrote: > >> Reading the discussion on this list, and the problem statement draft, I >> want to call attention to the fact that you are getting into a significa= nt >> amount of mission creep (extending the target scope well beyond the prob= lem >> statement. >> >> In particular, this discussion leads to issues that would require change= s >> to transport behavior, host stack structure, and routing structure. All= of >> the issues that lead to that are valid issues. However, they are also un= der >> investigation in other parts of the community (Transport area, Internet >> Area, and Routing Research Group.) Resolving those problems is going to = take >> significant time. Please, help with all of those issues. But if you wa= nt >> to make progress on the issues called out in the problem statement draft= , it >> would be a good idea to narrow the scope, not expand it. >> >> As a final caveat, while it is tempting it is an extremely bad idea to t= ry >> to add all of the system routing intelligence to the local node. Even th= e >> system does not have good visibility to many of the properties (actual p= ath >> availability is only approximated, for example). Using information the = host >> / node already has is a very good idea. Trying to get all the routing >> information (so as, for example, to have a better guess as to which >> interface can actually reach a given destination) would be a very bad id= ea. >> >> To restate, there are real problems, identified in the base draft, which >> are tricky to solve. If we want to solve them in a timely fashion, we n= eed >> to keep to a small set of problems. >> >> Yours, >> Joel M. Halpern >> >> Yungui Wang wrote: >> >>> >>> Hello, Hui >>> Agree with your statement. However, it (the app/flow has to be >>> restarted when interface-handoff happens) is actually an app/flow mobil= ity >>> issue related to multiple interfaces. Thus, it seems the working item = MIF >>> is the just place to resolve it. Hope it make sense. :_) >>> B.R. >>> Yungui >>> >>> ----- Original Message ----- >>> *From:* Hui Deng >>> *To:* Yungui Wang >>> *Cc:* pierrick.seite@orange-ftgroup.com >>> ; mif@ietf.org >>> >>> *Sent:* Friday, January 23, 2009 4:32 PM >>> *Subject:* Re: [mif] mobility issues and general issues on mif >>> >>> Hello, Yungui, >>> Excuse me for misunderstanding your point, >>> reply inline below. >>> >>> 2009/1/23 Yungui Wang > >>> >>> Hello Hui >>> Sorry for late response. In my understanding, one issue = of >>> MIF >>> is interface selection (or named access selection). However, >>> interface selection of a MIF-node is serving for its up-layer >>> app/flow. >>> some mobile phone can do it, but normally, like PC application don't >>> do it, it is up to network >>> socket to choose source address, then interface is automatically >>> selected. >>> >>> When one link associated with one interface of MIF-node is down >>> or congested, interface re-selection is needed. That's one type >>> of mobility of app/flow between different interfaces I wanted to >>> address. >>> If one interface is down or congested, then application will be down >>> as well, this socket will close as well, and you would like to move >>> some application, then you have to restart to do it. >>> thanks for the discussion. >>> -Hui >>> >>> Maybe IP address model is related to how to do. Please forget it= . >>> B.R. >>> Yungui >>> >>> ----- Original Message ----- >>> *From:* Hui Deng >>> *To:* Yungui Wang >>> *Cc:* pierrick.seite@orange-ftgroup.com >>> ; mif@ietf.org >>> >>> *Sent:* Thursday, January 22, 2009 2:26 PM >>> *Subject:* Re: [mif] mobility issues and general issues on m= if >>> >>> Hi, Yungui, >>> mif is targetting at multiple interface whatever >>> it has how >>> many ip address on each of them. >>> I guess that you are asking more IPv6 related question. >>> What I feel what ever per interface or per IP >>> address, how >>> it is related to mobility of application? >>> we are not handling handover related issues. >>> Thanks for the discussion. >>> Regards, >>> -Hui >>> >>> >>> 2009/1/22 Yungui Wang >> > >>> >>> Hello Hui >>> One comments, whether is the IP address >>> model to be investigated within MIF? For example, there >>> are different types of IP address model for >>> MIF-terminal, per IP address per IF, one IP address >>> for multiple IF(s), etc. If considered that, mobility of >>> application/flow over IP layer seems impliedly to be >>> studied (e.g. in topic of IP route changing). >>> B.R. >>> Yungui >>> >>> ----- Original Message ----- >>> *From:* Hui Deng >>> *To:* pierrick.seite@orange-ftgroup.com >>> >>> *Cc:* mif@ietf.org >>> *Sent:* Wednesday, January 21, 2009 11:23 PM >>> *Subject:* Re: [mif] mobility issues and general >>> issues on mif >>> >>> Hi, pierrick, >>> Thanks for joining the disucssio= n, >>> speaking for >>> mobile operator is quite helpful for mif's work, >>> Your experience is appreicate, see reply inline belo= w, >>> 2009/1/20 >> > >>> >>> >>> Hi all, >>> >>> I've joined recently this ML and I believe >>> discussed topics very interesting (BTW thanks to >>> MIF promoters for bringing these issues to >>> IETF). So, please let me jump into your >>> discussion. >>> >>> Thanks again. >>> >>> >>> Regarding difference between MIF and >>> multihoming: it seems there is confusion with >>> mobility. AFAIU, MIF is only supposed to deal >>> with routing issue at the multi-interface MN >>> side. The issue is to select the "best" >>> interface for each outgoing IP flow and, in MIF >>> context, access selection does not necessarily >>> imply flow mobility with IP session continuity >>> between interfaces. Nevertheless, solution >>> should work for terminal with several active >>> interfaces at the same time (multi-homed), or >>> for terminal with a single interface at a time. >>> Am I correct? >>> >>> As you said here, flow mobility and IP session >>> continuity is out of scope at the moment. >>> I cann't agree with any more about your left words. >>> >>> >>> >>> Regarding ANDSF issue, I agree with preceding >>> emails: I think access selection should rely on >>> policy. There are a couple of selection models >>> but the simplest is the selection managed by the >>> terminal and based on local policies and >>> measurement on the access link. The policies may >>> be provided/updated by a server via out-of-band >>> mechanism or on-demand (typically before >>> selection) if policies include "dynamic" >>> recommendation (e.g. access xx is overload and >>> forbidden to application type yy). Now you can >>> call the policy server ANDSF, or whatever you >>> want, it is just a generic functional entity in >>> the architecture and this entity is above all >>> access networks. Note the access selection via >>> policy server meet MIF requirement as well as >>> selection in inter-access mobility situation. >>> >>> Most mobile terminal has implemented the policy >>> based selection models. >>> Howver I would like to raise one case, sometime, if >>> the network congested, terminal couldn't visit >>> policy server such as ANDSF, only network side know >>> what happen, they may re-arrange some traffic for >>> mobile terminal, I guess that this is been discussed >>> in 3GPP SA2 side at the moment. >>> >>> >>> >>> Please do not hesitate to correct me if I >>> misunderstood MIF issues. >>> >>> thanks for the discussion. >>> -Hui >>> >>> >>> >>> Regards, >>> Pierrick >>> >>> > -----Message d'origine----- >>> > De : mif-bounces@ietf.org >>> >>> [mailto:mif-bounces@ietf.org >>> ] De la part de Pen= y >>> > Yang >>> > Envoy=E9 : lundi 19 janvier 2009 15:10 >>> > =C0 : Kai Ju >>> > Cc : mif@ietf.org >>> >>> > Objet : Re: [mif] mobility issues and general >>> issues on mif >>> > >>> > Hi, Kai: >>> > > The ANSDF solution is just a sample, >>> because there is no one type of >>> > server >>> > > which is >>> > > defined to provide the policy in IETF until >>> now. So let us consider it >>> > be >>> > > general, which >>> > > means it's one policy server that provides >>> the routing policy to UE when >>> > UE >>> > > is connecting >>> > > it. >>> > [Peny] Agree. 3GPP ANSDF could be a good >>> reference when we make the >>> > MIF solutions. >>> > >>> > BRG >>> > Peny >>> > >>> > >>> > >>> > >> >>> > >> Hi, Peng and Kai, >>> > >> >>> > >> See reply inline below. thanks for the >>> discussion. >>> > >> 2009/1/19 Peny Yang >>> >> > >>> >>> > >>> >>> > >>> Hi, Kai: >>> > >>> Nice point. Please check the lines below: >>> > >>> >>> > >>> > As you said, there are multiple way to >>> assign the routing policy by >>> > in >>> > >>> > the >>> > >>> > mobile access network. As viewed from >>> the aspect of terminal, I >>> > think >>> > >>> > its a >>> > >>> > good idea that terminal can get its >>> routing policy from the ANDSF. >>> > >>> [Peny] ANDSF may be one of the choices. >>> But ANDSF just follows the >>> > >>> assumption of generic "one default link" >>> IP model. So, in 3GPP, even >>> > >>> though ANDSF can help UE to select >>> accesses and find the route, UE can >>> > >>> only choose one of the interfaces as a >>> result. >>> > >>> Personally, I'm not sure if it's a good >>> way to rely on ANDSF of 3GPP, >>> > >>> since it's a specific definition in one >>> SDO. >>> > >> >>> > >> ANDSF in 3GPP 23.401 do cover only 3GPP >>> network, how could ANDSF work >>> > for >>> > >> 23.402 for non-3GPP access still a issue, >>> it may need some mechanism to >>> > >> coordinate >>> > >> between two type of access entwork.what do >>> you think? >>> > >> >>> > >>> >>> > >>> > We think a default policy can be used, >>> when terminal can't find >>> > >>> > corresponding policy in the routing >>> policy from the ANDSF. The >>> > default >>> > >>> > policy can be sent by the network. >>> > >>> [Peny] Could we give a chance to MN to >>> change the policy (like user >>> > >>> preference) ? >>> > >>> >>> > >>> > On another hand, I am a little confused >>> between MIF and Multihoming, >>> > >>> > would >>> > >>> > you please help me to clarify the >>> difference between them? >>> > >>> [Peny] I am also not clear yet. Just give >>> some lines as a seed for >>> > >>> discussion. In my personal feeling, MIF >>> is to change the "one default >>> > >>> link" feature of current generic IP >>> model. Multi-homing is to ensure >>> > >>> the reachability and reliability of IP >>> network. Well, in multi-homing >>> > >>> MN scenarios, multi-link-multi-address is >>> also one case. But, in this >>> > >>> case, MN only can choose one link as >>> default. >>> > >>> Some other comments? >>> > >> >>> > >> To challenge one default link, it really >>> takes time for mif to consider >>> > on >>> > >> it, current first step in mif is to >>> consider some straight forward way >>> > which >>> > >> is simple to resolve some issues. >>> > >> Regarding to multi-homing, I guess that it >>> is more site multi-homing. >>> > >> For last multi-link-multi-address mn's >>> scenario, it will be one of MIF >>> > >> scenario. >>> > >> >>> > >> thanks >>> > >> >>> > >> -Hui >>> > >> >>> > >>> >>> > >>> BRG >>> > >>> Peny >>> > >> >>> > > >>> > > >>> > _____________________________________________= __ >>> > mif mailing list >>> > mif@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mif >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >>> >>> >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --001636458206783f3b046164d9c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Kevin,
 
I agree with your all here, small set of issues will be a good start.<= /div>
 
Can you give more detail information about what host already has? such= as what kind set of tools and incentives?
thanks again.
 
-Hui
2009/1/24 Kevin Chin <kchin.xor@gmail.com>
As a final caveat, while it is t= empting it is an extremely bad idea to try to add all of the system routing= intelligence to the local node. Even the system does not have good visibil= ity to many of the properties (actual path availability is only approximate= d, for example).  Using information the host / node already has is a v= ery good idea.  Trying to get all the routing information (so as, for = example, to have a better guess as to which interface can actually reach a = given destination) would be a very bad idea.

Agree - Using information the host/node already has is a very good idea.= The host already has a set of tools and incentive to get it right.

 
 
To restate, there are real probl= ems, identified in the base draft, which are tricky to solve.  If we w= ant to solve them in a timely fashion, we need to keep to a small set of pr= oblems.

Yours,
Joel M. Halpern
 
I second this view. Let's define small set of issues to investigat= e.
 
regards,
Kevin

On Fri, Jan 23, 2009 at 10:01 AM, Joel M. Halper= n <jmh@joelhalpern.com> wrote:
Reading the discussion on this l= ist, and the problem statement draft, I want to call attention to the fact = that you are getting into a significant amount of mission creep (extending = the target scope well beyond the problem statement.

In particular, this discussion leads to issues that would require chang= es to transport behavior, host stack structure, and routing structure. &nbs= p;All of the issues that lead to that are valid issues. However, they are a= lso under investigation in other parts of the community (Transport area, In= ternet Area, and Routing Research Group.) Resolving those problems is going= to take significant time.  Please, help with all of those issues. &nb= sp;But if you want to make progress on the issues called out in the problem= statement draft, it would be a good idea to narrow the scope, not expand i= t.

As a final caveat, while it is tempting it is an extremely bad idea to = try to add all of the system routing intelligence to the local node. Even t= he system does not have good visibility to many of the properties (actual p= ath availability is only approximated, for example).  Using informatio= n the host / node already has is a very good idea.  Trying to get all = the routing information (so as, for example, to have a better guess as to w= hich interface can actually reach a given destination) would be a very bad = idea.

To restate, there are real problems, identified in the base draft, whic= h are tricky to solve.  If we want to solve them in a timely fashion, = we need to keep to a small set of problems.

Yours,
Joel M. Halper= n

Yungui Wang wrote:

Hello, Hui
 Agree with your statement.  However, it (= the app/flow has to be restarted when interface-handoff happens) is actuall= y an app/flow mobility issue related to multiple interfaces.  Thus, it= seems the working item MIF is the just place to resolve it.  Hope it = make sense. :_)
 B.R.
Yungui
 
   ----- Original Message -----=
   *From:* Hui Deng <mailto:denghui02@gmail.com>
   *To= :* Yungui Wang <mailto:w52006@huawei.com>
   *Cc:* pierrick.seite@orange-ftgroup.com
   <ma= ilto:pierrick.seite@orange-ftgroup.com> ; mif@ietf.org
   <mailto:m= if@ietf.org>
   *Sent:* Friday, January 23, 2009 4:32 P= M
   *Subject:* Re: [mif] mobility issues and general issues o= n mif

   Hello, Yungui,
       Excuse me for misunderstanding your point,
&n= bsp;  reply inline below.

   2009/1/23 Yungui W= ang <w52006@huawe= i.com <mailto:w52006@huawei.com>>=20


       Hello Hui
      &= nbsp;        Sorry for late response. In my understandi= ng, one issue of MIF
       is interface selection (= or named access selection). However,
       interfac= e selection of a MIF-node is serving for its up-layer
       app/flow.
   some mobile phone can= do it, but normally, like PC application don't
   do it, = it is up to network
   socket to choose source address, then i= nterface is automatically
   selected.
   
       When one link associated with one interface of M= IF-node is down
       or congested, interface re-se= lection is needed. That's one type
       of mob= ility of app/flow between different interfaces I wanted to
       address.  
   If one interface= is down or congested, then application will be down
   as wel= l, this socket will close as well, and you would like to move
  &nb= sp;some application, then you have to restart to do it.
       thanks for the discussion.
    &nbs= p;  -Hui

       Maybe IP address model is r= elated to how to do. Please forget it.
         = ;      B.R.
       Yungui
  &= nbsp;    
           ----- Orig= inal Message -----
           *From:* Hui Deng <mailto:<= a href=3D"mailto:denghui02@gmail.com" target=3D"_blank">denghui02@gmail.com= >
           *To:* Yungui Wang <= mailto:w52006@huawei= .com>
           *Cc:* pierrick.seite@orange-ftgroup.co= m
           <mailto:pierrick.seite@ora= nge-ftgroup.com> ; mif@ietf.org
           <mailto:mif@ietf.org>
      &nb= sp;    *Sent:* Thursday, January 22, 2009 2:26 PM
   = ;        *Subject:* Re: [mif] mobility issues and gener= al issues on mif

           Hi, Yungui,
    &= nbsp;                  mif is = targetting at multiple interface whatever it has how
     = ;      many ip address on each of them.
    &nb= sp;      I guess that you are asking more IPv6 related quest= ion.
                     = ;  What I feel what ever per interface or per IP address, how
 = ;          it is related to mobility of applicatio= n?
           we are not handling handover= related issues.
               =        Thanks for the discussion.
           Regards,
      &= nbsp;                -Hui

                    &nb= sp;  2009/1/22 Yungui Wang <w52006@huawei.com
        =    <mailto:w52006@huawei.com>>=20


               Hello H= ui
                   =            One comments, whether is the IP a= ddress
               model to b= e investigated within MIF? For example, there
       = ;        are different types of IP address model for                MIF-terminal, per IP= address per IF, one IP address
           = ;    for multiple IF(s), etc. If considered that, mobility of
=                application/flow ove= r IP layer seems impliedly to be
          &nbs= p;    studied (e.g. in topic of IP route changing).
                     = ;          B.R.
        &nb= sp;      Yungui
           =    
                =    ----- Original Message -----
                   *= From:* Hui Deng <mailto:denghui02@gmail.com>
          =          *To:* pierrick.seite@orange-ftgroup.com                    <ma= ilto:pierrick.seite@orange-ftgroup.com>
        &= nbsp;          *Cc:* mif@ietf.org <mailto:mif@ietf.org>
                   *Sent:= * Wednesday, January 21, 2009 11:23 PM
         = ;          *Subject:* Re: [mif] mobility issues an= d general
                 =  issues on mif

             = ;      Hi, pierrick,
          &= nbsp;                    =        Thanks for joining the disucssion, speaking for=
                   mobile= operator is quite helpful for mif's work,
      &nbs= p;            Your experience is appreicate, = see reply inline below,
             =      2009/1/20 <pierrick.seite@orange-ftgroup.com
                   = <mailto:pierrick.seite@orange-ftgroup.com>>=20


                 =      Hi all,

          &nbs= p;            I've joined recently this M= L and I believe
                =        discussed topics very interesting (BTW thanks to=
                    &= nbsp;  MIF promoters for bringing these issues to
                     = ;  IETF). So, please let me jump into your discussion.

  &= nbsp;                Thanks again.<= br>                   
                   =    Regarding difference between MIF and
      =                  multihoming: = it seems there is confusion with
                     = ;  mobility. AFAIU, MIF is only supposed to deal
    &nbs= p;                  with routi= ng issue at the multi-interface MN
          &n= bsp;            side. The issue is to select = the "best"
              &n= bsp;        interface for each outgoing IP flow and, in= MIF
                     = ;  context, access selection does not necessarily
    &nb= sp;                  imply flo= w mobility with IP session continuity
         =              between interfaces. Nevert= heless, solution
               =        should work for terminal with several active                      = ;  interfaces at the same time (multi-homed), or
    &nbs= p;                  for termin= al with a single interface at a time.
         =              Am I correct?

 = ;                  As you said= here, flow mobility and IP session
                   contin= uity is out of scope at the moment.
          &= nbsp;        I cann't agree with any more about you= r left words.
                &n= bsp;  


              &n= bsp;        Regarding ANDSF issue, I agree with precedi= ng
                     = ;  emails: I think access selection should rely on
    &n= bsp;                  policy. = There are a couple of selection models
         = ;              but the simplest is the s= election managed by the
                     = ;  terminal and based on local policies and
      &n= bsp;                measurement on = the access link. The policies may
          &nb= sp;            be provided/updated by a serve= r via out-of-band
               = ;        mechanism or on-demand (typically before
                     = ;  selection) if policies include "dynamic"
   =                    recom= mendation (e.g. access xx is overload and
        &n= bsp;              forbidden to applicati= on type yy). Now you can
                     = ;  call the policy server ANDSF, or whatever you
    &nbs= p;                  want, it i= s just a generic functional entity in
         =              the architecture and this = entity is above all
              &nb= sp;        access networks. Note the access selection v= ia
                     = ;  policy server meet MIF requirement as well as
    &nbs= p;                  selection = in inter-access mobility situation.

        &nbs= p;          Most mobile terminal has implemented t= he policy
                 =  based selection models.
                   Howver= I would like to raise one case, sometime, if
       = ;            the network congested, terminal = couldn't visit
              &nbs= p;    policy server such as ANDSF, only network side know
                   what h= appen, they may re-arrange some traffic for
        =            mobile terminal, I guess that this= is been discussed
              &nbs= p;    in 3GPP SA2 side at the moment.
      &nb= sp;            


                  &nbs= p;    Please do not hesitate to correct me if I
    =                    misund= erstood MIF issues.

             =      thanks for the discussion.
      &nb= sp;                     &= nbsp;          -Hui



                  =      Regards,
            &= nbsp;          Pierrick

     = ;                   > -----= Message d'origine-----
            &nb= sp;           > De : mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>
           =            [mailto:mif-bounces@ietf.org
                     = ;  <mailto:mif-bounces@ietf.org>] De la part de Peny
      =                   > Yang                    &nbs= p;   > Envoy=E9 : lundi 19 janvier 2009 15:10
                     = ;   > =C0 : Kai Ju
         = ;               > Cc : mif@ietf.org <mailto:mif@ietf.org>=20

                  &nb= sp;     > Objet : Re: [mif] mobility issues and general
&nb= sp;                     &= nbsp;issues on mif
              &nbs= p;         >
          &= nbsp;             > Hi, Kai:
  &nb= sp;                     &= gt; > The ANSDF solution is just a sample,
                     = ;  because there is no one type of
        &nbs= p;               > server
  &= nbsp;                    = > > which is
              &nb= sp;         > > defined to provide the policy in = IETF until
                     = ;  now. So let us consider it
          &n= bsp;             > be
    &nb= sp;                   > >= ; general, which
               =         > > means it's one policy server tha= t provides
                     = ;  the routing policy to UE when
         =               > UE
    =                     > = > is connecting
              &nbs= p;         > > it.
       =                 > [Peny] Agree.= 3GPP ANSDF could be a good
                     = ;  reference when we make the
          &n= bsp;             > MIF solutions.
 = ;                     &nb= sp; >
                  =       > BRG
            =             > Peny
     =                   >
                     = ;   >
                &n= bsp;       >
           =             > >>
    &= nbsp;                   > &= gt;> Hi, Peng and Kai,
            &nbs= p;           > >>
     =                   > >&g= t; See reply inline below. thanks for the
                     = ;  discussion.
              &nb= sp;         > >> 2009/1/19 Peny Yang
 =                     &nbs= p;<peng.yan= g.chn@gmail.com
                     = ;  <mailto:peng.yang.chn@gmail.com>>=20

                  &nb= sp;     > >>>
          &= nbsp;             > >>> Hi, Kai:<= br>                    &n= bsp;   > >>> Nice point. Please check the lines below:
=                      = ;   > >>>
                     = ;   > >>> > As you said, there are multiple way to
&= nbsp;                    =  assign the routing policy by
          &= nbsp;             > in
    &n= bsp;                   > &g= t;>> > the
                     = ;   > >>> > mobile access network. As viewed from
&n= bsp;                     =  the aspect of terminal, I
           = ;             > think
    &nb= sp;                   > >= ;>> > its a
                     = ;   > >>> > good idea that terminal can get its
&nbs= p;                     &n= bsp;routing policy from the ANDSF.
          &n= bsp;             > >>> [Peny] AND= SF may be one of the choices.
                     = ;  But ANDSF just follows the
          &n= bsp;             > >>> assumption= of generic "one default link"
        &nb= sp;              IP model. So, in 3GPP, = even
                  &nbs= p;     > >>> though ANDSF can help UE to select
                     = ;  accesses and find the route, UE can
        =                 > >>> o= nly choose one of the interfaces as a
         =              result.
    &= nbsp;                   > &= gt;>> Personally, I'm not sure if it's a good
                     = ;  way to rely on ANDSF of 3GPP,
         =               > >>> since i= t's a specific definition in one SDO.
        &n= bsp;               > >>
&nbs= p;                     &n= bsp; > >> ANDSF in 3GPP 23.401 do cover only 3GPP
                     = ;  network, how could ANDSF work
         =               > for
   =                     >= >> 23.402 for non-3GPP access still a issue,
     =                  it may need = some mechanism to
                     = ;   > >> coordinate
          &nb= sp;             > >> between two typ= e of access entwork.what do
            &n= bsp;          you think?
      &= nbsp;                 > >>=
                    &= nbsp;   > >>>
                     = ;   > >>> > We think a default policy can be used,
&= nbsp;                    =   when terminal can't find
          =               > >>> > cor= responding policy in the routing
                     = ;  policy from the ANDSF. The
          &n= bsp;             > default
   = ;                     >= ; >>> > policy can be sent by the network.
    &nb= sp;                   > >= ;>> [Peny] Could we give a chance to MN to
                     = ;  change the policy (like user
          =               > >>> preferen= ce) ?
                  &nb= sp;     > >>>
          &= nbsp;             > >>> > On a= nother hand, I am a little confused
                     = ;  between MIF and Multihoming,
          =               > >>> > wou= ld
                   =     > >>> > you please help me to clarify the
=                      = ;  difference between them?
                     = ;   > >>> [Peny] I am also not clear yet. Just give
&nb= sp;                     &= nbsp;some lines as a seed for
            =             > >>> discussion. In = my personal feeling, MIF
                     = ;  is to change the "one default
        &= nbsp;               > >>> li= nk" feature of current generic IP
         = ;              model. Multi-homing is to= ensure
                  &= nbsp;     > >>> the reachability and reliability of I= P
                     = ;  network. Well, in multi-homing
         = ;               > >>> MN sce= narios, multi-link-multi-address is
          &= nbsp;            also one case. But, in this<= br>                    &n= bsp;   > >>> case, MN only can choose one link as default.=
                     = ;   > >>> Some other comments?
      &nb= sp;                 > >>                    &nb= sp;   > >> To challenge one default link, it really
 =                     &nbs= p;takes time for mif to consider
                     = ;   > on
               =         > >> it, current first step in mif is= to
                   = ;    consider some straight forward way
      &= nbsp;                 > which                    &nbs= p;   > >> is simple to resolve some issues.
                     = ;   > >> Regarding to multi-homing, I guess that it
 =                     &nbs= p;is more site multi-homing.
            &= nbsp;           > >> For last multi-link-= multi-address mn's
                     = ;  scenario, it will be one of MIF
        &nbs= p;               > >> scenario.=
                    &= nbsp;   > >>
            &nb= sp;           > >> thanks
   = ;                     >= ; >>
                     = ;   > >> -Hui
            &n= bsp;           > >>
    &nbs= p;                   > >= >>
                  =       > >>> BRG
        &= nbsp;               > >>> Pe= ny
                     = ;   > >>
              =           > >
       =                 > >
 = ;                     &nb= sp; > _______________________________________________
    &= nbsp;                   > m= if mailing list
                  =       > mif@ietf.org <mailto:mif@ietf.org>=20

                  &nb= sp;     > https://www.ietf.org/mailman/listinfo/mif
 =                     &nbs= p;_______________________________________________
                     = ;  mif mailing list
           =            mif@ietf.org <mailto:mif@ietf.org>=20

                  &nb= sp;    https://www.ietf.org/mailman/listinfo/mif


&nbs= p;                  __________= _____________________________________
                   mif ma= iling list
               =    mif@ietf.or= g <mailto:mif@ietf= .org>=20

                  &nb= sp;= https://www.ietf.org/mailman/listinfo/mif




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

_______________________________________________
mif mailing list
= mif@ietf.org
https://= www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing listmif@ietf.org
https:/= /www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


--001636458206783f3b046164d9c0-- --===============0811620833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0811620833==-- From mif-bounces@ietf.org Mon Jan 26 16:13:07 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C463A6841; Mon, 26 Jan 2009 16:13:07 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE4B3A657C for ; Mon, 26 Jan 2009 16:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ+ZZ8cfYnQe for ; Mon, 26 Jan 2009 16:13:04 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id EC6673A6841 for ; Mon, 26 Jan 2009 16:13:03 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so5301339yxg.49 for ; Mon, 26 Jan 2009 16:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+xYdUQSVZuV2QF/Md6eN66ev0RT8jFg1m4IioO270s4=; b=j9yQc8SGBEWcshHFEWdB5LaQAFMs62iPvP/1sanBtmoC7uDiK8NrJ5D08v8vFuFRHa GOwlnyRIq9UZl/N/N71KP5Uxc2WjclU4+F44bQ6lvddHFvFrp/yazK08BmXfC72vz0Yv iYiH2Mpclcn3Fc4D2qcUDmZbhk+HlWfpxRF4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vuYpa4HE6aG7yStwHNAmljaJqWs+s4u+XY6eg1h4K3Bme7aHNUHEZ6igH9jV4kzTfi vJj1uAUPpypOrcfUlVrcNp05xgnJrIFSWF6aaw0AZuEZxSfm+991iZmeuDjZthmkxDdy FYdKNQRGjp9kAHTft00H3g89AkuPqcOYGZVhc= MIME-Version: 1.0 Received: by 10.150.196.5 with SMTP id t5mr1490079ybf.98.1233015166250; Mon, 26 Jan 2009 16:12:46 -0800 (PST) In-Reply-To: <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> Date: Mon, 26 Jan 2009 16:12:46 -0800 Message-ID: From: Kevin Chin To: Hui Deng Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491606006==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0491606006== Content-Type: multipart/alternative; boundary=000e0cd47e54fcb01d04616bb619 --000e0cd47e54fcb01d04616bb619 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 1) "Are you saying that sending information from MS to network is a kind of disclose privacy concern? can you help to elaborate more on that?" My assumption was the MS would pass on NAI, ISIM, or other mechanism which can be used as index into database. This same information can be used to track presence and location. Not a concern for your current Mobile Operator but when there are 2 or more parties involved, it should not assume network information can be freely shared across organizations. Some users may not want certain hosts to be accessed over a certain network -- e.g. sports scores during working hours... 2) "I could fee that it will be hard if there is policy confliction.but we can do sth in some scale. for what you said here, convenience and cost can't be achieved simultaneously, what do you mean about "monetary cost" here?" Assume I have WLAN and Cellular data interfaces. Further assume WLAN is free and where cellular data is not. A user may want to use WLAN even though non-optimal routing. There are also counter-examples of cost v. convenience. The best path is not always fastest or shortest path -- monetary cost may be a factor. thanks On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng wrote: > Hi, Kevin, > > I feel that you give two good advice here, > Please allow me more clarification inline below: > > 2009/1/24 Kevin Chin kchin.xor@gmail.com > >> > 7) Is there a way for the host and the network to communicate about >>> their >>> > policies regarding all of the above? >>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>> communicate their policies. Besides, if the policies of MIF node can >>> not be followed by the peer node, in this sense, we need a way to >>> communicate about the policies among host/peer/network. >>> >> >> "communicate their policies among host/peer/network" seems to imply more >> message intensive transfer of state from MS. >> Privacy concerns are also legitimate if network needs information from MS >> to support MIF. >> > Are you saying that sending information from MS to network is a kind of > disclose privacy concern? can you help to elaborate more on that? > >> >> "policy conflict when >1 operator/network" can not optimize for device >> specific policies, there are trade-offs between "monetary cost" and >> speed/access/convenience. >> > I could fee that it will be hard if there is policy confliction.but we can > do sth in some scale. > for what you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here? > > thanks for your explanation. > > -Hui > >> >> thanks >> >> >> On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: >> >>> Hi, Kevin, >>> >>> I tend to agree with you here that the terminal may not need to upstream >>> the capability to the network. but do you see any proposal here doing that? >>> >>> but sometime, MS made some decision on the interface and route, but what >>> happen if network congested, how to handle that? just waiting for the fall >>> back. >>> >>> For confliction of policy, I guess that it could be categorized by two >>> case, >>> one operator, then it should be avoided by offline arrangement, >>> for two ISPs, FIFO still work there, cause no problem for user's >>> traffic. >>> >>> thanks for the discussion. >>> >>> -Tao >>> >>> >>> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: >>> >>>> >>>> >>>>> 1) MIF for IPv4 or IPv6 or Both? >>>> >>>> >>>> >>>>> >>>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>>> need to do the harmonization with other protocols? >>>>> 3) There is the case that one interface is connected, but the route to >>>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>>> this case? >>>>> >>>> >>>> > 7) Is there a way for the host and the network to communicate about >>>> their >>>> > policies regarding all of the above? >>>> >>>> Very interesting topic. >>>> >>>> I assume MIF is optional "should" v. "must" w.r.t policies from the >>>> network (e.g. guidance not directive). >>>> The MS may have lots of policies which can make an informed decision. >>>> >>>> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. >>>> This would imply MS pushing characteristics up to the network so the >>>> network can push device-specific directives down. >>>> It should not be the case that the device needs to push capabilties >>>> upstream for the network to provide MIF-based guidance. >>>> >>>> Furthermore there may be different networks on each interface >>>> necessitating conflict resolution protocols, let alone issues that occur >>>> sporadically (e.g. WiFI portal, network roaming policies, access-based >>>> policy) .... >>>> >>>> Can't device based provisioning with (optional) input from network >>>> address most of the stated issues? >>>> >>>> thanks- >>>> Kevin >>>> >>>> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: >>>> >>>>> Hi, Jari: >>>>> >>>>> Please check my lines: >>>>> >>>>> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko >>>>> wrote: >>>>> > Again, there seems to be two issues. The first issue is having a >>>>> policy that >>>>> > tells an application which addresses to use (and indirectly which >>>>> interface >>>>> > to use). The second issue is that if the policy comes, e.g., via DHCP >>>>> on a >>>>> > per-interface basis, then we again have to reconcile the different >>>>> policies >>>>> > on a per-node basis. >>>>> [Peny] Agree with you for the two issues. Another point in my mind may >>>>> be a possible issue. When a peer tries to initiate flows with MIF >>>>> node, we need some way to let the peer know the policies and follow >>>>> the policies of MIF node. >>>>> >>>>> > My personal classification of problems in the multiple interface >>>>> space >>>>> > includes the following: >>>>> > >>>>> > 1) Access selection, i.e., which network(s) to attach to using the >>>>> physical >>>>> > interface(s) that the host has. Already covered in RFC 5113. >>>>> > >>>>> > 2) Split DNS: If a host is attached to a number of different >>>>> interfaces, how >>>>> > does it resolve a FQDN if more than one interface has provided a DNS >>>>> server >>>>> > address? >>>>> > >>>>> > 3) Configuration reconciliation: how do we merge and use DHCP and >>>>> other >>>>> > configuration information in a node, when the information is received >>>>> on a >>>>> > per-interface basis? >>>>> > >>>>> > 4) Routing: If a host is attached to a number of different >>>>> interfaces, where >>>>> > does a particular IP packet go? >>>>> > >>>>> > 5) Address selection: If a host is attached to a number of different >>>>> > interfaces, which addresses should be used for a particular >>>>> application >>>>> > flow? >>>>> > >>>>> > 6) Tunnel multihoming: If a host is attached to a number of different >>>>> > interfaces and runs some kind of a tunneling or mobility back to a >>>>> home >>>>> > agent, which interface and addresses should be used for a particular >>>>> packet? >>>>> > Already covered in existing MEXT WG work items. >>>>> [Peny] Agree with you from 1 to 6. >>>>> >>>>> > 7) Is there a way for the host and the network to communicate about >>>>> their >>>>> > policies regarding all of the above? >>>>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>>>> communicate their policies. Besides, if the policies of MIF node can >>>>> not be followed by the peer node, in this sense, we need a way to >>>>> communicate about the policies among host/peer/network. >>>>> >>>>> > My understanding is that the proposed BOF would be looking at >>>>> problems 2, 3, >>>>> > 4, 5, and 7. The others are covered elsewhere. >>>>> [Peny] Some other points I have been thinking of: >>>>> 1) MIF for IPv4 or IPv6 or Both? >>>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>>> need to do the harmonization with other protocols? >>>>> 3) There is the case that one interface is connected, but the route to >>>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>>> this case? >>>>> >>>>> BRG >>>>> Peny >>>>> >>>>> >>>>> > Jari >>>>> > >>>>> > _______________________________________________ >>>>> > mif mailing list >>>>> > mif@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/mif >>>>> > >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> >>>> >>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> >>> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --000e0cd47e54fcb01d04616bb619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) "Are you saying that sending information from MS to network is= a kind of disclose privacy concern? can you help to elaborate more on that= ?"
 
My assumption was the MS would pass on NAI, ISIM, or other mechanism w= hich can be used as index into database. This same information can be used = to track presence and location. Not a concern for your current Mobile Opera= tor but when there are 2 or more parties involved, it should not assume net= work information can be freely shared across organizations. Some users may = not want certain hosts to be accessed over a certain network -- e.g. sports= scores during working hours...
 
2) "I could fee that it will be hard if there is policy conflicti= on.but we can do sth in some scale.
for what you said here, convenience and cost can't be achieve= d simultaneously, what do you
mean about "monetary cost" here?"
 
Assume I have WLAN and Cellular data interfaces. Further assume WLAN i= s free and where cellular data is not.
A user may want to use WLAN even though non-optimal routing. There are= also counter-examples of cost v. convenience.
The best path is not always fastest or shortest path -- monetary cost = may be a factor.
 
thanks

On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng <denghui02@gmail.com<= /a>> wrote:
Hi, Kevin,
 
I feel that you give two good advice here,
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
[Peny] For 7, maybe we could make the way for host/PEER/network to
= communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.
 
"communicate their policies among host/peer/network" seems t= o imply more message intensive transfer of state from MS.
Privacy concerns are also legitimate if network needs information from= MS to support MIF.
Are you saying that sending information from MS to network is a kind o= f disclose privacy concern? can you help to elaborate more on that?

"policy conflict when >1 operator/network" can not op= timize for device specific policies, there are trade-offs between "mon= etary cost" and speed/access/convenience.
I could fee that it will be hard if there is policy confliction.but we= can do sth in some scale.
for what you said here, convenience and cost can't be achieve= d simultaneously, what do you
mean about "monetary cost" here?
 
thanks for your explanation.
 
-Hui
 
thanks

 
On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <his= untao@gmail.com> wrote:
Hi, Kevin,
 
I tend to agree with you here that the terminal may not need to&n= bsp;upstream the capability to the network. but do you see any proposal her= e doing that?

but sometime, MS made some decision on the interface a= nd route, but what happen if network congested, how to handle that? just wa= iting for the fall back.
 
For confliction of policy, I guess that it could be categorized by two= case,
one operator, then it should be avoided by offline arrangement,
for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
 
thanks for the discussion.
 
-Tao
 
 
On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.com> wrote:
 
1) MIF for IPv4 or IPv6 or Both?=
 

2)  Will M= IF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the = harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:=
> Again, there seems to be two issues. The first issue is having a p= olicy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate= about their
> policies regarding all of the above?
[Peny] F= or 7, maybe we could make the way for host/PEER/network to
communicate t= heir policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at= problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
<= /div>[Peny] Some other points I have been thinking of:
1) MIF for IPv4 o= r IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
= need to do the harmonization with other protocols?
3) There is the case = that one interface is connected, but the route to
internet is not availa= ble (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny


> Jari
>
> ____________________________________= ___________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/list= info/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mif" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinf= o/mif



<= br>_______________________________________________
mif mailing list
<= a href=3D"mailto:mif@ietf.org" target=3D"_blank">mif@ietf.org
https://w= ww.ietf.org/mailman/listinfo/mif



--000e0cd47e54fcb01d04616bb619-- --===============0491606006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0491606006==-- From mif-bounces@ietf.org Tue Jan 27 02:17:32 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D193A6A7E; Tue, 27 Jan 2009 02:17:32 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119113A692A for ; Tue, 27 Jan 2009 02:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEQif8Xg9NDC for ; Tue, 27 Jan 2009 02:17:30 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 355C43A6A7E for ; Tue, 27 Jan 2009 02:17:30 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 11:17:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 11:17:10 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet Thread-Index: AcmAE/9KMt4TdfvCR+yts1aMkVdySgAT5RrQAAA6AWA= References: <200901181405165005812@gmail.com><1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com><200901191706482187921@gmail.com><1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com><4977AC28.2050702@piuha.net><4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com><1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> From: To: , X-OriginalArrivalTime: 27 Jan 2009 10:17:10.0904 (UTC) FILETIME=[6A884780:01C98068] Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi Kevin, As you stated, the user may prefer, depending on the application, access wi= th lowest cost even if loosing QoS. I definitely agree but it's just an exa= mple and there are plenty of others criteria that may come into play. I also agree with your first statement. Some actors may want for informatio= n/policy to not be disclosed. In addition to your example, an operator may = not want to disclose its selection policies or network load information (as= suming load is part of the selection criteria). Anyway, if these considerations are very interesting and fundamentals, I'm = not sure they are in the scope of MIF and IETF. But, maybe I'm missing some= thing; are you proposing to work on access selection problem? Actually, now I'm confused about the scope of MIF. Hui, can you clarify MIF= 's scope? Do you have hints for a charter? What about Jari's proposal? Regards, Pierrick > = > ________________________________________ > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Kevin Chin > Envoy=E9=A0: mardi 27 janvier 2009 01:13 > =C0=A0: Hui Deng > Cc=A0: mif > Objet=A0: Re: [mif] draft-blanchet > = > 1) "Are you saying that sending information from MS to network is a kind > of disclose privacy concern? can you help to elaborate more on that?" > = > My assumption was the MS would pass on NAI, ISIM, or other mechanism which > can be used as index into database. This same information can be used to > track presence and location. Not a concern for your current Mobile > Operator but when there are 2 or more parties involved, it should not > assume network information can be freely shared across organizations. Some > users may not want certain hosts to be accessed over a certain network -- > e.g. sports scores during working hours... > = > 2) "I could fee that it will be hard if there is policy confliction.but we > can do sth in some scale. > for what=A0you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here?" > = > Assume I have WLAN and Cellular data interfaces. Further assume WLAN is > free and where cellular data is not. > A user may want to use WLAN even though non-optimal routing. There are > also counter-examples of cost v. convenience. > The best path is not always fastest or shortest path -- monetary cost may > be a factor. > = > thanks > On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng wrote: > Hi, Kevin, > = > I feel that you give two good advice here, > Please allow me more clarification inline below: > = > 2009/1/24 Kevin Chin kchin.xor@gmail.com > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > = > "communicate their policies among host/peer/network" seems to imply more > message intensive transfer of state from MS. > Privacy concerns are also legitimate if network needs information from MS > to support MIF. > Are you saying that sending information from MS to network is a kind of > disclose privacy concern? can you help to elaborate more on that? > = > "policy conflict when >1 operator/network" can not optimize for device > specific policies, there are trade-offs between "monetary cost" and > speed/access/convenience. > I could fee that it will be hard if there is policy confliction.but we can > do sth in some scale. > for what=A0you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here? > = > thanks for your explanation. > = > -Hui > = > thanks > = > = > On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: > Hi, Kevin, > = > I tend to agree with you=A0here that the terminal may not need to=A0upstr= eam > the capability to the network. but do you see any proposal here doing tha= t? > = > but sometime, MS made some decision on the interface and route, but what > happen if network congested, how to handle that? just waiting for the fall > back. > = > For confliction of policy, I guess that it could be categorized by two > case, > one operator, then it should be avoided by offline arrangement, > for two ISPs,=A0 FIFO still work there, cause no problem for user's traff= ic. > = > thanks for the discussion. > = > -Tao > = > = > On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: > = > 1) MIF for IPv4 or IPv6 or Both? > = > = > 2) =A0Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). =A0How does MIF handle > this case? > = > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > = > Very interesting topic. > = > I assume MIF is optional "should" v. "must" w.r.t policies from the > network (e.g. guidance not directive). > The MS may have lots of policies which can make an informed decision. > = > As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. > This would imply MS pushing characteristics up to the network so the > network can push device-specific directives down. > It should not be the case=A0that the device=A0needs to push capabilties > upstream for the network to provide MIF-based guidance. > = > Furthermore there may be different networks on each interface > necessitating conflict resolution protocols, let alone issues that occur > sporadically (e.g. WiFI portal, network roaming policies, access-based > policy) .... > = > Can't device based provisioning with (optional) input from network address > most of the stated issues? > = > thanks- > Kevin > On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrot= e: > Hi, Jari: > = > Please check my lines: > = > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko wrote: > > Again, there seems to be two issues. The first issue is having a policy > that > > tells an application which addresses to use (and indirectly which > interface > > to use). The second issue is that if the policy comes, e.g., via DHCP on > a > > per-interface basis, then we again have to reconcile the different > policies > > on a per-node basis. > [Peny] Agree with you for the two issues. Another point in my mind may > be a possible issue. When a peer tries to initiate flows with MIF > node, we need some way to let the peer know the policies and follow > the policies of MIF node. > = > > My personal classification of problems in the multiple interface space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > physical > > interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different interfaces, > how > > does it resolve a FQDN if more than one interface has provided a DNS > server > > address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and other > > configuration information in a node, when the information is received on > a > > per-interface basis? > > > > 4) Routing: If a host is attached to a number of different interfaces, > where > > does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > interfaces and runs some kind of a tunneling or mobility back to a home > > agent, which interface and addresses should be used for a particular > packet? > > Already covered in existing MEXT WG work items. > [Peny] Agree with you from 1 to 6. > = > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > = > > My understanding is that the proposed BOF would be looking at problems = 2, > 3, > > 4, 5, and 7. The others are covered elsewhere. > [Peny] Some other points I have been thinking of: > 1) MIF for IPv4 or IPv6 or Both? > 2) =A0Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). =A0How does MIF handle > this case? > = > BRG > Peny > = > = > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = > = > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = > = > = > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Tue Jan 27 08:10:27 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E203A6B8A; Tue, 27 Jan 2009 08:10:27 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437DB3A6B85 for ; Tue, 27 Jan 2009 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUDitZqtmL+d for ; Tue, 27 Jan 2009 08:10:20 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 6F3173A6A6F for ; Tue, 27 Jan 2009 08:10:20 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so7339229wfd.31 for ; Tue, 27 Jan 2009 08:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3FKIvKSwAETaNVauWrIHKj3ldgIlF9QIiXlYLA6kIjI=; b=hcc0WjLtX72nGMO+1XbUFBjyfqbcWPiwLcdhrF4oIjFkBbrYuVfzeAl4KNtH4i0enc +FpuER8zjO79P+N50O6K0TRQHhSZ2j0qQ1VHI5RMFf0kNhnlf9peqxP9l6ag+HcZSsvD wnayXPcycj6DW9k9f+6MXzrYkzA8dandGON2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kp1J6lxI2NBo7xgUJF4m74FeQO39ig9b526fTsqjdWtRItZW/KjLyi8EtgwpwsLcDv oN4pUU5hbnSncRETpIb2U4sIeW8ixM5IyRSKvipznz/T5hRArrUtggfwo8fpvVpJX3BD bANc/xcToVOnF0wjZjKj1tRV4Lx6mXlRiK4CI= MIME-Version: 1.0 Received: by 10.143.158.16 with SMTP id k16mr4419503wfo.47.1233072602196; Tue, 27 Jan 2009 08:10:02 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> Date: Wed, 28 Jan 2009 00:10:02 +0800 Message-ID: <1d38a3350901270810n48e03a7cyff1e25d1a5f23afe@mail.gmail.com> From: Hui Deng To: Kevin Chin Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937406696==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1937406696== Content-Type: multipart/alternative; boundary=001636e1fba76faa7204617916f2 --001636e1fba76faa7204617916f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Kevin, I guess that you raise one basic requirement which MIF should be takeing care with, one is not disclose user privacy information and should think the different policy on other links. Secondly, we should allow user could select cost other than better optimal routing. MIF does allow the host do that, what mif would like to do is to offer the other(better) choice for them. These two points you raised are not conflicted with current mif's intention but good remindness for our work. many thanks for your comments. -Hui 2009/1/27 Kevin Chin > 1) "Are you saying that sending information from MS to network is a kind > of disclose privacy concern? can you help to elaborate more on that?" > > My assumption was the MS would pass on NAI, ISIM, or other mechanism which > can be used as index into database. This same information can be used to > track presence and location. Not a concern for your current Mobile Operator > but when there are 2 or more parties involved, it should not assume network > information can be freely shared across organizations. Some users may not > want certain hosts to be accessed over a certain network -- e.g. sports > scores during working hours... > > 2) "I could fee that it will be hard if there is policy confliction.but > we can do sth in some scale. > for what you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here?" > > Assume I have WLAN and Cellular data interfaces. Further assume WLAN is > free and where cellular data is not. > A user may want to use WLAN even though non-optimal routing. There are also > counter-examples of cost v. convenience. > The best path is not always fastest or shortest path -- monetary cost may > be a factor. > > thanks > > On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng wrote: > >> Hi, Kevin, >> >> I feel that you give two good advice here, >> Please allow me more clarification inline below: >> >> 2009/1/24 Kevin Chin kchin.xor@gmail.com >> >>> > 7) Is there a way for the host and the network to communicate about >>>> their >>>> > policies regarding all of the above? >>>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>>> communicate their policies. Besides, if the policies of MIF node can >>>> not be followed by the peer node, in this sense, we need a way to >>>> communicate about the policies among host/peer/network. >>>> >>> >>> "communicate their policies among host/peer/network" seems to imply more >>> message intensive transfer of state from MS. >>> Privacy concerns are also legitimate if network needs information from MS >>> to support MIF. >>> >> Are you saying that sending information from MS to network is a kind of >> disclose privacy concern? can you help to elaborate more on that? >> >>> >>> "policy conflict when >1 operator/network" can not optimize for device >>> specific policies, there are trade-offs between "monetary cost" and >>> speed/access/convenience. >>> >> I could fee that it will be hard if there is policy confliction.but we can >> do sth in some scale. >> for what you said here, convenience and cost can't be achieved >> simultaneously, what do you >> mean about "monetary cost" here? >> >> thanks for your explanation. >> >> -Hui >> >>> >>> thanks >>> >>> >>> On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: >>> >>>> Hi, Kevin, >>>> >>>> I tend to agree with you here that the terminal may not need to upstream >>>> the capability to the network. but do you see any proposal here doing that? >>>> >>>> but sometime, MS made some decision on the interface and route, but what >>>> happen if network congested, how to handle that? just waiting for the fall >>>> back. >>>> >>>> For confliction of policy, I guess that it could be categorized by two >>>> case, >>>> one operator, then it should be avoided by offline arrangement, >>>> for two ISPs, FIFO still work there, cause no problem for user's >>>> traffic. >>>> >>>> thanks for the discussion. >>>> >>>> -Tao >>>> >>>> >>>> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: >>>> >>>>> >>>>> >>>>>> 1) MIF for IPv4 or IPv6 or Both? >>>>> >>>>> >>>>> >>>>>> >>>>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>>>> need to do the harmonization with other protocols? >>>>>> 3) There is the case that one interface is connected, but the route to >>>>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>>>> this case? >>>>>> >>>>> >>>>> > 7) Is there a way for the host and the network to communicate about >>>>> their >>>>> > policies regarding all of the above? >>>>> >>>>> Very interesting topic. >>>>> >>>>> I assume MIF is optional "should" v. "must" w.r.t policies from the >>>>> network (e.g. guidance not directive). >>>>> The MS may have lots of policies which can make an informed decision. >>>>> >>>>> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. >>>>> This would imply MS pushing characteristics up to the network so the >>>>> network can push device-specific directives down. >>>>> It should not be the case that the device needs to push capabilties >>>>> upstream for the network to provide MIF-based guidance. >>>>> >>>>> Furthermore there may be different networks on each interface >>>>> necessitating conflict resolution protocols, let alone issues that occur >>>>> sporadically (e.g. WiFI portal, network roaming policies, access-based >>>>> policy) .... >>>>> >>>>> Can't device based provisioning with (optional) input from network >>>>> address most of the stated issues? >>>>> >>>>> thanks- >>>>> Kevin >>>>> >>>>> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang wrote: >>>>> >>>>>> Hi, Jari: >>>>>> >>>>>> Please check my lines: >>>>>> >>>>>> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko >>>>>> wrote: >>>>>> > Again, there seems to be two issues. The first issue is having a >>>>>> policy that >>>>>> > tells an application which addresses to use (and indirectly which >>>>>> interface >>>>>> > to use). The second issue is that if the policy comes, e.g., via >>>>>> DHCP on a >>>>>> > per-interface basis, then we again have to reconcile the different >>>>>> policies >>>>>> > on a per-node basis. >>>>>> [Peny] Agree with you for the two issues. Another point in my mind may >>>>>> be a possible issue. When a peer tries to initiate flows with MIF >>>>>> node, we need some way to let the peer know the policies and follow >>>>>> the policies of MIF node. >>>>>> >>>>>> > My personal classification of problems in the multiple interface >>>>>> space >>>>>> > includes the following: >>>>>> > >>>>>> > 1) Access selection, i.e., which network(s) to attach to using the >>>>>> physical >>>>>> > interface(s) that the host has. Already covered in RFC 5113. >>>>>> > >>>>>> > 2) Split DNS: If a host is attached to a number of different >>>>>> interfaces, how >>>>>> > does it resolve a FQDN if more than one interface has provided a DNS >>>>>> server >>>>>> > address? >>>>>> > >>>>>> > 3) Configuration reconciliation: how do we merge and use DHCP and >>>>>> other >>>>>> > configuration information in a node, when the information is >>>>>> received on a >>>>>> > per-interface basis? >>>>>> > >>>>>> > 4) Routing: If a host is attached to a number of different >>>>>> interfaces, where >>>>>> > does a particular IP packet go? >>>>>> > >>>>>> > 5) Address selection: If a host is attached to a number of different >>>>>> > interfaces, which addresses should be used for a particular >>>>>> application >>>>>> > flow? >>>>>> > >>>>>> > 6) Tunnel multihoming: If a host is attached to a number of >>>>>> different >>>>>> > interfaces and runs some kind of a tunneling or mobility back to a >>>>>> home >>>>>> > agent, which interface and addresses should be used for a particular >>>>>> packet? >>>>>> > Already covered in existing MEXT WG work items. >>>>>> [Peny] Agree with you from 1 to 6. >>>>>> >>>>>> > 7) Is there a way for the host and the network to communicate about >>>>>> their >>>>>> > policies regarding all of the above? >>>>>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>>>>> communicate their policies. Besides, if the policies of MIF node can >>>>>> not be followed by the peer node, in this sense, we need a way to >>>>>> communicate about the policies among host/peer/network. >>>>>> >>>>>> > My understanding is that the proposed BOF would be looking at >>>>>> problems 2, 3, >>>>>> > 4, 5, and 7. The others are covered elsewhere. >>>>>> [Peny] Some other points I have been thinking of: >>>>>> 1) MIF for IPv4 or IPv6 or Both? >>>>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>>>> need to do the harmonization with other protocols? >>>>>> 3) There is the case that one interface is connected, but the route to >>>>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>>>> this case? >>>>>> >>>>>> BRG >>>>>> Peny >>>>>> >>>>>> >>>>>> > Jari >>>>>> > >>>>>> > _______________________________________________ >>>>>> > mif mailing list >>>>>> > mif@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/mif >>>>>> > >>>>>> _______________________________________________ >>>>>> mif mailing list >>>>>> mif@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mif >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >> > --001636e1fba76faa7204617916f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Kevin,
 
I guess that you raise one basic requirement which MIF shoul= d be takeing care with, one is not disclose user privacy information and sh= ould think the different policy on other links.
 
Secondly, we should allow user could select cost other than bette= r optimal routing. MIF does allow the host do that, what mif = ;would like to do is to offer the other(better) choice for them.
 
These two points you raised are not conflicted with current mif&#= 39;s intention but good remindness for our work.
many thanks for your comments.
 
-Hui
 
2009/1/27 Kevin Chin <kchin.xor@gmail.com>
1) "Are you saying that sending information from MS to network is= a kind of disclose privacy concern? can you help to elaborate more on that= ?"
 
My assumption was the MS would pass on NAI, ISIM, or other mechanism w= hich can be used as index into database. This same information can be used = to track presence and location. Not a concern for your current Mobile Opera= tor but when there are 2 or more parties involved, it should not assume net= work information can be freely shared across organizations. Some users may = not want certain hosts to be accessed over a certain network -- e.g. sports= scores during working hours...
 
2) "I could fee that it will be hard if there is policy conflicti= on.but we can do sth in some scale.
for what you said here, convenience and cost can't be achieve= d simultaneously, what do you
mean about "monetary cost" here?"
 
Assume I have WLAN and Cellular data interfaces. Further assume WLAN i= s free and where cellular data is not.
A user may want to use WLAN even though non-optimal routing. There are= also counter-examples of cost v. convenience.
The best path is not always fastest or shortest path -- monetary cost = may be a factor.
 
thanks

On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng <de= nghui02@gmail.com> wrote:
Hi, Kevin,
 
I feel that you give two good advice here,
Please allow me more clarification inline below:

2009/1/24 Kevi= n Chin kchin.xor@gmail.com
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
[Peny] For 7, maybe we could make the way for host/PEER/network to
= communicate their policies. Besides, if the policies of MIF node can
not= be followed by the peer node, in this sense, we need a way to
communica= te about the policies among host/peer/network.
 
"communicate their policies among host/peer/network" seems t= o imply more message intensive transfer of state from MS.
Privacy concerns are also legitimate if network needs information from= MS to support MIF.
Are you saying that sending information from MS to network is a kind o= f disclose privacy concern? can you help to elaborate more on that?

"policy conflict when >1 operator/network" can not op= timize for device specific policies, there are trade-offs between "mon= etary cost" and speed/access/convenience.
I could fee that it will be hard if there is policy confliction.but we= can do sth in some scale.
for what you said here, convenience and cost can't be achieve= d simultaneously, what do you
mean about "monetary cost" here?
 
thanks for your explanation.
 
-Hui
 
thanks

 
On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <his= untao@gmail.com> wrote:
Hi, Kevin,
 
I tend to agree with you here that the terminal may not need to&n= bsp;upstream the capability to the network. but do you see any proposal her= e doing that?

but sometime, MS made some decision on the interface a= nd route, but what happen if network congested, how to handle that? just wa= iting for the fall back.
 
For confliction of policy, I guess that it could be categorized by two= case,
one operator, then it should be avoided by offline arrangement,
for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
 
thanks for the discussion.
 
-Tao
 
 
On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.com> wrote:
 
1) MIF for IPv4 or IPv6 or Both?=
 

2)  Will M= IF need to co-work with (P)MIP, DSMIP, etc? If so, do we
need to do the = harmonization with other protocols?
3) There is the case that one interface is connected, but the route to
i= nternet is not available (Such as WiFi Portal).  How does MIF handlethis case?
 
> 7) Is there a way for the host and the network to communicate abo= ut their
> policies regarding all of the above?
 
Very interesting topic.
 
I assume MIF is optional "should" v. "must" w.r.t = policies from the network (e.g. guidance not directive).
The MS may have lots of policies which can make an informed decision.<= /div>
 
As such IPv6, PMIP, DSMIP should not be considered in policies for MIF= .
This would imply MS pushing characteristics up to the network so the n= etwork can push device-specific directives down.
It should not be the case that the device needs to push capa= bilties upstream for the network to provide MIF-based guidance.
 
Furthermore there may be different networks on each interface necessit= ating conflict resolution protocols, let alone issues that occur sporadical= ly (e.g. WiFI portal, network roaming policies, access-based policy) ....
 
Can't device based provisioning with (optional) input from network= address most of the stated issues?
 
thanks-
Kevin

On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> wrote:
Hi, Jari:

Please check my= lines:

On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:=
> Again, there seems to be two issues. The first issue is having a p= olicy that
> tells an application which addresses to use (and indirectly which inte= rface
> to use). The second issue is that if the policy comes, e.g., = via DHCP on a
> per-interface basis, then we again have to reconcile = the different policies
> on a per-node basis.
[Peny] Agree with you for the two issues= . Another point in my mind may
be a possible issue. When a peer tries to= initiate flows with MIF
node, we need some way to let the peer know the= policies and follow
the policies of MIF node.

> My personal classification of problems in the multiple interf= ace space
> includes the following:
>
> 1) Access selecti= on, i.e., which network(s) to attach to using the physical
> interfac= e(s) that the host has. Already covered in RFC 5113.
>
> 2) Split DNS: If a host is attached to a number of different i= nterfaces, how
> does it resolve a FQDN if more than one interface ha= s provided a DNS server
> address?
>
> 3) Configuration r= econciliation: how do we merge and use DHCP and other
> configuration information in a node, when the information is received = on a
> per-interface basis?
>
> 4) Routing: If a host is = attached to a number of different interfaces, where
> does a particul= ar IP packet go?
>
> 5) Address selection: If a host is attached to a number of dif= ferent
> interfaces, which addresses should be used for a particular = application
> flow?
>
> 6) Tunnel multihoming: If a host = is attached to a number of different
> interfaces and runs some kind of a tunneling or mobility back to a hom= e
> agent, which interface and addresses should be used for a particu= lar packet?
> Already covered in existing MEXT WG work items.
[Peny] Agree with you from 1 to 6.

> 7) Is there a way for the host and the network to communicate= about their
> policies regarding all of the above?
[Peny] F= or 7, maybe we could make the way for host/PEER/network to
communicate t= heir policies. Besides, if the policies of MIF node can
not be followed by the peer node, in this sense, we need a way to
commun= icate about the policies among host/peer/network.

> My understanding is that the proposed BOF would be looking at= problems 2, 3,
> 4, 5, and 7. The others are covered elsewhere.
<= /div>[Peny] Some other points I have been thinking of:
1) MIF for IPv4 o= r IPv6 or Both?
2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
= need to do the harmonization with other protocols?
3) There is the case = that one interface is connected, but the route to
internet is not availa= ble (Such as WiFi Portal).  How does MIF handle
this case?

BRG
Peny


> Jari
>
> ____________________________________= ___________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/list= info/mif
>
_______________________________________________
mif mailing list=
mif@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mif" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/mif


________________________= _______________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinf= o/mif



<= br>_______________________________________________
mif mailing list
<= a href=3D"mailto:mif@ietf.org" target=3D"_blank">mif@ietf.org
https://w= ww.ietf.org/mailman/listinfo/mif



<= /blockquote>

--001636e1fba76faa7204617916f2-- --===============1937406696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1937406696==-- From mif-bounces@ietf.org Tue Jan 27 08:17:41 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12833A6924; Tue, 27 Jan 2009 08:17:41 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987123A6924 for ; Tue, 27 Jan 2009 08:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+XGIKsNHUUu for ; Tue, 27 Jan 2009 08:17:38 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 2A5963A6826 for ; Tue, 27 Jan 2009 08:17:38 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1950956ana.4 for ; Tue, 27 Jan 2009 08:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BFRgxiGNCfbU2SPlZHb+VakwGrrj7Ofke4wZDKaCUN8=; b=AFCOpQKy6Tn4cm0iaVFYhFTsevN6hJG+lj6GKwPcQlKSNTxUVn8rc8tYco1qwKX/5G 10lFaOdjgM/wQdIFnjh4BefhUxytyMcURDE/x2GMGfG9ceVgEckVAggFeMeGcqPzFhnt Hr8hPIXPEmQSmRT3ZAsF7HSeIXQwVwHeZ5654= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cMkY15jL4KWxgxn448PalADWVPU28ClIj8FpDrR7+8JB8mTpZHY3soEwxcUThu5Msx PcvJ9meFv3Ijcbc8aFTrpL+Tizy/TsOfGyte5OzQsoLe+zYipXgWb7pDZKEdq9y9ywvq 8e0ga4Ie7MYoCx20Gw1SlOGeRzfxLULyb3dnE= MIME-Version: 1.0 Received: by 10.142.217.17 with SMTP id p17mr203173wfg.172.1233073039305; Tue, 27 Jan 2009 08:17:19 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> Date: Wed, 28 Jan 2009 00:17:19 +0800 Message-ID: <1d38a3350901270817y120e218ay42a34b9e4bfb4d31@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1446901414==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1446901414== Content-Type: multipart/alternative; boundary=000e0cd2e0827d6d450461793038 --000e0cd2e0827d6d450461793038 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Pierrick, You made the two points Kevin raised more clear from the ISP's point of view. I couldn't agree with you any more on it. As you said here, those are not i= n the scope of current MIF's proposal. for network discovery and selection, RFC 5113 already did a clear analysis on it which we could refer on it. For yoru question about what mif's scope at the moment, Jari already made the comments on http://www.ietf.org/mail-archive/web/mif/current/msg00050.html As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we should narrow down our scope based on current PS drafts: http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt Thanks again. Best regards, -Hui 2009/1/27 > Hi Kevin, > > > As you stated, the user may prefer, depending on the application, access > with lowest cost even if loosing QoS. I definitely agree but it's just an > example and there are plenty of others criteria that may come into play. > > I also agree with your first statement. Some actors may want for > information/policy to not be disclosed. In addition to your example, an > operator may not want to disclose its selection policies or network load > information (assuming load is part of the selection criteria). > > Anyway, if these considerations are very interesting and fundamentals, I'= m > not sure they are in the scope of MIF and IETF. But, maybe I'm missing > something; are you proposing to work on access selection problem? > > Actually, now I'm confused about the scope of MIF. Hui, can you clarify > MIF's scope? Do you have hints for a charter? What about Jari's proposal? > > Regards, > Pierrick > > > > > ________________________________________ > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > > Kevin Chin > > Envoy=E9 : mardi 27 janvier 2009 01:13 > > =C0 : Hui Deng > > Cc : mif > > Objet : Re: [mif] draft-blanchet > > > > 1) "Are you saying that sending information from MS to network is a > kind > > of disclose privacy concern? can you help to elaborate more on that?" > > > > My assumption was the MS would pass on NAI, ISIM, or other mechanism > which > > can be used as index into database. This same information can be used t= o > > track presence and location. Not a concern for your current Mobile > > Operator but when there are 2 or more parties involved, it should not > > assume network information can be freely shared across organizations. > Some > > users may not want certain hosts to be accessed over a certain network = -- > > e.g. sports scores during working hours... > > > > 2) "I could fee that it will be hard if there is policy confliction.but > we > > can do sth in some scale. > > for what you said here, convenience and cost can't be achieved > > simultaneously, what do you > > mean about "monetary cost" here?" > > > > Assume I have WLAN and Cellular data interfaces. Further assume WLAN is > > free and where cellular data is not. > > A user may want to use WLAN even though non-optimal routing. There are > > also counter-examples of cost v. convenience. > > The best path is not always fastest or shortest path -- monetary cost m= ay > > be a factor. > > > > thanks > > On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng wrote: > > Hi, Kevin, > > > > I feel that you give two good advice here, > > Please allow me more clarification inline below: > > > > 2009/1/24 Kevin Chin kchin.xor@gmail.com > > > 7) Is there a way for the host and the network to communicate about > > their > > > policies regarding all of the above? > > [Peny] For 7, maybe we could make the way for host/PEER/network to > > communicate their policies. Besides, if the policies of MIF node can > > not be followed by the peer node, in this sense, we need a way to > > communicate about the policies among host/peer/network. > > > > "communicate their policies among host/peer/network" seems to imply mor= e > > message intensive transfer of state from MS. > > Privacy concerns are also legitimate if network needs information from = MS > > to support MIF. > > Are you saying that sending information from MS to network is a kind of > > disclose privacy concern? can you help to elaborate more on that? > > > > "policy conflict when >1 operator/network" can not optimize for device > > specific policies, there are trade-offs between "monetary cost" and > > speed/access/convenience. > > I could fee that it will be hard if there is policy confliction.but we > can > > do sth in some scale. > > for what you said here, convenience and cost can't be achieved > > simultaneously, what do you > > mean about "monetary cost" here? > > > > thanks for your explanation. > > > > -Hui > > > > thanks > > > > > > On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: > > Hi, Kevin, > > > > I tend to agree with you here that the terminal may not need to upstrea= m > > the capability to the network. but do you see any proposal here doing > that? > > > > but sometime, MS made some decision on the interface and route, but wha= t > > happen if network congested, how to handle that? just waiting for the > fall > > back. > > > > For confliction of policy, I guess that it could be categorized by two > > case, > > one operator, then it should be avoided by offline arrangement, > > for two ISPs, FIFO still work there, cause no problem for user's > traffic. > > > > thanks for the discussion. > > > > -Tao > > > > > > On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin > wrote: > > > > 1) MIF for IPv4 or IPv6 or Both? > > > > > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > > need to do the harmonization with other protocols? > > 3) There is the case that one interface is connected, but the route to > > internet is not available (Such as WiFi Portal). How does MIF handle > > this case? > > > > > 7) Is there a way for the host and the network to communicate about > > their > > > policies regarding all of the above? > > > > Very interesting topic. > > > > I assume MIF is optional "should" v. "must" w.r.t policies from the > > network (e.g. guidance not directive). > > The MS may have lots of policies which can make an informed decision. > > > > As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. > > This would imply MS pushing characteristics up to the network so the > > network can push device-specific directives down. > > It should not be the case that the device needs to push capabilties > > upstream for the network to provide MIF-based guidance. > > > > Furthermore there may be different networks on each interface > > necessitating conflict resolution protocols, let alone issues that occu= r > > sporadically (e.g. WiFI portal, network roaming policies, access-based > > policy) .... > > > > Can't device based provisioning with (optional) input from network > address > > most of the stated issues? > > > > thanks- > > Kevin > > On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang > wrote: > > Hi, Jari: > > > > Please check my lines: > > > > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko > wrote: > > > Again, there seems to be two issues. The first issue is having a poli= cy > > that > > > tells an application which addresses to use (and indirectly which > > interface > > > to use). The second issue is that if the policy comes, e.g., via DHCP > on > > a > > > per-interface basis, then we again have to reconcile the different > > policies > > > on a per-node basis. > > [Peny] Agree with you for the two issues. Another point in my mind may > > be a possible issue. When a peer tries to initiate flows with MIF > > node, we need some way to let the peer know the policies and follow > > the policies of MIF node. > > > > > My personal classification of problems in the multiple interface spac= e > > > includes the following: > > > > > > 1) Access selection, i.e., which network(s) to attach to using the > > physical > > > interface(s) that the host has. Already covered in RFC 5113. > > > > > > 2) Split DNS: If a host is attached to a number of different > interfaces, > > how > > > does it resolve a FQDN if more than one interface has provided a DNS > > server > > > address? > > > > > > 3) Configuration reconciliation: how do we merge and use DHCP and oth= er > > > configuration information in a node, when the information is received > on > > a > > > per-interface basis? > > > > > > 4) Routing: If a host is attached to a number of different interfaces= , > > where > > > does a particular IP packet go? > > > > > > 5) Address selection: If a host is attached to a number of different > > > interfaces, which addresses should be used for a particular applicati= on > > > flow? > > > > > > 6) Tunnel multihoming: If a host is attached to a number of different > > > interfaces and runs some kind of a tunneling or mobility back to a ho= me > > > agent, which interface and addresses should be used for a particular > > packet? > > > Already covered in existing MEXT WG work items. > > [Peny] Agree with you from 1 to 6. > > > > > 7) Is there a way for the host and the network to communicate about > > their > > > policies regarding all of the above? > > [Peny] For 7, maybe we could make the way for host/PEER/network to > > communicate their policies. Besides, if the policies of MIF node can > > not be followed by the peer node, in this sense, we need a way to > > communicate about the policies among host/peer/network. > > > > > My understanding is that the proposed BOF would be looking at problem= s > 2, > > 3, > > > 4, 5, and 7. The others are covered elsewhere. > > [Peny] Some other points I have been thinking of: > > 1) MIF for IPv4 or IPv6 or Both? > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > > need to do the harmonization with other protocols? > > 3) There is the case that one interface is connected, but the route to > > internet is not available (Such as WiFi Portal). How does MIF handle > > this case? > > > > BRG > > Peny > > > > > > > Jari > > > > > > _______________________________________________ > > > mif mailing list > > > mif@ietf.org > > > https://www.ietf.org/mailman/listinfo/mif > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > --000e0cd2e0827d6d450461793038 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick,
 
You made the two points Kevin raised more clear from the ISP'= s point of view.
I couldn't agree with you any more on it. As you said here, those = are not in the scope of current MIF's proposal. for network discovery a= nd selection, RFC 5113 already did a clear analysis on it which we could re= fer on it.
 
For yoru question about what mif's scope at the moment, Jari alrea= dy made the comments on
http://www.ietf.org/mail-archive/web/mif/current/msg00050.html
As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we should narr= ow down our scope based on current PS drafts:

Thanks again.
Best regards,
 
-Hui
 
2009/1/27 <pierrick.seite@orange-ftgroup.com&= gt;
Hi Kevin,


As you stat= ed, the user may prefer, depending on the application, access with lowest c= ost even if loosing QoS. I definitely agree but it's just an example an= d there are plenty of others criteria that may come into play.

I also agree with your first statement. Some actors may want for inform= ation/policy to not be disclosed. In addition to your example, an operator = may not want to disclose its selection policies or network load information= (assuming load is part of the selection criteria).

Anyway, if these considerations are very interesting and fundamentals, = I'm not sure they are in the scope of MIF and IETF. But, maybe I'm = missing something; are you proposing to work on access selection problem?
Actually, now I'm confused about the scope of MIF. Hui, can you cla= rify MIF's scope? Do you have hints for a charter? What about Jari'= s proposal?

Regards,
Pierrick

>
> _______________= _________________________
> De : mif-bounces@ietf.org [mailto:= mif-bounces@ietf.org] De la part de
> Kevin Chin
> En= voy=E9 : mardi 27 janvier 2009 01:13
> =C0 : Hui Deng
> Cc : mif
> Objet : Re: [mif] dra= ft-blanchet
>
> 1) "Are you saying that sending information= from MS to network is a kind
> of disclose privacy concern? can you = help to elaborate more on that?"
>
> My assumption was the= MS would pass on NAI, ISIM, or other mechanism which
> can be used as index into database. This same information can be used = to
> track presence and location. Not a concern for your current Mobi= le
> Operator but when there are 2 or more parties involved, it shoul= d not
> assume network information can be freely shared across organizations. = Some
> users may not want certain hosts to be accessed over a certain= network --
> e.g. sports scores during working hours...
>
> 2) "I could fee that it will be hard if there is policy conflicti= on.but we
> can do sth in some scale.
> for what you said = here, convenience and cost can't be achieved
> simultaneously, wh= at do you
> mean about "monetary cost" here?"
>
> Assum= e I have WLAN and Cellular data interfaces. Further assume WLAN is
> = free and where cellular data is not.
> A user may want to use WLAN ev= en though non-optimal routing. There are
> also counter-examples of cost v. convenience.
> The best path is= not always fastest or shortest path -- monetary cost may
> be a fact= or.
>
> thanks
> On Mon, Jan 26, 2009 at 7:33 AM, Hui Den= g <denghui02@gmail.com> wr= ote:
> Hi, Kevin,
>
> I feel that you give two good advice here,<= br>> Please allow me more clarification inline below:
>
> 20= 09/1/24 Kevin Chin kchin.xor@gmail.c= om
> > 7) Is there a way for the host and the network to communicate abo= ut
> their
> > policies regarding all of the above?
> = [Peny] For 7, maybe we could make the way for host/PEER/network to
> = communicate their policies. Besides, if the policies of MIF node can
> not be followed by the peer node, in this sense, we need a way to
&= gt; communicate about the policies among host/peer/network.
>
>= "communicate their policies among host/peer/network" seems to im= ply more
> message intensive transfer of state from MS.
> Privacy concerns = are also legitimate if network needs information from MS
> to support= MIF.
> Are you saying that sending information from MS to network is= a kind of
> disclose privacy concern? can you help to elaborate more on that?
&= gt;
> "policy conflict when >1 operator/network" can not= optimize for device
> specific policies, there are trade-offs betwee= n "monetary cost" and
> speed/access/convenience.
> I could fee that it will be hard if = there is policy confliction.but we can
> do sth in some scale.
>= ; for what you said here, convenience and cost can't be achieved > simultaneously, what do you
> mean about "monetary cost&quo= t; here?
>
> thanks for your explanation.
>
> -Hui<= br>>
> thanks
>
>
> On Thu, Jan 22, 2009 at 11:1= 6 PM, Tao Sun <hisuntao@gmail.com<= /a>> wrote:
> Hi, Kevin,
>
> I tend to agree with you here that the= terminal may not need to upstream
> the capability to the netwo= rk. but do you see any proposal here doing that?
>
> but someti= me, MS made some decision on the interface and route, but what
> happen if network congested, how to handle that? just waiting for the = fall
> back.
>
> For confliction of policy, I guess that = it could be categorized by two
> case,
> one operator, then it = should be avoided by offline arrangement,
> for two ISPs,  FIFO still work there, cause no problem for user&#= 39;s traffic.
>
> thanks for the discussion.
>
> -T= ao
>
>
> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <= ;kchin.xor@gmail.com> wrote:<= br> >
> 1) MIF for IPv4 or IPv6 or Both?
>
>
> 2) &n= bsp;Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we
> = need to do the harmonization with other protocols?
> 3) There is the = case that one interface is connected, but the route to
> internet is not available (Such as WiFi Portal).  How does MIF ha= ndle
> this case?
>
> > 7) Is there a way for the host= and the network to communicate about
> their
> > policies r= egarding all of the above?
>
> Very interesting topic.
>
> I assume MIF is option= al "should" v. "must" w.r.t policies from the
> n= etwork (e.g. guidance not directive).
> The MS may have lots of polic= ies which can make an informed decision.
>
> As such IPv6, PMIP, DSMIP should not be considered in policies= for MIF.
> This would imply MS pushing characteristics up to the net= work so the
> network can push device-specific directives down.
> It should not be the case that the device needs to push capa= bilties
> upstream for the network to provide MIF-based guidance.
= >
> Furthermore there may be different networks on each interface<= br>> necessitating conflict resolution protocols, let alone issues that = occur
> sporadically (e.g. WiFI portal, network roaming policies, access-based=
> policy) ....
>
> Can't device based provisioning w= ith (optional) input from network address
> most of the stated issues= ?
>
> thanks-
> Kevin
> On Wed, Jan 21, 2009 at 6:06 PM,= Peny Yang <peng.yang.chn@gma= il.com> wrote:
> Hi, Jari:
>
> Please check my lin= es:
>
> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> > = Again, there seems to be two issues. The first issue is having a policy
> that
> > tells an application which addresses to use (and ind= irectly which
> interface
> > to use). The second issue is t= hat if the policy comes, e.g., via DHCP on
> a
> > per-inter= face basis, then we again have to reconcile the different
> policies
> > on a per-node basis.
> [Peny] Agree with y= ou for the two issues. Another point in my mind may
> be a possible i= ssue. When a peer tries to initiate flows with MIF
> node, we need so= me way to let the peer know the policies and follow
> the policies of MIF node.
>
> > My personal classificat= ion of problems in the multiple interface space
> > includes the f= ollowing:
> >
> > 1) Access selection, i.e., which networ= k(s) to attach to using the
> physical
> > interface(s) that the host has. Already covered = in RFC 5113.
> >
> > 2) Split DNS: If a host is attached = to a number of different interfaces,
> how
> > does it resol= ve a FQDN if more than one interface has provided a DNS
> server
> > address?
> >
> > 3) Configuratio= n reconciliation: how do we merge and use DHCP and other
> > confi= guration information in a node, when the information is received on
> a
> > per-interface basis?
> >
> > 4) Routi= ng: If a host is attached to a number of different interfaces,
> wher= e
> > does a particular IP packet go?
> >
> > 5)= Address selection: If a host is attached to a number of different
> > interfaces, which addresses should be used for a particular appli= cation
> > flow?
> >
> > 6) Tunnel multihoming: = If a host is attached to a number of different
> > interfaces and = runs some kind of a tunneling or mobility back to a home
> > agent, which interface and addresses should be used for a particu= lar
> packet?
> > Already covered in existing MEXT WG work i= tems.
> [Peny] Agree with you from 1 to 6.
>
> > 7) Is= there a way for the host and the network to communicate about
> their
> > policies regarding all of the above?
> [Peny]= For 7, maybe we could make the way for host/PEER/network to
> commun= icate their policies. Besides, if the policies of MIF node can
> not = be followed by the peer node, in this sense, we need a way to
> communicate about the policies among host/peer/network.
>
>= ; > My understanding is that the proposed BOF would be looking at proble= ms 2,
> 3,
> > 4, 5, and 7. The others are covered elsewhere= .
> [Peny] Some other points I have been thinking of:
> 1) MIF for I= Pv4 or IPv6 or Both?
> 2)  Will MIF need to co-work with (P)MIP,= DSMIP, etc? If so, do we
> need to do the harmonization with other p= rotocols?
> 3) There is the case that one interface is connected, but the route to=
> internet is not available (Such as WiFi Portal).  How does MI= F handle
> this case?
>
> BRG
> Peny
>
>= ;
> > Jari
> >
> > __________________________________= _____________
> > mif mailing list
> > mif@ietf.org
> > https://www.ietf.org/mailman/listi= nfo/mif
> >
> _______________________________________________
> m= if mailing list
> mif@ietf.org> https://www.ietf.org/mailman/listinfo/mif
>
>
> _______________________________________________
>= ; mif mailing list
> mif@ietf.org=
> https://www.ietf.org/mailman/listinfo/mif
>
>
>
> ______________________________________________= _
> mif mailing list
> mif@ietf= .org
> https://www.ietf.org/mailman/listinfo/mif
>


--000e0cd2e0827d6d450461793038-- --===============1446901414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1446901414==-- From mif-bounces@ietf.org Tue Jan 27 08:26:23 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777483A6922; Tue, 27 Jan 2009 08:26:23 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1373A68D2 for ; Tue, 27 Jan 2009 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbDIlFXK3FAT for ; Tue, 27 Jan 2009 08:26:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 840EC3A68CC for ; Tue, 27 Jan 2009 08:26:18 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 17:25:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 17:23:08 +0100 Message-ID: In-Reply-To: <1d38a3350901270817y120e218ay42a34b9e4bfb4d31@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] draft-blanchet Thread-Index: AcmAmuIOEEMtE0muQLiuN5+jy8TdtwAAJ+Hw References: <200901181405165005812@gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> <1d38a3350901260733t2649a9bex60fb7cb3e4c053f6@mail.gmail.com> <1d38a3350901270817y120e218ay42a34b9e4bfb4d31@mail.gmail.com> From: To: X-OriginalArrivalTime: 27 Jan 2009 16:25:57.0218 (UTC) FILETIME=[EED7DC20:01C9809B] Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1118577942==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1118577942== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9809B.EE7AAD8A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9809B.EE7AAD8A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for clarification. =20 ________________________________ De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : mardi 27 janvier 2009 17:17 =C0 : SEITE Pierrick RD-RESA-REN Cc : kchin.xor@gmail.com; mif@ietf.org Objet : Re: [mif] draft-blanchet =20 Hi, Pierrick, =20 You made the two points Kevin raised more clear from the ISP's point of = view. I couldn't agree with you any more on it. As you said here, those are = not in the scope of current MIF's proposal. for network discovery and = selection, RFC 5113 already did a clear analysis on it which we could = refer on it. =20 For yoru question about what mif's scope at the moment, Jari already = made the comments on http://www.ietf.org/mail-archive/web/mif/current/msg00050.html As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we should narrow = down our scope based on current PS drafts: http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt Thanks again. Best regards, =20 -Hui =20 2009/1/27 Hi Kevin, As you stated, the user may prefer, depending on the application, access = with lowest cost even if loosing QoS. I definitely agree but it's just = an example and there are plenty of others criteria that may come into = play. I also agree with your first statement. Some actors may want for = information/policy to not be disclosed. In addition to your example, an = operator may not want to disclose its selection policies or network load = information (assuming load is part of the selection criteria). Anyway, if these considerations are very interesting and fundamentals, = I'm not sure they are in the scope of MIF and IETF. But, maybe I'm = missing something; are you proposing to work on access selection = problem? Actually, now I'm confused about the scope of MIF. Hui, can you clarify = MIF's scope? Do you have hints for a charter? What about Jari's = proposal? Regards, Pierrick > > ________________________________________ > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Kevin Chin > Envoy=E9 : mardi 27 janvier 2009 01:13 > =C0 : Hui Deng > Cc : mif > Objet : Re: [mif] draft-blanchet > > 1) "Are you saying that sending information from MS to network is a = kind > of disclose privacy concern? can you help to elaborate more on that?" > > My assumption was the MS would pass on NAI, ISIM, or other mechanism = which > can be used as index into database. This same information can be used = to > track presence and location. Not a concern for your current Mobile > Operator but when there are 2 or more parties involved, it should not > assume network information can be freely shared across organizations. = Some > users may not want certain hosts to be accessed over a certain network = -- > e.g. sports scores during working hours... > > 2) "I could fee that it will be hard if there is policy = confliction.but we > can do sth in some scale. > for what you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here?" > > Assume I have WLAN and Cellular data interfaces. Further assume WLAN = is > free and where cellular data is not. > A user may want to use WLAN even though non-optimal routing. There are > also counter-examples of cost v. convenience. > The best path is not always fastest or shortest path -- monetary cost = may > be a factor. > > thanks > On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng wrote: > Hi, Kevin, > > I feel that you give two good advice here, > Please allow me more clarification inline below: > > 2009/1/24 Kevin Chin kchin.xor@gmail.com > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > > "communicate their policies among host/peer/network" seems to imply = more > message intensive transfer of state from MS. > Privacy concerns are also legitimate if network needs information from = MS > to support MIF. > Are you saying that sending information from MS to network is a kind = of > disclose privacy concern? can you help to elaborate more on that? > > "policy conflict when >1 operator/network" can not optimize for device > specific policies, there are trade-offs between "monetary cost" and > speed/access/convenience. > I could fee that it will be hard if there is policy confliction.but we = can > do sth in some scale. > for what you said here, convenience and cost can't be achieved > simultaneously, what do you > mean about "monetary cost" here? > > thanks for your explanation. > > -Hui > > thanks > > > On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: > Hi, Kevin, > > I tend to agree with you here that the terminal may not need to = upstream > the capability to the network. but do you see any proposal here doing = that? > > but sometime, MS made some decision on the interface and route, but = what > happen if network congested, how to handle that? just waiting for the = fall > back. > > For confliction of policy, I guess that it could be categorized by two > case, > one operator, then it should be avoided by offline arrangement, > for two ISPs, FIFO still work there, cause no problem for user's = traffic. > > thanks for the discussion. > > -Tao > > > On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin = wrote: > > 1) MIF for IPv4 or IPv6 or Both? > > > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? > > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > > Very interesting topic. > > I assume MIF is optional "should" v. "must" w.r.t policies from the > network (e.g. guidance not directive). > The MS may have lots of policies which can make an informed decision. > > As such IPv6, PMIP, DSMIP should not be considered in policies for = MIF. > This would imply MS pushing characteristics up to the network so the > network can push device-specific directives down. > It should not be the case that the device needs to push capabilties > upstream for the network to provide MIF-based guidance. > > Furthermore there may be different networks on each interface > necessitating conflict resolution protocols, let alone issues that = occur > sporadically (e.g. WiFI portal, network roaming policies, access-based > policy) .... > > Can't device based provisioning with (optional) input from network = address > most of the stated issues? > > thanks- > Kevin > On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang = wrote: > Hi, Jari: > > Please check my lines: > > On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko = wrote: > > Again, there seems to be two issues. The first issue is having a = policy > that > > tells an application which addresses to use (and indirectly which > interface > > to use). The second issue is that if the policy comes, e.g., via = DHCP on > a > > per-interface basis, then we again have to reconcile the different > policies > > on a per-node basis. > [Peny] Agree with you for the two issues. Another point in my mind may > be a possible issue. When a peer tries to initiate flows with MIF > node, we need some way to let the peer know the policies and follow > the policies of MIF node. > > > My personal classification of problems in the multiple interface = space > > includes the following: > > > > 1) Access selection, i.e., which network(s) to attach to using the > physical > > interface(s) that the host has. Already covered in RFC 5113. > > > > 2) Split DNS: If a host is attached to a number of different = interfaces, > how > > does it resolve a FQDN if more than one interface has provided a DNS > server > > address? > > > > 3) Configuration reconciliation: how do we merge and use DHCP and = other > > configuration information in a node, when the information is = received on > a > > per-interface basis? > > > > 4) Routing: If a host is attached to a number of different = interfaces, > where > > does a particular IP packet go? > > > > 5) Address selection: If a host is attached to a number of different > > interfaces, which addresses should be used for a particular = application > > flow? > > > > 6) Tunnel multihoming: If a host is attached to a number of = different > > interfaces and runs some kind of a tunneling or mobility back to a = home > > agent, which interface and addresses should be used for a particular > packet? > > Already covered in existing MEXT WG work items. > [Peny] Agree with you from 1 to 6. > > > 7) Is there a way for the host and the network to communicate about > their > > policies regarding all of the above? > [Peny] For 7, maybe we could make the way for host/PEER/network to > communicate their policies. Besides, if the policies of MIF node can > not be followed by the peer node, in this sense, we need a way to > communicate about the policies among host/peer/network. > > > My understanding is that the proposed BOF would be looking at = problems 2, > 3, > > 4, 5, and 7. The others are covered elsewhere. > [Peny] Some other points I have been thinking of: > 1) MIF for IPv4 or IPv6 or Both? > 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we > need to do the harmonization with other protocols? > 3) There is the case that one interface is connected, but the route to > internet is not available (Such as WiFi Portal). How does MIF handle > this case? > > BRG > Peny > > > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > =20 ------_=_NextPart_001_01C9809B.EE7AAD8A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for = clarification.

 

De : Hui = Deng [mailto:denghui02@gmail.com]
Envoy=E9 : mardi 27 = janvier 2009 17:17
=C0 : SEITE Pierrick RD-RESA-REN
Cc : = kchin.xor@gmail.com; mif@ietf.org
Objet : Re: [mif] draft-blanchet

 

Hi, Pierrick,

 

You made the two points Kevin raised more clear from the = ISP's point of view.

I couldn't agree with you any more on it. As you said here, = those are not in the scope of current MIF's proposal. for network discovery and selection, RFC 5113 already did a clear analysis on it which we could = refer on it.

 

For yoru question about what mif's scope at the moment, Jari = already made the comments on

As Joel, Kevin, Tao, Kai, Yungui et al. suggested here, we = should narrow down our scope based on current PS = drafts:


Thanks again.

Best regards,

 

-Hui

 

2009/1/27 <pierrick.seite@orange-f= tgroup.com>

Hi Kevin,


As you stated, the user may prefer, depending on the application, access = with lowest cost even if loosing QoS. I definitely agree but it's just an = example and there are plenty of others criteria that may come into play.

I also agree with your first statement. Some actors may want for information/policy to not be disclosed. In addition to your example, an operator may not want to disclose its selection policies or network load information (assuming load is part of the selection criteria).

Anyway, if these considerations are very interesting and fundamentals, = I'm not sure they are in the scope of MIF and IETF. But, maybe I'm missing = something; are you proposing to work on access selection problem?

Actually, now I'm confused about the scope of MIF. Hui, can you clarify = MIF's scope? Do you have hints for a charter? What about Jari's proposal?

Regards,
Pierrick

>
> = ________________________________________

> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de

> Kevin Chin
> Envoy=E9 : mardi 27 janvier 2009 01:13
> =C0 : Hui Deng

> Cc : mif
> Objet : Re: [mif] draft-blanchet
>

> 1) = "Are you saying that sending information from MS to network is a kind
> of disclose privacy concern? can you help to elaborate more on = that?"
>
> My assumption was the MS would pass on NAI, ISIM, or other = mechanism which
> can be used as index into database. This same information can be = used to
> track presence and location. Not a concern for your current = Mobile
> Operator but when there are 2 or more parties involved, it should = not
> assume network information can be freely shared across = organizations. Some
> users may not want certain hosts to be accessed over a certain = network --
> e.g. sports scores during working hours...
>
> 2) "I could fee that it will be hard if there is policy confliction.but we
> can do sth in some scale.
> for what you said here, convenience and cost can't be = achieved
> simultaneously, what do you
> mean about "monetary cost" here?"
>
> Assume I have WLAN and Cellular data interfaces. Further assume = WLAN is
> free and where cellular data is not.
> A user may want to use WLAN even though non-optimal routing. There = are
> also counter-examples of cost v. convenience.
> The best path is not always fastest or shortest path -- monetary = cost may
> be a factor.
>
> thanks
> On Mon, Jan 26, 2009 at 7:33 AM, Hui Deng <denghui02@gmail.com> = wrote:
> Hi, Kevin,
>
> I feel that you give two good advice here,
> Please allow me more clarification inline below:
>
> 2009/1/24 Kevin Chin kchin.xor@gmail.com
> > 7) Is there a way for the host and the network to communicate = about
> their
> > policies regarding all of the above?
> [Peny] For 7, maybe we could make the way for host/PEER/network = to
> communicate their policies. Besides, if the policies of MIF node = can
> not be followed by the peer node, in this sense, we need a way = to
> communicate about the policies among host/peer/network.
>
> "communicate their policies among host/peer/network" = seems to imply more
> message intensive transfer of state from MS.
> Privacy concerns are also legitimate if network needs information = from MS
> to support MIF.
> Are you saying that sending information from MS to network is a = kind of
> disclose privacy concern? can you help to elaborate more on = that?
>
> "policy conflict when >1 operator/network" can not = optimize for device
> specific policies, there are trade-offs between "monetary = cost" and
> speed/access/convenience.
> I could fee that it will be hard if there is policy confliction.but = we can
> do sth in some scale.
> for what you said here, convenience and cost can't be = achieved
> simultaneously, what do you
> mean about "monetary cost" here?
>
> thanks for your explanation.
>
> -Hui
>
> thanks
>
>
> On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun <hisuntao@gmail.com> wrote:
> Hi, Kevin,
>
> I tend to agree with you here that the terminal may not need to upstream
> the capability to the network. but do you see any proposal here = doing that?
>
> but sometime, MS made some decision on the interface and route, but = what
> happen if network congested, how to handle that? just waiting for = the fall
> back.
>
> For confliction of policy, I guess that it could be categorized by = two
> case,
> one operator, then it should be avoided by offline arrangement,
> for two ISPs,  FIFO still work there, cause no problem for = user's traffic.
>
> thanks for the discussion.
>
> -Tao
>
>
> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin <kchin.xor@gmail.com> = wrote:
>
> 1) MIF for IPv4 or IPv6 or Both?
>
>
> 2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, = do we
> need to do the harmonization with other protocols?
> 3) There is the case that one interface is connected, but the route = to
> internet is not available (Such as WiFi Portal).  How does MIF = handle
> this case?
>
> > 7) Is there a way for the host and the network to communicate = about
> their
> > policies regarding all of the above?
>
> Very interesting topic.
>
> I assume MIF is optional "should" v. "must" = w.r.t policies from the
> network (e.g. guidance not directive).
> The MS may have lots of policies which can make an informed = decision.
>
> As such IPv6, PMIP, DSMIP should not be considered in policies for = MIF.
> This would imply MS pushing characteristics up to the network so = the
> network can push device-specific directives down.
> It should not be the case that the device needs to push capabilties
> upstream for the network to provide MIF-based guidance.
>
> Furthermore there may be different networks on each interface
> necessitating conflict resolution protocols, let alone issues that = occur
> sporadically (e.g. WiFI portal, network roaming policies, = access-based
> policy) ....
>
> Can't device based provisioning with (optional) input from network = address
> most of the stated issues?
>
> thanks-
> Kevin
> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang <peng.yang.chn@gmail.com> = wrote:
> Hi, Jari:
>
> Please check my lines:
>
> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko <jari.arkko@piuha.net> = wrote:
> > Again, there seems to be two issues. The first issue is having = a policy
> that
> > tells an application which addresses to use (and indirectly = which
> interface
> > to use). The second issue is that if the policy comes, e.g., = via DHCP on
> a
> > per-interface basis, then we again have to reconcile the = different
> policies
> > on a per-node basis.
> [Peny] Agree with you for the two issues. Another point in my mind = may
> be a possible issue. When a peer tries to initiate flows with = MIF
> node, we need some way to let the peer know the policies and = follow
> the policies of MIF node.
>
> > My personal classification of problems in the multiple = interface space
> > includes the following:
> >
> > 1) Access selection, i.e., which network(s) to attach to using = the
> physical
> > interface(s) that the host has. Already covered in RFC = 5113.
> >
> > 2) Split DNS: If a host is attached to a number of different interfaces,
> how
> > does it resolve a FQDN if more than one interface has provided = a DNS
> server
> > address?
> >
> > 3) Configuration reconciliation: how do we merge and use DHCP = and other
> > configuration information in a node, when the information is = received on
> a
> > per-interface basis?
> >
> > 4) Routing: If a host is attached to a number of different interfaces,
> where
> > does a particular IP packet go?
> >
> > 5) Address selection: If a host is attached to a number of = different
> > interfaces, which addresses should be used for a particular = application
> > flow?
> >
> > 6) Tunnel multihoming: If a host is attached to a number of = different
> > interfaces and runs some kind of a tunneling or mobility back = to a home
> > agent, which interface and addresses should be used for a = particular
> packet?
> > Already covered in existing MEXT WG work items.
> [Peny] Agree with you from 1 to 6.
>
> > 7) Is there a way for the host and the network to communicate = about
> their
> > policies regarding all of the above?
> [Peny] For 7, maybe we could make the way for host/PEER/network = to
> communicate their policies. Besides, if the policies of MIF node = can
> not be followed by the peer node, in this sense, we need a way = to
> communicate about the policies among host/peer/network.
>
> > My understanding is that the proposed BOF would be looking at problems 2,
> 3,
> > 4, 5, and 7. The others are covered elsewhere.
> [Peny] Some other points I have been thinking of:
> 1) MIF for IPv4 or IPv6 or Both?
> 2)  Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, = do we
> need to do the harmonization with other protocols?
> 3) There is the case that one interface is connected, but the route = to
> internet is not available (Such as WiFi Portal).  How does MIF = handle
> this case?
>
> BRG
> Peny
>
>
> > Jari
> >
> > _______________________________________________
> > mif mailing list
> > mif@ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
> >
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>

 

------_=_NextPart_001_01C9809B.EE7AAD8A-- --===============1118577942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1118577942==-- From mif-bounces@ietf.org Tue Jan 27 19:22:43 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE743A6B4E; Tue, 27 Jan 2009 19:22:43 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561743A6B4E for ; Tue, 27 Jan 2009 19:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIwjvGcJODWo for ; Tue, 27 Jan 2009 19:22:42 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 965AD3A6B49 for ; Tue, 27 Jan 2009 19:22:42 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so6656786rvf.49 for ; Tue, 27 Jan 2009 19:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cmVIEs2+bmLUBeZMA9GQoII49+RC8in9dRHCQjZ+1M0=; b=UgXBrCEif9SqY3BF3kXQNdMVscvd8Z94RjGYD7KdEY648SmdgXnL61va/YbK6qk/3L 7fJcnB819+UKPrQQXHZL11wNBJPU2RmfCQZtCILm3OT7wGiirzEc1ChzeRPIk49515ti 3pqO3l87YV1wwPtJDaWJKxTjmpnYG4drRAmEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dPachI0Z2UfKsZAjQbr0rHwRVPI9IJgD7l3i01nulJWV1Y1cL0QNv7gJ+6LFawnAxP nrFiqxliSjTNk6fUcjxBXRX/GXa9jPh10rU2Ti3h8XX0FIIcNFQOkh9hCN8UVMSOljeU E2L2xC+S3rDf+f7Kbtgtx+ICq8Jrag1eetMFc= MIME-Version: 1.0 Received: by 10.142.107.5 with SMTP id f5mr1201540wfc.130.1233112944241; Tue, 27 Jan 2009 19:22:24 -0800 (PST) Date: Wed, 28 Jan 2009 11:22:24 +0800 Message-ID: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> From: Kai Ju To: mif Subject: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0633045680==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0633045680== Content-Type: multipart/alternative; boundary=001636e90a90026abc0461827b49 --001636e90a90026abc0461827b49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, All Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese Spring Festival, and good luck for whole new year. I got one issue which maybe would raise a fundamental question on MIF, and it has confused me for days. If host has WLan connection, and user wanna start one application on it, because Wlan provided by ISP is free. But the policy which host has got from network forbid it on Wlan. When they're conflict between the policy and user's willing, how should MIF do? Ignor user's willing, choose another interface according the policy? Or change the policy, do what the user wanna do? So, the question is policy and user's willing, who get the higher priority? BRG Kai --001636e90a90026abc0461827b49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, All
 
Firstly, allow me wish everyone in MIF Discussion a magnificent Chines= e Spring Festival, and good luck for whole new year.
 
I got one issue which maybe would raise a fundamental question on MIF,= and it has confused me for days.
 
If host has WLan connection, and user wanna start one application= on it, because Wlan provided by ISP is free. But the policy which host has= got from network forbid it on Wlan. When they're conflict between= the policy and user's willing, how should MIF do? Ignor user's wil= ling, choose another interface according the policy? Or change the
policy, do what the user wanna do?
 
So, the question is policy and user's willing, who get the higher = priority?
 
BRG
 
Kai
--001636e90a90026abc0461827b49-- --===============0633045680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0633045680==-- From mif-bounces@ietf.org Tue Jan 27 23:13:26 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C98028C1E1; Tue, 27 Jan 2009 23:13:26 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B30B3A677D for ; Tue, 27 Jan 2009 23:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.995 X-Spam-Level: ** X-Spam-Status: No, score=2.995 tagged_above=-999 required=5 tests=[AWL=-2.035, BAYES_20=-0.74, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+pofuaLNQmL for ; Tue, 27 Jan 2009 23:13:23 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 0544D3A6BD3 for ; Tue, 27 Jan 2009 23:13:22 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 28 Jan 2009 16:13:04 +0900 X-ReadCheckName: mif%40ietf.org X-ReadCheckMessageID: <690babcf-ce71-4949-a2af-e87125372036@etri.re.kr> From: "Hong Yong-Geun" To: , Date: Wed, 28 Jan 2009 16:13:04 +0900 Priority: normal Comment: ??, u-??, thread-index: AcmBF9xvrP3fCPyJS+i9Y9I2UeUbzQAAAA5B Message-ID: <932101c98117$dcb01d10$8310fe81@etri.info> X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple interfaces problems in MEXT and mif X-OriginalArrivalTime: 28 Jan 2009 07:13:04.0557 (UTC) FILETIME=[DCCF3DD0:01C98117] Cc: marcelo@it.uc3m.es, julien.laganier.IETF@googlemail.com Subject: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0826656559==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0826656559== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98114.CAF6F100" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98114.CAF6F100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------_=_NextPart_001_01C98114.CAF6F100 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4NCjxESVY+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1l bi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SGksIGFsbCBpbjwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y Pk1FWFQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPiBhbmQgbWlmLjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGln bj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9 ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkluIElFVEYgbWlmPC9GT05U PjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gKE11bHRpcGxlIEludGVyZmFjZSk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm1haWxpbmc8L0ZPTlQ+PC9T UEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwv Rk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmxpc3Q8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiAoPC9G T05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PV9ibGFuaz48U1BBTiBsYW5nPWVu LXVzPjxVPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYTwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBjb2xvcj0jMDAwMGZmIHNpemU9Mj5uL2xpc3RpbmZvL21pZjwvRk9OVD48L1U+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj4pLCA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxp Z249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj53PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5lPC9GT05UPiA8 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bm93PC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+ZDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+aXNjdXNzIHRoZSBob3N0IHdoaWNoPC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg 65SVIiBzaXplPTI+d291bGQgbGlrZSB0byB1c2UgbXVsdGlwbGUgaW50ZXJmYWNlczwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXplPTI+LjwvRk9OVD48L1NQQU4+PC9QPg0K PFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR 7J2AIOqzoOuUlSIgc2l6ZT0yPkkgdW5kZXJzdGFuZCB0aGF0PC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+TUVYVDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ IFdHIGlzIGFsc28gcmVsYXRlZCB0bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoZSB1c2Ugb2Y8L0ZPTlQ+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5tdWx0aXBs ZSBpbnRlcmZhY2VzPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj4gb2YgYSBob3N0PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPjxCUj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+dXNpbmcgTW9iaWxlIElQ djYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU88L0ZPTlQ+IDxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj5CYXNpYyBTdXBwb3J0IGFuZCB0aGVpciB2YXJpYW50czwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0 aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFOPjxBIHRh cmdldD1fYmxhbmsgbmFtZT0iIj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5NRVhUPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gV0cgaXMgZm9jdWluZyBvbiBtb25hbWk2PC9GT05UPjwvU1BBTj48L0E+PFNQQU4gbGFuZz1l bi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+IHJlbGF0ZWQgdG9waWM8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPiAobXVsdGlwbGUgQ29BLCBNdWx0aXBsZSBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLDwv Rk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+KTwvRk9OVD48L1NQQU4+PFNQ QU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BB TiBsYW5nPWtvLWtyPjxCUj48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFu Zz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YW5kIGV4dGVkbmluZyBN b2JpbGUgSVB2NiBhbmQgTkVNTzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+ PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmZvciB0 aGVzZSw8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmJ1dDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bWlmIGlzPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+bm90IHJlbGF0ZWQgdG8gdGhpcyBkaXJlY3Q8L0ZPTlQ+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlvbi48L0ZPTlQ+PC9TUEFOPjxTUEFO IGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEJSPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5JbiBtaWY8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiwgc291cmNlIGFk ZHJlc3Mgc2VsZWN0aW9uLDwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnI8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm91dGluZzwvRk9OVD4g PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFuZCBETlMgY29udHJvbCBwcm90b2Nv bDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+YXJlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BB Tj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5jb25zaWRlcmF0aW9uIGl0ZW1zPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxCUj48L1NQQU4+ PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+ZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMgb2YgYSBob3N0LiA8 L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWtv LWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPg0K PFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5Gb3I8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5taWY8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPuKAmTwvRk9OVD48L1NQQU4+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+cyBzY29wZSwgSmFyaSBBcmtrbzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPm1hZGU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zb21lIGNvbW1lbnRzIGFu ZCBjbGFzc2k8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmZpY2F0aW9uIG9mIHByb2Js ZW1zLiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBs YW5nPWVuLXVzPjwvU1BBTj48QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbCIgdGFyZ2V0PV9ibGFuaz48U1BBTiBsYW5n PWVuLXVzPjxVPjwvVT48L1NQQU4+PFU+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBjb2xvcj0jMDAwMGZmIHNpemU9Mj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbDwvRk9OVD48L1NQQU4+PC9VPjxT UEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBs YW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFu Zz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+QW1vbmcgdGhlc2UgY2xhc3NpZmljYXRpb24gd2hpY2ggaW5jbHVkZXM8L0ZPTlQ+ IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hY2Nlc3Mgc2VsZWN0aW9uLCBzcGxp dCBETlMsPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtv LWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+Y29uZmlndXJhdGlvbiByZWNv bmNpbGlhdGlvbiw8QlI+PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5y b3V0aW5nLCBhZGRyZXNzIHNlbGVjdGlvbiwgdHVubmVsIG11bHRpaG9taW5nLDwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFuZCB0aGU8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5jb21tdW5pY2F0aW9uIHdheSBiZXR3ZWVuIHRoZSBob3N0IGFuZDxCUj48 L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoZSBuZXR3b3JrIGFib3V0 IHRoZWlyIHBvbGljaWVzIHJlZ2FyZGluZyBhbGwgb2YgdGhlIGFib3ZlPC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj4sPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SmFyaSBz YWlkIHRoYXQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hY2Nlc3Mgc2VsZWN0aW9u IGlzIGFscmVhZHk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+PEJSPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtv LWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5jb3ZlcmQgaW4gUkZDIDUxMTM8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPmFuZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFu Zz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnR1bm5lbCBtdWx0aWhv bWluZzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1r cj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzIGFscmVhZHkgY292ZXJlZCBp bjwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1FWFQgV0cgd29yayBp dGVtcy48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBs YW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiPjwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48L1NQQU4+Jm5ic3A7PC9QPg0KPFAg ZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9 a28ta3I+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVu LXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj5BdCBtb25hbWk2IFdHIGluIDY8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPjR0aDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05U PiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+SUVURiBtZWV0aW5uZywgSSBzdWJt aXR0ZWQgYW5kIHByZXNlbnRlZCB0d28gSW50ZXJuZXQgRHJhZnRzLjwvRk9OVD48L1NQQU4+PC9Q Pg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPi0gQW5hbHlzaXMg b2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+IDwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0 LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxT UEFOIGxhbmc9ZW4tdXM+PFU+PC9VPjwvU1BBTj48VT48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dDwvRk9O VD48L1NQQU4+PC9VPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvQT48U1BBTiBsYW5nPWVuLXVz PjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1 c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGZvciBt dWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUgdXNpbmcgTW9iaWxlIElQdjY8L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFO PjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4t bWlwdjYtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxTUEFOIGxhbmc9ZW4tdXM+PFU+PC9VPjwvU1BB Tj48VT48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRmPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYt bW4tbWlwdjYtMDAudHh0PC9GT05UPjwvU1BBTj48L1U+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+ PC9BPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxhbmc9a28ta3I+PC9TUEFOPjwvUD4N CjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBs YW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5CZWNhdXNlIHRoZXNl IHR3byBkcmFmdHM8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFOIGxh bmc9a28ta3I+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj53PC9GT05UPjwvU1BB Tj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9Iuun keydgCDqs6DrlJUiIHNpemU9Mj5lcmU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9T UEFOPjxTUEFOIGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiBu b3Q8L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5pbiB0aGUgbW9uYW1p NiBXRzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1r cj48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+4oCZPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5zIHNjb3BlIGFuZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnZpcnR1YWwgbmV0PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj53PC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5vcmsgaW50ZXJmYWNlIGRyYWZ0 IHdhczwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxh bmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmk8L0ZPTlQ+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm1wbGVtZW50YXRpb248L0ZPTlQ+IDxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zcGVjaWZpYzwvRk9OVD48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+LCB0aDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBz aXplPTI+ZXJlIHdlcmUgbm90PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YWRvcGVk IGluIG1vbmFtaTYgV0c8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjxTUEFO IGxhbmc9a28ta3I+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPuKAmTwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cyB3b3JrIGl0ZW1zLjwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz48L1NQQU4+PFNQQU4gbGFuZz1rby1rcj4gPEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPlRoZSBpbnRlbnRpb25zIG9mIHR3PC9GT05UPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5vPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5n PWtvLWtyPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4gZHJhZnRzPEJSPjwvRk9O VD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YXJlPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjwvU1BBTj48U1BBTiBsYW5nPWtvLWtyPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+c3VwcG9ydGluZyBtdWx0aXBsZSBpbnRlcmZhY2VzIG9mPC9GT05UPiA8 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5n IE1vYmlsZSBJUHY2L05FTU8uPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjwvU1BBTj48 U1BBTiBsYW5nPWtvLWtyPjwvU1BBTj48L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQ QU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFO IGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkkgdGhpbmsgdGhhdDwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm11 bHRpcGxlIGludGVyZmFjZTwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuU lSIgc2l6ZT0yPnByb2JsZW1zPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5vZiBhIGhvc3Q8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hcmUgcmVsYXRlZCB0byBib3RoPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ TW9iaWxlIElQL05FTU88L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiBzcGVjaWZpYzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzc3VlczwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFu ZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPmdlbmVyYWw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5uZXR3b3JrIGlzc3VlczwvRk9OVD48Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUC9ORU1PPC9GT05U PjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj4gczwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cGVjaWZpYyBpc3N1 ZXM8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5hPC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5yPC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5lPC9GT05UPjxGT05UIGZhY2U9 IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5yZWxhdGVkIHRvPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZXh0ZW5kaW5nIG9mPC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+TW9iaWxlIElQ PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4vTkVNTzwvRk9OVD48L1NQ QU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGFu ZDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPnRoZXNlIGFyZTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YWxyZWFkeTwvRk9OVD4gPEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnN0dWRpZWQgaW4gTUVYVCBXRyBhbmQ8L0ZP TlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPmdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2ggd2VyZSBub3QgcmVsYXRl ZCB0bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+PEZPTlQgZmFjZT0i66eR7J2A IOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+L05FTU88L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5j b3VsZDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGJlIHN0dWRpZWQg aW4gbWlmLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+IEFzPC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXpl PTI+c2FtZSBtYTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+bm5lciw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxG T05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JIHRoaW5rIHRoYXQ8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5teTwv Rk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZHJhZnRzPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YzwvRk9OVD48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+b3VsZCBiZSBkaXNjdXNzZWQ8L0ZPTlQ+PC9TUEFOPjxT UEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5hbmQ8QlI+ PC9GT05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5kZXZlPC9GT05UPjwvU1BB Tj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5sPC9G T05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNp emU9Mj5vcDwvRk9OVD48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ZWQ8L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5pbiBtaWYuPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZh Y2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVz PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5uPC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+dDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+aGUgZmlyc3QgZHJhZnQ8L0ZPTlQ+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPiAoPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5BbmFseXNpcyBkb2N1PC9GT05U PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5tZW50PC9GT05UPjwvU1BBTj48U1BB TiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4pLDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y Pkk8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6Dr lJUiIHNpemU9Mj5jbGFzc2lmaWU8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPmQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5tdWx0aXBsZTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+aW48L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PnRlcmZhY2U8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj5wcm9ibGVtczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPiA8Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+aW50bzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48QlI+ PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPk1vYmlsZSBJUHY2LXNlcGNpZmljIGlz c3Vlcyw8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPkdlbmVyYWwgbmV0d29yazwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmlzc3VlczwvRk9O VD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXplPTI+LDwvRk9OVD48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGFuZCBoZXRlcm9nZW5lb3VzIGVudmlyb25tZW50PC9G T05UPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4gaXNzdWVzPC9GT05UPjxGT05U IGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj4uPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVu LXVzPiA8L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4t dXM+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVz PjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv UD4NCjxQIGRpcj1sdHIgYWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9 IuunkeydgCDqs6DrlJUiIHNpemU9Mj5JbmNsdWRpbmcgSHVpPC9GT05UPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+RGVuZzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+IGluIG1pZjwvRk9OVD48L1NQQU4+PFNQ QU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+LDwvRk9OVD48 L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0y PndpdGg8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDq s6DrlJUiIHNpemU9Mj5yZWdhcmRpbmcgdG88L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+ IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj50aGVzZSBkcmFmdHMsPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+ dGhleSB3YW50IHRvPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+aGVhciBjb21tZW50czwvRk9OVD48L1NQQU4+PFNQQU4gbGFu Zz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmY8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnJvbTwv Rk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPk1FWDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5Hs nYAg6rOg65SVIiBzaXplPTI+VCBXRzwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9O VCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+4oCZPC9GT05UPjwvU1BBTj48U1BBTiBsYW5n PWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5zPC9GT05UPjwvU1BBTj48 U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+cG9pbnQ8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIg c2l6ZT0yPjwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm9mIHZpZXc8 L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgc2l6ZT0yPiw8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEJSPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5i ZWNhdXNlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+aXQgc2U8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmVtczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1l bi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRoYXQ8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9O VD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6 ZT0yPnRoZXNlPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj4gZHI8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQg ZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFmdHMgYXJlIHF1aXRlIHJlbGF0ZWQgdG8gbW9u YW1pNi9NRVhUIFdHLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLr p5HsnYAg6rOg65SVIiBzaXplPTI+IFNvLCBJIGFzayBNRVhUPC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+dG88L0ZPTlQ+PC9T UEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9Mj5y ZXZpZXc8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPiB3aGV0aGVyIHRoZXJlIGFyZTwvRk9OVD48L1NQQU4+PC9QPg0KPFAgZGly PWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqz oOuUlSIgc2l6ZT0yPnM8L0ZPTlQ+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm9t ZTwvRk9OVD4gPEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPm92ZXJsYXA8L0ZPTlQ+ PC9TUEFOPjxTUEFOIGxhbmc9ZW4tdXM+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5iZXR3ZWVuPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9Iuunkeyd gCDqs6DrlJUiIHNpemU9Mj48L0ZPTlQ+IDxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUiIHNpemU9 Mj5NRVhUPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg 6rOg65SVIiBzaXplPTI+d29yazwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBm YWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11 cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBs YW5nPWVuLXVzPiA8Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SVIiBzaXplPTI+YW5kIG15IGRyYWZ0 czwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg65SV IiBzaXplPTI+IG9yIG5vdDwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBzaXpl PTI+LjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48L1NQQU4+PC9QPg0KPFAgZGlyPWx0 ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIg YWxpZ249anVzdGlmeT48U1BBTiBsYW5nPWVuLXVzPjxGT05UIGZhY2U9IuunkeydgCDqs6DrlJUi IHNpemU9Mj5JdCBpczwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz4gPEZPTlQgZmFjZT0i 66eR7J2AIOqzoOuUlSIgc2l6ZT0yPmFwcHJlY2lhdGU8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9 ZW4tdXM+PEZPTlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPjwvRk9OVD4gPEZPTlQgZmFj ZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPnRvIGdpdmUgY29tbWVudHMuPC9GT05UPjwvU1BBTj48 L1A+DQo8UCBkaXI9bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNl PSLrp5HsnYAg6rOg65SVIiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBkaXI9 bHRyIGFsaWduPWp1c3RpZnk+PFNQQU4gbGFuZz1lbi11cz48Rk9OVCBmYWNlPSLrp5HsnYAg6rOg 65SVIiBzaXplPTI+QmVzdCByZWdhcmRzLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1lbi11cz48 L1NQQU4+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1qdXN0aWZ5PjxTUEFOIGxhbmc9ZW4tdXM+PEZP TlQgZmFjZT0i66eR7J2AIOqzoOuUlSIgc2l6ZT0yPllvbmctR2V1bi48L0ZPTlQ+PC9TUEFOPjwv UD48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVp Z2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNw eD9lbWFpbD1taWZAaWV0Zi5vcmcmbmFtZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25n QGV0cmkucmUua3ImbWVzc2FnZWlkPSUzQzY5MGJhYmNmLWNlNzEtNDk0OS1hMmFmLWU4NzEyNTM3 MjAzNkBldHJpLnJlLmtyJTNFIj4= ------_=_NextPart_001_01C98114.CAF6F100-- --===============0826656559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0826656559==-- From mif-bounces@ietf.org Wed Jan 28 02:08:02 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3171028C25E; Wed, 28 Jan 2009 02:08:02 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A871128C25E; Wed, 28 Jan 2009 02:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfc3zJKpoqFM; Wed, 28 Jan 2009 02:07:56 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id CBA9728C25D; Wed, 28 Jan 2009 02:07:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,337,1231110000"; d="vcf'?scan'208";a="23182761" Received: from guest-rocq-135129.inria.fr ([128.93.135.129]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jan 2009 11:07:36 +0100 Message-ID: <49802E59.7030407@inria.fr> Date: Wed, 28 Jan 2009 11:07:21 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> In-Reply-To: <498027F9.8050604@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------070403020101030809060408" Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --------------070403020101030809060408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, The work on mobile edge multihoming (multiple interface support) started in the NEMO WG where we published RFC 4980 “Analysis of Multihoming in Network Mobility Support”. This document expresses the problem statement for multihomed mobile routers and mobile networks with multiple mobile routers. A similar document "Analysis of Multihoming in Mobile IPv6" http://tools.ietf.org/html/draft-ietf-monami6-mipv6-analysis-05 has been started under the framework of the MonAmi6 WG and is now a work item in MeXT, as pointed out by Marcelo. In addition, another draft explaining the motivations also exists http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 These two drafts correspond to the 2 MeXT WG items as reminded by Marcelo (we need to republish them, though - the lack of progress on these documents is due to a number of reasons and the recent activity on this topic is pleading for a quick update - and I'm will willing to do it ASAP given this interest). So, I think MIF shall be referring to these 3 documents (RFC 4980 and the 2 above mentioned drafts) since the purpose of these documents is to document the issues for mobile hosts and routers. Regards, Thierry marcelo bagnulo braun wrote: > Hi, > > In the current MEXT charter there are several items about supporting > multiple interfaces, including the following two: > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > I think this is very similar to the scope of one of you documents at > least, so i would find very strange that the same work is chartered in > two different working groups. > > Moreover, we do have wg documents for these two, but we find very hard > to find reviewers for those, which makes me think that there is not > much interest on these. So, if you find a more motivated crew to do > the work, that would be great, we can either do it in mext or > soemwhere else, if people feels that needs to be done, but that is > certainly not the feeling i am getting from the input in mext > > Regards, marcelo > > > > Hong Yong-Geun escribió: >> >> Hi, all in MEXT and mif. >> >> >> >> In IETF mif (Multiple Interface) mailing list >> (_https://www.ietf.org/mailman/listinfo/mif_ >> ), >> >> we now discuss the host which would like to use multiple interfaces. >> >> I understand that MEXT WG is also related to the use of multiple >> interfaces of a host >> using Mobile IPv6 or a mobile router using NEMO Basic Support and >> their variants >> >> MEXT WG is focuing on monami6 related topic (multiple CoA, Multiple >> HoA, and Multple HA, etc.,) >> and extedning Mobile IPv6 and NEMO for these, but mif is not related >> to this direction. >> In mif, source address selection, routing and DNS control protocol >> are consideration items >> due to multiple interfaces of a host. >> >> >> >> For mif’s scope, Jari Arkko made some comments and classification of >> problems. >> >> _http://www.ietf.org/mail-archive/web/mif/current/msg00050.html_ >> >> Among these classification which includes access selection, split >> DNS, configuration reconciliation, >> routing, address selection, tunnel multihoming, and the communication >> way between the host and >> the network about their policies regarding all of the above, Jari >> said that access selection is already >> coverd in RFC 5113 and tunnel multihoming is already covered in MEXT >> WG work items. >> >> >> >> At monami6 WG in 64th IETF meetinng, I submitted and presented two >> Internet Drafts. >> >> - Analysis of multiple interfaces in a Mobile Node >> >> _http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt_ >> >> - Virtual network interface for multiple interfaces in a Mobile node >> using Mobile IPv6 >> >> _http://tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_ >> >> >> Because these two drafts were not in the monami6 WG’s scope and >> virtual network interface draft was >> >> implementation specific, there were not adoped in monami6 WG’s work >> items. The intentions of two drafts >> are supporting multiple interfaces of a host without extending Mobile >> IPv6/NEMO. >> >> >> >> I think that multiple interfaces problems of a host are related to >> both Mobile IP/NEMO specific issues and >> general network issues. Mobile IP/NEMO specific issues are related to >> extending of Mobile IP/NEMO and >> these are already studied in MEXT WG and general network issues which >> were not related to >> Mobile IP/NEMO could be studied in mif. As same manner, I think that >> my drafts could be discussed and >> developed in mif. In the first draft (Analysis document), I >> classified multiple interface problems into >> Mobile IPv6-sepcific issues, General network issues, and >> heterogeneous environment issues. >> >> >> >> Including Hui Deng in mif, with regarding to these drafts, they want >> to hear comments from MEXT WG’s point of view, >> because it seems that these drafts are quite related to monami6/MEXT >> WG. So, I ask MEXT to review whether there are >> >> some overlap between MEXT works and my drafts or not. >> >> It is appreciate to give comments. >> >> >> >> Best regards. >> >> Yong-Geun. >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------070403020101030809060408 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="thierry_ernst.vcf" YmVnaW46dmNhcmQNCmZuOlRoaWVycnkgRXJuc3QNCm46RXJuc3Q7VGhpZXJyeQ0Kb3JnOklO UklBIFJvY3F1ZW5jb3VydDtJTUFSQSAtIExBUkENCmFkcjo7Ozs7OztGcmFuY2UNCnRlbDt3 b3JrOiszMyAxIDM5IDYzIDU5IDMwDQp0ZWw7ZmF4OiszMyAxIDM5IDYzIDU0IDkxDQp0ZWw7 Y2VsbDorMzMgNiA3NiA1NiAyNSA5Ng0KdXJsOmh0dHA6Ly93d3cubGFyYS5wcmQuZnINCnZl cnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --------------070403020101030809060408 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------070403020101030809060408-- From mif-bounces@ietf.org Wed Jan 28 02:35:38 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E1E3A69A2; Wed, 28 Jan 2009 02:35:38 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D057228C10F for ; Wed, 28 Jan 2009 02:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXpOiU9EaHPb for ; Wed, 28 Jan 2009 02:35:37 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 187FF3A63EB for ; Wed, 28 Jan 2009 02:35:35 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 11:34:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jan 2009 09:17:33 +0100 Message-ID: In-Reply-To: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] One general issue on MIF thread-index: AcmA96Ymei+S4BB0QOKy0X27pdOuuwAKArHg References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> From: To: , X-OriginalArrivalTime: 28 Jan 2009 10:34:07.0155 (UTC) FILETIME=[F2ADA030:01C98133] Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1878075854==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============1878075854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98120.DF2A1AF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98120.DF2A1AF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kai, =20 Please see my opinion inline. =20 Regards, Pierrick =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Kai Ju Envoy=E9 : mercredi 28 janvier 2009 04:22 =C0 : mif Objet : [mif] One general issue on MIF =20 Hi, All =20 Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese = Spring Festival, and good luck for whole new year. =20 I got one issue which maybe would raise a fundamental question on MIF, = and it has confused me for days. =20 If host has WLan connection, and user wanna start one application on it, = because Wlan provided by ISP is free. But the policy which host has got = from network forbid it on Wlan. When they're conflict between the policy = and user's willing, how should MIF do? Ignor user's willing, choose = another interface according the policy? Or change the policy, do what the user wanna do?=20 =20 So, the question is policy and user's willing, who get the higher = priority? =20 [PS] IMO, it is an implementation issue. Some operators are thinking = that the final decision is made on the user preferences except if cannot = apply (e.g. preferred access overloaded making it impossible to use); = but it's not the only way to do. =20 BRG =20 Kai ------_=_NextPart_001_01C98120.DF2A1AF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kai,

 

Please see my opinion inline.

 

Regards,

Pierrick

 

De : = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la = part de Kai Ju
Envoy=E9 : mercredi = 28 janvier 2009 04:22
=C0 : mif
Objet : [mif] One = general issue on MIF

 

Hi, All

 

Firstly, allow me wish everyone in MIF Discussion a magnificent = Chinese Spring Festival, and good luck for whole new = year.

 

I got one issue which maybe would raise a fundamental question = on MIF, and it has confused me for days.

 

If host has WLan connection, and user wanna start one = application on it, because Wlan provided by ISP is free. But the policy which host = has got from network forbid it on Wlan. When they're conflict between the = policy and user's willing, how should MIF do? Ignor user's willing, choose = another interface according the policy? Or change = the

policy, do what the user wanna do?

 

So, the question is policy and user's willing, who get the = higher priority?

 

[PS] IMO, it is an implementation issue. Some operators are thinking that the = final decision is made on the user preferences except if cannot apply (e.g. preferred = access overloaded making it impossible to use); but it's not the only way to = do.

 

BRG

 

Kai

------_=_NextPart_001_01C98120.DF2A1AF8-- --===============1878075854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1878075854==-- From mif-bounces@ietf.org Wed Jan 28 07:13:22 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A106B3A6B4C; Wed, 28 Jan 2009 07:13:22 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033D428C246; Wed, 28 Jan 2009 01:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Je3XbLgIDS; Wed, 28 Jan 2009 01:40:31 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B360D28C120; Wed, 28 Jan 2009 01:40:29 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.145.150]) by smtp01.uc3m.es (Postfix) with ESMTP id 03FE4B4D453; Wed, 28 Jan 2009 10:40:09 +0100 (CET) Message-ID: <498027F9.8050604@it.uc3m.es> Date: Wed, 28 Jan 2009 10:40:09 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Hong Yong-Geun References: <932b01c98117$dcb28e10$8310fe81@etri.info> In-Reply-To: <932b01c98117$dcb28e10$8310fe81@etri.info> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16428.005 X-Mailman-Approved-At: Wed, 28 Jan 2009 07:13:21 -0800 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org SGksCgpJbiB0aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMg YWJvdXQgc3VwcG9ydGluZyAKbXVsdGlwbGUgaW50ZXJmYWNlcywgaW5jbHVkaW5nIHRoZSBmb2xs b3dpbmcgdHdvOgoKLSBBIGRvY3VtZW50IGV4cGxhaW5pbmcgdGhlIG1vdGl2YXRpb25zIGZvciBh IG5vZGUgdXNpbmcgbXVsdGlwbGUKaW50ZXJmYWNlcyBhbmQgdGhlIHNjZW5hcmlvcyB3aGVyZSBp dCBtYXkgZW5kIHVwIHdpdGggbXVsdGlwbGUKZ2xvYmFsIGFkZHJlc3NlcyBvbiBpdHMgaW50ZXJm YWNlcyBbSW5mb3JtYXRpb25hbF0KCi0gQW4gYW5hbHlzaXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3 aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9yCm1vYmlsZSBob3N0cyB1c2luZyBtdWx0aXBsZSBz aW11bHRhbmVvdXMgQ2FyZS1vZiBBZGRyZXNzZXMgYW5kIEhvbWUKQWdlbnQgYWRkcmVzc2VzIHVz aW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlzc3VlcyBhcmUgc3BlY2lmaWMgdG8KTW9iaWxlIElQ djYgb3Igbm90IFtJbmZvcm1hdGlvbmFsXS4KCkkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHNpbWlsYXIg dG8gdGhlIHNjb3BlIG9mIG9uZSBvZiB5b3UgZG9jdW1lbnRzIGF0IApsZWFzdCwgc28gaSB3b3Vs ZCBmaW5kIHZlcnkgc3RyYW5nZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluIAp0 d28gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzLgoKTW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9j dW1lbnRzIGZvciB0aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZlcnkgaGFyZCAKdG8gZmluZCByZXZp ZXdlcnMgZm9yIHRob3NlLCB3aGljaCBtYWtlcyBtZSB0aGluayB0aGF0IHRoZXJlIGlzIG5vdCBt dWNoIAppbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5kIGEgbW9yZSBtb3RpdmF0ZWQg Y3JldyB0byBkbyB0aGUgd29yaywgCnRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIg ZG8gaXQgaW4gbWV4dCBvciBzb2Vtd2hlcmUgZWxzZSwgaWYgCnBlb3BsZSBmZWVscyB0aGF0IG5l ZWRzIHRvIGJlIGRvbmUsIGJ1dCB0aGF0IGlzIGNlcnRhaW5seSBub3QgdGhlIApmZWVsaW5nIGkg YW0gZ2V0dGluZyBmcm9tIHRoZSBpbnB1dCBpbiBtZXh0CgpSZWdhcmRzLCBtYXJjZWxvCgoKCkhv bmcgWW9uZy1HZXVuIGVzY3JpYmnDszoKPgo+IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLgo+Cj4g IAo+Cj4gSW4gSUVURiBtaWYgKE11bHRpcGxlIEludGVyZmFjZSkgbWFpbGluZyBsaXN0IAo+IChf aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfIAo+IDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+Cj4gd2Ugbm93IGRpc2N1c3MgdGhl IGhvc3Qgd2hpY2ggd291bGQgbGlrZSB0byB1c2UgbXVsdGlwbGUgaW50ZXJmYWNlcy4KPgo+IEkg dW5kZXJzdGFuZCB0aGF0IE1FWFQgV0cgaXMgYWxzbyByZWxhdGVkIHRvIHRoZSB1c2Ugb2YgbXVs dGlwbGUgCj4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPiB1c2luZyBNb2JpbGUgSVB2NiBvciBhIG1v YmlsZSByb3V0ZXIgdXNpbmcgTkVNTyBCYXNpYyBTdXBwb3J0IGFuZCAKPiB0aGVpciB2YXJpYW50 cwo+Cj4gTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1vbmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlw bGUgQ29BLCBNdWx0aXBsZSAKPiBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLCkKPiBhbmQgZXh0 ZWRuaW5nIE1vYmlsZSBJUHY2IGFuZCBORU1PIGZvciB0aGVzZSwgYnV0IG1pZiBpcyBub3QgcmVs YXRlZCAKPiB0byB0aGlzIGRpcmVjdGlvbi4KPiBJbiBtaWYsIHNvdXJjZSBhZGRyZXNzIHNlbGVj dGlvbiwgcm91dGluZyBhbmQgRE5TIGNvbnRyb2wgcHJvdG9jb2wgYXJlIAo+IGNvbnNpZGVyYXRp b24gaXRlbXMKPiBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuCj4KPiAgCj4K PiBGb3IgbWlm4oCZcyBzY29wZSwgSmFyaSBBcmtrbyBtYWRlIHNvbWUgY29tbWVudHMgYW5kIGNs YXNzaWZpY2F0aW9uIG9mIAo+IHByb2JsZW1zLgo+Cj4gX2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXwo+Cj4gQW1vbmcgdGhlc2Ug Y2xhc3NpZmljYXRpb24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgRE5T LCAKPiBjb25maWd1cmF0aW9uIHJlY29uY2lsaWF0aW9uLAo+IHJvdXRpbmcsIGFkZHJlc3Mgc2Vs ZWN0aW9uLCB0dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbiAKPiB3YXkg YmV0d2VlbiB0aGUgaG9zdCBhbmQKPiB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2llcyBy ZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkIAo+IHRoYXQgYWNjZXNzIHNlbGVj dGlvbiBpcyBhbHJlYWR5Cj4gY292ZXJkIGluIFJGQyA1MTEzIGFuZCB0dW5uZWwgbXVsdGlob21p bmcgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIE1FWFQgCj4gV0cgd29yayBpdGVtcy4KPgo+ICAKPgo+ IEF0IG1vbmFtaTYgV0cgaW4gNjR0aCBJRVRGIG1lZXRpbm5nLCBJIHN1Ym1pdHRlZCBhbmQgcHJl c2VudGVkIHR3byAKPiBJbnRlcm5ldCBEcmFmdHMuCj4KPiAtIEFuYWx5c2lzIG9mIG11bHRpcGxl IGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZQo+Cj4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF8KPgo+IC0gVmly dHVhbCBuZXR3b3JrIGludGVyZmFjZSBmb3IgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmls ZSBub2RlIAo+IHVzaW5nIE1vYmlsZSBJUHY2Cj4KPiBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8gCj4gPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ+Cj4KPiBCZWNh dXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0figJlzIHNjb3Bl IGFuZCAKPiB2aXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGRyYWZ0IHdhcwo+Cj4gaW1wbGVtZW50 YXRpb24gc3BlY2lmaWMsIHRoZXJlIHdlcmUgbm90IGFkb3BlZCBpbiBtb25hbWk2IFdH4oCZcyB3 b3JrIAo+IGl0ZW1zLiBUaGUgaW50ZW50aW9ucyBvZiB0d28gZHJhZnRzCj4gYXJlIHN1cHBvcnRp bmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3Qgd2l0aG91dCBleHRlbmRpbmcgTW9iaWxl IAo+IElQdjYvTkVNTy4KPgo+ICAKPgo+IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2Vz IHByb2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVsYXRlZCB0byAKPiBib3RoIE1vYmlsZSBJUC9ORU1P IHNwZWNpZmljIGlzc3VlcyBhbmQKPiBnZW5lcmFsIG5ldHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAv TkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJlbGF0ZWQgdG8gCj4gZXh0ZW5kaW5nIG9mIE1vYmls ZSBJUC9ORU1PIGFuZAo+IHRoZXNlIGFyZSBhbHJlYWR5IHN0dWRpZWQgaW4gTUVYVCBXRyBhbmQg Z2VuZXJhbCBuZXR3b3JrIGlzc3VlcyB3aGljaCAKPiB3ZXJlIG5vdCByZWxhdGVkIHRvCj4gTW9i aWxlIElQL05FTU8gY291bGQgYmUgc3R1ZGllZCBpbiBtaWYuIEFzIHNhbWUgbWFubmVyLCBJIHRo aW5rIHRoYXQgCj4gbXkgZHJhZnRzIGNvdWxkIGJlIGRpc2N1c3NlZCBhbmQKPiBkZXZlbG9wZWQg aW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQgKEFuYWx5c2lzIGRvY3VtZW50KSwgSSBjbGFzc2lm aWVkIAo+IG11bHRpcGxlIGludGVyZmFjZSBwcm9ibGVtcyBpbnRvCj4gTW9iaWxlIElQdjYtc2Vw Y2lmaWMgaXNzdWVzLCBHZW5lcmFsIG5ldHdvcmsgaXNzdWVzLCBhbmQgaGV0ZXJvZ2VuZW91cyAK PiBlbnZpcm9ubWVudCBpc3N1ZXMuCj4KPiAgCj4KPiBJbmNsdWRpbmcgSHVpIERlbmcgaW4gbWlm LCB3aXRoIHJlZ2FyZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkgd2FudCAKPiB0byBoZWFyIGNv bW1lbnRzIGZyb20gTUVYVCBXR+KAmXMgcG9pbnQgb2YgdmlldywKPiBiZWNhdXNlIGl0IHNlZW1z IHRoYXQgdGhlc2UgZHJhZnRzIGFyZSBxdWl0ZSByZWxhdGVkIHRvIG1vbmFtaTYvTUVYVCAKPiBX Ry4gU28sIEkgYXNrIE1FWFQgdG8gcmV2aWV3IHdoZXRoZXIgdGhlcmUgYXJlCj4KPiBzb21lIG92 ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Igbm90Lgo+Cj4gSXQgaXMg YXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLgo+Cj4gIAo+Cj4gQmVzdCByZWdhcmRzLgo+Cj4g WW9uZy1HZXVuLgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwptaWYgbWFpbGluZyBsaXN0Cm1pZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pZgo= From mif-bounces@ietf.org Wed Jan 28 08:57:09 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4373228C16B; Wed, 28 Jan 2009 08:57:09 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C5A28C12C for ; Wed, 28 Jan 2009 08:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14FmE6abpR2M for ; Wed, 28 Jan 2009 08:57:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 21FF33A6B2A for ; Wed, 28 Jan 2009 08:57:07 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so7944678wfd.31 for ; Wed, 28 Jan 2009 08:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SRjjzsfF3pekbpymfuqTrfvtQdTyg0UhKpyRzTQT6ak=; b=DBaCRnW0xwF0y5Ek68ptdqpjiErRaNv131d7AGsNT/yAQexJ+Dv8hV/Eq1bHZ44SVs hLRmC6M40kQKJEXwr2JAAjCbHzobL3xwJ0GdaR/h1unYEGt4UibKRGBrjx1a5JchFRyz 939TtlE4kP4Lr1WNPnRBIpPvSnBK+XqYHlrBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HdSeTTsSYP+yps0863soGyofc3ic2pLUNR/AtQmkar6eRIWrqNFMygoQkszMdfPWHx n6nG194hkuZrzjhCk0owq/zOOFajNalLK/LTqxSo5DY34i71QScY61SuZPY8pk38NyT2 0bQiJcS2GuDtIReYOgFEgAupPQWCP5bPYbQj8= MIME-Version: 1.0 Received: by 10.142.166.2 with SMTP id o2mr4433001wfe.312.1233161808049; Wed, 28 Jan 2009 08:56:48 -0800 (PST) In-Reply-To: References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> Date: Thu, 29 Jan 2009 00:56:48 +0800 Message-ID: <1d38a3350901280856p633bee5pc98c5ed95d996dfa@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1471126835==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1471126835== Content-Type: multipart/alternative; boundary=000e0cd32cf684f90904618ddbe9 --000e0cd32cf684f90904618ddbe9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree Pierrick's opinion here, it is more local policy implementaion issue, MIF is only working on transfer some network policy to the local policy repository. this repository may be used between application and socket api interface. thanks -Hui 2009/1/28 > Hi Kai, > > > > Please see my opinion inline. > > > > Regards, > > Pierrick > > > ------------------------------ > > *De :* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *De la part de*= Kai Ju > *Envoy=E9 :* mercredi 28 janvier 2009 04:22 > *=C0 :* mif > *Objet :* [mif] One general issue on MIF > > > > Hi, All > > > > Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese > Spring Festival, and good luck for whole new year. > > > > I got one issue which maybe would raise a fundamental question on MIF, an= d > it has confused me for days. > > > > If host has WLan connection, and user wanna start one application on it, > because Wlan provided by ISP is free. But the policy which host has got f= rom > network forbid it on Wlan. When they're conflict between the policy and > user's willing, how should MIF do? Ignor user's willing, choose another > interface according the policy? Or change the > > policy, do what the user wanna do? > > > > So, the question is policy and user's willing, who get the higher priorit= y > ? > > > > [PS] IMO, it is an implementation issue. Some operators are thinking that > the final decision is made on the user preferences except if cannot apply > (e.g. preferred access overloaded making it impossible to use); but it's = not > the only way to do. > > > > BRG > > > > Kai > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd32cf684f90904618ddbe9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree Pierrick's opinion here, it is more local policy implement= aion issue,
MIF is only working on transfer some network policy to the local polic= y repository.
this repository may be used between application and socket api interfa= ce.
 
thanks
 
-Hui

2009/1/28 <pierrick.seite@orange-ftgroup.com&= gt;

Hi Kai,

 =

Please see my opinio= n inline.

 =

Regards,

Pierrick

 =

De : mif-bounces@iet= f.org [mailto:mif-bounces@ietf.org] De la part = de Kai Ju
Envoy=E9 : mercredi 28= janvier 2009 04:22
=C0 : mif
Objet : = [mif] One general issue on MIF

 

[PS] IMO, it is an i= mplementation issue. Some operators are thinking that the final decision is= made on the user preferences except if cannot apply (e.g. preferred access= overloaded making it impossible to use); but it's not the only way to = do.

 


--000e0cd32cf684f90904618ddbe9-- --===============1471126835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1471126835==-- From mif-bounces@ietf.org Wed Jan 28 12:44:04 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DA328C111; Wed, 28 Jan 2009 12:44:04 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4C128C111 for ; Wed, 28 Jan 2009 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmQ+Lm4Un6RZ for ; Wed, 28 Jan 2009 12:44:02 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 15A1E28C10F for ; Wed, 28 Jan 2009 12:44:02 -0800 (PST) Received: (qmail 29733 invoked by uid 60001); 28 Jan 2009 20:43:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=VdnjkLHWRXkvQ3lK1PJm1rE0/yu7LIjzgE4kVJLUCySo+otjsetcsEBzKVG50VcZ2xHtmYVSuPnAtYNF4xwOnFTeNzUAQjzo74FgzW+T7WXLVqvDsS6eL3OkL62RtsR9CZJjw/D7UZhnpi+zH9dyiKX3x79h6zbYAGqC8nKziII=; X-YMail-OSG: Uane8.MVM1nbJx9iZF7TgjKfQf.5lyplbBVR1mR.mUCB6qnGsiDaaBpoXjR7QNVUTUBmfuYU2fjoT.Z56DQ3mFLKxRtcRapUdsweAl_u_IoVvCIR2iIAu_cTs1xmKopKyGRwBtpBM1m46m6ktH0e_dymgWzwtKGNqexUbHOK_KQ.5ijVYtJn1JwnKcBpDbAHgPmmVyKTV47jwE8- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 28 Jan 2009 12:43:43 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> <1d38a3350901280856p633bee5pc98c5ed95d996dfa@mail.gmail.com> Date: Wed, 28 Jan 2009 12:43:43 -0800 (PST) From: Behcet Sarikaya To: Hui Deng , pierrick.seite@orange-ftgroup.com MIME-Version: 1.0 Message-ID: <776469.29263.qm@web111411.mail.gq1.yahoo.com> Cc: mif@ietf.org Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1513556009==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1513556009== Content-Type: multipart/alternative; boundary="0-431070286-1233175423=:29263" --0-431070286-1233175423=:29263 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,=0A=A0 See my question below.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A= =0A________________________________=0AFrom: Hui Deng = =0ATo: pierrick.seite@orange-ftgroup.com=0ACc: mif@ietf.org=0ASent: Wednesd= ay, January 28, 2009 10:56:48 AM=0ASubject: Re: [mif] One general issue on = MIF=0A=0A=0AI agree Pierrick's opinion here, it is more local policy implem= entaion issue,=0AMIF is only working on transfer some network policy to the= local policy repository.=0Athis repository may be used between application= and socket api interface.=0A=A0=0A[behcet] What type of protocol will be u= sed for this purpose?=0A=0Athanks=0A=0A-Hui=0A=0A=0A2009/1/28 =0A=0AHi Kai,=0A=A0=0APlease see my opinion inline.= =0A=A0=0ARegards,=0APierrick=0A=A0=0A=0A________________________________=0A= =0ADe=A0:mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de K= ai Ju=0AEnvoy=E9=A0: mercredi 28 janvier 2009 04:22=0A=C0=A0: mif=0AObjet= =A0: [mif] One general issue on MIF=0A=A0=0AHi, All=0A=A0=0AFirstly, allow = me wish everyone in MIF Discussion a magnificent Chinese Spring Festival, a= nd good luck for=A0whole new year.=0A=A0=0AI got one issue which maybe woul= d raise a fundamental question on MIF, and it has confused me for days.=0A= =A0=0AIf=A0host has WLan connection, and user wanna start one application o= n it, because Wlan provided by ISP is free. But the policy which host has g= ot from network forbid it on Wlan. When=A0they're conflict between the poli= cy and user's willing, how should MIF do? Ignor user's willing, choose anot= her interface according the policy? Or change the=0Apolicy, do what the use= r wanna do? =0A=A0=0ASo, the question is policy and user's willing, who get= the higher priority?=0A=A0=0A[PS] IMO, it is an implementation issue. Some= operators are thinking that the final decision is made on the user prefere= nces except if cannot apply (e.g. preferred access overloaded making it imp= ossible to use); but it's not the only way to do.=0A=A0=0ABRG=0A=A0=0AKai= =0A_______________________________________________=0Amif mailing list=0Amif= @ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mif=0A=0A=0A --0-431070286-1233175423=:29263 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hui,
=0A
  See my question below.=0A
 
=0A
Regards,
=0A
 
=0A
Beh= cet
=0A

=0A
=0A=
=0AFrom: Hui D= eng <denghui02@gmail.com>
To:= pierrick.seite@orange-ftgroup.com
Cc: mif@ietf.org
Sent: Wednesday, January 28, 2009 10:56:48 AM
Subject: Re: [mif] One general issue o= n MIF

=0A
I agree Pierrick's opinion here, it is more loc= al policy implementaion issue,
=0A
MIF is only working on transfer= some network policy to the local policy repository.
=0A
this repo= sitory may be used between application and socket api interface.
=0A 
=0A
[= behcet] What type of protocol will be used for this purpose?
= =0A
 
=0A
thanks
=0A
 
=0A
-Hui
=0A
2009/1/28 <pierrick.seite@oran= ge-ftgroup.com>
=0A
=0A
=0A
=0A

Hi Kai,

=0A

 

=0A

Please see my opinion inline.

=0A

 

=0A

Regards,

=0A

Pierrick

=0A

 

=0A
=0A
=0A
=0A
=0A
=0A

De :mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Kai Ju
Envoy=E9 : mercredi 28 janvier 2009 04:= 22
=C0 : mif
= Objet : [mif] One general= issue on MIF

=0A
=0A
=0A
=0A

 

=0A
=0A

Hi, All

=0A
=0A

 

=0A
=0A

Firstly, allow me wish= everyone in MIF Discussion a magnificent Chinese Spring Festival, and good= luck for whole new year.

=0A
=0A

 

=0A
=0A

<= SPAN style=3D"FONT-SIZE: 12pt">I got one issue which maybe would raise a fu= ndamental question on MIF, and it has confused me for days.

=0A
=0A

 

=0A
=0A

If host = has WLan connection, and user wanna start one application on it, because Wl= an provided by ISP is free. But the policy which host has got from network = forbid it on Wlan. When they're conflict between the policy and user's= willing, how should MIF do? Ignor user's willing, choose another interface= according the policy? Or change the

=0A
=0A

<= FONT face=3D"Times New Roman" size=3D3>poli= cy, do what the user wanna do?

=0A
=0A

 

=0A
=0A
=0A
=0A
=0A

So, the question is policy and user's willing, who get the hi= gher priority?

=0A

 

=0A

[PS] IMO, it is an implementation issue. Some operators= are thinking that the final decision is made on the user preferences excep= t if cannot apply (e.g. preferred access overloaded making it impossible to= use); but it's not the only way to do.

=0A
=0A<= P> 

=0A
=0A

BRG

<= /DIV>=0A
=0A

 

=0A
=0A

Kai<= /P>


____________________________________________= ___
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

=

=0A=0A=0A=0A --0-431070286-1233175423=:29263-- --===============1513556009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1513556009==-- From mif-bounces@ietf.org Wed Jan 28 18:37:39 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101F528C243; Wed, 28 Jan 2009 18:37:39 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EE33A6872 for ; Wed, 28 Jan 2009 18:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.923 X-Spam-Level: * X-Spam-Status: No, score=1.923 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1YVMzn+NEKb for ; Wed, 28 Jan 2009 18:37:36 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 7145E3A693F for ; Wed, 28 Jan 2009 18:37:36 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 29 Jan 2009 11:37:19 +0900 Priority: normal X-ReadCheckName: mif%40ietf.org Thread-Topic: Re: Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <577f229e-2bf2-4c5e-9b97-e2d3891e2cb5@etri.re.kr> thread-index: AcmBuoFMCJH4RGXFThWZcJo161OlJg== From: "Hong Yong-Geun" To: "marcelo bagnulo braun" Date: Thu, 29 Jan 2009 11:37:19 +0900 Comment: ??, u-??, Message-ID: <545501c981ba$8155e500$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 29 Jan 2009 02:37:19.0243 (UTC) FILETIME=[81726DB0:01C981BA] Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0696481403==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0696481403== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_544B_01C98205.F138D210" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_544B_01C98205.F138D210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_544B_01C98205.F138D210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGksIE1hcmNlbG8uPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5JIGFncmVlIHRoYXQmbmJzcDsgdGhlIGN1cnJlbnQgTUVYVCBXRyBj aGFydGVyIGFscmVhZHkgaGFzIHNldmVyYWwgaXRlbXMgYWJvdXQgc3VwcG9ydGluZyBtdWx0aXBs ZSBpbnRlcmZhY2VzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+TXkgZG9jdW1lbnRz IGFyZSBvbGQgdmVyc2lvbiB3aGljaCB3ZXJlIHN1Ym1pdHRlZCB0byBtb25hbWk2IFdHIGF0IDY0 dGggSUVURiBtZWV0aW5nIGFuZCB0aGV5IHdlcmU8QlI+bm90IHVwZGF0ZWQgcHJvcGVybHkuIFNv LCBpdCBzZWVtcyB0aGF0IHNvbWUgY29udGVudHMgYXJlIHNpbWlsYXIgdG8gdGhlIHdvcmtzIGlu IE1FWFQgV0cuIDwvRElWPg0KPERJVj5JIHdpbGwgdXBkYXRlIG15IGRvY3VtZW50cyB0byBmb2N1 cyBvbiBtaWYncyBzY29wZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkl0IGlzIGFw cHJlY2lhdGUgdG8gdW5kZXJzdGFuZCB0aGF0IChldmVuIHRob3VnaCB0aGUgc2NvcGUgb2YgbWlm IGlzIG5vdCBmaXhlZCkgbWlmIGhhcyBkaWZmZXJlbnQgZGlyZWN0aW9ucyB0bzxCUj5NRVhULiA8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgcmVnYXJkcy48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPllvbmctR2V1bi48L0RJVj4NCjxESVY+PEJSPi0tLS0t7JuQ67O4 IOuplOyLnOyngC0tLS0tPEJSPjxCPkZyb206PC9CPiAibWFyY2VsbyBiYWdudWxvIGJyYXVuIiAm bHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9CPiAyMDA5LTAxLTI4 IOyYpO2bhCA2OjQwOjA5PEJSPjxCPlRvOjwvQj4gIkhvbmcgWW9uZy1HZXVuIiAmbHQ7eWdob25n QGV0cmkucmUua3ImZ3Q7PEJSPjxCPkNjOjwvQj4gIm1leHRAaWV0Zi5vcmciICZsdDttZXh0QGll dGYub3JnJmd0OywgIm1pZkBpZXRmLm9yZyIgJmx0O21pZkBpZXRmLm9yZyZndDssICJqdWxpZW4u bGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgJmx0O2p1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tJmd0OywgImRlbmdodWkwMkBnbWFpbC5jb20iICZsdDtkZW5naHVpMDJAZ21h aWwuY29tJmd0OzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJv YmxlbXMgaW4gTUVYVCBhbmQgbWlmPEJSPjxCUj4NCjxESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0 ZXh0L3BsYWluIGZvcm1hdCAtLT48QlI+DQo8UD48Rk9OVCBzaXplPTI+SGksPEJSPjxCUj5JbiB0 aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMgYWJvdXQgc3Vw cG9ydGluZzxCUj5tdWx0aXBsZSBpbnRlcmZhY2VzLCBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZyB0 d286PEJSPjxCUj4tIEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEg bm9kZSB1c2luZyBtdWx0aXBsZTxCUj5pbnRlcmZhY2VzIGFuZCB0aGUgc2NlbmFyaW9zIHdoZXJl IGl0IG1heSBlbmQgdXAgd2l0aCBtdWx0aXBsZTxCUj5nbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBp bnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXTxCUj48QlI+LSBBbiBhbmFseXNpcyBkb2N1bWVudCBl eHBsYWluaW5nIHdoYXQgYXJlIHRoZSBsaW1pdGF0aW9ucyBmb3I8QlI+bW9iaWxlIGhvc3RzIHVz aW5nIG11bHRpcGxlIHNpbXVsdGFuZW91cyBDYXJlLW9mIEFkZHJlc3NlcyBhbmQgSG9tZTxCUj5B Z2VudCBhZGRyZXNzZXMgdXNpbmcgTW9iaWxlIElQdjYsIHdoZXRoZXIgaXNzdWVzIGFyZSBzcGVj aWZpYyB0bzxCUj5Nb2JpbGUgSVB2NiBvciBub3QgW0luZm9ybWF0aW9uYWxdLjxCUj48QlI+SSB0 aGluayB0aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgc2NvcGUgb2Ygb25lIG9mIHlvdSBkb2N1 bWVudHMgYXQ8QlI+bGVhc3QsIHNvIGkgd291bGQgZmluZCB2ZXJ5IHN0cmFuZ2UgdGhhdCB0aGUg c2FtZSB3b3JrIGlzIGNoYXJ0ZXJlZCBpbjxCUj50d28gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBz LjxCUj48QlI+TW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0aGVzZSB0d28s IGJ1dCB3ZSBmaW5kIHZlcnkgaGFyZDxCUj50byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdo aWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhlcmUgaXMgbm90IG11Y2g8QlI+aW50ZXJlc3Qgb24g dGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8gdGhlIHdv cmssPEJSPnRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQgaW4gbWV4dCBv ciBzb2Vtd2hlcmUgZWxzZSwgaWY8QlI+cGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9u ZSwgYnV0IHRoYXQgaXMgY2VydGFpbmx5IG5vdCB0aGU8QlI+ZmVlbGluZyBpIGFtIGdldHRpbmcg ZnJvbSB0aGUgaW5wdXQgaW4gbWV4dDxCUj48QlI+UmVnYXJkcywgbWFyY2VsbzxCUj48QlI+PEJS PjxCUj5Ib25nIFlvbmctR2V1biBlc2NyaWJpPzo8QlI+Jmd0OzxCUj4mZ3Q7IEhpLCBhbGwgaW4g TUVYVCBhbmQgbWlmLjxCUj4mZ3Q7PEJSPiZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7IEluIElF VEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcgbGlzdDxCUj4mZ3Q7IChfPEEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfIiB0YXJnZXQ9X2Js YW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmXzwvQT48QlI+Jmd0 OyAmbHQ7PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYi IHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8 L0E+Jmd0OyksPEJSPiZndDs8QlI+Jmd0OyB3ZSBub3cgZGlzY3VzcyB0aGUgaG9zdCB3aGljaCB3 b3VsZCBsaWtlIHRvIHVzZSBtdWx0aXBsZSBpbnRlcmZhY2VzLjxCUj4mZ3Q7PEJSPiZndDsgSSB1 bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBtdWx0 aXBsZTxCUj4mZ3Q7IGludGVyZmFjZXMgb2YgYSBob3N0PEJSPiZndDsgdXNpbmcgTW9iaWxlIElQ djYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU8gQmFzaWMgU3VwcG9ydCBhbmQ8QlI+Jmd0 OyB0aGVpciB2YXJpYW50czxCUj4mZ3Q7PEJSPiZndDsgTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1v bmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlwbGUgQ29BLCBNdWx0aXBsZTxCUj4mZ3Q7IEhvQSwg YW5kIE11bHRwbGUgSEEsIGV0Yy4sKTxCUj4mZ3Q7IGFuZCBleHRlZG5pbmcgTW9iaWxlIElQdjYg YW5kIE5FTU8gZm9yIHRoZXNlLCBidXQgbWlmIGlzIG5vdCByZWxhdGVkPEJSPiZndDsgdG8gdGhp cyBkaXJlY3Rpb24uPEJSPiZndDsgSW4gbWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJv dXRpbmcgYW5kIEROUyBjb250cm9sIHByb3RvY29sIGFyZTxCUj4mZ3Q7IGNvbnNpZGVyYXRpb24g aXRlbXM8QlI+Jmd0OyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuPEJSPiZn dDs8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPiZndDsgRm9yIG1pZuKAmXMgc2NvcGUsIEphcmkg QXJra28gbWFkZSBzb21lIGNvbW1lbnRzIGFuZCBjbGFzc2lmaWNhdGlvbiBvZjxCUj4mZ3Q7IHBy b2JsZW1zLjxCUj4mZ3Q7PEJSPiZndDsgXzxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXyIgdGFyZ2V0PV9ibGFuaz5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAu aHRtbF88L0E+PEJSPiZndDs8QlI+Jmd0OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlvbiB3aGlj aCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsPEJSPiZndDsgY29uZmlndXJh dGlvbiByZWNvbmNpbGlhdGlvbiw8QlI+Jmd0OyByb3V0aW5nLCBhZGRyZXNzIHNlbGVjdGlvbiwg dHVubmVsIG11bHRpaG9taW5nLCBhbmQgdGhlIGNvbW11bmljYXRpb248QlI+Jmd0OyB3YXkgYmV0 d2VlbiB0aGUgaG9zdCBhbmQ8QlI+Jmd0OyB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2ll cyByZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkPEJSPiZndDsgdGhhdCBhY2Nl c3Mgc2VsZWN0aW9uIGlzIGFscmVhZHk8QlI+Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1 bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7IFdHIHdv cmsgaXRlbXMuPEJSPiZndDs8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPiZndDsgQXQgbW9uYW1p NiBXRyBpbiA2NHRoIElFVEYgbWVldGlubmcsIEkgc3VibWl0dGVkIGFuZCBwcmVzZW50ZWQgdHdv PEJSPiZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7PEJSPiZndDsgLSBBbmFseXNpcyBvZiBt dWx0aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIE5vZGU8QlI+Jmd0OzxCUj4mZ3Q7IF88QSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBi LXN0YXRlbWVudC0wMC50eHRfIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF88L0E+PEJSPiZn dDs8QlI+Jmd0OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVy ZmFjZXMgaW4gYSBNb2JpbGUgbm9kZTxCUj4mZ3Q7IHVzaW5nIE1vYmlsZSBJUHY2PEJSPiZndDs8 QlI+Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmly dHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZndDsg Jmx0OzxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxp Zi1tbi1taXB2Ni0wMC50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dDwvQT4mZ3Q7PEJSPiZndDs8QlI+ Jmd0OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0fi gJlzIHNjb3BlIGFuZDxCUj4mZ3Q7IHZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZHJhZnQgd2Fz PEJSPiZndDs8QlI+Jmd0OyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYywgdGhlcmUgd2VyZSBub3Qg YWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcms8QlI+Jmd0OyBpdGVtcy4gVGhlIGludGVudGlv bnMgb2YgdHdvIGRyYWZ0czxCUj4mZ3Q7IGFyZSBzdXBwb3J0aW5nIG11bHRpcGxlIGludGVyZmFj ZXMgb2YgYSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZTxCUj4mZ3Q7IElQdjYvTkVNTy48 QlI+Jmd0OzxCUj4mZ3Q7Jm5ic3A7PEJSPiZndDs8QlI+Jmd0OyBJIHRoaW5rIHRoYXQgbXVsdGlw bGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBvZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG88QlI+Jmd0OyBi b3RoIE1vYmlsZSBJUC9ORU1PIHNwZWNpZmljIGlzc3VlcyBhbmQ8QlI+Jmd0OyBnZW5lcmFsIG5l dHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJlbGF0ZWQg dG88QlI+Jmd0OyBleHRlbmRpbmcgb2YgTW9iaWxlIElQL05FTU8gYW5kPEJSPiZndDsgdGhlc2Ug YXJlIGFscmVhZHkgc3R1ZGllZCBpbiBNRVhUIFdHIGFuZCBnZW5lcmFsIG5ldHdvcmsgaXNzdWVz IHdoaWNoPEJSPiZndDsgd2VyZSBub3QgcmVsYXRlZCB0bzxCUj4mZ3Q7IE1vYmlsZSBJUC9ORU1P IGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwgSSB0aGluayB0aGF0PEJS PiZndDsgbXkgZHJhZnRzIGNvdWxkIGJlIGRpc2N1c3NlZCBhbmQ8QlI+Jmd0OyBkZXZlbG9wZWQg aW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQgKEFuYWx5c2lzIGRvY3VtZW50KSwgSSBjbGFzc2lm aWVkPEJSPiZndDsgbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG88QlI+Jmd0OyBNb2Jp bGUgSVB2Ni1zZXBjaWZpYyBpc3N1ZXMsIEdlbmVyYWwgbmV0d29yayBpc3N1ZXMsIGFuZCBoZXRl cm9nZW5lb3VzPEJSPiZndDsgZW52aXJvbm1lbnQgaXNzdWVzLjxCUj4mZ3Q7PEJSPiZndDsmbmJz cDs8QlI+Jmd0OzxCUj4mZ3Q7IEluY2x1ZGluZyBIdWkgRGVuZyBpbiBtaWYsIHdpdGggcmVnYXJk aW5nIHRvIHRoZXNlIGRyYWZ0cywgdGhleSB3YW50PEJSPiZndDsgdG8gaGVhciBjb21tZW50cyBm cm9tIE1FWFQgV0figJlzIHBvaW50IG9mIHZpZXcsPEJSPiZndDsgYmVjYXVzZSBpdCBzZWVtcyB0 aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01FWFQ8QlI+Jmd0 OyBXRy4gU28sIEkgYXNrIE1FWFQgdG8gcmV2aWV3IHdoZXRoZXIgdGhlcmUgYXJlPEJSPiZndDs8 QlI+Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Ig bm90LjxCUj4mZ3Q7PEJSPiZndDsgSXQgaXMgYXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLjxC Uj4mZ3Q7PEJSPiZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7IEJlc3QgcmVnYXJkcy48QlI+Jmd0 OzxCUj4mZ3Q7IFlvbmctR2V1bi48QlI+Jmd0OzxCUj48QlI+PC9GT05UPjwvUD48L0RJVj48L0RJ Vj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJo dHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1taWZA aWV0Zi5vcmcmbmFtZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25nQGV0cmkucmUua3Im bWVzc2FnZWlkPSUzQzU3N2YyMjllLTJiZjItNGM1ZS05Yjk3LWUyZDM4OTFlMmNiNUBldHJpLnJl LmtyJTNFIj4= ------=_NextPart_000_544B_01C98205.F138D210-- --===============0696481403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0696481403==-- From mif-bounces@ietf.org Wed Jan 28 18:46:01 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104513A6C35; Wed, 28 Jan 2009 18:46:01 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E015D3A6872 for ; Wed, 28 Jan 2009 18:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBogBZ7su6gh for ; Wed, 28 Jan 2009 18:45:57 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 8E2C83A697F for ; Wed, 28 Jan 2009 18:45:57 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 29 Jan 2009 11:45:39 +0900 Priority: normal X-ReadCheckName: mif%40ietf.org Thread-Topic: [MEXT] Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <62702911-2d45-4b38-9064-1326df8044fa@etri.re.kr> thread-index: AcmBu6vE3drNFl6kSdSQrFtmofgKHg== From: "Hong Yong-Geun" To: "Thierry Ernst" , "marcelo bagnulo braun" Date: Thu, 29 Jan 2009 11:45:39 +0900 Comment: ??, u-??, Message-ID: <582c01c981bb$abcbd6e0$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 29 Jan 2009 02:45:39.0978 (UTC) FILETIME=[ABE886A0:01C981BB] Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] [MEXT] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527049863==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0527049863== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_581D_01C98207.1BAEC3F0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_581D_01C98207.1BAEC3F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_581D_01C98207.1BAEC3F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SGksJm5ic3A7VGhpZXJyeS48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgYWdyZWUgdGhhdCB0aGUgMyBkb2N1bWVudHMgd2hpY2gg eW91IG1lbnRpb24gc2hvdWxkIGJlIHJlZmVycmVkIGluIG1pZjxCUj53aGVuIHdlIHRhbGsgdG8g bW9iaWxlIGhvc3RzIGFuZCByb3V0ZXJzIHdpdGggdXNpbmcgTW9iaWxlIElQdjYvTkVNTy48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgcmVnYXJkcy48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPllvbmctR2V1bi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxCUj4tLS0tLeybkOuzuCDrqZTsi5zsp4AtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gIlRoaWVycnkg RXJuc3QiICZsdDt0aGllcnJ5LmVybnN0QGlucmlhLmZyJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9C PiAyMDA5LTAxLTI4IOyYpO2bhCA3OjA3OjIxPEJSPjxCPlRvOjwvQj4gIm1hcmNlbG8gYmFnbnVs byBicmF1biIgJmx0O21hcmNlbG9AaXQudWMzbS5lcyZndDs8QlI+PEI+Q2M6PC9CPiAiSG9uZyBZ b25nLUdldW4iICZsdDt5Z2hvbmdAZXRyaS5yZS5rciZndDssICJqdWxpZW4ubGFnYW5pZXIuSUVU RkBnb29nbGVtYWlsLmNvbSIgJmx0O2p1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29t Jmd0OywgIm1pZkBpZXRmLm9yZyIgJmx0O21pZkBpZXRmLm9yZyZndDssICJtZXh0QGlldGYub3Jn IiAmbHQ7bWV4dEBpZXRmLm9yZyZndDs8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbTUVYVF0gTXVs dGlwbGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBpbiBNRVhUIGFuZCBtaWY8QlI+PEJSPg0KPERJVj48 IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPjxCUj48QlI+DQo8UD48Rk9O VCBzaXplPTI+RGVhciBhbGwsPEJSPjxCUj5UaGUgd29yayBvbiBtb2JpbGUgZWRnZSBtdWx0aWhv bWluZyAobXVsdGlwbGUgaW50ZXJmYWNlIHN1cHBvcnQpIHN0YXJ0ZWQ8QlI+aW4gdGhlIE5FTU8g V0cgd2hlcmUgd2UgcHVibGlzaGVkIFJGQyA0OTgwIOKAnEFuYWx5c2lzIG9mIE11bHRpaG9taW5n IGluPEJSPk5ldHdvcmsgTW9iaWxpdHkgU3VwcG9ydOKAnS4mbmJzcDsgVGhpcyBkb2N1bWVudCBl eHByZXNzZXMgdGhlIHByb2JsZW08QlI+c3RhdGVtZW50IGZvciBtdWx0aWhvbWVkIG1vYmlsZSBy b3V0ZXJzIGFuZCBtb2JpbGUgbmV0d29ya3Mgd2l0aDxCUj5tdWx0aXBsZSBtb2JpbGUgcm91dGVy cy48QlI+PEJSPkEgc2ltaWxhciBkb2N1bWVudCAiQW5hbHlzaXMgb2YgTXVsdGlob21pbmcgaW4g TW9iaWxlIElQdjYiPEJSPjxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbW9uYW1pNi1taXB2Ni1hbmFseXNpcy0wNSIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbWlwdjYtYW5hbHlzaXMtMDU8L0E+ PEJSPmhhcyBiZWVuIHN0YXJ0ZWQgdW5kZXIgdGhlIGZyYW1ld29yayBvZiB0aGUgTW9uQW1pNiBX RyBhbmQgaXMgbm93IGEgd29yazxCUj5pdGVtIGluIE1lWFQsIGFzIHBvaW50ZWQgb3V0IGJ5IE1h cmNlbG8uPEJSPjxCUj5JbiBhZGRpdGlvbiwgYW5vdGhlciBkcmFmdCBleHBsYWluaW5nIHRoZSBt b3RpdmF0aW9ucyBhbHNvIGV4aXN0czxCUj48QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlob21pbmctbW90aXZhdGlvbi1zY2VuYXJpby0w MyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1v bmFtaTYtbXVsdGlob21pbmctbW90aXZhdGlvbi1zY2VuYXJpby0wMzwvQT48QlI+PEJSPlRoZXNl IHR3byBkcmFmdHMgY29ycmVzcG9uZCB0byB0aGUgMiBNZVhUIFdHIGl0ZW1zIGFzIHJlbWluZGVk IGJ5PEJSPk1hcmNlbG8gKHdlIG5lZWQgdG8gcmVwdWJsaXNoIHRoZW0sIHRob3VnaCAtIHRoZSBs YWNrIG9mIHByb2dyZXNzIG9uPEJSPnRoZXNlIGRvY3VtZW50cyBpcyBkdWUgdG8gYSBudW1iZXIg b2YgcmVhc29ucyBhbmQgdGhlIHJlY2VudCBhY3Rpdml0eSBvbjxCUj50aGlzIHRvcGljIGlzIHBs ZWFkaW5nIGZvciBhIHF1aWNrIHVwZGF0ZSAtIGFuZCBJJ20gd2lsbCB3aWxsaW5nIHRvIGRvPEJS Pml0IEFTQVAgZ2l2ZW4gdGhpcyBpbnRlcmVzdCkuPEJSPjxCUj5TbywgSSB0aGluayBNSUYgc2hh bGwgYmUgcmVmZXJyaW5nIHRvIHRoZXNlIDMgZG9jdW1lbnRzIChSRkMgNDk4MCBhbmQ8QlI+dGhl IDIgYWJvdmUgbWVudGlvbmVkIGRyYWZ0cykgc2luY2UgdGhlIHB1cnBvc2Ugb2YgdGhlc2UgZG9j dW1lbnRzIGlzIHRvPEJSPmRvY3VtZW50IHRoZSBpc3N1ZXMgZm9yIG1vYmlsZSBob3N0cyBhbmQg cm91dGVycy48QlI+PEJSPlJlZ2FyZHMsPEJSPlRoaWVycnk8QlI+PEJSPjxCUj48QlI+PEJSPjxC Uj5tYXJjZWxvIGJhZ251bG8gYnJhdW4gd3JvdGU6PEJSPiZndDsgSGksPEJSPiZndDs8QlI+Jmd0 OyBJbiB0aGUgY3VycmVudCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMgYWJv dXQgc3VwcG9ydGluZzxCUj4mZ3Q7IG11bHRpcGxlIGludGVyZmFjZXMsIGluY2x1ZGluZyB0aGUg Zm9sbG93aW5nIHR3bzo8QlI+Jmd0OzxCUj4mZ3Q7IC0gQSBkb2N1bWVudCBleHBsYWluaW5nIHRo ZSBtb3RpdmF0aW9ucyBmb3IgYSBub2RlIHVzaW5nIG11bHRpcGxlPEJSPiZndDsgaW50ZXJmYWNl cyBhbmQgdGhlIHNjZW5hcmlvcyB3aGVyZSBpdCBtYXkgZW5kIHVwIHdpdGggbXVsdGlwbGU8QlI+ Jmd0OyBnbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXTxC Uj4mZ3Q7PEJSPiZndDsgLSBBbiBhbmFseXNpcyBkb2N1bWVudCBleHBsYWluaW5nIHdoYXQgYXJl IHRoZSBsaW1pdGF0aW9ucyBmb3I8QlI+Jmd0OyBtb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUg c2ltdWx0YW5lb3VzIENhcmUtb2YgQWRkcmVzc2VzIGFuZCBIb21lPEJSPiZndDsgQWdlbnQgYWRk cmVzc2VzIHVzaW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlzc3VlcyBhcmUgc3BlY2lmaWMgdG88 QlI+Jmd0OyBNb2JpbGUgSVB2NiBvciBub3QgW0luZm9ybWF0aW9uYWxdLjxCUj4mZ3Q7PEJSPiZn dDsgSSB0aGluayB0aGlzIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgc2NvcGUgb2Ygb25lIG9mIHlv dSBkb2N1bWVudHMgYXQ8QlI+Jmd0OyBsZWFzdCwgc28gaSB3b3VsZCBmaW5kIHZlcnkgc3RyYW5n ZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluPEJSPiZndDsgdHdvIGRpZmZlcmVu dCB3b3JraW5nIGdyb3Vwcy48QlI+Jmd0OzxCUj4mZ3Q7IE1vcmVvdmVyLCB3ZSBkbyBoYXZlIHdn IGRvY3VtZW50cyBmb3IgdGhlc2UgdHdvLCBidXQgd2UgZmluZCB2ZXJ5IGhhcmQ8QlI+Jmd0OyB0 byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhl cmUgaXMgbm90PEJSPiZndDsgbXVjaCBpbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5k IGEgbW9yZSBtb3RpdmF0ZWQgY3JldyB0byBkbzxCUj4mZ3Q7IHRoZSB3b3JrLCB0aGF0IHdvdWxk IGJlIGdyZWF0LCB3ZSBjYW4gZWl0aGVyIGRvIGl0IGluIG1leHQgb3I8QlI+Jmd0OyBzb2Vtd2hl cmUgZWxzZSwgaWYgcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSwgYnV0IHRoYXQg aXM8QlI+Jmd0OyBjZXJ0YWlubHkgbm90IHRoZSBmZWVsaW5nIGkgYW0gZ2V0dGluZyBmcm9tIHRo ZSBpbnB1dCBpbiBtZXh0PEJSPiZndDs8QlI+Jmd0OyBSZWdhcmRzLCBtYXJjZWxvPEJSPiZndDs8 QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSG9uZyBZb25nLUdldW4gZXNjcmliaT86PEJSPiZndDsm Z3Q7PEJSPiZndDsmZ3Q7IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLjxCUj4mZ3Q7Jmd0OzxCUj4m Z3Q7Jmd0OyZuYnNwOzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJbiBJRVRGIG1pZiAoTXVsdGlw bGUgSW50ZXJmYWNlKSBtYWlsaW5nIGxpc3Q8QlI+Jmd0OyZndDsgKF88QSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8iIHRhcmdldD1fYmxhbms+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfPC9BPjxCUj4mZ3Q7Jmd0OyAmbHQ7 PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYiIHRhcmdl dD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L0E+Jmd0 OyksPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IHdlIG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNo IHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMuPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IE1FWFQgV0cgaXMgYWxzbyByZWxhdGVkIHRvIHRoZSB1 c2Ugb2YgbXVsdGlwbGU8QlI+Jmd0OyZndDsgaW50ZXJmYWNlcyBvZiBhIGhvc3Q8QlI+Jmd0OyZn dDsgdXNpbmcgTW9iaWxlIElQdjYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIE5FTU8gQmFzaWMg U3VwcG9ydCBhbmQ8QlI+Jmd0OyZndDsgdGhlaXIgdmFyaWFudHM8QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsgTUVYVCBXRyBpcyBmb2N1aW5nIG9uIG1vbmFtaTYgcmVsYXRlZCB0b3BpYyAobXVsdGlw bGUgQ29BLCBNdWx0aXBsZTxCUj4mZ3Q7Jmd0OyBIb0EsIGFuZCBNdWx0cGxlIEhBLCBldGMuLCk8 QlI+Jmd0OyZndDsgYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhlc2Us IGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQ8QlI+Jmd0OyZndDsgdG8gdGhpcyBkaXJlY3Rpb24uPEJS PiZndDsmZ3Q7IEluIG1pZiwgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uLCByb3V0aW5nIGFuZCBE TlMgY29udHJvbCBwcm90b2NvbDxCUj4mZ3Q7Jmd0OyBhcmUgY29uc2lkZXJhdGlvbiBpdGVtczxC Uj4mZ3Q7Jmd0OyBkdWUgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuPEJSPiZndDsm Z3Q7PEJSPiZndDsmZ3Q7Jm5ic3A7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEZvciBtaWbigJlz IHNjb3BlLCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24g b2Y8QlI+Jmd0OyZndDsgcHJvYmxlbXMuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IF88QSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAw NTAuaHRtbF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21pZi9jdXJyZW50L21zZzAwMDUwLmh0bWxfPC9BPjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0 OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlvbiB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0 aW9uLCBzcGxpdDxCUj4mZ3Q7Jmd0OyBETlMsIGNvbmZpZ3VyYXRpb24gcmVjb25jaWxpYXRpb24s PEJSPiZndDsmZ3Q7IHJvdXRpbmcsIGFkZHJlc3Mgc2VsZWN0aW9uLCB0dW5uZWwgbXVsdGlob21p bmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbjxCUj4mZ3Q7Jmd0OyB3YXkgYmV0d2VlbiB0aGUgaG9z dCBhbmQ8QlI+Jmd0OyZndDsgdGhlIG5ldHdvcmsgYWJvdXQgdGhlaXIgcG9saWNpZXMgcmVnYXJk aW5nIGFsbCBvZiB0aGUgYWJvdmUsIEphcmk8QlI+Jmd0OyZndDsgc2FpZCB0aGF0IGFjY2VzcyBz ZWxlY3Rpb24gaXMgYWxyZWFkeTxCUj4mZ3Q7Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1 bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7Jmd0OyBX RyB3b3JrIGl0ZW1zLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZuYnNwOzxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7Jmd0OyBBdCBtb25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJtaXR0 ZWQgYW5kIHByZXNlbnRlZCB0d288QlI+Jmd0OyZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7 Jmd0OzxCUj4mZ3Q7Jmd0OyAtIEFuYWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBN b2JpbGUgTm9kZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0 XyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0 aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMC50eHRfPC9BPjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0 OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFjZXMgaW4g YSBNb2JpbGUgbm9kZTxCUj4mZ3Q7Jmd0OyB1c2luZyBNb2JpbGUgSVB2NjxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmct dmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZn dDsmZ3Q7ICZsdDs8QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12 aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ8L0E+Jmd0OzxCUj4m Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4g dGhlIG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZDxCUj4mZ3Q7Jmd0OyB2aXJ0dWFsIG5ldHdvcmsg aW50ZXJmYWNlIGRyYWZ0IHdhczxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlv biBzcGVjaWZpYywgdGhlcmUgd2VyZSBub3QgYWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcms8 QlI+Jmd0OyZndDsgaXRlbXMuIFRoZSBpbnRlbnRpb25zIG9mIHR3byBkcmFmdHM8QlI+Jmd0OyZn dDsgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBhIGhvc3Qgd2l0aG91dCBl eHRlbmRpbmcgTW9iaWxlPEJSPiZndDsmZ3Q7IElQdjYvTkVNTy48QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsmbmJzcDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgSSB0aGluayB0aGF0IG11bHRpcGxl IGludGVyZmFjZXMgcHJvYmxlbXMgb2YgYSBob3N0IGFyZSByZWxhdGVkIHRvPEJSPiZndDsmZ3Q7 IGJvdGggTW9iaWxlIElQL05FTU8gc3BlY2lmaWMgaXNzdWVzIGFuZDxCUj4mZ3Q7Jmd0OyBnZW5l cmFsIG5ldHdvcmsgaXNzdWVzLiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJlIHJl bGF0ZWQgdG88QlI+Jmd0OyZndDsgZXh0ZW5kaW5nIG9mIE1vYmlsZSBJUC9ORU1PIGFuZDxCUj4m Z3Q7Jmd0OyB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5kIGdlbmVyYWwg bmV0d29yayBpc3N1ZXMgd2hpY2g8QlI+Jmd0OyZndDsgd2VyZSBub3QgcmVsYXRlZCB0bzxCUj4m Z3Q7Jmd0OyBNb2JpbGUgSVAvTkVNTyBjb3VsZCBiZSBzdHVkaWVkIGluIG1pZi4gQXMgc2FtZSBt YW5uZXIsIEkgdGhpbmsgdGhhdDxCUj4mZ3Q7Jmd0OyBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vz c2VkIGFuZDxCUj4mZ3Q7Jmd0OyBkZXZlbG9wZWQgaW4gbWlmLiBJbiB0aGUgZmlyc3QgZHJhZnQg KEFuYWx5c2lzIGRvY3VtZW50KSwgSTxCUj4mZ3Q7Jmd0OyBjbGFzc2lmaWVkIG11bHRpcGxlIGlu dGVyZmFjZSBwcm9ibGVtcyBpbnRvPEJSPiZndDsmZ3Q7IE1vYmlsZSBJUHY2LXNlcGNpZmljIGlz c3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kPEJSPiZndDsmZ3Q7IGhldGVyb2dlbmVv dXMgZW52aXJvbm1lbnQgaXNzdWVzLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZuYnNwOzxCUj4m Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJbmNsdWRpbmcgSHVpIERlbmcgaW4gbWlmLCB3aXRoIHJlZ2Fy ZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkgd2FudDxCUj4mZ3Q7Jmd0OyB0byBoZWFyIGNvbW1l bnRzIGZyb20gTUVYVCBXR+KAmXMgcG9pbnQgb2Ygdmlldyw8QlI+Jmd0OyZndDsgYmVjYXVzZSBp dCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01F WFQ8QlI+Jmd0OyZndDsgV0cuIFNvLCBJIGFzayBNRVhUIHRvIHJldmlldyB3aGV0aGVyIHRoZXJl IGFyZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdv cmtzIGFuZCBteSBkcmFmdHMgb3Igbm90LjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJdCBpcyBh cHByZWNpYXRlIHRvIGdpdmUgY29tbWVudHMuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jm5ic3A7 PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEJlc3QgcmVnYXJkcy48QlI+Jmd0OyZndDs8QlI+Jmd0 OyZndDsgWW9uZy1HZXVuLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBNRVhUIG1haWxpbmcg bGlzdDxCUj4mZ3Q7IE1FWFRAaWV0Zi5vcmc8QlI+Jmd0OyA8QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0PC9BPjxCUj48QlI+PC9GT05UPjwvUD48L0RJ Vj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAg c3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFp bD1taWZAaWV0Zi5vcmcmbmFtZT1taWYlNDBpZXRmLm9yZyZmcm9tZW1haWw9eWdob25nQGV0cmku cmUua3ImbWVzc2FnZWlkPSUzQzYyNzAyOTExLTJkNDUtNGIzOC05MDY0LTEzMjZkZjgwNDRmYUBl dHJpLnJlLmtyJTNFIj4= ------=_NextPart_000_581D_01C98207.1BAEC3F0-- --===============0527049863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0527049863==-- From mif-bounces@ietf.org Thu Jan 29 00:28:27 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED96528C140; Thu, 29 Jan 2009 00:28:27 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41153A6905; Wed, 28 Jan 2009 23:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49b0vF5ry-yf; Wed, 28 Jan 2009 23:58:17 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id DA5053A682E; Wed, 28 Jan 2009 23:58:16 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.142.187]) by smtp01.uc3m.es (Postfix) with ESMTP id 0246BB4D439; Thu, 29 Jan 2009 08:57:55 +0100 (CET) Message-ID: <49816184.1080502@it.uc3m.es> Date: Thu, 29 Jan 2009 08:57:56 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Hong Yong-Geun References: <544a01c981ba$81512a10$8310fe81@etri.info> In-Reply-To: <544a01c981ba$81512a10$8310fe81@etri.info> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16430.005 X-Mailman-Approved-At: Thu, 29 Jan 2009 00:28:27 -0800 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org SGkgSG9uZywKCndoYXQgaXMgdGhlIHNjb3BlIG9mIE1JRj8KSSBtZWFuLCBpbiB0aGUgYm9mIHdp a2kgcGFnZSB0aGVyZSBpcyBubyBjaGFydGVyIHByb3Bvc2VkLCBpcyB0aGVyZSBhIApjaGFydGVy IHNvbWV3aGVyZT8KSW4gcGFydGljdWxhciwgaXMgTUlGIGdvaW5nIHRvIHdvcmsgaW4gTUlQdjYv TkVNTyByZWxhdGVkIGlzc3Vlcz8KClJlZ2FyZHMsIG1hcmNlbG8KCgpIb25nIFlvbmctR2V1biBl c2NyaWJpw7M6Cj4gIAo+IEhpLCBNYXJjZWxvLgo+ICAKPiBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuCj4gIAo+IEkgYWdyZWUgdGhhdCAgdGhlIGN1cnJlbnQgTUVYVCBXRyBjaGFydGVyIGFscmVh ZHkgaGFzIHNldmVyYWwgaXRlbXMgCj4gYWJvdXQgc3VwcG9ydGluZyBtdWx0aXBsZSBpbnRlcmZh Y2VzLgo+ICAKPiBNeSBkb2N1bWVudHMgYXJlIG9sZCB2ZXJzaW9uIHdoaWNoIHdlcmUgc3VibWl0 dGVkIHRvIG1vbmFtaTYgV0cgYXQgCj4gNjR0aCBJRVRGIG1lZXRpbmcgYW5kIHRoZXkgd2VyZQo+ IG5vdCB1cGRhdGVkIHByb3Blcmx5LiBTbywgaXQgc2VlbXMgdGhhdCBzb21lIGNvbnRlbnRzIGFy ZSBzaW1pbGFyIHRvIAo+IHRoZSB3b3JrcyBpbiBNRVhUIFdHLgo+IEkgd2lsbCB1cGRhdGUgbXkg ZG9jdW1lbnRzIHRvIGZvY3VzIG9uIG1pZidzIHNjb3BlLgo+ICAKPiBJdCBpcyBhcHByZWNpYXRl IHRvIHVuZGVyc3RhbmQgdGhhdCAoZXZlbiB0aG91Z2ggdGhlIHNjb3BlIG9mIG1pZiBpcyAKPiBu b3QgZml4ZWQpIG1pZiBoYXMgZGlmZmVyZW50IGRpcmVjdGlvbnMgdG8KPiBNRVhULgo+ICAKPiBC ZXN0IHJlZ2FyZHMuCj4gIAo+IFlvbmctR2V1bi4KPgo+IC0tLS0t7JuQ67O4IOuplOyLnOyngC0t LS0tCj4gKkZyb206KiAibWFyY2VsbyBiYWdudWxvIGJyYXVuIiA8bWFyY2Vsb0BpdC51YzNtLmVz Pgo+ICpGcm9tIERhdGU6KiAyMDA5LTAxLTI4IOyYpO2bhCA2OjQwOjA5Cj4gKlRvOiogIkhvbmcg WW9uZy1HZXVuIiA8eWdob25nQGV0cmkucmUua3I+Cj4gKkNjOiogIm1leHRAaWV0Zi5vcmciIDxt ZXh0QGlldGYub3JnPiwgIm1pZkBpZXRmLm9yZyIgPG1pZkBpZXRmLm9yZz4sIAo+ICJqdWxpZW4u bGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgCj4gPGp1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tPiwgImRlbmdodWkwMkBnbWFpbC5jb20iIAo+IDxkZW5naHVpMDJAZ21haWwu Y29tPgo+ICpTdWJqZWN0OiogUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJvYmxlbXMgaW4gTUVY VCBhbmQgbWlmCj4KPgo+IEhpLAo+Cj4gSW4gdGhlIGN1cnJlbnQgTUVYVCBjaGFydGVyIHRoZXJl IGFyZSBzZXZlcmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcKPiBtdWx0aXBsZSBpbnRlcmZhY2Vz LCBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZyB0d286Cj4KPiAtIEEgZG9jdW1lbnQgZXhwbGFpbmlu ZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBtdWx0aXBsZQo+IGludGVyZmFjZXMg YW5kIHRoZSBzY2VuYXJpb3Mgd2hlcmUgaXQgbWF5IGVuZCB1cCB3aXRoIG11bHRpcGxlCj4gZ2xv YmFsIGFkZHJlc3NlcyBvbiBpdHMgaW50ZXJmYWNlcyBbSW5mb3JtYXRpb25hbF0KPgo+IC0gQW4g YW5hbHlzaXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9y Cj4gbW9iaWxlIGhvc3RzIHVzaW5nIG11bHRpcGxlIHNpbXVsdGFuZW91cyBDYXJlLW9mIEFkZHJl c3NlcyBhbmQgSG9tZQo+IEFnZW50IGFkZHJlc3NlcyB1c2luZyBNb2JpbGUgSVB2Niwgd2hldGhl ciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvCj4gTW9iaWxlIElQdjYgb3Igbm90IFtJbmZvcm1hdGlv bmFsXS4KPgo+IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIHNjb3BlIG9mIG9u ZSBvZiB5b3UgZG9jdW1lbnRzIGF0Cj4gbGVhc3QsIHNvIGkgd291bGQgZmluZCB2ZXJ5IHN0cmFu Z2UgdGhhdCB0aGUgc2FtZSB3b3JrIGlzIGNoYXJ0ZXJlZCBpbgo+IHR3byBkaWZmZXJlbnQgd29y a2luZyBncm91cHMuCj4KPiBNb3Jlb3Zlciwgd2UgZG8gaGF2ZSB3ZyBkb2N1bWVudHMgZm9yIHRo ZXNlIHR3bywgYnV0IHdlIGZpbmQgdmVyeSBoYXJkCj4gdG8gZmluZCByZXZpZXdlcnMgZm9yIHRo b3NlLCB3aGljaCBtYWtlcyBtZSB0aGluayB0aGF0IHRoZXJlIGlzIG5vdCBtdWNoCj4gaW50ZXJl c3Qgb24gdGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8g dGhlIHdvcmssCj4gdGhhdCB3b3VsZCBiZSBncmVhdCwgd2UgY2FuIGVpdGhlciBkbyBpdCBpbiBt ZXh0IG9yIHNvZW13aGVyZSBlbHNlLCBpZgo+IHBlb3BsZSBmZWVscyB0aGF0IG5lZWRzIHRvIGJl IGRvbmUsIGJ1dCB0aGF0IGlzIGNlcnRhaW5seSBub3QgdGhlCj4gZmVlbGluZyBpIGFtIGdldHRp bmcgZnJvbSB0aGUgaW5wdXQgaW4gbWV4dAo+Cj4gUmVnYXJkcywgbWFyY2Vsbwo+Cj4KPgo+IEhv bmcgWW9uZy1HZXVuIGVzY3JpYmk/Ogo+ID4KPiA+IEhpLCBhbGwgaW4gTUVYVCBhbmQgbWlmLgo+ ID4KPiA+IAo+ID4KPiA+IEluIElFVEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcg bGlzdAo+ID4gKF9odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8KPiA+ IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+ID4KPiA+IHdl IG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGlu dGVyZmFjZXMuCj4gPgo+ID4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0 ZWQgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZQo+ID4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPiA+IHVz aW5nIE1vYmlsZSBJUHY2IG9yIGEgbW9iaWxlIHJvdXRlciB1c2luZyBORU1PIEJhc2ljIFN1cHBv cnQgYW5kCj4gPiB0aGVpciB2YXJpYW50cwo+ID4KPiA+IE1FWFQgV0cgaXMgZm9jdWluZyBvbiBt b25hbWk2IHJlbGF0ZWQgdG9waWMgKG11bHRpcGxlIENvQSwgTXVsdGlwbGUKPiA+IEhvQSwgYW5k IE11bHRwbGUgSEEsIGV0Yy4sKQo+ID4gYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVN TyBmb3IgdGhlc2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQKPiA+IHRvIHRoaXMgZGlyZWN0aW9u Lgo+ID4gSW4gbWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBj b250cm9sIHByb3RvY29sIGFyZQo+ID4gY29uc2lkZXJhdGlvbiBpdGVtcwo+ID4gZHVlIHRvIG11 bHRpcGxlIGludGVyZmFjZXMgb2YgYSBob3N0Lgo+ID4KPiA+IAo+ID4KPiA+IEZvciBtaWbigJlz IHNjb3BlLCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24g b2YKPiA+IHByb2JsZW1zLgo+ID4KPiA+IF9odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbF8KPiA+Cj4gPiBBbW9uZyB0aGVzZSBjbGFz c2lmaWNhdGlvbiB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsCj4g PiBjb25maWd1cmF0aW9uIHJlY29uY2lsaWF0aW9uLAo+ID4gcm91dGluZywgYWRkcmVzcyBzZWxl Y3Rpb24sIHR1bm5lbCBtdWx0aWhvbWluZywgYW5kIHRoZSBjb21tdW5pY2F0aW9uCj4gPiB3YXkg YmV0d2VlbiB0aGUgaG9zdCBhbmQKPiA+IHRoZSBuZXR3b3JrIGFib3V0IHRoZWlyIHBvbGljaWVz IHJlZ2FyZGluZyBhbGwgb2YgdGhlIGFib3ZlLCBKYXJpIHNhaWQKPiA+IHRoYXQgYWNjZXNzIHNl bGVjdGlvbiBpcyBhbHJlYWR5Cj4gPiBjb3ZlcmQgaW4gUkZDIDUxMTMgYW5kIHR1bm5lbCBtdWx0 aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVAo+ID4gV0cgd29yayBpdGVtcy4KPiA+ Cj4gPiAKPiA+Cj4gPiBBdCBtb25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJt aXR0ZWQgYW5kIHByZXNlbnRlZCB0d28KPiA+IEludGVybmV0IERyYWZ0cy4KPiA+Cj4gPiAtIEFu YWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZQo+ID4KPiA+IF9o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0YXRl bWVudC0wMC50eHRfCj4gPgo+ID4gLSBWaXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGZvciBtdWx0 aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIG5vZGUKPiA+IHVzaW5nIE1vYmlsZSBJUHY2Cj4g Pgo+ID4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1t aXB2Ni0wMC50eHRfCj4gPiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmly dHVhbGlmLW1uLW1pcHY2LTAwLnR4dD4KPiA+Cj4gPiBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMg d2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZAo+ID4gdmlydHVhbCBuZXR3 b3JrIGludGVyZmFjZSBkcmFmdCB3YXMKPiA+Cj4gPiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYywg dGhlcmUgd2VyZSBub3QgYWRvcGVkIGluIG1vbmFtaTYgV0figJlzIHdvcmsKPiA+IGl0ZW1zLiBU aGUgaW50ZW50aW9ucyBvZiB0d28gZHJhZnRzCj4gPiBhcmUgc3VwcG9ydGluZyBtdWx0aXBsZSBp bnRlcmZhY2VzIG9mIGEgaG9zdCB3aXRob3V0IGV4dGVuZGluZyBNb2JpbGUKPiA+IElQdjYvTkVN Ty4KPiA+Cj4gPiAKPiA+Cj4gPiBJIHRoaW5rIHRoYXQgbXVsdGlwbGUgaW50ZXJmYWNlcyBwcm9i bGVtcyBvZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG8KPiA+IGJvdGggTW9iaWxlIElQL05FTU8gc3Bl Y2lmaWMgaXNzdWVzIGFuZAo+ID4gZ2VuZXJhbCBuZXR3b3JrIGlzc3Vlcy4gTW9iaWxlIElQL05F TU8gc3BlY2lmaWMgaXNzdWVzIGFyZSByZWxhdGVkIHRvCj4gPiBleHRlbmRpbmcgb2YgTW9iaWxl IElQL05FTU8gYW5kCj4gPiB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5k IGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2gKPiA+IHdlcmUgbm90IHJlbGF0ZWQgdG8KPiA+ IE1vYmlsZSBJUC9ORU1PIGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwg SSB0aGluayB0aGF0Cj4gPiBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vzc2VkIGFuZAo+ID4gZGV2 ZWxvcGVkIGluIG1pZi4gSW4gdGhlIGZpcnN0IGRyYWZ0IChBbmFseXNpcyBkb2N1bWVudCksIEkg Y2xhc3NpZmllZAo+ID4gbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG8KPiA+IE1vYmls ZSBJUHY2LXNlcGNpZmljIGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVy b2dlbmVvdXMKPiA+IGVudmlyb25tZW50IGlzc3Vlcy4KPiA+Cj4gPiAKPiA+Cj4gPiBJbmNsdWRp bmcgSHVpIERlbmcgaW4gbWlmLCB3aXRoIHJlZ2FyZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkg d2FudAo+ID4gdG8gaGVhciBjb21tZW50cyBmcm9tIE1FWFQgV0figJlzIHBvaW50IG9mIHZpZXcs Cj4gPiBiZWNhdXNlIGl0IHNlZW1zIHRoYXQgdGhlc2UgZHJhZnRzIGFyZSBxdWl0ZSByZWxhdGVk IHRvIG1vbmFtaTYvTUVYVAo+ID4gV0cuIFNvLCBJIGFzayBNRVhUIHRvIHJldmlldyB3aGV0aGVy IHRoZXJlIGFyZQo+ID4KPiA+IHNvbWUgb3ZlcmxhcCBiZXR3ZWVuIE1FWFQgd29ya3MgYW5kIG15 IGRyYWZ0cyBvciBub3QuCj4gPgo+ID4gSXQgaXMgYXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRz Lgo+ID4KPiA+IAo+ID4KPiA+IEJlc3QgcmVnYXJkcy4KPiA+Cj4gPiBZb25nLUdldW4uCj4gPgo+ CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwptaWYgbWFp bGluZyBsaXN0Cm1pZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21pZgo= From mif-bounces@ietf.org Thu Jan 29 01:01:47 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EA83A68D4; Thu, 29 Jan 2009 01:01:47 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8293A68D4 for ; Thu, 29 Jan 2009 01:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z2wncKt3aEX for ; Thu, 29 Jan 2009 01:01:44 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3952F3A67F5 for ; Thu, 29 Jan 2009 01:01:43 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0T914V1019974; Thu, 29 Jan 2009 11:01:19 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 11:01:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 11:01:00 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 29 Jan 2009 10:00:59 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 29 Jan 2009 10:00:58 +0100 From: To: , , Date: Thu, 29 Jan 2009 10:00:34 +0100 Thread-Topic: [mif] One general issue on MIF Thread-Index: AcmA96Ymei+S4BB0QOKy0X27pdOuuwAKArHgADOHBwA= Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4@NOK-EUMSG-01.mgdnok.nokia.com> References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2009 09:01:00.0137 (UTC) FILETIME=[1AF81590:01C981F0] X-Nokia-AV: Clean Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088444909==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1088444909== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4NOKEUMSG01mgd_" --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4NOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, All existing devices do solve the complex multi-interface problem by some m= eans, but probably not perfectly. I think managing to standardize tools that help those current implementatio= n-specific solutions work better, e.g. with less user-interaction, with bet= ter default behaviour, with better and faster fall-backs or having better s= election between "otherwise-equal" interfaces etc. would be a good achievem= ent for mif. I mean to work on standardizing tools and issues that can and = should be standardized here, and leave the rest out. In the policy conflict case mentioned below I think it depends, e.g.: - if the device is ISP subsidized (e.g. "rented"), ISP's policy could force= the device to behave exactly as ISP policy says, even if user would prefer= free WLAN available nearby. The ISP likely is able to configure the device= to behave this way by non-IETF means. - similarly, if device is corporation managed & owned, corporation would pr= obably want to be able to force device to do exactly as corporation policy = says, even if user would prefer faster WLAN (the cost might not matter so m= uch in this case). The corporation is likely able to configure device this = way by non-IETF means. - however, if the device is user owned and user managed, user probably woul= d like to have full control on which interface is used, and e.g. have ways = to prioritize expensive (for user) connetions to low (and rather have lower= QoS, longer transport paths, than higher prize) . And the user should have= this possibly available - even if by default device would follow e.g. rece= ived ISP's policies in order to provide easy user experience for those peop= le who don't want to hear about any configuration issues Best regards, Teemu ________________________________ From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext p= ierrick.seite@orange-ftgroup.com Sent: 28 January, 2009 10:18 To: jukai.zte@gmail.com; mif@ietf.org Subject: Re: [mif] One general issue on MIF Hi Kai, Please see my opinion inline. Regards, Pierrick ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Kai J= u Envoy=E9 : mercredi 28 janvier 2009 04:22 =C0 : mif Objet : [mif] One general issue on MIF Hi, All Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese Spr= ing Festival, and good luck for whole new year. I got one issue which maybe would raise a fundamental question on MIF, and = it has confused me for days. If host has WLan connection, and user wanna start one application on it, be= cause Wlan provided by ISP is free. But the policy which host has got from = network forbid it on Wlan. When they're conflict between the policy and use= r's willing, how should MIF do? Ignor user's willing, choose another interf= ace according the policy? Or change the policy, do what the user wanna do? So, the question is policy and user's willing, who get the higher priority? [PS] IMO, it is an implementation issue. Some operators are thinking that t= he final decision is made on the user preferences except if cannot apply (e= .g. preferred access overloaded making it impossible to use); but it's not = the only way to do. BRG Kai --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4NOKEUMSG01mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
All existing devices do solve the complex multi-in= terface=20 problem by some means, but probably not perfectly.
 
I think managing to standardize tools that help th= ose=20 current implementation-specific solutions work better, e.g. with less=20 user-interaction, with better default behaviour, with better and faster=20 fall-backs or having better selection between "otherwise-equal" interfaces = etc.=20 would be a good achievement for mif. I mean to work on standardizing tools = and=20 issues that can and should be standardized here, and leave the rest=20 out.
 
In the policy conflict case mentioned below I thin= k it=20 depends, e.g.:
- if the device is ISP subsidized (e.g.=20 "rented"), ISP's policy could force the device to behave exactly as IS= P=20 policy says, even if user would prefer free WLAN available nearby. The ISP= =20 likely is able to configure the device to behave this way by non-IETF=20 means.
- similarly, if device is corporation managed &= ;=20 owned, corporation would probably want to be able to force device to d= o=20 exactly as corporation policy says, even if user would prefer faster WLAN (= the=20 cost might not matter so much in this case). The corporation is likely able= to=20 configure device this way by non-IETF means.
- however, if the device is user owned and us= er=20 managed, user probably would like to have full control on which interface i= s=20 used, and e.g. have ways to prioritize expensive (for user) connetions to l= ow=20 (and rather have lower QoS, longer transport paths, than higher prize) . An= d the=20 user should have this possibly available - even if by default device would= =20 follow e.g. received ISP's policies in order to provide easy user experienc= e for=20 those people who don't want to hear about any configuration=20 issues
 
Best regards,
 
  &n= bsp; Teemu

From: mif-bounces@ietf.org=20 [mailto:mif-bounces@ietf.org] On Behalf Of ext=20 pierrick.seite@orange-ftgroup.com
Sent: 28 January, 2009=20 10:18
To: jukai.zte@gmail.com; mif@ietf.org
Subject: = Re:=20 [mif] One general issue on MIF

Hi=20 Kai,

 

Please=20 see my opinion inline.

 

Regards,

Pierrick

 

De = ;:=20 mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Kai Ju
Envoy=E9 : mercredi 28 janvie= r 2009=20 04:22
=C0 :=20 mif
Objet : [mif]= One=20 general issue on MIF

 

Hi, All

 

Firstly, allow me wish everyone in MIF Discussi= on a=20 magnificent Chinese Spring Festival, and good luck for whole new=20 year.

 

I got one issue which maybe would raise a funda= mental=20 question on MIF, and it has confused me for=20 days.

 

If host has WLan connection, and user wann= a start=20 one application on it, because Wlan provided by ISP is free. But the poli= cy=20 which host has got from network forbid it on Wlan. When they're conf= lict=20 between the policy and user's willing, how should MIF do? Ignor user's=20 willing, choose another interface according the policy? Or change=20 the

policy, do what the user wanna do?=20

 

So, the question is policy and user's willing, = who get=20 the higher priority?=

 

[PS]=20 IMO, it is an implementation issue. Some operators are thinking that the = final=20 decision is made on the user preferences except if cannot apply (e.g.=20 preferred access overloaded making it impossible to use); but it's not th= e=20 only way to do.

 

BRG

 

Kai

--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4NOKEUMSG01mgd_-- --===============1088444909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1088444909==-- From mif-bounces@ietf.org Thu Jan 29 02:11:27 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE7B3A6C19; Thu, 29 Jan 2009 02:11:26 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E873A6A22; Thu, 29 Jan 2009 02:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FRT_MEETING=2.697, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If0GXzCC5Z3Z; Thu, 29 Jan 2009 02:11:23 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id A8C2D3A6359; Thu, 29 Jan 2009 02:11:22 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so8386746wfd.31 for ; Thu, 29 Jan 2009 02:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iGEjR7U2tbWUOKmSCwLrBPxGKLhut87v9UDvg5mfLd0=; b=Yd4l+o6+nM70N9dlk5M3DSf9PB+vcqDAZIHx7HIR006oEYmtjZb4+9Wb5oQOL3VDRx OlpcUrLVcv91pclp9/vYdkPUKikk70EjhsKQLa75+Tj3O7mc5/uGKTUQP03luCc5Mzml 0jyG6uiT15UXSJMsz7BszTPIlRdLXts7ZjtjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pCJw6PSM84vmMrSVB9YZt5F5GafM6JqRkxLEMFPHpqJmEY1JPjHtOEcT/7SduPr3bg TNxN80ZvFwmYXnsVBOT/zi4Fudvh16AfJVZ6roUWCvIjd3EJwgwLLZgkRhDAYp1DmIVe fuN3S/FAlTaO4NAT4iZ/U6zcfF4CKIxi9ddAg= MIME-Version: 1.0 Received: by 10.142.191.5 with SMTP id o5mr572268wff.326.1233223864590; Thu, 29 Jan 2009 02:11:04 -0800 (PST) In-Reply-To: <49816184.1080502@it.uc3m.es> References: <544a01c981ba$81512a10$8310fe81@etri.info> <49816184.1080502@it.uc3m.es> Date: Thu, 29 Jan 2009 18:11:04 +0800 Message-ID: <1d38a3350901290211g2bab9cfdhaa760405151bb3bc@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1972730725==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1972730725== Content-Type: multipart/alternative; boundary=000e0cd28df260a2d204619c4e9a --000e0cd28df260a2d204619c4e9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Marcelo For yoru question about what mif's scope at the moment, Jari already made the comments on http://www.ietf.org/mail-archive/web/mif/current/msg00050.html There are also several PS drafts you could refer to: http://tools.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt http://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt thanks -Hui 2009/1/29 marcelo bagnulo braun > Hi Hong, > > what is the scope of MIF? > I mean, in the bof wiki page there is no charter proposed, is there a > charter somewhere? > In particular, is MIF going to work in MIPv6/NEMO related issues? > > Regards, marcelo > > > Hong Yong-Geun escribi=C3=B3: > >> Hi, Marcelo. >> Thanks for your comments. >> I agree that the current MEXT WG charter already has several items abo= ut >> supporting multiple interfaces. >> My documents are old version which were submitted to monami6 WG at 64th >> IETF meeting and they were >> not updated properly. So, it seems that some contents are similar to the >> works in MEXT WG. >> I will update my documents to focus on mif's scope. >> It is appreciate to understand that (even though the scope of mif is no= t >> fixed) mif has different directions to >> MEXT. >> Best regards. >> Yong-Geun. >> >> -----=EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80----- >> *From:* "marcelo bagnulo braun" >> *From Date:* 2009-01-28 =EC=98=A4=ED=9B=84 6:40:09 >> *To:* "Hong Yong-Geun" >> *Cc:* "mext@ietf.org" , "mif@ietf.org" , " >> julien.laganier.IETF@googlemail.com" , >> "denghui02@gmail.com" >> *Subject:* Re: Multiple interfaces problems in MEXT and mif >> >> >> >> Hi, >> >> In the current MEXT charter there are several items about supporting >> multiple interfaces, including the following two: >> >> - A document explaining the motivations for a node using multiple >> interfaces and the scenarios where it may end up with multiple >> global addresses on its interfaces [Informational] >> >> - An analysis document explaining what are the limitations for >> mobile hosts using multiple simultaneous Care-of Addresses and Home >> Agent addresses using Mobile IPv6, whether issues are specific to >> Mobile IPv6 or not [Informational]. >> >> I think this is very similar to the scope of one of you documents at >> least, so i would find very strange that the same work is chartered in >> two different working groups. >> >> Moreover, we do have wg documents for these two, but we find very hard >> to find reviewers for those, which makes me think that there is not much >> interest on these. So, if you find a more motivated crew to do the work, >> that would be great, we can either do it in mext or soemwhere else, if >> people feels that needs to be done, but that is certainly not the >> feeling i am getting from the input in mext >> >> Regards, marcelo >> >> >> >> Hong Yong-Geun escribi?: >> > >> > Hi, all in MEXT and mif. >> > >> > > >> > In IETF mif (Multiple Interface) mailing list >> > (_https://www.ietf.org/mailman/listinfo/mif_ >> > ), >> > >> > we now discuss the host which would like to use multiple interfaces. >> > >> > I understand that MEXT WG is also related to the use of multiple >> > interfaces of a host >> > using Mobile IPv6 or a mobile router using NEMO Basic Support and >> > their variants >> > >> > MEXT WG is focuing on monami6 related topic (multiple CoA, Multiple >> > HoA, and Multple HA, etc.,) >> > and extedning Mobile IPv6 and NEMO for these, but mif is not related >> > to this direction. >> > In mif, source address selection, routing and DNS control protocol are >> > consideration items >> > due to multiple interfaces of a host. >> > >> > > >> > For mif's scope, Jari Arkko made some comments and classification of >> > problems. >> > >> > _http://www.ietf.org/mail-archive/web/mif/current/msg00050.html_ >> > >> > Among these classification which includes access selection, split DNS, >> > configuration reconciliation, >> > routing, address selection, tunnel multihoming, and the communication >> > way between the host and >> > the network about their policies regarding all of the above, Jari said >> > that access selection is already >> > coverd in RFC 5113 and tunnel multihoming is already covered in MEXT >> > WG work items. >> > >> > > >> > At monami6 WG in 64th IETF meetinng, I submitted and presented two >> > Internet Drafts. >> > >> > - Analysis of multiple interfaces in a Mobile Node >> > >> > _http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt= _ >> > >> > - Virtual network interface for multiple interfaces in a Mobile node >> > using Mobile IPv6 >> > >> > _http://tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_ >> > >> > >> > Because these two drafts were not in the monami6 WG's scope and >> > virtual network interface draft was >> > >> > implementation specific, there were not adoped in monami6 WG's work >> > items. The intentions of two drafts >> > are supporting multiple interfaces of a host without extending Mobile >> > IPv6/NEMO. >> > >> > > >> > I think that multiple interfaces problems of a host are related to >> > both Mobile IP/NEMO specific issues and >> > general network issues. Mobile IP/NEMO specific issues are related to >> > extending of Mobile IP/NEMO and >> > these are already studied in MEXT WG and general network issues which >> > were not related to >> > Mobile IP/NEMO could be studied in mif. As same manner, I think that >> > my drafts could be discussed and >> > developed in mif. In the first draft (Analysis document), I classified >> > multiple interface problems into >> > Mobile IPv6-sepcific issues, General network issues, and heterogeneous >> > environment issues. >> > >> > > >> > Including Hui Deng in mif, with regarding to these drafts, they want >> > to hear comments from MEXT WG's point of view, >> > because it seems that these drafts are quite related to monami6/MEXT >> > WG. So, I ask MEXT to review whether there are >> > >> > some overlap between MEXT works and my drafts or not. >> > >> > It is appreciate to give comments. >> > >> > > >> > Best regards. >> > >> > Yong-Geun. >> > >> >> > --000e0cd28df260a2d204619c4e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Marcelo

For yoru question about what mif's scope at the moment, Jari already= made the comments on
http://www.ietf.org/mail-archive/web/mif/current/m= sg00050.html

There are also several PS drafts you could refer to:
http://too= ls.ietf.org/id/draft-blanchet-mif-problem-statement-00.txt
h= ttp://tools.ietf.org/id/draft-hui-ip-multiple-connections-ps-01.txt
http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.tx= t

thanks

-Hui

2009/1/29 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hi Hong,

what is the scop= e of MIF?
I mean, in the bof wiki page there is no charter proposed, is = there a charter somewhere?
In particular, is MIF going to work in MIPv6/NEMO related issues?

Re= gards, marcelo


Hong Yong-Geun escribi=C3=B3:
 Hi, Marcelo.
 Than= ks for your comments.
 I agree that  the current MEXT WG chart= er already has several items about supporting multiple interfaces.=20

 My documents are old version which were sub= mitted to monami6 WG at 64th IETF meeting and they were
not updated prop= erly. So, it seems that some contents are similar to the works in MEXT WG.<= br> I will update my documents to focus on mif's scope.
 It is appr= eciate to understand that (even though the scope of mif is not fixed) mif h= as different directions to
MEXT.
 Best regards.
 Yong-Geun.

-----= =EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80-----
*From:* "= marcelo bagnulo braun" <marcelo@it.uc3m.es>
*From Date:* 2009-01-28 =EC=98= =A4=ED=9B=84 6:40:09
*To:* "Hong Yong-Geun" <yghong@etri.re.kr>
*Cc:* "mext@ietf.org" <mext@ietf.org>, "mif@ietf.org" <mif@ietf.org>, "juli= en.laganier.IETF@googlemail.com" <julien.laganier.IETF@googlemail= .com>, "denghui02@gmail.com" <denghui02@gmail.com>
*Subject:* Re: Multiple interfaces problems in MEXT and mif=20



Hi,

In the current MEXT charter th= ere are several items about supporting
multiple interfaces, including th= e following two:

- A document explaining the motivations for a node = using multiple
interfaces and the scenarios where it may end up with multiple
global ad= dresses on its interfaces [Informational]

- An analysis document exp= laining what are the limitations for
mobile hosts using multiple simulta= neous Care-of Addresses and Home
Agent addresses using Mobile IPv6, whether issues are specific to
Mobile= IPv6 or not [Informational].

I think this is very similar to the sc= ope of one of you documents at
least, so i would find very strange that = the same work is chartered in
two different working groups.

Moreover, we do have wg documents for = these two, but we find very hard
to find reviewers for those, which make= s me think that there is not much
interest on these. So, if you find a m= ore motivated crew to do the work,
that would be great, we can either do it in mext or soemwhere else, if
p= eople feels that needs to be done, but that is certainly not the
feeling= i am getting from the input in mext

Regards, marcelo



Hong Yong-Geun escribi?:
>
> Hi, all in MEXT and mif.
&g= t;
> >
> In IETF mif (Multiple Interface) mailing list
&g= t; (_https://www.ietf.org/mailman/listinfo/mif_
> <https://www.ietf.org/mailman/listinfo/mif>),
>
> w= e now discuss the host which would like to use multiple interfaces.
>=
> I understand that MEXT WG is also related to the use of multiple
&g= t; interfaces of a host
> using Mobile IPv6 or a mobile router using = NEMO Basic Support and
> their variants
>
> MEXT WG is fo= cuing on monami6 related topic (multiple CoA, Multiple
> HoA, and Multple HA, etc.,)
> and extedning Mobile IPv6 and NEMO= for these, but mif is not related
> to this direction.
> In mi= f, source address selection, routing and DNS control protocol are
> c= onsideration items
> due to multiple interfaces of a host.
>
> >
> For= mif's scope, Jari Arkko made some comments and classification of
> p= roblems.
>
> _http://www.ietf.org/mail-archi= ve/web/mif/current/msg00050.html_
>
> Among these classification which includes access selection, sp= lit DNS,
> configuration reconciliation,
> routing, address sel= ection, tunnel multihoming, and the communication
> way between the h= ost and
> the network about their policies regarding all of the above, Jari said=
> that access selection is already
> coverd in RFC 5113 and tu= nnel multihoming is already covered in MEXT
> WG work items.
><= br> > >
> At monami6 WG in 64th IETF meetinng, I submitted and pres= ented two
> Internet Drafts.
>
> - Analysis of multiple i= nterfaces in a Mobile Node
>
> _http:= //tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt_
>
> - Virtual network interface for multiple interfaces in a Mobil= e node
> using Mobile IPv6
>
> _http://= tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_
> <http://tools.ietf.org/id/draft-hong-virtualif-mn-= mipv6-00.txt>
>
> Because these two drafts were not in t= he monami6 WG's scope and
> virtual network interface draft was
>
> implementation spe= cific, there were not adoped in monami6 WG's work
> items. The intent= ions of two drafts
> are supporting multiple interfaces of a host wit= hout extending Mobile
> IPv6/NEMO.
>
> >
> I think that multiple interfac= es problems of a host are related to
> both Mobile IP/NEMO specific i= ssues and
> general network issues. Mobile IP/NEMO specific issues ar= e related to
> extending of Mobile IP/NEMO and
> these are already studied in M= EXT WG and general network issues which
> were not related to
>= Mobile IP/NEMO could be studied in mif. As same manner, I think that
> my drafts could be discussed and
> developed in mif. In the firs= t draft (Analysis document), I classified
> multiple interface proble= ms into
> Mobile IPv6-sepcific issues, General network issues, and he= terogeneous
> environment issues.
>
> >
> Including Hui Deng in= mif, with regarding to these drafts, they want
> to hear comments fr= om MEXT WG's point of view,
> because it seems that these drafts are = quite related to monami6/MEXT
> WG. So, I ask MEXT to review whether there are
>
> some ov= erlap between MEXT works and my drafts or not.
>
> It is apprec= iate to give comments.
>
> >
> Best regards.
> > Yong-Geun.
>



--000e0cd28df260a2d204619c4e9a-- --===============1972730725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1972730725==-- From mif-bounces@ietf.org Thu Jan 29 02:14:02 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C8528C148; Thu, 29 Jan 2009 02:14:02 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F5D28C148 for ; Thu, 29 Jan 2009 02:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAp7Xxo6B4R9 for ; Thu, 29 Jan 2009 02:14:00 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 7A4C328C146 for ; Thu, 29 Jan 2009 02:14:00 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so8387734wfd.31 for ; Thu, 29 Jan 2009 02:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KmcpqgX1jriACvGa2UNB/OObKV+sAgY/rNwm3vDzJLI=; b=IzZA7a/0zoj464EIRjCPwpY2AXR42WtZ8WcMhIQm+eP/nF00oTJIqsLlAMRE2f99aP l3HeW8gU0o9gl86NgRKykUm7o0MSDJYwUhrE+y7tX5zHoirczhP4zPTc6mlEGOVP3nJJ H7Sy3HCVQVBur7z8mb1oz41JERUI6Bstw9gMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EHHyDYr9tiUbWax/4LF1s9CbXiReymSNplI+8TYdvlVrqXHfO6z2eMZ08kwdF5Jm8v 7coehlHfgAuy4jPFZ3xdSaU1RmBPa8suEDnuocmFDfjp7Xs6XwllkONqrdGLPGjBrnwC U57irCTImEk2AzjwBIhLK04S3vYyH4sTAoJak= MIME-Version: 1.0 Received: by 10.142.103.2 with SMTP id a2mr510599wfc.164.1233224021987; Thu, 29 Jan 2009 02:13:41 -0800 (PST) In-Reply-To: <776469.29263.qm@web111411.mail.gq1.yahoo.com> References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> <1d38a3350901280856p633bee5pc98c5ed95d996dfa@mail.gmail.com> <776469.29263.qm@web111411.mail.gq1.yahoo.com> Date: Thu, 29 Jan 2009 18:13:41 +0800 Message-ID: <1d38a3350901290213q146a6a94v6f0aceeb126bac6f@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Cc: mif@ietf.org Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160596399==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1160596399== Content-Type: multipart/alternative; boundary=00504502cb58c251b304619c5709 --00504502cb58c251b304619c5709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Behcet, Thanks for your question, there are several proposals at the moment: http://tools.ietf.org/id/draft-savolainen-6man-fqdn-based-if-selection-00.t= xt http://tools.ietf.org/id/draft-hui-ip-multiple-connections-01.txt Regards, -Hui 2009/1/29 Behcet Sarikaya > Hi Hui, > See my question below. > > Regards, > > Behcet > > ------------------------------ > *From:* Hui Deng > *To:* pierrick.seite@orange-ftgroup.com > *Cc:* mif@ietf.org > *Sent:* Wednesday, January 28, 2009 10:56:48 AM > *Subject:* Re: [mif] One general issue on MIF > > I agree Pierrick's opinion here, it is more local policy implementaion > issue, > MIF is only working on transfer some network policy to the local policy > repository. > this repository may be used between application and socket api interface. > > [behcet] What type of protocol will be used for this purpose? > > thanks > > -Hui > > 2009/1/28 > >> Hi Kai, >> >> >> >> Please see my opinion inline. >> >> >> >> Regards, >> >> Pierrick >> >> >> ------------------------------ >> >> *De :* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *De la part de= *Kai Ju >> *Envoy=E9 :* mercredi 28 janvier 2009 04:22 >> *=C0 :* mif >> *Objet :* [mif] One general issue on MIF >> >> >> >> Hi, All >> >> >> >> Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese >> Spring Festival, and good luck for whole new year. >> >> >> >> I got one issue which maybe would raise a fundamental question on MIF, a= nd >> it has confused me for days. >> >> >> >> If host has WLan connection, and user wanna start one application on it, >> because Wlan provided by ISP is free. But the policy which host has got = from >> network forbid it on Wlan. When they're conflict between the policy and >> user's willing, how should MIF do? Ignor user's willing, choose another >> interface according the policy? Or change the >> >> policy, do what the user wanna do? >> >> >> >> So, the question is policy and user's willing, who get the higher >> priority? >> >> >> >> [PS] IMO, it is an implementation issue. Some operators are thinking tha= t >> the final decision is made on the user preferences except if cannot appl= y >> (e.g. preferred access overloaded making it impossible to use); but it's= not >> the only way to do. >> >> >> >> BRG >> >> >> >> Kai >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > > --00504502cb58c251b304619c5709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Behcet,
 
Thanks for your question,
there are several proposals at the moment:
 
Regards,
 
-Hui

2009/1/29 Behcet Sarikaya <= behcetsarikaya@yahoo.com>= ;
Hi Hui,
  See my question below.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com&g= t;
To: pierrick.seite@orange= -ftgroup.com
Cc: mif@ietf.org
Sent: Wednesday, January 28, 2009 10:56:48 AM
Subject: Re: [mif] One general is= sue on MIF

I agree Pierrick's opinion here, it is more local policy implement= aion issue,
MIF is only working on transfer some network policy to the local polic= y repository.
this repository may be used between application and socket api interfa= ce.
 
[behcet] What type of protocol will be used fo= r this purpose?
 
thanks
 
-Hui

2009/1/28 <pie= rrick.seite@orange-ftgroup.com>

Hi Kai,

 =

Please see my opinio= n inline.

 =

Regards,

Pierrick

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Kai Ju
Envoy=E9 : mercredi 28= janvier 2009 04:22
=C0 : mif
Objet : = [mif] One general issue on MIF

 

[PS] IMO, it is an i= mplementation issue. Some operators are thinking that the final decision is= made on the user preferences except if cannot apply (e.g. preferred access= overloaded making it impossible to use); but it's not the only way to = do.

 




--00504502cb58c251b304619c5709-- --===============1160596399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1160596399==-- From mif-bounces@ietf.org Thu Jan 29 02:17:32 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769A23A69C3; Thu, 29 Jan 2009 02:17:32 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542073A69C3; Thu, 29 Jan 2009 02:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2m2VstPhhHN; Thu, 29 Jan 2009 02:17:30 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B3DC63A6359; Thu, 29 Jan 2009 02:17:29 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n0TAH1K9001986; Thu, 29 Jan 2009 11:17:01 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n0TAH1fg019122; Thu, 29 Jan 2009 11:17:01 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n0TAH05J015880; Thu, 29 Jan 2009 11:17:00 +0100 Message-ID: <4981821C.1030808@gmail.com> Date: Thu, 29 Jan 2009 11:17:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hong Yong-Geun References: <545501c981ba$8155e500$8310fe81@etri.info> In-Reply-To: <545501c981ba$8155e500$8310fe81@etri.info> Cc: marcelo bagnulo braun , mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org SG9uZyBZb25nLUdldW4gYSDDqWNyaXQgOgpbLi4uXQo+IEl0IGlzIGFwcHJlY2lhdGUgdG8gdW5k ZXJzdGFuZCB0aGF0IChldmVuIHRob3VnaCB0aGUgc2NvcGUgb2YgbWlmIGlzIAo+IG5vdCBmaXhl ZCkgbWlmIGhhcyBkaWZmZXJlbnQgZGlyZWN0aW9ucyB0byBNRVhULgoKRG8gdGhlICdETlMgY29u dHJvbCBwcm90b2NvbCcgZGlyZWN0aW9ucyBtZW50aW9uZWQgaW4gTUlGIGRpZmZlciBzb21laG93 CmZyb20gdGhlIGV4aXN0aW5nIE1FWFQgbW9uYW1pNi1pbmhlcml0ZWQgZGlyZWN0aW9ucz8gIERv ZXMgTUVYVCBhZGRyZXNzCidETlMgY29udHJvbCBwcm90b2NvbCcgd2hlbiBtdWx0aXBsZS1pbnRl cmZhY2VzLWluLWEtaG9zdCBhcmUgaW52b2x2ZWQ/CgpBbGV4Cgo+IAo+IEJlc3QgcmVnYXJkcy4K PiAKPiBZb25nLUdldW4uCj4gCj4gLS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS0gKkZyb206KiAi bWFyY2VsbyBiYWdudWxvIGJyYXVuIiA8bWFyY2Vsb0BpdC51YzNtLmVzPgo+ICAqRnJvbSBEYXRl OiogMjAwOS0wMS0yOCDsmKTtm4QgNjo0MDowOSAqVG86KiAiSG9uZyBZb25nLUdldW4iIAo+IDx5 Z2hvbmdAZXRyaS5yZS5rcj4gKkNjOiogIm1leHRAaWV0Zi5vcmciIDxtZXh0QGlldGYub3JnPiwg Cj4gIm1pZkBpZXRmLm9yZyIgPG1pZkBpZXRmLm9yZz4sICJqdWxpZW4ubGFnYW5pZXIuSUVURkBn b29nbGVtYWlsLmNvbSIgCj4gPGp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tPiwg ImRlbmdodWkwMkBnbWFpbC5jb20iIAo+IDxkZW5naHVpMDJAZ21haWwuY29tPiAqU3ViamVjdDoq IFJlOiBNdWx0aXBsZSBpbnRlcmZhY2VzIHByb2JsZW1zIGluIAo+IE1FWFQgYW5kIG1pZgo+IAo+ IAo+IEhpLAo+IAo+IEluIHRoZSBjdXJyZW50IE1FWFQgY2hhcnRlciB0aGVyZSBhcmUgc2V2ZXJh bCBpdGVtcyBhYm91dCBzdXBwb3J0aW5nCj4gIG11bHRpcGxlIGludGVyZmFjZXMsIGluY2x1ZGlu ZyB0aGUgZm9sbG93aW5nIHR3bzoKPiAKPiAtIEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90 aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBtdWx0aXBsZSAKPiBpbnRlcmZhY2VzIGFuZCB0aGUg c2NlbmFyaW9zIHdoZXJlIGl0IG1heSBlbmQgdXAgd2l0aCBtdWx0aXBsZSBnbG9iYWwKPiAgYWRk cmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJbmZvcm1hdGlvbmFsXQo+IAo+IC0gQW4gYW5hbHlz aXMgZG9jdW1lbnQgZXhwbGFpbmluZyB3aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMgZm9yIG1vYmls ZQo+ICBob3N0cyB1c2luZyBtdWx0aXBsZSBzaW11bHRhbmVvdXMgQ2FyZS1vZiBBZGRyZXNzZXMg YW5kIEhvbWUgQWdlbnQgCj4gYWRkcmVzc2VzIHVzaW5nIE1vYmlsZSBJUHY2LCB3aGV0aGVyIGlz c3VlcyBhcmUgc3BlY2lmaWMgdG8gTW9iaWxlIAo+IElQdjYgb3Igbm90IFtJbmZvcm1hdGlvbmFs XS4KPiAKPiBJIHRoaW5rIHRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBzY29wZSBvZiBvbmUg b2YgeW91IGRvY3VtZW50cyBhdAo+ICBsZWFzdCwgc28gaSB3b3VsZCBmaW5kIHZlcnkgc3RyYW5n ZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIAo+IGluIHR3byBkaWZmZXJlbnQgd29y a2luZyBncm91cHMuCj4gCj4gTW9yZW92ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0 aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZlcnkgCj4gaGFyZCB0byBmaW5kIHJldmlld2VycyBmb3Ig dGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhlcmUgaXMgCj4gbm90IG11Y2ggaW50 ZXJlc3Qgb24gdGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8g Cj4gZG8gdGhlIHdvcmssIHRoYXQgd291bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQg aW4gbWV4dCBvciAKPiBzb2Vtd2hlcmUgZWxzZSwgaWYgcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMg dG8gYmUgZG9uZSwgYnV0IHRoYXQgaXMgCj4gY2VydGFpbmx5IG5vdCB0aGUgZmVlbGluZyBpIGFt IGdldHRpbmcgZnJvbSB0aGUgaW5wdXQgaW4gbWV4dAo+IAo+IFJlZ2FyZHMsIG1hcmNlbG8KPiAK PiAKPiAKPiBIb25nIFlvbmctR2V1biBlc2NyaWJpPzoKPj4gCj4+IEhpLCBhbGwgaW4gTUVYVCBh bmQgbWlmLgo+PiAKPj4gCj4+IAo+PiBJbiBJRVRGIG1pZiAoTXVsdGlwbGUgSW50ZXJmYWNlKSBt YWlsaW5nIGxpc3QgCj4+IChfaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t aWZfIAo+PiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY+KSwKPj4g Cj4+IHdlIG5vdyBkaXNjdXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRp cGxlIAo+PiBpbnRlcmZhY2VzLgo+PiAKPj4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBh bHNvIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZSAKPj4gaW50ZXJmYWNlcyBvZiBhIGhv c3QgdXNpbmcgTW9iaWxlIElQdjYgb3IgYSBtb2JpbGUgcm91dGVyIHVzaW5nIAo+PiBORU1PIEJh c2ljIFN1cHBvcnQgYW5kIHRoZWlyIHZhcmlhbnRzCj4+IAo+PiBNRVhUIFdHIGlzIGZvY3Vpbmcg b24gbW9uYW1pNiByZWxhdGVkIHRvcGljIChtdWx0aXBsZSBDb0EsIE11bHRpcGxlCj4+ICBIb0Es IGFuZCBNdWx0cGxlIEhBLCBldGMuLCkgYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVN TyBmb3IKPj4gIHRoZXNlLCBidXQgbWlmIGlzIG5vdCByZWxhdGVkIHRvIHRoaXMgZGlyZWN0aW9u LiBJbiBtaWYsIHNvdXJjZSAKPj4gYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBj b250cm9sIHByb3RvY29sIGFyZSAKPj4gY29uc2lkZXJhdGlvbiBpdGVtcyBkdWUgdG8gbXVsdGlw bGUgaW50ZXJmYWNlcyBvZiBhIGhvc3QuCj4+IAo+PiAKPj4gCj4+IEZvciBtaWbigJlzIHNjb3Bl LCBKYXJpIEFya2tvIG1hZGUgc29tZSBjb21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24gCj4+IG9m IHByb2JsZW1zLgo+PiAKPj4gX2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9t aWYvY3VycmVudC9tc2cwMDA1MC5odG1sXwo+PiAKPj4gQW1vbmcgdGhlc2UgY2xhc3NpZmljYXRp b24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgCj4+IEROUywgY29uZmln dXJhdGlvbiByZWNvbmNpbGlhdGlvbiwgcm91dGluZywgYWRkcmVzcyBzZWxlY3Rpb24sIAo+PiB0 dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbiB3YXkgYmV0d2VlbiB0aGUg aG9zdCBhbmQKPj4gIHRoZSBuZXR3b3JrIGFib3V0IHRoZWlyIHBvbGljaWVzIHJlZ2FyZGluZyBh bGwgb2YgdGhlIGFib3ZlLCBKYXJpIAo+PiBzYWlkIHRoYXQgYWNjZXNzIHNlbGVjdGlvbiBpcyBh bHJlYWR5IGNvdmVyZCBpbiBSRkMgNTExMyBhbmQgdHVubmVsCj4+ICBtdWx0aWhvbWluZyBpcyBh bHJlYWR5IGNvdmVyZWQgaW4gTUVYVCBXRyB3b3JrIGl0ZW1zLgo+PiAKPj4gCj4+IAo+PiBBdCBt b25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0aW5uZywgSSBzdWJtaXR0ZWQgYW5kIHByZXNlbnRl ZCB0d28KPj4gIEludGVybmV0IERyYWZ0cy4KPj4gCj4+IC0gQW5hbHlzaXMgb2YgbXVsdGlwbGUg aW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlCj4+IAo+PiBfaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1wYi1zdGF0ZW1lbnQtMDAudHh0Xwo+PiAKPj4g Cj4+IAo+PiAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFj ZXMgaW4gYSBNb2JpbGUgCj4+IG5vZGUgdXNpbmcgTW9iaWxlIElQdjYKPj4gCj4+IF9odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYtbW4tbWlwdjYtMDAudHh0XyAK Pj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1tbi1taXB2 Ni0wMC50eHQ+Cj4+IAo+PiBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhl IG1vbmFtaTYgV0figJlzIHNjb3BlIGFuZCAKPj4gdmlydHVhbCBuZXR3b3JrIGludGVyZmFjZSBk cmFmdCB3YXMKPj4gCj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCB0aGVyZSB3ZXJlIG5vdCBh ZG9wZWQgaW4gbW9uYW1pNiBXR+KAmXMgd29yawo+PiAgaXRlbXMuIFRoZSBpbnRlbnRpb25zIG9m IHR3byBkcmFmdHMgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgCj4+IGludGVyZmFjZXMgb2YgYSBo b3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZSBJUHY2L05FTU8uCj4+IAo+PiAKPj4gCj4+IEkg dGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2VzIHByb2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVs YXRlZCB0bwo+PiAgYm90aCBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYW5kIGdlbmVy YWwgbmV0d29yayBpc3N1ZXMuIAo+PiBNb2JpbGUgSVAvTkVNTyBzcGVjaWZpYyBpc3N1ZXMgYXJl IHJlbGF0ZWQgdG8gZXh0ZW5kaW5nIG9mIE1vYmlsZSAKPj4gSVAvTkVNTyBhbmQgdGhlc2UgYXJl IGFscmVhZHkgc3R1ZGllZCBpbiBNRVhUIFdHIGFuZCBnZW5lcmFsIAo+PiBuZXR3b3JrIGlzc3Vl cyB3aGljaCB3ZXJlIG5vdCByZWxhdGVkIHRvIE1vYmlsZSBJUC9ORU1PIGNvdWxkIGJlIAo+PiBz dHVkaWVkIGluIG1pZi4gQXMgc2FtZSBtYW5uZXIsIEkgdGhpbmsgdGhhdCBteSBkcmFmdHMgY291 bGQgYmUgCj4+IGRpc2N1c3NlZCBhbmQgZGV2ZWxvcGVkIGluIG1pZi4gSW4gdGhlIGZpcnN0IGRy YWZ0IChBbmFseXNpcyAKPj4gZG9jdW1lbnQpLCBJIGNsYXNzaWZpZWQgbXVsdGlwbGUgaW50ZXJm YWNlIHByb2JsZW1zIGludG8gTW9iaWxlIAo+PiBJUHY2LXNlcGNpZmljIGlzc3VlcywgR2VuZXJh bCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVvdXMgCj4+IGVudmlyb25tZW50IGlzc3Vl cy4KPj4gCj4+IAo+PiAKPj4gSW5jbHVkaW5nIEh1aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRp bmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5IAo+PiB3YW50IHRvIGhlYXIgY29tbWVudHMgZnJvbSBN RVhUIFdH4oCZcyBwb2ludCBvZiB2aWV3LCBiZWNhdXNlIGl0IAo+PiBzZWVtcyB0aGF0IHRoZXNl IGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01FWFQgV0cuIFNvLCBJCj4+ICBh c2sgTUVYVCB0byByZXZpZXcgd2hldGhlciB0aGVyZSBhcmUKPj4gCj4+IHNvbWUgb3ZlcmxhcCBi ZXR3ZWVuIE1FWFQgd29ya3MgYW5kIG15IGRyYWZ0cyBvciBub3QuCj4+IAo+PiBJdCBpcyBhcHBy ZWNpYXRlIHRvIGdpdmUgY29tbWVudHMuCj4+IAo+PiAKPj4gCj4+IEJlc3QgcmVnYXJkcy4KPj4g Cj4+IFlvbmctR2V1bi4KPj4gCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gCj4gCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gbWlmIG1haWxpbmcg bGlzdCAKPiBtaWZAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9taWYKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpt aWYgbWFpbGluZyBsaXN0Cm1pZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21pZgo= From mif-bounces@ietf.org Thu Jan 29 02:35:13 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DC33A68F7; Thu, 29 Jan 2009 02:35:13 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287423A6835 for ; Thu, 29 Jan 2009 02:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9PIBLLLp5Uk for ; Thu, 29 Jan 2009 02:35:11 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id BD80A3A68F7 for ; Thu, 29 Jan 2009 02:35:11 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so8395423wfd.31 for ; Thu, 29 Jan 2009 02:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yTwCHDabEOsXLibiQ3MxFaB7riIN1mSJi3mc6R0Xkto=; b=jlRnqAw+jemOpyTi5SuryKVtk1SKgJQTLx1oObCTmm4sYKnzuczC2CQW/YgkdOzPqX BxI/yJPo3jogzDU8/PP+gMXHe5pndydOZKKEta5yCKwCUpz4cZHPLr4qCyMNwT4RLd+w puznM0PmMs/32Hd91Wkb7jjkJHEELqbVKD8G4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FoDay5zo3JxoFNWfEWog0vZp22KOzE8clHo7tAIyShSWbdvh15RQb6Ng6IQ9zUwzBX zcLoadCYWJrqfLvSfiLOLat3Pw5+pi1i8jzlpq3/DmQh4Ir8a3RNaeJYbhl5e3FnCvlk LqXxRDsE21x2kK+tV44+TpJM9pgSjAUGiWLTM= MIME-Version: 1.0 Received: by 10.142.166.2 with SMTP id o2mr185434wfe.312.1233225293371; Thu, 29 Jan 2009 02:34:53 -0800 (PST) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4@NOK-EUMSG-01.mgdnok.nokia.com> References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 29 Jan 2009 18:34:53 +0800 Message-ID: <1d38a3350901290234r4698a6f4h7a0a188f799e54ad@mail.gmail.com> From: Hui Deng To: teemu.savolainen@nokia.com Cc: mif@ietf.org Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314830817==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1314830817== Content-Type: multipart/alternative; boundary=000e0cd32cf68a1b9504619ca380 --000e0cd32cf68a1b9504619ca380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Teemu, I would like to append more based on your three categorization. 1) for ISP subsidized , policy works 2) for corporation owned, policy together with ISP should also work. 3) for user owned, policy recommend better way to do, and user can change, anyhow, policy should be first position to consider, so policy works again if user is not able to change it. summary all these 3 cases, configured policy will all works. For your first part, wondering whether MIF is suitable for tools? Since iet= f more focus on the protocol, anyhow protocol will influence those tools finally. thanks -Hui 2009/1/29 > Hi, > > All existing devices do solve the complex multi-interface problem by some > means, but probably not perfectly. > > I think managing to standardize tools that help those current > implementation-specific solutions work better, e.g. with less > user-interaction, with better default behaviour, with better and faster > fall-backs or having better selection between "otherwise-equal" interface= s > etc. would be a good achievement for mif. I mean to work on standardizing > tools and issues that can and should be standardized here, and leave the > rest out. > > In the policy conflict case mentioned below I think it depends, e.g.: > - if the device is ISP subsidized (e.g. "rented"), ISP's policy could for= ce > the device to behave exactly as ISP policy says, even if user would prefe= r > free WLAN available nearby. The ISP likely is able to configure the devic= e > to behave this way by non-IETF means. > - similarly, if device is corporation managed & owned, corporation would > probably want to be able to force device to do exactly as corporation pol= icy > says, even if user would prefer faster WLAN (the cost might not matter so > much in this case). The corporation is likely able to configure device th= is > way by non-IETF means. > - however, if the device is user owned and user managed, user probably > would like to have full control on which interface is used, and e.g. have > ways to prioritize expensive (for user) connetions to low (and rather hav= e > lower QoS, longer transport paths, than higher prize) . And the user shou= ld > have this possibly available - even if by default device would follow e.g= . > received ISP's policies in order to provide easy user experience for thos= e > people who don't want to hear about any configuration issues > > Best regards, > > Teemu > > ------------------------------ > *From:* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *On Behalf Of = *ext > pierrick.seite@orange-ftgroup.com > *Sent:* 28 January, 2009 10:18 > *To:* jukai.zte@gmail.com; mif@ietf.org > *Subject:* Re: [mif] One general issue on MIF > > Hi Kai, > > > > Please see my opinion inline. > > > > Regards, > > Pierrick > > > ------------------------------ > > *De :* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *De la part de*= Kai Ju > *Envoy=E9 :* mercredi 28 janvier 2009 04:22 > *=C0 :* mif > *Objet :* [mif] One general issue on MIF > > > > Hi, All > > > > Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese > Spring Festival, and good luck for whole new year. > > > > I got one issue which maybe would raise a fundamental question on MIF, an= d > it has confused me for days. > > > > If host has WLan connection, and user wanna start one application on it, > because Wlan provided by ISP is free. But the policy which host has got f= rom > network forbid it on Wlan. When they're conflict between the policy and > user's willing, how should MIF do? Ignor user's willing, choose another > interface according the policy? Or change the > > policy, do what the user wanna do? > > > > So, the question is policy and user's willing, who get the higher priorit= y > ? > > > > [PS] IMO, it is an implementation issue. Some operators are thinking that > the final decision is made on the user preferences except if cannot apply > (e.g. preferred access overloaded making it impossible to use); but it's = not > the only way to do. > > > > BRG > > > > Kai > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd32cf68a1b9504619ca380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Teemu,
 
I would like to append more based on your three categorization.
1) for  ISP subsidized , policy works
2) for corporation owned, policy together with= ISP should also work.
3) for user owned, policy recommend better way= to do, and user can change, anyhow, policy should be first position to con= sider, so policy works again if user is not able to change it.
summary all these 3 cases, configured policy w= ill all works.
 
For your first part, wondering whether MIF is = suitable for tools? Since ietf more focus on the protocol, anyhow prot= ocol will influence those tools finally.
 
thanks
 
-Hui

 

 


2009/1/29 <teemu.savolainen@nokia.com>
Hi,
 
All existing devices do solve the complex multi-interface prob= lem by some means, but probably not perfectly.
 
I think managing to standardize tools that help those current = implementation-specific solutions work better, e.g. with less user-interact= ion, with better default behaviour, with better and faster fall-backs or ha= ving better selection between "otherwise-equal" interfaces etc. w= ould be a good achievement for mif. I mean to work on standardizing tools a= nd issues that can and should be standardized here, and leave the rest out.=
 
In the policy conflict case mentioned below I think it depends= , e.g.:
- if the device is ISP subsidized (e.g. "rented"),&n= bsp;ISP's policy could force the device to behave exactly as ISP policy= says, even if user would prefer free WLAN available nearby. The ISP likely= is able to configure the device to behave this way by non-IETF means.
- similarly, if device is corporation managed & owned,&nbs= p;corporation would probably want to be able to force device to do exactly = as corporation policy says, even if user would prefer faster WLAN (the cost= might not matter so much in this case). The corporation is likely able to = configure device this way by non-IETF means.
- however, if the device is user owned and user managed, = user probably would like to have full control on which interface is used, a= nd e.g. have ways to prioritize expensive (for user) connetions to low (and= rather have lower QoS, longer transport paths, than higher prize) . And th= e user should have this possibly available - even if by default device woul= d follow e.g. received ISP's policies in order to provide easy user exp= erience for those people who don't want to hear about any configuration= issues
 
Best regards,
 
    Teemu

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] O= n Behalf Of ext pierrick.seite@orange-ftgroup.com
Sent: 28 January, 2009 10:18
To: jukai.zte@gmail.com; mif@ietf.org
Subject: Re: [mi= f] One general issue on MIF

Hi Kai,

 =

Please see my opinio= n inline.

 =

Regards,

Pierrick

 =

De : mif-bounces@iet= f.org [mailto:mif-bounces@ietf.org] De la part = de Kai Ju
Envoy=E9 : mercredi 28= janvier 2009 04:22
=C0 : mif
Objet : = [mif] One general issue on MIF

 

[PS] IMO, it is an i= mplementation issue. Some operators are thinking that the final decision is= made on the user preferences except if cannot apply (e.g. preferred access= overloaded making it impossible to use); but it's not the only way to = do.

 


--000e0cd32cf68a1b9504619ca380-- --===============1314830817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1314830817==-- From mif-bounces@ietf.org Thu Jan 29 02:43:00 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74643A6914; Thu, 29 Jan 2009 02:43:00 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078013A6914 for ; Thu, 29 Jan 2009 02:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HbUyhANkCZZ for ; Thu, 29 Jan 2009 02:42:58 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AE9CE3A6359 for ; Thu, 29 Jan 2009 02:42:53 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0TAg5N1024893; Thu, 29 Jan 2009 12:42:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 12:42:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 12:42:18 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 29 Jan 2009 11:42:18 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 29 Jan 2009 11:42:17 +0100 From: To: Date: Thu, 29 Jan 2009 11:41:54 +0100 Thread-Topic: [mif] One general issue on MIF Thread-Index: AcmB/Us0hoXNz30UQIKBx5un8+KIgQAAJGyw Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E86177DD@NOK-EUMSG-01.mgdnok.nokia.com> References: <3db7b9d60901271922oc1944fag247e83840f1dad79@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E86176C4@NOK-EUMSG-01.mgdnok.nokia.com> <1d38a3350901290234r4698a6f4h7a0a188f799e54ad@mail.gmail.com> In-Reply-To: <1d38a3350901290234r4698a6f4h7a0a188f799e54ad@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2009 10:42:18.0600 (UTC) FILETIME=[4203EE80:01C981FE] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] One general issue on MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1321438915==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============1321438915== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86177DDNOKEUMSG01mgd_" --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86177DDNOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, I agree on those. I ment MIF is a part, a tool, of the greater system. Best regards, Teemu ________________________________ From: ext Hui Deng [mailto:denghui02@gmail.com] Sent: 29 January, 2009 12:35 To: Savolainen Teemu (Nokia-D-MSW/Tampere) Cc: pierrick.seite@orange-ftgroup.com; jukai.zte@gmail.com; mif@ietf.org Subject: Re: [mif] One general issue on MIF Hi, Teemu, I would like to append more based on your three categorization. 1) for ISP subsidized , policy works 2) for corporation owned, policy together with ISP should also work. 3) for user owned, policy recommend better way to do, and user can change, = anyhow, policy should be first position to consider, so policy works again = if user is not able to change it. summary all these 3 cases, configured policy will all works. For your first part, wondering whether MIF is suitable for tools? Since iet= f more focus on the protocol, anyhow protocol will influence those tools fi= nally. thanks -Hui 2009/1/29 > Hi, All existing devices do solve the complex multi-interface problem by some m= eans, but probably not perfectly. I think managing to standardize tools that help those current implementatio= n-specific solutions work better, e.g. with less user-interaction, with bet= ter default behaviour, with better and faster fall-backs or having better s= election between "otherwise-equal" interfaces etc. would be a good achievem= ent for mif. I mean to work on standardizing tools and issues that can and = should be standardized here, and leave the rest out. In the policy conflict case mentioned below I think it depends, e.g.: - if the device is ISP subsidized (e.g. "rented"), ISP's policy could force= the device to behave exactly as ISP policy says, even if user would prefer= free WLAN available nearby. The ISP likely is able to configure the device= to behave this way by non-IETF means. - similarly, if device is corporation managed & owned, corporation would pr= obably want to be able to force device to do exactly as corporation policy = says, even if user would prefer faster WLAN (the cost might not matter so m= uch in this case). The corporation is likely able to configure device this = way by non-IETF means. - however, if the device is user owned and user managed, user probably woul= d like to have full control on which interface is used, and e.g. have ways = to prioritize expensive (for user) connetions to low (and rather have lower= QoS, longer transport paths, than higher prize) . And the user should have= this possibly available - even if by default device would follow e.g. rece= ived ISP's policies in order to provide easy user experience for those peop= le who don't want to hear about any configuration issues Best regards, Teemu ________________________________ From: mif-bounces@ietf.org [mailto:mif-bounces= @ietf.org] On Behalf Of ext pierrick.seite@ora= nge-ftgroup.com Sent: 28 January, 2009 10:18 To: jukai.zte@gmail.com; mif@ietf.org Subject: Re: [mif] One general issue on MIF Hi Kai, Please see my opinion inline. Regards, Pierrick ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@= ietf.org] De la part de Kai Ju Envoy=E9 : mercredi 28 janvier 2009 04:22 =C0 : mif Objet : [mif] One general issue on MIF Hi, All Firstly, allow me wish everyone in MIF Discussion a magnificent Chinese Spr= ing Festival, and good luck for whole new year. I got one issue which maybe would raise a fundamental question on MIF, and = it has confused me for days. If host has WLan connection, and user wanna start one application on it, be= cause Wlan provided by ISP is free. But the policy which host has got from = network forbid it on Wlan. When they're conflict between the policy and use= r's willing, how should MIF do? Ignor user's willing, choose another interf= ace according the policy? Or change the policy, do what the user wanna do? So, the question is policy and user's willing, who get the higher priority? [PS] IMO, it is an implementation issue. Some operators are thinking that t= he final decision is made on the user preferences except if cannot apply (e= .g. preferred access overloaded making it impossible to use); but it's not = the only way to do. BRG Kai _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86177DDNOKEUMSG01mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Hui,
 
I agree on those. I ment MIF is a part, a=20 tool, of the greater system.
 
Best regards,
 
  &n= bsp; Teemu

From: ext Hui Deng=20 [mailto:denghui02@gmail.com]
Sent: 29 January, 2009=20 12:35
To: Savolainen Teemu (Nokia-D-MSW/Tampere)
Cc:= =20 pierrick.seite@orange-ftgroup.com; jukai.zte@gmail.com;=20 mif@ietf.org
Subject: Re: [mif] One general issue on=20 MIF

Hi, Teemu,
 
I would like to append more based on your three categorization.
1) for  ISP subsidized , policy=20 works
2) for corporation owned, policy together with= ISP=20 should also work.
3) for user owned, policy recommend better way= to do,=20 and user can change, anyhow, policy should be first position to consider,= so=20 policy works again if user is not able to change it.
summary all these 3 cases, configured policy w= ill all=20 works.
 
For your first part, wondering whether MIF is= =20 suitable for tools? Since ietf more focus on the protocol, anyhow=20 protocol will influence those tools finally.
 
thanks
 
-Hui

 

 


2009/1/29 <teemu.savolainen@nokia.com= >
Hi,
 
All=20 existing devices do solve the complex multi-interface problem by some m= eans,=20 but probably not perfectly.
 
I think=20 managing to standardize tools that help those current=20 implementation-specific solutions work better, e.g. with less=20 user-interaction, with better default behaviour, with better and faster= =20 fall-backs or having better selection between "otherwise-equal" interfa= ces=20 etc. would be a good achievement for mif. I mean to work on standardizi= ng=20 tools and issues that can and should be standardized here, and leave th= e=20 rest out.
 
In the=20 policy conflict case mentioned below I think it depends,=20 e.g.:
- if the=20 device is ISP subsidized (e.g. "rented"), ISP's policy could force= the=20 device to behave exactly as ISP policy says, even if user would prefer = free=20 WLAN available nearby. The ISP likely is able to configure the device t= o=20 behave this way by non-IETF means.
-=20 similarly, if device is corporation managed & owned, corporati= on=20 would probably want to be able to force device to do exactly as corpora= tion=20 policy says, even if user would prefer faster WLAN (the cost might not= =20 matter so much in this case). The corporation is likely able to configu= re=20 device this way by non-IETF means.
-=20 however, if the device is user owned and user managed, user probab= ly=20 would like to have full control on which interface is used, and e.g. ha= ve=20 ways to prioritize expensive (for user) connetions to low (and rather h= ave=20 lower QoS, longer transport paths, than higher prize) . And the user sh= ould=20 have this possibly available - even if by default device would follow e= .g.=20 received ISP's policies in order to provide easy user experience for th= ose=20 people who don't want to hear about any configuration=20 issues
 
Best=20 regards,
 
    Teemu

From: mif-bounces@ietf= .org=20 [mailto:mif-bounces@ietf.org] On Behalf Of ext pierrick.seite@orange-ftgroup.com
Sent:= 28=20 January, 2009 10:18
To: jukai.zte@gmail.com; mif@ietf.org
Subject: Re: [mif] One gen= eral=20 issue on MIF

Hi=20 Kai,

 

Please see= my=20 opinion inline.

 

Regards,

Pierrick

 

De&= nbsp;: mif-bounces@ietf= .org=20 [mailto:mif-bounces@ietf.org] De la part de Kai Ju
Envoy=E9 : mercredi 28 ja= nvier=20 2009 04:22
=C0 :<= /B>=20 mif
Objet : [= mif]=20 One general issue on MIF

 

Hi,=20 All

 

Firstly, allow me wish everyone in MIF Disc= ussion=20 a magnificent Chinese Spring Festival, and good luck for whole n= ew=20 year.

 

I got=20 one issue which maybe would raise a fundamental question on MIF, and = it=20 has confused me for days.

 

If host has WLan connection, and user = wanna=20 start one application on it, because Wlan provided by ISP is free. Bu= t the=20 policy which host has got from network forbid it on Wlan.=20 When they're conflict between the policy and user's willing, how= =20 should MIF do? Ignor user's willing, choose another interface accordi= ng=20 the policy? Or change the

policy, do what the user wanna do?=20

 

So,=20 the question is policy and user's willing, who get the higher=20 priority?

 

[PS] IMO, = it is=20 an implementation issue. Some operators are thinking that the final=20 decision is made on the user preferences except if cannot apply (e.g.= =20 preferred access overloaded making it impossible to use); but it's no= t the=20 only way to do.

 

BRG

 

Kai


____________________________________________= ___
mif=20 mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif


--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86177DDNOKEUMSG01mgd_-- --===============1321438915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============1321438915==-- From mif-bounces@ietf.org Thu Jan 29 12:04:30 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED18228C0E0; Thu, 29 Jan 2009 12:04:30 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940EB3A6974; Thu, 29 Jan 2009 12:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDhZjAuNn6cg; Thu, 29 Jan 2009 12:04:28 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EBDCF3A69DD; Thu, 29 Jan 2009 12:04:27 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 13AB629E1552; Thu, 29 Jan 2009 15:04:09 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 8F41629E14EE; Thu, 29 Jan 2009 15:04:07 -0500 (EST) Message-ID: <49820BB6.9070405@viagenie.ca> Date: Thu, 29 Jan 2009 15:04:06 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> In-Reply-To: <498027F9.8050604@it.uc3m.es> X-Enigmail-Version: 0.95.7 Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org bWFyY2VsbyBiYWdudWxvIGJyYXVuIGEgw6ljcml0IDoKPiBIaSwKPiAKPiBJbiB0aGUgY3VycmVu dCBNRVhUIGNoYXJ0ZXIgdGhlcmUgYXJlIHNldmVyYWwgaXRlbXMgYWJvdXQgc3VwcG9ydGluZwo+ IG11bHRpcGxlIGludGVyZmFjZXMsIGluY2x1ZGluZyB0aGUgZm9sbG93aW5nIHR3bzoKPiAKPiAt IEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBt dWx0aXBsZQo+IGludGVyZmFjZXMgYW5kIHRoZSBzY2VuYXJpb3Mgd2hlcmUgaXQgbWF5IGVuZCB1 cCB3aXRoIG11bHRpcGxlCj4gZ2xvYmFsIGFkZHJlc3NlcyBvbiBpdHMgaW50ZXJmYWNlcyBbSW5m b3JtYXRpb25hbF0KPiAKPiAtIEFuIGFuYWx5c2lzIGRvY3VtZW50IGV4cGxhaW5pbmcgd2hhdCBh cmUgdGhlIGxpbWl0YXRpb25zIGZvcgo+IG1vYmlsZSBob3N0cyB1c2luZyBtdWx0aXBsZSBzaW11 bHRhbmVvdXMgQ2FyZS1vZiBBZGRyZXNzZXMgYW5kIEhvbWUKPiBBZ2VudCBhZGRyZXNzZXMgdXNp bmcgTW9iaWxlIElQdjYsIHdoZXRoZXIgaXNzdWVzIGFyZSBzcGVjaWZpYyB0bwo+IE1vYmlsZSBJ UHY2IG9yIG5vdCBbSW5mb3JtYXRpb25hbF0uCj4gCj4gSSB0aGluayB0aGlzIGlzIHZlcnkgc2lt aWxhciB0byB0aGUgc2NvcGUgb2Ygb25lIG9mIHlvdSBkb2N1bWVudHMgYXQKPiBsZWFzdCwgc28g aSB3b3VsZCBmaW5kIHZlcnkgc3RyYW5nZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVk IGluCj4gdHdvIGRpZmZlcmVudCB3b3JraW5nIGdyb3Vwcy4KPiAKPiBNb3Jlb3Zlciwgd2UgZG8g aGF2ZSB3ZyBkb2N1bWVudHMgZm9yIHRoZXNlIHR3bywgYnV0IHdlIGZpbmQgdmVyeSBoYXJkCj4g dG8gZmluZCByZXZpZXdlcnMgZm9yIHRob3NlLCB3aGljaCBtYWtlcyBtZSB0aGluayB0aGF0IHRo ZXJlIGlzIG5vdCBtdWNoCj4gaW50ZXJlc3Qgb24gdGhlc2UuIFNvLCBpZiB5b3UgZmluZCBhIG1v cmUgbW90aXZhdGVkIGNyZXcgdG8gZG8gdGhlIHdvcmssCj4gdGhhdCB3b3VsZCBiZSBncmVhdCwg d2UgY2FuIGVpdGhlciBkbyBpdCBpbiBtZXh0IG9yIHNvZW13aGVyZSBlbHNlLCBpZgo+IHBlb3Bs ZSBmZWVscyB0aGF0IG5lZWRzIHRvIGJlIGRvbmUsIGJ1dCB0aGF0IGlzIGNlcnRhaW5seSBub3Qg dGhlCj4gZmVlbGluZyBpIGFtIGdldHRpbmcgZnJvbSB0aGUgaW5wdXQgaW4gbWV4dAoKdG8gbWUs IHRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgJ211bHRpcGxlIGludGVyZmFjZScgaXNz dWUgaXMgbm90CmJvdW5kIHRvIG1vYmlsaXR5LCBhbmQgbW9yZSBzcGVjaWZpY2FsbHkgdG8gbW9i aWxpdHkgcHJvdG9jb2xzCihtb2JpbGVJUHY0LCBtb2JpbGVpcHY2LCBuZW1vLCAuLi4pLgoKVGhl cmVmb3JlLCB0aGUgTUlGIHdvcmsgaXMgbm90IHNjb3BpbmcgYWJvdXQgbW9iaWxpdHkgcHJvdG9j b2xzIGFuZApzaGFsbCBub3QgcmVxdWlyZSBtb2JpbGl0eSBwcm90b2NvbHMuCgpJIHdvdWxkIHNl ZSB0aGF0IGlmIHNvbWUgcGFydCBvZiB0aGUgTUlGIHdvcmsgaXMgbG9va2luZyBhdCB0aGUgbW9i aWxpdHkKcHJvdG9jb2xzLCB0aGVuIHRoZXNlIHNob3VsZCBiZSB0aGVuICJ0cmFuc2ZlcmVkIiB0 byBNRVhULgoKTWFyYy4KCj4gCj4gUmVnYXJkcywgbWFyY2Vsbwo+IAo+IAo+IAo+IEhvbmcgWW9u Zy1HZXVuIGVzY3JpYmnDszoKPj4KPj4gSGksIGFsbCBpbiBNRVhUIGFuZCBtaWYuCj4+Cj4+ICAK Pj4KPj4gSW4gSUVURiBtaWYgKE11bHRpcGxlIEludGVyZmFjZSkgbWFpbGluZyBsaXN0Cj4+IChf aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWZfCj4+IDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+Pgo+PiB3ZSBub3cgZGlzY3VzcyB0 aGUgaG9zdCB3aGljaCB3b3VsZCBsaWtlIHRvIHVzZSBtdWx0aXBsZSBpbnRlcmZhY2VzLgo+Pgo+ PiBJIHVuZGVyc3RhbmQgdGhhdCBNRVhUIFdHIGlzIGFsc28gcmVsYXRlZCB0byB0aGUgdXNlIG9m IG11bHRpcGxlCj4+IGludGVyZmFjZXMgb2YgYSBob3N0Cj4+IHVzaW5nIE1vYmlsZSBJUHY2IG9y IGEgbW9iaWxlIHJvdXRlciB1c2luZyBORU1PIEJhc2ljIFN1cHBvcnQgYW5kCj4+IHRoZWlyIHZh cmlhbnRzCj4+Cj4+IE1FWFQgV0cgaXMgZm9jdWluZyBvbiBtb25hbWk2IHJlbGF0ZWQgdG9waWMg KG11bHRpcGxlIENvQSwgTXVsdGlwbGUKPj4gSG9BLCBhbmQgTXVsdHBsZSBIQSwgZXRjLiwpCj4+ IGFuZCBleHRlZG5pbmcgTW9iaWxlIElQdjYgYW5kIE5FTU8gZm9yIHRoZXNlLCBidXQgbWlmIGlz IG5vdCByZWxhdGVkCj4+IHRvIHRoaXMgZGlyZWN0aW9uLgo+PiBJbiBtaWYsIHNvdXJjZSBhZGRy ZXNzIHNlbGVjdGlvbiwgcm91dGluZyBhbmQgRE5TIGNvbnRyb2wgcHJvdG9jb2wgYXJlCj4+IGNv bnNpZGVyYXRpb24gaXRlbXMKPj4gZHVlIHRvIG11bHRpcGxlIGludGVyZmFjZXMgb2YgYSBob3N0 Lgo+Pgo+PiAgCj4+Cj4+IEZvciBtaWbigJlzIHNjb3BlLCBKYXJpIEFya2tvIG1hZGUgc29tZSBj b21tZW50cyBhbmQgY2xhc3NpZmljYXRpb24gb2YKPj4gcHJvYmxlbXMuCj4+Cj4+IF9odHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNnMDAwNTAuaHRtbF8K Pj4KPj4gQW1vbmcgdGhlc2UgY2xhc3NpZmljYXRpb24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNl bGVjdGlvbiwgc3BsaXQgRE5TLAo+PiBjb25maWd1cmF0aW9uIHJlY29uY2lsaWF0aW9uLAo+PiBy b3V0aW5nLCBhZGRyZXNzIHNlbGVjdGlvbiwgdHVubmVsIG11bHRpaG9taW5nLCBhbmQgdGhlIGNv bW11bmljYXRpb24KPj4gd2F5IGJldHdlZW4gdGhlIGhvc3QgYW5kCj4+IHRoZSBuZXR3b3JrIGFi b3V0IHRoZWlyIHBvbGljaWVzIHJlZ2FyZGluZyBhbGwgb2YgdGhlIGFib3ZlLCBKYXJpIHNhaWQK Pj4gdGhhdCBhY2Nlc3Mgc2VsZWN0aW9uIGlzIGFscmVhZHkKPj4gY292ZXJkIGluIFJGQyA1MTEz IGFuZCB0dW5uZWwgbXVsdGlob21pbmcgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIE1FWFQKPj4gV0cg d29yayBpdGVtcy4KPj4KPj4gIAo+Pgo+PiBBdCBtb25hbWk2IFdHIGluIDY0dGggSUVURiBtZWV0 aW5uZywgSSBzdWJtaXR0ZWQgYW5kIHByZXNlbnRlZCB0d28KPj4gSW50ZXJuZXQgRHJhZnRzLgo+ Pgo+PiAtIEFuYWx5c2lzIG9mIG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgTm9kZQo+ Pgo+PiBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctbXVsdGlwbGVpZi1tbi1w Yi1zdGF0ZW1lbnQtMDAudHh0Xwo+Pgo+PiAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9y IG11bHRpcGxlIGludGVyZmFjZXMgaW4gYSBNb2JpbGUgbm9kZQo+PiB1c2luZyBNb2JpbGUgSVB2 Ngo+Pgo+PiBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1u LW1pcHY2LTAwLnR4dF8KPj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZp cnR1YWxpZi1tbi1taXB2Ni0wMC50eHQ+Cj4+Cj4+IEJlY2F1c2UgdGhlc2UgdHdvIGRyYWZ0cyB3 ZXJlIG5vdCBpbiB0aGUgbW9uYW1pNiBXR+KAmXMgc2NvcGUgYW5kCj4+IHZpcnR1YWwgbmV0d29y ayBpbnRlcmZhY2UgZHJhZnQgd2FzCj4+Cj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCB0aGVy ZSB3ZXJlIG5vdCBhZG9wZWQgaW4gbW9uYW1pNiBXR+KAmXMgd29yawo+PiBpdGVtcy4gVGhlIGlu dGVudGlvbnMgb2YgdHdvIGRyYWZ0cwo+PiBhcmUgc3VwcG9ydGluZyBtdWx0aXBsZSBpbnRlcmZh Y2VzIG9mIGEgaG9zdCB3aXRob3V0IGV4dGVuZGluZyBNb2JpbGUKPj4gSVB2Ni9ORU1PLgo+Pgo+ PiAgCj4+Cj4+IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2VzIHByb2JsZW1zIG9mIGEg aG9zdCBhcmUgcmVsYXRlZCB0bwo+PiBib3RoIE1vYmlsZSBJUC9ORU1PIHNwZWNpZmljIGlzc3Vl cyBhbmQKPj4gZ2VuZXJhbCBuZXR3b3JrIGlzc3Vlcy4gTW9iaWxlIElQL05FTU8gc3BlY2lmaWMg aXNzdWVzIGFyZSByZWxhdGVkIHRvCj4+IGV4dGVuZGluZyBvZiBNb2JpbGUgSVAvTkVNTyBhbmQK Pj4gdGhlc2UgYXJlIGFscmVhZHkgc3R1ZGllZCBpbiBNRVhUIFdHIGFuZCBnZW5lcmFsIG5ldHdv cmsgaXNzdWVzIHdoaWNoCj4+IHdlcmUgbm90IHJlbGF0ZWQgdG8KPj4gTW9iaWxlIElQL05FTU8g Y291bGQgYmUgc3R1ZGllZCBpbiBtaWYuIEFzIHNhbWUgbWFubmVyLCBJIHRoaW5rIHRoYXQKPj4g bXkgZHJhZnRzIGNvdWxkIGJlIGRpc2N1c3NlZCBhbmQKPj4gZGV2ZWxvcGVkIGluIG1pZi4gSW4g dGhlIGZpcnN0IGRyYWZ0IChBbmFseXNpcyBkb2N1bWVudCksIEkgY2xhc3NpZmllZAo+PiBtdWx0 aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgaW50bwo+PiBNb2JpbGUgSVB2Ni1zZXBjaWZpYyBpc3N1 ZXMsIEdlbmVyYWwgbmV0d29yayBpc3N1ZXMsIGFuZCBoZXRlcm9nZW5lb3VzCj4+IGVudmlyb25t ZW50IGlzc3Vlcy4KPj4KPj4gIAo+Pgo+PiBJbmNsdWRpbmcgSHVpIERlbmcgaW4gbWlmLCB3aXRo IHJlZ2FyZGluZyB0byB0aGVzZSBkcmFmdHMsIHRoZXkgd2FudAo+PiB0byBoZWFyIGNvbW1lbnRz IGZyb20gTUVYVCBXR+KAmXMgcG9pbnQgb2YgdmlldywKPj4gYmVjYXVzZSBpdCBzZWVtcyB0aGF0 IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBtb25hbWk2L01FWFQKPj4gV0cuIFNv LCBJIGFzayBNRVhUIHRvIHJldmlldyB3aGV0aGVyIHRoZXJlIGFyZQo+Pgo+PiBzb21lIG92ZXJs YXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Igbm90Lgo+Pgo+PiBJdCBpcyBh cHByZWNpYXRlIHRvIGdpdmUgY29tbWVudHMuCj4+Cj4+ICAKPj4KPj4gQmVzdCByZWdhcmRzLgo+ Pgo+PiBZb25nLUdldW4uCj4+Cj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiBtaWYgbWFpbGluZyBsaXN0Cj4gbWlmQGlldGYub3JnCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYKCgotLSAKPT09PT09PT09CklQdjYg Ym9vazogTWlncmF0aW5nIHRvIElQdjYsIFdpbGV5LiBodHRwOi8vd3d3LmlwdjZib29rLmNhClN0 dW4vVHVybiBzZXJ2ZXIgZm9yIFZvSVAgTkFULUZXIHRyYXZlcnNhbDogaHR0cDovL251bWIudmlh Z2VuaWUuY2EKRFROIG5ld3Mgc2VydmljZTogaHR0cDovL3JlZXZlcy52aWFnZW5pZS5jYQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWlmIG1haWxpbmcg bGlzdAptaWZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t aWYK From mif-bounces@ietf.org Thu Jan 29 12:10:18 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698A63A6AA2; Thu, 29 Jan 2009 12:10:18 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEAD3A6AA2; Thu, 29 Jan 2009 12:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FRT_MEETING=2.697, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycou0oT3IT4C; Thu, 29 Jan 2009 12:10:15 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 895C33A6A64; Thu, 29 Jan 2009 12:10:14 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (187.pool85-53-142.dynamic.orange.es [85.53.142.187]) by smtp02.uc3m.es (Postfix) with ESMTP id EBB1A65A1FD; Thu, 29 Jan 2009 21:09:54 +0100 (CET) Message-ID: <49820D13.2060601@it.uc3m.es> Date: Thu, 29 Jan 2009 21:09:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> In-Reply-To: <49820BB6.9070405@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.001 Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org bWFrZXMgc2Vuc2UgdG8gbWUKCgoKTWFyYyBCbGFuY2hldCBlc2NyaWJpw7M6Cj4gbWFyY2VsbyBi YWdudWxvIGJyYXVuIGEgw6ljcml0IDoKPiAgIAo+PiBIaSwKPj4KPj4gSW4gdGhlIGN1cnJlbnQg TUVYVCBjaGFydGVyIHRoZXJlIGFyZSBzZXZlcmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcKPj4g bXVsdGlwbGUgaW50ZXJmYWNlcywgaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmcgdHdvOgo+Pgo+PiAt IEEgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZm9yIGEgbm9kZSB1c2luZyBt dWx0aXBsZQo+PiBpbnRlcmZhY2VzIGFuZCB0aGUgc2NlbmFyaW9zIHdoZXJlIGl0IG1heSBlbmQg dXAgd2l0aCBtdWx0aXBsZQo+PiBnbG9iYWwgYWRkcmVzc2VzIG9uIGl0cyBpbnRlcmZhY2VzIFtJ bmZvcm1hdGlvbmFsXQo+Pgo+PiAtIEFuIGFuYWx5c2lzIGRvY3VtZW50IGV4cGxhaW5pbmcgd2hh dCBhcmUgdGhlIGxpbWl0YXRpb25zIGZvcgo+PiBtb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUg c2ltdWx0YW5lb3VzIENhcmUtb2YgQWRkcmVzc2VzIGFuZCBIb21lCj4+IEFnZW50IGFkZHJlc3Nl cyB1c2luZyBNb2JpbGUgSVB2Niwgd2hldGhlciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvCj4+IE1v YmlsZSBJUHY2IG9yIG5vdCBbSW5mb3JtYXRpb25hbF0uCj4+Cj4+IEkgdGhpbmsgdGhpcyBpcyB2 ZXJ5IHNpbWlsYXIgdG8gdGhlIHNjb3BlIG9mIG9uZSBvZiB5b3UgZG9jdW1lbnRzIGF0Cj4+IGxl YXN0LCBzbyBpIHdvdWxkIGZpbmQgdmVyeSBzdHJhbmdlIHRoYXQgdGhlIHNhbWUgd29yayBpcyBj aGFydGVyZWQgaW4KPj4gdHdvIGRpZmZlcmVudCB3b3JraW5nIGdyb3Vwcy4KPj4KPj4gTW9yZW92 ZXIsIHdlIGRvIGhhdmUgd2cgZG9jdW1lbnRzIGZvciB0aGVzZSB0d28sIGJ1dCB3ZSBmaW5kIHZl cnkgaGFyZAo+PiB0byBmaW5kIHJldmlld2VycyBmb3IgdGhvc2UsIHdoaWNoIG1ha2VzIG1lIHRo aW5rIHRoYXQgdGhlcmUgaXMgbm90IG11Y2gKPj4gaW50ZXJlc3Qgb24gdGhlc2UuIFNvLCBpZiB5 b3UgZmluZCBhIG1vcmUgbW90aXZhdGVkIGNyZXcgdG8gZG8gdGhlIHdvcmssCj4+IHRoYXQgd291 bGQgYmUgZ3JlYXQsIHdlIGNhbiBlaXRoZXIgZG8gaXQgaW4gbWV4dCBvciBzb2Vtd2hlcmUgZWxz ZSwgaWYKPj4gcGVvcGxlIGZlZWxzIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSwgYnV0IHRoYXQgaXMg Y2VydGFpbmx5IG5vdCB0aGUKPj4gZmVlbGluZyBpIGFtIGdldHRpbmcgZnJvbSB0aGUgaW5wdXQg aW4gbWV4dAo+PiAgICAgCj4KPiB0byBtZSwgdGhlIG1haW4gZGlmZmVyZW5jZSBpcyB0aGF0IHRo ZSAnbXVsdGlwbGUgaW50ZXJmYWNlJyBpc3N1ZSBpcyBub3QKPiBib3VuZCB0byBtb2JpbGl0eSwg YW5kIG1vcmUgc3BlY2lmaWNhbGx5IHRvIG1vYmlsaXR5IHByb3RvY29scwo+IChtb2JpbGVJUHY0 LCBtb2JpbGVpcHY2LCBuZW1vLCAuLi4pLgo+Cj4gVGhlcmVmb3JlLCB0aGUgTUlGIHdvcmsgaXMg bm90IHNjb3BpbmcgYWJvdXQgbW9iaWxpdHkgcHJvdG9jb2xzIGFuZAo+IHNoYWxsIG5vdCByZXF1 aXJlIG1vYmlsaXR5IHByb3RvY29scy4KPgo+IEkgd291bGQgc2VlIHRoYXQgaWYgc29tZSBwYXJ0 IG9mIHRoZSBNSUYgd29yayBpcyBsb29raW5nIGF0IHRoZSBtb2JpbGl0eQo+IHByb3RvY29scywg dGhlbiB0aGVzZSBzaG91bGQgYmUgdGhlbiAidHJhbnNmZXJlZCIgdG8gTUVYVC4KPgo+IE1hcmMu Cj4KPiAgIAo+PiBSZWdhcmRzLCBtYXJjZWxvCj4+Cj4+Cj4+Cj4+IEhvbmcgWW9uZy1HZXVuIGVz Y3JpYmnDszoKPj4gICAgIAo+Pj4gSGksIGFsbCBpbiBNRVhUIGFuZCBtaWYuCj4+Pgo+Pj4gIAo+ Pj4KPj4+IEluIElFVEYgbWlmIChNdWx0aXBsZSBJbnRlcmZhY2UpIG1haWxpbmcgbGlzdAo+Pj4g KF9odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZl8KPj4+IDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZj4pLAo+Pj4KPj4+IHdlIG5vdyBkaXNj dXNzIHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMu Cj4+Pgo+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgTUVYVCBXRyBpcyBhbHNvIHJlbGF0ZWQgdG8gdGhl IHVzZSBvZiBtdWx0aXBsZQo+Pj4gaW50ZXJmYWNlcyBvZiBhIGhvc3QKPj4+IHVzaW5nIE1vYmls ZSBJUHY2IG9yIGEgbW9iaWxlIHJvdXRlciB1c2luZyBORU1PIEJhc2ljIFN1cHBvcnQgYW5kCj4+ PiB0aGVpciB2YXJpYW50cwo+Pj4KPj4+IE1FWFQgV0cgaXMgZm9jdWluZyBvbiBtb25hbWk2IHJl bGF0ZWQgdG9waWMgKG11bHRpcGxlIENvQSwgTXVsdGlwbGUKPj4+IEhvQSwgYW5kIE11bHRwbGUg SEEsIGV0Yy4sKQo+Pj4gYW5kIGV4dGVkbmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhl c2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0ZWQKPj4+IHRvIHRoaXMgZGlyZWN0aW9uLgo+Pj4gSW4g bWlmLCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24sIHJvdXRpbmcgYW5kIEROUyBjb250cm9sIHBy b3RvY29sIGFyZQo+Pj4gY29uc2lkZXJhdGlvbiBpdGVtcwo+Pj4gZHVlIHRvIG11bHRpcGxlIGlu dGVyZmFjZXMgb2YgYSBob3N0Lgo+Pj4KPj4+ICAKPj4+Cj4+PiBGb3IgbWlm4oCZcyBzY29wZSwg SmFyaSBBcmtrbyBtYWRlIHNvbWUgY29tbWVudHMgYW5kIGNsYXNzaWZpY2F0aW9uIG9mCj4+PiBw cm9ibGVtcy4KPj4+Cj4+PiBfaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21p Zi9jdXJyZW50L21zZzAwMDUwLmh0bWxfCj4+Pgo+Pj4gQW1vbmcgdGhlc2UgY2xhc3NpZmljYXRp b24gd2hpY2ggaW5jbHVkZXMgYWNjZXNzIHNlbGVjdGlvbiwgc3BsaXQgRE5TLAo+Pj4gY29uZmln dXJhdGlvbiByZWNvbmNpbGlhdGlvbiwKPj4+IHJvdXRpbmcsIGFkZHJlc3Mgc2VsZWN0aW9uLCB0 dW5uZWwgbXVsdGlob21pbmcsIGFuZCB0aGUgY29tbXVuaWNhdGlvbgo+Pj4gd2F5IGJldHdlZW4g dGhlIGhvc3QgYW5kCj4+PiB0aGUgbmV0d29yayBhYm91dCB0aGVpciBwb2xpY2llcyByZWdhcmRp bmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkCj4+PiB0aGF0IGFjY2VzcyBzZWxlY3Rpb24g aXMgYWxyZWFkeQo+Pj4gY292ZXJkIGluIFJGQyA1MTEzIGFuZCB0dW5uZWwgbXVsdGlob21pbmcg aXMgYWxyZWFkeSBjb3ZlcmVkIGluIE1FWFQKPj4+IFdHIHdvcmsgaXRlbXMuCj4+Pgo+Pj4gIAo+ Pj4KPj4+IEF0IG1vbmFtaTYgV0cgaW4gNjR0aCBJRVRGIG1lZXRpbm5nLCBJIHN1Ym1pdHRlZCBh bmQgcHJlc2VudGVkIHR3bwo+Pj4gSW50ZXJuZXQgRHJhZnRzLgo+Pj4KPj4+IC0gQW5hbHlzaXMg b2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBpbiBhIE1vYmlsZSBOb2RlCj4+Pgo+Pj4gX2h0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAw LnR4dF8KPj4+Cj4+PiAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGlu dGVyZmFjZXMgaW4gYSBNb2JpbGUgbm9kZQo+Pj4gdXNpbmcgTW9iaWxlIElQdjYKPj4+Cj4+PiBf aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAw LnR4dF8KPj4+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy12aXJ0dWFsaWYt bW4tbWlwdjYtMDAudHh0Pgo+Pj4KPj4+IEJlY2F1c2UgdGhlc2UgdHdvIGRyYWZ0cyB3ZXJlIG5v dCBpbiB0aGUgbW9uYW1pNiBXR+KAmXMgc2NvcGUgYW5kCj4+PiB2aXJ0dWFsIG5ldHdvcmsgaW50 ZXJmYWNlIGRyYWZ0IHdhcwo+Pj4KPj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCB0aGVyZSB3 ZXJlIG5vdCBhZG9wZWQgaW4gbW9uYW1pNiBXR+KAmXMgd29yawo+Pj4gaXRlbXMuIFRoZSBpbnRl bnRpb25zIG9mIHR3byBkcmFmdHMKPj4+IGFyZSBzdXBwb3J0aW5nIG11bHRpcGxlIGludGVyZmFj ZXMgb2YgYSBob3N0IHdpdGhvdXQgZXh0ZW5kaW5nIE1vYmlsZQo+Pj4gSVB2Ni9ORU1PLgo+Pj4K Pj4+ICAKPj4+Cj4+PiBJIHRoaW5rIHRoYXQgbXVsdGlwbGUgaW50ZXJmYWNlcyBwcm9ibGVtcyBv ZiBhIGhvc3QgYXJlIHJlbGF0ZWQgdG8KPj4+IGJvdGggTW9iaWxlIElQL05FTU8gc3BlY2lmaWMg aXNzdWVzIGFuZAo+Pj4gZ2VuZXJhbCBuZXR3b3JrIGlzc3Vlcy4gTW9iaWxlIElQL05FTU8gc3Bl Y2lmaWMgaXNzdWVzIGFyZSByZWxhdGVkIHRvCj4+PiBleHRlbmRpbmcgb2YgTW9iaWxlIElQL05F TU8gYW5kCj4+PiB0aGVzZSBhcmUgYWxyZWFkeSBzdHVkaWVkIGluIE1FWFQgV0cgYW5kIGdlbmVy YWwgbmV0d29yayBpc3N1ZXMgd2hpY2gKPj4+IHdlcmUgbm90IHJlbGF0ZWQgdG8KPj4+IE1vYmls ZSBJUC9ORU1PIGNvdWxkIGJlIHN0dWRpZWQgaW4gbWlmLiBBcyBzYW1lIG1hbm5lciwgSSB0aGlu ayB0aGF0Cj4+PiBteSBkcmFmdHMgY291bGQgYmUgZGlzY3Vzc2VkIGFuZAo+Pj4gZGV2ZWxvcGVk IGluIG1pZi4gSW4gdGhlIGZpcnN0IGRyYWZ0IChBbmFseXNpcyBkb2N1bWVudCksIEkgY2xhc3Np ZmllZAo+Pj4gbXVsdGlwbGUgaW50ZXJmYWNlIHByb2JsZW1zIGludG8KPj4+IE1vYmlsZSBJUHY2 LXNlcGNpZmljIGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVv dXMKPj4+IGVudmlyb25tZW50IGlzc3Vlcy4KPj4+Cj4+PiAgCj4+Pgo+Pj4gSW5jbHVkaW5nIEh1 aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRpbmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5IHdhbnQK Pj4+IHRvIGhlYXIgY29tbWVudHMgZnJvbSBNRVhUIFdH4oCZcyBwb2ludCBvZiB2aWV3LAo+Pj4g YmVjYXVzZSBpdCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUgcmVsYXRlZCB0byBt b25hbWk2L01FWFQKPj4+IFdHLiBTbywgSSBhc2sgTUVYVCB0byByZXZpZXcgd2hldGhlciB0aGVy ZSBhcmUKPj4+Cj4+PiBzb21lIG92ZXJsYXAgYmV0d2VlbiBNRVhUIHdvcmtzIGFuZCBteSBkcmFm dHMgb3Igbm90Lgo+Pj4KPj4+IEl0IGlzIGFwcHJlY2lhdGUgdG8gZ2l2ZSBjb21tZW50cy4KPj4+ Cj4+PiAgCj4+Pgo+Pj4gQmVzdCByZWdhcmRzLgo+Pj4KPj4+IFlvbmctR2V1bi4KPj4+Cj4+PiAg ICAgICAKPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4gbWlmIG1haWxpbmcgbGlzdAo+PiBtaWZAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9taWYKPj4gICAgIAo+Cj4KPiAgIAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWlmIG1haWxpbmcgbGlzdAptaWZAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYK From mif-bounces@ietf.org Thu Jan 29 12:27:10 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C063A6A64; Thu, 29 Jan 2009 12:27:10 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8503A6A56; Thu, 29 Jan 2009 12:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtszSbNKR0t9; Thu, 29 Jan 2009 12:27:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4B3703A6872; Thu, 29 Jan 2009 12:27:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,346,1231113600"; d="scan'208";a="35335632" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2009 20:26:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0TKQnQA027486; Thu, 29 Jan 2009 15:26:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0TKQnmX017729; Thu, 29 Jan 2009 20:26:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 15:26:49 -0500 Received: from cisco.com ([10.86.244.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 15:26:48 -0500 Date: Thu, 29 Jan 2009 15:26:44 -0500 From: Scott Brim To: marcelo bagnulo braun Message-ID: <20090129202644.GZ34382@cisco.com> References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49820D13.2060601@it.uc3m.es> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 29 Jan 2009 20:26:49.0018 (UTC) FILETIME=[E99D09A0:01C9824F] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM +0100: > makes sense to me > > Marc Blanchet escribi=F3: >> to me, the main difference is that the 'multiple interface' issue >> is not bound to mobility, and more specifically to mobility >> protocols (mobileIPv4, mobileipv6, nemo, ...). >> >> Therefore, the MIF work is not scoping about mobility protocols and >> shall not require mobility protocols. >> >> I would see that if some part of the MIF work is looking at the >> mobility protocols, then these should be then "transfered" to MEXT. Even without mobility considerations, the issue of how to handle multiple interfaces overlaps with IntArea, RRG, and Behave (those are the ones I can think of offhand). Have you seen the arguments, for example, about session initialization when multiple addresses can be in play simultaneously at both ends? I apologize but I still don't understand the MIF boundaries. Thanks ... Scott _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 12:33:54 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E9C3A6A20; Thu, 29 Jan 2009 12:33:54 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA5C3A687E; Thu, 29 Jan 2009 12:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9Acs4jnBCFm; Thu, 29 Jan 2009 12:33:53 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7CFEC3A6A20; Thu, 29 Jan 2009 12:33:53 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (187.pool85-53-142.dynamic.orange.es [85.53.142.187]) by smtp02.uc3m.es (Postfix) with ESMTP id 78B48659C89; Thu, 29 Jan 2009 21:33:32 +0100 (CET) Message-ID: <4982129D.3060503@it.uc3m.es> Date: Thu, 29 Jan 2009 21:33:33 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Scott Brim References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> In-Reply-To: <20090129202644.GZ34382@cisco.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Scott Brim escribi=F3: > Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM > +0100: > = >> makes sense to me >> >> Marc Blanchet escribi=F3: >> = >>> to me, the main difference is that the 'multiple interface' issue >>> is not bound to mobility, and more specifically to mobility >>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>> >>> Therefore, the MIF work is not scoping about mobility protocols and >>> shall not require mobility protocols. >>> >>> I would see that if some part of the MIF work is looking at the >>> mobility protocols, then these should be then "transfered" to MEXT. >>> = > > Even without mobility considerations, the issue of how to handle > multiple interfaces overlaps with IntArea, RRG, and Behave (those are > the ones I can think of offhand). Have you seen the arguments, for > example, about session initialization when multiple addresses can be > in play simultaneously at both ends? I apologize but I still don't > understand the MIF boundaries. > > = I wrote a draft a long time ago about the problems for selecting the = source address in multiaddressed hosts, not sure if this is related to = what you asking about... you can check it at http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.txt regards, marcelo > Thanks ... Scott > > = _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 12:36:46 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922053A6A64; Thu, 29 Jan 2009 12:36:46 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE0C3A6A55; Thu, 29 Jan 2009 12:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU5zxrtrzitc; Thu, 29 Jan 2009 12:36:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DD9793A6872; Thu, 29 Jan 2009 12:36:43 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 0F14229E1555; Thu, 29 Jan 2009 15:36:25 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id A0ACE29E14EE; Thu, 29 Jan 2009 15:36:24 -0500 (EST) Message-ID: <49821348.3000904@viagenie.ca> Date: Thu, 29 Jan 2009 15:36:24 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982129D.3060503@it.uc3m.es> In-Reply-To: <4982129D.3060503@it.uc3m.es> X-Enigmail-Version: 0.95.7 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org marcelo bagnulo braun a =E9crit : > Scott Brim escribi=F3: >> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >> +0100: >> = >>> makes sense to me >>> >>> Marc Blanchet escribi=F3: >>> = >>>> to me, the main difference is that the 'multiple interface' issue >>>> is not bound to mobility, and more specifically to mobility >>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>> >>>> Therefore, the MIF work is not scoping about mobility protocols and >>>> shall not require mobility protocols. >>>> >>>> I would see that if some part of the MIF work is looking at the >>>> mobility protocols, then these should be then "transfered" to MEXT. >>>> = >> >> Even without mobility considerations, the issue of how to handle >> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >> the ones I can think of offhand). Have you seen the arguments, for >> example, about session initialization when multiple addresses can be >> in play simultaneously at both ends? I apologize but I still don't >> understand the MIF boundaries. >> >> = > = > I wrote a draft a long time ago about the problems for selecting the > source address in multiaddressed hosts, not sure if this is related to > what you asking about... > = > you can check it at > = > http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.t= xt there is an address selection design team that is looking at this currently. Marc. > = > = > regards, marcelo > = >> Thanks ... Scott >> >> = -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 12:42:11 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E40E28C0EB; Thu, 29 Jan 2009 12:42:11 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EED3A6A64; Thu, 29 Jan 2009 12:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YTkJLrDLV-F; Thu, 29 Jan 2009 12:42:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4C6853A6A55; Thu, 29 Jan 2009 12:42:08 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 09C2829E1555; Thu, 29 Jan 2009 15:41:50 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 9AFAF29E14EE; Thu, 29 Jan 2009 15:41:49 -0500 (EST) Message-ID: <4982148C.9080608@viagenie.ca> Date: Thu, 29 Jan 2009 15:41:48 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Scott Brim References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> In-Reply-To: <20090129202644.GZ34382@cisco.com> X-Enigmail-Version: 0.95.7 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Scott Brim a =E9crit : > Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM > +0100: >> makes sense to me >> >> Marc Blanchet escribi=F3: >>> to me, the main difference is that the 'multiple interface' issue >>> is not bound to mobility, and more specifically to mobility >>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>> >>> Therefore, the MIF work is not scoping about mobility protocols and >>> shall not require mobility protocols. >>> >>> I would see that if some part of the MIF work is looking at the >>> mobility protocols, then these should be then "transfered" to MEXT. > = > Even without mobility considerations, the issue of how to handle > multiple interfaces overlaps with IntArea, RRG, and Behave (those are > the ones I can think of offhand). Have you seen the arguments, for > example, about session initialization when multiple addresses can be > in play simultaneously at both ends? I apologize but I still don't > understand the MIF boundaries. of course, there is overlap, as most IETF issues and work span over multiple groups. to me, the question in hand is the following: a) do we think this is a "real" problem b) if yes, then what should we do with it. c) if what =3D possible wg, then write charter, ... to me, a) and b) are clearly subject of the BOF. c) depends on the outcome of the BOF. Looking at the various comments over the past weeks, it might be good that we (the initial proposers or anyone I shall say) should write a possible wg charter based on the discussions. We might then define the scope and the out of scope... Marc. > = > Thanks ... Scott -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 12:44:28 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8413A6A71; Thu, 29 Jan 2009 12:44:28 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2C83A6A83; Thu, 29 Jan 2009 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUI+Jxc+cIWG; Thu, 29 Jan 2009 12:44:27 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 875FF3A6A64; Thu, 29 Jan 2009 12:44:25 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (134.pool85-53-135.dynamic.orange.es [85.53.135.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 2AA59B4D496; Thu, 29 Jan 2009 21:44:04 +0100 (CET) Message-ID: <49821513.8060307@it.uc3m.es> Date: Thu, 29 Jan 2009 21:44:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982129D.3060503@it.uc3m.es> <49821348.3000904@viagenie.ca> In-Reply-To: <49821348.3000904@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Marc Blanchet escribi=F3: > marcelo bagnulo braun a =E9crit : > = >> Scott Brim escribi=F3: >> = >>> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >>> +0100: >>> = >>> = >>>> makes sense to me >>>> >>>> Marc Blanchet escribi=F3: >>>> = >>>> = >>>>> to me, the main difference is that the 'multiple interface' issue >>>>> is not bound to mobility, and more specifically to mobility >>>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>>> >>>>> Therefore, the MIF work is not scoping about mobility protocols and >>>>> shall not require mobility protocols. >>>>> >>>>> I would see that if some part of the MIF work is looking at the >>>>> mobility protocols, then these should be then "transfered" to MEXT. >>>>> = >>>>> = >>> Even without mobility considerations, the issue of how to handle >>> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >>> the ones I can think of offhand). Have you seen the arguments, for >>> example, about session initialization when multiple addresses can be >>> in play simultaneously at both ends? I apologize but I still don't >>> understand the MIF boundaries. >>> >>> = >>> = >> I wrote a draft a long time ago about the problems for selecting the >> source address in multiaddressed hosts, not sure if this is related to >> what you asking about... >> >> you can check it at >> >> http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.= txt >> = > > there is an address selection design team that is looking at this current= ly. > = mmm, not really maybe i missing somehting, but i understnad that the scope of the design = team is limited to the automatic update of the rfc3484 policy table, and = they are not dealing with the issue of how the properly select the = source address, for instance, in the case that you need to retry due to = ingress filtering and the like regards, marcelo > Marc. > > = >> regards, marcelo >> >> = >>> Thanks ... Scott >>> >>> = >>> = > > > = _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 12:56:36 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0473A68D7; Thu, 29 Jan 2009 12:56:36 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71EB3A68BC; Thu, 29 Jan 2009 12:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p1uo3eLOP2f; Thu, 29 Jan 2009 12:56:35 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AC9243A68D7; Thu, 29 Jan 2009 12:56:34 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (134.pool85-53-135.dynamic.orange.es [85.53.135.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 5D1BA65A16D; Thu, 29 Jan 2009 21:56:14 +0100 (CET) Message-ID: <498217EF.50709@it.uc3m.es> Date: Thu, 29 Jan 2009 21:56:15 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Marc Blanchet References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982148C.9080608@viagenie.ca> In-Reply-To: <4982148C.9080608@viagenie.ca> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16432.002 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Marc Blanchet escribi=F3: > Scott Brim a =E9crit : > = >> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >> +0100: >> = >>> makes sense to me >>> >>> Marc Blanchet escribi=F3: >>> = >>>> to me, the main difference is that the 'multiple interface' issue >>>> is not bound to mobility, and more specifically to mobility >>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>> >>>> Therefore, the MIF work is not scoping about mobility protocols and >>>> shall not require mobility protocols. >>>> >>>> I would see that if some part of the MIF work is looking at the >>>> mobility protocols, then these should be then "transfered" to MEXT. >>>> = >> Even without mobility considerations, the issue of how to handle >> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >> the ones I can think of offhand). Have you seen the arguments, for >> example, about session initialization when multiple addresses can be >> in play simultaneously at both ends? I apologize but I still don't >> understand the MIF boundaries. >> = > > of course, there is overlap, as most IETF issues and work span over > multiple groups. > > to me, the question in hand is the following: > a) do we think this is a "real" problem > b) if yes, then what should we do with it. > c) if what =3D possible wg, then write charter, ... > > to me, a) and b) are clearly subject of the BOF. c) depends on the > outcome of the BOF. > > Looking at the various comments over the past weeks, it might be good > that we (the initial proposers or anyone I shall say) should write a > possible wg charter based on the discussions. We might then define the > scope and the out of scope... > = that would be perfect imho now it is a bit confusing what is the scope of this effort at least for me thanks, marcelo > Marc. > = >> Thanks ... Scott >> = > > > = _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Thu Jan 29 17:32:25 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D387328C21F; Thu, 29 Jan 2009 17:32:25 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73F93A6AB0 for ; Thu, 29 Jan 2009 17:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.035 X-Spam-Level: ** X-Spam-Status: No, score=2.035 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGA0UgyDHmTF for ; Thu, 29 Jan 2009 17:32:22 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 851CE28C185 for ; Thu, 29 Jan 2009 17:32:22 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 30 Jan 2009 10:32:02 +0900 Priority: normal X-ReadCheckName: mif%40ietf.org Thread-Topic: Re: Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: <06a0ab2a-498a-4b86-8e3e-93337d1f1a4a@etri.re.kr> thread-index: AcmCeozR41kqgY52QEWeQnaYgETsEw== From: "Hong Yong-Geun" To: "Hui Deng" , "marcelo bagnulo braun" Date: Fri, 30 Jan 2009 10:32:01 +0900 Comment: ??, u-??, Message-ID: <29c101c9827a$8cdacba0$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 30 Jan 2009 01:32:02.0160 (UTC) FILETIME=[8D18BF00:01C9827A] Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0241580683==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0241580683== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_29B2_01C982C5.FCBB47B0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_29B2_01C982C5.FCBB47B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_29B2_01C982C5.FCBB47B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBIdWkg Zm9yIHlvdXIgZXhwbGFuYXRpb24gb2YgbWlmJyBzY29wZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkkgYmVsaWV2ZSB0aGF0IHNvb24gdGhlIGNoYXJ0ZXIgcHJvcG9zZWQgb2YgbWlm IHdpbGwgYmUgc2hvd24uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BcyBJIGtub3cs Jm5ic3A7bWlmIGlzIG5vdCBnb2luZyB0byB3b3JrIGluIE1JUHY2L05FTU8gcmVsYXRlZCBpc3N1 ZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5CZXN0IFJlZ2FyZHMuPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5Zb25nLUdldW4uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48QlI+LS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS08QlI+PEI+RnJvbTo8L0I+ICJI dWkgRGVuZyIgJmx0O2RlbmdodWkwMkBnbWFpbC5jb20mZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+ IDIwMDktMDEtMjkg7Jik7ZuEIDc6MTE6MDQ8QlI+PEI+VG86PC9CPiAibWFyY2VsbyBiYWdudWxv IGJyYXVuIiAmbHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0OzxCUj48Qj5DYzo8L0I+IO2Zjeyaqeq3 vCAmbHQ7eWdob25nQGV0cmkucmUua3ImZ3Q7LCAibWV4dEBpZXRmLm9yZyIgJmx0O21leHRAaWV0 Zi5vcmcmZ3Q7LCAibWlmQGlldGYub3JnIiAmbHQ7bWlmQGlldGYub3JnJmd0OywgImp1bGllbi5s YWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tIiAmbHQ7anVsaWVuLmxhZ2FuaWVyLklFVEZAZ29v Z2xlbWFpbC5jb20mZ3Q7PEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogTXVsdGlwbGUgaW50ZXJmYWNl cyBwcm9ibGVtcyBpbiBNRVhUIGFuZCBtaWY8QlI+PEJSPjwvRElWPg0KPERJVj4NCjxQPkhpLCBN YXJjZWxvPC9QPg0KPFA+Rm9yIHlvcnUgcXVlc3Rpb24gYWJvdXQgd2hhdCBtaWYncyBzY29wZSBh dCB0aGUgbW9tZW50LCBKYXJpIGFscmVhZHkgbWFkZSB0aGUgY29tbWVudHMgb248QlI+PEEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21pZi9jdXJyZW50L21zZzAw MDUwLmh0bWwiIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21pZi9jdXJyZW50L21zZzAwMDUwLmh0bWw8L0E+PC9QPg0KPFA+VGhlcmUgYXJlIGFsc28g c2V2ZXJhbCBQUyBkcmFmdHMgeW91IGNvdWxkIHJlZmVyIHRvOjxCUj48QSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYmxhbmNoZXQtbWlmLXByb2JsZW0tc3RhdGVtZW50LTAw LnR4dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYmxhbmNo ZXQtbWlmLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dDwvQT48QlI+PEEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWh1aS1pcC1tdWx0aXBsZS1jb25uZWN0aW9ucy1wcy0wMS50 eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWh1aS1pcC1t dWx0aXBsZS1jb25uZWN0aW9ucy1wcy0wMS50eHQ8L0E+PEJSPjxBIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4 dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0 aXBsZWlmLW1uLXBiLXN0YXRlbWVudC0wMC50eHQ8L0E+PC9QPg0KPFA+dGhhbmtzPC9QPg0KPFA+ LUh1aTxCUj48QlI+PC9QPg0KPERJViBjbGFzcz1nbWFpbF9xdW90ZT4yMDA5LzEvMjkgbWFyY2Vs byBiYWdudWxvIGJyYXVuIDxTUEFOIGRpcj1sdHI+Jmx0OzxBIGhyZWY9Im1haWx0bzptYXJjZWxv QGl0LnVjM20uZXMiIHRhcmdldD1fYmxhbms+bWFyY2Vsb0BpdC51YzNtLmVzPC9BPiZndDs8L1NQ QU4+PEJSPg0KPEJMT0NLUVVPVEUgY2xhc3M9Z21haWxfcXVvdGUgc3R5bGU9IlBBRERJTkctTEVG VDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHgg c29saWQiPkhpIEhvbmcsPEJSPjxCUj53aGF0IGlzIHRoZSBzY29wZSBvZiBNSUY/PEJSPkkgbWVh biwgaW4gdGhlIGJvZiB3aWtpIHBhZ2UgdGhlcmUgaXMgbm8gY2hhcnRlciBwcm9wb3NlZCwgaXMg dGhlcmUgYSBjaGFydGVyIHNvbWV3aGVyZT88QlI+SW4gcGFydGljdWxhciwgaXMgTUlGIGdvaW5n IHRvIHdvcmsgaW4gTUlQdjYvTkVNTyByZWxhdGVkIGlzc3Vlcz88QlI+PEJSPlJlZ2FyZHMsIG1h cmNlbG88QlI+PEJSPjxCUj5Ib25nIFlvbmctR2V1biBlc2NyaWJpPzo8QlI+DQo8QkxPQ0tRVU9U RSBjbGFzcz1nbWFpbF9xdW90ZSBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4 IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+Jm5ic3A7SGksIE1h cmNlbG8uPEJSPiZuYnNwO1RoYW5rcyBmb3IgeW91ciBjb21tZW50cy48QlI+Jm5ic3A7SSBhZ3Jl ZSB0aGF0ICZuYnNwO3RoZSBjdXJyZW50IE1FWFQgV0cgY2hhcnRlciBhbHJlYWR5IGhhcyBzZXZl cmFsIGl0ZW1zIGFib3V0IHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcy4gDQo8RElWIGNs YXNzPUloMkUzZD48QlI+Jm5ic3A7TXkgZG9jdW1lbnRzIGFyZSBvbGQgdmVyc2lvbiB3aGljaCB3 ZXJlIHN1Ym1pdHRlZCB0byBtb25hbWk2IFdHIGF0IDY0dGggSUVURiBtZWV0aW5nIGFuZCB0aGV5 IHdlcmU8QlI+bm90IHVwZGF0ZWQgcHJvcGVybHkuIFNvLCBpdCBzZWVtcyB0aGF0IHNvbWUgY29u dGVudHMgYXJlIHNpbWlsYXIgdG8gdGhlIHdvcmtzIGluIE1FWFQgV0cuPEJSPkkgd2lsbCB1cGRh dGUgbXkgZG9jdW1lbnRzIHRvIGZvY3VzIG9uIG1pZidzIHNjb3BlLjxCUj4mbmJzcDtJdCBpcyBh cHByZWNpYXRlIHRvIHVuZGVyc3RhbmQgdGhhdCAoZXZlbiB0aG91Z2ggdGhlIHNjb3BlIG9mIG1p ZiBpcyBub3QgZml4ZWQpIG1pZiBoYXMgZGlmZmVyZW50IGRpcmVjdGlvbnMgdG88QlI+TUVYVC48 QlI+PC9ESVY+DQo8RElWIGNsYXNzPUloMkUzZD4mbmJzcDtCZXN0IHJlZ2FyZHMuPEJSPiZuYnNw O1lvbmctR2V1bi48QlI+PEJSPi0tLS0t7JuQ67O4IOuplOyLnOyngC0tLS0tPEJSPjwvRElWPipG cm9tOiogIm1hcmNlbG8gYmFnbnVsbyBicmF1biIgJmx0OzxBIGhyZWY9Im1haWx0bzptYXJjZWxv QGl0LnVjM20uZXMiIHRhcmdldD1fYmxhbms+bWFyY2Vsb0BpdC51YzNtLmVzPC9BPiZndDs8QlI+ KkZyb20gRGF0ZToqIDIwMDktMDEtMjgg7Jik7ZuEIDY6NDA6MDk8QlI+KlRvOiogIkhvbmcgWW9u Zy1HZXVuIiAmbHQ7PEEgaHJlZj0ibWFpbHRvOnlnaG9uZ0BldHJpLnJlLmtyIiB0YXJnZXQ9X2Js YW5rPnlnaG9uZ0BldHJpLnJlLmtyPC9BPiZndDs8QlI+KkNjOiogIjxBIGhyZWY9Im1haWx0bzpt ZXh0QGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1leHRAaWV0Zi5vcmc8L0E+IiAmbHQ7PEEgaHJl Zj0ibWFpbHRvOm1leHRAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+bWV4dEBpZXRmLm9yZzwvQT4m Z3Q7LCAiPEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5taWZAaWV0 Zi5vcmc8L0E+IiAmbHQ7PEEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFu az5taWZAaWV0Zi5vcmc8L0E+Jmd0OywgIjxBIGhyZWY9Im1haWx0bzpqdWxpZW4ubGFnYW5pZXIu SUVURkBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PV9ibGFuaz5qdWxpZW4ubGFnYW5pZXIuSUVURkBn b29nbGVtYWlsLmNvbTwvQT4iICZsdDs8QSBocmVmPSJtYWlsdG86anVsaWVuLmxhZ2FuaWVyLklF VEZAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD1fYmxhbms+anVsaWVuLmxhZ2FuaWVyLklFVEZAZ29v Z2xlbWFpbC5jb208L0E+Jmd0OywgIjxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29t IiB0YXJnZXQ9X2JsYW5rPmRlbmdodWkwMkBnbWFpbC5jb208L0E+IiAmbHQ7PEEgaHJlZj0ibWFp bHRvOmRlbmdodWkwMkBnbWFpbC5jb20iIHRhcmdldD1fYmxhbms+ZGVuZ2h1aTAyQGdtYWlsLmNv bTwvQT4mZ3Q7PEJSPipTdWJqZWN0OiogUmU6IE11bHRpcGxlIGludGVyZmFjZXMgcHJvYmxlbXMg aW4gTUVYVCBhbmQgbWlmIA0KPERJVj4NCjxESVY+PC9ESVY+DQo8RElWIGNsYXNzPVdqM0M3Yz48 QlI+PEJSPjxCUj5IaSw8QlI+PEJSPkluIHRoZSBjdXJyZW50IE1FWFQgY2hhcnRlciB0aGVyZSBh cmUgc2V2ZXJhbCBpdGVtcyBhYm91dCBzdXBwb3J0aW5nPEJSPm11bHRpcGxlIGludGVyZmFjZXMs IGluY2x1ZGluZyB0aGUgZm9sbG93aW5nIHR3bzo8QlI+PEJSPi0gQSBkb2N1bWVudCBleHBsYWlu aW5nIHRoZSBtb3RpdmF0aW9ucyBmb3IgYSBub2RlIHVzaW5nIG11bHRpcGxlPEJSPmludGVyZmFj ZXMgYW5kIHRoZSBzY2VuYXJpb3Mgd2hlcmUgaXQgbWF5IGVuZCB1cCB3aXRoIG11bHRpcGxlPEJS Pmdsb2JhbCBhZGRyZXNzZXMgb24gaXRzIGludGVyZmFjZXMgW0luZm9ybWF0aW9uYWxdPEJSPjxC Uj4tIEFuIGFuYWx5c2lzIGRvY3VtZW50IGV4cGxhaW5pbmcgd2hhdCBhcmUgdGhlIGxpbWl0YXRp b25zIGZvcjxCUj5tb2JpbGUgaG9zdHMgdXNpbmcgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIENhcmUt b2YgQWRkcmVzc2VzIGFuZCBIb21lPEJSPkFnZW50IGFkZHJlc3NlcyB1c2luZyBNb2JpbGUgSVB2 Niwgd2hldGhlciBpc3N1ZXMgYXJlIHNwZWNpZmljIHRvPEJSPk1vYmlsZSBJUHY2IG9yIG5vdCBb SW5mb3JtYXRpb25hbF0uPEJSPjxCUj5JIHRoaW5rIHRoaXMgaXMgdmVyeSBzaW1pbGFyIHRvIHRo ZSBzY29wZSBvZiBvbmUgb2YgeW91IGRvY3VtZW50cyBhdDxCUj5sZWFzdCwgc28gaSB3b3VsZCBm aW5kIHZlcnkgc3RyYW5nZSB0aGF0IHRoZSBzYW1lIHdvcmsgaXMgY2hhcnRlcmVkIGluPEJSPnR3 byBkaWZmZXJlbnQgd29ya2luZyBncm91cHMuPEJSPjxCUj5Nb3Jlb3Zlciwgd2UgZG8gaGF2ZSB3 ZyBkb2N1bWVudHMgZm9yIHRoZXNlIHR3bywgYnV0IHdlIGZpbmQgdmVyeSBoYXJkPEJSPnRvIGZp bmQgcmV2aWV3ZXJzIGZvciB0aG9zZSwgd2hpY2ggbWFrZXMgbWUgdGhpbmsgdGhhdCB0aGVyZSBp cyBub3QgbXVjaDxCUj5pbnRlcmVzdCBvbiB0aGVzZS4gU28sIGlmIHlvdSBmaW5kIGEgbW9yZSBt b3RpdmF0ZWQgY3JldyB0byBkbyB0aGUgd29yayw8QlI+dGhhdCB3b3VsZCBiZSBncmVhdCwgd2Ug Y2FuIGVpdGhlciBkbyBpdCBpbiBtZXh0IG9yIHNvZW13aGVyZSBlbHNlLCBpZjxCUj5wZW9wbGUg ZmVlbHMgdGhhdCBuZWVkcyB0byBiZSBkb25lLCBidXQgdGhhdCBpcyBjZXJ0YWlubHkgbm90IHRo ZTxCUj5mZWVsaW5nIGkgYW0gZ2V0dGluZyBmcm9tIHRoZSBpbnB1dCBpbiBtZXh0PEJSPjxCUj5S ZWdhcmRzLCBtYXJjZWxvPEJSPjxCUj48QlI+PEJSPkhvbmcgWW9uZy1HZXVuIGVzY3JpYmk/OjxC Uj4mZ3Q7PEJSPiZndDsgSGksIGFsbCBpbiBNRVhUIGFuZCBtaWYuPEJSPiZndDs8QlI+Jmd0OyAm Z3Q7PEJSPiZndDsgSW4gSUVURiBtaWYgKE11bHRpcGxlIEludGVyZmFjZSkgbWFpbGluZyBsaXN0 PEJSPiZndDsgKF88QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pZl8iIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9taWZfPC9BPjxCUj4mZ3Q7ICZsdDs8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21pZjwvQT4mZ3Q7KSw8QlI+Jmd0OzxCUj4mZ3Q7IHdlIG5vdyBkaXNjdXNz IHRoZSBob3N0IHdoaWNoIHdvdWxkIGxpa2UgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMuPEJS PiZndDs8QlI+Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCBNRVhUIFdHIGlzIGFsc28gcmVsYXRlZCB0 byB0aGUgdXNlIG9mIG11bHRpcGxlPEJSPiZndDsgaW50ZXJmYWNlcyBvZiBhIGhvc3Q8QlI+Jmd0 OyB1c2luZyBNb2JpbGUgSVB2NiBvciBhIG1vYmlsZSByb3V0ZXIgdXNpbmcgTkVNTyBCYXNpYyBT dXBwb3J0IGFuZDxCUj4mZ3Q7IHRoZWlyIHZhcmlhbnRzPEJSPiZndDs8QlI+Jmd0OyBNRVhUIFdH IGlzIGZvY3Vpbmcgb24gbW9uYW1pNiByZWxhdGVkIHRvcGljIChtdWx0aXBsZSBDb0EsIE11bHRp cGxlPEJSPiZndDsgSG9BLCBhbmQgTXVsdHBsZSBIQSwgZXRjLiwpPEJSPiZndDsgYW5kIGV4dGVk bmluZyBNb2JpbGUgSVB2NiBhbmQgTkVNTyBmb3IgdGhlc2UsIGJ1dCBtaWYgaXMgbm90IHJlbGF0 ZWQ8QlI+Jmd0OyB0byB0aGlzIGRpcmVjdGlvbi48QlI+Jmd0OyBJbiBtaWYsIHNvdXJjZSBhZGRy ZXNzIHNlbGVjdGlvbiwgcm91dGluZyBhbmQgRE5TIGNvbnRyb2wgcHJvdG9jb2wgYXJlPEJSPiZn dDsgY29uc2lkZXJhdGlvbiBpdGVtczxCUj4mZ3Q7IGR1ZSB0byBtdWx0aXBsZSBpbnRlcmZhY2Vz IG9mIGEgaG9zdC48QlI+Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyBGb3IgbWlmJ3Mgc2NvcGUs IEphcmkgQXJra28gbWFkZSBzb21lIGNvbW1lbnRzIGFuZCBjbGFzc2lmaWNhdGlvbiBvZjxCUj4m Z3Q7IHByb2JsZW1zLjxCUj4mZ3Q7PEJSPiZndDsgXzxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9taWYvY3VycmVudC9tc2cwMDA1MC5odG1sXyIgdGFyZ2V0PV9i bGFuaz5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlmL2N1cnJlbnQvbXNn MDAwNTAuaHRtbF88L0E+PEJSPiZndDs8QlI+Jmd0OyBBbW9uZyB0aGVzZSBjbGFzc2lmaWNhdGlv biB3aGljaCBpbmNsdWRlcyBhY2Nlc3Mgc2VsZWN0aW9uLCBzcGxpdCBETlMsPEJSPiZndDsgY29u ZmlndXJhdGlvbiByZWNvbmNpbGlhdGlvbiw8QlI+Jmd0OyByb3V0aW5nLCBhZGRyZXNzIHNlbGVj dGlvbiwgdHVubmVsIG11bHRpaG9taW5nLCBhbmQgdGhlIGNvbW11bmljYXRpb248QlI+Jmd0OyB3 YXkgYmV0d2VlbiB0aGUgaG9zdCBhbmQ8QlI+Jmd0OyB0aGUgbmV0d29yayBhYm91dCB0aGVpciBw b2xpY2llcyByZWdhcmRpbmcgYWxsIG9mIHRoZSBhYm92ZSwgSmFyaSBzYWlkPEJSPiZndDsgdGhh dCBhY2Nlc3Mgc2VsZWN0aW9uIGlzIGFscmVhZHk8QlI+Jmd0OyBjb3ZlcmQgaW4gUkZDIDUxMTMg YW5kIHR1bm5lbCBtdWx0aWhvbWluZyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gTUVYVDxCUj4mZ3Q7 IFdHIHdvcmsgaXRlbXMuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgQXQgbW9uYW1pNiBX RyBpbiA2NHRoIElFVEYgbWVldGlubmcsIEkgc3VibWl0dGVkIGFuZCBwcmVzZW50ZWQgdHdvPEJS PiZndDsgSW50ZXJuZXQgRHJhZnRzLjxCUj4mZ3Q7PEJSPiZndDsgLSBBbmFseXNpcyBvZiBtdWx0 aXBsZSBpbnRlcmZhY2VzIGluIGEgTW9iaWxlIE5vZGU8QlI+Jmd0OzxCUj4mZ3Q7IF88QSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaG9uZy1tdWx0aXBsZWlmLW1uLXBiLXN0 YXRlbWVudC0wMC50eHRfIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1ob25nLW11bHRpcGxlaWYtbW4tcGItc3RhdGVtZW50LTAwLnR4dF88L0E+PEJSPiZndDs8 QlI+Jmd0OyAtIFZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgZm9yIG11bHRpcGxlIGludGVyZmFj ZXMgaW4gYSBNb2JpbGUgbm9kZTxCUj4mZ3Q7IHVzaW5nIE1vYmlsZSBJUHY2PEJSPiZndDs8QlI+ Jmd0OyBfPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWhvbmctdmlydHVh bGlmLW1uLW1pcHY2LTAwLnR4dF8iIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dF88L0E+PEJSPiZndDsgJmx0 OzxBIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ob25nLXZpcnR1YWxpZi1t bi1taXB2Ni0wMC50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWhvbmctdmlydHVhbGlmLW1uLW1pcHY2LTAwLnR4dDwvQT4mZ3Q7PEJSPiZndDs8QlI+Jmd0 OyBCZWNhdXNlIHRoZXNlIHR3byBkcmFmdHMgd2VyZSBub3QgaW4gdGhlIG1vbmFtaTYgV0cncyBz Y29wZSBhbmQ8QlI+Jmd0OyB2aXJ0dWFsIG5ldHdvcmsgaW50ZXJmYWNlIGRyYWZ0IHdhczxCUj4m Z3Q7PEJSPiZndDsgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIHRoZXJlIHdlcmUgbm90IGFkb3Bl ZCBpbiBtb25hbWk2IFdHJ3Mgd29yazxCUj4mZ3Q7IGl0ZW1zLiBUaGUgaW50ZW50aW9ucyBvZiB0 d28gZHJhZnRzPEJSPiZndDsgYXJlIHN1cHBvcnRpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiBh IGhvc3Qgd2l0aG91dCBleHRlbmRpbmcgTW9iaWxlPEJSPiZndDsgSVB2Ni9ORU1PLjxCUj4mZ3Q7 PEJSPiZndDsgJmd0OzxCUj4mZ3Q7IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBpbnRlcmZhY2VzIHBy b2JsZW1zIG9mIGEgaG9zdCBhcmUgcmVsYXRlZCB0bzxCUj4mZ3Q7IGJvdGggTW9iaWxlIElQL05F TU8gc3BlY2lmaWMgaXNzdWVzIGFuZDxCUj4mZ3Q7IGdlbmVyYWwgbmV0d29yayBpc3N1ZXMuIE1v YmlsZSBJUC9ORU1PIHNwZWNpZmljIGlzc3VlcyBhcmUgcmVsYXRlZCB0bzxCUj4mZ3Q7IGV4dGVu ZGluZyBvZiBNb2JpbGUgSVAvTkVNTyBhbmQ8QlI+Jmd0OyB0aGVzZSBhcmUgYWxyZWFkeSBzdHVk aWVkIGluIE1FWFQgV0cgYW5kIGdlbmVyYWwgbmV0d29yayBpc3N1ZXMgd2hpY2g8QlI+Jmd0OyB3 ZXJlIG5vdCByZWxhdGVkIHRvPEJSPiZndDsgTW9iaWxlIElQL05FTU8gY291bGQgYmUgc3R1ZGll ZCBpbiBtaWYuIEFzIHNhbWUgbWFubmVyLCBJIHRoaW5rIHRoYXQ8QlI+Jmd0OyBteSBkcmFmdHMg Y291bGQgYmUgZGlzY3Vzc2VkIGFuZDxCUj4mZ3Q7IGRldmVsb3BlZCBpbiBtaWYuIEluIHRoZSBm aXJzdCBkcmFmdCAoQW5hbHlzaXMgZG9jdW1lbnQpLCBJIGNsYXNzaWZpZWQ8QlI+Jmd0OyBtdWx0 aXBsZSBpbnRlcmZhY2UgcHJvYmxlbXMgaW50bzxCUj4mZ3Q7IE1vYmlsZSBJUHY2LXNlcGNpZmlj IGlzc3VlcywgR2VuZXJhbCBuZXR3b3JrIGlzc3VlcywgYW5kIGhldGVyb2dlbmVvdXM8QlI+Jmd0 OyBlbnZpcm9ubWVudCBpc3N1ZXMuPEJSPiZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgSW5jbHVk aW5nIEh1aSBEZW5nIGluIG1pZiwgd2l0aCByZWdhcmRpbmcgdG8gdGhlc2UgZHJhZnRzLCB0aGV5 IHdhbnQ8QlI+Jmd0OyB0byBoZWFyIGNvbW1lbnRzIGZyb20gTUVYVCBXRydzIHBvaW50IG9mIHZp ZXcsPEJSPiZndDsgYmVjYXVzZSBpdCBzZWVtcyB0aGF0IHRoZXNlIGRyYWZ0cyBhcmUgcXVpdGUg cmVsYXRlZCB0byBtb25hbWk2L01FWFQ8QlI+Jmd0OyBXRy4gU28sIEkgYXNrIE1FWFQgdG8gcmV2 aWV3IHdoZXRoZXIgdGhlcmUgYXJlPEJSPiZndDs8QlI+Jmd0OyBzb21lIG92ZXJsYXAgYmV0d2Vl biBNRVhUIHdvcmtzIGFuZCBteSBkcmFmdHMgb3Igbm90LjxCUj4mZ3Q7PEJSPiZndDsgSXQgaXMg YXBwcmVjaWF0ZSB0byBnaXZlIGNvbW1lbnRzLjxCUj4mZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7 IEJlc3QgcmVnYXJkcy48QlI+Jmd0OzxCUj4mZ3Q7IFlvbmctR2V1bi48QlI+Jmd0OzxCUj48QlI+ PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjxCUj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvRElW PjwvRElWPjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9Imh0 dHA6Ly91bWFpbC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPW1pZkBp ZXRmLm9yZyZuYW1lPW1pZiU0MGlldGYub3JnJmZyb21lbWFpbD15Z2hvbmdAZXRyaS5yZS5rciZt ZXNzYWdlaWQ9JTNDMDZhMGFiMmEtNDk4YS00Yjg2LThlM2UtOTMzMzdkMWYxYTRhQGV0cmkucmUu a3IlM0UiPg== ------=_NextPart_000_29B2_01C982C5.FCBB47B0-- --===============0241580683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0241580683==-- From mif-bounces@ietf.org Thu Jan 29 17:52:01 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E363A6B00; Thu, 29 Jan 2009 17:52:01 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993BB3A6B00 for ; Thu, 29 Jan 2009 17:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjqk5bsfVxUE for ; Thu, 29 Jan 2009 17:51:59 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 218CC3A6403 for ; Thu, 29 Jan 2009 17:51:58 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 30 Jan 2009 10:51:40 +0900 Priority: normal X-ReadCheckName: mif%40ietf.org Thread-Topic: Re: [mif] Multiple interfaces problems in MEXT and mif X-ReadCheckMessageID: thread-index: AcmCfUtx9ESXBeVCSgmwzQJc5IY4rg== From: "Hong Yong-Geun" To: "Marc Blanchet" , "Scott Brim" Date: Fri, 30 Jan 2009 10:51:40 +0900 Comment: ??, u-??, Message-ID: <326f01c9827d$4b78f170$8310fe81@etri.info> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 X-OriginalArrivalTime: 30 Jan 2009 01:51:40.0738 (UTC) FILETIME=[4B957A20:01C9827D] Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hong Yong-Geun List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992741643==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org This is a multi-part message in MIME format. --===============0992741643== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----=_NextPart_000_3260_01C982C8.BB5BDE80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_3260_01C982C8.BB5BDE80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_3260_01C982C8.BB5BDE80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5JIGFncmVlIHRvIE1hcmMuPEJSPjxCUj5JdCBpcyBiZXR0ZXIgdG8gZGlzY3Vz cyBtaWYncyBzY29wZSB3aXRoIGEgcG9zc2libGUgY2hhcnRlci48QlI+PEJSPkJlc3QgcmVnYXJk cy48QlI+PEJSPllvbmctR2V1bi48L0RJVj4NCjxESVY+PEJSPi0tLS0t7JuQ67O4IOuplOyLnOyn gC0tLS0tPEJSPjxCPkZyb206PC9CPiAiTWFyYyBCbGFuY2hldCIgJmx0O21hcmMuYmxhbmNoZXRA dmlhZ2VuaWUuY2EmZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+IDIwMDktMDEtMzAg7Jik7KCEIDU6 NDE6NDg8QlI+PEI+VG86PC9CPiAiU2NvdHQgQnJpbSIgJmx0O3N3YkBlbXBsb3llZXMub3JnJmd0 OzxCUj48Qj5DYzo8L0I+ICJqdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSIgJmx0 O2p1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tJmd0OywgIm1pZkBpZXRmLm9yZyIg Jmx0O21pZkBpZXRmLm9yZyZndDssICJtZXh0QGlldGYub3JnIiAmbHQ7bWV4dEBpZXRmLm9yZyZn dDs8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbbWlmXSBNdWx0aXBsZSBpbnRlcmZhY2VzIHByb2Js ZW1zIGluIE1FWFQgYW5kIG1pZjxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9wbGFpbiBmb3JtYXQgLS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPlNjb3R0IEJyaW0gYSA/Y3Jp dCA6PEJSPiZndDsgRXhjZXJwdHMgZnJvbSBtYXJjZWxvIGJhZ251bG8gYnJhdW4gb24gVGh1LCBK YW4gMjksIDIwMDkgMDk6MDk6NTVQTTxCUj4mZ3Q7ICswMTAwOjxCUj4mZ3Q7Jmd0OyBtYWtlcyBz ZW5zZSB0byBtZTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBNYXJjIEJsYW5jaGV0IGVzY3JpYmk/ OjxCUj4mZ3Q7Jmd0OyZndDsgdG8gbWUsIHRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUg J211bHRpcGxlIGludGVyZmFjZScgaXNzdWU8QlI+Jmd0OyZndDsmZ3Q7IGlzIG5vdCBib3VuZCB0 byBtb2JpbGl0eSwgYW5kIG1vcmUgc3BlY2lmaWNhbGx5IHRvIG1vYmlsaXR5PEJSPiZndDsmZ3Q7 Jmd0OyBwcm90b2NvbHMgKG1vYmlsZUlQdjQsIG1vYmlsZWlwdjYsIG5lbW8sIC4uLikuPEJSPiZn dDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgVGhlcmVmb3JlLCB0aGUgTUlGIHdvcmsgaXMgbm90 IHNjb3BpbmcgYWJvdXQgbW9iaWxpdHkgcHJvdG9jb2xzIGFuZDxCUj4mZ3Q7Jmd0OyZndDsgc2hh bGwgbm90IHJlcXVpcmUgbW9iaWxpdHkgcHJvdG9jb2xzLjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDsmZ3Q7IEkgd291bGQgc2VlIHRoYXQgaWYgc29tZSBwYXJ0IG9mIHRoZSBNSUYgd29yayBp cyBsb29raW5nIGF0IHRoZTxCUj4mZ3Q7Jmd0OyZndDsgbW9iaWxpdHkgcHJvdG9jb2xzLCB0aGVu IHRoZXNlIHNob3VsZCBiZSB0aGVuICJ0cmFuc2ZlcmVkIiB0byBNRVhULjxCUj4mZ3Q7PEJSPiZn dDsgRXZlbiB3aXRob3V0IG1vYmlsaXR5IGNvbnNpZGVyYXRpb25zLCB0aGUgaXNzdWUgb2YgaG93 IHRvIGhhbmRsZTxCUj4mZ3Q7IG11bHRpcGxlIGludGVyZmFjZXMgb3ZlcmxhcHMgd2l0aCBJbnRB cmVhLCBSUkcsIGFuZCBCZWhhdmUgKHRob3NlIGFyZTxCUj4mZ3Q7IHRoZSBvbmVzIEkgY2FuIHRo aW5rIG9mIG9mZmhhbmQpLiZuYnNwOyBIYXZlIHlvdSBzZWVuIHRoZSBhcmd1bWVudHMsIGZvcjxC Uj4mZ3Q7IGV4YW1wbGUsIGFib3V0IHNlc3Npb24gaW5pdGlhbGl6YXRpb24gd2hlbiBtdWx0aXBs ZSBhZGRyZXNzZXMgY2FuIGJlPEJSPiZndDsgaW4gcGxheSBzaW11bHRhbmVvdXNseSBhdCBib3Ro IGVuZHM/Jm5ic3A7IEkgYXBvbG9naXplIGJ1dCBJIHN0aWxsIGRvbid0PEJSPiZndDsgdW5kZXJz dGFuZCB0aGUgTUlGIGJvdW5kYXJpZXMuPEJSPjxCUj5vZiBjb3Vyc2UsIHRoZXJlIGlzIG92ZXJs YXAsIGFzIG1vc3QgSUVURiBpc3N1ZXMgYW5kIHdvcmsgc3BhbiBvdmVyPEJSPm11bHRpcGxlIGdy b3Vwcy48QlI+PEJSPnRvIG1lLCB0aGUgcXVlc3Rpb24gaW4gaGFuZCBpcyB0aGUgZm9sbG93aW5n OjxCUj5hKSBkbyB3ZSB0aGluayB0aGlzIGlzIGEgInJlYWwiIHByb2JsZW08QlI+YikgaWYgeWVz LCB0aGVuIHdoYXQgc2hvdWxkIHdlIGRvIHdpdGggaXQuPEJSPmMpIGlmIHdoYXQgPSBwb3NzaWJs ZSB3ZywgdGhlbiB3cml0ZSBjaGFydGVyLCAuLi48QlI+PEJSPnRvIG1lLCBhKSBhbmQgYikgYXJl IGNsZWFybHkgc3ViamVjdCBvZiB0aGUgQk9GLiBjKSBkZXBlbmRzIG9uIHRoZTxCUj5vdXRjb21l IG9mIHRoZSBCT0YuPEJSPjxCUj5Mb29raW5nIGF0IHRoZSB2YXJpb3VzIGNvbW1lbnRzIG92ZXIg dGhlIHBhc3Qgd2Vla3MsIGl0IG1pZ2h0IGJlIGdvb2Q8QlI+dGhhdCB3ZSAodGhlIGluaXRpYWwg cHJvcG9zZXJzIG9yIGFueW9uZSBJIHNoYWxsIHNheSkgc2hvdWxkIHdyaXRlIGE8QlI+cG9zc2li bGUgd2cgY2hhcnRlciBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMuIFdlIG1pZ2h0IHRoZW4gZGVm aW5lIHRoZTxCUj5zY29wZSBhbmQgdGhlIG91dCBvZiBzY29wZS4uLjxCUj48QlI+TWFyYy48QlI+ Jmd0OzxCUj4mZ3Q7IFRoYW5rcyAuLi4gU2NvdHQ8QlI+PEJSPjxCUj4tLTxCUj49PT09PT09PT08 QlI+SVB2NiBib29rOiBNaWdyYXRpbmcgdG8gSVB2NiwgV2lsZXkuIDxBIGhyZWY9Imh0dHA6Ly93 d3cuaXB2NmJvb2suY2EvIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaXB2NmJvb2suY2E8L0E+ PEJSPlN0dW4vVHVybiBzZXJ2ZXIgZm9yIFZvSVAgTkFULUZXIHRyYXZlcnNhbDogPEEgaHJlZj0i aHR0cDovL251bWIudmlhZ2VuaWUuY2EvIiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly9udW1iLnZpYWdl bmllLmNhPC9BPjxCUj5EVE4gbmV3cyBzZXJ2aWNlOiA8QSBocmVmPSJodHRwOi8vcmVldmVzLnZp YWdlbmllLmNhLyIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vcmVldmVzLnZpYWdlbmllLmNhPC9BPjxC Uj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ bWlmIG1haWxpbmcgbGlzdDxCUj5taWZAaWV0Zi5vcmc8QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L0E+PEJSPjwvRk9OVD48L1A+PC9ESVY+PC9E SVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0i aHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9bWlm QGlldGYub3JnJm5hbWU9bWlmJTQwaWV0Zi5vcmcmZnJvbWVtYWlsPXlnaG9uZ0BldHJpLnJlLmty Jm1lc3NhZ2VpZD0lM0NhMTE0NTQ3ZS1hZmFlLTRiNTktOGZkMi0yOGVlMGI0ZGExMmJAZXRyaS5y ZS5rciUzRSI+ ------=_NextPart_000_3260_01C982C8.BB5BDE80-- --===============0992741643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0992741643==-- From mif-bounces@ietf.org Sat Jan 31 22:35:08 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F79D3A6B6F; Sat, 31 Jan 2009 22:35:07 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4373A6B6F for ; Sat, 31 Jan 2009 22:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF2GaIX9d3Ao for ; Sat, 31 Jan 2009 22:35:03 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id A7A5D3A679F for ; Sat, 31 Jan 2009 22:35:02 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so595699ana.4 for ; Sat, 31 Jan 2009 22:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lZVhlNI14RT+GDNsOd3gV0slaTgh/rQfo8j4pBaZ/Hc=; b=PbSlIvUCdqIrQpBwchjkvvcCaKFL9KyJye1NPN2wEIlgaXU5udn05C5k2u0spU0fzh Zz/XbIQKTzQQ0tPh+0vdJ9H4ezKV4jqpMQ7YS6xJ4nLCpGQ8nT9/DN2uMz7sBXO0KoJi N3jzWBknNqg1GrOrNd0QJXRjPykrDON2JbLBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZG7+9y3tqAk9E5ReVton4nmdOCuJkYSbareGOc78aGySwzikHcxdglsQylbZWQL6l cp166AlybbpnBBmqDhYSTO9IvG5gKN/wOO5mkbFDaURk6cF+Ah9Sb2E/T0fLGbAy3pph S92NzYMxCP8pFagK3gsVjlv+sCKBN6h17/Af0= MIME-Version: 1.0 Received: by 10.100.197.7 with SMTP id u7mr2098594anf.72.1233470083130; Sat, 31 Jan 2009 22:34:43 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Sun, 1 Feb 2009 14:34:43 +0800 Message-ID: <4c5c7a6d0901312234q76cd27c3meea120ef92455a42@mail.gmail.com> From: Peny Yang To: pierrick.seite@orange-ftgroup.com Cc: mif@ietf.org Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Pierrick: Check my lines please: On Thu, Jan 22, 2009 at 5:14 PM, wrote: > IMHO, MIF management should be independent from mobility protocol. Actually, multi-interface management can be described in 4 steps: > > 1. Initiation: management of events which are expected to start multi-interface management process (detection of new access network, loss of interface, user launch an application, etc....) > 2. Decision: The terminal selects the "best" interface to use. > 3. Preparation - e.g. acquisition of IP address on selected interface, AAA, and so on. > 4. Mobility execution - IP session continuity with MIP or derived > > IMU, MIF operation takes place on steps 2 and 3. Then, step 3 may, or may not, steer mobility protocol (step 4). If so, mobility protocol runs as specified in RFCs (3775, 5213,...), without interaction with MIF mechanisms. [Peny] Basically, I don't think we need to modify the MIP protocols. And, I also think MIF should be independent from the MIP protocols. In last email, I mean the harmonization between MIP stacks and MIF. In the case you mentioned above, in step 3, MIF may need to instruct the registration of MIP stack. Some local interfaces may help. In the meanwhile, if the registration of MIP fails, MIF function may need to change the policies. Lastly, MIP protocol may help the policy delivery, although it does not have to do that. Some other ideas? BRG Peny >> >> >> > Jari >> > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Sat Jan 31 22:45:05 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EA63A6B72; Sat, 31 Jan 2009 22:45:05 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244F73A6B72 for ; Sat, 31 Jan 2009 22:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbgYaRzd3KG4 for ; Sat, 31 Jan 2009 22:45:04 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id 0898D3A679F for ; Sat, 31 Jan 2009 22:45:03 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so596566ana.4 for ; Sat, 31 Jan 2009 22:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BUAZpm1/QHlw++kU9rlLWyuz7Ux8LE5f8kltImLB2TA=; b=m44+GKSASU1h160Tgh77ddGmz51kJeoeAJ2yD/gAs3U3LUMZnOBDwHON7PHUTi2PZi zFteSw1l8/R/waT0fioJH6xGhbsME6k/4dKGmbMvVsjwFdkT9r3KXwFSiRCSKFSDAJrQ fgmTSrgcNHYrZNbs5gM1ZkFMpa/iaraKss8mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aLnw+ka0DAabLwVXbWGfQl2NFXKJ5QooOKNC9F19dsBiIqeWhfq3QVUFoEdSd5yxk0 28YoG7Kpeq0uF2bkOnP3MhIQscEkKzmb8SkgCM+PjSq4mq0L7oh/PhOWvYGwTFZ5SzUk sjg2xudDifVwdLhZ365V96x1IIOvWRa2B9dUU= MIME-Version: 1.0 Received: by 10.100.122.12 with SMTP id u12mr2120131anc.78.1233470684130; Sat, 31 Jan 2009 22:44:44 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Sun, 1 Feb 2009 14:44:44 +0800 Message-ID: <4c5c7a6d0901312244s7dc903d4x8d8d5e9716af25ee@mail.gmail.com> From: Peny Yang To: Tao Sun Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Tao: Please check my lines below: On Fri, Jan 23, 2009 at 3:25 PM, Tao Sun wrote: > ==> let peer know the MIF node, it will break IP model of Internet > or have to be involved in mobility protocol, so I would recommend MIF not > working on that. [Peny] Sorry, I don't get your point here. What do you mean on "let peer know the MIF node"? If peer would like to set up a session with MIF node, it must at least know the address of MIF node. Did I miss something here? > ==> it is possible to allow network to communiate the policy, > but it will be diffcult to allow host and node to communicate with each > other about policy, right? [Peny] The peer does not have to communicate with MIF node for policies. It can consult with the network to get the policies. >> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >> need to do the harmonization with other protocols? > ==> I agree Pierrick's point here. [Peny] Please check my mail to Pierrick. >> 3) There is the case that one interface is connected, but the route to >> internet is not available (Such as WiFi Portal). How does MIF handle >> this case? > > ==> I guess that user should judge and decide how to handle this case. > what do you think? [Peny] Yeah. It's one of the possible solutions. IMHO, at least in the policies, such kind of cases should be covered. Otherwise, if some applications try to select such kind of interfaces and can not get connected, the user experience will be decreased greatly. BRG Peny > > >> >> BRG >> Peny >> >> >> > Jari >> > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Sat Jan 31 23:46:31 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE743A67FF; Sat, 31 Jan 2009 23:46:31 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD7A3A67FF for ; Sat, 31 Jan 2009 23:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDCzOO+1psqj for ; Sat, 31 Jan 2009 23:46:30 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id B32183A67E5 for ; Sat, 31 Jan 2009 23:46:29 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so601626ana.4 for ; Sat, 31 Jan 2009 23:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f+zo0i3GpXlBbFFhUnMwg4ZbVzl0QK4prO6C1l5NixQ=; b=Oqc5HAMZo+kVMPrFEHrcF0ueR4wnVzduH+e8TtxpKzcLQaw5jlrbqGZ9U6zJx5o5ZS W1bRnevUp171kQWX7X7oQ13YdLyFRQFClgtoa2sq8eV5OAOLtM9v/8q753GeuCU8vsig xr+9Ss/2yJAeYgYwxBKMQwWS+MveuFI8spIYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sCkX7LrkyFcYdc+Xf4YrmnUvdyzvtk2rMcrIBHV7yMwjSdM+UOK7f5Uv9tjfUHXfXa C8OI5DRzfN+OibXMmEJI2CSFyGUahfxqiY1884ohWPogy1ia4ojOZi2QCFge8hOYpaM+ W8kuzNVM+h+qfdYcMoNyidSDAKsW0onjmaXT8= MIME-Version: 1.0 Received: by 10.100.137.12 with SMTP id k12mr2109138and.124.1233474370084; Sat, 31 Jan 2009 23:46:10 -0800 (PST) In-Reply-To: References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <4c5c7a6d0901211806w11bc0381pc38345880fb9810d@mail.gmail.com> Date: Sun, 1 Feb 2009 15:46:10 +0800 Message-ID: <4c5c7a6d0901312346g7abd3dabjbee60a1eb8df5c28@mail.gmail.com> From: Peny Yang To: Kevin Chin Cc: mif Subject: Re: [mif] draft-blanchet X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Kevin: On Sat, Jan 24, 2009 at 2:20 AM, Kevin Chin wrote: > "communicate their policies among host/peer/network" seems to imply more > message intensive transfer of state from MS. [Peny] So far, I still can not judge how intensive the message exchange is, when peer want to know some policies of MS. Basically, if MS want one kind of sessions (like VoIP) go through one interface, when the peer tries to set up this session, the peer at least should know which interface of MS should be contacted. BRG Peny > thanks > > On Thu, Jan 22, 2009 at 11:16 PM, Tao Sun wrote: >> >> Hi, Kevin, >> >> I tend to agree with you here that the terminal may not need to upstream >> the capability to the network. but do you see any proposal here doing that? >> >> but sometime, MS made some decision on the interface and route, but what >> happen if network congested, how to handle that? just waiting for the fall >> back. >> >> For confliction of policy, I guess that it could be categorized by two >> case, >> one operator, then it should be avoided by offline arrangement, >> for two ISPs, FIFO still work there, cause no problem for user's traffic. >> >> thanks for the discussion. >> >> -Tao >> >> >> On Thu, Jan 22, 2009 at 11:32 AM, Kevin Chin wrote: >>> >>> >>>> >>>> 1) MIF for IPv4 or IPv6 or Both? >>> >>> >>>> >>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>> need to do the harmonization with other protocols? >>>> 3) There is the case that one interface is connected, but the route to >>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>> this case? >>> >>> >>> > 7) Is there a way for the host and the network to communicate about >>> > their >>> > policies regarding all of the above? >>> >>> Very interesting topic. >>> >>> I assume MIF is optional "should" v. "must" w.r.t policies from the >>> network (e.g. guidance not directive). >>> The MS may have lots of policies which can make an informed decision. >>> >>> As such IPv6, PMIP, DSMIP should not be considered in policies for MIF. >>> This would imply MS pushing characteristics up to the network so the >>> network can push device-specific directives down. >>> It should not be the case that the device needs to push capabilties >>> upstream for the network to provide MIF-based guidance. >>> >>> Furthermore there may be different networks on each interface >>> necessitating conflict resolution protocols, let alone issues that occur >>> sporadically (e.g. WiFI portal, network roaming policies, access-based >>> policy) .... >>> >>> Can't device based provisioning with (optional) input from network >>> address most of the stated issues? >>> >>> thanks- >>> Kevin >>> >>> On Wed, Jan 21, 2009 at 6:06 PM, Peny Yang >>> wrote: >>>> >>>> Hi, Jari: >>>> >>>> Please check my lines: >>>> >>>> On Thu, Jan 22, 2009 at 7:13 AM, Jari Arkko >>>> wrote: >>>> > Again, there seems to be two issues. The first issue is having a >>>> > policy that >>>> > tells an application which addresses to use (and indirectly which >>>> > interface >>>> > to use). The second issue is that if the policy comes, e.g., via DHCP >>>> > on a >>>> > per-interface basis, then we again have to reconcile the different >>>> > policies >>>> > on a per-node basis. >>>> [Peny] Agree with you for the two issues. Another point in my mind may >>>> be a possible issue. When a peer tries to initiate flows with MIF >>>> node, we need some way to let the peer know the policies and follow >>>> the policies of MIF node. >>>> >>>> > My personal classification of problems in the multiple interface space >>>> > includes the following: >>>> > >>>> > 1) Access selection, i.e., which network(s) to attach to using the >>>> > physical >>>> > interface(s) that the host has. Already covered in RFC 5113. >>>> > >>>> > 2) Split DNS: If a host is attached to a number of different >>>> > interfaces, how >>>> > does it resolve a FQDN if more than one interface has provided a DNS >>>> > server >>>> > address? >>>> > >>>> > 3) Configuration reconciliation: how do we merge and use DHCP and >>>> > other >>>> > configuration information in a node, when the information is received >>>> > on a >>>> > per-interface basis? >>>> > >>>> > 4) Routing: If a host is attached to a number of different interfaces, >>>> > where >>>> > does a particular IP packet go? >>>> > >>>> > 5) Address selection: If a host is attached to a number of different >>>> > interfaces, which addresses should be used for a particular >>>> > application >>>> > flow? >>>> > >>>> > 6) Tunnel multihoming: If a host is attached to a number of different >>>> > interfaces and runs some kind of a tunneling or mobility back to a >>>> > home >>>> > agent, which interface and addresses should be used for a particular >>>> > packet? >>>> > Already covered in existing MEXT WG work items. >>>> [Peny] Agree with you from 1 to 6. >>>> >>>> > 7) Is there a way for the host and the network to communicate about >>>> > their >>>> > policies regarding all of the above? >>>> [Peny] For 7, maybe we could make the way for host/PEER/network to >>>> communicate their policies. Besides, if the policies of MIF node can >>>> not be followed by the peer node, in this sense, we need a way to >>>> communicate about the policies among host/peer/network. >>>> >>>> > My understanding is that the proposed BOF would be looking at problems >>>> > 2, 3, >>>> > 4, 5, and 7. The others are covered elsewhere. >>>> [Peny] Some other points I have been thinking of: >>>> 1) MIF for IPv4 or IPv6 or Both? >>>> 2) Will MIF need to co-work with (P)MIP, DSMIP, etc? If so, do we >>>> need to do the harmonization with other protocols? >>>> 3) There is the case that one interface is connected, but the route to >>>> internet is not available (Such as WiFi Portal). How does MIF handle >>>> this case? >>>> >>>> BRG >>>> Peny >>>> >>>> >>>> > Jari >>>> > >>>> > _______________________________________________ >>>> > mif mailing list >>>> > mif@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mif >>>> > >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif