From Internet-Drafts@ietf.org Tue Feb 1 06:00:03 2011 Return-Path: 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 A9D6D3A6CEA; Tue, 1 Feb 2011 06:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 1tPTb-+5YAK9; Tue, 1 Feb 2011 06:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376C53A6C00; Tue, 1 Feb 2011 06:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201140002.18775.41047.idtracker@localhost> Date: Tue, 01 Feb 2011 06:00:02 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-current-practices-06.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: , X-List-Received-Date: Tue, 01 Feb 2011 14:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Current Practices for Multiple Interface Hosts Author(s) : M. Wasserman, P. Seite Filename : draft-ietf-mif-current-practices-06.txt Pages : 22 Date : 2011-02-01 An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-current-practices-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-01054923.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Tue Feb 1 06:38:28 2011 Return-Path: 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 43E183A6D2C for ; Tue, 1 Feb 2011 06:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 nroPy4ytYAXB for ; Tue, 1 Feb 2011 06:38:27 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 9AF343A6D0E for ; Tue, 1 Feb 2011 06:38:26 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 27D296C0009; Tue, 1 Feb 2011 15:42:12 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1BE286C0008; Tue, 1 Feb 2011 15:42:12 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 15:41:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 15:41:41 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: ActhmNZW/ik6sbrgTwK5zdMFE2uu0QO1SYAwFGseqwA= References: <4CA62C43.5080105@piuha.net> From: To: , X-OriginalArrivalTime: 01 Feb 2011 14:41:42.0578 (UTC) FILETIME=[2467C920:01CBC21E] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Tue, 01 Feb 2011 14:38:28 -0000 Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed.=20 BR, Pierrick > -----Message d'origine----- > De=A0: SEITE Pierrick RD-RESA-REN > Envoy=E9=A0: samedi 23 octobre 2010 12:01 > =C0=A0: mif@ietf.org; jari.arkko@piuha.net > Objet=A0: RE: [mif] AD review of draft-ietf-mif-current-practices >=20 > Hi Jari, all, >=20 > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. >=20 > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: >=20 > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? >=20 > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. >=20 > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? >=20 >=20 > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. >=20 > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? >=20 >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9=A0: vendredi 1 octobre 2010 20:45 > > =C0=A0: mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet=A0: [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > >=20 > NEW TEXT: >=20 > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. >=20 > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? >=20 > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. >=20 > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > >=20 > Ok, text has been revised. >=20 > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. >=20 > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. >=20 > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. >=20 > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > >=20 > Yep, we need additional information from vendors.... >=20 > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > >=20 > Fixed >=20 > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > >=20 > We meant: a terminal which remains under coverage of the same AP. >=20 > The test has been revised. >=20 > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > >=20 > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". >=20 > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > >=20 > Ok, fixed >=20 > > Jari > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif From sfaccin@rim.com Fri Feb 4 11:28:40 2011 Return-Path: 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 9C5E13A6A0D for ; Fri, 4 Feb 2011 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 teNsIAjrS4Br for ; Fri, 4 Feb 2011 11:28:38 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 16BF23A69CF for ; Fri, 4 Feb 2011 11:28:38 -0800 (PST) X-AuditID: 0a401fcb-b7c02ae0000009e2-29-4d4c543258c8 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 17.3F.02530.2345C4D4; Fri, 4 Feb 2011 14:32:02 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Feb 2011 14:32:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC4A2.30A99749" Date: Fri, 4 Feb 2011 13:32:00 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F3E6@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvEohSlQQGti4hKQfq1WjvzI/3TSgAAAcPQ References: <4CA62C43.5080105@piuha.net><843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> From: "Stefano Faccin" To: X-OriginalArrivalTime: 04 Feb 2011 19:32:03.0047 (UTC) FILETIME=[330DA770:01CBC4A2] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Fri, 04 Feb 2011 19:28:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC4A2.30A99749 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to= just "applications", since I believe we want to capture the most generic ca= se of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application connecting to= the Internet, can use either the BlackBerry Internet Service or the Interne= t gateway of the wireless server provider to manage connections". Can we mod= ify this to "... can use either the BlackBerry Internet Service or the Inter= net gateway of the wireless server provider or direct Internet connectivity= over WLAN to ..." for correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry behaves= differently, the connection manager selects the first SSID on which it has= managed to attach in the past." Please replace this statement with "The RIM= Blackberry behaves differently: the user (e.g. the enterprise owning the de= vice) is allowed to define its preferred access. The connection manager sele= cts the first SSID of the preferred list of SSIDs configured in the device a= nd that is available based on the WLAN scan the device has performed", since= it is not true that the BlackBerry always tries first the last SSID it has= managed to attach in the past. The section also contain a statement that does not apply to all devices, i.e= . "When the IP stack fails to obtain an IP address, the handset, excepted th= e iPhone, restarts WLAN attachment selecting the second SSID in the list. "= The BlackBerry, when it fails to obtain an IP address after successful WLAN= attachment, performs a new WLAN scan and, among the networks available, it= selects the next SSID in the preferred list, which means that the approach= is different from the one the original sentence tries to capture. Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices (http://www= .ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.txt). Accordin= g to your comments, Nokia (thanks again Teemu), Andro=EFd and Linux sections= have been updated with information regarding DNS configuration, RFC3484 sup= port, RFC1122 status and address overlapping issue. Section "Apple" has been= removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows implement > RFC3484 (I've just noticed that only the windows section refers to RFC3484= , > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well documented. > But others sections must be developed. Reflecting Jari's comment: is DNS > configuration per-node or per-interface? If an application is bound to an > interface, does it always use the DNS settings for exactly that interface > or the per-node settings. > > - address space overlapping: we do not have information on these issues > and we'd appreciate feedback from the WG (especially from manufacturers > involved in MIF). When the terminal is simultaneously attached to several > interfaces, is the OS manage address space overlapping? If yes, how does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and Linux > section. If we do not have more information for apple mac os, we'll remove > the section. > > - Android: can we consider that basic android kernel (excluding vendors > specific implementations) manages multiple interfaces issues in the same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection problem, > > which has already been discussed extensively in RFC 5113. It is fine to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, are > > DNS settings per-node or per-interface, if an application is bound to an > > interface does it always use the DNS settings for exactly that interface > > or the per-node settings, what happens with overlapping address space, > etc. > > > > The document is somewhat imbalanced, there's very little (too little) > > information about some devices and operating systems whereas the Windows > > description is detailed and informative. I would suggest that some of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update of > the routing functionality in the case where the terminal can be attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple applications > > can use different networks simultaneously?`Please be more precise about > > what is actually happening, as opposed to claiming a general capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard to > > get information, but at least some of these devices are open source and > > run on top of standard kernels such as Linux, so it should be possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's true > that Android is based on a Linux kernel but some functions are sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android terminal > cannot run IPv6 only, they need getting an IPv4 address first, and then, > even with IPv6 support some android cannot manage multiple IPv6 prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure is > not > > > supported for motionless terminals. Actually, the connection > > > manager always selects the most powerful signal strength without > > > considering IP configuration results. In other words, if the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBC4A2.30A99749 Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hello all= ,
I have reviewed version 06 of the draft and I have a few comments.
<= br>Under section 3.1.3 on the BlackBerry, I would modify "Java applicat= ions" to just "applications", since I believe we want to capt= ure the most generic case of BlackBerry, independently of the OS.

Und= er section 3.1.3 on the BlackBerry, it says "An application connecting= to the Internet, can use either the BlackBerry Internet Service or the Inte= rnet gateway of the wireless server provider to manage connections". Ca= n we modify this to "... can use either the BlackBerry Internet Service= or the Internet gateway of the wireless server provider or direct Internet= connectivity over WLAN to ..." for correctness/completeness?

In= section 3.1.7 there is an incorrect statement "The RIM Blackberry beha= ves differently, the connection manager selects the first SSID on which it h= as managed to attach in the past." Please replace this statement with &= quot;The RIM Blackberry behaves differently: the user (e.g. the enterprise o= wning the device) is allowed to define its preferred access. The connection= manager selects the first SSID of the preferred list of SSIDs configured in= the device and that is available based on the WLAN scan the device has perf= ormed", since it is not true that the BlackBerry always tries first the= last SSID it has managed to attach in the past. 

The section a= lso contain a statement that does not apply to all devices, i.e. "When the IP stack fails to obtain an IP address,= the handset, excepted the iPhone, restarts WLAN attachment selecting the se= cond SSID in the list. " The BlackBerry, when it fails to obtain= an IP address after successful WLAN attachment, performs a new WLAN scan an= d, among the networks available, it selects the next SSID in the preferred l= ist, which means that the approach is different from the one the original se= ntence tries to capture.

Cheers,

Stefano

 

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.se= ite@orange-ftgroup.com> wrote:

Hel= lo Jari,

I've submitted a new version of draft-ietf-mif-current-pract= ices (http://www.ietf.org/internet-drafts/draf= t-ietf-mif-current-practices-06.txt). According to your comments, Nokia= (thanks again Teemu), Andro=EFd and Linux sections have been updated with i= nformation regarding DNS configuration, RFC3484 support, RFC1122 status and= address overlapping issue. Section "Apple" has been removed.
<= br>BR,
Pierrick

> -----Message d'origine-----
> De := SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 1= 2:01
> =C0 : mi= f@ietf.org; ja= ri.arkko@piuha.net
> Objet : RE: [mif] AD review of draft-iet= f-mif-current-practices

>
>= Hi Jari, all,
>
> We've submitted a new version of the draft-ie= tf-mif-current-practices
> (More details inline). However, there is a= pending issue: we still need
> additional information, especially fro= m manufacturers, to address your
> concern with section 3.1.
>> So, we request the support from the WG, especially from folks who hav= e
> provided per-OS initial information, to address Jari's concerns. I= nterface
> selection is, generally, well documented but we need more d= etails on
> following topics:
>
> - Address selection: is= RFC 3484 supported? Linux and windows implement
> RFC3484 (I've just= noticed that only the windows section refers to RFC3484,
> I'll align= the linux section in the next version), but what about the
> others (= nokia, blackberry, windows mobile, android)?
>
> - DNS resolutio= n issues: Windows and Linux section are well documented.
> But others= sections must be developed. Reflecting Jari's comment: is DNS

> configuration per-node or per-interface? If= an application is bound to an

>= interface, does it always use the DNS settings for exactly that interface

> or the per-node settings.<= /o:p>

>
> - address space overlapping:= we do not have information on these issues
> and we'd appreciate feed= back from the WG (especially from manufacturers
> involved in MIF). Wh= en the terminal is simultaneously attached to several
> interfaces, is= the OS manage address space overlapping? If yes, how does
> it work?<= br>>
>
> - The section "Apple Mac OS X" is poor in= comparison to windows and Linux
> section. If we do not have more inf= ormation for apple mac os, we'll remove
> the section.
>
>= - Android: can we consider that basic android kernel (excluding vendors
= > specific implementations) manages multiple interfaces issues in the sam= e
> way than the current Linux OS?
>
>
> Regards,> Pierrick
>
> > -----Message d'origine-----
> >= De : mif-bou= nces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Ar= kko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> >= =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of draft-ietf-mif-current-practi= ces
> >

> > I h= ave reviewed this document. Overall, this is a good document, but
> &g= t; some work still remains. My biggest issues were the following:
> &g= t;
> > The document is quite focused on the access network selectio= n problem,
> > which has already been discussed extensively in RFC= 5113. It is fine to
> > include discussion of the access network s= election problem as well,
> > because it is all part of the same pr= oblem space. But I would have
> > expected the document discuss in= more detail what the various
> > implementations do at layer 3. Fo= r instance, do they use RFC 3484, are
> > DNS settings per-node or= per-interface, if an application is bound to an
> > interface does= it always use the DNS settings for exactly that interface
> > or t= he per-node settings, what happens with overlapping address space,
> e= tc.
> >
> > The document is somewhat imbalanced, there's v= ery little (too little)
> > information about some devices and oper= ating systems whereas the Windows
> > description is detailed and i= nformative. I would suggest that some of
> > the devices for which= there is very little information are either
> > removed from the d= ocument or some more information is inserted about
> them.
> >= ;
> > Detailed comments:
> >
> > Section 3.1.3 s/= in a MIF context/here/ (the MIF context is a fine term
> > to use i= n WG discussion, but will look odd in a published RFC by the
> > ti= me the WG has concluded).
> >
>

> > Section 3.1.7 says very little about the h= ard issues around MIF, such as
> > whether overlapping address spac= e is tolerated, whether there is a
> > possibility of some policy b= eing sent from the network, whether DNS info
> > is per node or per= interface, etc.
> >
> > But also other sections under 3.1= seem thin. I realize that its hard to
> > get information, but at= least some of these devices are open source and
> > run on top of= standard kernels such as Linux, so it should be possible
> > to fi= nd out a bit more.
>

>= ; I guess you are referencing to android terminals; I was also thinking that=
> the behaviour of an android could be deduced from current Linux
= > functionalities but it seems that the situation is more complex. It's t= rue
> that Android is based on a Linux kernel but some functions are s= ometimes
> customized by vendors. So we sometimes experience different= behaviour
> between different android terminals. For instance, some a= ndroid terminal
> cannot run IPv6 only, they need getting an IPv4 addr= ess first, and then,
> even with IPv6 support some android cannot mana= ge multiple IPv6 prefixes
> on a single interface; some others inhibit= the 3G/WLAN multihoming....
> while all these functions are well supp= orted on a Linux laptop. Note that
> it is not just a matter of config= uration since and the only way to
> overcome these limitations is to c= hange the android platform.
>
> I've added in the text that beha= viour of an android terminal can depends
> on the vendors implementati= on.
>

> Ok, fixed<= o:p>



--
Stefano M. Faccin
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




-- Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
May the Force be with you

-----------------------= ----------------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBC4A2.30A99749-- From sfaccinstd@gmail.com Fri Feb 4 11:27:21 2011 Return-Path: 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 D6AF83A68FC for ; Fri, 4 Feb 2011 11:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.438 X-Spam-Level: X-Spam-Status: No, score=-103.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 5klsw0WIhHcv for ; Fri, 4 Feb 2011 11:27:19 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 35CF63A6952 for ; Fri, 4 Feb 2011 11:27:19 -0800 (PST) Received: by qwi2 with SMTP id 2so2193137qwi.31 for ; Fri, 04 Feb 2011 11:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=a/T2G2LEiEkb0X3J6uZTZ2cQRDzMdnlonCTHCVrzitw=; b=AzcU/cbjgGcKGwNN2hVch6sc4bqcDXj1T3RKNZU3H423q4nC6eaBIP40KEsRkGxfia XU7UX82d96n6gjLA/2n4trTsOKT1yi/7upPw93tk/eIasWXw0UEe/Kb7BD/8tPye8HTN YR5dL4YSu6PeQ8hq3WradR/tCGB0PeQ0hZ6NE= 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 :content-type; b=SfiWs6umbBQ2dYhswrNST5q4TdwhuvxiFjY9RdEHHDdkOkM1jqurBTxsnKCm4gz919 7fsVumBHYay1MPAdxP+7c24kDTqXMDMGCyd+dN+m5Y2efPbIxKs10zoEsytOLh/PkteK rUxxt3VKZUU+FYcc/gsUCI4AzGbmwwJgVgtZE= MIME-Version: 1.0 Received: by 10.229.233.19 with SMTP id jw19mr8838907qcb.24.1296847844550; Fri, 04 Feb 2011 11:30:44 -0800 (PST) Received: by 10.229.20.70 with HTTP; Fri, 4 Feb 2011 11:30:44 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> References: <4CA62C43.5080105@piuha.net> <843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> Date: Fri, 4 Feb 2011 11:30:44 -0800 Message-ID: From: stefano faccin To: mif@ietf.org, jari.arkko@piuha.net Content-Type: multipart/alternative; boundary=0016363b8b701a293b049b79eb9f X-Mailman-Approved-At: Sat, 05 Feb 2011 03:02:11 -0800 Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Fri, 04 Feb 2011 19:27:22 -0000 --0016363b8b701a293b049b79eb9f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java applications" t= o just "applications", since I believe we want to capture the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application connecting t= o the Internet, can use either the BlackBerry Internet Service or the Interne= t gateway of the wireless server provider to manage connections". Can we modify this to "... can use either the BlackBerry Internet Service or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry behave= s differently, the connection manager selects the first SSID on which it has managed to attach in the past." Please replace this statement with "The RIM Blackberry behaves differently: the user (e.g. the enterprise owning the device) is allowed to define its preferred access. The connection manager selects the first SSID of the preferred list of SSIDs configured in the device and that is available based on the WLAN scan the device has performed", since it is not true that the BlackBerry always tries first the last SSID it has managed to attach in the past. The section also contain a statement that does not apply to all devices, i.e. "When the IP stack fails to obtain an IP address, the handset, excepte= d the iPhone, restarts WLAN attachment selecting the second SSID in the list."The BlackBerry, when it fails to obtain an IP address after successful WLAN attachment, performs a new WLAN scan and, among the networks available, it selects the next SSID in the preferred list, which means that the approach is different from the one the original sentence tries to capture. Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, wrote: > Hello Jari, > > I've submitted a new version of draft-ietf-mif-current-practices ( > http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.t= xt). > According to your comments, Nokia (thanks again Teemu), Andro=EFd and Lin= ux > sections have been updated with information regarding DNS configuration, > RFC3484 support, RFC1122 status and address overlapping issue. Section > "Apple" has been removed. > > BR, > Pierrick > > > -----Message d'origine----- > > De : SEITE Pierrick RD-RESA-REN > > Envoy=E9 : samedi 23 octobre 2010 12:01 > > =C0 : mif@ietf.org; jari.arkko@piuha.net > > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > > > Hi Jari, all, > > > > We've submitted a new version of the draft-ietf-mif-current-practices > > (More details inline). However, there is a pending issue: we still need > > additional information, especially from manufacturers, to address your > > concern with section 3.1. > > > > So, we request the support from the WG, especially from folks who have > > provided per-OS initial information, to address Jari's concerns. > Interface > > selection is, generally, well documented but we need more details on > > following topics: > > > > - Address selection: is RFC 3484 supported? Linux and windows implement > > RFC3484 (I've just noticed that only the windows section refers to > RFC3484, > > I'll align the linux section in the next version), but what about the > > others (nokia, blackberry, windows mobile, android)? > > > > - DNS resolution issues: Windows and Linux section are well documented. > > But others sections must be developed. Reflecting Jari's comment: is DN= S > > configuration per-node or per-interface? If an application is bound to = an > > interface, does it always use the DNS settings for exactly that interfa= ce > > or the per-node settings. > > > > - address space overlapping: we do not have information on these issues > > and we'd appreciate feedback from the WG (especially from manufacturers > > involved in MIF). When the terminal is simultaneously attached to sever= al > > interfaces, is the OS manage address space overlapping? If yes, how doe= s > > it work? > > > > > > - The section "Apple Mac OS X" is poor in comparison to windows and Lin= ux > > section. If we do not have more information for apple mac os, we'll > remove > > the section. > > > > - Android: can we consider that basic android kernel (excluding vendors > > specific implementations) manages multiple interfaces issues in the sam= e > > way than the current Linux OS? > > > > > > Regards, > > Pierrick > > > > > -----Message d'origine----- > > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > > Jari > > > Arkko > > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > > > I have reviewed this document. Overall, this is a good document, but > > > some work still remains. My biggest issues were the following: > > > > > > The document is quite focused on the access network selection problem= , > > > which has already been discussed extensively in RFC 5113. It is fine = to > > > include discussion of the access network selection problem as well, > > > because it is all part of the same problem space. But I would have > > > expected the document discuss in more detail what the various > > > implementations do at layer 3. For instance, do they use RFC 3484, ar= e > > > DNS settings per-node or per-interface, if an application is bound to > an > > > interface does it always use the DNS settings for exactly that > interface > > > or the per-node settings, what happens with overlapping address space= , > > etc. > > > > > > The document is somewhat imbalanced, there's very little (too little) > > > information about some devices and operating systems whereas the > Windows > > > description is detailed and informative. I would suggest that some of > > > the devices for which there is very little information are either > > > removed from the document or some more information is inserted about > > them. > > > > > > Detailed comments: > > > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine ter= m > > > to use in WG discussion, but will look odd in a published RFC by the > > > time the WG has concluded). > > > > > > > NEW TEXT: > > > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > > the routing functionality in the case where the terminal can be attache= d > > simultaneously to several interfaces. > > > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of > gateways > > > the text refers to. Default router, web proxy, application proxy, > > > something else? > > > > I agree that the original text was unclear. I've revised the section bu= t > > Giyeong, please check we kept ideas from your original text. > > > > On the second paragraph of the same section it is > > > unclear what "device" refers to. The entire device can use multiple > > > networks simultaneously? Does that mean that one application can use > > > multiple networks simultaneously, to the same destinations (like in > > > mp-tcp) or to different destinations? Or just that multiple > applications > > > can use different networks simultaneously?`Please be more precise abo= ut > > > what is actually happening, as opposed to claiming a general > capability. > > > > > > > Ok, text has been revised. > > > > > Section 3.1.7 says very little about the hard issues around MIF, such > as > > > whether overlapping address space is tolerated, whether there is a > > > possibility of some policy being sent from the network, whether DNS > info > > > is per node or per interface, etc. > > > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > > get information, but at least some of these devices are open source a= nd > > > run on top of standard kernels such as Linux, so it should be possibl= e > > > to find out a bit more. > > > > I guess you are referencing to android terminals; I was also thinking > that > > the behaviour of an android could be deduced from current Linux > > functionalities but it seems that the situation is more complex. It's > true > > that Android is based on a Linux kernel but some functions are sometime= s > > customized by vendors. So we sometimes experience different behaviour > > between different android terminals. For instance, some android termina= l > > cannot run IPv6 only, they need getting an IPv4 address first, and then= , > > even with IPv6 support some android cannot manage multiple IPv6 prefixe= s > > on a single interface; some others inhibit the 3G/WLAN multihoming.... > > while all these functions are well supported on a Linux laptop. Note th= at > > it is not just a matter of configuration since and the only way to > > overcome these limitations is to change the android platform. > > > > I've added in the text that behaviour of an android terminal can depend= s > > on the vendors implementation. > > > > Or we can ask for further information from the > > > people who gave us the original data, I suppose at least some of them > > > work for the manufacturers. > > > > > > > Yep, we need additional information from vendors.... > > > > > > iPhone > > > > > > > > Iphone > > > Inconsistent capitalization. > > > > > > > Fixed > > > > > > Whatever is the handset, fallback on L3 attachment failure is > > not > > > > supported for motionless terminals. Actually, the connection > > > > manager always selects the most powerful signal strength > without > > > > considering IP configuration results. In other words, if the > > > > terminal is unable to set up the IP connectivity on one wifi > > > > access, the connection manager will not try to attach to an > > > > alternative point of attachment (or SSID) as long as the sign= al > > > > strength of the first radio link is the most powerful. > > > > > > What is "motionless terminal"? All devices that you mention are mobil= e. > > > > > > > We meant: a terminal which remains under coverage of the same AP. > > > > The test has been revised. > > > > > Besides, I'm fairly certain that the above does not apply to Android. > > > The device that I have does seem to switch away from a strong-signal > > > SSID to another SSID, if L3 attachment fails. > > > > > > > Actually, we can have different behaviour with different Android > platforms > > (see above). The text in the doc applies only to the "HTC majic". > > > > > > in the scope of MIF. > > > > > > > > > > ... in the scope of this document. > > > > > > > Ok, fixed > > > > > 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 > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016363b8b701a293b049b79eb9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,
I have reviewed version 06 of the draft and I have a few comments.=

Under section 3.1.3 on the BlackBerry,= I would modify "Java applications" to just "applications&qu= ot;, since I believe we want to capture the most generic case of BlackBerry= , independently of the OS.

Under section 3.1.3 on the BlackBerry,= it says "An application connecting to the Internet, can use either the BlackBerry Internet Service or the Internet gateway of the wireless server provider t= o manage connections". Can we modify this to "... can use either the <= /span>BlackBerry Internet Service or the Internet gateway of the wireless server provider o= r direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect= statement "The RIM Blackberry behaves differently, the connection manager selects the first SSID on which it has mana= ged to attach in the past." Please replace this statement with "The RIM<= span> Blackberry behaves differently: the user (e.g. the enterprise = owning the device) is allowed to define its preferred access. The connection manager selects the first SSID of the preferred lis= t of SSIDs configured in the device and that is available based on the WLAN= scan the device has performed", since it is not true that the BlackBe= rry always tries first the last SSID it has managed to attach in the past.= =A0

The section also contain a statement t= hat does not apply to all devices, i.e. "W<= span style=3D"background-image: none; background-repeat: repeat; background= -attachment: scroll; background-position: 0% 0%; -moz-background-clip: bord= er; -moz-background-origin: padding; -moz-background-size: auto auto;">hen = the IP stack fails to obtain an IP address, the handset, excepted the iPhone, restarts WLAN attachment selecting the second SSID in the list. " The = BlackBerry, when it fails to obtain an IP address after successful WLAN att= achment, performs a new WLAN scan and, among the networks available, it sel= ects the next SSID in the preferred list, which means that the approach is = different from the one the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pier= rick.seite@orange-ftgroup.com> wrote:
Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mi= f-current-practices-06.txt). According to your comments, Nokia (thanks = again Teemu), Andro=EFd and Linux sections have been updated with informati= on regarding DNS configuration, RFC3484 support, RFC1122 status and address= overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De=A0: SEITE Pierrick RD-RESA-REN
> Envoy=E9=A0: samedi 23 octobre 2010 12:01
> =C0=A0: mif@ietf.org; jari.arkko@piuha.net
> Objet=A0: RE: [mif] AD review of draft-ietf-mif-current-practices
>
> Hi Jari, all,
>
> We've submitted a new version of the draft-ietf-mif-current-practi= ces
> (More details inline). However, there is a pending issue: we still nee= d
> additional information, especially from manufacturers, to address your=
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who have=
> provided per-OS initial information, to address Jari's concerns. I= nterface
> selection is, generally, well documented but we need more details on > following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows implemen= t
> RFC3484 (I've just noticed that only the windows section refers to= RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well documented= .
> But others sections must be developed. Reflecting Jari's comment: = is DNS
> configuration per-node or per-interface? If an application is bo= und to an
> interface, does it always use the DNS settings for e= xactly that interface
> or the per-node settings.
>
> - address space overlapping: we do not have information on these issue= s
> and we'd appreciate feedback from the WG (especially from manufact= urers
> involved in MIF). When the terminal is simultaneously attached to seve= ral
> interfaces, is the OS manage address space overlapping? If yes, how do= es
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to wind= ows and Linux
> section. If we do not have more information for apple mac os, we'l= l remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding vendor= s
> specific implementations) manages multiple interfaces issues in the sa= me
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De=A0: mif-bounces@ietf.o= rg [mailto:mif-bounces@ietf.org= ] De la part de
> Jari
> > Arkko
> > Envoy=E9=A0: vendredi 1 octobre 2010 20:45
> > =C0=A0: mif; draft-ietf-mif-current-practices@tools.ietf.org
> > Objet=A0: [mif] AD review of draft-ietf-mif-current-practices
> >
> > I have reviewed this document. Overall, t= his is a good document, but
> > some work still remains. My biggest issues were the following: > >
> > The document is quite focused on the access network selection pro= blem,
> > which has already been discussed extensively in RFC 5113. It is f= ine to
> > include discussion of the access network selection problem as wel= l,
> > because it is all part of the same problem space. But I would hav= e
> > expected the document discuss in more detail what the various
> > implementations do at layer 3. For instance, do they use RFC 3484= , are
> > DNS settings per-node or per-interface, if an application is boun= d to an
> > interface does it always use the DNS settings for exactly that in= terface
> > or the per-node settings, what happens with overlapping address s= pace,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too= little)
> > information about some devices and operating systems whereas the = Windows
> > description is detailed and informative. I would suggest that som= e of
> > the devices for which there is very little information are either=
> > removed from the document or some more information is inserted ab= out
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine= term
> > to use in WG discussion, but will look odd in a published RFC by = the
> > time the WG has concluded).
> >
>
> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update= of
> the routing functionality in the case where the terminal can be attach= ed
> simultaneously to several interfaces.
>
> > On Section 3.1.4 (BlackBerry) it was uncl= ear to me what type of gateways
> > the text refers to. Default router, web proxy, application proxy,=
> > something else?
>
> I agree that the original text was unclear. I&= #39;ve revised the section but
> Giyeong, please check we kept ideas from your original text.
>
> On the second paragraph of the same section it= is
> > unclear what "device" refers to. The entire device can = use multiple
> > networks simultaneously? Does that mean that one application can = use
> > multiple networks simultaneously, to the same destinations (like = in
> > mp-tcp) or to different destinations? Or just that multiple appli= cations
> > can use different networks simultaneously?`Please be more precise= about
> > what is actually happening, as opposed to claiming a general capa= bility.
> >
>
> Ok, text has been revised.
>
> > Section 3.1.7 says very little about the = hard issues around MIF, such as
> > whether overlapping address space is tolerated, whether there is = a
> > possibility of some policy being sent from the network, whether D= NS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that its h= ard to
> > get information, but at least some of these devices are open sour= ce and
> > run on top of standard kernels such as Linux, so it should be pos= sible
> > to find out a bit more.
>
> I guess you are referencing to android termina= ls; I was also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. It= 9;s true
> that Android is based on a Linux kernel but some functions are sometim= es
> customized by vendors. So we sometimes experience different behaviour<= br> > between different android terminals. For instance, some android termin= al
> cannot run IPv6 only, they need getting an IPv4 address first, and the= n,
> even with IPv6 support some android cannot manage multiple IPv6 prefix= es
> on a single interface; some others inhibit the 3G/WLAN multihoming....=
> while all these functions are well supported on a Linux laptop. Note t= hat
> it is not just a matter of configuration since and the only way to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can d= epends
> on the vendors implementation.
>
> Or we can ask for further information from the=
> > people who gave us the original data, I suppose at least some of = them
> > work for the manufacturers.
> >
>
> Yep, we need additional information from vendo= rs....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>
> > > =A0 =A0 =A0 Whatever is the handset,= fallback on L3 attachment failure is
> not
> > > =A0 =A0 =A0 supported for motionless terminals. =A0Actually,= the connection
> > > =A0 =A0 =A0 manager always selects the most powerful signal = strength without
> > > =A0 =A0 =A0 considering IP configuration results. =A0In othe= r words, if the
> > > =A0 =A0 =A0 terminal is unable to set up the IP connectivity= on one wifi
> > > =A0 =A0 =A0 access, the connection manager will not try to a= ttach to an
> > > =A0 =A0 =A0 alternative point of attachment (or SSID) as lon= g as the signal
> > > =A0 =A0 =A0 strength of the first radio link is the most pow= erful.
> >
> > What is "motionless terminal"? All devices that you men= tion are mobile.
> >
>
> We meant: a terminal which remains under cover= age of the same AP.
>
> The test has been revised.
>
> > Besides, I'm fairly certain that the = above does not apply to Android.
> > The device that I have does seem to switch away from a strong-sig= nal
> > SSID to another SSID, if L3 attachment fails.
> >
>
> Actually, we can have different behaviour with= different Android platforms
> (see above). The text in the doc applies only to the "HTC majic&q= uot;.
>
> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>
> Ok, fixed
>
> > Jari
> >
> > _______________________________________________
> > mif mailing list
> > mif@ietf.org
> > https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif



--
Stefano M. = Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the= Force be with you
--0016363b8b701a293b049b79eb9f-- From pierrick.seite@orange-ftgroup.com Mon Feb 7 00:39:59 2011 Return-Path: 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 33CBA3A6CC4 for ; Mon, 7 Feb 2011 00:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 9kiF4w9+8Zbo for ; Mon, 7 Feb 2011 00:39:44 -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 996783A694F for ; Mon, 7 Feb 2011 00:39:43 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA38C768002; Mon, 7 Feb 2011 09:44:51 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9B574760003; Mon, 7 Feb 2011 09:44:51 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 09:39:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC6A2.9271DA02" Date: Mon, 7 Feb 2011 09:39:45 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017967D3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybA References: <4CA62C43.5080105@piuha.net><843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> From: To: , , X-OriginalArrivalTime: 07 Feb 2011 08:39:46.0051 (UTC) FILETIME=[92D33D30:01CBC6A2] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 08:39:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6A2.9271DA02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefano, =20 Thanks for your comments, I'll update the draft accordingly. BTW, do you = have information on the following points for RIM blackberry: =20 - How the RIM blackberry manage Address selection: e.g. is RFC 3484 = supported?=20 =20 - DNS resolution issue on RIM blackberry: is DNS configuration per-node = or per-interface? If an application is bound to an interface, does it = always use the DNS settings for exactly that interface or the per-node = settings.=20 =20 - address space overlapping: When the RIM blackberry is simultaneously = attached to several interfaces, is the OS manage address space = overlapping? If yes, how does it work? =20 BR, Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java = applications" to just "applications", since I believe we want to capture = the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet = Service or the Internet gateway of the wireless server provider to = manage connections". Can we modify this to "... can use either the = BlackBerry Internet Service or the Internet gateway of the wireless = server provider or direct Internet connectivity over WLAN to ..." for = correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. =20 The section also contain a statement that does not apply to all devices, = i.e. "When the IP stack fails to obtain an IP address, the handset, = excepted the iPhone, restarts WLAN attachment selecting the second SSID = in the list. " The BlackBerry, when it fails to obtain an IP address = after successful WLAN attachment, performs a new WLAN scan and, among = the networks available, it selects the next SSID in the preferred list, = which means that the approach is different from the one the original = sentence tries to capture.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, = wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. > > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. > > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ------_=_NextPart_001_01CBC6A2.9271DA02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Stefano,

 =

Thanks for your = comments, I’ll update the draft accordingly. BTW, do you have information on = the following points for RIM blackberry:

 =

- How the RIM = blackberry manage Address selection: e.g. is RFC 3484 supported? =

 =

- DNS resolution = issue on RIM blackberry: is DNS configuration per-node or per-interface? If an application is bound to an interface, does it always use the DNS = settings for exactly that interface or the per-node settings. =

 =

- address space overlapping: When the RIM blackberry is simultaneously attached to = several interfaces, is the OS manage address space overlapping? If yes, how does = it work?

 

BR,

Pierrick

 =

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefano faccin
Envoy=E9 : vendredi = 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hello all,
I have reviewed version 06 of the draft and I have a few comments.

Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to just "applications", since I believe we = want to capture the most generic case of BlackBerry, independently of the = OS.

Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet Service or the = Internet gateway of the wireless server provider to manage connections". Can = we modify this to "... can use either the BlackBerry Internet Service = or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect statement "The RIM = Blackberry behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this statement = with "The RIM Blackberry behaves differently: the user (e.g. the = enterprise owning the device) is allowed to define its preferred access. The = connection manager selects the first SSID of the preferred list of SSIDs configured = in the device and that is available based on the WLAN scan the device has performed", since it is not true that the BlackBerry always tries = first the last SSID it has managed to attach in the past. 

The section also contain a statement that does not apply to all devices, i.e. "When the IP = stack fails to obtain an IP address, the handset, excepted the = iPhone, restarts WLAN attachment selecting the second SSID in the list. = " The BlackBerry, when it fails to obtain an IP address after successful = WLAN attachment, performs a new WLAN scan and, among the networks available, = it selects the next SSID in the preferred list, which means that the = approach is different from the one the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-f= tgroup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mif-curr= ent-practices-06.txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd and = Linux sections have been updated with information regarding DNS configuration, RFC3484 support, RFC1122 status and address overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 12:01
> =C0 : mif@ietf.org; jari.arkko@piuha.net
> Objet : RE: [mif] AD review of = draft-ietf-mif-current-practices

>
> Hi Jari, all,
>
> We've submitted a new version of the = draft-ietf-mif-current-practices
> (More details inline). However, there is a pending issue: we still = need
> additional information, especially from manufacturers, to address = your
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who = have
> provided per-OS initial information, to address Jari's concerns. = Interface
> selection is, generally, well documented but we need more details = on
> following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows = implement
> RFC3484 (I've just noticed that only the windows section refers to RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well = documented.
> But others sections must be developed. Reflecting Jari's comment: = is DNS

> configuration per-node or per-interface? If an application = is bound to an

> interface, does it always use the DNS settings for exactly = that interface

> or the per-node settings.

>
> - address space overlapping: we do not have information on these = issues
> and we'd appreciate feedback from the WG (especially from = manufacturers
> involved in MIF). When the terminal is simultaneously attached to = several
> interfaces, is the OS manage address space overlapping? If yes, how = does
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to = windows and Linux
> section. If we do not have more information for apple mac os, we'll = remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding = vendors
> specific implementations) manages multiple interfaces issues in the = same
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-iet= f-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of = draft-ietf-mif-current-practices
> >

> > I have reviewed this document. Overall, this is a good document, but
> > some work still remains. My biggest issues were the = following:
> >
> > The document is quite focused on the access network selection problem,
> > which has already been discussed extensively in RFC 5113. It = is fine to
> > include discussion of the access network selection problem as = well,
> > because it is all part of the same problem space. But I would = have
> > expected the document discuss in more detail what the = various
> > implementations do at layer 3. For instance, do they use RFC = 3484, are
> > DNS settings per-node or per-interface, if an application is = bound to an
> > interface does it always use the DNS settings for exactly that interface
> > or the per-node settings, what happens with overlapping = address space,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too = little)
> > information about some devices and operating systems whereas = the Windows
> > description is detailed and informative. I would suggest that = some of
> > the devices for which there is very little information are = either
> > removed from the document or some more information is inserted = about
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a = fine term
> > to use in WG discussion, but will look odd in a published RFC = by the
> > time the WG has concluded).
> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings = update of
> the routing functionality in the case where the terminal can be = attached
> simultaneously to several interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to me = what type of gateways
> > the text refers to. Default router, web proxy, application = proxy,
> > something else?
>

> I agree that the original text was unclear. I've revised = the section but
> Giyeong, please check we kept ideas from your original text.
>

> On the second paragraph of the same section it is
> > unclear what "device" refers to. The entire device = can use multiple
> > networks simultaneously? Does that mean that one application = can use
> > multiple networks simultaneously, to the same destinations = (like in
> > mp-tcp) or to different destinations? Or just that multiple applications
> > can use different networks simultaneously?`Please be more = precise about
> > what is actually happening, as opposed to claiming a general capability.
> >
>

> Ok, text has been revised.
>

> > Section 3.1.7 says very little about the hard issues = around MIF, such as
> > whether overlapping address space is tolerated, whether there = is a
> > possibility of some policy being sent from the network, = whether DNS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that = its hard to
> > get information, but at least some of these devices are open = source and
> > run on top of standard kernels such as Linux, so it should be possible
> > to find out a bit more.
>

> I guess you are referencing to android terminals; I was = also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. = It's true
> that Android is based on a Linux kernel but some functions are = sometimes
> customized by vendors. So we sometimes experience different = behaviour
> between different android terminals. For instance, some android = terminal
> cannot run IPv6 only, they need getting an IPv4 address first, and = then,
> even with IPv6 support some android cannot manage multiple IPv6 = prefixes
> on a single interface; some others inhibit the 3G/WLAN = multihoming....
> while all these functions are well supported on a Linux laptop. = Note that
> it is not just a matter of configuration since and the only way = to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can = depends
> on the vendors implementation.
>

> Or we can ask for further information from the
> > people who gave us the original data, I suppose at least some = of them
> > work for the manufacturers.
> >
>

> Yep, we need additional information from vendors....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>

> > >       Whatever is the handset, = fallback on L3 attachment failure is
> not
> > >       supported for motionless terminals.  Actually, the connection
> > >       manager always selects the most = powerful signal strength without
> > >       considering IP configuration = results.  In other words, if the
> > >       terminal is unable to set up the IP connectivity on one wifi
> > >       access, the connection manager will = not try to attach to an
> > >       alternative point of attachment (or = SSID) as long as the signal
> > >       strength of the first radio link is = the most powerful.
> >
> > What is "motionless terminal"? All devices that you = mention are mobile.
> >
>

> We meant: a terminal which remains under coverage of the = same AP.
>
> The test has been revised.
>

> > Besides, I'm fairly certain that the above does not = apply to Android.
> > The device that I have does seem to switch away from a = strong-signal
> > SSID to another SSID, if L3 attachment fails.
> >
>

> Actually, we can have different behaviour with different = Android platforms
> (see above). The text in the doc applies only to the "HTC majic".
>

> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>

> Ok, fixed

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




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

------_=_NextPart_001_01CBC6A2.9271DA02-- From pierrick.seite@orange-ftgroup.com Mon Feb 7 03:07:58 2011 Return-Path: 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 94F493A6ABD for ; Mon, 7 Feb 2011 03:07:58 -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=1.300, 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 4uU8mA+yd2RP for ; Mon, 7 Feb 2011 03:07:42 -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 9DEAB3A6D6C for ; Mon, 7 Feb 2011 03:07:41 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0766778001; Mon, 7 Feb 2011 12:12:50 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B274A760005; Mon, 7 Feb 2011 12:12:50 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 12:07:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC6B7.3EB8BF42" Date: Mon, 7 Feb 2011 12:07:43 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201796902@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAAAU2/AA= References: <4CA62C43.5080105@piuha.net><843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> From: To: , , , X-OriginalArrivalTime: 07 Feb 2011 11:07:44.0942 (UTC) FILETIME=[3F0E7CE0:01CBC6B7] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 11:07:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6B7.3EB8BF42 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I forgot a clarifying question to you, Stefano: You wrote: "In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. " =20 But what happen if the user defined list of preferred SSID is empty? = Does the blackberry build its own list of preferred SSIDs? If yes, how? = According to our test, when the Blackberry manages to attach to SSID1, = then SSID2, then SSID3 it seems that the preferred access is SSID1. Is = it correct?=20 Pierrick =20 ________________________________ De : SEITE Pierrick RD-RESA-REN=20 Envoy=E9 : lundi 7 f=E9vrier 2011 09:40 =C0 : 'stefano faccin'; mif@ietf.org; jari.arkko@piuha.net Objet : RE: [mif] AD review of draft-ietf-mif-current-practices =20 Hi Stefano, =20 Thanks for your comments, I'll update the draft accordingly. BTW, do you = have information on the following points for RIM blackberry: =20 - How the RIM blackberry manage Address selection: e.g. is RFC 3484 = supported?=20 =20 - DNS resolution issue on RIM blackberry: is DNS configuration per-node = or per-interface? If an application is bound to an interface, does it = always use the DNS settings for exactly that interface or the per-node = settings.=20 =20 - address space overlapping: When the RIM blackberry is simultaneously = attached to several interfaces, is the OS manage address space = overlapping? If yes, how does it work? =20 BR, Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java = applications" to just "applications", since I believe we want to capture = the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet = Service or the Internet gateway of the wireless server provider to = manage connections". Can we modify this to "... can use either the = BlackBerry Internet Service or the Internet gateway of the wireless = server provider or direct Internet connectivity over WLAN to ..." for = correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. =20 The section also contain a statement that does not apply to all devices, = i.e. "When the IP stack fails to obtain an IP address, the handset, = excepted the iPhone, restarts WLAN attachment selecting the second SSID = in the list. " The BlackBerry, when it fails to obtain an IP address = after successful WLAN attachment, performs a new WLAN scan and, among = the networks available, it selects the next SSID in the preferred list, = which means that the approach is different from the one the original = sentence tries to capture.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, = wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. > > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. > > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ------_=_NextPart_001_01CBC6B7.3EB8BF42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=A0

I forgot a clarifying question to you, = Stefano:

You wrote:

“In section 3.1.7 there is an incorrect statement = "The RIM Blackberry behaves differently, the connection manager selects the = first SSID on which it has managed to attach in the past." Please replace = this statement with "The RIM Blackberry behaves differently: the user = (e.g. the enterprise owning the device) is allowed to define its preferred access. = The connection manager selects the first SSID of the preferred list of SSIDs configured in the device and that is available based on the WLAN scan = the device has performed", since it is not true that the BlackBerry = always tries first the last SSID it has managed to attach in the past.  = “

 

But what happen if the user defined list of preferred SSID = is empty? Does the blackberry build its own list of preferred SSIDs? If yes, how? = According to our test, when the Blackberry manages to attach to SSID1, then SSID2, = then SSID3 it seems that the preferred access is SSID1. Is it correct? =

Pierrick

 

De : SEITE = Pierrick RD-RESA-REN
Envoy=E9 : lundi 7 = f=E9vrier 2011 09:40
=C0 : 'stefano = faccin'; mif@ietf.org; jari.arkko@piuha.net
Objet : RE: [mif] AD = review of draft-ietf-mif-current-practices

 

Hi = Stefano,

 =

Thanks for your = comments, I’ll update the draft accordingly. BTW, do you have information on = the following points for RIM blackberry:

 =

- How the RIM = blackberry manage Address selection: e.g. is RFC 3484 supported? =

 =

- DNS resolution = issue on RIM blackberry: is DNS configuration per-node or per-interface? If an application is bound to an interface, does it always use the DNS = settings for exactly that interface or the per-node settings. =

 =

- address space overlapping: When the RIM blackberry is simultaneously attached to = several interfaces, is the OS manage address space overlapping? If yes, how does = it work?

 

BR,

Pierrick

 =

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefano faccin
Envoy=E9 : vendredi = 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hello all,
I have reviewed version 06 of the draft and I have a few comments.

Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to just "applications", since I believe we = want to capture the most generic case of BlackBerry, independently of the = OS.

Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet Service or the = Internet gateway of the wireless server provider to manage connections". Can = we modify this to "... can use either the BlackBerry Internet Service = or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect statement "The RIM = Blackberry behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this statement = with "The RIM Blackberry behaves differently: the user (e.g. the = enterprise owning the device) is allowed to define its preferred access. The = connection manager selects the first SSID of the preferred list of SSIDs configured = in the device and that is available based on the WLAN scan the device has performed", since it is not true that the BlackBerry always tries = first the last SSID it has managed to attach in the past. 

The section also contain a statement that does not apply to all devices, i.e. "When the IP stack = fails to obtain an IP address, the handset, excepted the = iPhone, restarts WLAN attachment selecting the second SSID in the list. = " The BlackBerry, when it fails to obtain an IP address after successful = WLAN attachment, performs a new WLAN scan and, among the networks available, = it selects the next SSID in the preferred list, which means that the = approach is different from the one the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-f= tgroup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mif-curr= ent-practices-06.txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd and = Linux sections have been updated with information regarding DNS configuration, RFC3484 support, RFC1122 status and address overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 12:01
> =C0 : mif@ietf.org; jari.arkko@piuha.net
> Objet : RE: [mif] AD review of = draft-ietf-mif-current-practices

>
> Hi Jari, all,
>
> We've submitted a new version of the = draft-ietf-mif-current-practices
> (More details inline). However, there is a pending issue: we still = need
> additional information, especially from manufacturers, to address = your
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who = have
> provided per-OS initial information, to address Jari's concerns. = Interface
> selection is, generally, well documented but we need more details = on
> following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows = implement
> RFC3484 (I've just noticed that only the windows section refers to RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well = documented.
> But others sections must be developed. Reflecting Jari's comment: = is DNS

> configuration per-node or per-interface? If an application = is bound to an

> interface, does it always use the DNS settings for exactly = that interface

> or the per-node settings.

>
> - address space overlapping: we do not have information on these = issues
> and we'd appreciate feedback from the WG (especially from = manufacturers
> involved in MIF). When the terminal is simultaneously attached to = several
> interfaces, is the OS manage address space overlapping? If yes, how = does
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to = windows and Linux
> section. If we do not have more information for apple mac os, we'll = remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding = vendors
> specific implementations) manages multiple interfaces issues in the = same
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-iet= f-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of = draft-ietf-mif-current-practices
> >

> > I have reviewed this document. Overall, this is a good document, but
> > some work still remains. My biggest issues were the = following:
> >
> > The document is quite focused on the access network selection problem,
> > which has already been discussed extensively in RFC 5113. It = is fine to
> > include discussion of the access network selection problem as = well,
> > because it is all part of the same problem space. But I would = have
> > expected the document discuss in more detail what the = various
> > implementations do at layer 3. For instance, do they use RFC = 3484, are
> > DNS settings per-node or per-interface, if an application is = bound to an
> > interface does it always use the DNS settings for exactly that interface
> > or the per-node settings, what happens with overlapping = address space,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too = little)
> > information about some devices and operating systems whereas = the Windows
> > description is detailed and informative. I would suggest that = some of
> > the devices for which there is very little information are = either
> > removed from the document or some more information is inserted = about
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a = fine term
> > to use in WG discussion, but will look odd in a published RFC = by the
> > time the WG has concluded).
> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings = update of
> the routing functionality in the case where the terminal can be = attached
> simultaneously to several interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to me = what type of gateways
> > the text refers to. Default router, web proxy, application = proxy,
> > something else?
>

> I agree that the original text was unclear. I've revised = the section but
> Giyeong, please check we kept ideas from your original text.
>

> On the second paragraph of the same section it is
> > unclear what "device" refers to. The entire device = can use multiple
> > networks simultaneously? Does that mean that one application = can use
> > multiple networks simultaneously, to the same destinations = (like in
> > mp-tcp) or to different destinations? Or just that multiple applications
> > can use different networks simultaneously?`Please be more = precise about
> > what is actually happening, as opposed to claiming a general capability.
> >
>

> Ok, text has been revised.
>

> > Section 3.1.7 says very little about the hard issues = around MIF, such as
> > whether overlapping address space is tolerated, whether there = is a
> > possibility of some policy being sent from the network, = whether DNS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that = its hard to
> > get information, but at least some of these devices are open = source and
> > run on top of standard kernels such as Linux, so it should be possible
> > to find out a bit more.
>

> I guess you are referencing to android terminals; I was = also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. = It's true
> that Android is based on a Linux kernel but some functions are = sometimes
> customized by vendors. So we sometimes experience different = behaviour
> between different android terminals. For instance, some android = terminal
> cannot run IPv6 only, they need getting an IPv4 address first, and = then,
> even with IPv6 support some android cannot manage multiple IPv6 = prefixes
> on a single interface; some others inhibit the 3G/WLAN = multihoming....
> while all these functions are well supported on a Linux laptop. = Note that
> it is not just a matter of configuration since and the only way = to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can = depends
> on the vendors implementation.
>

> Or we can ask for further information from the
> > people who gave us the original data, I suppose at least some = of them
> > work for the manufacturers.
> >
>

> Yep, we need additional information from vendors....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>

> > >       Whatever is the handset, = fallback on L3 attachment failure is
> not
> > >       supported for motionless terminals.  Actually, the connection
> > >       manager always selects the most = powerful signal strength without
> > >       considering IP configuration = results.  In other words, if the
> > >       terminal is unable to set up the IP connectivity on one wifi
> > >       access, the connection manager will = not try to attach to an
> > >       alternative point of attachment (or = SSID) as long as the signal
> > >       strength of the first radio link is = the most powerful.
> >
> > What is "motionless terminal"? All devices that you = mention are mobile.
> >
>

> We meant: a terminal which remains under coverage of the = same AP.
>
> The test has been revised.
>

> > Besides, I'm fairly certain that the above does not = apply to Android.
> > The device that I have does seem to switch away from a = strong-signal
> > SSID to another SSID, if L3 attachment fails.
> >
>

> Actually, we can have different behaviour with different = Android platforms
> (see above). The text in the doc applies only to the "HTC majic".
>

> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>

> Ok, fixed

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




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

------_=_NextPart_001_01CBC6B7.3EB8BF42-- From sfaccin@rim.com Mon Feb 7 08:41:50 2011 Return-Path: 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 92F9D3A6D83 for ; Mon, 7 Feb 2011 08:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 x3ONMDpu5PT0 for ; Mon, 7 Feb 2011 08:41:33 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id F189D3A6E3E for ; Mon, 7 Feb 2011 08:41:29 -0800 (PST) X-AuditID: 0a666446-b7bcdae0000009d0-d1-4d5020bd5e61 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 3E.4A.02512.DB0205D4; Mon, 7 Feb 2011 11:41:33 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Feb 2011 11:41:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC6E5.DF4C2460" Date: Mon, 7 Feb 2011 10:41:27 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1FAA5@XCH02DFW.rim.net> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017967D3@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESA= References: <4CA62C43.5080105@piuha.net><843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017967D3@ftrdmel0.rd.francetelecom.fr> From: "Stefano Faccin" To: , , , X-OriginalArrivalTime: 07 Feb 2011 16:41:32.0925 (UTC) FILETIME=[E0AA2AD0:01CBC6E5] X-Brightmail-Tracker: AAAABQAAAZEXVCjMF1QozRdUKM4XVNa5 Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 16:41:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6E5.DF4C2460 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC6E5.DF4C2460" ------_=_NextPart_002_01CBC6E5.DF4C2460 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Pierrick, The BlackBerry uses per-interface DNS and applications use the DNS bound to= a specific interface. Address overlapping is supported and is managed by OS= mechanisms. I hope this suffices. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierri= ck.seite@orange-ftgroup.com Sent: Monday, February 07, 2011 12:40 AM To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net Subject: Re: [mif] AD review of draft-ietf-mif-current-practices Hi Stefano, Thanks for your comments, I'll update the draft accordingly. BTW, do you hav= e information on the following points for RIM blackberry: - How the RIM blackberry manage Address selection: e.g. is RFC 3484 supporte= d? - DNS resolution issue on RIM blackberry: is DNS configuration per-node or p= er-interface? If an application is bound to an interface, does it always use= the DNS settings for exactly that interface or the per-node settings. - address space overlapping: When the RIM blackberry is simultaneously attac= hed to several interfaces, is the OS manage address space overlapping? If ye= s, how does it work? BR, Pierrick ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefan= o faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to= just "applications", since I believe we want to capture the most generic ca= se of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application connecting to= the Internet, can use either the BlackBerry Internet Service or the Interne= t gateway of the wireless server provider to manage connections". Can we mod= ify this to "... can use either the BlackBerry Internet Service or the Inter= net gateway of the wireless server provider or direct Internet connectivity= over WLAN to ..." for correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry behaves= differently, the connection manager selects the first SSID on which it has= managed to attach in the past." Please replace this statement with "The RIM= Blackberry behaves differently: the user (e.g. the enterprise owning the de= vice) is allowed to define its preferred access. The connection manager sele= cts the first SSID of the preferred list of SSIDs configured in the device a= nd that is available based on the WLAN scan the device has performed", since= it is not true that the BlackBerry always tries first the last SSID it has= managed to attach in the past. The section also contain a statement that does not apply to all devices, i.e= . "When the IP stack fails to obtain an IP address, the handset, excepted th= e iPhone, restarts WLAN attachment selecting the second SSID in the list. "= The BlackBerry, when it fails to obtain an IP address after successful WLAN= attachment, performs a new WLAN scan and, among the networks available, it= selects the next SSID in the preferred list, which means that the approach= is different from the one the original sentence tries to capture. Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices (http://www= .ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.txt). Accordin= g to your comments, Nokia (thanks again Teemu), Andro=EFd and Linux sections= have been updated with information regarding DNS configuration, RFC3484 sup= port, RFC1122 status and address overlapping issue. Section "Apple" has been= removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows implement > RFC3484 (I've just noticed that only the windows section refers to RFC3484= , > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well documented. > But others sections must be developed. Reflecting Jari's comment: is DNS > configuration per-node or per-interface? If an application is bound to an > interface, does it always use the DNS settings for exactly that interface > or the per-node settings. > > - address space overlapping: we do not have information on these issues > and we'd appreciate feedback from the WG (especially from manufacturers > involved in MIF). When the terminal is simultaneously attached to several > interfaces, is the OS manage address space overlapping? If yes, how does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and Linux > section. If we do not have more information for apple mac os, we'll remove > the section. > > - Android: can we consider that basic android kernel (excluding vendors > specific implementations) manages multiple interfaces issues in the same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection problem, > > which has already been discussed extensively in RFC 5113. It is fine to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, are > > DNS settings per-node or per-interface, if an application is bound to an > > interface does it always use the DNS settings for exactly that interface > > or the per-node settings, what happens with overlapping address space, > etc. > > > > The document is somewhat imbalanced, there's very little (too little) > > information about some devices and operating systems whereas the Windows > > description is detailed and informative. I would suggest that some of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update of > the routing functionality in the case where the terminal can be attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple applications > > can use different networks simultaneously?`Please be more precise about > > what is actually happening, as opposed to claiming a general capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard to > > get information, but at least some of these devices are open source and > > run on top of standard kernels such as Linux, so it should be possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's true > that Android is based on a Linux kernel but some functions are sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android terminal > cannot run IPv6 only, they need getting an IPv4 address first, and then, > even with IPv6 support some android cannot manage multiple IPv6 prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure is > not > > > supported for motionless terminals. Actually, the connection > > > manager always selects the most powerful signal strength without > > > considering IP configuration results. In other words, if the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC6E5.DF4C2460 Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Pierrick,=

The BlackBerry uses per-interfac= e DNS and applications use the DNS bound to a specific interface. Address ov= erlapping is supported and is managed by OS mechanisms. I hope this suffices= .

Cheers,=

 

Stefano Faccin<= /o:p>

 

Standards Manager

Research In Motion Corporation
5000 Riversid= e Drive
Building 6, Brazos East, Ste. 100

Irving, Texas 75039 USA
Office: (972) 910 345= 1 

Internal: 820.63451

3DUntitl=: (510) 230 8422

www.rim.com= ; www.blackberry.com

 

P Consider the environmen= t before printing.

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: mi= f-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierric= k.seite@orange-ftgroup.com
Sent: Monday, February 07, 2011 12:40 A= M
To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
= Subject: Re: [mif] AD review of draft-ietf-mif-current-practices=

 

Hi Stefano,

 

Thanks for your comments, I’ll update the draft accordingly.= BTW, do you have information on the following points for RIM blackberry:

 

- How the RIM blackberry manage Add= ress selection: e.g. is RFC 3484 supported?

 

= - DNS resolution issue on RIM blackberry: is DNS configuration= per-node or per-interface? If an application is bound to an interface, does= it always use the DNS settings for exactly that interface or the per-node s= ettings.

 = ;

- address space overlap= ping: When the RIM blackberry is simultaneously attached to several interfac= es, is the OS manage address space overlapping? If yes, how does it work?

&nbs= p;

BR,<= /o:p>

Pierrick=

 =

 

De : mif-bounces@ietf.org [mailto:mif-bounces@= ietf.org] De la part de stefano faccin
Envoy=E9 : vend= redi 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@pi= uha.net
Objet : Re: [mif] AD review of draft-ietf-mif-current= -practices

 

Hello all,
I have reviewed version= 06 of the draft and I have a few comments.

Under section 3.1.3 on th= e BlackBerry, I would modify "Java applications" to just "app= lications", since I believe we want to capture the most generic case of= BlackBerry, independently of the OS.

Under section 3.1.3 on the Blac= kBerry, it says "An application connecting to the Internet, can use eit= her the BlackBerry Internet Service or the Internet gateway of the wireless= server provider to manage connections". Can we modify this to "..= . can use either the BlackBerry Internet Service or the Internet gateway of= the wireless server provider or direct Internet connectivity over WLAN to .= .." for correctness/completeness?

In section 3.1.7 there is an i= ncorrect statement "The RIM Blackberry behaves differently, the connect= ion manager selects the first SSID on which it has managed to attach in the= past." Please replace this statement with "The RIM Blackberry beh= aves differently: the user (e.g. the enterprise owning the device) is allowe= d to define its preferred access. The connection manager selects the first S= SID of the preferred list of SSIDs configured in the device and that is avai= lable based on the WLAN scan the device has performed", since it is not= true that the BlackBerry always tries first the last SSID it has managed to= attach in the past. 

The section also contain a statement that= does not apply to all devices, i.e. "= When the IP stack fails to obtain an IP address, the handset, excepted the i= Phone, restarts WLAN attachment selecting the second SSID in the list. "= ; The BlackBerry, when it fails to obtain an IP address after success= ful WLAN attachment, performs a new WLAN scan and, among the networks availa= ble, it selects the next SSID in the preferred list, which means that the ap= proach is different from the one the original sentence tries to capture.
Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-ftg= roup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-curr= ent-practices (http://www.ietf.org/internet-dr= afts/draft-ietf-mif-current-practices-06.txt). According to your comment= s, Nokia (thanks again Teemu), Andro=EFd and Linux sections have been update= d with information regarding DNS configuration, RFC3484 support, RFC1122 sta= tus and address overlapping issue. Section "Apple" has been remove= d.

BR,
Pierrick

> -----Message d'origine-----
> De=  : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre= 2010 12:01
> =C0 : mif@ietf.org<= /a>; jari.arkko@piuha.net
>= ; Objet : RE: [mif] AD review of draft-ietf-mif-current-practices<= /o:p>

>
> Hi Ja= ri, all,
>
> We've submitted a new version of the draft-ietf-mif= -current-practices
> (More details inline). However, there is a pendin= g issue: we still need
> additional information, especially from manuf= acturers, to address your
> concern with section 3.1.
>
>= So, we request the support from the WG, especially from folks who have
&= gt; provided per-OS initial information, to address Jari's concerns. Interfa= ce
> selection is, generally, well documented but we need more details= on
> following topics:
>
> - Address selection: is RFC 34= 84 supported? Linux and windows implement
> RFC3484 (I've just noticed= that only the windows section refers to RFC3484,
> I'll align the lin= ux section in the next version), but what about the
> others (nokia, b= lackberry, windows mobile, android)?
>
> - DNS resolution issues= : Windows and Linux section are well documented.
> But others sections= must be developed. Reflecting Jari's comment: is DNS

<= /div>

> configuration per-node or per= -interface? If an application is bound to an

> interface, does it always use the DNS s= ettings for exactly that interface

> or the per-node settings.

<= div>

>
> - address space overla= pping: we do not have information on these issues
> and we'd appreciat= e feedback from the WG (especially from manufacturers
> involved in MI= F). When the terminal is simultaneously attached to several
> interfac= es, is the OS manage address space overlapping? If yes, how does
> it= work?
>
>
> - The section "Apple Mac OS X" is p= oor in comparison to windows and Linux
> section. If we do not have mo= re information for apple mac os, we'll remove
> the section.
>> - Android: can we consider that basic android kernel (excluding vendo= rs
> specific implementations) manages multiple interfaces issues in t= he same
> way than the current Linux OS?
>
>
> Regar= ds,
> Pierrick
>
> > -----Message d'origine-----
>= ; > De : mif-bounces@ietf.or= g [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 = ;: vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-ietf-mif-current-= practices@tools.ietf.org
> > Objet : [mif] AD review of dr= aft-ietf-mif-current-practices
> >

=

> > I have reviewed this document= . Overall, this is a good document, but
> > some work still remains= . My biggest issues were the following:
> >
> > The docume= nt is quite focused on the access network selection problem,
> > wh= ich has already been discussed extensively in RFC 5113. It is fine to
>= ; > include discussion of the access network selection problem as well,> > because it is all part of the same problem space. But I would ha= ve
> > expected the document discuss in more detail what the variou= s
> > implementations do at layer 3. For instance, do they use RFC= 3484, are
> > DNS settings per-node or per-interface, if an applic= ation is bound to an
> > interface does it always use the DNS setti= ngs for exactly that interface
> > or the per-node settings, what h= appens with overlapping address space,
> etc.
> >
> >= ; The document is somewhat imbalanced, there's very little (too little)
&= gt; > information about some devices and operating systems whereas the Wi= ndows
> > description is detailed and informative. I would suggest= that some of
> > the devices for which there is very little inform= ation are either
> > removed from the document or some more informa= tion is inserted about
> them.
> >
> > Detailed comm= ents:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the= MIF context is a fine term
> > to use in WG discussion, but will l= ook odd in a published RFC by the
> > time the WG has concluded).> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile= 2003 SE, Windows phone 7 brings update of
> the routing functionality= in the case where the terminal can be attached
> simultaneously to se= veral interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to= me what type of gateways
> > the text refers to. Default router, w= eb proxy, application proxy,
> > something else?
>=

> I agree that= the original text was unclear. I've revised the section but
> Giyeong= , please check we kept ideas from your original text.
>

> On the second pa= ragraph of the same section it is
> > unclear what "device&quo= t; refers to. The entire device can use multiple
> > networks simul= taneously? Does that mean that one application can use
> > multiple= networks simultaneously, to the same destinations (like in
> > mp-= tcp) or to different destinations? Or just that multiple applications
>= ; > can use different networks simultaneously?`Please be more precise abo= ut
> > what is actually happening, as opposed to claiming a general= capability.
> >
>

> Ok, text has been revised.
>

> > Sect= ion 3.1.7 says very little about the hard issues around MIF, such as
>= > whether overlapping address space is tolerated, whether there is a
= > > possibility of some policy being sent from the network, whether DN= S info
> > is per node or per interface, etc.
> >
>= > But also other sections under 3.1 seem thin. I realize that its hard t= o
> > get information, but at least some of these devices are open= source and
> > run on top of standard kernels such as Linux, so it= should be possible
> > to find out a bit more.
><= /span>

> I guess you a= re referencing to android terminals; I was also thinking that
> the be= haviour of an android could be deduced from current Linux
> functional= ities but it seems that the situation is more complex. It's true
> tha= t Android is based on a Linux kernel but some functions are sometimes
>= ; customized by vendors. So we sometimes experience different behaviour
&= gt; between different android terminals. For instance, some android terminal=
> cannot run IPv6 only, they need getting an IPv4 address first, and= then,
> even with IPv6 support some android cannot manage multiple IP= v6 prefixes
> on a single interface; some others inhibit the 3G/WLAN m= ultihoming....
> while all these functions are well supported on a Lin= ux laptop. Note that
> it is not just a matter of configuration since= and the only way to
> overcome these limitations is to change the and= roid platform.
>
> I've added in the text that behaviour of an a= ndroid terminal can depends
> on the vendors implementation.
>

> Or= we can ask for further information from the
> > people who gave us= the original data, I suppose at least some of them
> > work for th= e manufacturers.
> >
>

> Yep, we need additional information from= vendors....
>
> > > iPhone
> > >
> >= > Iphone
> > Inconsistent capitalization.
> >
><= br>> Fixed
>

<= span lang=3DFR>> > >       Whatever is the handset,= fallback on L3 attachment failure is
> not
> > >   &= nbsp;   supported for motionless terminals.  Actually, the connect= ion
> > >       manager always selects the most p= owerful signal strength without
> > >       consi= dering IP configuration results.  In other words, if the
> > &= gt;       terminal is unable to set up the IP connectivity on= one wifi
> > >       access, the connection mana= ger will not try to attach to an
> > >       alte= rnative point of attachment (or SSID) as long as the signal
> > >= ;       strength of the first radio link is the most powerful= .
> >
> > What is "motionless terminal"? All dev= ices that you mention are mobile.
> >
>

=

> We meant: a terminal wh= ich remains under coverage of the same AP.
>
> The test has been= revised.
>

> > Besides, I'm fairly certain that the above does not app= ly to Android.
> > The device that I have does seem to switch away= from a strong-signal
> > SSID to another SSID, if L3 attachment fa= ils.
> >
>

> Actually, we can have different behaviour with diffe= rent Android platforms
> (see above). The text in the doc applies only= to the "HTC majic".
>

> > > in the scope of MIF.
>= > >
> >
> > ... in the scope of this document.
&= gt; >
>

> Ok, fixed

>
> > Jari
> >
> > ______________= _________________________________
> > mif mailing list
> >= mif@ietf.org
> > https://www.ietf.= org/mailman/listinfo/mif
____________________________________________= ___
mif mailing list
mif@ietf.org<= br>h= ttps://www.ietf.org/mailman/listinfo/mif




--
= Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= br>May the Force be with you

--------------= -------------------------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC6E5.DF4C2460-- ------_=_NextPart_001_01CBC6E5.DF4C2460 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC6E5.DF4C2460 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC6E5.DF4C2460-- From pierrick.seite@orange-ftgroup.com Mon Feb 7 09:07:57 2011 Return-Path: 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 7E72A3A6E22 for ; Mon, 7 Feb 2011 09:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 POZqNLu+9ogm for ; Mon, 7 Feb 2011 09:07:40 -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 A02CD3A6E24 for ; Mon, 7 Feb 2011 09:07:36 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 613008B8010; Mon, 7 Feb 2011 18:08:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 50C778B800C; Mon, 7 Feb 2011 18:08:45 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 18:07:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBC6E9.86A62FA6"; type="multipart/alternative" Date: Mon, 7 Feb 2011 18:07:39 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D41D8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1FAA5@XCH02DFW.rim.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESAAALy+cA== References: <4CA62C43.5080105@piuha.net><843DA8228A1BA74CA31FB4E111A5C46201795ACE@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017967D3@ftrdmel0.rd.francetelecom.fr> <680854867F7FD04BB9B06EB8ACA8D5AC05E1FAA5@XCH02DFW.rim.net> From: To: , , , X-OriginalArrivalTime: 07 Feb 2011 17:07:40.0693 (UTC) FILETIME=[87209450:01CBC6E9] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 17:07:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6E9.86A62FA6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC6E9.86A62FA6" ------_=_NextPart_002_01CBC6E9.86A62FA6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If I refer to the current text on RIM, I understand that Address = overlapping is supported because the OS can manage multiple IP stacks = associated to multiple interface. Right? =20 Pierrick=20 =20 ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com]=20 Envoy=E9 : lundi 7 f=E9vrier 2011 17:41 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net Objet : RE: [mif] AD review of draft-ietf-mif-current-practices =20 Pierrick, The BlackBerry uses per-interface DNS and applications use the DNS bound = to a specific interface. Address overlapping is supported and is managed = by OS mechanisms. I hope this suffices.=20 Cheers, =20 Stefano Faccin =20 Standards Manager Research In Motion Corporation=20 5000 Riverside Drive=20 Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA=20 Office: (972) 910 3451 =20 Internal: 820.63451 : (510) 230 8422 www.rim.com = ; www.blackberry.com = =20 =20 =20 =20 P Consider the environment before printing. =20 From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = pierrick.seite@orange-ftgroup.com Sent: Monday, February 07, 2011 12:40 AM To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net Subject: Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hi Stefano, =20 Thanks for your comments, I'll update the draft accordingly. BTW, do you = have information on the following points for RIM blackberry: =20 - How the RIM blackberry manage Address selection: e.g. is RFC 3484 = supported?=20 =20 - DNS resolution issue on RIM blackberry: is DNS configuration per-node = or per-interface? If an application is bound to an interface, does it = always use the DNS settings for exactly that interface or the per-node = settings.=20 =20 - address space overlapping: When the RIM blackberry is simultaneously = attached to several interfaces, is the OS manage address space = overlapping? If yes, how does it work? =20 BR, Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java = applications" to just "applications", since I believe we want to capture = the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet = Service or the Internet gateway of the wireless server provider to = manage connections". Can we modify this to "... can use either the = BlackBerry Internet Service or the Internet gateway of the wireless = server provider or direct Internet connectivity over WLAN to ..." for = correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. =20 The section also contain a statement that does not apply to all devices, = i.e. "When the IP stack fails to obtain an IP address, the handset, = excepted the iPhone, restarts WLAN attachment selecting the second SSID = in the list. " The BlackBerry, when it fails to obtain an IP address = after successful WLAN attachment, performs a new WLAN scan and, among = the networks available, it selects the next SSID in the preferred list, = which means that the approach is different from the one the original = sentence tries to capture.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, = wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. > > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. > > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_002_01CBC6E9.86A62FA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If I refer to = the current text on RIM, I understand that Address overlapping is supported because = the OS can manage multiple IP stacks = associated to multiple interface. Right?

 =

Pierrick =

 =

De : = Stefano Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : lundi 7 = f=E9vrier 2011 17:41
=C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net
Objet : RE: [mif] AD = review of draft-ietf-mif-current-practices

 

Pierrick,

The = BlackBerry uses per-interface DNS and applications use the DNS bound to a specific = interface. Address overlapping is supported and is managed by OS mechanisms. I hope = this suffices.

Cheers,=

 <= /o:p>

Stefano = Faccin

 <= /o:p>

Standards = Manager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, = Texas 75039 USA
Office: (972) 910 3451 

Internal: = 820.63451

3DUntitled-1: (510) 230 8422

www.rim.com; www.blackberry.com<= font size=3D2 color=3Dblack face=3DCalibri>

 

3D"cid:image004.png@01CB49EA.87D92140"

 <= /o:p>

P Consider the environment before = printing.

 <= /o:p>

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierrick.seite@orange-ftgroup.com
Sent: Monday, February = 07, 2011 12:40 AM
To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
Subject: Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hi = Stefano,

 =

Thanks for your = comments, I’ll update the draft accordingly. BTW, do you have information on = the following points for RIM blackberry:

 =

- How the RIM = blackberry manage Address selection: e.g. is RFC 3484 supported? =

 =

- DNS resolution = issue on RIM blackberry: is DNS configuration per-node or per-interface? If an application is bound to an interface, does it always use the DNS = settings for exactly that interface or the per-node settings. =

 =

- address space overlapping: When the RIM blackberry is simultaneously attached to = several interfaces, is the OS manage address space overlapping? If yes, how does = it work?

 

BR,

Pierrick

 =

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefano faccin
Envoy=E9 : vendredi = 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hello all,
I have reviewed version 06 of the draft and I have a few comments.

Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to just "applications", since I believe we = want to capture the most generic case of BlackBerry, independently of the = OS.

Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet Service or the = Internet gateway of the wireless server provider to manage connections". Can = we modify this to "... can use either the BlackBerry Internet Service = or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect statement "The RIM = Blackberry behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this statement = with "The RIM Blackberry behaves differently: the user (e.g. the = enterprise owning the device) is allowed to define its preferred access. The = connection manager selects the first SSID of the preferred list of SSIDs configured = in the device and that is available based on the WLAN scan the device has = performed", since it is not true that the BlackBerry always tries first the last = SSID it has managed to attach in the past. 

The section also contain a statement that does not apply to all devices, i.e. "When the IP stack fails to = obtain an IP address, the handset, excepted the iPhone, restarts WLAN = attachment selecting the second SSID in the list. " The BlackBerry, = when it fails to obtain an IP address after successful WLAN attachment, performs = a new WLAN scan and, among the networks available, it selects the next SSID in = the preferred list, which means that the approach is different from the one = the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-f= tgroup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mif-curr= ent-practices-06.txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd and = Linux sections have been updated with information regarding DNS configuration, RFC3484 support, RFC1122 status and address overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 12:01
> =C0 : mif@ietf.org; jari.arkko@piuha.net
> Objet : RE: [mif] AD review of = draft-ietf-mif-current-practices

>
> Hi Jari, all,
>
> We've submitted a new version of the = draft-ietf-mif-current-practices
> (More details inline). However, there is a pending issue: we still = need
> additional information, especially from manufacturers, to address = your
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who = have
> provided per-OS initial information, to address Jari's concerns. = Interface
> selection is, generally, well documented but we need more details = on
> following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows = implement
> RFC3484 (I've just noticed that only the windows section refers to RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well = documented.
> But others sections must be developed. Reflecting Jari's comment: = is DNS

> configuration per-node or per-interface? If an application = is bound to an

> interface, does it always use the DNS settings for exactly = that interface

> or the per-node settings.

>
> - address space overlapping: we do not have information on these = issues
> and we'd appreciate feedback from the WG (especially from = manufacturers
> involved in MIF). When the terminal is simultaneously attached to = several
> interfaces, is the OS manage address space overlapping? If yes, how = does
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to = windows and Linux
> section. If we do not have more information for apple mac os, we'll = remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding = vendors
> specific implementations) manages multiple interfaces issues in the = same
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-iet= f-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of = draft-ietf-mif-current-practices
> >

> > I have reviewed this document. Overall, this is a good document, but
> > some work still remains. My biggest issues were the = following:
> >
> > The document is quite focused on the access network selection problem,
> > which has already been discussed extensively in RFC 5113. It = is fine to
> > include discussion of the access network selection problem as = well,
> > because it is all part of the same problem space. But I would = have
> > expected the document discuss in more detail what the = various
> > implementations do at layer 3. For instance, do they use RFC = 3484, are
> > DNS settings per-node or per-interface, if an application is = bound to an
> > interface does it always use the DNS settings for exactly that interface
> > or the per-node settings, what happens with overlapping = address space,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too = little)
> > information about some devices and operating systems whereas = the Windows
> > description is detailed and informative. I would suggest that = some of
> > the devices for which there is very little information are = either
> > removed from the document or some more information is inserted = about
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a = fine term
> > to use in WG discussion, but will look odd in a published RFC = by the
> > time the WG has concluded).
> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings = update of
> the routing functionality in the case where the terminal can be = attached
> simultaneously to several interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to me = what type of gateways
> > the text refers to. Default router, web proxy, application = proxy,
> > something else?
>

> I agree that the original text was unclear. I've revised = the section but
> Giyeong, please check we kept ideas from your original text.
>

> On the second paragraph of the same section it is
> > unclear what "device" refers to. The entire device = can use multiple
> > networks simultaneously? Does that mean that one application = can use
> > multiple networks simultaneously, to the same destinations = (like in
> > mp-tcp) or to different destinations? Or just that multiple applications
> > can use different networks simultaneously?`Please be more = precise about
> > what is actually happening, as opposed to claiming a general capability.
> >
>

> Ok, text has been revised.
>

> > Section 3.1.7 says very little about the hard issues = around MIF, such as
> > whether overlapping address space is tolerated, whether there = is a
> > possibility of some policy being sent from the network, = whether DNS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that = its hard to
> > get information, but at least some of these devices are open = source and
> > run on top of standard kernels such as Linux, so it should be possible
> > to find out a bit more.
>

> I guess you are referencing to android terminals; I was = also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. = It's true
> that Android is based on a Linux kernel but some functions are = sometimes
> customized by vendors. So we sometimes experience different = behaviour
> between different android terminals. For instance, some android = terminal
> cannot run IPv6 only, they need getting an IPv4 address first, and = then,
> even with IPv6 support some android cannot manage multiple IPv6 = prefixes
> on a single interface; some others inhibit the 3G/WLAN = multihoming....
> while all these functions are well supported on a Linux laptop. = Note that
> it is not just a matter of configuration since and the only way = to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can = depends
> on the vendors implementation.
>

> Or we can ask for further information from the
> > people who gave us the original data, I suppose at least some = of them
> > work for the manufacturers.
> >
>

> Yep, we need additional information from vendors....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>

> > >       Whatever is the handset, = fallback on L3 attachment failure is
> not
> > >       supported for motionless terminals.  Actually, the connection
> > >       manager always selects the most = powerful signal strength without
> > >       considering IP configuration = results.  In other words, if the
> > >       terminal is unable to set up the IP connectivity on one wifi
> > >       access, the connection manager will = not try to attach to an
> > >       alternative point of attachment (or = SSID) as long as the signal
> > >       strength of the first radio link is = the most powerful.
> >
> > What is "motionless terminal"? All devices that you = mention are mobile.
> >
>

> We meant: a terminal which remains under coverage of the = same AP.
>
> The test has been revised.
>

> > Besides, I'm fairly certain that the above does not = apply to Android.
> > The device that I have does seem to switch away from a = strong-signal
> > SSID to another SSID, if L3 attachment fails.
> >
>

> Actually, we can have different behaviour with different = Android platforms
> (see above). The text in the doc applies only to the "HTC majic".
>

> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>

> Ok, fixed

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




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

----------------------------------------------= -----------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_002_01CBC6E9.86A62FA6-- ------_=_NextPart_001_01CBC6E9.86A62FA6 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC6E9.86A62FA6 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z ------_=_NextPart_001_01CBC6E9.86A62FA6-- From sfaccin@rim.com Mon Feb 7 09:13:16 2011 Return-Path: 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 5A39D3A6E2E for ; Mon, 7 Feb 2011 09:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 TbIU375NyhjG for ; Mon, 7 Feb 2011 09:13:00 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 680223A6920 for ; Mon, 7 Feb 2011 09:13:00 -0800 (PST) X-AuditID: 0a401fcb-b7c02ae0000009e2-4d-4d50281e8b4a Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id F6.A2.02530.E18205D4; Mon, 7 Feb 2011 12:13:02 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Feb 2011 12:13:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC6EA.450F365F" Date: Mon, 7 Feb 2011 11:12:57 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAD2@XCH02DFW.rim.net> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D41D8@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESAAALy+cAAAZC9v From: "Stefano Faccin" To: , , , X-OriginalArrivalTime: 07 Feb 2011 17:13:02.0354 (UTC) FILETIME=[46DA2720:01CBC6EA] X-Brightmail-Tracker: AAAABQAAAZEXVCjMF1QozRdUKM4XVNa5 Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 17:13:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6EA.450F365F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC6EA.450F365F" ------_=_NextPart_002_01CBC6EA.450F365F Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 UGllcnJpY2ssDQpJIGJlbGlldmUgdGhlIHN0YXRlbWVudCBhcyB5b3UgcGhyYXNlZCBjYXB0 dXJlcyB0aGUgY29uY2VwdCB2ZXJ5IHdlbGwuDQpUaGFua3MsDQpTdGVmYW5vDQoNClN0ZWZh bm8gTS4gRmFjY2luIA0KDQpTdGFuZGFyZHMgTWFuYWdlciANClJlc2VhcmNoIEluIE1vdGlv biANCjEyMiBXZXN0IEpvaG4gQ2FycGVudGVyIFBhcmt3YXkgDQpJcnZpbmcsIFRYIDc1MDM5 IA0KSW50ZXJuYWw6IDgyMCA2MzQ1MSANCkRlc2s6ICsxIDk3MiA5MTAgMzQ1MSANCkJsYWNr QmVycnk6ICsxIDUxMCAyMzAgODQyMiANCnNmYWNjaW5AcmltLmNvbSANClRpbWUgem9uZTog UFNUIChHTVQgLTgpDQogDQoNCkZyb206IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3Vw LmNvbSBbbWFpbHRvOnBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNvbV0gDQpTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDA3LCAyMDExIDExOjA3IEFNDQpUbzogU3RlZmFubyBGYWNj aW47IHNmYWNjaW5zdGRAZ21haWwuY29tIDxzZmFjY2luc3RkQGdtYWlsLmNvbT47IG1pZkBp ZXRmLm9yZyA8bWlmQGlldGYub3JnPjsgamFyaS5hcmtrb0BwaXVoYS5uZXQgPGphcmkuYXJr a29AcGl1aGEubmV0PiANClN1YmplY3Q6IFJFOiBbbWlmXSBBRCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1taWYtY3VycmVudC1wcmFjdGljZXMgDQogDQoNCg0KSWYgSSByZWZlciB0byB0aGUg Y3VycmVudCB0ZXh0IG9uIFJJTSwgSSB1bmRlcnN0YW5kIHRoYXQgQWRkcmVzcyBvdmVybGFw cGluZyBpcyBzdXBwb3J0ZWQgYmVjYXVzZSB0aGUgT1MgY2FuIG1hbmFnZSBtdWx0aXBsZSBJ UCBzdGFja3MgYXNzb2NpYXRlZCB0byBtdWx0aXBsZSBpbnRlcmZhY2UuIFJpZ2h0Pw0KDQog DQoNClBpZXJyaWNrIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkRlIDogU3RlZmFubyBGYWNjaW4gW21haWx0bzpzZmFjY2luQHJpbS5jb21dIA0KRW52 b3nDqSA6IGx1bmRpIDcgZsOpdnJpZXIgMjAxMSAxNzo0MQ0Kw4AgOiBTRUlURSBQaWVycmlj ayBSRC1SRVNBLVJFTjsgc2ZhY2NpbnN0ZEBnbWFpbC5jb207IG1pZkBpZXRmLm9yZzsgamFy aS5hcmtrb0BwaXVoYS5uZXQNCk9iamV0IDogUkU6IFttaWZdIEFEIHJldmlldyBvZiBkcmFm dC1pZXRmLW1pZi1jdXJyZW50LXByYWN0aWNlcw0KDQogDQoNClBpZXJyaWNrLA0KDQpUaGUg QmxhY2tCZXJyeSB1c2VzIHBlci1pbnRlcmZhY2UgRE5TIGFuZCBhcHBsaWNhdGlvbnMgdXNl IHRoZSBETlMgYm91bmQgdG8gYSBzcGVjaWZpYyBpbnRlcmZhY2UuIEFkZHJlc3Mgb3Zlcmxh cHBpbmcgaXMgc3VwcG9ydGVkIGFuZCBpcyBtYW5hZ2VkIGJ5IE9TIG1lY2hhbmlzbXMuIEkg aG9wZSB0aGlzIHN1ZmZpY2VzLiANCg0KQ2hlZXJzLA0KDQogDQoNClN0ZWZhbm8gRmFjY2lu DQoNCiANCg0KU3RhbmRhcmRzIE1hbmFnZXINCg0KUmVzZWFyY2ggSW4gTW90aW9uIENvcnBv cmF0aW9uIA0KNTAwMCBSaXZlcnNpZGUgRHJpdmUgDQpCdWlsZGluZyA2LCBCcmF6b3MgRWFz dCwgU3RlLiAxMDANCg0KSXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5NzIp IDkxMCAzNDUxICANCg0KSW50ZXJuYWw6IDgyMC42MzQ1MQ0KDQo6ICg1MTApIDIzMCA4NDIy DQoNCnd3dy5yaW0uY29tIDxvdXRiaW5kOi8vMjgtMDAwMDAwMDAxMTlFMzM4OUREQzVFMDQ1 OTNFOTBGQjEzMzJBMDhDMTA3MDBBM0YwNjc1M0Q0MEQ0MTQ5QkYxNkU0MkVBMzAyNTlBQjAw MDAwMUI3OTA4QjAwMDBGN0I1MEFCNUI0RTExQjRDODA1MjlBQUIyMzEzRUYzRTAwMDAwMDZG MUJFQTAwMDAvd3d3LnJpbS5jb20+IDsgd3d3LmJsYWNrYmVycnkuY29tIDxvdXRiaW5kOi8v MjgtMDAwMDAwMDAxMTlFMzM4OUREQzVFMDQ1OTNFOTBGQjEzMzJBMDhDMTA3MDBBM0YwNjc1 M0Q0MEQ0MTQ5QkYxNkU0MkVBMzAyNTlBQjAwMDAwMUI3OTA4QjAwMDBGN0I1MEFCNUI0RTEx QjRDODA1MjlBQUIyMzEzRUYzRTAwMDAwMDZGMUJFQTAwMDAvd3d3LmJsYWNrYmVycnkuY29t PiAgDQoNCiANCg0KIDxodHRwOi8vd3d3LmJsYWNrYmVycnkuY29tLz4gDQoNCiANCg0KUCBD b25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHByaW50aW5nLg0KDQogDQoNCkZyb206 IG1pZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20NClNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMDcsIDIwMTEgMTI6NDAgQU0NClRvOiBzZmFjY2luc3RkQGdtYWls LmNvbTsgbWlmQGlldGYub3JnOyBqYXJpLmFya2tvQHBpdWhhLm5ldA0KU3ViamVjdDogUmU6 IFttaWZdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1pZi1jdXJyZW50LXByYWN0aWNlcw0K DQogDQoNCkhpIFN0ZWZhbm8sDQoNCiANCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBJ 4oCZbGwgdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4gQlRXLCBkbyB5b3UgaGF2ZSBp bmZvcm1hdGlvbiBvbiB0aGUgZm9sbG93aW5nIHBvaW50cyBmb3IgUklNIGJsYWNrYmVycnk6 DQoNCiANCg0KLSBIb3cgdGhlIFJJTSBibGFja2JlcnJ5IG1hbmFnZSBBZGRyZXNzIHNlbGVj dGlvbjogZS5nLiBpcyBSRkMgMzQ4NCBzdXBwb3J0ZWQ/IA0KDQogDQoNCi0gRE5TIHJlc29s dXRpb24gaXNzdWUgb24gUklNIGJsYWNrYmVycnk6IGlzIEROUyBjb25maWd1cmF0aW9uIHBl ci1ub2RlIG9yIHBlci1pbnRlcmZhY2U/IElmIGFuIGFwcGxpY2F0aW9uIGlzIGJvdW5kIHRv IGFuIGludGVyZmFjZSwgZG9lcyBpdCBhbHdheXMgdXNlIHRoZSBETlMgc2V0dGluZ3MgZm9y IGV4YWN0bHkgdGhhdCBpbnRlcmZhY2Ugb3IgdGhlIHBlci1ub2RlIHNldHRpbmdzLiANCg0K IA0KDQotIGFkZHJlc3Mgc3BhY2Ugb3ZlcmxhcHBpbmc6IFdoZW4gdGhlIFJJTSBibGFja2Jl cnJ5IGlzIHNpbXVsdGFuZW91c2x5IGF0dGFjaGVkIHRvIHNldmVyYWwgaW50ZXJmYWNlcywg aXMgdGhlIE9TIG1hbmFnZSBhZGRyZXNzIHNwYWNlIG92ZXJsYXBwaW5nPyBJZiB5ZXMsIGhv dyBkb2VzIGl0IHdvcms/DQoNCiANCg0KQlIsDQoNClBpZXJyaWNrDQoNCiANCg0KIA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEZSA6IG1pZi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgc3Rl ZmFubyBmYWNjaW4NCkVudm95w6kgOiB2ZW5kcmVkaSA0IGbDqXZyaWVyIDIwMTEgMjA6MzEN CsOAIDogbWlmQGlldGYub3JnOyBqYXJpLmFya2tvQHBpdWhhLm5ldA0KT2JqZXQgOiBSZTog W21pZl0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbWlmLWN1cnJlbnQtcHJhY3RpY2VzDQoN CiANCg0KSGVsbG8gYWxsLA0KSSBoYXZlIHJldmlld2VkIHZlcnNpb24gMDYgb2YgdGhlIGRy YWZ0IGFuZCBJIGhhdmUgYSBmZXcgY29tbWVudHMuDQoNClVuZGVyIHNlY3Rpb24gMy4xLjMg b24gdGhlIEJsYWNrQmVycnksIEkgd291bGQgbW9kaWZ5ICJKYXZhIGFwcGxpY2F0aW9ucyIg dG8ganVzdCAiYXBwbGljYXRpb25zIiwgc2luY2UgSSBiZWxpZXZlIHdlIHdhbnQgdG8gY2Fw dHVyZSB0aGUgbW9zdCBnZW5lcmljIGNhc2Ugb2YgQmxhY2tCZXJyeSwgaW5kZXBlbmRlbnRs eSBvZiB0aGUgT1MuDQoNClVuZGVyIHNlY3Rpb24gMy4xLjMgb24gdGhlIEJsYWNrQmVycnks IGl0IHNheXMgIkFuIGFwcGxpY2F0aW9uIGNvbm5lY3RpbmcgdG8gdGhlIEludGVybmV0LCBj YW4gdXNlIGVpdGhlciB0aGUgQmxhY2tCZXJyeSBJbnRlcm5ldCBTZXJ2aWNlIG9yIHRoZSBJ bnRlcm5ldCBnYXRld2F5IG9mIHRoZSB3aXJlbGVzcyBzZXJ2ZXIgcHJvdmlkZXIgdG8gbWFu YWdlIGNvbm5lY3Rpb25zIi4gQ2FuIHdlIG1vZGlmeSB0aGlzIHRvICIuLi4gY2FuIHVzZSBl aXRoZXIgdGhlIEJsYWNrQmVycnkgSW50ZXJuZXQgU2VydmljZSBvciB0aGUgSW50ZXJuZXQg Z2F0ZXdheSBvZiB0aGUgd2lyZWxlc3Mgc2VydmVyIHByb3ZpZGVyIG9yIGRpcmVjdCBJbnRl cm5ldCBjb25uZWN0aXZpdHkgb3ZlciBXTEFOIHRvIC4uLiIgZm9yIGNvcnJlY3RuZXNzL2Nv bXBsZXRlbmVzcz8NCg0KSW4gc2VjdGlvbiAzLjEuNyB0aGVyZSBpcyBhbiBpbmNvcnJlY3Qg c3RhdGVtZW50ICJUaGUgUklNIEJsYWNrYmVycnkgYmVoYXZlcyBkaWZmZXJlbnRseSwgdGhl IGNvbm5lY3Rpb24gbWFuYWdlciBzZWxlY3RzIHRoZSBmaXJzdCBTU0lEIG9uIHdoaWNoIGl0 IGhhcyBtYW5hZ2VkIHRvIGF0dGFjaCBpbiB0aGUgcGFzdC4iIFBsZWFzZSByZXBsYWNlIHRo aXMgc3RhdGVtZW50IHdpdGggIlRoZSBSSU0gQmxhY2tiZXJyeSBiZWhhdmVzIGRpZmZlcmVu dGx5OiB0aGUgdXNlciAoZS5nLiB0aGUgZW50ZXJwcmlzZSBvd25pbmcgdGhlIGRldmljZSkg aXMgYWxsb3dlZCB0byBkZWZpbmUgaXRzIHByZWZlcnJlZCBhY2Nlc3MuIFRoZSBjb25uZWN0 aW9uIG1hbmFnZXIgc2VsZWN0cyB0aGUgZmlyc3QgU1NJRCBvZiB0aGUgcHJlZmVycmVkIGxp c3Qgb2YgU1NJRHMgY29uZmlndXJlZCBpbiB0aGUgZGV2aWNlIGFuZCB0aGF0IGlzIGF2YWls YWJsZSBiYXNlZCBvbiB0aGUgV0xBTiBzY2FuIHRoZSBkZXZpY2UgaGFzIHBlcmZvcm1lZCIs IHNpbmNlIGl0IGlzIG5vdCB0cnVlIHRoYXQgdGhlIEJsYWNrQmVycnkgYWx3YXlzIHRyaWVz IGZpcnN0IHRoZSBsYXN0IFNTSUQgaXQgaGFzIG1hbmFnZWQgdG8gYXR0YWNoIGluIHRoZSBw YXN0LiAgDQoNClRoZSBzZWN0aW9uIGFsc28gY29udGFpbiBhIHN0YXRlbWVudCB0aGF0IGRv ZXMgbm90IGFwcGx5IHRvIGFsbCBkZXZpY2VzLCBpLmUuICJXaGVuIHRoZSBJUCBzdGFjayBm YWlscyB0byBvYnRhaW4gYW4gSVAgYWRkcmVzcywgdGhlIGhhbmRzZXQsIGV4Y2VwdGVkIHRo ZSBpUGhvbmUsIHJlc3RhcnRzIFdMQU4gYXR0YWNobWVudCBzZWxlY3RpbmcgdGhlIHNlY29u ZCBTU0lEIGluIHRoZSBsaXN0LiAiIFRoZSBCbGFja0JlcnJ5LCB3aGVuIGl0IGZhaWxzIHRv IG9idGFpbiBhbiBJUCBhZGRyZXNzIGFmdGVyIHN1Y2Nlc3NmdWwgV0xBTiBhdHRhY2htZW50 LCBwZXJmb3JtcyBhIG5ldyBXTEFOIHNjYW4gYW5kLCBhbW9uZyB0aGUgbmV0d29ya3MgYXZh aWxhYmxlLCBpdCBzZWxlY3RzIHRoZSBuZXh0IFNTSUQgaW4gdGhlIHByZWZlcnJlZCBsaXN0 LCB3aGljaCBtZWFucyB0aGF0IHRoZSBhcHByb2FjaCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUg b25lIHRoZSBvcmlnaW5hbCBzZW50ZW5jZSB0cmllcyB0byBjYXB0dXJlLiANCg0KQ2hlZXJz LA0KDQpTdGVmYW5vDQoNCk9uIFR1ZSwgRmViIDEsIDIwMTEgYXQgNjo0MSBBTSwgPHBpZXJy aWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNvbT4gd3JvdGU6DQoNCkhlbGxvIEphcmksDQoN CkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1taWYtY3VycmVu dC1wcmFjdGljZXMgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtbWlmLWN1cnJlbnQtcHJhY3RpY2VzLTA2LnR4dCkuIEFjY29yZGluZyB0byB5b3Vy IGNvbW1lbnRzLCBOb2tpYSAodGhhbmtzIGFnYWluIFRlZW11KSwgQW5kcm/Dr2QgYW5kIExp bnV4IHNlY3Rpb25zIGhhdmUgYmVlbiB1cGRhdGVkIHdpdGggaW5mb3JtYXRpb24gcmVnYXJk aW5nIEROUyBjb25maWd1cmF0aW9uLCBSRkMzNDg0IHN1cHBvcnQsIFJGQzExMjIgc3RhdHVz IGFuZCBhZGRyZXNzIG92ZXJsYXBwaW5nIGlzc3VlLiBTZWN0aW9uICJBcHBsZSIgaGFzIGJl ZW4gcmVtb3ZlZC4NCg0KQlIsDQpQaWVycmljaw0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZSA6IFNFSVRFIFBpZXJyaWNrIFJELVJFU0EtUkVODQo+IEVudm95w6kg OiBzYW1lZGkgMjMgb2N0b2JyZSAyMDEwIDEyOjAxDQo+IMOAIDogbWlmQGlldGYub3JnOyBq YXJpLmFya2tvQHBpdWhhLm5ldA0KPiBPYmpldCA6IFJFOiBbbWlmXSBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1taWYtY3VycmVudC1wcmFjdGljZXMNCg0KPg0KPiBIaSBKYXJpLCBhbGws DQo+DQo+IFdlJ3ZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC1pZXRm LW1pZi1jdXJyZW50LXByYWN0aWNlcw0KPiAoTW9yZSBkZXRhaWxzIGlubGluZSkuIEhvd2V2 ZXIsIHRoZXJlIGlzIGEgcGVuZGluZyBpc3N1ZTogd2Ugc3RpbGwgbmVlZA0KPiBhZGRpdGlv bmFsIGluZm9ybWF0aW9uLCBlc3BlY2lhbGx5IGZyb20gbWFudWZhY3R1cmVycywgdG8gYWRk cmVzcyB5b3VyDQo+IGNvbmNlcm4gd2l0aCBzZWN0aW9uIDMuMS4NCj4NCj4gU28sIHdlIHJl cXVlc3QgdGhlIHN1cHBvcnQgZnJvbSB0aGUgV0csIGVzcGVjaWFsbHkgZnJvbSBmb2xrcyB3 aG8gaGF2ZQ0KPiBwcm92aWRlZCBwZXItT1MgaW5pdGlhbCBpbmZvcm1hdGlvbiwgdG8gYWRk cmVzcyBKYXJpJ3MgY29uY2VybnMuIEludGVyZmFjZQ0KPiBzZWxlY3Rpb24gaXMsIGdlbmVy YWxseSwgd2VsbCBkb2N1bWVudGVkIGJ1dCB3ZSBuZWVkIG1vcmUgZGV0YWlscyBvbg0KPiBm b2xsb3dpbmcgdG9waWNzOg0KPg0KPiAtIEFkZHJlc3Mgc2VsZWN0aW9uOiBpcyBSRkMgMzQ4 NCBzdXBwb3J0ZWQ/IExpbnV4IGFuZCB3aW5kb3dzIGltcGxlbWVudA0KPiBSRkMzNDg0IChJ J3ZlIGp1c3Qgbm90aWNlZCB0aGF0IG9ubHkgdGhlIHdpbmRvd3Mgc2VjdGlvbiByZWZlcnMg dG8gUkZDMzQ4NCwNCj4gSSdsbCBhbGlnbiB0aGUgbGludXggc2VjdGlvbiBpbiB0aGUgbmV4 dCB2ZXJzaW9uKSwgYnV0IHdoYXQgYWJvdXQgdGhlDQo+IG90aGVycyAobm9raWEsIGJsYWNr YmVycnksIHdpbmRvd3MgbW9iaWxlLCBhbmRyb2lkKT8NCj4NCj4gLSBETlMgcmVzb2x1dGlv biBpc3N1ZXM6IFdpbmRvd3MgYW5kIExpbnV4IHNlY3Rpb24gYXJlIHdlbGwgZG9jdW1lbnRl ZC4NCj4gQnV0IG90aGVycyBzZWN0aW9ucyBtdXN0IGJlIGRldmVsb3BlZC4gUmVmbGVjdGlu ZyBKYXJpJ3MgY29tbWVudDogaXMgRE5TDQoNCj4gY29uZmlndXJhdGlvbiBwZXItbm9kZSBv ciBwZXItaW50ZXJmYWNlPyBJZiBhbiBhcHBsaWNhdGlvbiBpcyBib3VuZCB0byBhbg0KDQo+ IGludGVyZmFjZSwgZG9lcyBpdCBhbHdheXMgdXNlIHRoZSBETlMgc2V0dGluZ3MgZm9yIGV4 YWN0bHkgdGhhdCBpbnRlcmZhY2UNCg0KPiBvciB0aGUgcGVyLW5vZGUgc2V0dGluZ3MuDQoN Cj4NCj4gLSBhZGRyZXNzIHNwYWNlIG92ZXJsYXBwaW5nOiB3ZSBkbyBub3QgaGF2ZSBpbmZv cm1hdGlvbiBvbiB0aGVzZSBpc3N1ZXMNCj4gYW5kIHdlJ2QgYXBwcmVjaWF0ZSBmZWVkYmFj ayBmcm9tIHRoZSBXRyAoZXNwZWNpYWxseSBmcm9tIG1hbnVmYWN0dXJlcnMNCj4gaW52b2x2 ZWQgaW4gTUlGKS4gV2hlbiB0aGUgdGVybWluYWwgaXMgc2ltdWx0YW5lb3VzbHkgYXR0YWNo ZWQgdG8gc2V2ZXJhbA0KPiBpbnRlcmZhY2VzLCBpcyB0aGUgT1MgbWFuYWdlIGFkZHJlc3Mg c3BhY2Ugb3ZlcmxhcHBpbmc/IElmIHllcywgaG93IGRvZXMNCj4gaXQgd29yaz8NCj4NCj4N Cj4gLSBUaGUgc2VjdGlvbiAiQXBwbGUgTWFjIE9TIFgiIGlzIHBvb3IgaW4gY29tcGFyaXNv biB0byB3aW5kb3dzIGFuZCBMaW51eA0KPiBzZWN0aW9uLiBJZiB3ZSBkbyBub3QgaGF2ZSBt b3JlIGluZm9ybWF0aW9uIGZvciBhcHBsZSBtYWMgb3MsIHdlJ2xsIHJlbW92ZQ0KPiB0aGUg c2VjdGlvbi4NCj4NCj4gLSBBbmRyb2lkOiBjYW4gd2UgY29uc2lkZXIgdGhhdCBiYXNpYyBh bmRyb2lkIGtlcm5lbCAoZXhjbHVkaW5nIHZlbmRvcnMNCj4gc3BlY2lmaWMgaW1wbGVtZW50 YXRpb25zKSBtYW5hZ2VzIG11bHRpcGxlIGludGVyZmFjZXMgaXNzdWVzIGluIHRoZSBzYW1l DQo+IHdheSB0aGFuIHRoZSBjdXJyZW50IExpbnV4IE9TPw0KPg0KPg0KPiBSZWdhcmRzLA0K PiBQaWVycmljaw0KPg0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERl IDogbWlmLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWYtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZQ0KPiBKYXJpDQo+ID4gQXJra28NCj4gPiBFbnZvecOpIDogdmVuZHJl ZGkgMSBvY3RvYnJlIDIwMTAgMjA6NDUNCj4gPiDDgCA6IG1pZjsgZHJhZnQtaWV0Zi1taWYt Y3VycmVudC1wcmFjdGljZXNAdG9vbHMuaWV0Zi5vcmcNCj4gPiBPYmpldCA6IFttaWZdIEFE IHJldmlldyBvZiBkcmFmdC1pZXRmLW1pZi1jdXJyZW50LXByYWN0aWNlcw0KPiA+DQoNCj4g PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudC4gT3ZlcmFsbCwgdGhpcyBpcyBhIGdv b2QgZG9jdW1lbnQsIGJ1dA0KPiA+IHNvbWUgd29yayBzdGlsbCByZW1haW5zLiBNeSBiaWdn ZXN0IGlzc3VlcyB3ZXJlIHRoZSBmb2xsb3dpbmc6DQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQg aXMgcXVpdGUgZm9jdXNlZCBvbiB0aGUgYWNjZXNzIG5ldHdvcmsgc2VsZWN0aW9uIHByb2Js ZW0sDQo+ID4gd2hpY2ggaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkg aW4gUkZDIDUxMTMuIEl0IGlzIGZpbmUgdG8NCj4gPiBpbmNsdWRlIGRpc2N1c3Npb24gb2Yg dGhlIGFjY2VzcyBuZXR3b3JrIHNlbGVjdGlvbiBwcm9ibGVtIGFzIHdlbGwsDQo+ID4gYmVj YXVzZSBpdCBpcyBhbGwgcGFydCBvZiB0aGUgc2FtZSBwcm9ibGVtIHNwYWNlLiBCdXQgSSB3 b3VsZCBoYXZlDQo+ID4gZXhwZWN0ZWQgdGhlIGRvY3VtZW50IGRpc2N1c3MgaW4gbW9yZSBk ZXRhaWwgd2hhdCB0aGUgdmFyaW91cw0KPiA+IGltcGxlbWVudGF0aW9ucyBkbyBhdCBsYXll ciAzLiBGb3IgaW5zdGFuY2UsIGRvIHRoZXkgdXNlIFJGQyAzNDg0LCBhcmUNCj4gPiBETlMg c2V0dGluZ3MgcGVyLW5vZGUgb3IgcGVyLWludGVyZmFjZSwgaWYgYW4gYXBwbGljYXRpb24g aXMgYm91bmQgdG8gYW4NCj4gPiBpbnRlcmZhY2UgZG9lcyBpdCBhbHdheXMgdXNlIHRoZSBE TlMgc2V0dGluZ3MgZm9yIGV4YWN0bHkgdGhhdCBpbnRlcmZhY2UNCj4gPiBvciB0aGUgcGVy LW5vZGUgc2V0dGluZ3MsIHdoYXQgaGFwcGVucyB3aXRoIG92ZXJsYXBwaW5nIGFkZHJlc3Mg c3BhY2UsDQo+IGV0Yy4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCBpcyBzb21ld2hhdCBpbWJh bGFuY2VkLCB0aGVyZSdzIHZlcnkgbGl0dGxlICh0b28gbGl0dGxlKQ0KPiA+IGluZm9ybWF0 aW9uIGFib3V0IHNvbWUgZGV2aWNlcyBhbmQgb3BlcmF0aW5nIHN5c3RlbXMgd2hlcmVhcyB0 aGUgV2luZG93cw0KPiA+IGRlc2NyaXB0aW9uIGlzIGRldGFpbGVkIGFuZCBpbmZvcm1hdGl2 ZS4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgc29tZSBvZg0KPiA+IHRoZSBkZXZpY2VzIGZvciB3 aGljaCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBpbmZvcm1hdGlvbiBhcmUgZWl0aGVyDQo+ID4g cmVtb3ZlZCBmcm9tIHRoZSBkb2N1bWVudCBvciBzb21lIG1vcmUgaW5mb3JtYXRpb24gaXMg aW5zZXJ0ZWQgYWJvdXQNCj4gdGhlbS4NCj4gPg0KPiA+IERldGFpbGVkIGNvbW1lbnRzOg0K PiA+DQo+ID4gU2VjdGlvbiAzLjEuMyBzL2luIGEgTUlGIGNvbnRleHQvaGVyZS8gKHRoZSBN SUYgY29udGV4dCBpcyBhIGZpbmUgdGVybQ0KPiA+IHRvIHVzZSBpbiBXRyBkaXNjdXNzaW9u LCBidXQgd2lsbCBsb29rIG9kZCBpbiBhIHB1Ymxpc2hlZCBSRkMgYnkgdGhlDQo+ID4gdGlt ZSB0aGUgV0cgaGFzIGNvbmNsdWRlZCkuDQo+ID4NCj4NCg0KPiBORVcgVEVYVDoNCj4NCj4g SW4gY29tcGFyaXNvbiB0byBXaW5kb3dzIE1vYmlsZSAyMDAzIFNFLCBXaW5kb3dzIHBob25l IDcgYnJpbmdzIHVwZGF0ZSBvZg0KPiB0aGUgcm91dGluZyBmdW5jdGlvbmFsaXR5IGluIHRo ZSBjYXNlIHdoZXJlIHRoZSB0ZXJtaW5hbCBjYW4gYmUgYXR0YWNoZWQNCj4gc2ltdWx0YW5l b3VzbHkgdG8gc2V2ZXJhbCBpbnRlcmZhY2VzLg0KPg0KDQo+ID4gT24gU2VjdGlvbiAzLjEu NCAoQmxhY2tCZXJyeSkgaXQgd2FzIHVuY2xlYXIgdG8gbWUgd2hhdCB0eXBlIG9mIGdhdGV3 YXlzDQo+ID4gdGhlIHRleHQgcmVmZXJzIHRvLiBEZWZhdWx0IHJvdXRlciwgd2ViIHByb3h5 LCBhcHBsaWNhdGlvbiBwcm94eSwNCj4gPiBzb21ldGhpbmcgZWxzZT8NCj4NCg0KPiBJIGFn cmVlIHRoYXQgdGhlIG9yaWdpbmFsIHRleHQgd2FzIHVuY2xlYXIuIEkndmUgcmV2aXNlZCB0 aGUgc2VjdGlvbiBidXQNCj4gR2l5ZW9uZywgcGxlYXNlIGNoZWNrIHdlIGtlcHQgaWRlYXMg ZnJvbSB5b3VyIG9yaWdpbmFsIHRleHQuDQo+DQoNCj4gT24gdGhlIHNlY29uZCBwYXJhZ3Jh cGggb2YgdGhlIHNhbWUgc2VjdGlvbiBpdCBpcw0KPiA+IHVuY2xlYXIgd2hhdCAiZGV2aWNl IiByZWZlcnMgdG8uIFRoZSBlbnRpcmUgZGV2aWNlIGNhbiB1c2UgbXVsdGlwbGUNCj4gPiBu ZXR3b3JrcyBzaW11bHRhbmVvdXNseT8gRG9lcyB0aGF0IG1lYW4gdGhhdCBvbmUgYXBwbGlj YXRpb24gY2FuIHVzZQ0KPiA+IG11bHRpcGxlIG5ldHdvcmtzIHNpbXVsdGFuZW91c2x5LCB0 byB0aGUgc2FtZSBkZXN0aW5hdGlvbnMgKGxpa2UgaW4NCj4gPiBtcC10Y3ApIG9yIHRvIGRp ZmZlcmVudCBkZXN0aW5hdGlvbnM/IE9yIGp1c3QgdGhhdCBtdWx0aXBsZSBhcHBsaWNhdGlv bnMNCj4gPiBjYW4gdXNlIGRpZmZlcmVudCBuZXR3b3JrcyBzaW11bHRhbmVvdXNseT9gUGxl YXNlIGJlIG1vcmUgcHJlY2lzZSBhYm91dA0KPiA+IHdoYXQgaXMgYWN0dWFsbHkgaGFwcGVu aW5nLCBhcyBvcHBvc2VkIHRvIGNsYWltaW5nIGEgZ2VuZXJhbCBjYXBhYmlsaXR5Lg0KPiA+ DQo+DQoNCj4gT2ssIHRleHQgaGFzIGJlZW4gcmV2aXNlZC4NCj4NCg0KPiA+IFNlY3Rpb24g My4xLjcgc2F5cyB2ZXJ5IGxpdHRsZSBhYm91dCB0aGUgaGFyZCBpc3N1ZXMgYXJvdW5kIE1J Riwgc3VjaCBhcw0KPiA+IHdoZXRoZXIgb3ZlcmxhcHBpbmcgYWRkcmVzcyBzcGFjZSBpcyB0 b2xlcmF0ZWQsIHdoZXRoZXIgdGhlcmUgaXMgYQ0KPiA+IHBvc3NpYmlsaXR5IG9mIHNvbWUg cG9saWN5IGJlaW5nIHNlbnQgZnJvbSB0aGUgbmV0d29yaywgd2hldGhlciBETlMgaW5mbw0K PiA+IGlzIHBlciBub2RlIG9yIHBlciBpbnRlcmZhY2UsIGV0Yy4NCj4gPg0KPiA+IEJ1dCBh bHNvIG90aGVyIHNlY3Rpb25zIHVuZGVyIDMuMSBzZWVtIHRoaW4uIEkgcmVhbGl6ZSB0aGF0 IGl0cyBoYXJkIHRvDQo+ID4gZ2V0IGluZm9ybWF0aW9uLCBidXQgYXQgbGVhc3Qgc29tZSBv ZiB0aGVzZSBkZXZpY2VzIGFyZSBvcGVuIHNvdXJjZSBhbmQNCj4gPiBydW4gb24gdG9wIG9m IHN0YW5kYXJkIGtlcm5lbHMgc3VjaCBhcyBMaW51eCwgc28gaXQgc2hvdWxkIGJlIHBvc3Np YmxlDQo+ID4gdG8gZmluZCBvdXQgYSBiaXQgbW9yZS4NCj4NCg0KPiBJIGd1ZXNzIHlvdSBh cmUgcmVmZXJlbmNpbmcgdG8gYW5kcm9pZCB0ZXJtaW5hbHM7IEkgd2FzIGFsc28gdGhpbmtp bmcgdGhhdA0KPiB0aGUgYmVoYXZpb3VyIG9mIGFuIGFuZHJvaWQgY291bGQgYmUgZGVkdWNl ZCBmcm9tIGN1cnJlbnQgTGludXgNCj4gZnVuY3Rpb25hbGl0aWVzIGJ1dCBpdCBzZWVtcyB0 aGF0IHRoZSBzaXR1YXRpb24gaXMgbW9yZSBjb21wbGV4LiBJdCdzIHRydWUNCj4gdGhhdCBB bmRyb2lkIGlzIGJhc2VkIG9uIGEgTGludXgga2VybmVsIGJ1dCBzb21lIGZ1bmN0aW9ucyBh cmUgc29tZXRpbWVzDQo+IGN1c3RvbWl6ZWQgYnkgdmVuZG9ycy4gU28gd2Ugc29tZXRpbWVz IGV4cGVyaWVuY2UgZGlmZmVyZW50IGJlaGF2aW91cg0KPiBiZXR3ZWVuIGRpZmZlcmVudCBh bmRyb2lkIHRlcm1pbmFscy4gRm9yIGluc3RhbmNlLCBzb21lIGFuZHJvaWQgdGVybWluYWwN Cj4gY2Fubm90IHJ1biBJUHY2IG9ubHksIHRoZXkgbmVlZCBnZXR0aW5nIGFuIElQdjQgYWRk cmVzcyBmaXJzdCwgYW5kIHRoZW4sDQo+IGV2ZW4gd2l0aCBJUHY2IHN1cHBvcnQgc29tZSBh bmRyb2lkIGNhbm5vdCBtYW5hZ2UgbXVsdGlwbGUgSVB2NiBwcmVmaXhlcw0KPiBvbiBhIHNp bmdsZSBpbnRlcmZhY2U7IHNvbWUgb3RoZXJzIGluaGliaXQgdGhlIDNHL1dMQU4gbXVsdGlo b21pbmcuLi4uDQo+IHdoaWxlIGFsbCB0aGVzZSBmdW5jdGlvbnMgYXJlIHdlbGwgc3VwcG9y dGVkIG9uIGEgTGludXggbGFwdG9wLiBOb3RlIHRoYXQNCj4gaXQgaXMgbm90IGp1c3QgYSBt YXR0ZXIgb2YgY29uZmlndXJhdGlvbiBzaW5jZSBhbmQgdGhlIG9ubHkgd2F5IHRvDQo+IG92 ZXJjb21lIHRoZXNlIGxpbWl0YXRpb25zIGlzIHRvIGNoYW5nZSB0aGUgYW5kcm9pZCBwbGF0 Zm9ybS4NCj4NCj4gSSd2ZSBhZGRlZCBpbiB0aGUgdGV4dCB0aGF0IGJlaGF2aW91ciBvZiBh biBhbmRyb2lkIHRlcm1pbmFsIGNhbiBkZXBlbmRzDQo+IG9uIHRoZSB2ZW5kb3JzIGltcGxl bWVudGF0aW9uLg0KPg0KDQo+IE9yIHdlIGNhbiBhc2sgZm9yIGZ1cnRoZXIgaW5mb3JtYXRp b24gZnJvbSB0aGUNCj4gPiBwZW9wbGUgd2hvIGdhdmUgdXMgdGhlIG9yaWdpbmFsIGRhdGEs IEkgc3VwcG9zZSBhdCBsZWFzdCBzb21lIG9mIHRoZW0NCj4gPiB3b3JrIGZvciB0aGUgbWFu dWZhY3R1cmVycy4NCj4gPg0KPg0KDQo+IFllcCwgd2UgbmVlZCBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGZyb20gdmVuZG9ycy4uLi4NCj4NCj4gPiA+IGlQaG9uZQ0KPiA+ID4NCj4gPiA+ IElwaG9uZQ0KPiA+IEluY29uc2lzdGVudCBjYXBpdGFsaXphdGlvbi4NCj4gPg0KPg0KPiBG aXhlZA0KPg0KDQo+ID4gPiAgICAgICBXaGF0ZXZlciBpcyB0aGUgaGFuZHNldCwgZmFsbGJh Y2sgb24gTDMgYXR0YWNobWVudCBmYWlsdXJlIGlzDQo+IG5vdA0KPiA+ID4gICAgICAgc3Vw cG9ydGVkIGZvciBtb3Rpb25sZXNzIHRlcm1pbmFscy4gIEFjdHVhbGx5LCB0aGUgY29ubmVj dGlvbg0KPiA+ID4gICAgICAgbWFuYWdlciBhbHdheXMgc2VsZWN0cyB0aGUgbW9zdCBwb3dl cmZ1bCBzaWduYWwgc3RyZW5ndGggd2l0aG91dA0KPiA+ID4gICAgICAgY29uc2lkZXJpbmcg SVAgY29uZmlndXJhdGlvbiByZXN1bHRzLiAgSW4gb3RoZXIgd29yZHMsIGlmIHRoZQ0KPiA+ ID4gICAgICAgdGVybWluYWwgaXMgdW5hYmxlIHRvIHNldCB1cCB0aGUgSVAgY29ubmVjdGl2 aXR5IG9uIG9uZSB3aWZpDQo+ID4gPiAgICAgICBhY2Nlc3MsIHRoZSBjb25uZWN0aW9uIG1h bmFnZXIgd2lsbCBub3QgdHJ5IHRvIGF0dGFjaCB0byBhbg0KPiA+ID4gICAgICAgYWx0ZXJu YXRpdmUgcG9pbnQgb2YgYXR0YWNobWVudCAob3IgU1NJRCkgYXMgbG9uZyBhcyB0aGUgc2ln bmFsDQo+ID4gPiAgICAgICBzdHJlbmd0aCBvZiB0aGUgZmlyc3QgcmFkaW8gbGluayBpcyB0 aGUgbW9zdCBwb3dlcmZ1bC4NCj4gPg0KPiA+IFdoYXQgaXMgIm1vdGlvbmxlc3MgdGVybWlu YWwiPyBBbGwgZGV2aWNlcyB0aGF0IHlvdSBtZW50aW9uIGFyZSBtb2JpbGUuDQo+ID4NCj4N Cg0KPiBXZSBtZWFudDogYSB0ZXJtaW5hbCB3aGljaCByZW1haW5zIHVuZGVyIGNvdmVyYWdl IG9mIHRoZSBzYW1lIEFQLg0KPg0KPiBUaGUgdGVzdCBoYXMgYmVlbiByZXZpc2VkLg0KPg0K DQo+ID4gQmVzaWRlcywgSSdtIGZhaXJseSBjZXJ0YWluIHRoYXQgdGhlIGFib3ZlIGRvZXMg bm90IGFwcGx5IHRvIEFuZHJvaWQuDQo+ID4gVGhlIGRldmljZSB0aGF0IEkgaGF2ZSBkb2Vz IHNlZW0gdG8gc3dpdGNoIGF3YXkgZnJvbSBhIHN0cm9uZy1zaWduYWwNCj4gPiBTU0lEIHRv IGFub3RoZXIgU1NJRCwgaWYgTDMgYXR0YWNobWVudCBmYWlscy4NCj4gPg0KPg0KDQo+IEFj dHVhbGx5LCB3ZSBjYW4gaGF2ZSBkaWZmZXJlbnQgYmVoYXZpb3VyIHdpdGggZGlmZmVyZW50 IEFuZHJvaWQgcGxhdGZvcm1zDQo+IChzZWUgYWJvdmUpLiBUaGUgdGV4dCBpbiB0aGUgZG9j IGFwcGxpZXMgb25seSB0byB0aGUgIkhUQyBtYWppYyIuDQo+DQoNCj4gPiA+IGluIHRoZSBz Y29wZSBvZiBNSUYuDQo+ID4gPg0KPiA+DQo+ID4gLi4uIGluIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KPiA+DQo+DQoNCj4gT2ssIGZpeGVkDQoNCj4NCj4gPiBKYXJpDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IG1pZiBtYWlsaW5nIGxpc3QNCj4gPiBtaWZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pZiBtYWlsaW5nIGxpc3QNCm1pZkBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYNCg0KDQoN Cg0KLS0gDQpTdGVmYW5vIE0uIEZhY2Npbg0KPT09PT09PT09PT09PT09PT09DQpNYXkgdGhl IEZvcmNlIGJlIHdpdGggeW91DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANClRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlh bCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJs ZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBB bnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBh dXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpU aGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNs dWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90 aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBp bmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlh dGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBm cm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3Ig cmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBp ZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K ------_=_NextPart_002_01CBC6EA.450F365F Content-Type: text/html; charset="UTF-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cu dzMub3JnL1RSL1JFQy1odG1sNDAiDQp4bWxuczpuczA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1l PUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQgbWVkaXVt KSI+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZh dWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tYTps aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElOSw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7fQ0KYTp2aXNpdGVkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElOS0ZPTExPV0VEDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTt9DQpwLk1TT0FDRVRBVEUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5O30NCmxpLk1T T0FDRVRBVEUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5O30NCmRpdi5NU09BQ0VUQVRFDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTt9DQpzcGFuLkJBTExPT05URVhUQ0hBUg0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7fQ0KDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXZWJkaW5nczsNCglwYW5vc2UtMTo1IDMgMSAyIDEgNSA5IDYg NyAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1T IE1pbmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseTpUYWhvbWE7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7Zm9udC1mYW1pbHk6VGFob21hO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OkFyaWFsOw0KCWNvbG9yOm5hdnk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdE O30NCnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlh bDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEu OXB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KDQo8Ym9keSBsYW5nPUZSIGxpbms9Ymx1ZSB2bGluaz1ibHVlPjxmb250IHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NClBpZXJyaWNrLDxicj5JIGJlbGll dmUgdGhlIHN0YXRlbWVudCBhcyB5b3UgcGhyYXNlZCBjYXB0dXJlcyB0aGUgY29uY2VwdCB2 ZXJ5IHdlbGwuPGJyPlRoYW5rcyw8YnI+U3RlZmFubzxicj4NPGJyPlN0ZWZhbm8gTS4gRmFj Y2luDTxicj4NPGJyPlN0YW5kYXJkcyBNYW5hZ2VyDTxicj5SZXNlYXJjaCBJbiBNb3Rpb24N PGJyPjEyMiBXZXN0IEpvaG4gQ2FycGVudGVyIFBhcmt3YXkNPGJyPklydmluZywgVFggNzUw MzkNPGJyPkludGVybmFsOiA4MjAgNjM0NTENPGJyPkRlc2s6ICsxIDk3MiA5MTAgMzQ1MQ08 YnI+QmxhY2tCZXJyeTogKzEgNTEwIDIzMCA4NDIyDTxicj5zZmFjY2luQHJpbS5jb20NPGJy PlRpbWUgem9uZTogUFNUIChHTVQgLTgpPC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8Yj5Gcm9tPC9iPjogcGllcnJpY2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tIFttYWls dG86cGllcnJpY2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tXQ08YnI+PGI+U2VudDwvYj46 IE1vbmRheSwgRmVicnVhcnkgMDcsIDIwMTEgMTE6MDcgQU08YnI+PGI+VG88L2I+OiBTdGVm YW5vIEZhY2Npbjsgc2ZhY2NpbnN0ZEBnbWFpbC5jb20gJmx0O3NmYWNjaW5zdGRAZ21haWwu Y29tJmd0OzsgbWlmQGlldGYub3JnICZsdDttaWZAaWV0Zi5vcmcmZ3Q7OyBqYXJpLmFya2tv QHBpdWhhLm5ldCAmbHQ7amFyaS5hcmtrb0BwaXVoYS5uZXQmZ3Q7DTxicj48Yj5TdWJqZWN0 PC9iPjogUkU6IFttaWZdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1pZi1jdXJyZW50LXBy YWN0aWNlcw08YnI+PC9mb250PiZuYnNwOzxicj48L2Rpdj4NCg0KDQo8ZGl2IGNsYXNzPVNl Y3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5JZiBJIHJlZmVyIHRvIHRoZSBjdXJyZW50 DQp0ZXh0IG9uIFJJTSwgSSB1bmRlcnN0YW5kIHRoYXQgPC9zcGFuPjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IiMxZjQ5N2QiDQpmYWNlPUNhbGlicmk+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpOw0KY29sb3I6IzFG NDk3RCc+QWRkcmVzcyBvdmVybGFwcGluZyBpcyBzdXBwb3J0ZWQgYmVjYXVzZSB0PC9zcGFu PjwvZm9udD48Zm9udA0Kc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6bmF2eSc+aGUgT1MgY2FuIG1hbmFnZSBtdWx0aXBsZSBJUCBzdGFja3MgYXNzb2NpYXRl ZCB0bw0KbXVsdGlwbGUgaW50ZXJmYWNlLiBSaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5QaWVycmljayA8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8 ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAl IiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWln aHQ6Ym9sZCc+RGUmbmJzcDs6PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNl PVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhv bWEnPiBTdGVmYW5vIEZhY2Npbg0KW21haWx0bzpzZmFjY2luQHJpbS5jb21dIDxicj4NCjxi PjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5FbnZvecOpJm5ic3A7Ojwvc3Bhbj48 L2I+IGx1bmRpIDcgZsOpdnJpZXIgMjAxMQ0KMTc6NDE8YnI+DQo8Yj48c3BhbiBzdHlsZT0n Zm9udC13ZWlnaHQ6Ym9sZCc+w4AmbmJzcDs6PC9zcGFuPjwvYj4gU0VJVEUgUGllcnJpY2sN ClJELVJFU0EtUkVOOyBzZmFjY2luc3RkQGdtYWlsLmNvbTsgbWlmQGlldGYub3JnOyBqYXJp LmFya2tvQHBpdWhhLm5ldDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xk Jz5PYmpldCZuYnNwOzo8L3NwYW4+PC9iPiBSRTogW21pZl0gQUQgcmV2aWV3DQpvZiBkcmFm dC1pZXRmLW1pZi1jdXJyZW50LXByYWN0aWNlczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9 RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCc+UGllcnJpY2ssPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1D YWxpYnJpPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+VGhlIEJsYWNrQmVycnkgdXNlcw0KcGVy LWludGVyZmFjZSBETlMgYW5kIGFwcGxpY2F0aW9ucyB1c2UgdGhlIEROUyBib3VuZCB0byBh IHNwZWNpZmljIGludGVyZmFjZS4NCkFkZHJlc3Mgb3ZlcmxhcHBpbmcgaXMgc3VwcG9ydGVk IGFuZCBpcyBtYW5hZ2VkIGJ5IE9TIG1lY2hhbmlzbXMuIEkgaG9wZSB0aGlzDQpzdWZmaWNl cy4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIGxhbmc9 RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCc+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2Fs aWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxkaXY+DQoNCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3Jk ZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+DQogPHRyPg0KICA8dGQgc3R5bGU9 J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuDQogIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+U3Rl ZmFubyBGYWNjaW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNw YW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGli cmk+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjojMUY0OTdEJz5TdGFuZGFyZHMgTWFuYWdlcjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgY29sb3I9 YmxhY2sgZmFjZT1DYWxpYnJpPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCc+UmVzZWFy Y2gNCiAgSW4gTW90aW9uIENvcnBvcmF0aW9uPC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsYWNrIGZhY2U9Q2FsaWJyaT48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrJz4gPGJyPg0KICA1MDAw IFJpdmVyc2lkZSBEcml2ZSA8YnI+DQogIEJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUu IDEwMDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT1DYWxpYnJpPjxzcGFuDQogIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2snPkly dmluZywgVGV4YXMgNzUwMzkNCiAgVVNBIDxicj4NCiAgT2ZmaWNlOiAoOTcyKSA5MTAgMzQ1 MSZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9Q2FsaWJyaT48c3Bhbg0KICBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr Jz5JbnRlcm5hbDogODIwLjYzNDUxPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCiAg PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPUNhbGli cmk+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayc+PGltZyB3aWR0aD0xNA0KICBoZWlnaHQ9MTAgaWQ9IlBpY3R1cmVf eDAwNWZfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxQ0JDNkYxLkU4MTE3RkIw Ig0KICBhbHQ9VW50aXRsZWQtMT46ICg1MTApIDIzMCA4NDIyPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIg0KICBmYWNlPUNhbGlicmk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjojMUY0OTdEJz48YQ0KICBocmVmPSJvdXRiaW5kOi8vMjgtMDAwMDAwMDAxMTlFMzM4OURE QzVFMDQ1OTNFOTBGQjEzMzJBMDhDMTA3MDBBM0YwNjc1M0Q0MEQ0MTQ5QkYxNkU0MkVBMzAy NTlBQjAwMDAwMUI3OTA4QjAwMDBGN0I1MEFCNUI0RTExQjRDODA1MjlBQUIyMzEzRUYzRTAw MDAwMDZGMUJFQTAwMDAvd3d3LnJpbS5jb20iDQogIHRpdGxlPSJvdXRiaW5kOi8vMjgtMDAw MDAwMDAxMTlFMzM4OUREQzVFMDQ1OTNFOTBGQjEzMzJBMDhDMTA3MDBBM0YwNjc1M0Q0MEQ0 MTQ5QkYxNkU0MkVBMzAyNTlBQjAwMDAwMUI3OTA4QjAwMDBGN0I1MEFCNUI0RTExQjRDODA1 MjlBQUIyMzEzRUYzRTAwMDAwMDZGMUJFQTAwMDAvd3d3LnJpbS5jb20mIzEwO3d3dy5yaW0u Y29tIj48Zm9udA0KICBjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnd3 dy5yaW0uY29tPC9zcGFuPjwvZm9udD48L2E+PC9zcGFuPjwvZm9udD48Zm9udA0KICBzaXpl PTIgY29sb3I9YmxhY2sgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5Og0KICBDYWxpYnJpO2NvbG9yOmJsYWNrJz47IDwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIg0KICBmYWNlPUNhbGlicmk+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0 OTdEJz48YQ0KICBocmVmPSJvdXRiaW5kOi8vMjgtMDAwMDAwMDAxMTlFMzM4OUREQzVFMDQ1 OTNFOTBGQjEzMzJBMDhDMTA3MDBBM0YwNjc1M0Q0MEQ0MTQ5QkYxNkU0MkVBMzAyNTlBQjAw MDAwMUI3OTA4QjAwMDBGN0I1MEFCNUI0RTExQjRDODA1MjlBQUIyMzEzRUYzRTAwMDAwMDZG MUJFQTAwMDAvd3d3LmJsYWNrYmVycnkuY29tIg0KICB0aXRsZT0ib3V0YmluZDovLzI4LTAw MDAwMDAwMTE5RTMzODlEREM1RTA0NTkzRTkwRkIxMzMyQTA4QzEwNzAwQTNGMDY3NTNENDBE NDE0OUJGMTZFNDJFQTMwMjU5QUIwMDAwMDFCNzkwOEIwMDAwRjdCNTBBQjVCNEUxMUI0Qzgw NTI5QUFCMjMxM0VGM0UwMDAwMDA2RjFCRUEwMDAwL3d3dy5ibGFja2JlcnJ5LmNvbSYjMTA7 d3d3LmJsYWNrYmVycnkuY29tIj48Zm9udA0KICBjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPnd3dy5ibGFja2JlcnJ5LmNvbTwvc3Bhbj48L2ZvbnQ+PC9hPjwvc3Bh bj48L2ZvbnQ+PGZvbnQNCiAgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9Q2FsaWJyaT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToNCiAgQ2FsaWJyaTtjb2xv cjpibGFjayc+IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQogIDwvdGQ+DQogIDx0 ZCB3aWR0aD0xNjAgc3R5bGU9J3dpZHRoOjEyMC4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAw Y20nPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQogIDwvdGQ+DQogPC90cj4NCjwvdGFibGU+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PGEgaHJlZj0i aHR0cDovL3d3dy5ibGFja2JlcnJ5LmNvbS8iPjxmb250IHNpemU9Mg0KY29sb3I9IiMxZjQ5 N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpOw0KY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSc+PGlt ZyBib3JkZXI9MCB3aWR0aD0xMzggaGVpZ2h0PTYyDQppZD0iUGljdHVyZV94MDA1Zl94MDAy MF82IiBzcmM9ImNpZDppbWFnZTAwMy5qcGdAMDFDQkM2RjEuRTgxMTdGQjAiDQphbHQ9ImNp ZDppbWFnZTAwNC5wbmdAMDFDQjQ5RUEuODdEOTIxNDAiPjwvc3Bhbj48L2ZvbnQ+PC9hPjwv c3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJp PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTUgY29s b3I9IiM0ZjYyMjgiIGZhY2U9V2ViZGluZ3M+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2Zv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6V2ViZGluZ3M7Y29sb3I6IzRGNjIyOCc+UDwv c3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9NCBjb2xvcj0iIzRmNjIyOCIgZmFjZT1WZXJkYW5h PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7DQpmb250LWZhbWls eTpWZXJkYW5hO2NvbG9yOiM0RjYyMjgnPiA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MSBj b2xvcj0iIzRmNjIyOCINCmZhY2U9Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCmNvbG9yOiM0RjYyMjgnPkNv bnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcuPC9zcGFuPjwvZm9udD48 Zm9udA0Kc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 Q2FsaWJyaT48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bh biBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhv bWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udA0Kc2l6 ZT0yIGZhY2U9VGFob21hPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6VGFob21hJz4NCm1pZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bWlmLWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDoNCmJv bGQnPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9iPnBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdy b3VwLmNvbTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwv c3Bhbj48L2I+IE1vbmRheSwgRmVicnVhcnkgMDcsIDIwMTENCjEyOjQwIEFNPGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IHNmYWNjaW5z dGRAZ21haWwuY29tOw0KbWlmQGlldGYub3JnOyBqYXJpLmFya2tvQHBpdWhhLm5ldDxicj4N CjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+ IFJlOiBbbWlmXSBBRCByZXZpZXcgb2YNCmRyYWZ0LWlldGYtbWlmLWN1cnJlbnQtcHJhY3Rp Y2VzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkhpIFN0 ZWZhbm8sPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1H Qg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1F Ti1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eSc+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLA0KSSYjODIxNztsbCB1cGRhdGUgdGhl IGRyYWZ0IGFjY29yZGluZ2x5LiBCVFcsIGRvIHlvdSBoYXZlIGluZm9ybWF0aW9uIG9uIHRo ZQ0KZm9sbG93aW5nIHBvaW50cyBmb3IgUklNIGJsYWNrYmVycnk6PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+LSBIb3cgdGhlIFJJTSBi bGFja2JlcnJ5DQptYW5hZ2UgQWRkcmVzcyBzZWxlY3Rpb246IGUuZy4gaXMgUkZDIDM0ODQg c3VwcG9ydGVkPyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5n PUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBs YW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Jz4tIEROUyByZXNvbHV0aW9uIGlzc3VlIG9uDQpSSU0gYmxhY2tiZXJyeTog aXMgRE5TIGNvbmZpZ3VyYXRpb24gcGVyLW5vZGUgb3IgcGVyLWludGVyZmFjZT8gSWYgYW4N CmFwcGxpY2F0aW9uIGlzIGJvdW5kIHRvIGFuIGludGVyZmFjZSwgZG9lcyBpdCBhbHdheXMg dXNlIHRoZSBETlMgc2V0dGluZ3MgZm9yDQpleGFjdGx5IHRoYXQgaW50ZXJmYWNlIG9yIHRo ZSBwZXItbm9kZSBzZXR0aW5ncy4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+ PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+LSBhZGRyZXNzIHNwYWNlDQpvdmVybGFwcGluZzogV2hl biB0aGUgUklNIGJsYWNrYmVycnkgaXMgc2ltdWx0YW5lb3VzbHkgYXR0YWNoZWQgdG8gc2V2 ZXJhbA0KaW50ZXJmYWNlcywgaXMgdGhlIE9TIG1hbmFnZSBhZGRyZXNzIHNwYWNlIG92ZXJs YXBwaW5nPyBJZiB5ZXMsIGhvdyBkb2VzIGl0DQp3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6 bm9uZSc+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0KbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+QlIsPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlBpZXJyaWNr PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2Vu dGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNp emU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQt d2VpZ2h0OmJvbGQnPkRlJm5ic3A7Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0K ZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 VGFob21hJz4NCm1pZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDoNCmJvbGQnPkRlIGxhIHBhcnQg ZGU8L3NwYW4+PC9iPiBzdGVmYW5vIGZhY2Npbjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250 LXdlaWdodDpib2xkJz5FbnZvecOpJm5ic3A7Ojwvc3Bhbj48L2I+IHZlbmRyZWRpIDQgZsOp dnJpZXINCjIwMTEgMjA6MzE8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+w4AmbmJzcDs6PC9zcGFuPjwvYj4gbWlmQGlldGYub3JnOw0KamFyaS5hcmtrb0BwaXVo YS5uZXQ8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+T2JqZXQmbmJz cDs6PC9zcGFuPjwvYj4gUmU6IFttaWZdIEFEIHJldmlldw0Kb2YgZHJhZnQtaWV0Zi1taWYt Y3VycmVudC1wcmFjdGljZXM8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxmb250IHNpemU9MiBjb2xvcj1ibGFjaw0KZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpibGFjayc+SGVsbG8NCmFsbCw8YnI+DQpJIGhhdmUgcmV2aWV3ZWQgdmVyc2lvbiAwNiBv ZiB0aGUgZHJhZnQgYW5kIEkgaGF2ZSBhIGZldyBjb21tZW50cy48YnI+DQo8YnI+DQpVbmRl ciBzZWN0aW9uIDMuMS4zIG9uIHRoZSBCbGFja0JlcnJ5LCBJIHdvdWxkIG1vZGlmeSAmcXVv dDtKYXZhDQphcHBsaWNhdGlvbnMmcXVvdDsgdG8ganVzdCAmcXVvdDthcHBsaWNhdGlvbnMm cXVvdDssIHNpbmNlIEkgYmVsaWV2ZSB3ZSB3YW50IHRvDQpjYXB0dXJlIHRoZSBtb3N0IGdl bmVyaWMgY2FzZSBvZiBCbGFja0JlcnJ5LCBpbmRlcGVuZGVudGx5IG9mIHRoZSBPUy48YnI+ DQo8YnI+DQpVbmRlciBzZWN0aW9uIDMuMS4zIG9uIHRoZSBCbGFja0JlcnJ5LCBpdCBzYXlz ICZxdW90O0FuIGFwcGxpY2F0aW9uIGNvbm5lY3RpbmcNCnRvIHRoZSBJbnRlcm5ldCwgY2Fu IHVzZSBlaXRoZXIgdGhlIEJsYWNrQmVycnkgSW50ZXJuZXQgU2VydmljZSBvciB0aGUgSW50 ZXJuZXQNCmdhdGV3YXkgb2YgdGhlIHdpcmVsZXNzIHNlcnZlciBwcm92aWRlciB0byBtYW5h Z2UgY29ubmVjdGlvbnMmcXVvdDsuIENhbiB3ZQ0KbW9kaWZ5IHRoaXMgdG8gJnF1b3Q7Li4u IGNhbiB1c2UgZWl0aGVyIHRoZSBCbGFja0JlcnJ5IEludGVybmV0IFNlcnZpY2Ugb3IgdGhl DQpJbnRlcm5ldCBnYXRld2F5IG9mIHRoZSB3aXJlbGVzcyBzZXJ2ZXIgcHJvdmlkZXIgb3Ig ZGlyZWN0IEludGVybmV0DQpjb25uZWN0aXZpdHkgb3ZlciBXTEFOIHRvIC4uLiZxdW90OyBm b3IgY29ycmVjdG5lc3MvY29tcGxldGVuZXNzPzxicj4NCjxicj4NCkluIHNlY3Rpb24gMy4x LjcgdGhlcmUgaXMgYW4gaW5jb3JyZWN0IHN0YXRlbWVudCAmcXVvdDtUaGUgUklNIEJsYWNr YmVycnkNCmJlaGF2ZXMgZGlmZmVyZW50bHksIHRoZSBjb25uZWN0aW9uIG1hbmFnZXIgc2Vs ZWN0cyB0aGUgZmlyc3QgU1NJRCBvbiB3aGljaCBpdA0KaGFzIG1hbmFnZWQgdG8gYXR0YWNo IGluIHRoZSBwYXN0LiZxdW90OyBQbGVhc2UgcmVwbGFjZSB0aGlzIHN0YXRlbWVudCB3aXRo DQomcXVvdDtUaGUgUklNIEJsYWNrYmVycnkgYmVoYXZlcyBkaWZmZXJlbnRseTogdGhlIHVz ZXIgKGUuZy4gdGhlIGVudGVycHJpc2UNCm93bmluZyB0aGUgZGV2aWNlKSBpcyBhbGxvd2Vk IHRvIGRlZmluZSBpdHMgcHJlZmVycmVkIGFjY2Vzcy4gVGhlIGNvbm5lY3Rpb24NCm1hbmFn ZXIgc2VsZWN0cyB0aGUgZmlyc3QgU1NJRCBvZiB0aGUgcHJlZmVycmVkIGxpc3Qgb2YgU1NJ RHMgY29uZmlndXJlZCBpbiB0aGUNCmRldmljZSBhbmQgdGhhdCBpcyBhdmFpbGFibGUgYmFz ZWQgb24gdGhlIFdMQU4gc2NhbiB0aGUgZGV2aWNlIGhhcyBwZXJmb3JtZWQmcXVvdDssDQpz aW5jZSBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBCbGFja0JlcnJ5IGFsd2F5cyB0cmllcyBm aXJzdCB0aGUgbGFzdCBTU0lEIGl0DQpoYXMgbWFuYWdlZCB0byBhdHRhY2ggaW4gdGhlIHBh c3QuJm5ic3A7IDxicj4NCjxicj4NClRoZSBzZWN0aW9uIGFsc28gY29udGFpbiBhIHN0YXRl bWVudCB0aGF0IGRvZXMgbm90IGFwcGx5IHRvIGFsbCBkPHNwYW4NCnN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz5ldmljZXMsIGkuZS4gJnF1b3Q7V2hlbiB0aGUgSVAgc3RhY2sgZmFpbHMg dG8gb2J0YWluDQphbiBJUCBhZGRyZXNzLCB0aGUgaGFuZHNldCwgZXhjZXB0ZWQgdGhlIGlQ aG9uZSwgcmVzdGFydHMgV0xBTiBhdHRhY2htZW50DQpzZWxlY3RpbmcgdGhlIHNlY29uZCBT U0lEIGluIHRoZSBsaXN0LiAmcXVvdDs8L3NwYW4+IFRoZSBCbGFja0JlcnJ5LCB3aGVuIGl0 DQpmYWlscyB0byBvYnRhaW4gYW4gSVAgYWRkcmVzcyBhZnRlciBzdWNjZXNzZnVsIFdMQU4g YXR0YWNobWVudCwgcGVyZm9ybXMgYSBuZXcNCldMQU4gc2NhbiBhbmQsIGFtb25nIHRoZSBu ZXR3b3JrcyBhdmFpbGFibGUsIGl0IHNlbGVjdHMgdGhlIG5leHQgU1NJRCBpbiB0aGUNCnBy ZWZlcnJlZCBsaXN0LCB3aGljaCBtZWFucyB0aGF0IHRoZSBhcHByb2FjaCBpcyBkaWZmZXJl bnQgZnJvbSB0aGUgb25lIHRoZSBvcmlnaW5hbA0Kc2VudGVuY2UgdHJpZXMgdG8gY2FwdHVy ZS4gPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NClN0ZWZhbm88L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEyLjBwdCc+T24gVHVlLCBGZWIgMSwgMjAxMSBhdCA2OjQxIEFNLCAmbHQ7PGENCmhyZWY9 Im1haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20iPnBpZXJyaWNrLnNl aXRlQG9yYW5nZS1mdGdyb3VwLmNvbTwvYT4mZ3Q7DQp3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SGVs bG8gSmFyaSw8YnI+DQo8YnI+DQpJJ3ZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRy YWZ0LWlldGYtbWlmLWN1cnJlbnQtcHJhY3RpY2VzICg8YQ0KaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taWYtY3VycmVudC1wcmFjdGlj ZXMtMDYudHh0Ig0KdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWlmLWN1cnJlbnQtcHJhY3RpY2VzLTA2LnR4dDwvYT4p Lg0KQWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMsIE5va2lhICh0aGFua3MgYWdhaW4gVGVl bXUpLCBBbmRyb8OvZCBhbmQgTGludXgNCnNlY3Rpb25zIGhhdmUgYmVlbiB1cGRhdGVkIHdp dGggaW5mb3JtYXRpb24gcmVnYXJkaW5nIEROUyBjb25maWd1cmF0aW9uLA0KUkZDMzQ4NCBz dXBwb3J0LCBSRkMxMTIyIHN0YXR1cyBhbmQgYWRkcmVzcyBvdmVybGFwcGluZyBpc3N1ZS4g U2VjdGlvbg0KJnF1b3Q7QXBwbGUmcXVvdDsgaGFzIGJlZW4gcmVtb3ZlZC48YnI+DQo8YnI+ DQpCUiw8YnI+DQpQaWVycmljazxicj4NCjxicj4NCiZndDsgLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tPGJyPg0KJmd0OyBEZSZuYnNwOzogU0VJVEUgUGllcnJpY2sgUkQtUkVTQS1S RU48YnI+DQomZ3Q7IEVudm95w6kmbmJzcDs6IHNhbWVkaSAyMyBvY3RvYnJlIDIwMTAgMTI6 MDE8YnI+DQomZ3Q7IMOAJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIj5t aWZAaWV0Zi5vcmc8L2E+OyA8YQ0KaHJlZj0ibWFpbHRvOmphcmkuYXJra29AcGl1aGEubmV0 Ij5qYXJpLmFya2tvQHBpdWhhLm5ldDwvYT48YnI+DQomZ3Q7IE9iamV0Jm5ic3A7OiBSRTog W21pZl0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbWlmLWN1cnJlbnQtcHJhY3RpY2VzPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMi4wcHQnPiZndDs8YnI+DQomZ3Q7IEhpIEphcmksIGFsbCw8YnI+DQom Z3Q7PGJyPg0KJmd0OyBXZSd2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJh ZnQtaWV0Zi1taWYtY3VycmVudC1wcmFjdGljZXM8YnI+DQomZ3Q7IChNb3JlIGRldGFpbHMg aW5saW5lKS4gSG93ZXZlciwgdGhlcmUgaXMgYSBwZW5kaW5nIGlzc3VlOiB3ZSBzdGlsbCBu ZWVkPGJyPg0KJmd0OyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBlc3BlY2lhbGx5IGZyb20g bWFudWZhY3R1cmVycywgdG8gYWRkcmVzcyB5b3VyPGJyPg0KJmd0OyBjb25jZXJuIHdpdGgg c2VjdGlvbiAzLjEuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28sIHdlIHJlcXVlc3QgdGhlIHN1 cHBvcnQgZnJvbSB0aGUgV0csIGVzcGVjaWFsbHkgZnJvbSBmb2xrcyB3aG8gaGF2ZTxicj4N CiZndDsgcHJvdmlkZWQgcGVyLU9TIGluaXRpYWwgaW5mb3JtYXRpb24sIHRvIGFkZHJlc3Mg SmFyaSdzIGNvbmNlcm5zLiBJbnRlcmZhY2U8YnI+DQomZ3Q7IHNlbGVjdGlvbiBpcywgZ2Vu ZXJhbGx5LCB3ZWxsIGRvY3VtZW50ZWQgYnV0IHdlIG5lZWQgbW9yZSBkZXRhaWxzIG9uPGJy Pg0KJmd0OyBmb2xsb3dpbmcgdG9waWNzOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gQWRkcmVz cyBzZWxlY3Rpb246IGlzIFJGQyAzNDg0IHN1cHBvcnRlZD8gTGludXggYW5kIHdpbmRvd3Mg aW1wbGVtZW50PGJyPg0KJmd0OyBSRkMzNDg0IChJJ3ZlIGp1c3Qgbm90aWNlZCB0aGF0IG9u bHkgdGhlIHdpbmRvd3Mgc2VjdGlvbiByZWZlcnMgdG8NClJGQzM0ODQsPGJyPg0KJmd0OyBJ J2xsIGFsaWduIHRoZSBsaW51eCBzZWN0aW9uIGluIHRoZSBuZXh0IHZlcnNpb24pLCBidXQg d2hhdCBhYm91dCB0aGU8YnI+DQomZ3Q7IG90aGVycyAobm9raWEsIGJsYWNrYmVycnksIHdp bmRvd3MgbW9iaWxlLCBhbmRyb2lkKT88YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEROUyByZXNv bHV0aW9uIGlzc3VlczogV2luZG93cyBhbmQgTGludXggc2VjdGlvbiBhcmUgd2VsbCBkb2N1 bWVudGVkLjxicj4NCiZndDsgQnV0IG90aGVycyBzZWN0aW9ucyBtdXN0IGJlIGRldmVsb3Bl ZC4gUmVmbGVjdGluZyBKYXJpJ3MgY29tbWVudDogaXMgRE5TPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz4mZ3Q7IGNvbmZpZ3VyYXRpb24gcGVyLW5vZGUgb3IgcGVyLWludGVyZmFjZT8gSWYg YW4gYXBwbGljYXRpb24gaXMNCmJvdW5kIHRvIGFuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZn dDsgaW50ZXJmYWNlLCBkb2VzIGl0IGFsd2F5cyB1c2UgdGhlIEROUyBzZXR0aW5ncyBmb3Ig ZXhhY3RseSB0aGF0DQppbnRlcmZhY2U8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZndDsgb3Ig dGhlIHBlci1ub2RlIHNldHRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mZ3Q7PGJyPg0K Jmd0OyAtIGFkZHJlc3Mgc3BhY2Ugb3ZlcmxhcHBpbmc6IHdlIGRvIG5vdCBoYXZlIGluZm9y bWF0aW9uIG9uIHRoZXNlIGlzc3Vlczxicj4NCiZndDsgYW5kIHdlJ2QgYXBwcmVjaWF0ZSBm ZWVkYmFjayBmcm9tIHRoZSBXRyAoZXNwZWNpYWxseSBmcm9tIG1hbnVmYWN0dXJlcnM8YnI+ DQomZ3Q7IGludm9sdmVkIGluIE1JRikuIFdoZW4gdGhlIHRlcm1pbmFsIGlzIHNpbXVsdGFu ZW91c2x5IGF0dGFjaGVkIHRvIHNldmVyYWw8YnI+DQomZ3Q7IGludGVyZmFjZXMsIGlzIHRo ZSBPUyBtYW5hZ2UgYWRkcmVzcyBzcGFjZSBvdmVybGFwcGluZz8gSWYgeWVzLCBob3cgZG9l czxicj4NCiZndDsgaXQgd29yaz88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBU aGUgc2VjdGlvbiAmcXVvdDtBcHBsZSBNYWMgT1MgWCZxdW90OyBpcyBwb29yIGluIGNvbXBh cmlzb24gdG8gd2luZG93cw0KYW5kIExpbnV4PGJyPg0KJmd0OyBzZWN0aW9uLiBJZiB3ZSBk byBub3QgaGF2ZSBtb3JlIGluZm9ybWF0aW9uIGZvciBhcHBsZSBtYWMgb3MsIHdlJ2xsIHJl bW92ZTxicj4NCiZndDsgdGhlIHNlY3Rpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgLSBBbmRy b2lkOiBjYW4gd2UgY29uc2lkZXIgdGhhdCBiYXNpYyBhbmRyb2lkIGtlcm5lbCAoZXhjbHVk aW5nIHZlbmRvcnM8YnI+DQomZ3Q7IHNwZWNpZmljIGltcGxlbWVudGF0aW9ucykgbWFuYWdl cyBtdWx0aXBsZSBpbnRlcmZhY2VzIGlzc3VlcyBpbiB0aGUgc2FtZTxicj4NCiZndDsgd2F5 IHRoYW4gdGhlIGN1cnJlbnQgTGludXggT1M/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBQaWVycmljazxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IERlJm5ic3A7 OiA8YSBocmVmPSJtYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5vcmciPm1pZi1ib3VuY2VzQGll dGYub3JnPC9hPg0KW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlmLWJvdW5jZXNAaWV0Zi5v cmciPm1pZi1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGENCnBhcnQgZGU8YnI+DQomZ3Q7 IEphcmk8YnI+DQomZ3Q7ICZndDsgQXJra288YnI+DQomZ3Q7ICZndDsgRW52b3nDqSZuYnNw OzogdmVuZHJlZGkgMSBvY3RvYnJlIDIwMTAgMjA6NDU8YnI+DQomZ3Q7ICZndDsgw4AmbmJz cDs6IG1pZjsgPGENCmhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1pZi1jdXJyZW50LXByYWN0 aWNlc0B0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1taWYtY3VycmVudC1wcmFjdGljZXNA dG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IE9iamV0Jm5ic3A7OiBbbWlmXSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taWYtY3VycmVudC1wcmFjdGljZXM8YnI+DQomZ3Q7 ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZndDsgJmd0OyBJIGhhdmUg cmV2aWV3ZWQgdGhpcyBkb2N1bWVudC4gT3ZlcmFsbCwgdGhpcyBpcyBhIGdvb2QNCmRvY3Vt ZW50LCBidXQ8YnI+DQomZ3Q7ICZndDsgc29tZSB3b3JrIHN0aWxsIHJlbWFpbnMuIE15IGJp Z2dlc3QgaXNzdWVzIHdlcmUgdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgVGhlIGRvY3VtZW50IGlzIHF1aXRlIGZvY3VzZWQgb24gdGhlIGFjY2VzcyBu ZXR3b3JrIHNlbGVjdGlvbg0KcHJvYmxlbSw8YnI+DQomZ3Q7ICZndDsgd2hpY2ggaGFzIGFs cmVhZHkgYmVlbiBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gUkZDIDUxMTMuIEl0IGlzIGZp bmUNCnRvPGJyPg0KJmd0OyAmZ3Q7IGluY2x1ZGUgZGlzY3Vzc2lvbiBvZiB0aGUgYWNjZXNz IG5ldHdvcmsgc2VsZWN0aW9uIHByb2JsZW0gYXMgd2VsbCw8YnI+DQomZ3Q7ICZndDsgYmVj YXVzZSBpdCBpcyBhbGwgcGFydCBvZiB0aGUgc2FtZSBwcm9ibGVtIHNwYWNlLiBCdXQgSSB3 b3VsZCBoYXZlPGJyPg0KJmd0OyAmZ3Q7IGV4cGVjdGVkIHRoZSBkb2N1bWVudCBkaXNjdXNz IGluIG1vcmUgZGV0YWlsIHdoYXQgdGhlIHZhcmlvdXM8YnI+DQomZ3Q7ICZndDsgaW1wbGVt ZW50YXRpb25zIGRvIGF0IGxheWVyIDMuIEZvciBpbnN0YW5jZSwgZG8gdGhleSB1c2UgUkZD IDM0ODQsDQphcmU8YnI+DQomZ3Q7ICZndDsgRE5TIHNldHRpbmdzIHBlci1ub2RlIG9yIHBl ci1pbnRlcmZhY2UsIGlmIGFuIGFwcGxpY2F0aW9uIGlzIGJvdW5kIHRvDQphbjxicj4NCiZn dDsgJmd0OyBpbnRlcmZhY2UgZG9lcyBpdCBhbHdheXMgdXNlIHRoZSBETlMgc2V0dGluZ3Mg Zm9yIGV4YWN0bHkgdGhhdA0KaW50ZXJmYWNlPGJyPg0KJmd0OyAmZ3Q7IG9yIHRoZSBwZXIt bm9kZSBzZXR0aW5ncywgd2hhdCBoYXBwZW5zIHdpdGggb3ZlcmxhcHBpbmcgYWRkcmVzcw0K c3BhY2UsPGJyPg0KJmd0OyBldGMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRo ZSBkb2N1bWVudCBpcyBzb21ld2hhdCBpbWJhbGFuY2VkLCB0aGVyZSdzIHZlcnkgbGl0dGxl ICh0b28gbGl0dGxlKTxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBhYm91dCBzb21lIGRl dmljZXMgYW5kIG9wZXJhdGluZyBzeXN0ZW1zIHdoZXJlYXMgdGhlDQpXaW5kb3dzPGJyPg0K Jmd0OyAmZ3Q7IGRlc2NyaXB0aW9uIGlzIGRldGFpbGVkIGFuZCBpbmZvcm1hdGl2ZS4gSSB3 b3VsZCBzdWdnZXN0IHRoYXQgc29tZSBvZjxicj4NCiZndDsgJmd0OyB0aGUgZGV2aWNlcyBm b3Igd2hpY2ggdGhlcmUgaXMgdmVyeSBsaXR0bGUgaW5mb3JtYXRpb24gYXJlIGVpdGhlcjxi cj4NCiZndDsgJmd0OyByZW1vdmVkIGZyb20gdGhlIGRvY3VtZW50IG9yIHNvbWUgbW9yZSBp bmZvcm1hdGlvbiBpcyBpbnNlcnRlZCBhYm91dDxicj4NCiZndDsgdGhlbS48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgRGV0YWlsZWQgY29tbWVudHM6PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFNlY3Rpb24gMy4xLjMgcy9pbiBhIE1JRiBjb250ZXh0L2hlcmUv ICh0aGUgTUlGIGNvbnRleHQgaXMgYSBmaW5lDQp0ZXJtPGJyPg0KJmd0OyAmZ3Q7IHRvIHVz ZSBpbiBXRyBkaXNjdXNzaW9uLCBidXQgd2lsbCBsb29rIG9kZCBpbiBhIHB1Ymxpc2hlZCBS RkMgYnkgdGhlPGJyPg0KJmd0OyAmZ3Q7IHRpbWUgdGhlIFdHIGhhcyBjb25jbHVkZWQpLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PiZndDsgTkVXIFRFWFQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gY29tcGFyaXNvbiB0byBX aW5kb3dzIE1vYmlsZSAyMDAzIFNFLCBXaW5kb3dzIHBob25lIDcgYnJpbmdzIHVwZGF0ZSBv Zjxicj4NCiZndDsgdGhlIHJvdXRpbmcgZnVuY3Rpb25hbGl0eSBpbiB0aGUgY2FzZSB3aGVy ZSB0aGUgdGVybWluYWwgY2FuIGJlIGF0dGFjaGVkPGJyPg0KJmd0OyBzaW11bHRhbmVvdXNs eSB0byBzZXZlcmFsIGludGVyZmFjZXMuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+Jmd0OyAmZ3Q7IE9uIFNlY3Rpb24gMy4xLjQgKEJsYWNrQmVycnkpIGl0 IHdhcyB1bmNsZWFyIHRvIG1lIHdoYXQgdHlwZQ0Kb2YgZ2F0ZXdheXM8YnI+DQomZ3Q7ICZn dDsgdGhlIHRleHQgcmVmZXJzIHRvLiBEZWZhdWx0IHJvdXRlciwgd2ViIHByb3h5LCBhcHBs aWNhdGlvbiBwcm94eSw8YnI+DQomZ3Q7ICZndDsgc29tZXRoaW5nIGVsc2U/PGJyPg0KJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jmd0OyBJIGFncmVlIHRoYXQgdGhl IG9yaWdpbmFsIHRleHQgd2FzIHVuY2xlYXIuIEkndmUgcmV2aXNlZCB0aGUNCnNlY3Rpb24g YnV0PGJyPg0KJmd0OyBHaXllb25nLCBwbGVhc2UgY2hlY2sgd2Uga2VwdCBpZGVhcyBmcm9t IHlvdXIgb3JpZ2luYWwgdGV4dC48YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mZ3Q7IE9uIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHRoZSBzYW1lIHNlY3Rp b24gaXQgaXM8YnI+DQomZ3Q7ICZndDsgdW5jbGVhciB3aGF0ICZxdW90O2RldmljZSZxdW90 OyByZWZlcnMgdG8uIFRoZSBlbnRpcmUgZGV2aWNlIGNhbiB1c2UNCm11bHRpcGxlPGJyPg0K Jmd0OyAmZ3Q7IG5ldHdvcmtzIHNpbXVsdGFuZW91c2x5PyBEb2VzIHRoYXQgbWVhbiB0aGF0 IG9uZSBhcHBsaWNhdGlvbiBjYW4gdXNlPGJyPg0KJmd0OyAmZ3Q7IG11bHRpcGxlIG5ldHdv cmtzIHNpbXVsdGFuZW91c2x5LCB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbnMgKGxpa2UgaW48 YnI+DQomZ3Q7ICZndDsgbXAtdGNwKSBvciB0byBkaWZmZXJlbnQgZGVzdGluYXRpb25zPyBP ciBqdXN0IHRoYXQgbXVsdGlwbGUNCmFwcGxpY2F0aW9uczxicj4NCiZndDsgJmd0OyBjYW4g dXNlIGRpZmZlcmVudCBuZXR3b3JrcyBzaW11bHRhbmVvdXNseT9gUGxlYXNlIGJlIG1vcmUg cHJlY2lzZQ0KYWJvdXQ8YnI+DQomZ3Q7ICZndDsgd2hhdCBpcyBhY3R1YWxseSBoYXBwZW5p bmcsIGFzIG9wcG9zZWQgdG8gY2xhaW1pbmcgYSBnZW5lcmFsDQpjYXBhYmlsaXR5Ljxicj4N CiZndDsgJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZn dDsgT2ssIHRleHQgaGFzIGJlZW4gcmV2aXNlZC48YnI+DQomZ3Q7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTIuMHB0Jz4mZ3Q7ICZndDsgU2VjdGlvbiAzLjEuNyBzYXlzIHZlcnkgbGl0 dGxlIGFib3V0IHRoZSBoYXJkIGlzc3VlcyBhcm91bmQNCk1JRiwgc3VjaCBhczxicj4NCiZn dDsgJmd0OyB3aGV0aGVyIG92ZXJsYXBwaW5nIGFkZHJlc3Mgc3BhY2UgaXMgdG9sZXJhdGVk LCB3aGV0aGVyIHRoZXJlIGlzIGE8YnI+DQomZ3Q7ICZndDsgcG9zc2liaWxpdHkgb2Ygc29t ZSBwb2xpY3kgYmVpbmcgc2VudCBmcm9tIHRoZSBuZXR3b3JrLCB3aGV0aGVyIEROUw0KaW5m bzxicj4NCiZndDsgJmd0OyBpcyBwZXIgbm9kZSBvciBwZXIgaW50ZXJmYWNlLCBldGMuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJ1dCBhbHNvIG90aGVyIHNlY3Rpb25zIHVu ZGVyIDMuMSBzZWVtIHRoaW4uIEkgcmVhbGl6ZSB0aGF0IGl0cyBoYXJkDQp0bzxicj4NCiZn dDsgJmd0OyBnZXQgaW5mb3JtYXRpb24sIGJ1dCBhdCBsZWFzdCBzb21lIG9mIHRoZXNlIGRl dmljZXMgYXJlIG9wZW4gc291cmNlDQphbmQ8YnI+DQomZ3Q7ICZndDsgcnVuIG9uIHRvcCBv ZiBzdGFuZGFyZCBrZXJuZWxzIHN1Y2ggYXMgTGludXgsIHNvIGl0IHNob3VsZCBiZQ0KcG9z c2libGU8YnI+DQomZ3Q7ICZndDsgdG8gZmluZCBvdXQgYSBiaXQgbW9yZS48YnI+DQomZ3Q7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mZ3Q7IEkgZ3Vlc3MgeW91IGFyZSBy ZWZlcmVuY2luZyB0byBhbmRyb2lkIHRlcm1pbmFsczsgSSB3YXMgYWxzbw0KdGhpbmtpbmcg dGhhdDxicj4NCiZndDsgdGhlIGJlaGF2aW91ciBvZiBhbiBhbmRyb2lkIGNvdWxkIGJlIGRl ZHVjZWQgZnJvbSBjdXJyZW50IExpbnV4PGJyPg0KJmd0OyBmdW5jdGlvbmFsaXRpZXMgYnV0 IGl0IHNlZW1zIHRoYXQgdGhlIHNpdHVhdGlvbiBpcyBtb3JlIGNvbXBsZXguIEl0J3MgdHJ1 ZTxicj4NCiZndDsgdGhhdCBBbmRyb2lkIGlzIGJhc2VkIG9uIGEgTGludXgga2VybmVsIGJ1 dCBzb21lIGZ1bmN0aW9ucyBhcmUgc29tZXRpbWVzPGJyPg0KJmd0OyBjdXN0b21pemVkIGJ5 IHZlbmRvcnMuIFNvIHdlIHNvbWV0aW1lcyBleHBlcmllbmNlIGRpZmZlcmVudCBiZWhhdmlv dXI8YnI+DQomZ3Q7IGJldHdlZW4gZGlmZmVyZW50IGFuZHJvaWQgdGVybWluYWxzLiBGb3Ig aW5zdGFuY2UsIHNvbWUgYW5kcm9pZCB0ZXJtaW5hbDxicj4NCiZndDsgY2Fubm90IHJ1biBJ UHY2IG9ubHksIHRoZXkgbmVlZCBnZXR0aW5nIGFuIElQdjQgYWRkcmVzcyBmaXJzdCwgYW5k IHRoZW4sPGJyPg0KJmd0OyBldmVuIHdpdGggSVB2NiBzdXBwb3J0IHNvbWUgYW5kcm9pZCBj YW5ub3QgbWFuYWdlIG11bHRpcGxlIElQdjYgcHJlZml4ZXM8YnI+DQomZ3Q7IG9uIGEgc2lu Z2xlIGludGVyZmFjZTsgc29tZSBvdGhlcnMgaW5oaWJpdCB0aGUgM0cvV0xBTiBtdWx0aWhv bWluZy4uLi48YnI+DQomZ3Q7IHdoaWxlIGFsbCB0aGVzZSBmdW5jdGlvbnMgYXJlIHdlbGwg c3VwcG9ydGVkIG9uIGEgTGludXggbGFwdG9wLiBOb3RlIHRoYXQ8YnI+DQomZ3Q7IGl0IGlz IG5vdCBqdXN0IGEgbWF0dGVyIG9mIGNvbmZpZ3VyYXRpb24gc2luY2UgYW5kIHRoZSBvbmx5 IHdheSB0bzxicj4NCiZndDsgb3ZlcmNvbWUgdGhlc2UgbGltaXRhdGlvbnMgaXMgdG8gY2hh bmdlIHRoZSBhbmRyb2lkIHBsYXRmb3JtLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkndmUgYWRk ZWQgaW4gdGhlIHRleHQgdGhhdCBiZWhhdmlvdXIgb2YgYW4gYW5kcm9pZCB0ZXJtaW5hbCBj YW4gZGVwZW5kczxicj4NCiZndDsgb24gdGhlIHZlbmRvcnMgaW1wbGVtZW50YXRpb24uPGJy Pg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jmd0OyBPciB3ZSBjYW4g YXNrIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uIGZyb20gdGhlPGJyPg0KJmd0OyAmZ3Q7IHBl b3BsZSB3aG8gZ2F2ZSB1cyB0aGUgb3JpZ2luYWwgZGF0YSwgSSBzdXBwb3NlIGF0IGxlYXN0 IHNvbWUgb2YgdGhlbTxicj4NCiZndDsgJmd0OyB3b3JrIGZvciB0aGUgbWFudWZhY3R1cmVy cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz4mZ3Q7IFllcCwgd2UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZyb20gdmVu ZG9ycy4uLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgaVBob25lPGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJcGhvbmU8YnI+DQomZ3Q7ICZndDsg SW5jb25zaXN0ZW50IGNhcGl0YWxpemF0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IEZpeGVkPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBw dCc+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2hhdGV2ZXIgaXMgdGhl IGhhbmRzZXQsIGZhbGxiYWNrDQpvbiBMMyBhdHRhY2htZW50IGZhaWx1cmUgaXM8YnI+DQom Z3Q7IG5vdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1cHBv cnRlZCBmb3IgbW90aW9ubGVzcyB0ZXJtaW5hbHMuDQombmJzcDtBY3R1YWxseSwgdGhlIGNv bm5lY3Rpb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtYW5h Z2VyIGFsd2F5cyBzZWxlY3RzIHRoZSBtb3N0IHBvd2VyZnVsDQpzaWduYWwgc3RyZW5ndGgg d2l0aG91dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNp ZGVyaW5nIElQIGNvbmZpZ3VyYXRpb24gcmVzdWx0cy4NCiZuYnNwO0luIG90aGVyIHdvcmRz LCBpZiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0ZXJt aW5hbCBpcyB1bmFibGUgdG8gc2V0IHVwIHRoZSBJUA0KY29ubmVjdGl2aXR5IG9uIG9uZSB3 aWZpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWNjZXNzLCB0 aGUgY29ubmVjdGlvbiBtYW5hZ2VyIHdpbGwgbm90IHRyeQ0KdG8gYXR0YWNoIHRvIGFuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWx0ZXJuYXRpdmUgcG9p bnQgb2YgYXR0YWNobWVudCAob3IgU1NJRCkNCmFzIGxvbmcgYXMgdGhlIHNpZ25hbDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN0cmVuZ3RoIG9mIHRoZSBm aXJzdCByYWRpbyBsaW5rIGlzIHRoZQ0KbW9zdCBwb3dlcmZ1bC48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgV2hhdCBpcyAmcXVvdDttb3Rpb25sZXNzIHRlcm1pbmFsJnF1b3Q7 PyBBbGwgZGV2aWNlcyB0aGF0IHlvdSBtZW50aW9uDQphcmUgbW9iaWxlLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZndDsgV2Ug bWVhbnQ6IGEgdGVybWluYWwgd2hpY2ggcmVtYWlucyB1bmRlciBjb3ZlcmFnZSBvZiB0aGUg c2FtZSBBUC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgdGVzdCBoYXMgYmVlbiByZXZpc2Vk Ljxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZndDsgJmd0OyBC ZXNpZGVzLCBJJ20gZmFpcmx5IGNlcnRhaW4gdGhhdCB0aGUgYWJvdmUgZG9lcyBub3QgYXBw bHkgdG8NCkFuZHJvaWQuPGJyPg0KJmd0OyAmZ3Q7IFRoZSBkZXZpY2UgdGhhdCBJIGhhdmUg ZG9lcyBzZWVtIHRvIHN3aXRjaCBhd2F5IGZyb20gYSBzdHJvbmctc2lnbmFsPGJyPg0KJmd0 OyAmZ3Q7IFNTSUQgdG8gYW5vdGhlciBTU0lELCBpZiBMMyBhdHRhY2htZW50IGZhaWxzLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PiZndDsgQWN0dWFsbHksIHdlIGNhbiBoYXZlIGRpZmZlcmVudCBiZWhhdmlvdXIgd2l0aCBk aWZmZXJlbnQgQW5kcm9pZA0KcGxhdGZvcm1zPGJyPg0KJmd0OyAoc2VlIGFib3ZlKS4gVGhl IHRleHQgaW4gdGhlIGRvYyBhcHBsaWVzIG9ubHkgdG8gdGhlICZxdW90O0hUQw0KbWFqaWMm cXVvdDsuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jmd0OyAm Z3Q7ICZndDsgaW4gdGhlIHNjb3BlIG9mIE1JRi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAuLi4gaW4gdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ Jmd0OyBPaywgZml4ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jmd0Ozxicj4N CiZndDsgJmd0OyBKYXJpPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 IG1pZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm1pZkBp ZXRmLm9yZyI+bWlmQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmPC9hPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWlm IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptaWZAaWV0Zi5vcmciPm1pZkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21pZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTIuMHB0Jz48YnI+DQo8YnIgY2xlYXI9YWxsPg0KPGJyPg0KLS0gPGJyPg0KU3RlZmFu byBNLiBGYWNjaW48YnI+DQo9PT09PT09PT09PT09PT09PT08YnI+DQpNYXkgdGhlIEZvcmNl IGJlIHdpdGggeW91PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo8YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsDQppbmZvcm1hdGlvbiwgcHJpdmlsZWdl ZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUNCnNvbGlj aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3Rp dHV0ZSBub24tcHVibGljDQppbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0 aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGlzIHBy b2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLA0KcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91cg0Kc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9u DQpieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPgpUaGlzIHRyYW5zbWlzc2lvbiAoaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVj dGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBv ZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg dHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXpl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_002_01CBC6EA.450F365F-- ------_=_NextPart_001_01CBC6EA.450F365F Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC6EA.450F365F Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z ------_=_NextPart_001_01CBC6EA.450F365F-- From pierrick.seite@orange-ftgroup.com Mon Feb 7 09:14:59 2011 Return-Path: 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 1F3513A6E22 for ; Mon, 7 Feb 2011 09:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, 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 iOgZsOb5BcHw for ; Mon, 7 Feb 2011 09:14:43 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id CE7B33A6920 for ; Mon, 7 Feb 2011 09:14:42 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51320FC4005; Mon, 7 Feb 2011 18:14:51 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 349B1FC4001; Mon, 7 Feb 2011 18:14:51 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 18:14:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBC6EA.847C006A"; type="multipart/alternative" Date: Mon, 7 Feb 2011 18:14:45 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D41E4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAD2@XCH02DFW.rim.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESAAALy+cAAAZC9vAAAKvcA= References: <843DA8228A1BA74CA31FB4E111A5C462017D41D8@ftrdmel0.rd.francetelecom.fr> <680854867F7FD04BB9B06EB8ACA8D5AC0465FAD2@XCH02DFW.rim.net> From: To: , , , X-OriginalArrivalTime: 07 Feb 2011 17:14:46.0255 (UTC) FILETIME=[84C82FF0:01CBC6EA] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 07 Feb 2011 17:14:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC6EA.847C006A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC6EA.847C006A" ------_=_NextPart_002_01CBC6EA.847C006A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for clarification. I'll submitted the updated version soon. Pierrick =20 ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com]=20 Envoy=E9 : lundi 7 f=E9vrier 2011 18:13 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Pierrick, I believe the statement as you phrased captures the concept very well. Thanks, Stefano Stefano M. Faccin=20 Standards Manager=20 Research In Motion=20 122 West John Carpenter Parkway=20 Irving, TX 75039=20 Internal: 820 63451=20 Desk: +1 972 910 3451=20 BlackBerry: +1 510 230 8422=20 sfaccin@rim.com=20 Time zone: PST (GMT -8) =20 From: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com]=20 Sent: Monday, February 07, 2011 11:07 AM To: Stefano Faccin; sfaccinstd@gmail.com ; = mif@ietf.org ; jari.arkko@piuha.net = Subject: RE: [mif] AD review of draft-ietf-mif-current-practices=20 =20 If I refer to the current text on RIM, I understand that Address = overlapping is supported because the OS can manage multiple IP stacks = associated to multiple interface. Right? =20 Pierrick=20 =20 ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com]=20 Envoy=E9 : lundi 7 f=E9vrier 2011 17:41 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net Objet : RE: [mif] AD review of draft-ietf-mif-current-practices =20 Pierrick, The BlackBerry uses per-interface DNS and applications use the DNS bound = to a specific interface. Address overlapping is supported and is managed = by OS mechanisms. I hope this suffices.=20 Cheers, =20 Stefano Faccin =20 Standards Manager Research In Motion Corporation=20 5000 Riverside Drive=20 Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA=20 Office: (972) 910 3451 =20 Internal: 820.63451 : (510) 230 8422 www.rim.com = ; www.blackberry.com = =20 =20 =20 =20 P Consider the environment before printing. =20 From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = pierrick.seite@orange-ftgroup.com Sent: Monday, February 07, 2011 12:40 AM To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net Subject: Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hi Stefano, =20 Thanks for your comments, I'll update the draft accordingly. BTW, do you = have information on the following points for RIM blackberry: =20 - How the RIM blackberry manage Address selection: e.g. is RFC 3484 = supported?=20 =20 - DNS resolution issue on RIM blackberry: is DNS configuration per-node = or per-interface? If an application is bound to an interface, does it = always use the DNS settings for exactly that interface or the per-node = settings.=20 =20 - address space overlapping: When the RIM blackberry is simultaneously = attached to several interfaces, is the OS manage address space = overlapping? If yes, how does it work? =20 BR, Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java = applications" to just "applications", since I believe we want to capture = the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet = Service or the Internet gateway of the wireless server provider to = manage connections". Can we modify this to "... can use either the = BlackBerry Internet Service or the Internet gateway of the wireless = server provider or direct Internet connectivity over WLAN to ..." for = correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. =20 The section also contain a statement that does not apply to all devices, = i.e. "When the IP stack fails to obtain an IP address, the handset, = excepted the iPhone, restarts WLAN attachment selecting the second SSID = in the list. " The BlackBerry, when it fails to obtain an IP address = after successful WLAN attachment, performs a new WLAN scan and, among = the networks available, it selects the next SSID in the preferred list, = which means that the approach is different from the one the original = sentence tries to capture.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, = wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. > > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. > > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_002_01CBC6EA.847C006A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for = clarification. I’ll submitted the updated version = soon.

Pierrick

 

De : = Stefano Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : lundi 7 = f=E9vrier 2011 18:13
=C0 : SEITE Pierrick = RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Pierrick, I believe the statement as you phrased captures the concept very = well.
Thanks,
Stefano

Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)
 

From: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com]
Sent: Monday, February = 07, 2011 11:07 AM
To: Stefano Faccin; sfaccinstd@gmail.com <sfaccinstd@gmail.com>; mif@ietf.org <mif@ietf.org>; jari.arkko@piuha.net <jari.arkko@piuha.net> =
Subject: RE: [mif] AD = review of draft-ietf-mif-current-practices
 

If I refer to = the current text on RIM, I understand that Address overlapping is supported because = the OS can manage multiple IP stacks = associated to multiple interface. Right?

 =

Pierrick =

 =

De : = Stefano Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : lundi 7 = f=E9vrier 2011 17:41
=C0 : SEITE Pierrick = RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
Objet : RE: [mif] AD = review of draft-ietf-mif-current-practices

 

Pierrick,

The = BlackBerry uses per-interface DNS and applications use the DNS bound to a specific = interface. Address overlapping is supported and is managed by OS mechanisms. I hope = this suffices.

Cheers,=

 <= /o:p>

Stefano = Faccin

 <= /o:p>

Standards = Manager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, = Texas 75039 USA
Office: (972) 910 3451 

Internal: = 820.63451

3DUntitled-1: (510) = 230 8422

www.rim.com; www.blackberry.com<= font size=3D2 color=3Dblack face=3DCalibri>

 

3D"cid:image004.png@01CB49EA.87D92140"

 <= /o:p>

P Consider the environment before = printing.

 <= /o:p>

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierrick.seite@orange-ftgroup.com
Sent: Monday, February = 07, 2011 12:40 AM
To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
Subject: Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hi = Stefano,

 =

Thanks for your = comments, I’ll update the draft accordingly. BTW, do you have information on = the following points for RIM blackberry:

 =

- How the RIM = blackberry manage Address selection: e.g. is RFC 3484 supported? =

 =

- DNS resolution = issue on RIM blackberry: is DNS configuration per-node or per-interface? If an application is bound to an interface, does it always use the DNS = settings for exactly that interface or the per-node settings. =

 =

- address space overlapping: When the RIM blackberry is simultaneously attached to = several interfaces, is the OS manage address space overlapping? If yes, how does = it work?

 

BR,

Pierrick

 =

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefano faccin
Envoy=E9 : vendredi = 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hello all,
I have reviewed version 06 of the draft and I have a few comments.

Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to just "applications", since I believe we = want to capture the most generic case of BlackBerry, independently of the = OS.

Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet Service or the = Internet gateway of the wireless server provider to manage connections". Can = we modify this to "... can use either the BlackBerry Internet Service = or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect statement "The RIM = Blackberry behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this statement with "The RIM Blackberry behaves differently: the user (e.g. the = enterprise owning the device) is allowed to define its preferred access. The = connection manager selects the first SSID of the preferred list of SSIDs configured = in the device and that is available based on the WLAN scan the device has performed", since it is not true that the BlackBerry always tries = first the last SSID it has managed to attach in the past. 

The section also contain a statement that does not apply to all devices, i.e. "When the IP stack fails to = obtain an IP address, the handset, excepted the iPhone, restarts WLAN = attachment selecting the second SSID in the list. " The BlackBerry, = when it fails to obtain an IP address after successful WLAN attachment, performs = a new WLAN scan and, among the networks available, it selects the next SSID in = the preferred list, which means that the approach is different from the one = the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-f= tgroup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mif-curr= ent-practices-06.txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd and = Linux sections have been updated with information regarding DNS configuration, RFC3484 support, RFC1122 status and address overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 12:01
> =C0 : mif@ietf.org; jari.arkko@piuha.net
> Objet : RE: [mif] AD review of = draft-ietf-mif-current-practices

>
> Hi Jari, all,
>
> We've submitted a new version of the = draft-ietf-mif-current-practices
> (More details inline). However, there is a pending issue: we still = need
> additional information, especially from manufacturers, to address = your
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who = have
> provided per-OS initial information, to address Jari's concerns. = Interface
> selection is, generally, well documented but we need more details = on
> following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows = implement
> RFC3484 (I've just noticed that only the windows section refers to RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well = documented.
> But others sections must be developed. Reflecting Jari's comment: = is DNS

> configuration per-node or per-interface? If an application = is bound to an

> interface, does it always use the DNS settings for exactly = that interface

> or the per-node settings.

>
> - address space overlapping: we do not have information on these = issues
> and we'd appreciate feedback from the WG (especially from = manufacturers
> involved in MIF). When the terminal is simultaneously attached to = several
> interfaces, is the OS manage address space overlapping? If yes, how = does
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to = windows and Linux
> section. If we do not have more information for apple mac os, we'll = remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding = vendors
> specific implementations) manages multiple interfaces issues in the = same
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-iet= f-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of = draft-ietf-mif-current-practices
> >

> > I have reviewed this document. Overall, this is a good document, but
> > some work still remains. My biggest issues were the = following:
> >
> > The document is quite focused on the access network selection problem,
> > which has already been discussed extensively in RFC 5113. It = is fine to
> > include discussion of the access network selection problem as = well,
> > because it is all part of the same problem space. But I would = have
> > expected the document discuss in more detail what the = various
> > implementations do at layer 3. For instance, do they use RFC = 3484, are
> > DNS settings per-node or per-interface, if an application is = bound to an
> > interface does it always use the DNS settings for exactly that interface
> > or the per-node settings, what happens with overlapping = address space,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too = little)
> > information about some devices and operating systems whereas = the Windows
> > description is detailed and informative. I would suggest that = some of
> > the devices for which there is very little information are = either
> > removed from the document or some more information is inserted = about
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a = fine term
> > to use in WG discussion, but will look odd in a published RFC = by the
> > time the WG has concluded).
> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings = update of
> the routing functionality in the case where the terminal can be = attached
> simultaneously to several interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to me = what type of gateways
> > the text refers to. Default router, web proxy, application = proxy,
> > something else?
>

> I agree that the original text was unclear. I've revised = the section but
> Giyeong, please check we kept ideas from your original text.
>

> On the second paragraph of the same section it is
> > unclear what "device" refers to. The entire device = can use multiple
> > networks simultaneously? Does that mean that one application = can use
> > multiple networks simultaneously, to the same destinations = (like in
> > mp-tcp) or to different destinations? Or just that multiple applications
> > can use different networks simultaneously?`Please be more = precise about
> > what is actually happening, as opposed to claiming a general capability.
> >
>

> Ok, text has been revised.
>

> > Section 3.1.7 says very little about the hard issues = around MIF, such as
> > whether overlapping address space is tolerated, whether there = is a
> > possibility of some policy being sent from the network, = whether DNS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that = its hard to
> > get information, but at least some of these devices are open = source and
> > run on top of standard kernels such as Linux, so it should be possible
> > to find out a bit more.
>

> I guess you are referencing to android terminals; I was = also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. = It's true
> that Android is based on a Linux kernel but some functions are = sometimes
> customized by vendors. So we sometimes experience different = behaviour
> between different android terminals. For instance, some android = terminal
> cannot run IPv6 only, they need getting an IPv4 address first, and = then,
> even with IPv6 support some android cannot manage multiple IPv6 = prefixes
> on a single interface; some others inhibit the 3G/WLAN = multihoming....
> while all these functions are well supported on a Linux laptop. = Note that
> it is not just a matter of configuration since and the only way = to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can = depends
> on the vendors implementation.
>

> Or we can ask for further information from the
> > people who gave us the original data, I suppose at least some = of them
> > work for the manufacturers.
> >
>

> Yep, we need additional information from vendors....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>

> > >       Whatever is the handset, = fallback on L3 attachment failure is
> not
> > >       supported for motionless terminals.  Actually, the connection
> > >       manager always selects the most = powerful signal strength without
> > >       considering IP configuration = results.  In other words, if the
> > >       terminal is unable to set up the IP connectivity on one wifi
> > >       access, the connection manager will = not try to attach to an
> > >       alternative point of attachment (or = SSID) as long as the signal
> > >       strength of the first radio link is = the most powerful.
> >
> > What is "motionless terminal"? All devices that you = mention are mobile.
> >
>

> We meant: a terminal which remains under coverage of the = same AP.
>
> The test has been revised.
>

> > Besides, I'm fairly certain that the above does not = apply to Android.
> > The device that I have does seem to switch away from a = strong-signal
> > SSID to another SSID, if L3 attachment fails.
> >
>

> Actually, we can have different behaviour with different = Android platforms
> (see above). The text in the doc applies only to the "HTC majic".
>

> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>

> Ok, fixed

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




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

----------------------------------------------= -----------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

-----------------------------------------------------------------= ----
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_002_01CBC6EA.847C006A-- ------_=_NextPart_001_01CBC6EA.847C006A Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC6EA.847C006A Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z ------_=_NextPart_001_01CBC6EA.847C006A-- From Internet-Drafts@ietf.org Mon Feb 14 06:00:05 2011 Return-Path: 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 D45D93A6D2F; Mon, 14 Feb 2011 06:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 1REgFc+aPGwq; Mon, 14 Feb 2011 06:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFE83A6D48; Mon, 14 Feb 2011 06:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110214140001.5826.93318.idtracker@localhost> Date: Mon, 14 Feb 2011 06:00:01 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-current-practices-07.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: , X-List-Received-Date: Mon, 14 Feb 2011 14:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Current Practices for Multiple Interface Hosts Author(s) : M. Wasserman, P. Seite Filename : draft-ietf-mif-current-practices-07.txt Pages : 23 Date : 2011-02-14 An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-07.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-current-practices-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-14054529.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Mon Feb 14 06:26:04 2011 Return-Path: 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 D759B3A6D4A for ; Mon, 14 Feb 2011 06:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, 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 8aKTHqDhKUTK for ; Mon, 14 Feb 2011 06:25:45 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id D6C583A6CA2 for ; Mon, 14 Feb 2011 06:25:44 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E168FC4010; Mon, 14 Feb 2011 15:26:12 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 11A32FC400F; Mon, 14 Feb 2011 15:26:12 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 15:26:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBCC53.1D4CC9F6"; type="multipart/alternative" Date: Mon, 14 Feb 2011 15:26:05 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620180DCE3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D41E4@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESAAALy+cAAAZC9vAAAKvcABWWt1kA== References: <843DA8228A1BA74CA31FB4E111A5C462017D41D8@ftrdmel0.rd.francetelecom.fr><680854867F7FD04BB9B06EB8ACA8D5AC0465FAD2@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C462017D41E4@ftrdmel0.rd.francetelecom.fr> From: To: , , , , X-OriginalArrivalTime: 14 Feb 2011 14:26:07.0066 (UTC) FILETIME=[1E2ABBA0:01CBCC53] Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 14 Feb 2011 14:26:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCC53.1D4CC9F6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBCC53.1D4CC9F6" ------_=_NextPart_002_01CBCC53.1D4CC9F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 A new version of "current practices" is available : = http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-07.t= xt = =20 =20 =20 The Diff from previous version is on: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-current-practices-07 = =20 =20 modifications of releases -06 and -07 are summarized below: =20 -06: update Nokia S60, Andro=EFd and Linux sections with information = regarding DNS configuration, RFC3484 support and address overlapping = issue. Section "Apple" has been removed. -07: address Stefano's comments and updates RIM section regarding DNS = configuration, RFC3484 support and address overlapping issue. This = version also adds considerations on RFC3484 support for Windows Mobile = and windows phone. =20 =20 Regards, Pierrick Seite =20 =20 =20 ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com]=20 Envoy=E9 : lundi 7 f=E9vrier 2011 18:13 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Pierrick, I believe the statement as you phrased captures the concept very well. Thanks, Stefano Stefano M. Faccin=20 Standards Manager=20 Research In Motion=20 122 West John Carpenter Parkway=20 Irving, TX 75039=20 Internal: 820 63451=20 Desk: +1 972 910 3451=20 BlackBerry: +1 510 230 8422=20 sfaccin@rim.com=20 Time zone: PST (GMT -8) =20 From: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com]=20 Sent: Monday, February 07, 2011 11:07 AM To: Stefano Faccin; sfaccinstd@gmail.com ; = mif@ietf.org ; jari.arkko@piuha.net = Subject: RE: [mif] AD review of draft-ietf-mif-current-practices=20 =20 If I refer to the current text on RIM, I understand that Address = overlapping is supported because the OS can manage multiple IP stacks = associated to multiple interface. Right? =20 Pierrick=20 =20 ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com]=20 Envoy=E9 : lundi 7 f=E9vrier 2011 17:41 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net Objet : RE: [mif] AD review of draft-ietf-mif-current-practices =20 Pierrick, The BlackBerry uses per-interface DNS and applications use the DNS bound = to a specific interface. Address overlapping is supported and is managed = by OS mechanisms. I hope this suffices.=20 Cheers, =20 Stefano Faccin =20 Standards Manager Research In Motion Corporation=20 5000 Riverside Drive=20 Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA=20 Office: (972) 910 3451 =20 Internal: 820.63451 : (510) 230 8422 www.rim.com = ; www.blackberry.com = =20 =20 =20 =20 P Consider the environment before printing. =20 From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = pierrick.seite@orange-ftgroup.com Sent: Monday, February 07, 2011 12:40 AM To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net Subject: Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hi Stefano, =20 Thanks for your comments, I'll update the draft accordingly. BTW, do you = have information on the following points for RIM blackberry: =20 - How the RIM blackberry manage Address selection: e.g. is RFC 3484 = supported?=20 =20 - DNS resolution issue on RIM blackberry: is DNS configuration per-node = or per-interface? If an application is bound to an interface, does it = always use the DNS settings for exactly that interface or the per-node = settings.=20 =20 - address space overlapping: When the RIM blackberry is simultaneously = attached to several interfaces, is the OS manage address space = overlapping? If yes, how does it work? =20 BR, Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 : mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of draft-ietf-mif-current-practices =20 Hello all, I have reviewed version 06 of the draft and I have a few comments. Under section 3.1.3 on the BlackBerry, I would modify "Java = applications" to just "applications", since I believe we want to capture = the most generic case of BlackBerry, independently of the OS. Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet = Service or the Internet gateway of the wireless server provider to = manage connections". Can we modify this to "... can use either the = BlackBerry Internet Service or the Internet gateway of the wireless = server provider or direct Internet connectivity over WLAN to ..." for = correctness/completeness? In section 3.1.7 there is an incorrect statement "The RIM Blackberry = behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this = statement with "The RIM Blackberry behaves differently: the user (e.g. = the enterprise owning the device) is allowed to define its preferred = access. The connection manager selects the first SSID of the preferred = list of SSIDs configured in the device and that is available based on = the WLAN scan the device has performed", since it is not true that the = BlackBerry always tries first the last SSID it has managed to attach in = the past. =20 The section also contain a statement that does not apply to all devices, = i.e. "When the IP stack fails to obtain an IP address, the handset, = excepted the iPhone, restarts WLAN attachment selecting the second SSID = in the list. " The BlackBerry, when it fails to obtain an IP address = after successful WLAN attachment, performs a new WLAN scan and, among = the networks available, it selects the next SSID in the preferred list, = which means that the approach is different from the one the original = sentence tries to capture.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 6:41 AM, = wrote: Hello Jari, I've submitted a new version of draft-ietf-mif-current-practices = (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-06.= txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd = and Linux sections have been updated with information regarding DNS = configuration, RFC3484 support, RFC1122 status and address overlapping = issue. Section "Apple" has been removed. BR, Pierrick > -----Message d'origine----- > De : SEITE Pierrick RD-RESA-REN > Envoy=E9 : samedi 23 octobre 2010 12:01 > =C0 : mif@ietf.org; jari.arkko@piuha.net > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices > > Hi Jari, all, > > We've submitted a new version of the draft-ietf-mif-current-practices > (More details inline). However, there is a pending issue: we still = need > additional information, especially from manufacturers, to address your > concern with section 3.1. > > So, we request the support from the WG, especially from folks who have > provided per-OS initial information, to address Jari's concerns. = Interface > selection is, generally, well documented but we need more details on > following topics: > > - Address selection: is RFC 3484 supported? Linux and windows = implement > RFC3484 (I've just noticed that only the windows section refers to = RFC3484, > I'll align the linux section in the next version), but what about the > others (nokia, blackberry, windows mobile, android)? > > - DNS resolution issues: Windows and Linux section are well = documented. > But others sections must be developed. Reflecting Jari's comment: is = DNS > configuration per-node or per-interface? If an application is bound to = an > interface, does it always use the DNS settings for exactly that = interface > or the per-node settings. > > - address space overlapping: we do not have information on these = issues > and we'd appreciate feedback from the WG (especially from = manufacturers > involved in MIF). When the terminal is simultaneously attached to = several > interfaces, is the OS manage address space overlapping? If yes, how = does > it work? > > > - The section "Apple Mac OS X" is poor in comparison to windows and = Linux > section. If we do not have more information for apple mac os, we'll = remove > the section. > > - Android: can we consider that basic android kernel (excluding = vendors > specific implementations) manages multiple interfaces issues in the = same > way than the current Linux OS? > > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Jari > > Arkko > > Envoy=E9 : vendredi 1 octobre 2010 20:45 > > =C0 : mif; draft-ietf-mif-current-practices@tools.ietf.org > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > I have reviewed this document. Overall, this is a good document, but > > some work still remains. My biggest issues were the following: > > > > The document is quite focused on the access network selection = problem, > > which has already been discussed extensively in RFC 5113. It is fine = to > > include discussion of the access network selection problem as well, > > because it is all part of the same problem space. But I would have > > expected the document discuss in more detail what the various > > implementations do at layer 3. For instance, do they use RFC 3484, = are > > DNS settings per-node or per-interface, if an application is bound = to an > > interface does it always use the DNS settings for exactly that = interface > > or the per-node settings, what happens with overlapping address = space, > etc. > > > > The document is somewhat imbalanced, there's very little (too = little) > > information about some devices and operating systems whereas the = Windows > > description is detailed and informative. I would suggest that some = of > > the devices for which there is very little information are either > > removed from the document or some more information is inserted about > them. > > > > Detailed comments: > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine = term > > to use in WG discussion, but will look odd in a published RFC by the > > time the WG has concluded). > > > > NEW TEXT: > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings update = of > the routing functionality in the case where the terminal can be = attached > simultaneously to several interfaces. > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of = gateways > > the text refers to. Default router, web proxy, application proxy, > > something else? > > I agree that the original text was unclear. I've revised the section = but > Giyeong, please check we kept ideas from your original text. > > On the second paragraph of the same section it is > > unclear what "device" refers to. The entire device can use multiple > > networks simultaneously? Does that mean that one application can use > > multiple networks simultaneously, to the same destinations (like in > > mp-tcp) or to different destinations? Or just that multiple = applications > > can use different networks simultaneously?`Please be more precise = about > > what is actually happening, as opposed to claiming a general = capability. > > > > Ok, text has been revised. > > > Section 3.1.7 says very little about the hard issues around MIF, = such as > > whether overlapping address space is tolerated, whether there is a > > possibility of some policy being sent from the network, whether DNS = info > > is per node or per interface, etc. > > > > But also other sections under 3.1 seem thin. I realize that its hard = to > > get information, but at least some of these devices are open source = and > > run on top of standard kernels such as Linux, so it should be = possible > > to find out a bit more. > > I guess you are referencing to android terminals; I was also thinking = that > the behaviour of an android could be deduced from current Linux > functionalities but it seems that the situation is more complex. It's = true > that Android is based on a Linux kernel but some functions are = sometimes > customized by vendors. So we sometimes experience different behaviour > between different android terminals. For instance, some android = terminal > cannot run IPv6 only, they need getting an IPv4 address first, and = then, > even with IPv6 support some android cannot manage multiple IPv6 = prefixes > on a single interface; some others inhibit the 3G/WLAN multihoming.... > while all these functions are well supported on a Linux laptop. Note = that > it is not just a matter of configuration since and the only way to > overcome these limitations is to change the android platform. > > I've added in the text that behaviour of an android terminal can = depends > on the vendors implementation. > > Or we can ask for further information from the > > people who gave us the original data, I suppose at least some of = them > > work for the manufacturers. > > > > Yep, we need additional information from vendors.... > > > > iPhone > > > > > > Iphone > > Inconsistent capitalization. > > > > Fixed > > > > Whatever is the handset, fallback on L3 attachment failure = is > not > > > supported for motionless terminals. Actually, the = connection > > > manager always selects the most powerful signal strength = without > > > considering IP configuration results. In other words, if = the > > > terminal is unable to set up the IP connectivity on one wifi > > > access, the connection manager will not try to attach to an > > > alternative point of attachment (or SSID) as long as the = signal > > > strength of the first radio link is the most powerful. > > > > What is "motionless terminal"? All devices that you mention are = mobile. > > > > We meant: a terminal which remains under coverage of the same AP. > > The test has been revised. > > > Besides, I'm fairly certain that the above does not apply to = Android. > > The device that I have does seem to switch away from a strong-signal > > SSID to another SSID, if L3 attachment fails. > > > > Actually, we can have different behaviour with different Android = platforms > (see above). The text in the doc applies only to the "HTC majic". > > > > in the scope of MIF. > > > > > > > ... in the scope of this document. > > > > Ok, fixed > > > 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 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_002_01CBCC53.1D4CC9F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

A new = version of “current practices” is available : http://www.ietf.org/internet-drafts/draft-ietf-mif-current-p= ractices-07.txt

 

 

The = Diff from previous version is on: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-current-= practices-07

 

modifications of releases -06 and -07 are summarized = below:

 

-06: update Nokia S60, =A0Andro=EFd and Linux sections with information regarding DNS = configuration, RFC3484 support and address overlapping issue. Section "Apple" = has been removed.

-07: = address Stefano’s comments and updates RIM section regarding DNS configuration, RFC3484 support and address = overlapping issue. =A0This version also adds considerations on RFC3484 support for Windows Mobile and windows = phone.

 

 =

Regards,

Pierrick = Seite

 =

 =

 

De : = Stefano Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : lundi 7 = f=E9vrier 2011 18:13
=C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Pierrick, I believe the statement as you phrased captures the concept very = well.
Thanks,
Stefano

Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)
 

From: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com]
Sent: Monday, February = 07, 2011 11:07 AM
To: Stefano Faccin; sfaccinstd@gmail.com <sfaccinstd@gmail.com>; mif@ietf.org <mif@ietf.org>; jari.arkko@piuha.net <jari.arkko@piuha.net> =
Subject: RE: [mif] AD = review of draft-ietf-mif-current-practices
 

If I refer to = the current text on RIM, I understand that Address overlapping is supported because = the OS can manage multiple IP stacks = associated to multiple interface. Right?

 =

Pierrick =

 =

De : = Stefano Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : lundi 7 = f=E9vrier 2011 17:41
=C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com; mif@ietf.org; = jari.arkko@piuha.net
Objet : RE: [mif] AD = review of draft-ietf-mif-current-practices

 

Pierrick,

The = BlackBerry uses per-interface DNS and applications use the DNS bound to a specific = interface. Address overlapping is supported and is managed by OS mechanisms. I hope = this suffices.

Cheers,=

 <= /o:p>

Stefano = Faccin

 <= /o:p>

Standards = Manager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, = Texas 75039 USA
Office: (972) 910 3451 

Internal: = 820.63451

3DUntitled-1: (510) = 230 8422

www.rim.com; www.blackberry.com<= font size=3D2 color=3Dblack face=3DCalibri>

 

3D"cid:image004.png@01CB49EA.87D92140"

 <= /o:p>

P Consider the environment before = printing.

 <= /o:p>

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierrick.seite@orange-ftgroup.com
Sent: Monday, February = 07, 2011 12:40 AM
To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net
Subject: Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hi = Stefano,

 =

Thanks for your = comments, I’ll update the draft accordingly. BTW, do you have information on = the following points for RIM blackberry:

 =

- How the RIM = blackberry manage Address selection: e.g. is RFC 3484 supported? =

 =

- DNS resolution = issue on RIM blackberry: is DNS configuration per-node or per-interface? If an application is bound to an interface, does it always use the DNS = settings for exactly that interface or the per-node settings. =

 =

- address space overlapping: When the RIM blackberry is simultaneously attached to = several interfaces, is the OS manage address space overlapping? If yes, how does = it work?

 

BR,

Pierrick

 =

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de stefano faccin
Envoy=E9 : vendredi = 4 f=E9vrier 2011 20:31
=C0 : mif@ietf.org; jari.arkko@piuha.net
Objet : Re: [mif] AD = review of draft-ietf-mif-current-practices

 

Hello all,
I have reviewed version 06 of the draft and I have a few comments.

Under section 3.1.3 on the BlackBerry, I would modify "Java applications" to just "applications", since I believe we = want to capture the most generic case of BlackBerry, independently of the = OS.

Under section 3.1.3 on the BlackBerry, it says "An application = connecting to the Internet, can use either the BlackBerry Internet Service or the = Internet gateway of the wireless server provider to manage connections". Can = we modify this to "... can use either the BlackBerry Internet Service = or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to ..." for correctness/completeness?

In section 3.1.7 there is an incorrect statement "The RIM = Blackberry behaves differently, the connection manager selects the first SSID on = which it has managed to attach in the past." Please replace this statement = with "The RIM Blackberry behaves differently: the user (e.g. the = enterprise owning the device) is allowed to define its preferred access. The = connection manager selects the first SSID of the preferred list of SSIDs configured = in the device and that is available based on the WLAN scan the device has = performed", since it is not true that the BlackBerry always tries first the last = SSID it has managed to attach in the past. 

The section also contain a statement that does not apply to all devices, i.e. "When the IP stack fails to = obtain an IP address, the handset, excepted the iPhone, restarts WLAN = attachment selecting the second SSID in the list. " The BlackBerry, = when it fails to obtain an IP address after successful WLAN attachment, performs = a new WLAN scan and, among the networks available, it selects the next SSID in the preferred list, which means that the approach is different from the one = the original sentence tries to capture.

Cheers,

Stefano

On Tue, Feb 1, 2011 at 6:41 AM, <pierrick.seite@orange-f= tgroup.com> wrote:

Hello Jari,

I've submitted a new version of draft-ietf-mif-current-practices (http://www.ietf.org/internet-drafts/draft-ietf-mif-curr= ent-practices-06.txt). According to your comments, Nokia (thanks again Teemu), Andro=EFd and = Linux sections have been updated with information regarding DNS configuration, RFC3484 support, RFC1122 status and address overlapping issue. Section "Apple" has been removed.

BR,
Pierrick

> -----Message d'origine-----
> De : SEITE Pierrick RD-RESA-REN
> Envoy=E9 : samedi 23 octobre 2010 12:01
> =C0 : mif@ietf.org; jari.arkko@piuha.net
> Objet : RE: [mif] AD review of = draft-ietf-mif-current-practices

>
> Hi Jari, all,
>
> We've submitted a new version of the = draft-ietf-mif-current-practices
> (More details inline). However, there is a pending issue: we still = need
> additional information, especially from manufacturers, to address = your
> concern with section 3.1.
>
> So, we request the support from the WG, especially from folks who = have
> provided per-OS initial information, to address Jari's concerns. = Interface
> selection is, generally, well documented but we need more details = on
> following topics:
>
> - Address selection: is RFC 3484 supported? Linux and windows = implement
> RFC3484 (I've just noticed that only the windows section refers to RFC3484,
> I'll align the linux section in the next version), but what about = the
> others (nokia, blackberry, windows mobile, android)?
>
> - DNS resolution issues: Windows and Linux section are well = documented.
> But others sections must be developed. Reflecting Jari's comment: = is DNS

> configuration per-node or per-interface? If an application = is bound to an

> interface, does it always use the DNS settings for exactly = that interface

> or the per-node settings.

>
> - address space overlapping: we do not have information on these = issues
> and we'd appreciate feedback from the WG (especially from = manufacturers
> involved in MIF). When the terminal is simultaneously attached to = several
> interfaces, is the OS manage address space overlapping? If yes, how = does
> it work?
>
>
> - The section "Apple Mac OS X" is poor in comparison to = windows and Linux
> section. If we do not have more information for apple mac os, we'll = remove
> the section.
>
> - Android: can we consider that basic android kernel (excluding = vendors
> specific implementations) manages multiple interfaces issues in the = same
> way than the current Linux OS?
>
>
> Regards,
> Pierrick
>
> > -----Message d'origine-----
> > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> Jari
> > Arkko
> > Envoy=E9 : vendredi 1 octobre 2010 20:45
> > =C0 : mif; draft-iet= f-mif-current-practices@tools.ietf.org
> > Objet : [mif] AD review of = draft-ietf-mif-current-practices
> >

> > I have reviewed this document. Overall, this is a good document, but
> > some work still remains. My biggest issues were the = following:
> >
> > The document is quite focused on the access network selection problem,
> > which has already been discussed extensively in RFC 5113. It = is fine to
> > include discussion of the access network selection problem as = well,
> > because it is all part of the same problem space. But I would = have
> > expected the document discuss in more detail what the = various
> > implementations do at layer 3. For instance, do they use RFC = 3484, are
> > DNS settings per-node or per-interface, if an application is = bound to an
> > interface does it always use the DNS settings for exactly that interface
> > or the per-node settings, what happens with overlapping = address space,
> etc.
> >
> > The document is somewhat imbalanced, there's very little (too = little)
> > information about some devices and operating systems whereas = the Windows
> > description is detailed and informative. I would suggest that = some of
> > the devices for which there is very little information are = either
> > removed from the document or some more information is inserted = about
> them.
> >
> > Detailed comments:
> >
> > Section 3.1.3 s/in a MIF context/here/ (the MIF context is a = fine term
> > to use in WG discussion, but will look odd in a published RFC = by the
> > time the WG has concluded).
> >
>

> NEW TEXT:
>
> In comparison to Windows Mobile 2003 SE, Windows phone 7 brings = update of
> the routing functionality in the case where the terminal can be = attached
> simultaneously to several interfaces.
>

> > On Section 3.1.4 (BlackBerry) it was unclear to me = what type of gateways
> > the text refers to. Default router, web proxy, application = proxy,
> > something else?
>

> I agree that the original text was unclear. I've revised = the section but
> Giyeong, please check we kept ideas from your original text.
>

> On the second paragraph of the same section it is
> > unclear what "device" refers to. The entire device = can use multiple
> > networks simultaneously? Does that mean that one application = can use
> > multiple networks simultaneously, to the same destinations = (like in
> > mp-tcp) or to different destinations? Or just that multiple applications
> > can use different networks simultaneously?`Please be more = precise about
> > what is actually happening, as opposed to claiming a general capability.
> >
>

> Ok, text has been revised.
>

> > Section 3.1.7 says very little about the hard issues = around MIF, such as
> > whether overlapping address space is tolerated, whether there = is a
> > possibility of some policy being sent from the network, = whether DNS info
> > is per node or per interface, etc.
> >
> > But also other sections under 3.1 seem thin. I realize that = its hard to
> > get information, but at least some of these devices are open = source and
> > run on top of standard kernels such as Linux, so it should be possible
> > to find out a bit more.
>

> I guess you are referencing to android terminals; I was = also thinking that
> the behaviour of an android could be deduced from current Linux
> functionalities but it seems that the situation is more complex. = It's true
> that Android is based on a Linux kernel but some functions are = sometimes
> customized by vendors. So we sometimes experience different = behaviour
> between different android terminals. For instance, some android = terminal
> cannot run IPv6 only, they need getting an IPv4 address first, and = then,
> even with IPv6 support some android cannot manage multiple IPv6 = prefixes
> on a single interface; some others inhibit the 3G/WLAN = multihoming....
> while all these functions are well supported on a Linux laptop. = Note that
> it is not just a matter of configuration since and the only way = to
> overcome these limitations is to change the android platform.
>
> I've added in the text that behaviour of an android terminal can = depends
> on the vendors implementation.
>

> Or we can ask for further information from the
> > people who gave us the original data, I suppose at least some = of them
> > work for the manufacturers.
> >
>

> Yep, we need additional information from vendors....
>
> > > iPhone
> > >
> > > Iphone
> > Inconsistent capitalization.
> >
>
> Fixed
>

> > >       Whatever is the handset, = fallback on L3 attachment failure is
> not
> > >       supported for motionless terminals.  Actually, the connection
> > >       manager always selects the most = powerful signal strength without
> > >       considering IP configuration = results.  In other words, if the
> > >       terminal is unable to set up the IP connectivity on one wifi
> > >       access, the connection manager will = not try to attach to an
> > >       alternative point of attachment (or = SSID) as long as the signal
> > >       strength of the first radio link is = the most powerful.
> >
> > What is "motionless terminal"? All devices that you = mention are mobile.
> >
>

> We meant: a terminal which remains under coverage of the = same AP.
>
> The test has been revised.
>

> > Besides, I'm fairly certain that the above does not = apply to Android.
> > The device that I have does seem to switch away from a = strong-signal
> > SSID to another SSID, if L3 attachment fails.
> >
>

> Actually, we can have different behaviour with different = Android platforms
> (see above). The text in the doc applies only to the "HTC majic".
>

> > > in the scope of MIF.
> > >
> >
> > ... in the scope of this document.
> >
>

> Ok, fixed

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




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

----------------------------------------------= -----------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

-----------------------------------------------------------------= ----
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_002_01CBCC53.1D4CC9F6-- ------_=_NextPart_001_01CBCC53.1D4CC9F6 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z ------_=_NextPart_001_01CBCC53.1D4CC9F6 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBCC53.1D4CC9F6-- From Internet-Drafts@ietf.org Mon Feb 28 06:45:02 2011 Return-Path: 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 8AF0D3A6BDF; Mon, 28 Feb 2011 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 O6Zer5yLaozr; Mon, 28 Feb 2011 06:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D123A6C05; Mon, 28 Feb 2011 06:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110228144501.25453.79339.idtracker@localhost> Date: Mon, 28 Feb 2011 06:45:01 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action:draft-ietf-mif-current-practices-08.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: , X-List-Received-Date: Mon, 28 Feb 2011 14:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Current Practices for Multiple Interface Hosts Author(s) : M. Wasserman, P. Seite Filename : draft-ietf-mif-current-practices-08.txt Pages : 23 Date : 2011-02-28 An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-08.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mif-current-practices-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28064458.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Mon Feb 28 06:47:47 2011 Return-Path: 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 D54453A6BF4 for ; Mon, 28 Feb 2011 06:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, 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 9d8nAutLV7Sf for ; Mon, 28 Feb 2011 06:47:45 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 098C53A69BF for ; Mon, 28 Feb 2011 06:47:45 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A0AEFC4004; Mon, 28 Feb 2011 15:48:50 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 19DB6FC4002; Mon, 28 Feb 2011 15:48:50 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 15:48:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 15:48:40 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620188765B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1cef01cbd3b5$2183acd0$648b0670$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] AD review of draft-ietf-mif-current-practices Thread-Index: AcvFJKKqGfKO6G1+SPerkebuG5b7LwBfSybAABD4ESAAALy+cAAAZC9vAAAKvcABWWt1kAHZGJxQAOduH7A= References: <843DA8228A1BA74CA31FB4E111A5C462017D41D8@ftrdmel0.rd.francetelecom.fr><680854867F7FD04BB9B06EB8ACA8D5AC0465FAD2@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C462017D41E4@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C4620180DCE3@ftrdmel0.rd.francetelecom.fr> <1cef01cbd3b5$2183acd0$648b0670$@com> From: To: X-OriginalArrivalTime: 28 Feb 2011 14:48:44.0574 (UTC) FILETIME=[991683E0:01CBD756] Cc: mif@ietf.org Subject: Re: [mif] AD review of draft-ietf-mif-current-practices 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: , X-List-Received-Date: Mon, 28 Feb 2011 14:47:47 -0000 Hi Dan, Thanks for the comments. The new version is now available: = http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices-08.t= xt=20 Pierrick > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com]=20 > Envoy=E9 : jeudi 24 f=E9vrier 2011 00:55 > =C0 : SEITE Pierrick RD-RESA-REN > Objet : RE: [mif] AD review of draft-ietf-mif-current-practices >=20 > Nit: >=20 > Could section 3 please name the company for each? It can=20 > help with searching. =20 >=20 > 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . .=20 > . . . . 7 > 3.1.2. Microsoft Windows Mobile and Windows Phone 7 .=20 > . . . . 9 > 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . .=20 > . . . . 10 >=20 > should be "RIM BlackBerry" or "Research in Motion BlackBerry" >=20 > 3.1.4. Google Android . . . . . . . . . . . . . . . .=20 > . . . . 11 > 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . .=20 > . . . . 12 > 3.1.6. Arena Connection Manager . . . . . . . . . . .=20 > . . . . 13 >=20 > maybe should be "Linux Arena Connection Manager" >=20 > 3.1.7. Current practices for network selection in=20 > handsets . 13 >=20 > 3.1.7 seems out of place. Was it supposed to be the next=20 > section, and there is a mis-placed "", perhaps? >=20 >=20 > There is long-standing confusion that the iPhone has IPv6 on=20 > the cellular interface because it has IPv6 on WiFi. Perhaps=20 > mention that, as a one paragraph thing, like: >=20 > 3.1.x Apple iPhone >=20 > Apple iPhone supports IPv6 on its WiFi interface, but not on > the cellular interface. Its interaction on WiFi has not been > analyzed and is out of scope of this paper. >=20 > ? >=20 >=20 > -d >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 > Behalf Of=20 > > pierrick.seite@orange-ftgroup.com > > Sent: Monday, February 14, 2011 6:26 AM > > To: pierrick.seite@orange-ftgroup.com; sfaccin@rim.com;=20 > > sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices > >=20 > > Hi, > >=20 > >=20 > >=20 > > A new version of "current practices" is available : > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices- > > 07.txt > practices-07.txt> > >=20 > >=20 > >=20 > >=20 > >=20 > > The Diff from previous version is on: > >=20 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-current-practices-07 > >=20 > = > 07> > >=20 > >=20 > >=20 > > modifications of releases -06 and -07 are summarized below: > >=20 > >=20 > >=20 > > -06: update Nokia S60, Andro=EFd and Linux sections with = information=20 > > regarding DNS configuration, RFC3484 support and address=20 > overlapping=20 > > issue. Section "Apple" has been removed. > >=20 > >=20 > >=20 > > -07: address Stefano's comments and updates RIM section=20 > regarding DNS=20 > > configuration, RFC3484 support and address overlapping issue. This=20 > > version also adds considerations on RFC3484 support for=20 > Windows Mobile=20 > > and windows phone. > >=20 > >=20 > >=20 > >=20 > >=20 > > Regards, > >=20 > > Pierrick Seite > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > De : Stefano Faccin [mailto:sfaccin@rim.com] Envoy=E9 : lundi=20 > 7 f=E9vrier=20 > > 2011 18:13 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com;=20 > > mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of=20 > > draft-ietf-mif-current-practices > >=20 > >=20 > >=20 > > Pierrick, > > I believe the statement as you phrased captures the concept=20 > very well. > > Thanks, > > Stefano > >=20 > > Stefano M. Faccin > >=20 > > Standards Manager > > Research In Motion > > 122 West John Carpenter Parkway > > Irving, TX 75039 > > Internal: 820 63451 > > Desk: +1 972 910 3451 > > BlackBerry: +1 510 230 8422 > > sfaccin@rim.com > > Time zone: PST (GMT -8) > >=20 > >=20 > > From: pierrick.seite@orange-ftgroup.com=20 > [mailto:pierrick.seite@orange-=20 > > ftgroup.com] > > Sent: Monday, February 07, 2011 11:07 AM > > To: Stefano Faccin; sfaccinstd@gmail.com ;=20 > > mif@ietf.org ; jari.arkko@piuha.net=20 > > > > Subject: RE: [mif] AD review of draft-ietf-mif-current-practices > >=20 > >=20 > > If I refer to the current text on RIM, I understand that Address=20 > > overlapping is supported because the OS can manage multiple=20 > IP stacks=20 > > associated to multiple interface. Right? > >=20 > >=20 > >=20 > > Pierrick > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > De : Stefano Faccin [mailto:sfaccin@rim.com] Envoy=E9 : lundi=20 > 7 f=E9vrier=20 > > 2011 17:41 =C0 : SEITE Pierrick RD-RESA-REN; sfaccinstd@gmail.com;=20 > > mif@ietf.org; jari.arkko@piuha.net Objet : RE: [mif] AD review of=20 > > draft-ietf-mif-current-practices > >=20 > >=20 > >=20 > > Pierrick, > >=20 > > The BlackBerry uses per-interface DNS and applications use the DNS=20 > > bound to a specific interface. Address overlapping is=20 > supported and is=20 > > managed by OS mechanisms. I hope this suffices. > >=20 > > Cheers, > >=20 > >=20 > >=20 > > Stefano Faccin > >=20 > >=20 > >=20 > > Standards Manager > >=20 > > Research In Motion Corporation > > 5000 Riverside Drive > > Building 6, Brazos East, Ste. 100 > >=20 > > Irving, Texas 75039 USA > > Office: (972) 910 3451 > >=20 > > Internal: 820.63451 > >=20 > > Untitled-1: (510) 230 8422 > >=20 > > www.rim.com >=20 > 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA3 > > 0=20 > >=20 > 259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/ > > w ww.rim.com> ; www.blackberry.com >=20 > 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA3 > > 0=20 > >=20 > 259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/ > > w > > ww.blackberry.com> > >=20 > >=20 > >=20 > > cid:image004.png@01CB49EA.87D92140 > >=20 > >=20 > >=20 > > P Consider the environment before printing. > >=20 > >=20 > >=20 > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 > Behalf Of=20 > > pierrick.seite@orange-ftgroup.com > > Sent: Monday, February 07, 2011 12:40 AM > > To: sfaccinstd@gmail.com; mif@ietf.org; jari.arkko@piuha.net > > Subject: Re: [mif] AD review of draft-ietf-mif-current-practices > >=20 > >=20 > >=20 > > Hi Stefano, > >=20 > >=20 > >=20 > > Thanks for your comments, I'll update the draft=20 > accordingly. BTW, do=20 > > you have information on the following points for RIM blackberry: > >=20 > >=20 > >=20 > > - How the RIM blackberry manage Address selection: e.g. is RFC 3484=20 > > supported? > >=20 > >=20 > >=20 > > - DNS resolution issue on RIM blackberry: is DNS configuration=20 > > per-node or per-interface? If an application is bound to an=20 > interface,=20 > > does it always use the DNS settings for exactly that=20 > interface or the=20 > > per-node settings. > >=20 > >=20 > >=20 > > - address space overlapping: When the RIM blackberry is=20 > simultaneously=20 > > attached to several interfaces, is the OS manage address space=20 > > overlapping? If yes, how does it work? > >=20 > >=20 > >=20 > > BR, > >=20 > > Pierrick > >=20 > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De=20 > la part de=20 > > stefano faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 20:31 =C0 :=20 > > mif@ietf.org; jari.arkko@piuha.net Objet : Re: [mif] AD review of=20 > > draft-ietf-mif-current-practices > >=20 > >=20 > >=20 > > Hello all, > > I have reviewed version 06 of the draft and I have a few comments. > >=20 > > Under section 3.1.3 on the BlackBerry, I would modify "Java=20 > > applications" to just "applications", since I believe we want to=20 > > capture the most generic case of BlackBerry, independently=20 > of the OS. > >=20 > > Under section 3.1.3 on the BlackBerry, it says "An application=20 > > connecting to the Internet, can use either the BlackBerry Internet=20 > > Service or the Internet gateway of the wireless server provider to=20 > > manage connections". Can we modify this to "... can use either the=20 > > BlackBerry Internet Service or the Internet gateway of the wireless=20 > > server provider or direct Internet connectivity over WLAN=20 > to ..." for=20 > > correctness/completeness? > >=20 > > In section 3.1.7 there is an incorrect statement "The RIM=20 > Blackberry=20 > > behaves differently, the connection manager selects the=20 > first SSID on=20 > > which it has managed to attach in the past." Please replace this=20 > > statement with "The RIM Blackberry behaves differently: the=20 > user (e.g. > > the enterprise owning the device) is allowed to define its=20 > preferred=20 > > access. The connection manager selects the first SSID of=20 > the preferred=20 > > list of SSIDs configured in the device and that is=20 > available based on=20 > > the WLAN scan the device has performed", since it is not=20 > true that the=20 > > BlackBerry always tries first the last SSID it has managed=20 > to attach=20 > > in the past. > >=20 > > The section also contain a statement that does not apply to all=20 > > devices, i.e. "When the IP stack fails to obtain an IP address, the=20 > > handset, excepted the iPhone, restarts WLAN attachment=20 > selecting the=20 > > second SSID in the list. " The BlackBerry, when it fails to=20 > obtain an=20 > > IP address after successful WLAN attachment, performs a new=20 > WLAN scan=20 > > and, among the networks available, it selects the next SSID in the=20 > > preferred list, which means that the approach is different from the=20 > > one the original sentence tries to capture. > >=20 > > Cheers, > >=20 > > Stefano > >=20 > > On Tue, Feb 1, 2011 at 6:41 AM, > > wrote: > >=20 > > Hello Jari, > >=20 > > I've submitted a new version of draft-ietf-mif-current-practices > >=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mif-current-practices- > > 06.txt). According to your comments, Nokia (thanks again Teemu),=20 > > Andro=EFd and Linux sections have been updated with information=20 > > regarding DNS configuration, RFC3484 support, RFC1122 status and=20 > > address overlapping issue. Section "Apple" has been removed. > >=20 > > BR, > > Pierrick > >=20 > > > -----Message d'origine----- > > > De : SEITE Pierrick RD-RESA-REN > > > Envoy=E9 : samedi 23 octobre 2010 12:01 =C0 : mif@ietf.org;=20 > > > jari.arkko@piuha.net Objet : RE: [mif] AD review of=20 > > > draft-ietf-mif-current-practices > >=20 > > > > > > Hi Jari, all, > > > > > > We've submitted a new version of the=20 > > > draft-ietf-mif-current-practices (More details inline). However,=20 > > > there is a pending issue: we still > > need > > > additional information, especially from manufacturers, to address > > your > > > concern with section 3.1. > > > > > > So, we request the support from the WG, especially from folks who > > have > > > provided per-OS initial information, to address Jari's concerns. > > Interface > > > selection is, generally, well documented but we need more=20 > details on=20 > > > following topics: > > > > > > - Address selection: is RFC 3484 supported? Linux and windows > > implement > > > RFC3484 (I've just noticed that only the windows section refers to > > RFC3484, > > > I'll align the linux section in the next version), but what about=20 > > > the others (nokia, blackberry, windows mobile, android)? > > > > > > - DNS resolution issues: Windows and Linux section are well > > documented. > > > But others sections must be developed. Reflecting Jari's=20 > comment: is > > DNS > >=20 > > > configuration per-node or per-interface? If an=20 > application is bound > > to an > >=20 > > > interface, does it always use the DNS settings for exactly that > > interface > >=20 > > > or the per-node settings. > >=20 > > > > > > - address space overlapping: we do not have information on these > > issues > > > and we'd appreciate feedback from the WG (especially from > > manufacturers > > > involved in MIF). When the terminal is simultaneously attached to > > several > > > interfaces, is the OS manage address space overlapping?=20 > If yes, how > > does > > > it work? > > > > > > > > > - The section "Apple Mac OS X" is poor in comparison to=20 > windows and > > Linux > > > section. If we do not have more information for apple mac=20 > os, we'll > > remove > > > the section. > > > > > > - Android: can we consider that basic android kernel (excluding > > vendors > > > specific implementations) manages multiple interfaces=20 > issues in the > > same > > > way than the current Linux OS? > > > > > > > > > Regards, > > > Pierrick > > > > > > > -----Message d'origine----- > > > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org]=20 > De la part > > de > > > Jari > > > > Arkko > > > > Envoy=E9 : vendredi 1 octobre 2010 20:45 =C0 : mif;=20 > > > > draft-ietf-mif-current-practices@tools.ietf.org > > > > Objet : [mif] AD review of draft-ietf-mif-current-practices > > > > > >=20 > > > > I have reviewed this document. Overall, this is a good document, > > but > > > > some work still remains. My biggest issues were the following: > > > > > > > > The document is quite focused on the access network selection > > problem, > > > > which has already been discussed extensively in RFC 5113. It is > > fine to > > > > include discussion of the access network selection problem as=20 > > > > well, because it is all part of the same problem space. But I=20 > > > > would have expected the document discuss in more detail=20 > what the=20 > > > > various implementations do at layer 3. For instance, do=20 > they use=20 > > > > RFC 3484, > > are > > > > DNS settings per-node or per-interface, if an=20 > application is bound > > to an > > > > interface does it always use the DNS settings for exactly that > > interface > > > > or the per-node settings, what happens with overlapping address > > space, > > > etc. > > > > > > > > The document is somewhat imbalanced, there's very little (too > > little) > > > > information about some devices and operating systems whereas the > > Windows > > > > description is detailed and informative. I would=20 > suggest that some > > of > > > > the devices for which there is very little information=20 > are either=20 > > > > removed from the document or some more information is inserted > > about > > > them. > > > > > > > > Detailed comments: > > > > > > > > Section 3.1.3 s/in a MIF context/here/ (the MIF context=20 > is a fine > > term > > > > to use in WG discussion, but will look odd in a published RFC by > > the > > > > time the WG has concluded). > > > > > > > > >=20 > > > NEW TEXT: > > > > > > In comparison to Windows Mobile 2003 SE, Windows phone 7 brings > > update of > > > the routing functionality in the case where the terminal can be > > attached > > > simultaneously to several interfaces. > > > > >=20 > > > > On Section 3.1.4 (BlackBerry) it was unclear to me what type of > > gateways > > > > the text refers to. Default router, web proxy,=20 > application proxy,=20 > > > > something else? > > > > >=20 > > > I agree that the original text was unclear. I've revised=20 > the section > > but > > > Giyeong, please check we kept ideas from your original text. > > > > >=20 > > > On the second paragraph of the same section it is > > > > unclear what "device" refers to. The entire device can use=20 > > > > multiple networks simultaneously? Does that mean that one=20 > > > > application can > > use > > > > multiple networks simultaneously, to the same=20 > destinations (like=20 > > > > in > > > > mp-tcp) or to different destinations? Or just that multiple > > applications > > > > can use different networks simultaneously?`Please be=20 > more precise > > about > > > > what is actually happening, as opposed to claiming a general > > capability. > > > > > > > > >=20 > > > Ok, text has been revised. > > > > >=20 > > > > Section 3.1.7 says very little about the hard issues around MIF, > > such as > > > > whether overlapping address space is tolerated, whether=20 > there is a=20 > > > > possibility of some policy being sent from the network, whether=20 > > > > DNS > > info > > > > is per node or per interface, etc. > > > > > > > > But also other sections under 3.1 seem thin. I realize that its > > hard to > > > > get information, but at least some of these devices are open=20 > > > > source > > and > > > > run on top of standard kernels such as Linux, so it should be > > possible > > > > to find out a bit more. > > > > >=20 > > > I guess you are referencing to android terminals; I was also=20 > > > thinking > > that > > > the behaviour of an android could be deduced from current Linux=20 > > > functionalities but it seems that the situation is more complex.=20 > > > It's > > true > > > that Android is based on a Linux kernel but some functions are > > sometimes > > > customized by vendors. So we sometimes experience different=20 > > > behaviour between different android terminals. For instance, some=20 > > > android > > terminal > > > cannot run IPv6 only, they need getting an IPv4 address first, and > > then, > > > even with IPv6 support some android cannot manage multiple IPv6 > > prefixes > > > on a single interface; some others inhibit the 3G/WLAN > > multihoming.... > > > while all these functions are well supported on a Linux=20 > laptop. Note > > that > > > it is not just a matter of configuration since and the=20 > only way to=20 > > > overcome these limitations is to change the android platform. > > > > > > I've added in the text that behaviour of an android terminal can > > depends > > > on the vendors implementation. > > > > >=20 > > > Or we can ask for further information from the > > > > people who gave us the original data, I suppose at least some of > > them > > > > work for the manufacturers. > > > > > > > > >=20 > > > Yep, we need additional information from vendors.... > > > > > > > > iPhone > > > > > > > > > > Iphone > > > > Inconsistent capitalization. > > > > > > > > > > Fixed > > > > >=20 > > > > > Whatever is the handset, fallback on L3=20 > attachment failure > > is > > > not > > > > > supported for motionless terminals. Actually, the > > connection > > > > > manager always selects the most powerful signal strength > > without > > > > > considering IP configuration results. In other=20 > words, if > > the > > > > > terminal is unable to set up the IP connectivity on one > > wifi > > > > > access, the connection manager will not try to=20 > attach to an > > > > > alternative point of attachment (or SSID) as long as the > > signal > > > > > strength of the first radio link is the most powerful. > > > > > > > > What is "motionless terminal"? All devices that you mention are > > mobile. > > > > > > > > >=20 > > > We meant: a terminal which remains under coverage of the same AP. > > > > > > The test has been revised. > > > > >=20 > > > > Besides, I'm fairly certain that the above does not apply to > > Android. > > > > The device that I have does seem to switch away from a strong- > > signal > > > > SSID to another SSID, if L3 attachment fails. > > > > > > > > >=20 > > > Actually, we can have different behaviour with different Android > > platforms > > > (see above). The text in the doc applies only to the "HTC majic". > > > > >=20 > > > > > in the scope of MIF. > > > > > > > > > > > > > ... in the scope of this document. > > > > > > > > >=20 > > > Ok, fixed > >=20 > > > > > > > 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 > >=20 > >=20 > >=20 > >=20 > > -- > > Stefano M. Faccin > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > May the Force be with you > >=20 > >=20 > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain=20 > confidential=20 > > information, privileged material (including material=20 > protected by the=20 > > solicitor-client or other applicable privileges), or=20 > constitute non-=20 > > public information. Any use of this information by anyone=20 > other than=20 > > the intended recipient is prohibited. If you have received this=20 > > transmission in error, please immediately reply to the sender and=20 > > delete this information from your system. Use, dissemination,=20 > > distribution, or reproduction of this transmission by unintended=20 > > recipients is not authorized and may be unlawful. > >=20 > >=20 > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain=20 > confidential=20 > > information, privileged material (including material=20 > protected by the=20 > > solicitor-client or other applicable privileges), or=20 > constitute non-=20 > > public information. Any use of this information by anyone=20 > other than=20 > > the intended recipient is prohibited. If you have received this=20 > > transmission in error, please immediately reply to the sender and=20 > > delete this information from your system. Use, dissemination,=20 > > distribution, or reproduction of this transmission by unintended=20 > > recipients is not authorized and may be unlawful. >=20 >=20 >=20