From nobody Tue May 3 05:14:51 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D4212D79E; Tue, 3 May 2016 05:14:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503121449.7538.49429.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 05:14:49 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-03.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:14:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : On Demand Mobility Management Authors : Alper Yegin Kisuk Kweon Jinsung Lee Jungshin Park Danny Moses Filename : draft-ietf-dmm-ondemand-mobility-03.txt Pages : 11 Date : 2016-05-03 Abstract: Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 3 05:19:31 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB712D7BA for ; Tue, 3 May 2016 05:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyUwR2RbBsbf for ; Tue, 3 May 2016 05:19:27 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC512D1D2 for ; Tue, 3 May 2016 05:19:27 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 03 May 2016 05:19:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208,217";a="957820007" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 03 May 2016 05:19:27 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:19:27 -0700 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:19:26 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by hasmsx108.ger.corp.intel.com ([169.254.9.32]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:19:24 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: A new version of the On-Demand draft Thread-Index: AdGlNgUYqArOvRWsQj23aLWZfuUFLA== Date: Tue, 3 May 2016 12:19:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmMwNzU5MDktMzI2OS00MDY2LWE0YjctNDc4MWI0MzgxMDdjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlpYZWk4OWVKbGNNNFRtd1Byakc0aDBPWnQ5K1NuXC9TMWpLdElGVVc1cXRjPSJ9 x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134A13FC3HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] A new version of the On-Demand draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:19:29 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FC3HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, We thank everyone that provided comments and suggestions for improving the = OnDemand draft. We have made some changes to the draft addressing some of t= he comments. The main changes were to improve the description of the three = different source IP address types and improving their names. We would like to address each of the comments (even those that did not lead= to changes in the draft). Since there were quite a few, we grouped them in= to several topics and will address each one in a different email to enable = a focus discussion (if any) on a per-topic basis. Alper and Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FC3HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
 
Hi all,
We thank everyone that provided comments= and suggestions for improving the OnDemand draft. We have made some change= s to the draft addressing some of the comments. The main changes were to im= prove the description of the three different source IP address types and improving their names.
We would like to address each of the com= ments (even those that did not lead to changes in the draft). Since there w= ere quite a few, we grouped them into several topics and will address each = one in a different email to enable a focus discussion (if any) on a per-topic basis.
Alper and Danny
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134A13FC3HASMSX106gercor_-- From nobody Tue May 3 05:27:46 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C980112D79F for ; Tue, 3 May 2016 05:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAvOWkfs1rgm for ; Tue, 3 May 2016 05:27:41 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA212D776 for ; Tue, 3 May 2016 05:27:41 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 03 May 2016 05:27:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208,217";a="967644074" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga002.jf.intel.com with ESMTP; 03 May 2016 05:27:25 -0700 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:27:03 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by fmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:27:03 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by LCSMSX154.ger.corp.intel.com ([169.254.7.187]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:27:00 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: OnDemand draft: 3 address types discussion Thread-Index: AdGlNxViVeTLSORKTxOVT+qsHcWdEQ== Date: Tue, 3 May 2016 12:27:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2U5ODliYmQtMDU0Mi00MmQyLTkwNDUtNjUwMmViN2U3YWE2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IllIN1pOc21YUHVuZmVuUFZkN3VmV0lRRHBSTzRPMWhxYVI2WjJMYzVUSXc9In0= x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134A13FD9HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:27:45 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FD9HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is in reply to comments we received from Behcet and Suresh regarding t= he three types of addresses define in the draft. Suresh commented that the = 'Fixed IP address' is not necessary and application only require to select = Sustained or Nomadic IP addresses and Behcet commented that the 'Sustained = IP address' is not needed and not well define due to the fact that the draf= t does not define how to identify the end of an IP session (will be discuss= ed in a separate email). We have gave more thought to these types and concluded that the definitions= in the spec were confusing. We are providing new text in the new version, = hoping they are more clear. We re-evaluated whether to stay with the definition of three IP address typ= es or move to a two IP address type scheme and eventually concluded that it= is better to stay with the three type alternative. We hope that the better= text in the new draft version will clarify and here are some additional in= puts: Nomadic IP address (or in its new name: Non-persistent IP address): Clearly this type is useful for all applications that do not require any IP= session continuity guarantee from the network and wish to avoid the overhe= ad introduced by the network as part of that guarantee (inefficient routes,= tunneling etc...). Sustained IP address (or in its new name: Session-lasting IP address): This is our accurate definition for the IP session continuity service that = some application require and is similar to what is provided today by defaul= t, by mobile operators via GTP or PMIP. Basically, current implementations = provide a guarantee for the source IP address to be valid throughout the t= ime the mobile host is connected to the mobile network. We concluded that mobile hosts do not really require such a guarantee. It i= s sufficient to require a guarantee of the IP address availability while th= ere is/are an IP session(s) using this IP address and hence the more accura= te definition. Furthermore, some WG members have shown cases in DMM where i= t is more efficient for applications to request a new Session-lasting IP ad= dress when launched rather than using an existing one that was allocated to= the mobile host in the past. This is due to possible movement of the mobil= e host to a LAN which is being served by a mobility anchor that is differen= t from the one that was used when the older Session-lasting IP address was = assigned to the mobile host. Fixed IP address (no renaming ...): We believe that this is where our original text was the most unclear leadin= g to the confusion on the mailing list and the comments from the flour. A F= ixed IP address is guaranteed by the network to Always be valid, even if th= e mobile host is not utilizing any IP sessions, or has been disconnected fr= om the network for some time. This is a special service that mobile network= operators provide for a premium charge, for servers, VPNs , secured conten= t and other applications. With this IP address type the network operator pr= ovide IP address reachability in addition to IP session continuity, and mob= ile hosts may register these addresses in DNS infrastructure for name resol= ution. Clearly, most mobile hosts do not require Fixed IP addresses and their owne= rs will not pay the premium cost for this service, but still, it is a servi= ce that mobile operators provide and this is enough proof for us to acknowl= edge its need. Please see some examples from AT&T - https://www.wireless.att.com/businesscenter/solutions/connectivity/= ip-addressing.jsp, Verizon - http://www.verizonwireless.com/businessportals/support/features/= data_services/static_ip.html and Sprint - https://www.sprint.com/business/solutions/sprint_enablers/sp= rint_datalink_and_static_ip/index.html#.VxC7xSN9480 providing this service (which is called: Static IP address) Regards, Alper and Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FD9HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
 
This is in reply to comments we received= from Behcet and Suresh regarding the three types of addresses define in th= e draft. Suresh commented that the ‘Fixed IP address’ is not ne= cessary and application only require to select Sustained or Nomadic IP addresses and Behcet commented that the ‘Sust= ained IP address’ is not needed and not well define due to the fact t= hat the draft does not define how to identify the end of an IP session (wil= l be discussed in a separate email).
We have gave more thought to these types= and concluded that the definitions in the spec were confusing. We are prov= iding new text in the new version, hoping they are more clear.
We re-evaluated whether to stay with the= definition of three IP address types or move to a two IP address type sche= me and eventually concluded that it is better to stay with the three type a= lternative. We hope that the better text in the new draft version will clarify and here are some additional inp= uts:
Nomadic IP address (or in its new name: = Non-persistent IP address):
Clearly this type is useful for all appl= ications that do not require any IP session continuity guarantee from the n= etwork and wish to avoid the overhead introduced by the network as part of = that guarantee (inefficient routes, tunneling etc…).
Sustained IP address (or in its new name= : Session-lasting IP address):
This is our accurate definition for the = IP session continuity service that some application require and is similar = to what is provided today by default, by mobile operators via GTP or PMIP. = Basically, current implementations provide  a guarantee for the source IP address to be valid throughout = the time the mobile host is connected to the mobile network.
We concluded that mobile hosts do not re= ally require such a guarantee. It is sufficient to require a guarantee of t= he IP address availability while there is/are an IP session(s) using this I= P address and hence the more accurate definition. Furthermore, some WG members have shown cases in DMM where it i= s more efficient for applications to request a new Session-lasting IP addre= ss when launched rather than using an existing one that was allocated to th= e mobile host in the past. This is due to possible movement of the mobile host to a LAN which is being serv= ed by a mobility anchor that is different from the one that was used when t= he older Session-lasting IP address was assigned to the mobile host.
Fixed IP address (no renaming …):<= /div>
We believe that this is where our origin= al text was the most unclear leading to the confusion on the mailing list a= nd the comments from the flour. A Fixed IP address is guaranteed by the net= work to Always be valid, even if the mobile host is not utilizing any IP sessions, or has been disconnected from= the network for some time. This is a special service that mobile network o= perators provide for a premium charge, for servers, VPNs , secured content = and other applications. With this IP address type the network operator provide IP address reachability in add= ition to IP session continuity, and mobile hosts may register these address= es in DNS infrastructure for name resolution.
Clearly, most mobile hosts do not requir= e Fixed IP addresses and their owners will not pay the premium cost for thi= s service, but still, it is a service that mobile operators provide and thi= s is enough proof for us to acknowledge its need. Please see some examples from
providing this service (which is called= : Static IP address)
Regards,
Alper and Danny
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134A13FD9HASMSX106gercor_-- From nobody Tue May 3 05:31:40 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AC812D78F for ; Tue, 3 May 2016 05:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YYNeX62P5BZ for ; Tue, 3 May 2016 05:31:37 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37D12D776 for ; Tue, 3 May 2016 05:31:36 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 03 May 2016 05:31:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208,217";a="797704967" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 03 May 2016 05:31:29 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:31:28 -0700 Received: from lcsmsx152.ger.corp.intel.com (10.186.165.231) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:31:27 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by LCSMSX152.ger.corp.intel.com ([169.254.4.224]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:31:25 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: How to detect the ending of an IP session Thread-Index: AdGlN7Sh21o+Sz4tS36QQH2vnsqGRA== Date: Tue, 3 May 2016 12:31:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjNiMDY3YTUtNzAyMy00ZjZiLWE4Y2QtYTE3M2YzYTNmYjk0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InZIcng0eUZyZmZcL21tRzlTYTFEOHRwdldsWG5UQkZRZEF5WGs5bmF4YlhrPSJ9 x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134A13FF1HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] How to detect the ending of an IP session X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:31:39 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FF1HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Behcet indicated that the draft does not define how the ending of an IP ses= sion is detected and stated that one cannot define a Sustained IP address t= ype without defining how to detect the ending of an IP session. Well, we do not think that a draft that extends the Socket interface should= define how to detect the starting or ending of an IP session. This could b= e done in a separate draft and we are willing to participate in writing one= if the group thinks it is important and part of the DMM charter. RFC 5014, which this draft is extending, defines the ability to select Home= -address or Care-of-address, but does not define how they are created or pr= ovided to the mobile host (and this is OK). We do not see why the definitio= n of IP session begin/end is different. But Behcet, we can provide some ideas for detecting IP session ending (if y= ou are planning to provide a draft): - The Mobile host may issue an IP release DHCP message after the Sock= et is closed. - The network can detect the FIN sequence for TCP session - Watchdog mechanisms may be applied to detect long periods without a= ny traffic on a specific 5-touple But moreover, this draft does not claim that Session-lasting IP addresses M= ust not continue to be valid after the session ends. Networks may continue = to guarantee there validity even after the session ends and new application= s may use them in new IP sessions. It states that by requesting a Session-l= asting IP address, the application informs that it will require a valid IP = address throughout the IP session. Please refer to the text in the draft th= at explicitly allows both cases. Regards, Alper and Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134A13FF1HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
 
Behcet indicated that the draft does not= define how the ending of an IP session is detected and stated that one can= not define a Sustained IP address type without defining how to detect the e= nding of an IP session.
Well, we do not think that a draft that = extends the Socket interface should define how to detect the starting or en= ding of an IP session. This could be done in a separate draft and we are wi= lling to participate in writing one if the group thinks it is important and part of the DMM charter.
RFC 5014, which this draft is extending,= defines the ability to select Home-address or Care-of-address, but does no= t define how they are created or provided to the mobile host (and this is O= K). We do not see why the definition of IP session begin/end is different.
But Behcet, we can provide some ideas fo= r detecting IP session ending (if you are planning to provide a draft):
  • The Mobile host may issue an IP release D= HCP message after the Socket is closed.
  • The network can detect the FIN sequence for TCP session
  • Watchdog mechanisms may be applied to detect long per= iods without any traffic on a specific 5-touple
But moreover, this draft does not claim = that Session-lasting IP addresses Must not continue to be valid after the s= ession ends. Networks may continue to guarantee there validity even after t= he session ends and new applications may use them in new IP sessions. It states that by requesting a Session-las= ting IP address, the application informs that it will require a valid IP ad= dress throughout the IP session. Please refer to the text in the draft that= explicitly allows both cases.
Regards,
Alper and Danny
 
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134A13FF1HASMSX106gercor_-- From nobody Tue May 3 05:34:19 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE312D776 for ; Tue, 3 May 2016 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmf4HYuiTo-Q for ; Tue, 3 May 2016 05:34:17 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4266B12D766 for ; Tue, 3 May 2016 05:34:17 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 03 May 2016 05:34:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208,217";a="797707193" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 03 May 2016 05:34:15 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:34:13 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:34:13 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by LCSMSX154.ger.corp.intel.com ([169.254.7.187]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:34:10 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: Reachable vs Resolvable Thread-Index: AdGlOBZ9t7XnN64tSIWfEWjXxNDZCA== Date: Tue, 3 May 2016 12:34:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjJkOWE1NzAtZjRlNi00M2M0LWJkNzItOTg4MTk0OWNmN2VmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InZtUUtDbVlkUkdTbERja1B3QW5Ha1pJcEs3UFwvd20zR0VvRGd2SGpDQlVNPSJ9 x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134A14017HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] Reachable vs Resolvable X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:34:19 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134A14017HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Charlie suggested to refer to Reachable IP addresses as Resolvable IP addre= sses. This is in the introduction section of the draft that defines IP sess= ion continuity and IP address reachability. This is also something we evaluated and decided not to change the text. We = believe that the term Resolution is used with regards to host names, not IP= addresses. Host names are either 'resolvable' or not. When a client needs = to reach a server, it uses DNS and perform name -resolution to obtain the s= erver's IP address. Therefore, we prefer to stay with the original definition. Regards, Alper and Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134A14017HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
 
Charlie suggested to refer to Reachable = IP addresses as Resolvable IP addresses. This is in the introduction sectio= n of the draft that defines IP session continuity and IP address reachabili= ty.
This is also something we evaluated and = decided not to change the text. We believe that the term Resolution is used= with regards to host names, not IP addresses. Host names are either 'resol= vable' or not. When a client needs to reach a server, it uses DNS and perform name –resolution to obtain= the server’s IP address.
Therefore, we prefer to stay with the or= iginal definition.
Regards,
Alper and Danny
 
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134A14017HASMSX106gercor_-- From nobody Tue May 3 05:40:09 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071FE12D7D0 for ; Tue, 3 May 2016 05:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNxZipWi6T2k for ; Tue, 3 May 2016 05:40:06 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8412D7CC for ; Tue, 3 May 2016 05:40:06 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 03 May 2016 05:39:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,572,1455004800"; d="scan'208";a="945145689" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 03 May 2016 05:39:39 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 3 May 2016 05:39:36 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by hasmsx107.ger.corp.intel.com ([169.254.6.216]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:39:33 +0300 From: "Moses, Danny" To: "'pierrick.seite@orange.com'" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAGoVAIAEdKFAgACboYCAM1UhgIABgxHggAMH1YCAA0Q/cIAAD+0AgAGOdYCACQUJgIAAhIqQgCoatqA= Date: Tue, 3 May 2016 12:39:33 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjllODg5ZWEtMTEyYi00ZjM4LWE1MDAtYmI3MDA4ZTdhNWE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjlHS054ZDVpSGZ3QmhqZ2JqZ08rOTRNTzF5MFlWeERhRWpya3ZSNkRyZjQ9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "'dmm@ietf.org'" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:40:08 -0000 Hi again, We added text to the draft indicating that the means of communicating requi= red address types between the host and the network is outside the scope of = the OnDemand draft. This is due to the fact that there is no RFC that we co= uld refer to. When we complete the new RFCs that handle this communication, we will add r= eference to the OnDemand draft (hopefully it will become and RFC) to indica= te how applications can specify the required type of the source IP address. Regards, Alper and Danny -----Original Message----- From: Moses, Danny = Sent: Wednesday, April 06, 2016 20:40 To: pierrick.seite@orange.com Cc: dmm@ietf.org; sarikaya@ieee.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 H Pierrick, Thanks for the support. Yes, we will look for a place to add the clarification that these API exten= sion rely on other protocol enhancements to communicate the address type re= quest to the network. We cannot currently provide reference to the specific= documents you gave in your examples because they are not RFCs (yet...). Danny -----Original Message----- From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] Sent: Wednesday, April 06, 2016 05:43 To: Moses, Danny; sarikaya@ieee.org Cc: dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dany, I support this I-D. I find the document very useful, and well written. We a= ll agree that mobility management must be activated on purpose, it likely = requires an enhanced source address selection framework where applications = can obtain IP address with specific properties. By allowing applications to= request prefix properties, this I-D is clearly a part of this framework. M= aybe the document could be better by stressing clearly that it should be us= ed together with solutions allowing the network to expose prefix properties= to the host, for example with draft-korhonen-dmm-prefix-properties and dra= ft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... Lik= e I said, it is a framework :-) BR, Pierrick > -----Message d'origine----- > De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Moses, Danny = > Envoy=E9=A0: jeudi 31 mars 2016 18:44 =C0=A0: sarikaya@ieee.org Cc=A0: > dmm@ietf.org Objet=A0: Re: [DMM] WGLC #1 for > draft-ietf-dmm-ondemand-mobility-01 > = > Hi, > Good, see my reply inline (surrounded by >>>>>>>>>>>>) . > = > Thanks again for investing the time to review the drafts, > /Danny > = > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Wednesday, March 30, 2016 12:12 > To: Moses, Danny > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > = > Hi Danny, > = > I am removing all previous conversation because it all got mixed up. > Let's start afresh. > = > = > I read you dhcp draft also. > = > There is confusion in several levels. Your API draft talks about = > different applications on a MN needing different types of mobility = > services. Your DHCPv6 draft seems to give a solution on how a host can = > get different types of addresses/prefixes from DHCPv6 server, so is it fo= r a host or an application? > Prefix or address is assigned for an interface, that is another well = > known concept which your draft seem to completely ignore, i.e. a host = > may have multiple interfaces. > DM>>>>>>>>>>>>>>>>>>>>>> > Yes, I understand were the confusion might arise. The only entity in = > the host (or - mobile device) which uses DHCP is the DHCP client that = > is part of the TCP/IP stack. There may be several triggers to cause = > the DHCP client to request a source IP address: > - When the mobile node initially attaches to a network. > - When the mobile node moves to a different location and needs to = > refresh its source IP address. > The On-Demand concept implies a new trigger: > - When an application is launched, opens an IP Socket and requires a = > special type of source IP address which was not already assigned to the m= obile node. > So, it is the responsibility of the TCP/IP stack in the mobile node to = > figure out when it is required to initiate a DHCP transaction to serve th= e application's needs. > = > Regarding multiple interface, you are correct once more. A mobile node = > may have multiple interfaces. When this occurs, the mobile node needs = > to send at least one DHCP request on each interface and the network = > assigns the source IP address to the interface from which the DHCP = > request had arrived. This is not new and the DHCP draft does not = > mention it because there are no changes or extensions required. > >>>>>>>>>>>>>>>>>>>>>>>>>DM > = > Another concept is (as I already mentioned) topological correctness. > If MN changes subnet, its previous prefix becomes topologically = > incorrect. Either it has to get a new prefix or there must be some system= support, e.g. host routes. > Of course another case is anchoring, like in 3GPP or in MIP. If you = > are anchored your prefix does not change. > = > So you seem to ignore all these and instead introduce three types of = > addresses among which the sustained IP address/prefix is the key to your = solution. > = > Sustained address/prefix has this magical property: > the IP address used at the beginning of the session remains usable = > despite the movement of the mobile host. > = > and then you say > = > access network anchoring, corresponding network anchoring, or some > other solution > can provide sustained address/prefixes. > what does corresponding network anchoring mean? > = > DM>>>>>>>>>>>>>>>>>> > Corresponding network is a concept from Alper Yegin's draft - = > https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It = > defines the concept of having the mobility anchor in the network of = > the mobile node's corresponding node, rather than in the access = > network. It is an interesting concept with its advantages (and disadvanta= ges...). > >>>>>>>>>>>>>>>>>>>DM > = > I have a feeling that what your drafts are saying that right now we = > don't know but we anticipate in the future some ways will be found to = > make sustained IP addresses. > Is this true? > DM>>>>>>>>>>>>>>>>>>>> > Well, we do know how the network can support sustained addresses. But = > I believe that in our DMM work, new alternatives for supporting Fixed = > and Sustained IP addresses will be defined. > >>>>>>>>>>>>>>>>>>>>>DM > = > BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained = > address/prefix but it does not say how it will be different than the fixe= d one? > DM>>>>>>>>>>>>>>>>>>>>>>> > That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in = > order to support the requests and replies. DHCP does not define how IP = > addresses are allocated. > >>>>>>>>>>>>>>>>>>>>>>>>DM > = > Suppose we want to develop an access network anchoring for sustained = > IP addresses. > What about the needs for signaling? I have a feeling that a host = > running very many applications, like in today's smart phones, and so = > many smart phones in the system that is going to involve huge amount = > of signaling to get/release sustained address/prefixes, right? > DM>>>>>>>>>>>>>>>>>>>>> > Yes, a mobile host may activate several applications concurrently, but = > this does not mean that each application requires its own unique = > source IP address. Let's assume that a large amount of application are = > launched, some require Fixed IP addresses, some require Sustained IP = > addresses and the rest settle for Nomadic IP addresses. In that case, = > only three source IP addresses are required by the mobile node: One Fixed= IP address, one Sustained and one Nomadic IP address. > So the signaling overhead is not that huge. > >>>>>>>>>>>>>>>>>>>>>>DM > = > = > My conclusion from all of the above is that, I think what you propose = > sounds like a flashy idea but it seems to me that the complications = > involved in any solution is intractable. > Unless you can show me otherwise. > DM>>>>>>>>>>>>>>>>>>>>> > I hope I managed to convince you that it is not that complicated. I = > really think (and there are other members who share this belief) that = > the tunneling overhead and un- optimized routes are much more costly = > than what we are suggesting in this new concept. > >>>>>>>>>>>>>>>>>>>>>>>DM > = > Regards, > = > Behcet > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > = > This e-mail and any attachments may contain confidential material for = > the sole use of the intended recipient(s). Any review or distribution = > by others is strictly prohibited. If you are not the intended = > recipient, please contact the sender and delete all copies. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Fri May 6 12:20:49 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9812D1EA for ; Fri, 6 May 2016 12:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N1VquMFUjng for ; Fri, 6 May 2016 12:20:45 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A3212D0E4 for ; Fri, 6 May 2016 12:20:44 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id u64so14324204lff.2 for ; Fri, 06 May 2016 12:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=YO9RYxYYrTh1/rOVXpnxz1Z6iIqY2hDeGPQ/G85UzE4=; b=t6j1vYbc2+1jqf/B9chpFj+BCdZxtUxnfDS97H2PSoEUH41jMld5hA6ucY/PIqAZVE GmRwPznilZJtmbXzIvL9NENV5LNNFtW95hzBwMmbcoyIFRZMelwVWTdtoKBpo2+4o5sP cowfCSyBgNV2i0CxJHadXWq6ncXMsEcBo938dCMmKR/1p12/+D/mWxFtGM2AifgsGcsF pNY6r/a/DzxIyG0UVeXMubl8YQYBNWGOEn1SY4lFlhysLXanDwKxeP+C8/Jk3pAu/DsQ fp61HL9+Vtb1HPDHXbbQnrxhwaPvg6J3s4VDpIMynjb33P11hfjv+aHgaJScmPR2y8nE ivIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=YO9RYxYYrTh1/rOVXpnxz1Z6iIqY2hDeGPQ/G85UzE4=; b=K+iRbtomUhYPo5ZdNCTiqKL2CEcPNGKZuCdZdEgDNgFPDm94Upp4m1XMcuqCcYv3IG Q/mtyVUdnk7/DqNIUxxvqTzVI6Ucp4sSPSyj92Ond0Y0hJths38B4oTFy+eNRw2Fpdgc 51JiK4YT6YFBsuzuGZAAoiafmQeBvynLcz/v1rwlP+NrYIWC06FeF5WkPX4uOj2Zf8s5 xrkptlu0TJeVQ9yRvA7MMpjFT/w1SWWOJQGl7kIfZldKpIGNZTQJc6dsN7YQnqJrP34f bApXQ685SQ9CcyWoDhujrqesr3dwtRjGkCaEA9o5F2me01P2A98gfBTiGB5QSGfdtrGu WOsg== X-Gm-Message-State: AOPr4FU/v3tXy2vjFquStahEFgZPthrwggnwQvxLVg8TCPyK96EQWwFEgMqTLp4BtGe/s0YmY8IYxz2MIjcDMQ== MIME-Version: 1.0 X-Received: by 10.25.17.212 with SMTP id 81mr10574262lfr.38.1462562442873; Fri, 06 May 2016 12:20:42 -0700 (PDT) Received: by 10.112.5.34 with HTTP; Fri, 6 May 2016 12:20:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2016 14:20:42 -0500 Message-ID: From: Behcet Sarikaya To: "Moses, Danny" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 19:20:48 -0000 Hi Danny, This is my reply to all your mails. I hope it clarifies the air. I read RFC 5014 and I think that on-demand mobility as I and it seems like as 3GPP understands is already there: IPV6_PREFER_SRC_HOME IPV6_PREFER_SRC_COA are all we need. So if UE wants mobility, it sets IPV6_PREFER_SRC_HOME and as a result gets the fixed IP address as you call it or it gets anchored mobility service. If UE does not want mobility, it sets IPV6_PREFER_SRC_COA then it gets the nomadic IP address. Note that in the case of mobility, UE may still get nomadic address and mobility, that is another issue. Therefore RFC 5014 is good enough, the authors, all good friends of this community have done a good job. Regards, Behcet On Tue, May 3, 2016 at 7:27 AM, Moses, Danny wrote: > > This is in reply to comments we received from Behcet and Suresh regarding > the three types of addresses define in the draft. Suresh commented that t= he > =E2=80=98Fixed IP address=E2=80=99 is not necessary and application only = require to select > Sustained or Nomadic IP addresses and Behcet commented that the =E2=80=98= Sustained > IP address=E2=80=99 is not needed and not well define due to the fact tha= t the draft > does not define how to identify the end of an IP session (will be discuss= ed > in a separate email). > We have gave more thought to these types and concluded that the definitio= ns > in the spec were confusing. We are providing new text in the new version, > hoping they are more clear. > We re-evaluated whether to stay with the definition of three IP address > types or move to a two IP address type scheme and eventually concluded th= at > it is better to stay with the three type alternative. We hope that the > better text in the new draft version will clarify and here are some > additional inputs: > Nomadic IP address (or in its new name: Non-persistent IP address): > Clearly this type is useful for all applications that do not require any = IP > session continuity guarantee from the network and wish to avoid the overh= ead > introduced by the network as part of that guarantee (inefficient routes, > tunneling etc=E2=80=A6). > Sustained IP address (or in its new name: Session-lasting IP address): > This is our accurate definition for the IP session continuity service tha= t > some application require and is similar to what is provided today by > default, by mobile operators via GTP or PMIP. Basically, current > implementations provide a guarantee for the source IP address to be vali= d > throughout the time the mobile host is connected to the mobile network. > We concluded that mobile hosts do not really require such a guarantee. It= is > sufficient to require a guarantee of the IP address availability while th= ere > is/are an IP session(s) using this IP address and hence the more accurate > definition. Furthermore, some WG members have shown cases in DMM where it= is > more efficient for applications to request a new Session-lasting IP addre= ss > when launched rather than using an existing one that was allocated to the > mobile host in the past. This is due to possible movement of the mobile h= ost > to a LAN which is being served by a mobility anchor that is different fro= m > the one that was used when the older Session-lasting IP address was assig= ned > to the mobile host. > Fixed IP address (no renaming =E2=80=A6): > We believe that this is where our original text was the most unclear lead= ing > to the confusion on the mailing list and the comments from the flour. A > Fixed IP address is guaranteed by the network to Always be valid, even if > the mobile host is not utilizing any IP sessions, or has been disconnecte= d > from the network for some time. This is a special service that mobile > network operators provide for a premium charge, for servers, VPNs , secur= ed > content and other applications. With this IP address type the network > operator provide IP address reachability in addition to IP session > continuity, and mobile hosts may register these addresses in DNS > infrastructure for name resolution. > Clearly, most mobile hosts do not require Fixed IP addresses and their > owners will not pay the premium cost for this service, but still, it is a > service that mobile operators provide and this is enough proof for us to > acknowledge its need. Please see some examples from > AT&T - > https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-add= ressing.jsp, > Verizon - > http://www.verizonwireless.com/businessportals/support/features/data_serv= ices/static_ip.html > and Sprint - > https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink= _and_static_ip/index.html#.VxC7xSN9480 > providing this service (which is called: Static IP address) > Regards, > Alper and Danny > > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Sun May 8 04:06:12 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC77D12D144 for ; Sun, 8 May 2016 04:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmAD4ATMLkuL for ; Sun, 8 May 2016 04:06:08 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id B573612D105 for ; Sun, 8 May 2016 04:06:08 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 08 May 2016 04:06:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,595,1455004800"; d="scan'208";a="961303803" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 08 May 2016 04:06:04 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 8 May 2016 04:06:01 -0700 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 8 May 2016 04:06:01 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by hasmsx109.ger.corp.intel.com ([169.254.3.59]) with mapi id 14.03.0248.002; Sun, 8 May 2016 14:05:58 +0300 From: "Moses, Danny" To: "sarikaya@ieee.org" Thread-Topic: [DMM] OnDemand draft: 3 address types discussion Thread-Index: AdGlNxViVeTLSORKTxOVT+qsHcWdEQCfCa4AAFlMDsA= Date: Sun, 8 May 2016 11:05:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmFjMzFhNTktYjc0NS00NzZmLWEyMzktYTk1Mzk4ZDAzZTExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InBlQ0dsKzBXVlg2MG9SZFwvRmM5RFJqR0ZCbmorTlRGXC9FNllUUUN0YVlIST0ifQ== x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 11:06:11 -0000 Q29tZSBvbiBCZWhjZXQsIHRoaXMgbm90ZSBmcm9tIHlvdSBpcyByZWFsbHkgaW5zdWx0aW5nLg0K SVBWNl9QUkVGRVJfU1JDX0hPTUUgYW5kIElQVjZfUFJFRkVSX1NSQ19DT0EgYXNzdW1lcyB0aGUg aW1wbGVtZW50YXRpb24gb2YgTUlQIHdoZXJlIHRoZSBtb2JpbGUgaG9zdCBpcyBwcm92aXNpb25l ZCBhIEhvbWUgQWRkcmVzcyBhbmQgYSBDYXJlLW9mIEFkZHJlc3MuDQoNCkJ1dCB3aXRoIFBNSVB2 NiBhbmQgM0dQUCAoR1RQIC0gdG8gYmUgbW9yZSBhY2N1cmF0ZSksIHRoZSBtb2JpbGUgbm9kZSBp cyBwcm92aXNpb25lZCB3aXRoIGEgc291cmNlIElQIGFkZHJlc3MgYW5kIHRoZSB0dW5uZWxpbmcg b3BlcmF0aW9uIGlzIHBlcmZvcm1lZCBieSBwcm94eSBhbmQgaXMgdHJhbnNwYXJlbnQgdG8gdGhl IG1vYmlsZSBob3N0LiBTbyBhIG1vYmlsZSBub2RlIGNhbm5vdCBpbmZsdWVuY2UgdGhlIG5ldHdv cmsncyB0dW5uZWxpbmcgb3BlcmF0aW9uLi4uDQoNClJlZ2FyZHMsDQoJL0Rhbm55DQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZWhjZXQgU2FyaWtheWEgW21haWx0bzpzYXJp a2F5YTIwMTJAZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwgTWF5IDA2LCAyMDE2IDIyOjIxDQpU bzogTW9zZXMsIERhbm55DQpDYzogZG1tQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RNTV0gT25E ZW1hbmQgZHJhZnQ6IDMgYWRkcmVzcyB0eXBlcyBkaXNjdXNzaW9uDQoNCkhpIERhbm55LA0KDQpU aGlzIGlzIG15IHJlcGx5IHRvIGFsbCB5b3VyIG1haWxzLiBJIGhvcGUgaXQgY2xhcmlmaWVzIHRo ZSBhaXIuDQoNCkkgcmVhZCBSRkMgNTAxNCBhbmQgSSB0aGluayB0aGF0IG9uLWRlbWFuZCBtb2Jp bGl0eSBhcyBJIGFuZCBpdCBzZWVtcyBsaWtlIGFzIDNHUFAgdW5kZXJzdGFuZHMgaXMgYWxyZWFk eSB0aGVyZToNCg0KSVBWNl9QUkVGRVJfU1JDX0hPTUUNCklQVjZfUFJFRkVSX1NSQ19DT0ENCg0K YXJlIGFsbCB3ZSBuZWVkLg0KU28gaWYgVUUgd2FudHMgbW9iaWxpdHksIGl0IHNldHMgIElQVjZf UFJFRkVSX1NSQ19IT01FIGFuZCBhcyBhIHJlc3VsdCBnZXRzIHRoZSBmaXhlZCBJUCBhZGRyZXNz IGFzIHlvdSBjYWxsIGl0IG9yIGl0IGdldHMgYW5jaG9yZWQgbW9iaWxpdHkgc2VydmljZS4NCg0K SWYgVUUgZG9lcyBub3Qgd2FudCBtb2JpbGl0eSwgaXQgc2V0cyBJUFY2X1BSRUZFUl9TUkNfQ09B IHRoZW4gaXQgZ2V0cyB0aGUgbm9tYWRpYyBJUCBhZGRyZXNzLg0KDQpOb3RlIHRoYXQgaW4gdGhl IGNhc2Ugb2YgbW9iaWxpdHksIFVFIG1heSBzdGlsbCBnZXQgbm9tYWRpYyBhZGRyZXNzIGFuZCBt b2JpbGl0eSwgdGhhdCBpcyBhbm90aGVyIGlzc3VlLg0KDQpUaGVyZWZvcmUgUkZDIDUwMTQgaXMg Z29vZCBlbm91Z2gsIHRoZSBhdXRob3JzLCBhbGwgZ29vZCBmcmllbmRzIG9mIHRoaXMgY29tbXVu aXR5IGhhdmUgZG9uZSBhIGdvb2Qgam9iLg0KDQpSZWdhcmRzLA0KDQpCZWhjZXQNCg0KDQpPbiBU dWUsIE1heSAzLCAyMDE2IGF0IDc6MjcgQU0sIE1vc2VzLCBEYW5ueSA8ZGFubnkubW9zZXNAaW50 ZWwuY29tPiB3cm90ZToNCj4NCj4gVGhpcyBpcyBpbiByZXBseSB0byBjb21tZW50cyB3ZSByZWNl aXZlZCBmcm9tIEJlaGNldCBhbmQgU3VyZXNoIA0KPiByZWdhcmRpbmcgdGhlIHRocmVlIHR5cGVz IG9mIGFkZHJlc3NlcyBkZWZpbmUgaW4gdGhlIGRyYWZ0LiBTdXJlc2ggDQo+IGNvbW1lbnRlZCB0 aGF0IHRoZSDigJhGaXhlZCBJUCBhZGRyZXNz4oCZIGlzIG5vdCBuZWNlc3NhcnkgYW5kIGFwcGxp Y2F0aW9uIA0KPiBvbmx5IHJlcXVpcmUgdG8gc2VsZWN0IFN1c3RhaW5lZCBvciBOb21hZGljIElQ IGFkZHJlc3NlcyBhbmQgQmVoY2V0IA0KPiBjb21tZW50ZWQgdGhhdCB0aGUg4oCYU3VzdGFpbmVk IElQIGFkZHJlc3PigJkgaXMgbm90IG5lZWRlZCBhbmQgbm90IHdlbGwgDQo+IGRlZmluZSBkdWUg dG8gdGhlIGZhY3QgdGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBpZGVudGlm eSANCj4gdGhlIGVuZCBvZiBhbiBJUCBzZXNzaW9uICh3aWxsIGJlIGRpc2N1c3NlZCBpbiBhIHNl cGFyYXRlIGVtYWlsKS4NCj4gV2UgaGF2ZSBnYXZlIG1vcmUgdGhvdWdodCB0byB0aGVzZSB0eXBl cyBhbmQgY29uY2x1ZGVkIHRoYXQgdGhlIA0KPiBkZWZpbml0aW9ucyBpbiB0aGUgc3BlYyB3ZXJl IGNvbmZ1c2luZy4gV2UgYXJlIHByb3ZpZGluZyBuZXcgdGV4dCBpbiANCj4gdGhlIG5ldyB2ZXJz aW9uLCBob3BpbmcgdGhleSBhcmUgbW9yZSBjbGVhci4NCj4gV2UgcmUtZXZhbHVhdGVkIHdoZXRo ZXIgdG8gc3RheSB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHRocmVlIElQIA0KPiBhZGRyZXNzIHR5 cGVzIG9yIG1vdmUgdG8gYSB0d28gSVAgYWRkcmVzcyB0eXBlIHNjaGVtZSBhbmQgZXZlbnR1YWxs eSANCj4gY29uY2x1ZGVkIHRoYXQgaXQgaXMgYmV0dGVyIHRvIHN0YXkgd2l0aCB0aGUgdGhyZWUg dHlwZSBhbHRlcm5hdGl2ZS4gDQo+IFdlIGhvcGUgdGhhdCB0aGUgYmV0dGVyIHRleHQgaW4gdGhl IG5ldyBkcmFmdCB2ZXJzaW9uIHdpbGwgY2xhcmlmeSBhbmQgDQo+IGhlcmUgYXJlIHNvbWUgYWRk aXRpb25hbCBpbnB1dHM6DQo+IE5vbWFkaWMgSVAgYWRkcmVzcyAob3IgaW4gaXRzIG5ldyBuYW1l OiBOb24tcGVyc2lzdGVudCBJUCBhZGRyZXNzKToNCj4gQ2xlYXJseSB0aGlzIHR5cGUgaXMgdXNl ZnVsIGZvciBhbGwgYXBwbGljYXRpb25zIHRoYXQgZG8gbm90IHJlcXVpcmUgDQo+IGFueSBJUCBz ZXNzaW9uIGNvbnRpbnVpdHkgZ3VhcmFudGVlIGZyb20gdGhlIG5ldHdvcmsgYW5kIHdpc2ggdG8g YXZvaWQgDQo+IHRoZSBvdmVyaGVhZCBpbnRyb2R1Y2VkIGJ5IHRoZSBuZXR3b3JrIGFzIHBhcnQg b2YgdGhhdCBndWFyYW50ZWUgDQo+IChpbmVmZmljaWVudCByb3V0ZXMsIHR1bm5lbGluZyBldGPi gKYpLg0KPiBTdXN0YWluZWQgSVAgYWRkcmVzcyAob3IgaW4gaXRzIG5ldyBuYW1lOiBTZXNzaW9u LWxhc3RpbmcgSVAgYWRkcmVzcyk6DQo+IFRoaXMgaXMgb3VyIGFjY3VyYXRlIGRlZmluaXRpb24g Zm9yIHRoZSBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgc2VydmljZSANCj4gdGhhdCBzb21lIGFwcGxp Y2F0aW9uIHJlcXVpcmUgYW5kIGlzIHNpbWlsYXIgdG8gd2hhdCBpcyBwcm92aWRlZCB0b2RheSAN Cj4gYnkgZGVmYXVsdCwgYnkgbW9iaWxlIG9wZXJhdG9ycyB2aWEgR1RQIG9yIFBNSVAuIEJhc2lj YWxseSwgY3VycmVudCANCj4gaW1wbGVtZW50YXRpb25zIHByb3ZpZGUgIGEgZ3VhcmFudGVlIGZv ciB0aGUgc291cmNlIElQIGFkZHJlc3MgdG8gYmUgDQo+IHZhbGlkIHRocm91Z2hvdXQgdGhlIHRp bWUgdGhlIG1vYmlsZSBob3N0IGlzIGNvbm5lY3RlZCB0byB0aGUgbW9iaWxlIG5ldHdvcmsuDQo+ IFdlIGNvbmNsdWRlZCB0aGF0IG1vYmlsZSBob3N0cyBkbyBub3QgcmVhbGx5IHJlcXVpcmUgc3Vj aCBhIGd1YXJhbnRlZS4gDQo+IEl0IGlzIHN1ZmZpY2llbnQgdG8gcmVxdWlyZSBhIGd1YXJhbnRl ZSBvZiB0aGUgSVAgYWRkcmVzcyBhdmFpbGFiaWxpdHkgDQo+IHdoaWxlIHRoZXJlIGlzL2FyZSBh biBJUCBzZXNzaW9uKHMpIHVzaW5nIHRoaXMgSVAgYWRkcmVzcyBhbmQgaGVuY2UgDQo+IHRoZSBt b3JlIGFjY3VyYXRlIGRlZmluaXRpb24uIEZ1cnRoZXJtb3JlLCBzb21lIFdHIG1lbWJlcnMgaGF2 ZSBzaG93biANCj4gY2FzZXMgaW4gRE1NIHdoZXJlIGl0IGlzIG1vcmUgZWZmaWNpZW50IGZvciBh cHBsaWNhdGlvbnMgdG8gcmVxdWVzdCBhIA0KPiBuZXcgU2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJl c3Mgd2hlbiBsYXVuY2hlZCByYXRoZXIgdGhhbiB1c2luZyBhbiANCj4gZXhpc3Rpbmcgb25lIHRo YXQgd2FzIGFsbG9jYXRlZCB0byB0aGUgbW9iaWxlIGhvc3QgaW4gdGhlIHBhc3QuIFRoaXMgDQo+ IGlzIGR1ZSB0byBwb3NzaWJsZSBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QgdG8gYSBMQU4g d2hpY2ggaXMgYmVpbmcgDQo+IHNlcnZlZCBieSBhIG1vYmlsaXR5IGFuY2hvciB0aGF0IGlzIGRp ZmZlcmVudCBmcm9tIHRoZSBvbmUgdGhhdCB3YXMgDQo+IHVzZWQgd2hlbiB0aGUgb2xkZXIgU2Vz c2lvbi1sYXN0aW5nIElQIGFkZHJlc3Mgd2FzIGFzc2lnbmVkIHRvIHRoZSBtb2JpbGUgaG9zdC4N Cj4gRml4ZWQgSVAgYWRkcmVzcyAobm8gcmVuYW1pbmcg4oCmKToNCj4gV2UgYmVsaWV2ZSB0aGF0 IHRoaXMgaXMgd2hlcmUgb3VyIG9yaWdpbmFsIHRleHQgd2FzIHRoZSBtb3N0IHVuY2xlYXIgDQo+ IGxlYWRpbmcgdG8gdGhlIGNvbmZ1c2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCB0aGUgY29t bWVudHMgZnJvbSB0aGUgDQo+IGZsb3VyLiBBIEZpeGVkIElQIGFkZHJlc3MgaXMgZ3VhcmFudGVl ZCBieSB0aGUgbmV0d29yayB0byBBbHdheXMgYmUgDQo+IHZhbGlkLCBldmVuIGlmIHRoZSBtb2Jp bGUgaG9zdCBpcyBub3QgdXRpbGl6aW5nIGFueSBJUCBzZXNzaW9ucywgb3IgDQo+IGhhcyBiZWVu IGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBuZXR3b3JrIGZvciBzb21lIHRpbWUuIFRoaXMgaXMgYSAN Cj4gc3BlY2lhbCBzZXJ2aWNlIHRoYXQgbW9iaWxlIG5ldHdvcmsgb3BlcmF0b3JzIHByb3ZpZGUg Zm9yIGEgcHJlbWl1bSANCj4gY2hhcmdlLCBmb3Igc2VydmVycywgVlBOcyAsIHNlY3VyZWQgY29u dGVudCBhbmQgb3RoZXIgYXBwbGljYXRpb25zLiANCj4gV2l0aCB0aGlzIElQIGFkZHJlc3MgdHlw ZSB0aGUgbmV0d29yayBvcGVyYXRvciBwcm92aWRlIElQIGFkZHJlc3MgDQo+IHJlYWNoYWJpbGl0 eSBpbiBhZGRpdGlvbiB0byBJUCBzZXNzaW9uIGNvbnRpbnVpdHksIGFuZCBtb2JpbGUgaG9zdHMg DQo+IG1heSByZWdpc3RlciB0aGVzZSBhZGRyZXNzZXMgaW4gRE5TIGluZnJhc3RydWN0dXJlIGZv ciBuYW1lIHJlc29sdXRpb24uDQo+IENsZWFybHksIG1vc3QgbW9iaWxlIGhvc3RzIGRvIG5vdCBy ZXF1aXJlIEZpeGVkIElQIGFkZHJlc3NlcyBhbmQgdGhlaXIgDQo+IG93bmVycyB3aWxsIG5vdCBw YXkgdGhlIHByZW1pdW0gY29zdCBmb3IgdGhpcyBzZXJ2aWNlLCBidXQgc3RpbGwsIGl0IA0KPiBp cyBhIHNlcnZpY2UgdGhhdCBtb2JpbGUgb3BlcmF0b3JzIHByb3ZpZGUgYW5kIHRoaXMgaXMgZW5v dWdoIHByb29mIA0KPiBmb3IgdXMgdG8gYWNrbm93bGVkZ2UgaXRzIG5lZWQuIFBsZWFzZSBzZWUg c29tZSBleGFtcGxlcyBmcm9tIEFUJlQgLSANCj4gaHR0cHM6Ly93d3cud2lyZWxlc3MuYXR0LmNv bS9idXNpbmVzc2NlbnRlci9zb2x1dGlvbnMvY29ubmVjdGl2aXR5L2lwLQ0KPiBhZGRyZXNzaW5n LmpzcCwNCj4gVmVyaXpvbiAtDQo+IGh0dHA6Ly93d3cudmVyaXpvbndpcmVsZXNzLmNvbS9idXNp bmVzc3BvcnRhbHMvc3VwcG9ydC9mZWF0dXJlcy9kYXRhX3MNCj4gZXJ2aWNlcy9zdGF0aWNfaXAu aHRtbA0KPiBhbmQgU3ByaW50IC0NCj4gaHR0cHM6Ly93d3cuc3ByaW50LmNvbS9idXNpbmVzcy9z b2x1dGlvbnMvc3ByaW50X2VuYWJsZXJzL3NwcmludF9kYXRhbA0KPiBpbmtfYW5kX3N0YXRpY19p cC9pbmRleC5odG1sIy5WeEM3eFNOOTQ4MA0KPiBwcm92aWRpbmcgdGhpcyBzZXJ2aWNlICh3aGlj aCBpcyBjYWxsZWQ6IFN0YXRpYyBJUCBhZGRyZXNzKSBSZWdhcmRzLCANCj4gQWxwZXIgYW5kIERh bm55DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9y YXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzDQo+DQo+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvciANCj4gdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0 aW9uIA0KPiBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIA0KPiByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSBhbGwgY29waWVzLg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXMK ClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG1hdGVyaWFsIGZvcgp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g QW55IHJldmlldyBvciBkaXN0cmlidXRpb24KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLgo= From nobody Mon May 9 01:53:40 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08012B05F for ; Mon, 9 May 2016 01:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7iqPcIdzf1L for ; Mon, 9 May 2016 01:53:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5494412B023 for ; Mon, 9 May 2016 01:53:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u498rWtM012716; Mon, 9 May 2016 10:53:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2C2BE207553; Mon, 9 May 2016 10:55:28 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 14217207546; Mon, 9 May 2016 10:55:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u498rV6m014920; Mon, 9 May 2016 10:53:32 +0200 To: "Moses, Danny" , "dmm@ietf.org" References: From: Alexandre Petrescu Message-ID: Date: Mon, 9 May 2016 10:53:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 08:53:38 -0000 Hi Danny, Thank you for continuing the discussion on the 3 address types. Le 03/05/2016 à 14:27, Moses, Danny a écrit : > > This is in reply to comments we received from Behcet and Suresh > regarding the three types of addresses define in the draft. Suresh > commented that the ‘Fixed IP address’ is not necessary and > application only require to select Sustained or Nomadic IP addresses > and Behcet commented that the ‘Sustained IP address’ is not needed > and not well define due to the fact that the draft does not define > how to identify the end of an IP session (will be discussed in a > separate email). To me, the problem in the definitions shown in the Buenos Aires slide 4 https://www.ietf.org/proceedings/95/slides/slides-95-dmm-2.pdf is that they dont relate to each other. This makes that a FIXED address could be a SUSTAINED could be a NOMADIC. For example, a FIXED 'exists no matter where the host moves to', and a SUSTAINED 'is valid as long as the IP session is alive'. One does not exclude the other. You could have an address be NOMADIC and SUSTAINED at the same time ('exists no matter where the host moves to' and 'valid as long as the IP session is alive'). A definition which relates them would keep the FIXED to be 'exists no matter where the host moves to' and NOMADIC to be 'changes in certain places where the host moves to'. Thus, this improved definition would not allow a FIXED _and_ NOMADIC at the same time. > We have gave more thought to these types and concluded that the > definitions in the spec were confusing. We are providing new text in > the new version, hoping they are more clear. Let me see whether I can understand. > We re-evaluated whether to stay with the definition of three IP > address types or move to a two IP address type scheme and eventually > concluded that it is better to stay with the three type > alternative. A-ha. > We hope that the better text in the new draft version will clarify > and here are some additional inputs: > Nomadic IP address (or in its new name: Non-persistent IP address): > Clearly this type is useful for all applications that do not require > any IP session continuity guarantee from the network and wish to > avoid the overhead introduced by the network as part of that > guarantee (inefficient routes, tunneling etc…). > Sustained IP address (or in its new name: Session-lasting IP > address): This is our accurate definition for the IP session > continuity service that some application require and is similar to > what is provided today by default, by mobile operators via GTP or > PMIP. These two definitions relate more to each other than the earlier definitions, by the application requirements. Yet, some questions arise: The apps which don't require a session-lasting IP address can obviously work with a session-lasting IP address too. So some of the session-lasting IP addresses can be non-persistent IP addresses? The apps which require a session-lasting IP address wish to introduce overhead in the network? Mobile operators using GTP or PMIP do not provide non-persistent IP addresses? > Basically, current implementations provide a guarantee for the > source IP address to be valid throughout the time the mobile host is > connected to the mobile network. We concluded that mobile hosts do > not really require such a guarantee. It is sufficient to require a > guarantee of the IP address availability while there is/are an IP > session(s) using this IP address and hence the more accurate > definition. I dont understand. Until here the app requirements where important. Now we change to make the mobile host to be important(?) > Furthermore, some WG members have shown cases in DMM where it is > more efficient for applications to request a new Session-lasting IP > address when launched rather than using an existing one that was > allocated to the mobile host in the past. Well, I wonder about this. In the environments I work I never saw an application (e.g. a browser) to request an IP address. It is the connection manager which deals with address configuration. This connection manager is not in contact with other applications like web browsers. > This is due to possible movement of the mobile host to a LAN which is > being served by a mobility anchor that is different from the one that > was used when the older Session-lasting IP address was assigned to > the mobile host. Fixed IP address (no renaming …): We believe that > this is where our original text was the most unclear leading to the > confusion on the mailing list and the comments from the flour. > A Fixed IP address is guaranteed by the network to Always be valid, > even if the mobile host is not utilizing any IP sessions, or has been > disconnected from the network for some time. This is a special > service that mobile network operators provide for a premium charge, > for servers, VPNs , secured content and other applications. With this > IP address type the network operator provide IP address reachability > in addition to IP session continuity, and mobile hosts may register > these addresses in DNS infrastructure for name resolution. I can understand the intention of the fixed IP address definition. But I wonder whether there can be an improved definition of a fixed IP address. Because of the following: A 'fixed' IP address, as much as it can be guaranteed by an operator at a premium cost, will not be possible if moving to a more remote area: for example, when moving from US to Europe can not maintain that fixed IP address even if it is paid a very high price. > Clearly, most mobile hosts do not require Fixed IP Again: _mobile hosts_ require? Or apps require? A more coherent definition can take advantage of using only app requirements, or only mobile host reqs, or both but everywhere (i.e. each of the 3 types of addresses relates to both MH reqs and to app reqs). > addresses and their owners will not pay the premium cost for this > service, but still, it is a service that mobile operators provide > and this is enough proof for us to acknowledge its need. > Please see some examples Thank you very much for these pointers. This makes it easier to understand the intention. > from AT&T - > _https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp_, Is this IPv4 only? > Verizon - > _http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html_ Is this IPv4 only? > Sprint - > _https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480_ Is this IPv4 only? I am asking the IP version question because address configuration is very different in IPv6 than IPv4. For example, in IPv6 the network does not assign an address to a host (as in IPv4 is done with context setup), but advertises a prefix to a link and the host forms an address. In such a context the potential mechanism to achieve static IP addresses is very different - not only the network is in charge but the terminal too. Moreover, whereas in IPv4 cellular networks the mechanism to achieve static IP address is standardised (NAI, PDP context setup, ppp), in IPv6 there is no such mechanism standardised nor deployed. Is there an example of deployed static IPv6 addresses in cellular networks? (as the IPv4 example of AT&T, Verizon, Sprint). That would be very relevant too. Alex From nobody Mon May 9 10:37:01 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9605712D167 for ; Mon, 9 May 2016 10:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3JyMhhgmk5u for ; Mon, 9 May 2016 10:36:58 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E037312D589 for ; Mon, 9 May 2016 10:36:37 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id y69so77760486pfb.1 for ; Mon, 09 May 2016 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eT7ouGNSPnNiS5a52EwaJzaUL0bMM9broqH5a9kvJro=; b=0RVm9NnVPQkNimsqSiJW+jhKclxTE/9xoJPEe0iEmXh4mZIPTZBuMWZ+gF6N/YlLNc 8swDhWvvvdezKznhhhCYxf2aIH7N9bxn/C3CS9SHaAAE9ovrE6HYjm9b6+ZKRk+MJpJ3 YG0tIxj45hUPhXXHfvGvKfjzjOPS7xaBfjpyC1ydAv9O6W0IGK31kas7/2zJDp14dwS/ S6PlZeCFvN+f2lSiP1bFGXh4mXpMm1mi6Yj8QyJ5NvLKliaqQphWXvNccaBr38zXYF3x IrAt3NDvp5gHjloM1VEf0mplVla+VCEvARaPDNh/wyX6qDwFhuARN5zcPAJvPkd5DGXI SBgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eT7ouGNSPnNiS5a52EwaJzaUL0bMM9broqH5a9kvJro=; b=UVisov6xpn/QrEIyKvOidsak1OREQZysC0kEphWgbzuz+/kLdGQLVBhluhyWySPHxO nmK/oarH935JZlT/3XiHfd0ZN+32cx6zVchR/m6qke8slvEkSHQL7Nv1soVGVXnvlBsJ dp2mk4i4zBZNqPG4IGJzmGMeX0X5WcqUV2LHyq5TlAk1RU4fk6ysZGjGRR21QbR4aDOa 3eW3P59cImGh55ZPEENVqyBeGaF2hqTSqELNpy405w/gMyCFCbCQZotJt0/DlYDBQepM A4pA0LCi2RbDSlVTYQeEungIsiDJAmVxPr2QBUx9BloLsuASajRQrQD7zbQk8Kzv8LIS jQqQ== X-Gm-Message-State: AOPr4FWB3HTXqht8qNxd9nHprhmZK5YqrtEvTfPJCyIyPa/n8+NTUWwYYZIxyNLmKhOQUg== X-Received: by 10.98.42.216 with SMTP id q207mr40964024pfq.6.1462815397503; Mon, 09 May 2016 10:36:37 -0700 (PDT) Received: from [10.16.65.123] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id w15sm41962486pfa.34.2016.05.09.10.36.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 10:36:36 -0700 (PDT) References: To: Alexandre Petrescu , "Moses, Danny" , "dmm@ietf.org" From: Jouni Korhonen Message-ID: <5730CA9E.1010300@gmail.com> Date: Mon, 9 May 2016 10:36:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 17:37:00 -0000 Actually, IKEv2-based mechanisms did allow assigning /128 IPv6 address to an UE within 3GPP specs (haven't checked possible changes since rel-11, though). I have no idea whether this was ever implemented. 5/9/2016, 1:53 AM, Alexandre Petrescu kirjoitti: > Moreover, whereas in IPv4 cellular networks the mechanism to achieve > static IP address is standardised (NAI, PDP context setup, ppp), in IPv6 > there is no such mechanism standardised nor deployed. From nobody Mon May 16 02:58:57 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AB112D0CE for ; Mon, 16 May 2016 02:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt255PG18W_Q for ; Mon, 16 May 2016 02:58:53 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4390A12D0C5 for ; Mon, 16 May 2016 02:58:53 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP; 16 May 2016 02:58:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,626,1455004800"; d="scan'208";a="981897870" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 16 May 2016 02:58:52 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 May 2016 02:58:51 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.231]) by LCSMSX154.ger.corp.intel.com ([169.254.7.36]) with mapi id 14.03.0248.002; Mon, 16 May 2016 12:58:48 +0300 From: "Moses, Danny" To: Alexandre Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] OnDemand draft: 3 address types discussion Thread-Index: AdGlNxViVeTLSORKTxOVT+qsHcWdEQEgAgmAAWOfSXA= Date: Mon, 16 May 2016 09:58:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWE5YWUyMzEtMmM0Yy00NTUwLWE4Y2UtNjZkOTRjNGY3ZWQ1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InNLWkhDZDk3ZGczRWR6QXVGemZoazl6M1J1NnVNWktQNHByQjRRQlBTbVU9In0= x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:58:55 -0000 Hi Alex, Thank you very much for the detailed review and comments. I have tried to a= nswer them, but if I was not able to be clear enough, I will be happy to di= scuss this with you. I am removing parts of the previous exchange so that everyone can find the = open questions and answers more easily. Regards, /Danny --------------- Text removed from previous exchange----------------- ---------------------------------------------------------------------------= ----- Alex > Yet, some questions arise: The apps which don't require a session-lasting IP address can obviously wor= k with a session-lasting IP address too. So some of the session-lasting IP= addresses can be non-persistent IP addresses? Danny > True, applications that do not require a session-lasting IP address can wor= k correctly with a session-lasting IP address. But in that case, the networ= k will invest resources in guaranteeing this without any real need and thus= , these resources will be wasted. From the application side, its traffic ma= y suffer from the treatment associated with providing session-lasting chara= cteristics (non-optimal routing, encapsulation/decapsulation overhead which= influences MTU, etc). Still, I believe that there will be cases when this = is performed. One example is in cellular networks that automatically provid= e tunneling and do not support the ability to receive IP address type reque= sts from the mobile node. But, if an application requests a session-lasting IP address, and the netwo= rk provides one, it should treat it as such - e.g. provide IP continuity gu= arantee throughout the lifetime of the session. The network cannot tell if = the address is 'really' using the guarantee or not. = I did not understand what you mean by 'So some of the session-lasting IP ad= dresses can be non-persistent IP addresses?'. No, if the network provides a= session-lasting IP address, it is committed to guarantee it (even if the a= pplication does not need the service). Alex > The apps which require a session-lasting IP address wish to introduce overh= ead in the network? Danny > Apps which require session-lasting IP addresses are apps that cannot recove= r from the event of source IP addresses becoming obsolete as a result of th= e mobile node moving to a LAN with a different IP prefix. This is why they = request a session-lasting IP address. Not because they wish to introduce ov= erhead - this is a by product... Alex > Mobile operators using GTP or PMIP do not provide non-persistent IP address= es? Danny > = Mobile operators using GTP or PMIP provide a guarantee that the source IP a= ddress they allocated to a mobile node will continue to exist (and be valid= ) as long as the mobile node is connected to the network (or as long as the= DHCP lease condition are meat - if DHCP is used). This even a better guara= ntee than what we defined by 'session-lasting' IP address, because the GTP/= PMIP source IP address is guaranteed regardless of the initiation/end of IP= session. In our understanding, this extra guarantee is not really needed a= nd in the DMM environment where they may be multiple mobility anchors might= even introduce inefficient routing (which could be avoided in the newly in= troduced scheme). To the best of my knowledge, mobile operators do not provide non-persistent= IP addresses. Alex> > Basically, current implementations provide a guarantee for the source = > IP address to be valid throughout the time the mobile host is = > connected to the mobile network. We concluded that mobile hosts do not = > really require such a guarantee. It is sufficient to require a = > guarantee of the IP address availability while there is/are an IP > session(s) using this IP address and hence the more accurate = > definition. I dont understand. Until here the app requirements where important. Now we change to make the= mobile host to be important(?) Danny > In current implementation a source IP address is allocated to the mobile ho= st and is valid throughout the connection of the mobile host to the network= . This is why I use the term 'mobile host' in the description that you quot= ed. We are introducing an new concept - 'OnDemand' - where each time an IP ses= sion is created (by an application running on the host), an application can= request a specific source IP address for that session (with specific type)= . From the network's perspective, this address was allocated to a mobile ho= st. This means that at any given time, a mobile host might have more than o= ne source IP address allocated to in, and different IP sessions initiated b= y that host (by different applications running on that host) may be used in= different packets being sent/received by it. I can understand why this is confusing. If this explanation is not sufficie= nt, I will be happy to discuss this point with you. Alex > > Furthermore, some WG members have shown cases in DMM where it is more = > efficient for applications to request a new Session-lasting IP address = > when launched rather than using an existing one that was allocated to = > the mobile host in the past. Well, I wonder about this. Danny > Well, they did not use the term 'OnDemand' specifically, but they did show = that in a distributed mobility anchor scheme, there are cases where allocat= ing a new IP address may result in a more optimal route of the IP flow comp= ared with using the already-allocated IP address. This is because the origi= nal IP address is served by one mobility anchor (hence all traffic must be = routed through it), and after the mobile host moves to a new location, traf= fic may possibility be routed via a different mobility anchor which is topo= logically better. Once again, we can further discuss this topic). Please refer to the following IDs: https://datatracker.ietf.org/doc/draft-bernardos-dmm-distributed-anchoring/ https://tools.ietf.org/html/draft-seite-dmm-dma-07 Alex > In the environments I work I never saw an application (e.g. a browser) to r= equest an IP address. It is the connection manager which deals with addres= s configuration. This connection manager is not in contact with other appl= ications like web browsers. Danny > That is correct - application do not request IP addresses. This is a new co= ncept we are introducing. Application, through the Socket interface, can in= dicate to the TCP/IP stack, the type of source IP address they require. The= TCP/IP stack, will ether associate an existing IP address with that Socket= or initiate a request to the network for a source IP address of the desire= d type. Alex > > This is due to possible movement of the mobile host to a LAN which is = > being served by a mobility anchor that is different from the one that = > was used when the older Session-lasting IP address was assigned to the = > mobile host. Fixed IP address (no renaming ...): We believe that this is = > where our original text was the most unclear leading to the confusion = > on the mailing list and the comments from the flour. > A Fixed IP address is guaranteed by the network to Always be valid, = > even if the mobile host is not utilizing any IP sessions, or has been = > disconnected from the network for some time. This is a special service = > that mobile network operators provide for a premium charge, for = > servers, VPNs , secured content and other applications. With this IP = > address type the network operator provide IP address reachability in = > addition to IP session continuity, and mobile hosts may register these = > addresses in DNS infrastructure for name resolution. I can understand the intention of the fixed IP address definition. But I wonder whether there can be an improved definition of a fixed IP addr= ess. Because of the following: A 'fixed' IP address, as much as it can be guaranteed by an operator at a p= remium cost, will not be possible if moving to a more remote area: for example, when moving from US to Europe can not maintain that fixed IP a= ddress even if it is paid a very high price. Danny > With the appropriate roaming implementation, even this can be achieved. But= , when moving to an area where no roaming partner exists, you are correct. = But this sounds to me like a business issue, not technical. Alex > > Clearly, most mobile hosts do not require Fixed IP Again: _mobile hosts_ require? Or apps require? Danny > You are correct. Its applications, not mobile hosts... Alex > A more coherent definition can take advantage of using only app requirement= s, or only mobile host reqs, or both but everywhere (i.e. each of the 3 types of addresses relates to both MH reqs and to app reqs). Danny > I agree Alex > > addresses and their owners will not pay the premium cost for this = > service, but still, it is a service that mobile operators provide and = > this is enough proof for us to acknowledge its need. > Please see some examples Thank you very much for these pointers. This makes it easier to understand= the intention. > from AT&T - > _https://www.wireless.att.com/businesscenter/solutions/connectivity/ip > -addressing.jsp_, Is this IPv4 only? > Verizon - > _http://www.verizonwireless.com/businessportals/support/features/data_ > services/static_ip.html_ Is this IPv4 only? > Sprint - > _https://www.sprint.com/business/solutions/sprint_enablers/sprint_data > link_and_static_ip/index.html#.VxC7xSN9480_ Is this IPv4 only? I am asking the IP version question because address configuration is very d= ifferent in IPv6 than IPv4. For example, in IPv6 the network does not assign an address to a host (as i= n IPv4 is done with context setup), but advertises a prefix to a link and t= he host forms an address. In such a context the potential mechanism to ach= ieve static IP addresses is very different - not only the network is in cha= rge but the terminal too. Moreover, whereas in IPv4 cellular networks the mechanism to achieve static= IP address is standardised (NAI, PDP context setup, ppp), in IPv6 there is= no such mechanism standardised nor deployed. Is there an example of deployed static IPv6 addresses in cellular networks?= (as the IPv4 example of AT&T, Verizon, Sprint). That would be very releva= nt too. Danny > Well, to the best of my knowledge, IPv4 is still more popular than IPv6 in = the States. But if this service is available for IPv4 today, I believe oper= ators will provide it with IPv6 service once they believe there is a busine= ss justification. We do not want to prevent this right? Alex --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Mon May 16 11:18:46 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDDD12D8F8 for ; Mon, 16 May 2016 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1o_1XkwlixM for ; Mon, 16 May 2016 11:18:44 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F68A12D8ED for ; Mon, 16 May 2016 11:18:44 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id bt5so66644155pac.3 for ; Mon, 16 May 2016 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=YJdmknKBz5Sn86qXrCL/2hgTLTFx+ruUcEsVHT/ig+M=; b=wJU08DldbcWBHrtMJNLMTSB+ql9frpyrUEG5JD17BPcyRtys3R4c5Cw0OJwKf+0tjv 6PRAhePbcIFpbpeT0vNqmWk9fwkH0i1dcY3eTmSeVZXKPmXk82HoApFfVCPMxVg9R4rG YtpV464gnLdpmURULIv9wuEwLPoyrkpRh/aKW2E1FEXO7aPOTf18Emy/lChuEGaVIc4J FTWwAEzRynoewhWv/r0nbSiYpa4CODHjD8x8E/8tT66f2U289Enl27ZcnFYvEWgVQPrT elu/FUpW8AcEwVjUBJZmQG3t+SiQ8/3vCj1wnp2tolufYYo4nlhdfijmw2JoNIJPmBht mvHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=YJdmknKBz5Sn86qXrCL/2hgTLTFx+ruUcEsVHT/ig+M=; b=VBmnsb689VMW2kCeH0eYbgiJhanr7WhaEWSznvc+Yjk1O0VqvGX4IwSB36clA6h3jS 1KBlBS7QOGF9wEx1iaG8fd8jQrTSj3mqBOpwwjM9HD16UxDfQChqdQnlUuqmEDP+V0gB eXK98DWz+1krft0006t5dwNOAXXrr0kTA4LIciSOQ/dGT+uVpeCq89qyzh7YS30p3/Gi 7ur78/iWrDLWWMb8UYMeQ146oxRgE4tDhoTNr6tU7HSyhwA2HfWs7BVCToZXqBx4hJRb Y4ZEHMJDTcB0hiAyqXkG2I6jwPEpMrBL+AFy/AaW2ktwN4jPYcVOPvudqrW2LAsV7teU oeRw== X-Gm-Message-State: AOPr4FUYyUg89bYE9f6qZ/0ypVXa9668lP78RGEGvSRP4ma4H4sWNAUJxgY5hRgonmtB7A== X-Received: by 10.66.141.103 with SMTP id rn7mr47171245pab.70.1463422723884; Mon, 16 May 2016 11:18:43 -0700 (PDT) Received: from [10.16.75.74] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id z9sm48829833pfa.84.2016.05.16.11.18.43 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 11:18:43 -0700 (PDT) To: "dmm@ietf.org" From: Jouni Korhonen Message-ID: <573A0EFC.9000008@gmail.com> Date: Mon, 16 May 2016 11:18:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] reviews requested for draft-ietf-dmm-mag-multihoming-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:18:46 -0000 Folks, Please, have a read on draft-ietf-dmm-mag-multihoming-01. More reviews are needed for this I-D before we move forward. It is a fairly short document.. If you have comments and want them addressed properly, also use the Issue Tracker to file your comments. Regards, Jouni & Dapeng From nobody Mon May 16 11:24:05 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED29112D905 for ; Mon, 16 May 2016 11:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZovzO5Jb6tHh for ; Mon, 16 May 2016 11:24:02 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5597212D904 for ; Mon, 16 May 2016 11:24:02 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id xk12so67614718pac.0 for ; Mon, 16 May 2016 11:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=LStNr7qmDCgaAYVjtPO7+ZTWAmnCB8y6nYcKor2aADE=; b=pjvIzBsgxNJ4QwS9WRR7N5gl3nn5aj1s0zBBHtIkHSR4MPZIQkLqNvix7ENGgZt5Qj M24pN65jooVl2607lGF7nKFn85kVaMyn0/MLik55742hB2GdeS6+pCQTQrFurXRppHaI pP+Du2rQYpfMS3/80n3bCTPbtbPqfrvYUd1ocBguB1b7zKTlTpCEI0EWVIaH9zr6yHa4 GmFAKpTZ2pZCnuHAhfGA+l8jINLarImpWHlp4onSw0ocFzybPGhTyhr7beJgiOTFQHv8 D45jmEzqtjQBRwoEv3Bi5WzL7nyZ4K2s1YU0aEp68GAYfDhPgAMG6dZuADI0Fl3STXlw EaNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=LStNr7qmDCgaAYVjtPO7+ZTWAmnCB8y6nYcKor2aADE=; b=msHYIA9cCg1GstfKODoECy3dZ6GHpFPsOZNveURskEkCnEWp3uCDBoJvHnUsbjipv2 f4h0Tp3ARDZZKDeu1VRLOu9LdD2/zBdhbz/NDDzf4x0f9Ce8Z8Acd7aFnjo9eLhkHdKd fd6OeUJeQaq+M97tDL4OibpsdXEq/JcUzjK8reBXVHe3iPNqZ2apIMbnJnlxmkX/H6mN TscFb20844honaim3EMcOCCmDJxIUSWQigItKfkOS7jLMH4haWyEcaW++0B1XzgojguE OEu/jJHyoS3ygRnp1R7u02c2JKHs5oH/yIN4yvrlk/3YTiWl+5tSRR0y70AKtnqMdCxs p2YQ== X-Gm-Message-State: AOPr4FXZAZBAiNPNTs+cbgMYYK2Nk7gAanDIhmzTtuDlJkIcWsOZsZSrWE2RqOi7vojVvA== X-Received: by 10.66.138.16 with SMTP id qm16mr47766213pab.28.1463423042014; Mon, 16 May 2016 11:24:02 -0700 (PDT) Received: from [10.16.75.74] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id zn12sm48993593pab.14.2016.05.16.11.24.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 11:24:01 -0700 (PDT) To: "dmm@ietf.org" , Jouni , =?UTF-8?B?5oiQIOm5jw==?= From: Jouni Korhonen Message-ID: <573A1039.2090001@gmail.com> Date: Mon, 16 May 2016 11:23:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] WGLC #1 for draft-ietf-dmm-lma-controlled-mag-params-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:24:04 -0000 Folks, This email starts the WGLC #1 for draft-ietf-dmm-lma-controlled-mag-params-01. Post your comment to the mailing list and also add your issues/correction requests/concerns etc into the Issue Tracker. WGLC #1 Starts: 5/16/2016 WGLC #1 Ends: 5/30/2016 EOB PDT Regards, Jouni & Dapeng From nobody Wed May 18 06:32:55 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AF712D136 for ; Wed, 18 May 2016 06:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su47bPkU4MCp for ; Wed, 18 May 2016 06:32:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C169612B050 for ; Wed, 18 May 2016 06:32:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4IDWm2w017627; Wed, 18 May 2016 15:32:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DB2E6205F67; Wed, 18 May 2016 15:32:49 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CD7E3205E16; Wed, 18 May 2016 15:32:49 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4IDWmcb005744; Wed, 18 May 2016 15:32:48 +0200 To: "Moses, Danny" , "dmm@ietf.org" References: From: Alexandre Petrescu Message-ID: Date: Wed, 18 May 2016 15:32:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 13:32:54 -0000 Danny, Thank you for the reply. I agree with most comments. I appreciate the effort you made to make a common understandable email. But we may further need to better understand each other by email. To that end, we would need to use a common way of citing each other. There are many ways that each person believes is the best. But there is only one way that is agreed by most. Le 16/05/2016 à 11:58, Moses, Danny a écrit : > Hi Alex, > > > Thank you very much for the detailed review and comments. I have > tried to answer them, but if I was not able to be clear enough, I > will be happy to discuss this with you. > > I am removing parts of the previous exchange so that everyone can > find the open questions and answers more easily. > > Regards, /Danny > > > --------------- Text removed from previous exchange----------------- > > -------------------------------------------------------------------------------- > > > > > > > > > > Alex > Yet, some questions arise: > > The apps which don't require a session-lasting IP address can > obviously work with a session-lasting IP address too. So some of > the session-lasting IP addresses can be non-persistent IP addresses? > > Danny > True, applications that do not require a session-lasting IP > address can work correctly with a session-lasting IP address. But in > that case, the network will invest resources in guaranteeing this > without any real need and thus, these resources will be wasted. Intuitively it can appear so: more state in routers maybe needed to maintain routes to an IP address which moves, rather than simply changing the IP address. And that state may look more expensive. On another hand, it may be that that 'cost' is artificial in the first place. Modem connections were first charged on a per-time basis - it was artificial; now there are flat rates. Initial 4G subscriptions plans allowed only for 1Gb 'fair use' - it was artificial; now there is 50Gb 'faire use' for same price as 1Gb only 2 years ago. Currently, some cellular operators only offer session-lasting IP addresses (do not offer non-persistent IP addresses). > From the application side, its traffic may suffer from the treatment > associated with providing session-lasting characteristics > (non-optimal routing, encapsulation/decapsulation overhead which > influences MTU, etc). Again, this may look so, intuitively speaking. But I beg to differ. If one looks at a cellular network from a latency perspective, one has to imagine the radio access link as very large, and the core network as very small. That means that sub-optimal routing and encap/decap overheads are very small compared to the radio access. On 4G, latency between the UE and the first IP hop is in the order of 50 milli-seconds, whereas the Ethernet latency (supposedly used in the wired segment to the first IP hop) is in the order of 1 micro-second. So, if instead of the optimal routing 1 micro-second the non-optimal routing is 3 micro-seconds that is very small compared to the radio access latency. That can not be considered as additional cost. > Still, I believe that there will be cases when this is performed. > One example is in cellular networks that automatically provide > tunneling and do not support the ability to receive IP address type > requests from the mobile node. Right. > But, if an application requests a session-lasting IP address, and > the network provides one, it should treat it as such - e.g. provide > IP continuity guarantee throughout the lifetime of the session. The > network cannot tell if the address is 'really' using the guarantee > or not. I can not agree that an application will require some kind of IP address. > I did not understand what you mean by 'So some of the > session-lasting IP addresses can be non-persistent IP addresses?'. > No, if the network provides a session-lasting IP address, it is > committed to guarantee it (even if the application does not need the > service). > > Alex > The apps which require a session-lasting IP address wish to > introduce overhead in the network? > > Danny > Apps which require session-lasting IP addresses are apps > that cannot recover from the event of source IP addresses becoming > obsolete as a result of the mobile node moving to a LAN with a > different IP prefix. This is why they request a session-lasting IP > address. Not because they wish to introduce overhead - this is a by > product... > > Alex > Mobile operators using GTP or PMIP do not provide > non-persistent IP addresses? > > Danny > Mobile operators using GTP or PMIP provide a guarantee that > the source IP address they allocated to a mobile node will continue > to exist (and be valid) as long as the mobile node is connected to > the network (or as long as the DHCP lease condition are meat - if > DHCP is used). This even a better guarantee than what we defined by > 'session-lasting' IP address, because the GTP/PMIP source IP address > is guaranteed regardless of the initiation/end of IP session. I can not imagine a Mobile operator which will give an address to a mobile that is not accepted on another access point. That is the whole point of 'Mobile' in mobile operator. Imagine - the end users will have to stay fixed (dont move), if they started some application. And there are many applications out there unaware. Or one would have to update all existing applications? This will _not_ work whenever the user wants to get in a train or car either (despite having the feeling of being fixed). Or do you consider the Mobile operator will equip the trains and the cars as well? > In our understanding, this extra guarantee is not really needed and > in the DMM environment where they may be multiple mobility anchors > might even introduce inefficient routing (which could be avoided in > the newly introduced scheme). > > To the best of my knowledge, mobile operators do not provide > non-persistent IP addresses. > > Alex> >> Basically, current implementations provide a guarantee for the >> source IP address to be valid throughout the time the mobile host >> is connected to the mobile network. We concluded that mobile hosts >> do not really require such a guarantee. It is sufficient to require >> a guarantee of the IP address availability while there is/are an IP >> session(s) using this IP address and hence the more accurate >> definition. > > I dont understand. > > Until here the app requirements where important. Now we change to > make the mobile host to be important(?) > > Danny > In current implementation a source IP address is allocated > to the mobile host and is valid throughout the connection of the > mobile host to the network. This is why I use the term 'mobile host' > in the description that you quoted. > > We are introducing an new concept - 'OnDemand' - where each time an > IP session is created (by an application running on the host), an > application can request a specific source IP address for that > session (with specific type). From the network's perspective, this > address was allocated to a mobile host. This means that at any given > time, a mobile host might have more than one source IP address > allocated to in, and different IP sessions initiated by that host (by > different applications running on that host) may be used in different > packets being sent/received by it. > > I can understand why this is confusing. If this explanation is not > sufficient, I will be happy to discuss this point with you. Yes, please clarify whether one has to update all applications in order to take advantage of this 'ondemand' aspect? > Alex > >> Furthermore, some WG members have shown cases in DMM where it is >> more efficient for applications to request a new Session-lasting >> IP address when launched rather than using an existing one that >> was allocated to the mobile host in the past. > > Well, I wonder about this. > > Danny > Well, they did not use the term 'OnDemand' specifically, but > they did show that in a distributed mobility anchor scheme, there are > cases where allocating a new IP address may result in a more optimal > route of the IP flow compared with using the already-allocated IP > address. This is because the original IP address is served by one > mobility anchor (hence all traffic must be routed through it), and > after the mobile host moves to a new location, traffic may > possibility be routed via a different mobility anchor which is > topologically better. Once again, we can further discuss this topic). > Please refer to the following IDs: > https://datatracker.ietf.org/doc/draft-bernardos-dmm-distributed-anchoring/ > > > > > > > https://tools.ietf.org/html/draft-seite-dmm-dma-07 > > Alex > In the environments I work I never saw an application (e.g. a > browser) to request an IP address. It is the connection manager > which deals with address configuration. This connection manager is > not in contact with other applications like web browsers. > > Danny > That is correct - application do not request IP addresses. > This is a new concept we are introducing. Application, through the > Socket interface, can indicate to the TCP/IP stack, the type of > source IP address they require. The TCP/IP stack, will ether > associate an existing IP address with that Socket or initiate a > request to the network for a source IP address of the desired type. It makes sense in a way: applications featuring 'ondemand' may put less apparent strain in the network. However, we need to make sure that all existing applications continue to work as before even if they dont run 'ondemand'. > > Alex > >> This is due to possible movement of the mobile host to a LAN which >> is being served by a mobility anchor that is different from the one >> that was used when the older Session-lasting IP address was >> assigned to the mobile host. Fixed IP address (no renaming ...): >> We believe that this is where our original text was the most >> unclear leading to the confusion on the mailing list and the >> comments from the flour. > >> A Fixed IP address is guaranteed by the network to Always be >> valid, even if the mobile host is not utilizing any IP sessions, or >> has been disconnected from the network for some time. This is a >> special service that mobile network operators provide for a premium >> charge, for servers, VPNs , secured content and other applications. >> With this IP address type the network operator provide IP address >> reachability in addition to IP session continuity, and mobile >> hosts may register these addresses in DNS infrastructure for name >> resolution. > > I can understand the intention of the fixed IP address definition. > > But I wonder whether there can be an improved definition of a fixed > IP address. Because of the following: > > A 'fixed' IP address, as much as it can be guaranteed by an operator > at a premium cost, will not be possible if moving to a more remote > area: for example, when moving from US to Europe can not maintain > that fixed IP address even if it is paid a very high price. > > Danny > With the appropriate roaming implementation, even this can > be achieved. Well, I think that can be a good goal, but I can't see it happening. The roaming concepts in telecom operators kept evolving in recent years: acquisitions of networking assets across multiple continents; regulatory bodies fix budget limits while roaming; billing agreements between certain countries exist to make look as if at home. Yet in none of these is it possible to keep same IP address while moving across large areas. Whatever amount of money one pays, one can't just make host-based routes across the globe - it equates to the price of all Internet altogether. > But, when moving to an area where no roaming partner exists, you are > correct. But this sounds to me like a business issue, not technical. I think it is technical. I think even when roaming partners exist, some things may appear as if at home, but never the IP address is the same. > Alex > >> Clearly, most mobile hosts do not require Fixed IP > > Again: _mobile hosts_ require? Or apps require? > > Danny > You are correct. Its applications, not mobile hosts... > > Alex > > > A more coherent definition can take advantage of using only app > requirements, or only mobile host reqs, or both but everywhere (i.e. > each of the 3 types of addresses relates to both MH reqs and to app > reqs). > > Danny > I agree > > Alex > >> addresses and their owners will not pay the premium cost for this >> service, but still, it is a service that mobile operators provide >> and this is enough proof for us to acknowledge its need. > > >> Please see some examples > > Thank you very much for these pointers. This makes it easier to > understand the intention. [...] > Is this IPv4 only? > > I am asking the IP version question because address configuration is > very different in IPv6 than IPv4. > > For example, in IPv6 the network does not assign an address to a > host (as in IPv4 is done with context setup), but advertises a prefix > to a link and the host forms an address. In such a context the > potential mechanism to achieve static IP addresses is very different > - not only the network is in charge but the terminal too. > > Moreover, whereas in IPv4 cellular networks the mechanism to achieve > static IP address is standardised (NAI, PDP context setup, ppp), in > IPv6 there is no such mechanism standardised nor deployed. > > Is there an example of deployed static IPv6 addresses in cellular > networks? (as the IPv4 example of AT&T, Verizon, Sprint). That > would be very relevant too. > > Danny > Well, to the best of my knowledge, IPv4 is still more > popular than IPv6 in the States. But if this service is available for > IPv4 today, I believe operators will provide it with IPv6 service > once they believe there is a business justification. We do not want > to prevent this right? Right, we dont want to prevent that. But we dont want to prevent these operators to migrate to IPv6 either, simply because IPv4 had the above cited Static IP addresses, whereas IPv6 didnt have. If the referred operators dont talk IPv6 in the first place in their web pages, then I think it is not worth talking about them here; moreover - it is not worth designing solutions satisfying some need they may (or may not) have. We are a huge distance apart. Alex From nobody Thu May 19 01:04:09 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170412D0B1 for ; Thu, 19 May 2016 01:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxRkC5UH4UqP for ; Thu, 19 May 2016 01:04:06 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id E229912B03E for ; Thu, 19 May 2016 01:04:05 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 19 May 2016 01:03:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,333,1459839600"; d="scan'208";a="957882248" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 19 May 2016 01:03:28 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 19 May 2016 01:03:11 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 19 May 2016 01:03:10 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.101]) by HASMSX105.ger.corp.intel.com ([169.254.1.109]) with mapi id 14.03.0248.002; Thu, 19 May 2016 11:03:07 +0300 From: "Moses, Danny" To: Alexandre Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] OnDemand draft: 3 address types discussion Thread-Index: AdGlNxViVeTLSORKTxOVT+qsHcWdEQEgAgmAAWOfSXAAasEiAAAr0+bQ Date: Thu, 19 May 2016 08:03:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmQ2ZTZjODYtMGIyMi00ZDgyLTgyZDEtYmI5OWJmZjA3MzA4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFkQzVQTUdhS1wvQ05COVQ5MTExbEtJVFJ3STNXTDJMeGwrZXhsS0JcL3dUbz0ifQ== x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:04:08 -0000 Hi Alex, My replies in this email are marked with 'Danny >>2'. Regards, /Danny -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] = Sent: Wednesday, May 18, 2016 16:33 To: Moses, Danny; dmm@ietf.org Subject: Re: [DMM] OnDemand draft: 3 address types discussion Danny, Thank you for the reply. I agree with most comments. I appreciate the effort you made to make a common understandable email. But we may further need to better understand each other by email. To that = end, we would need to use a common way of citing each other. There are man= y ways that each person believes is the best. But there is only one way th= at is agreed by most. Le 16/05/2016 =E0 11:58, Moses, Danny a =E9crit : > Hi Alex, > > > Thank you very much for the detailed review and comments. I have tried = > to answer them, but if I was not able to be clear enough, I will be = > happy to discuss this with you. > > I am removing parts of the previous exchange so that everyone can find = > the open questions and answers more easily. > > Regards, /Danny > > > --------------- Text removed from previous exchange----------------- > > ---------------------------------------------------------------------- > ---------- > > > > > > > > > > Alex > Yet, some questions arise: > > The apps which don't require a session-lasting IP address can = > obviously work with a session-lasting IP address too. So some of the = > session-lasting IP addresses can be non-persistent IP addresses? > > Danny > True, applications that do not require a session-lasting IP = > address can work correctly with a session-lasting IP address. But in = > that case, the network will invest resources in guaranteeing this = > without any real need and thus, these resources will be wasted. Intuitively it can appear so: more state in routers maybe needed to maintai= n routes to an IP address which moves, rather than simply changing the IP a= ddress. And that state may look more expensive. On another hand, it may be that that 'cost' is artificial in the first plac= e. Modem connections were first charged on a per-time basis - it was artif= icial; now there are flat rates. Initial 4G subscriptions plans allowed on= ly for 1Gb 'fair use' - it was artificial; now there is 50Gb 'faire use' fo= r same price as 1Gb only 2 years ago. Currently, some cellular operators only offer session-lasting IP addresses = (do not offer non-persistent IP addresses). Danny >>2 I am not sure I understood your comment here. When I referred to 'cost' I d= id not mean actual dollars. I was referring to cost of infrastructure, cost= in terms of non-optimal routes (which may translate to latency in packet a= rrival), cost of overhead (encapsulation overhead - for example) etc. Clearly, all these are saved when there is no need for session-lasting IP g= uarantee. So if the application does not need this guarantee and the networ= k supports the ability not to provide this guarantee, both sides gain. = Do you have a concern here? Am I relating to it? --------------------------------- > From the application side, its traffic may suffer from the treatment = > associated with providing session-lasting characteristics (non-optimal = > routing, encapsulation/decapsulation overhead which influences MTU, = > etc). Again, this may look so, intuitively speaking. But I beg to differ. If one looks at a cellular network from a latency perspective, one has to i= magine the radio access link as very large, and the core network as very sm= all. That means that sub-optimal routing and encap/decap overheads are ver= y small compared to the radio access. On 4G, latency between the UE and the first IP hop is in the order of 50 mi= lli-seconds, whereas the Ethernet latency (supposedly used in the wired seg= ment to the first IP hop) is in the order of 1 micro-second. So, if instead of the optimal routing 1 micro-second the non-optimal routin= g is 3 micro-seconds that is very small compared to the radio access latenc= y. That can not be considered as additional cost. Danny >>2 As I mentioned, there are various costs, not just latency. = Regarding latency, I am not sure your data will be valid in DMM deployments= with multiple mobility anchors. One of the ideas which relates to multiple= mobility anchors is to place the anchors close to the base-station (or eve= n co-located in the base-station). This has various advantages (not relevan= t to OnDemand), but also a disadvantage in terms of routing traffic after a= hand-off (since the traffic needs to flow through the original mobility an= chor. But the OnDemand draft does not mandate all future networks to support it. = We offer backwards compatibility of working with networks that provide IP a= ddress continuity regardless of the application's request. Operators who be= lieve that the cost of providing this guarantee is negligible, may decide n= ot to implement this feature. ----------------------------------------- > Still, I believe that there will be cases when this is performed. > One example is in cellular networks that automatically provide = > tunneling and do not support the ability to receive IP address type = > requests from the mobile node. Right. > But, if an application requests a session-lasting IP address, and the = > network provides one, it should treat it as such - e.g. provide IP = > continuity guarantee throughout the lifetime of the session. The = > network cannot tell if the address is 'really' using the guarantee or = > not. I can not agree that an application will require some kind of IP address. Danny >>2 I do not understand what you cannot agree to. This whole draft is about app= lications requesting specific types of IP address. So are you saying that y= ou cannot agree to the OnDemand concept? -------------------------------- > I did not understand what you mean by 'So some of the session-lasting = > IP addresses can be non-persistent IP addresses?'. > No, if the network provides a session-lasting IP address, it is = > committed to guarantee it (even if the application does not need the = > service). > > Alex > The apps which require a session-lasting IP address wish to = > introduce overhead in the network? > > Danny > Apps which require session-lasting IP addresses are apps that = > cannot recover from the event of source IP addresses becoming obsolete = > as a result of the mobile node moving to a LAN with a different IP = > prefix. This is why they request a session-lasting IP address. Not = > because they wish to introduce overhead - this is a by product... > > Alex > Mobile operators using GTP or PMIP do not provide = > non-persistent IP addresses? > > Danny > Mobile operators using GTP or PMIP provide a guarantee that = > the source IP address they allocated to a mobile node will continue to = > exist (and be valid) as long as the mobile node is connected to the = > network (or as long as the DHCP lease condition are meat - if DHCP is = > used). This even a better guarantee than what we defined by = > 'session-lasting' IP address, because the GTP/PMIP source IP address = > is guaranteed regardless of the initiation/end of IP session. I can not imagine a Mobile operator which will give an address to a mobile = that is not accepted on another access point. That is the whole point of '= Mobile' in mobile operator. Imagine - the end users will have to stay fixe= d (dont move), if they started some application. And there are many applic= ations out there unaware. Or one would have to update all existing applica= tions? This will _not_ work whenever the user wants to get in a train or car eithe= r (despite having the feeling of being fixed). Or do you consider the Mobi= le operator will equip the trains and the cars as well? Danny >>2 The draft does not say that the end user cannot be mobile. It indicates tha= t there are more and more applications that do not break when the source IP= address they are using is obsolete. They simply re-open the Socket and us= e the new source IP address. So for these types of applications, the sessio= n-lasting guarantee is redundant (even when the user is mobile). -------------------------------------------- > In our understanding, this extra guarantee is not really needed and in = > the DMM environment where they may be multiple mobility anchors might = > even introduce inefficient routing (which could be avoided in the = > newly introduced scheme). > > To the best of my knowledge, mobile operators do not provide = > non-persistent IP addresses. > > Alex> >> Basically, current implementations provide a guarantee for the = >> source IP address to be valid throughout the time the mobile host is = >> connected to the mobile network. We concluded that mobile hosts do = >> not really require such a guarantee. It is sufficient to require a = >> guarantee of the IP address availability while there is/are an IP >> session(s) using this IP address and hence the more accurate = >> definition. > > I dont understand. > > Until here the app requirements where important. Now we change to = > make the mobile host to be important(?) > > Danny > In current implementation a source IP address is allocated to = > the mobile host and is valid throughout the connection of the mobile = > host to the network. This is why I use the term 'mobile host' > in the description that you quoted. > > We are introducing an new concept - 'OnDemand' - where each time an IP = > session is created (by an application running on the host), an = > application can request a specific source IP address for that session = > (with specific type). From the network's perspective, this address was = > allocated to a mobile host. This means that at any given time, a = > mobile host might have more than one source IP address allocated to = > in, and different IP sessions initiated by that host (by different = > applications running on that host) may be used in different packets = > being sent/received by it. > > I can understand why this is confusing. If this explanation is not = > sufficient, I will be happy to discuss this point with you. Yes, please clarify whether one has to update all applications in order to = take advantage of this 'ondemand' aspect? Danny >>2 Yes. If an applications wish to request a specific type of source IP addres= s, they have to use the new flags we are specifying in the Socket interface ----------------------------- > Alex > >> Furthermore, some WG members have shown cases in DMM where it is more = >> efficient for applications to request a new Session-lasting IP = >> address when launched rather than using an existing one that was = >> allocated to the mobile host in the past. > > Well, I wonder about this. > > Danny > Well, they did not use the term 'OnDemand' specifically, but = > they did show that in a distributed mobility anchor scheme, there are = > cases where allocating a new IP address may result in a more optimal = > route of the IP flow compared with using the already-allocated IP = > address. This is because the original IP address is served by one = > mobility anchor (hence all traffic must be routed through it), and = > after the mobile host moves to a new location, traffic may possibility = > be routed via a different mobility anchor which is topologically = > better. Once again, we can further discuss this topic). > Please refer to the following IDs: > https://datatracker.ietf.org/doc/draft-bernardos-dmm-distributed-ancho > ring/ > > > > > > > https://tools.ietf.org/html/draft-seite-dmm-dma-07 > > Alex > In the environments I work I never saw an application (e.g. a > browser) to request an IP address. It is the connection manager which = > deals with address configuration. This connection manager is not in = > contact with other applications like web browsers. > > Danny > That is correct - application do not request IP addresses. > This is a new concept we are introducing. Application, through the = > Socket interface, can indicate to the TCP/IP stack, the type of source = > IP address they require. The TCP/IP stack, will ether associate an = > existing IP address with that Socket or initiate a request to the = > network for a source IP address of the desired type. It makes sense in a way: applications featuring 'ondemand' may put less app= arent strain in the network. However, we need to make sure that all existing applications continue to wo= rk as before even if they dont run 'ondemand'. Danny >>2 That is correct. The draft has a chapter on backwards compatibility. = ------------------------------------------ > > Alex > >> This is due to possible movement of the mobile host to a LAN which is = >> being served by a mobility anchor that is different from the one that = >> was used when the older Session-lasting IP address was assigned to = >> the mobile host. Fixed IP address (no renaming ...): >> We believe that this is where our original text was the most unclear = >> leading to the confusion on the mailing list and the comments from = >> the flour. > >> A Fixed IP address is guaranteed by the network to Always be valid, = >> even if the mobile host is not utilizing any IP sessions, or has been = >> disconnected from the network for some time. This is a special = >> service that mobile network operators provide for a premium charge, = >> for servers, VPNs , secured content and other applications. >> With this IP address type the network operator provide IP address = >> reachability in addition to IP session continuity, and mobile hosts = >> may register these addresses in DNS infrastructure for name = >> resolution. > > I can understand the intention of the fixed IP address definition. > > But I wonder whether there can be an improved definition of a fixed IP = > address. Because of the following: > > A 'fixed' IP address, as much as it can be guaranteed by an operator = > at a premium cost, will not be possible if moving to a more remote > area: for example, when moving from US to Europe can not maintain that = > fixed IP address even if it is paid a very high price. > > Danny > With the appropriate roaming implementation, even this can be = > achieved. Well, I think that can be a good goal, but I can't see it happening. The roaming concepts in telecom operators kept evolving in recent years: acquisitions of networking assets across multiple continents; regulatory bo= dies fix budget limits while roaming; billing agreements between certain co= untries exist to make look as if at home. Yet in none of these is it possi= ble to keep same IP address while moving across large areas. Whatever amount of money one pays, one can't just make host-based routes ac= ross the globe - it equates to the price of all Internet altogether. > But, when moving to an area where no roaming partner exists, you are = > correct. But this sounds to me like a business issue, not technical. I think it is technical. I think even when roaming partners exist, some things may appear as if at h= ome, but never the IP address is the same. Danny >>2 OK. Let's agree to disagree on whether or not Fixed IP addresses can be sup= ported in roaming scenarios. Does that impact the whole concept? I do not think so... -------------------------------------------- > Alex > >> Clearly, most mobile hosts do not require Fixed IP > > Again: _mobile hosts_ require? Or apps require? > > Danny > You are correct. Its applications, not mobile hosts... > > Alex > > > A more coherent definition can take advantage of using only app = > requirements, or only mobile host reqs, or both but everywhere (i.e. > each of the 3 types of addresses relates to both MH reqs and to app = > reqs). > > Danny > I agree > > Alex > >> addresses and their owners will not pay the premium cost for this = >> service, but still, it is a service that mobile operators provide and = >> this is enough proof for us to acknowledge its need. > > >> Please see some examples > > Thank you very much for these pointers. This makes it easier to = > understand the intention. [...] > Is this IPv4 only? > > I am asking the IP version question because address configuration is = > very different in IPv6 than IPv4. > > For example, in IPv6 the network does not assign an address to a host = > (as in IPv4 is done with context setup), but advertises a prefix to a = > link and the host forms an address. In such a context the potential = > mechanism to achieve static IP addresses is very different > - not only the network is in charge but the terminal too. > > Moreover, whereas in IPv4 cellular networks the mechanism to achieve = > static IP address is standardised (NAI, PDP context setup, ppp), in > IPv6 there is no such mechanism standardised nor deployed. > > Is there an example of deployed static IPv6 addresses in cellular = > networks? (as the IPv4 example of AT&T, Verizon, Sprint). That would = > be very relevant too. > > Danny > Well, to the best of my knowledge, IPv4 is still more popular = > than IPv6 in the States. But if this service is available for > IPv4 today, I believe operators will provide it with IPv6 service once = > they believe there is a business justification. We do not want to = > prevent this right? Right, we dont want to prevent that. But we dont want to prevent these operators to migrate to IPv6 either, simp= ly because IPv4 had the above cited Static IP addresses, whereas IPv6 didnt have. If the referred operators dont talk IPv6 in the first place in their web pa= ges, then I think it is not worth talking about them here; moreover - it is= not worth designing solutions satisfying some need they may (or may not) h= ave. We are a huge distance apart. Alex --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Thu May 19 01:33:34 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F0E12D0CA for ; Thu, 19 May 2016 01:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHApiL4z_qWz for ; Thu, 19 May 2016 01:33:31 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002DB12B05D for ; Thu, 19 May 2016 01:33:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u4J8XTmY026480; Thu, 19 May 2016 10:33:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 474AA200EC1; Thu, 19 May 2016 10:33:31 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3ACB4206909; Thu, 19 May 2016 10:33:31 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u4J8XScn011500; Thu, 19 May 2016 10:33:28 +0200 To: "Moses, Danny" , "dmm@ietf.org" References: From: Alexandre Petrescu Message-ID: Date: Thu, 19 May 2016 10:33:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:33:33 -0000 [...] > Danny >>2 I am not sure I understood your comment here. When I > referred to 'cost' I did not mean actual dollars. I was referring to > cost of infrastructure, cost in terms of non-optimal routes (which > may translate to latency in packet arrival), cost of overhead > (encapsulation overhead - for example) etc. Hi Danny, These costs - infra, non-optimal routes, latency in packet arrival - are two: memory-CPU costs in the infra, and latency costs. The memory and CPU cost in the infra, induced by triangular routing, can be characterized by the memory size and CPU cycles. In triangular routing there is one more entry in the routing tables in memory at a 3rd point (instead of just at 2 points). The CPU cycles - I dont know. How much is it? The latency cost: again, as I explained previously - it is negligible - it is 3 micro-seconds in triangular routing (compared to 2 micro-seconds w/o triangular routing), when the UE experiences a first hop of 50ms. The encap/decap costs: there is memory, CPU and on-the wire costs. What is the mem-CPU cost? On the wire cost of encap/decap is very low: encap/decap is about 40bytes of additional header compared to 1200bytes which is the minimal MTU of IPv6. > Clearly, all these are saved when there is no need for > session-lasting IP guarantee. YEs, but is it worth the effort? Or is it just like in flat-rate and 'fair use' concepts where we should not worry about the cost, but worry about the growth. > So if the application does not need this guarantee and the network > supports the ability not to provide this guarantee, both sides gain. If we worry about these costs - then yes. > Do you have a concern here? Am I relating to it? YEs, the concern is how much do we gain by modifying the network too _not_ provide the currently provided stable addresses? [...] > Danny >>2 As I mentioned, there are various costs, not just latency. > Regarding latency, I am not sure your data will be valid in DMM > deployments with multiple mobility anchors. One of the ideas which > relates to multiple mobility anchors is to place the anchors close to > the base-station (or even co-located in the base-station). This has > various advantages (not relevant to OnDemand), but also a > disadvantage in terms of routing traffic after a hand-off (since the > traffic needs to flow through the original mobility anchor. I dont understand: if we place a mobility anchor closer to the base station, the traffic after hand-off will no longer flow through the original mobility anchor, right? > But the OnDemand draft does not mandate all future networks to > support it. We offer backwards compatibility of working with networks > that provide IP address continuity regardless of the application's > request. Operators who believe that the cost of providing this > guarantee is negligible, may decide not to implement this feature. A-ha, but it's not related to our discussion. [...] > I can not agree that an application will require some kind of IP > address. > > > Danny >>2 I do not understand what you cannot agree to. This whole > draft is about applications requesting specific types of IP address. > So are you saying that you cannot agree to the OnDemand concept? If the OnDemand concept could be applied to specific connectivity managers - then I could agree with the concept. I dont agree that any other application needs to require some particular kind of application. The existing base is that of applications which consider that address to be stable and fixed. This is the default and should continue. Improved applications may develop a relationship with a new Connectivity Manager which may in turn request address kinds. [...] > Danny >>2 The draft does not say that the end user cannot be mobile. > It indicates that there are more and more applications that do not > break when the source IP address they are using is obsolete. They > simply re-open the Socket and use the new source IP address. So for > these types of applications, the session-lasting guarantee is > redundant (even when the user is mobile). When you say "more and more applications" do you mean smartphone applications? In my setting, we dont consider smartphones, but multiple bigger computers connected to a cellular link through a Mobile Router. Such computers run different kinds of apps than the typical *-store-based apps. [...] > Danny >>2 OK. Let's agree to disagree on whether or not Fixed IP > addresses can be supported in roaming scenarios. Does that impact the > whole concept? I do not think so... Right, it doesnt impact the whole concept. It just modifies it: on a large scale, it's impossible to provide a fixed IP address - as such dont request one if it's on a large scale. Alex > -------------------------------------------- > >> Alex > >>> Clearly, most mobile hosts do not require Fixed IP >> >> Again: _mobile hosts_ require? Or apps require? >> >> Danny > You are correct. Its applications, not mobile hosts... >> >> Alex > >> >> A more coherent definition can take advantage of using only app >> requirements, or only mobile host reqs, or both but everywhere >> (i.e. each of the 3 types of addresses relates to both MH reqs and >> to app reqs). >> >> Danny > I agree >> >> Alex > >>> addresses and their owners will not pay the premium cost for this >>> service, but still, it is a service that mobile operators provide >>> and this is enough proof for us to acknowledge its need. >> >> >>> Please see some examples >> >> Thank you very much for these pointers. This makes it easier to >> understand the intention. > > [...] > >> Is this IPv4 only? >> >> I am asking the IP version question because address configuration >> is very different in IPv6 than IPv4. >> >> For example, in IPv6 the network does not assign an address to a >> host (as in IPv4 is done with context setup), but advertises a >> prefix to a link and the host forms an address. In such a context >> the potential mechanism to achieve static IP addresses is very >> different - not only the network is in charge but the terminal >> too. >> >> Moreover, whereas in IPv4 cellular networks the mechanism to >> achieve static IP address is standardised (NAI, PDP context setup, >> ppp), in IPv6 there is no such mechanism standardised nor >> deployed. >> >> Is there an example of deployed static IPv6 addresses in cellular >> networks? (as the IPv4 example of AT&T, Verizon, Sprint). That >> would be very relevant too. >> >> Danny > Well, to the best of my knowledge, IPv4 is still more >> popular than IPv6 in the States. But if this service is available >> for IPv4 today, I believe operators will provide it with IPv6 >> service once they believe there is a business justification. We do >> not want to prevent this right? > > Right, we dont want to prevent that. > > But we dont want to prevent these operators to migrate to IPv6 > either, simply because IPv4 had the above cited Static IP addresses, > whereas IPv6 didnt have. > > If the referred operators dont talk IPv6 in the first place in their > web pages, then I think it is not worth talking about them here; > moreover - it is not worth designing solutions satisfying some need > they may (or may not) have. We are a huge distance apart. > > Alex > --------------------------------------------------------------------- > > > > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material > for the sole use of the intended recipient(s). Any review or > distribution by others is strictly prohibited. If you are not the > intended recipient, please contact the sender and delete all copies. > > From nobody Fri May 20 16:02:57 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5012D66A for ; Fri, 20 May 2016 16:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLJ_atylQOTA for ; Fri, 20 May 2016 16:02:49 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BBC12D669 for ; Fri, 20 May 2016 16:02:48 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id tb2so26530226pac.2 for ; Fri, 20 May 2016 16:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:reply-to:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=b4iHS0mySsMzuZ+nvoZCnJrZpTXCENLeOL0yBViXlxILXBFaGWeMmieQs96XR4UEao o6NKFWR1ttFi6smtnBw4XzG5g7kgpHgU3ocYZZX3gPd/3WmJWKmaVFXKQhMvdlQGibKv iwpPyF5c8zMsbpgeJ/PNmqN2uf3yDSmtPgvwDtIf/gh1HjoKIvjj6Thlvp+bxmO7mOCz CU5KOwyb3yXldguK+Rio6avR2yCW3K/V7ins21oh3MZ5ogKD424B1VHwM7sIdKHQHX06 yNpyVkoTngh4pkRLBtNi8wTlDULdTEtmHDeV1LHJ1nID70KEhdtoCAOMWQk8SnGwW0Bi tMFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:reply-to:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=ORMMyu10varLG6hRQFutNScRHfPK/VXm/tdol8agWiwddKoP0Zf3gsjmm477AEKaaW ugcUSSxkthA8CzI9fGhlKAadHbvgm8M3mGESA13KXmBkS9roue29sjc1QKX2q2NTYGrC YA/8fSWbHurU1rG0nuFnFkc7smRCj3m8dH8NMr9aXidSf9O3TTfG5F0UGxuS4uOJlV1D na2oLKYw1IkjzaHmuEZWU1m9/rP6FXWxCemc10dGRn+F74e7CC7aWut8rCB4USEo1vnI uDpx6D3Wf3pt6NczOntTSj3GYsMPnHNvzWsjLBDQBnZtvegIaFVRZlsQHXprb5ZGbXaO k+/A== X-Gm-Message-State: AOPr4FWJFT9846egEcf0O4xDtRxjMbMixngS1EjuRAny7NYBhdDp3gv0fIpqbyMFCVeNjw== X-Received: by 10.66.159.102 with SMTP id xb6mr8398097pab.73.1463785368257; Fri, 20 May 2016 16:02:48 -0700 (PDT) Received: from [10.16.75.74] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id n6sm29532218pfa.2.2016.05.20.16.02.47 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 16:02:47 -0700 (PDT) References: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> To: "dmm@ietf.org" From: Jouni Korhonen X-Forwarded-Message-Id: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> Message-ID: <48031bd8-0fe8-c940-adbf-6168fd46525a@gmail.com> Date: Fri, 20 May 2016 16:02:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [DMM] Fwd: NomCom 2016-2017 Call for Volunteers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 23:02:56 -0000 FYI -------- Välitetty viesti / Fwd.Msg -------- Aihe: NomCom 2016-2017 Call for Volunteers Päiväys: Thu, 19 May 2016 12:03:42 -0700 Lähettäjä: NomCom Chair 2016 Vastausosoite: ietf@ietf.org Vastaanottaja: IETF Announcement List Subject: NomCom 2016-2017 Call for Volunteers The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF = 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as a candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. Some 229 people have already volunteered by ticking the box on the IETF 95 registration form. 131 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Lou Berger IAB: Ralph Droms Russ Housley Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC) Joel Jaeggli (OPS) Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (with the exception of GEN) have at least one continuing AD. The primary activity for this nomcom will begin in July 2016 and should be completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a nomcom member does require some time commitment it is also a very rewarding experience. As a member of the nomcom it is very important that you be able to attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, as follows: To: nomcom-chair-2016@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Lucy Lynch llynch@civil-tongue.net nomcom-chair-2016@ietf.org From nobody Fri May 20 18:52:16 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3A12D0F5; Fri, 20 May 2016 18:52:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160521015212.4829.24239.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 18:52:12 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-hnprenum-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 01:52:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : Home Network Prefix Renumbering in PMIPv6 Authors : Zhiwei Yan Jong-Hyouk Lee Xiaodong Lee Filename : draft-ietf-dmm-hnprenum-01.txt Pages : 8 Date : 2016-05-20 Abstract: In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its initial attachment for the Home Address (HoA) configuration. During the movement of the MN, this prefix remains unchanged and in this way it is unnecessary for the MN to reconfigure its HoA and reconnect the ongoing communications. However, the current protocol [RFC5213] does not specify related operations to support the MN to timely receive and use a new HNP when the allocated HNP changes. In this draft, a solution to support the HNP renumbering is proposed, as an update of [RFC5213]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-hnprenum-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 19:23:12 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2312D0BE; Fri, 20 May 2016 19:23:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160521022310.4879.16956.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 19:23:10 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-hnprenum-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 02:23:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : Home Network Prefix Renumbering in PMIPv6 Authors : Zhiwei Yan Jong-Hyouk Lee Xiaodong Lee Filename : draft-ietf-dmm-hnprenum-02.txt Pages : 8 Date : 2016-05-20 Abstract: In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its initial attachment for the Home Address (HoA) configuration. During the movement of the MN, this prefix remains unchanged and in this way it is unnecessary for the MN to reconfigure its HoA and reconnect the ongoing communications. However, the current PMIPv6 specification does not specify related operations to support the MN to timely receive and use a new HNP when the allocated HNP changes. In this draft, a solution to support the HNP renumbering is proposed, as an update of the PMIPv6 specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-hnprenum-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 21:20:43 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E012D536 for ; Fri, 20 May 2016 21:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY3GBt0ZBCuS for ; Fri, 20 May 2016 21:20:40 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BF712B05A for ; Fri, 20 May 2016 21:20:40 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id y69so47030198pfb.1 for ; Fri, 20 May 2016 21:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=Tg1DYjIVM0KSa/xzcsBK51G8Jw7594zanBiEvHfXecM=; b=jpF38fWn1PjXLrJToUwdutlZQ5ZNCVsYKp6VnB6XhEhwFNFiD57Ofh1GarvtFk0ftM Z3HXc/Ylm5vv/u84upFbDkizxqC+M/NExkDkZ/n7hS8L7k3OAGYyRmxsd3XMcMpH+MLf db0z3wILAKAaB/1cnnE7XpUN2CSFc5aiU3tyU0bePziPSA9PKfwJJkhR+cGvmu3K5jU/ PN37njD56P+5edsQ/4xB567gmek+RKBk8dH4K5T/N2BZbpHAFFhbCl6JGjzTQwqgsWPN 0dodZ/lCCxkS9aoT5Z3xoiV/nnKHygoJfs3awSRSFHc8SBlFhNXFKrHqew2gvYimZrUB 4KeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=Tg1DYjIVM0KSa/xzcsBK51G8Jw7594zanBiEvHfXecM=; b=LWMQleWZcyPTEZ4/kZrCtNrVSutWyonrVItSV/LvDAvBFSreG7gNRt39YsOoViYMyg sO0BCWQ4aP0plbVMRkrZj30DSgDhfjLApS3xVmYj/DRq/yar3a0Y8taogPNSPjpgIzXt Pa+6xI44aEzCyt4J14ImORNdXVD2MlVqmNMDwpj6k2vDYBa8rr3txm9a4W90ShdP8XSo I11FMnasORfBQMFh5ebybPe12Au8qSOXIdB4Kox/Pc+siTZYkmVNiVWg4L0T/EgdWbon bKPzwq6r0Zz+49EWiR+VXRazPxv41JQotXEyj8dHsdSIso/9t42Fpsu2MrZKis4vLVPb xExw== X-Gm-Message-State: AOPr4FWFre/FHdXZG5SHZSpwNOQNotKER2iuT56CpMrNxQOG6b1XcjzqFcBZrpMupvjZ/A== X-Received: by 10.98.95.4 with SMTP id t4mr10071411pfb.162.1463804439842; Fri, 20 May 2016 21:20:39 -0700 (PDT) Received: from ?IPv6:2601:b00:c580:31d0:4d4c:905:31c5:8085? ([2601:b00:c580:31d0:4d4c:905:31c5:8085]) by smtp.gmail.com with ESMTPSA id eh9sm30512341pad.47.2016.05.20.21.20.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 May 2016 21:20:39 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2016 21:20:34 -0700 Message-Id: <2838572A-2ED1-469A-9CBF-BA440DB4F0D2@gmail.com> To: dmm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: =?utf-8?B?IuWImOWkp+m5jyjpuY/miJApIg==?= Subject: [DMM] WGLC #1 for draft-ietf-dmm-hnprenum-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 04:20:42 -0000 Folks, This email starts the WGLC #1 for draft-ietf-dmm-hnprenum-02. Post your = comment to the mailing list and also add your issues/correction = requests/concerns etc into the Issue Tracker. WGLC #1 Starts: 5/20/2016 WGLC #1 Ends: 6/3/2016 EOB PDT Regards, Jouni & Dapeng= From nobody Mon May 23 02:50:23 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B0E12D508 for ; Mon, 23 May 2016 02:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIsnfaqeWz_W for ; Mon, 23 May 2016 02:50:20 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8972E12B05B for ; Mon, 23 May 2016 02:50:20 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 23 May 2016 02:50:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,354,1459839600"; d="scan'208";a="812764847" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga003.jf.intel.com with ESMTP; 23 May 2016 02:50:19 -0700 Received: from fmsmsx122.amr.corp.intel.com (10.18.125.37) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 23 May 2016 02:50:19 -0700 Received: from lcsmsx152.ger.corp.intel.com (10.186.165.231) by fmsmsx122.amr.corp.intel.com (10.18.125.37) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 23 May 2016 02:50:18 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.101]) by LCSMSX152.ger.corp.intel.com ([169.254.4.110]) with mapi id 14.03.0248.002; Mon, 23 May 2016 12:50:16 +0300 From: "Moses, Danny" To: Alexandre Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] OnDemand draft: 3 address types discussion Thread-Index: AdGlNxViVeTLSORKTxOVT+qsHcWdEQEgAgmAAWOfSXAAasEiAAAr0+bQ///gEQD/+YISIA== Date: Mon, 23 May 2016 09:50:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGQ3ZGY5YTktMjg5Yi00MTBhLWJjMzEtYTViZjY4ZDc2YTBkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFtbnJ6M3AwbnM5aHdYRFJ6cHJma3pNdWN1eElDSGRBVkJzODlPeElHWDg9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] OnDemand draft: 3 address types discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 09:50:22 -0000 Hi, My newest answers are marked: Danny>>3 Regards, /Danny -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] = Sent: Thursday, May 19, 2016 11:33 To: Moses, Danny; dmm@ietf.org Subject: Re: [DMM] OnDemand draft: 3 address types discussion [...] > Danny >>2 I am not sure I understood your comment here. When I = > referred to 'cost' I did not mean actual dollars. I was referring to = > cost of infrastructure, cost in terms of non-optimal routes (which may = > translate to latency in packet arrival), cost of overhead = > (encapsulation overhead - for example) etc. Hi Danny, These costs - infra, non-optimal routes, latency in packet arrival - are two: memory-CPU costs in the infra, and latency costs. The memory and CPU cost in the infra, induced by triangular routing, can be= characterized by the memory size and CPU cycles. In triangular routing th= ere is one more entry in the routing tables in memory at a 3rd point (inste= ad of just at 2 points). The CPU cycles - I dont know. How much is it? The latency cost: again, as I explained previously - it is negligible - it = is 3 micro-seconds in triangular routing (compared to 2 micro-seconds w/o t= riangular routing), when the UE experiences a first hop of 50ms. The encap/decap costs: there is memory, CPU and on-the wire costs. What is= the mem-CPU cost? On the wire cost of encap/decap is very low: encap/decap is about 40bytes o= f additional header compared to 1200bytes which is the minimal MTU of IPv6. > Clearly, all these are saved when there is no need for session-lasting = > IP guarantee. YEs, but is it worth the effort? Or is it just like in flat-rate and 'fair= use' concepts where we should not worry about the cost, but worry about th= e growth. > So if the application does not need this guarantee and the network = > supports the ability not to provide this guarantee, both sides gain. If we worry about these costs - then yes. > Do you have a concern here? Am I relating to it? YEs, the concern is how much do we gain by modifying the network too _not_ = provide the currently provided stable addresses? Danny>>3 Well, you are showing some costs, but I am not sure you covered all of them= . Nevertheless, there are quite a few people that think that the investment= is worth the savings in latency, CPU and memory, especially with the incre= asing demands for resource in the future 5G installations. Our intent is to= prepare the future access networks for the growing demand not just by incr= easing the pure bandwidth of the wire (or wireless medium), but also by imp= roving other aspects (as described). Clearly, there will never be consensus as to the appropriate features and w= e do not expect all operators to support them at once. But, unless better a= nd competing ideas are introduced, we think they will gradually be used. Re= member, even IPv4 is still very common, although IPv6 has been released age= s ago. -------------------------------------- [...] > Danny >>2 As I mentioned, there are various costs, not just latency. > Regarding latency, I am not sure your data will be valid in DMM = > deployments with multiple mobility anchors. One of the ideas which = > relates to multiple mobility anchors is to place the anchors close to = > the base-station (or even co-located in the base-station). This has = > various advantages (not relevant to OnDemand), but also a disadvantage = > in terms of routing traffic after a hand-off (since the traffic needs = > to flow through the original mobility anchor. I dont understand: if we place a mobility anchor closer to the base station= , the traffic after hand-off will no longer flow through the original mobil= ity anchor, right? Danny>>3 This is not correct. Packets generated by the Sockets that were opened befo= re the hand-off must be routed through the original mobility anchor (hence = the triangular routing you mentioned previously. Packets generated by Sock= ets opened after the hand-off will be routed via the new mobility anchor (i= f the mobile host is triggered to request a new session-lasting IP address = after the hand-off). = ---------------------------------------------------- > But the OnDemand draft does not mandate all future networks to support = > it. We offer backwards compatibility of working with networks that = > provide IP address continuity regardless of the application's request. = > Operators who believe that the cost of providing this guarantee is = > negligible, may decide not to implement this feature. A-ha, but it's not related to our discussion. [...] > I can not agree that an application will require some kind of IP = > address. > > > Danny >>2 I do not understand what you cannot agree to. This whole = > draft is about applications requesting specific types of IP address. > So are you saying that you cannot agree to the OnDemand concept? If the OnDemand concept could be applied to specific connectivity managers = - then I could agree with the concept. I dont agree that any other application needs to require some particular ki= nd of application. The existing base is that of applications which consider that address to be= stable and fixed. This is the default and should continue. Improved applications may develop a relationship with a new Connectivity Ma= nager which may in turn request address kinds. Danny>>3 The 'mobility manager' is not well defined so It is difficult for me to rel= ated to it. The 'OnDemand' concept assumes that - (a) not all applications require the = session-lasting service and (b) the 'demand' is performed through the Socke= t interface which is and interface for application. So, yes, we count of applications to request the IP address type. Applicati= ons are the only entity who knows if it requires session-lasting IP address= es or can handle source IP address changes without breaking. I did not understand what you do not agree to. You might have a typo in tha= t sentence. -------------------------------------- [...] > Danny >>2 The draft does not say that the end user cannot be mobile. > It indicates that there are more and more applications that do not = > break when the source IP address they are using is obsolete. They = > simply re-open the Socket and use the new source IP address. So for = > these types of applications, the session-lasting guarantee is = > redundant (even when the user is mobile). When you say "more and more applications" do you mean smartphone applicatio= ns? Danny>>3 Coould be smartphone applications but also others. For example, any applica= tion that performs short data exchanges in long periods of time, could reco= ver from a source IP address change without breaking. --------------------------- In my setting, we dont consider smartphones, but multiple bigger computers = connected to a cellular link through a Mobile Router. Such computers run d= ifferent kinds of apps than the typical *-store-based apps. [...] > Danny >>2 OK. Let's agree to disagree on whether or not Fixed IP = > addresses can be supported in roaming scenarios. Does that impact the = > whole concept? I do not think so... Right, it doesnt impact the whole concept. It just modifies it: on a large= scale, it's impossible to provide a fixed IP address - as such dont reques= t one if it's on a large scale. Alex > -------------------------------------------- > >> Alex > >>> Clearly, most mobile hosts do not require Fixed IP >> >> Again: _mobile hosts_ require? Or apps require? >> >> Danny > You are correct. Its applications, not mobile hosts... >> >> Alex > >> >> A more coherent definition can take advantage of using only app = >> requirements, or only mobile host reqs, or both but everywhere (i.e. = >> each of the 3 types of addresses relates to both MH reqs and to app = >> reqs). >> >> Danny > I agree >> >> Alex > >>> addresses and their owners will not pay the premium cost for this = >>> service, but still, it is a service that mobile operators provide = >>> and this is enough proof for us to acknowledge its need. >> >> >>> Please see some examples >> >> Thank you very much for these pointers. This makes it easier to = >> understand the intention. > > [...] > >> Is this IPv4 only? >> >> I am asking the IP version question because address configuration is = >> very different in IPv6 than IPv4. >> >> For example, in IPv6 the network does not assign an address to a host = >> (as in IPv4 is done with context setup), but advertises a prefix to a = >> link and the host forms an address. In such a context the potential = >> mechanism to achieve static IP addresses is very different - not only = >> the network is in charge but the terminal too. >> >> Moreover, whereas in IPv4 cellular networks the mechanism to achieve = >> static IP address is standardised (NAI, PDP context setup, ppp), in = >> IPv6 there is no such mechanism standardised nor deployed. >> >> Is there an example of deployed static IPv6 addresses in cellular = >> networks? (as the IPv4 example of AT&T, Verizon, Sprint). That would = >> be very relevant too. >> >> Danny > Well, to the best of my knowledge, IPv4 is still more popular = >> than IPv6 in the States. But if this service is available for IPv4 = >> today, I believe operators will provide it with IPv6 service once = >> they believe there is a business justification. We do not want to = >> prevent this right? > > Right, we dont want to prevent that. > > But we dont want to prevent these operators to migrate to IPv6 either, = > simply because IPv4 had the above cited Static IP addresses, whereas = > IPv6 didnt have. > > If the referred operators dont talk IPv6 in the first place in their = > web pages, then I think it is not worth talking about them here; = > moreover - it is not worth designing solutions satisfying some need = > they may (or may not) have. We are a huge distance apart. > > Alex > --------------------------------------------------------------------- > > > > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for = > the sole use of the intended recipient(s). Any review or distribution = > by others is strictly prohibited. If you are not the intended = > recipient, please contact the sender and delete all copies. > > --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Mon May 23 09:29:58 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9912D9EE; Mon, 23 May 2016 09:29:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523162956.20971.50862.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:29:56 -0700 Archived-At: Cc: dmm-chairs@ietf.org, dmm@ietf.org, jounikor@gmail.com Subject: [DMM] dmm - New Meeting Session Request for IETF 96 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:29:57 -0000 A new meeting session request has just been submitted by Jouni Korhonen, a Chair of the dmm working group. --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Jouni Korhonen Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dime detnet Second Priority: 6man v6ops Special Requests: --------------------------------------------------------- From nobody Mon May 23 10:17:23 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184C212D0CC for ; Mon, 23 May 2016 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52f6j9udtdY3 for ; Mon, 23 May 2016 10:17:20 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D6B12D123 for ; Mon, 23 May 2016 10:17:19 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id xk12so64230374pac.0 for ; Mon, 23 May 2016 10:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=+pDsy9Q0e6s+9WtT5VfhFFLIq/CPY+/1I6s+TgetTv4=; b=wFCSwZGpZqiw2BzRrSp/J+yGvCBFBNjOLO87L6YtTLXg8ZshP7+6YcNdmylrWbSJem PaCOpZCcTj0iq6CELs0HF9qhyiX5hjsZ3Xl+42w7t7n5T+WIFqUkbAHNY+Lh7CvjAkNj K9RvbA7GiVreji0j00ianB9IZo8HGuqpBw24CsP3fVLm+pMdLGKnLflGK+B8QwyDGk/K znok3n3eD0oan6M0CSTYYrvTpaD+lvQau8XHPGlSPAGe679dg/INALvqsqhCdIJ2jp1V /GZW6mx6Z4uaIsEu9ptuv79LSaXSfgQcYQKcAmKVC0GwzlnxLvYAexoYexAc0Ep+ACyD 45NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=+pDsy9Q0e6s+9WtT5VfhFFLIq/CPY+/1I6s+TgetTv4=; b=FkX9zmbjbZ7nh8lzeYjqxpHhRg9tITSTS41MUzkY1CUpvejorFXy6KDcaiH8zDROSf oWJbETEYVKzFCvFX678DeNAY4/ifvFyI6aKcG/8HMaP3gpPW9mll0NHHAPgkyoLLqfJ+ f5isujBwbRBZrOPwNKEKhUxmFBdGttijzNhk1/m8y4ih5jZcEc3U/qFMqWdddmlSq7ot MzoeLvtdkL7LuKtcv7gB4k0cjbZuBe0H1/YEAuo7X16gKXpyTOeGnsr2yoiDY3K5HOjV VJvOOFJjKjc1RQum3hxckGFjnwVFnpDYfIRGgdYKV9fVkz1xVGdFO1meZbaofS7tWZ18 E/TQ== X-Gm-Message-State: AOPr4FVkOwrTUn1lkTPEcbDZSLAKyHdMk/eHXgZj0b1Ha5wfLfh+02pKse6UVxVDf521+g== X-Received: by 10.66.26.16 with SMTP id h16mr29017584pag.154.1464023839344; Mon, 23 May 2016 10:17:19 -0700 (PDT) Received: from [10.57.11.140] ([166.170.41.75]) by smtp.gmail.com with ESMTPSA id l123sm48062192pfl.36.2016.05.23.10.17.18 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 10:17:18 -0700 (PDT) From: "Jouni.nosmap" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> Date: Mon, 23 May 2016 10:17:17 -0700 To: dmm@ietf.org X-Mailer: iPhone Mail (13E238) Archived-At: Subject: [DMM] WGLC reminder X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:17:21 -0000 Folks, Friendly nudge to do reviews on drafts we got now in WGLC. Jouni Sent from a smart phone.. Mind the typos.. From nobody Tue May 24 03:06:44 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7412D65C for ; Tue, 24 May 2016 03:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S38RRz2YYd1M for ; Tue, 24 May 2016 03:06:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A520D12D650 for ; Tue, 24 May 2016 03:06:41 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id C5A641806CD; Tue, 24 May 2016 12:06:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 9DE2D20057; Tue, 24 May 2016 12:06:39 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Tue, 24 May 2016 12:06:39 +0200 From: To: Jouni.nosmap , "dmm@ietf.org" Thread-Topic: [DMM] WGLC reminder Thread-Index: AQHRtRb6tc5nmVBEKkqYPeZ+w1+Pkp/H0UqA Date: Tue, 24 May 2016 10:06:39 +0000 Message-ID: <15992_1464084399_574427AF_15992_1560_1_81C77F07008CA24F9783A98CFD706F71161B878B@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> In-Reply-To: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] WGLC reminder X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 10:06:43 -0000 Hi, I've read draft-ietf-dmm-hnprenum and I think this draft can move forward. I've just couple of comments/questions What do you mean by _uplink_ ISP? s/ which detected the attachment/ which detects the attachment/ "[sic.] a scheme is also needed for the LMA to immediately initiate the PMI= Pv6 binding state refreshment.[snip] The related solution has not been spec= ified. " . But, binding states are updated during renumbering process (depi= cted on fig. 1), right? "allocate a new address within the new HNP with a DHCP message" Do you mean= DHCPv6 reconfiguration message? Pierrick > -----Message d'origine----- > De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Jouni.nosmap > Envoy=E9=A0: lundi 23 mai 2016 19:17 > =C0=A0: dmm@ietf.org > Objet=A0: [DMM] WGLC reminder >=20 > Folks, >=20 > Friendly nudge to do reviews on drafts we got now in WGLC. >=20 > Jouni >=20 > Sent from a smart phone.. Mind the typos.. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue May 24 18:23:57 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0075012D5E8 for ; Tue, 24 May 2016 18:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVXh7ExPg9wv for ; Tue, 24 May 2016 18:23:53 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0534012D5E3 for ; Tue, 24 May 2016 18:23:52 -0700 (PDT) Received: from yanzhiwei (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoEyo_kRXgtrUCQ--.46804S2; Wed, 25 May 2016 09:23:52 +0800 (CST) Date: Wed, 25 May 2016 09:23:47 +0800 From: "=?utf-8?B?Wi5XLiBZYW4=?=" To: "=?utf-8?B?cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbQ==?=" , "=?utf-8?B?Sm91bmkubm9zbWFw?=" , "=?utf-8?B?ZG1tQGlldGYub3Jn?=" References: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> Message-ID: <201605250923468010774@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon656841264841_=====" X-CM-TRANSID: AQAAf0CZoEyo_kRXgtrUCQ--.46804S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJFy3XFW5KF1kAFy7uF4fuFg_yoW5Cw48p3 yUKr17Cr1UJryUA34ku34UJry8ur4rGrW7Jr15tr1UAa45WF1qvryagw1YvayDCrn5J34j qrWj9ry7Gw10vrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvFb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E 42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72 CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wCY 02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c 02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_ JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAF wI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvj xU7ZjjDUUUU X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: Re: [DMM] =?utf-8?q?WGLC_reminder?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 01:23:57 -0000 This is a multi-part message in MIME format. --=====003_Dragon656841264841_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFBpZXJyaWNrLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBteSBp bmxpbmUgZmVlZGJhY2sNCg0KDQoyMDE2LTA1LTI1IA0KDQoNCg0KWi5XLiBZYW4gDQoNCg0KDQrl j5Hku7bkurrvvJogcGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbSANCuWPkemAgeaXtumXtO+8miAy MDE2LTA1LTI0ICAxODowNjo1NyANCuaUtuS7tuS6uu+8miBKb3VuaS5ub3NtYXA7IGRtbUBpZXRm Lm9yZyANCuaKhOmAge+8miANCuS4u+mimO+8miBSZTogW0RNTV0gV0dMQyByZW1pbmRlciANCiAN CkhpLA0KSSd2ZSByZWFkIGRyYWZ0LWlldGYtZG1tLWhucHJlbnVtIGFuZCBJIHRoaW5rIHRoaXMg ZHJhZnQgY2FuIG1vdmUgZm9yd2FyZC4NCkkndmUganVzdCBjb3VwbGUgb2YgY29tbWVudHMvcXVl c3Rpb25zDQpXaGF0IGRvIHlvdSBtZWFuIGJ5IF91cGxpbmtfIElTUD8NCg0KWWFuOiBJIHVzZSAi dXBsaW5rIElTUCIgaW4gdGhlIGRyYWZ0IHRvIGRlbm90ZSB0aGUgSVNQIHdoaWNoIGFsbG9jYXRl cyB0aGUgSE5QIHNldCB0byB0aGUgUE1JUHY2IHNlcnZpY2UgcHJvdmlkZXIuIA0KVGhpcyBpcyBj b25mdXNlZCBhbmQgSSB3aWxsIHJldmlzZSB0aGlzIGRlc2NyaXB0aW9uIG1heWJlIGFzIGZvbGxv d2luZzoNCiJ0aGUgSE5QIHNldCB1c2VkIGJ5IGEgUE1JUHY2IHNlcnZpY2UgcHJvdmlkZXIgaXMg YXNzaWduZWQgYnkgYSBkaWZmZXJlbnQgSW50ZXJuZXQgU2VydmljZSBQcm92aWRlciAoSVNQKSAi DQoNCg0Kcy8gd2hpY2ggZGV0ZWN0ZWQgdGhlIGF0dGFjaG1lbnQvIHdoaWNoIGRldGVjdHMgdGhl IGF0dGFjaG1lbnQvDQoNCllhbjogIndoaWNoIGRldGVjdGVkIHRoZSBhdHRhY2htZW50IiBzaG91 bGQgYmUgIndoaWNoIGRldGVjdHMgdGhlIGF0dGFjaG1lbnQiIA0KDQoiW3NpYy5dIGEgc2NoZW1l IGlzIGFsc28gbmVlZGVkIGZvciB0aGUgTE1BIHRvIGltbWVkaWF0ZWx5IGluaXRpYXRlIHRoZSBQ TUlQdjYgYmluZGluZyBzdGF0ZSByZWZyZXNobWVudC5bc25pcF0gVGhlIHJlbGF0ZWQgc29sdXRp b24gaGFzIG5vdCBiZWVuIHNwZWNpZmllZC4gIiAuIEJ1dCwgYmluZGluZyBzdGF0ZXMgYXJlIHVw ZGF0ZWQgZHVyaW5nIHJlbnVtYmVyaW5nIHByb2Nlc3MgKGRlcGljdGVkIG9uIGZpZy4gMSksIHJp Z2h0Pw0KDQpZYW46IFllcywgaXQgc2hvdWxkIGJlICJBIHNjaGVtZSBpcyBhbHNvIG5lZWRlZCBm b3IgdGhlIExNQSB0byBpbW1lZGlhdGVseSBpbml0aWF0ZSB0aGUgUE1JUHY2IGJpbmRpbmcgc3Rh dGUgcmVmcmVzaG1lbnQgZHVyaW5nIHRoZSBITlAgcmVudW1iZXJpbmcgcHJvY2VzcyIgDQoNCg0K ImFsbG9jYXRlIGEgbmV3IGFkZHJlc3Mgd2l0aGluIHRoZSBuZXcgSE5QIHdpdGggYSBESENQIG1l c3NhZ2UiIERvIHlvdSBtZWFuIERIQ1B2NiByZWNvbmZpZ3VyYXRpb24gbWVzc2FnZT8NCg0KWWFu OiBZZXMsIHRoaXMgd2lsbCBiZSByZXZpc2VkIGFzICJhbGxvY2F0ZSBhIG5ldyBhZGRyZXNzIHdp dGhpbiB0aGUgbmV3IEhOUCB3aXRoIERIQ1B2NiByZWNvbmZpZ3VyYXRpb24gbWVzc2FnZXMiDQoN ClBpZXJyaWNrDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IGRtbSBbbWFp bHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvdW5pLm5vc21hcA0KPiBF bnZvecOpIDogbHVuZGkgMjMgbWFpIDIwMTYgMTk6MTcNCj4gw4AgOiBkbW1AaWV0Zi5vcmcNCj4g T2JqZXQgOiBbRE1NXSBXR0xDIHJlbWluZGVyDQo+IA0KPiBGb2xrcywNCj4gDQo+IEZyaWVuZGx5 IG51ZGdlIHRvIGRvIHJldmlld3Mgb24gZHJhZnRzIHdlIGdvdCBub3cgaW4gV0dMQy4NCj4gDQo+ IEpvdW5pDQo+IA0KPiBTZW50IGZyb20gYSBzbWFydCBwaG9uZS4uIE1pbmQgdGhlIHR5cG9zLi4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGRtbSBtYWlsaW5nIGxpc3QNCj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlz dA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt bQ0K --=====003_Dragon656841264841_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDAuMTYzODUiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFu YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpV U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20g MGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVw dA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVY VC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAx MC41cHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5k b3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0K CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9 DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJ WkU6IDEwcHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+ SGksIFBpZXJyaWNrLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFu a3MgZm9yIHlvdXIgY29tbWVudHMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw MDgwPlBsZWFzZSBzZWUgbXkgaW5saW5lIGZlZWRiYWNrPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAx Ni0wNS0yNSA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZl cmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRm IFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1W ZXJkYW5hPjxTUEFOPlouVy4gWWFuPC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1 YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWP keS7tuS6uu+8mjwvU1RST05HPiBwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tIA0KPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Y+R6YCB5pe26Ze0 77yaPC9TVFJPTkc+IDIwMTYtMDUtMjQmbmJzcDsgMTg6MDY6NTcgDQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9O Rz4gSm91bmkubm9zbWFwOyBkbW1AaWV0Zi5vcmcgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Li76aKY77yaPC9T VFJPTkc+IFJlOiBbRE1NXSBXR0xDIHJlbWluZGVyIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm YWNlPVZlcmRhbmE+DQo8RElWPkhpLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SSd2ZSZuYnNw O3JlYWQmbmJzcDtkcmFmdC1pZXRmLWRtbS1obnByZW51bSZuYnNwO2FuZCZuYnNwO0kmbmJzcDt0 aGluayZuYnNwO3RoaXMmbmJzcDtkcmFmdCZuYnNwO2NhbiZuYnNwO21vdmUmbmJzcDtmb3J3YXJk LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SSd2ZSZuYnNwO2p1c3QmbmJzcDtjb3VwbGUmbmJz cDtvZiZuYnNwO2NvbW1lbnRzL3F1ZXN0aW9uczwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+V2hh dCZuYnNwO2RvJm5ic3A7eW91Jm5ic3A7bWVhbiZuYnNwO2J5Jm5ic3A7X3VwbGlua18mbmJzcDtJ U1A/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+PEVNPllhbjogDQpJJm5i c3A7dXNlJm5ic3A7InVwbGluayZuYnNwO0lTUCImbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2RyYWZ0 Jm5ic3A7dG8mbmJzcDtkZW5vdGUmbmJzcDt0aGUmbmJzcDtJU1AmbmJzcDt3aGljaCZuYnNwO2Fs bG9jYXRlcyZuYnNwO3RoZSZuYnNwO0hOUCZuYnNwO3NldCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 UE1JUHY2Jm5ic3A7c2VydmljZSZuYnNwO3Byb3ZpZGVyLiZuYnNwOzwvRU0+PC9ESVY+DQo8RElW PjxFTT5UaGlzJm5ic3A7aXMmbmJzcDtjb25mdXNlZCZuYnNwO2FuZCZuYnNwO0kmbmJzcDt3aWxs Jm5ic3A7cmV2aXNlJm5ic3A7dGhpcyZuYnNwO2Rlc2NyaXB0aW9uJm5ic3A7bWF5YmUmbmJzcDth cyZuYnNwO2ZvbGxvd2luZzo8L0VNPjwvRElWPg0KPERJVj48RU0+InRoZSZuYnNwO0hOUCZuYnNw O3NldCZuYnNwO3VzZWQmbmJzcDtieSZuYnNwO2EmbmJzcDtQTUlQdjYmbmJzcDtzZXJ2aWNlJm5i c3A7cHJvdmlkZXImbmJzcDtpcyZuYnNwO2Fzc2lnbmVkJm5ic3A7YnkmbmJzcDthJm5ic3A7ZGlm ZmVyZW50Jm5ic3A7SW50ZXJuZXQmbmJzcDtTZXJ2aWNlJm5ic3A7UHJvdmlkZXImbmJzcDsoSVNQ KSZuYnNwOyI8L0VNPjwvRElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5zLyZuYnNwO3doaWNoJm5ic3A7ZGV0ZWN0ZWQmbmJz cDt0aGUmbmJzcDthdHRhY2htZW50LyZuYnNwO3doaWNoJm5ic3A7ZGV0ZWN0cyZuYnNwO3RoZSZu YnNwO2F0dGFjaG1lbnQvPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48RU0+WWFuOiAN CiJ3aGljaCZuYnNwO2RldGVjdGVkJm5ic3A7dGhlJm5ic3A7YXR0YWNobWVudCImbmJzcDtzaG91 bGQmbmJzcDtiZSZuYnNwOyJ3aGljaCZuYnNwO2RldGVjdHMmbmJzcDt0aGUmbmJzcDthdHRhY2ht ZW50IjwvRU0+IA0KPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+ IltzaWMuXSZuYnNwO2EmbmJzcDtzY2hlbWUmbmJzcDtpcyZuYnNwO2Fsc28mbmJzcDtuZWVkZWQm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtMTUEmbmJzcDt0byZuYnNwO2ltbWVkaWF0ZWx5Jm5ic3A7 aW5pdGlhdGUmbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtiaW5kaW5nJm5ic3A7c3RhdGUmbmJz cDtyZWZyZXNobWVudC5bc25pcF0mbmJzcDtUaGUmbmJzcDtyZWxhdGVkJm5ic3A7c29sdXRpb24m bmJzcDtoYXMmbmJzcDtub3QmbmJzcDtiZWVuJm5ic3A7c3BlY2lmaWVkLiZuYnNwOyImbmJzcDsu Jm5ic3A7QnV0LCZuYnNwO2JpbmRpbmcmbmJzcDtzdGF0ZXMmbmJzcDthcmUmbmJzcDt1cGRhdGVk Jm5ic3A7ZHVyaW5nJm5ic3A7cmVudW1iZXJpbmcmbmJzcDtwcm9jZXNzJm5ic3A7KGRlcGljdGVk Jm5ic3A7b24mbmJzcDtmaWcuJm5ic3A7MSksJm5ic3A7cmlnaHQ/PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48RU0+WWFuOiANClllcywmbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNwO2Jl Jm5ic3A7IkEmbmJzcDtzY2hlbWUmbmJzcDtpcyZuYnNwO2Fsc28mbmJzcDtuZWVkZWQmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDtMTUEmbmJzcDt0byZuYnNwO2ltbWVkaWF0ZWx5Jm5ic3A7aW5pdGlh dGUmbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtiaW5kaW5nJm5ic3A7c3RhdGUmbmJzcDtyZWZy ZXNobWVudCZuYnNwO2R1cmluZyZuYnNwO3RoZSZuYnNwO0hOUCZuYnNwO3JlbnVtYmVyaW5nJm5i c3A7cHJvY2VzczwvRU0+PEVNPiI8L0VNPiANCjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4iYWxsb2NhdGUmbmJzcDthJm5ic3A7 bmV3Jm5ic3A7YWRkcmVzcyZuYnNwO3dpdGhpbiZuYnNwO3RoZSZuYnNwO25ldyZuYnNwO0hOUCZu YnNwO3dpdGgmbmJzcDthJm5ic3A7REhDUCZuYnNwO21lc3NhZ2UiJm5ic3A7RG8mbmJzcDt5b3Um bmJzcDttZWFuJm5ic3A7REhDUHY2Jm5ic3A7cmVjb25maWd1cmF0aW9uJm5ic3A7bWVzc2FnZT88 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxFTT5ZYW46IFllcywgdGhpcyB3aWxsIGJl IHJldmlzZWQgYXMgDQoiYWxsb2NhdGUmbmJzcDthJm5ic3A7bmV3Jm5ic3A7YWRkcmVzcyZuYnNw O3dpdGhpbiZuYnNwO3RoZSZuYnNwO25ldyZuYnNwO0hOUCZuYnNwO3dpdGgmbmJzcDtESENQdjYm bmJzcDtyZWNvbmZpZ3VyYXRpb24mbmJzcDttZXNzYWdlcyI8L0VNPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlBpZXJyaWNrPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7LS0tLS1NZXNzYWdlJm5ic3A7ZCdvcmlnaW5lLS0tLS08L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO0RlJm5ic3A7OiZuYnNwO2RtbSZuYnNwO1ttYWlsdG86ZG1tLWJvdW5jZXNA aWV0Zi5vcmddJm5ic3A7RGUmbmJzcDtsYSZuYnNwO3BhcnQmbmJzcDtkZSZuYnNwO0pvdW5pLm5v c21hcDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RW52b3nDqSZuYnNwOzombmJzcDtsdW5kaSZuYnNw OzIzJm5ic3A7bWFpJm5ic3A7MjAxNiZuYnNwOzE5OjE3PC9ESVY+DQo8RElWPiZndDsmbmJzcDvD gCZuYnNwOzombmJzcDtkbW1AaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO09iamV0Jm5i c3A7OiZuYnNwO1tETU1dJm5ic3A7V0dMQyZuYnNwO3JlbWluZGVyPC9ESVY+DQo8RElWPiZndDsm bmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0ZvbGtzLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 PC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcmllbmRseSZuYnNwO251ZGdlJm5ic3A7dG8mbmJzcDtk byZuYnNwO3Jldmlld3MmbmJzcDtvbiZuYnNwO2RyYWZ0cyZuYnNwO3dlJm5ic3A7Z290Jm5ic3A7 bm93Jm5ic3A7aW4mbmJzcDtXR0xDLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElW PiZndDsmbmJzcDtKb3VuaTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsm bmJzcDtTZW50Jm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDtzbWFydCZuYnNwO3Bob25lLi4mbmJzcDtN aW5kJm5ic3A7dGhlJm5ic3A7dHlwb3MuLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8 RElWPiZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZG1tJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO2RtbUBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkNlJm5ic3A7bWVzc2FnZSZu YnNwO2V0Jm5ic3A7c2VzJm5ic3A7cGllY2VzJm5ic3A7am9pbnRlcyZuYnNwO3BldXZlbnQmbmJz cDtjb250ZW5pciZuYnNwO2RlcyZuYnNwO2luZm9ybWF0aW9ucyZuYnNwO2NvbmZpZGVudGllbGxl cyZuYnNwO291Jm5ic3A7cHJpdmlsZWdpZWVzJm5ic3A7ZXQmbmJzcDtuZSZuYnNwO2RvaXZlbnQm bmJzcDtkb25jPC9ESVY+DQo8RElWPnBhcyZuYnNwO2V0cmUmbmJzcDtkaWZmdXNlcywmbmJzcDtl eHBsb2l0ZXMmbmJzcDtvdSZuYnNwO2NvcGllcyZuYnNwO3NhbnMmbmJzcDthdXRvcmlzYXRpb24u Jm5ic3A7U2kmbmJzcDt2b3VzJm5ic3A7YXZleiZuYnNwO3JlY3UmbmJzcDtjZSZuYnNwO21lc3Nh Z2UmbmJzcDtwYXImbmJzcDtlcnJldXIsJm5ic3A7dmV1aWxsZXombmJzcDtsZSZuYnNwO3NpZ25h bGVyPC9ESVY+DQo8RElWPmEmbmJzcDtsJ2V4cGVkaXRldXImbmJzcDtldCZuYnNwO2xlJm5ic3A7 ZGV0cnVpcmUmbmJzcDthaW5zaSZuYnNwO3F1ZSZuYnNwO2xlcyZuYnNwO3BpZWNlcyZuYnNwO2pv aW50ZXMuJm5ic3A7TGVzJm5ic3A7bWVzc2FnZXMmbmJzcDtlbGVjdHJvbmlxdWVzJm5ic3A7ZXRh bnQmbmJzcDtzdXNjZXB0aWJsZXMmbmJzcDtkJ2FsdGVyYXRpb24sPC9ESVY+DQo8RElWPk9yYW5n ZSZuYnNwO2RlY2xpbmUmbmJzcDt0b3V0ZSZuYnNwO3Jlc3BvbnNhYmlsaXRlJm5ic3A7c2kmbmJz cDtjZSZuYnNwO21lc3NhZ2UmbmJzcDthJm5ic3A7ZXRlJm5ic3A7YWx0ZXJlLCZuYnNwO2RlZm9y bWUmbmJzcDtvdSZuYnNwO2ZhbHNpZmllLiZuYnNwO01lcmNpLjwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthbmQmbmJzcDtpdHMmbmJzcDthdHRhY2htZW50 cyZuYnNwO21heSZuYnNwO2NvbnRhaW4mbmJzcDtjb25maWRlbnRpYWwmbmJzcDtvciZuYnNwO3By aXZpbGVnZWQmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO3RoYXQmbmJzcDttYXkmbmJzcDtiZSZuYnNw O3Byb3RlY3RlZCZuYnNwO2J5Jm5ic3A7bGF3OzwvRElWPg0KPERJVj50aGV5Jm5ic3A7c2hvdWxk Jm5ic3A7bm90Jm5ic3A7YmUmbmJzcDtkaXN0cmlidXRlZCwmbmJzcDt1c2VkJm5ic3A7b3ImbmJz cDtjb3BpZWQmbmJzcDt3aXRob3V0Jm5ic3A7YXV0aG9yaXNhdGlvbi48L0RJVj4NCjxESVY+SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3Nl bmRlciZuYnNwO2FuZCZuYnNwO2RlbGV0ZSZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YW5k Jm5ic3A7aXRzJm5ic3A7YXR0YWNobWVudHMuPC9ESVY+DQo8RElWPkFzJm5ic3A7ZW1haWxzJm5i c3A7bWF5Jm5ic3A7YmUmbmJzcDthbHRlcmVkLCZuYnNwO09yYW5nZSZuYnNwO2lzJm5ic3A7bm90 Jm5ic3A7bGlhYmxlJm5ic3A7Zm9yJm5ic3A7bWVzc2FnZXMmbmJzcDt0aGF0Jm5ic3A7aGF2ZSZu YnNwO2JlZW4mbmJzcDttb2RpZmllZCwmbmJzcDtjaGFuZ2VkJm5ic3A7b3ImbmJzcDtmYWxzaWZp ZWQuPC9ESVY+DQo8RElWPlRoYW5rJm5ic3A7eW91LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxE SVY+ZG1tJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ZG1tQGlldGYub3JnPC9E SVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9ESVY+ PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon656841264841_=====-- From nobody Wed May 25 02:36:13 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8718812D5FC for ; Wed, 25 May 2016 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kclWY3nnbE_Z for ; Wed, 25 May 2016 02:36:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC7412D59A for ; Wed, 25 May 2016 02:36:09 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D2A7C18C0DA; Wed, 25 May 2016 11:36:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id ACFC14C06F; Wed, 25 May 2016 11:36:07 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0294.000; Wed, 25 May 2016 11:36:07 +0200 From: To: "Z.W. Yan" , Jouni.nosmap , "dmm@ietf.org" Thread-Topic: Re: [DMM] WGLC reminder Thread-Index: AQHRtRb6tc5nmVBEKkqYPeZ+w1+Pkp/I3gxagACIznA= Date: Wed, 25 May 2016 09:36:07 +0000 Message-ID: <20990_1464168967_57457207_20990_15010_1_81C77F07008CA24F9783A98CFD706F71161B8BD2@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> <201605250923468010774@cnnic.cn> In-Reply-To: <201605250923468010774@cnnic.cn> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71161B8BD2OPEXCLILM22corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.25.90316 Archived-At: Subject: Re: [DMM] WGLC reminder X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:36:11 -0000 --_000_81C77F07008CA24F9783A98CFD706F71161B8BD2OPEXCLILM22corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkRlIDogWi5XLiBZYW4gW21haWx0bzp5YW5AY25uaWMuY25dDQpFbnZvecOpIDogbWVy Y3JlZGkgMjUgbWFpIDIwMTYgMDM6MjQNCsOAIDogU0VJVEUgUGllcnJpY2sgSU1UL09MTjsgSm91 bmkubm9zbWFwOyBkbW1AaWV0Zi5vcmcNCk9iamV0IDogUmU6IFJlOiBbRE1NXSBXR0xDIHJlbWlu ZGVyDQoNCkhpLCBQaWVycmljaywNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NClBsZWFzZSBz ZWUgbXkgaW5saW5lIGZlZWRiYWNrDQoNCg0KMjAxNi0wNS0yNQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClouVy4gWWFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0K5Y+R5Lu25Lq677yaIHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb208bWFpbHRvOnBpZXJyaWNr LnNlaXRlQG9yYW5nZS5jb20+DQrlj5HpgIHml7bpl7TvvJogMjAxNi0wNS0yNCAgMTg6MDY6NTcN CuaUtuS7tuS6uu+8miBKb3VuaS5ub3NtYXA7IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYu b3JnPg0K5oqE6YCB77yaDQrkuLvpopjvvJogUmU6IFtETU1dIFdHTEMgcmVtaW5kZXINCkhpLA0K SSd2ZSByZWFkIGRyYWZ0LWlldGYtZG1tLWhucHJlbnVtIGFuZCBJIHRoaW5rIHRoaXMgZHJhZnQg Y2FuIG1vdmUgZm9yd2FyZC4NCkkndmUganVzdCBjb3VwbGUgb2YgY29tbWVudHMvcXVlc3Rpb25z DQpXaGF0IGRvIHlvdSBtZWFuIGJ5IF91cGxpbmtfIElTUD8NCg0KWWFuOiBJIHVzZSAidXBsaW5r IElTUCIgaW4gdGhlIGRyYWZ0IHRvIGRlbm90ZSB0aGUgSVNQIHdoaWNoIGFsbG9jYXRlcyB0aGUg SE5QIHNldCB0byB0aGUgUE1JUHY2IHNlcnZpY2UgcHJvdmlkZXIuDQpUaGlzIGlzIGNvbmZ1c2Vk IGFuZCBJIHdpbGwgcmV2aXNlIHRoaXMgZGVzY3JpcHRpb24gbWF5YmUgYXMgZm9sbG93aW5nOg0K InRoZSBITlAgc2V0IHVzZWQgYnkgYSBQTUlQdjYgc2VydmljZSBwcm92aWRlciBpcyBhc3NpZ25l ZCBieSBhIGRpZmZlcmVudCBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyIChJU1ApICINCg0KPj4g dGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uDQoNCg0Kcy8gd2hpY2ggZGV0ZWN0ZWQgdGhlIGF0dGFj aG1lbnQvIHdoaWNoIGRldGVjdHMgdGhlIGF0dGFjaG1lbnQvDQoNCllhbjogIndoaWNoIGRldGVj dGVkIHRoZSBhdHRhY2htZW50IiBzaG91bGQgYmUgIndoaWNoIGRldGVjdHMgdGhlIGF0dGFjaG1l bnQiDQoNCiJbc2ljLl0gYSBzY2hlbWUgaXMgYWxzbyBuZWVkZWQgZm9yIHRoZSBMTUEgdG8gaW1t ZWRpYXRlbHkgaW5pdGlhdGUgdGhlIFBNSVB2NiBiaW5kaW5nIHN0YXRlIHJlZnJlc2htZW50Lltz bmlwXSBUaGUgcmVsYXRlZCBzb2x1dGlvbiBoYXMgbm90IGJlZW4gc3BlY2lmaWVkLiAiIC4gQnV0 LCBiaW5kaW5nIHN0YXRlcyBhcmUgdXBkYXRlZCBkdXJpbmcgcmVudW1iZXJpbmcgcHJvY2VzcyAo ZGVwaWN0ZWQgb24gZmlnLiAxKSwgcmlnaHQ/DQoNCllhbjogWWVzLCBpdCBzaG91bGQgYmUgIkEg c2NoZW1lIGlzIGFsc28gbmVlZGVkIGZvciB0aGUgTE1BIHRvIGltbWVkaWF0ZWx5IGluaXRpYXRl IHRoZSBQTUlQdjYgYmluZGluZyBzdGF0ZSByZWZyZXNobWVudCBkdXJpbmcgdGhlIEhOUCByZW51 bWJlcmluZyBwcm9jZXNzIg0KDQoNCiJhbGxvY2F0ZSBhIG5ldyBhZGRyZXNzIHdpdGhpbiB0aGUg bmV3IEhOUCB3aXRoIGEgREhDUCBtZXNzYWdlIiBEbyB5b3UgbWVhbiBESENQdjYgcmVjb25maWd1 cmF0aW9uIG1lc3NhZ2U/DQoNCllhbjogWWVzLCB0aGlzIHdpbGwgYmUgcmV2aXNlZCBhcyAiYWxs b2NhdGUgYSBuZXcgYWRkcmVzcyB3aXRoaW4gdGhlIG5ldyBITlAgd2l0aCBESENQdjYgcmVjb25m aWd1cmF0aW9uIG1lc3NhZ2VzIg0KDQo+PiBtYXliZSwgeW91IGNhbiBhZGQgYSByZWZlcmVuY2Ug dG8gdGhlIERIQ1B2NiByZWNvbmZpZ3VyYXRpb24gUkZDDQo+PiB0aGFua3MgZm9yIHlvdXIgcHJv bXB0IGFuc3dlcg0KDQpQaWVycmljaw0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g RGUgOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb3Vu aS5ub3NtYXANCj4gRW52b3nDqSA6IGx1bmRpIDIzIG1haSAyMDE2IDE5OjE3DQo+IMOAIDogZG1t QGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQo+IE9iamV0IDogW0RNTV0gV0dMQyByZW1p bmRlcg0KPg0KPiBGb2xrcywNCj4NCj4gRnJpZW5kbHkgbnVkZ2UgdG8gZG8gcmV2aWV3cyBvbiBk cmFmdHMgd2UgZ290IG5vdyBpbiBXR0xDLg0KPg0KPiBKb3VuaQ0KPg0KPiBTZW50IGZyb20gYSBz bWFydCBwaG9uZS4uIE1pbmQgdGhlIHR5cG9zLi4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1tIG1haWxpbmcgbGlzdA0KPiBkbW1AaWV0 Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbW0NCl9fX19fX19fX19yX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1t QGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_81C77F07008CA24F9783A98CFD706F71161B8BD2OPEXCLILM22corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIg NSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglw YW5vc2UtMToyIDIgNSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5v c2UtMToyIDIgNSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA TVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3Rp Znk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiOw0KCW1zby1iZWxpZXZlLW5vcm1hbC1sZWZ0Onllczt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUg ZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ dGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhW2lmIG1zbyA5XT48c3R5bGU+cC5N c29Ob3JtYWwNCgl7bWFyZ2luLWxlZnQ6Ny41cHQ7fQ0KPC9zdHlsZT48IVtlbmRpZl0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 Ny41cHQ7bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmlnaHQ6Ny41cHQ7bWFyZ2luLWJvdHRvbTo3 LjVwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBaLlcuIFlhbiBbbWFpbHRvOnlhbkBjbm5pYy5jbl0NCjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyNSBtYWkgMjAxNiAwMzoyNDxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gU0VJVEUgUGllcnJpY2sgSU1UL09MTjsgSm91bmkubm9zbWFwOyBkbW1AaWV0Zi5vcmc8 YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBSZTogW0RNTV0gV0dMQyByZW1pbmRlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs aWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5IaSwgUGll cnJpY2ssPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpuYXZ5Ij5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5QbGVhc2Ugc2VlIG15IGlubGluZSBm ZWVkYmFjazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6c2lsdmVyIj4yMDE2LTA1LTI1 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0 ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4N CjxociBzaXplPSIxIiB3aWR0aD0iMTAwIiBzdHlsZT0id2lkdGg6NzUuMHB0IiBub3NoYWRlPSIi IHN0eWxlPSJjb2xvcjojQjVDNERGIiBhbGlnbj0ibGVmdCI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpzaWx2ZXIiPlouVy4gWWFuDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl eHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9 IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojQjVDNERGIiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7lj5Hku7bkurrvvJo8L3NwYW4+PC9z dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpwaWVy cmljay5zZWl0ZUBvcmFuZ2UuY29tIj5waWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPC9hPiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7lj5HpgIHml7bpl7TvvJo8L3Nw YW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNi0wNS0yNCZuYnNw OyAxODowNjo1Nw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij7mlLbku7bkurrvvJo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gSm91bmkubm9zbWFwOw0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ ZG1tQGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDsiPuaKhOmAge+8mjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg R290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7popjvvJo8L3NwYW4+PC9zdHJvbmc+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBSZTogW0RNTV0gV0dMQyByZW1pbmRlciA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSd2ZSZuYnNwO3JlYWQmbmJzcDtkcmFm dC1pZXRmLWRtbS1obnByZW51bSZuYnNwO2FuZCZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3RoaXMm bmJzcDtkcmFmdCZuYnNwO2NhbiZuYnNwO21vdmUmbmJzcDtmb3J3YXJkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkn dmUmbmJzcDtqdXN0Jm5ic3A7Y291cGxlJm5ic3A7b2YmbmJzcDtjb21tZW50cy9xdWVzdGlvbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XaGF0Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDttZWFuJm5ic3A7YnkmbmJzcDtf dXBsaW5rXyZuYnNwO0lTUD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PllhbjogSSZuYnNwO3VzZSZuYnNwOyZxdW90O3VwbGluayZuYnNwO0lTUCZxdW90OyZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7ZHJhZnQmbmJzcDt0byZuYnNwO2Rlbm90ZSZuYnNwO3RoZSZuYnNwO0lT UCZuYnNwO3doaWNoJm5ic3A7YWxsb2NhdGVzJm5ic3A7dGhlJm5ic3A7SE5QJm5ic3A7c2V0Jm5i c3A7dG8mbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtzZXJ2aWNlJm5ic3A7cHJvdmlkZXIuJm5i c3A7PC9zcGFuPjwvZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VGhpcyZuYnNwO2lzJm5ic3A7Y29uZnVzZWQmbmJzcDthbmQmbmJzcDtJJm5ic3A7d2lsbCZu YnNwO3JldmlzZSZuYnNwO3RoaXMmbmJzcDtkZXNjcmlwdGlvbiZuYnNwO21heWJlJm5ic3A7YXMm bmJzcDtmb2xsb3dpbmc6PC9zcGFuPjwvZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGVtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+JnF1b3Q7dGhlJm5ic3A7SE5QJm5ic3A7c2V0Jm5ic3A7dXNlZCZuYnNw O2J5Jm5ic3A7YSZuYnNwO1BNSVB2NiZuYnNwO3NlcnZpY2UmbmJzcDtwcm92aWRlciZuYnNwO2lz Jm5ic3A7YXNzaWduZWQmbmJzcDtieSZuYnNwO2EmbmJzcDtkaWZmZXJlbnQmbmJzcDtJbnRlcm5l dCZuYnNwO1NlcnZpY2UmbmJzcDtQcm92aWRlciZuYnNwOyhJU1ApJm5ic3A7JnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9lbT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZndDsmZ3Q7IHRoYW5rcyBmb3IgY2xhcmlmaWNhdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cy8mbmJz cDt3aGljaCZuYnNwO2RldGVjdGVkJm5ic3A7dGhlJm5ic3A7YXR0YWNobWVudC8mbmJzcDt3aGlj aCZuYnNwO2RldGVjdHMmbmJzcDt0aGUmbmJzcDthdHRhY2htZW50LzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5ZYW46ICZxdW90O3doaWNoJm5ic3A7ZGV0ZWN0ZWQmbmJzcDt0aGUm bmJzcDthdHRhY2htZW50JnF1b3Q7Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDsmcXVvdDt3aGlj aCZuYnNwO2RldGVjdHMmbmJzcDt0aGUmbmJzcDthdHRhY2htZW50JnF1b3Q7PC9zcGFuPjwvZW0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4 dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZxdW90O1tzaWMuXSZuYnNwO2EmbmJzcDtzY2hlbWUmbmJzcDtpcyZuYnNwO2Fsc28mbmJz cDtuZWVkZWQmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtMTUEmbmJzcDt0byZuYnNwO2ltbWVkaWF0 ZWx5Jm5ic3A7aW5pdGlhdGUmbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtiaW5kaW5nJm5ic3A7 c3RhdGUmbmJzcDtyZWZyZXNobWVudC5bc25pcF0mbmJzcDtUaGUmbmJzcDtyZWxhdGVkJm5ic3A7 c29sdXRpb24mbmJzcDtoYXMmbmJzcDtub3QmbmJzcDtiZWVuJm5ic3A7c3BlY2lmaWVkLiZuYnNw OyZxdW90OyZuYnNwOy4mbmJzcDtCdXQsJm5ic3A7YmluZGluZyZuYnNwO3N0YXRlcyZuYnNwO2Fy ZSZuYnNwO3VwZGF0ZWQmbmJzcDtkdXJpbmcmbmJzcDtyZW51bWJlcmluZyZuYnNwO3Byb2Nlc3Mm bmJzcDsoZGVwaWN0ZWQmbmJzcDtvbiZuYnNwO2ZpZy4mbmJzcDsxKSwmbmJzcDtyaWdodD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGVt PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWFuOiBZZXMsJm5ic3A7aXQmbmJzcDtzaG91 bGQmbmJzcDtiZSZuYnNwOyZxdW90O0EmbmJzcDtzY2hlbWUmbmJzcDtpcyZuYnNwO2Fsc28mbmJz cDtuZWVkZWQmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtMTUEmbmJzcDt0byZuYnNwO2ltbWVkaWF0 ZWx5Jm5ic3A7aW5pdGlhdGUmbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtiaW5kaW5nJm5ic3A7 c3RhdGUmbmJzcDtyZWZyZXNobWVudCZuYnNwO2R1cmluZyZuYnNwO3RoZSZuYnNwO0hOUCZuYnNw O3JlbnVtYmVyaW5nJm5ic3A7cHJvY2VzcyZxdW90Ozwvc3Bhbj48L2VtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9 InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mcXVvdDthbGxvY2F0ZSZuYnNwO2EmbmJzcDtuZXcmbmJzcDthZGRyZXNzJm5ic3A7 d2l0aGluJm5ic3A7dGhlJm5ic3A7bmV3Jm5ic3A7SE5QJm5ic3A7d2l0aCZuYnNwO2EmbmJzcDtE SENQJm5ic3A7bWVzc2FnZSZxdW90OyZuYnNwO0RvJm5ic3A7eW91Jm5ic3A7bWVhbiZuYnNwO0RI Q1B2NiZuYnNwO3JlY29uZmlndXJhdGlvbiZuYnNwO21lc3NhZ2U/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxlbT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPllhbjogWWVzLCB0aGlzIHdpbGwgYmUgcmV2aXNlZCBhcyAmcXVvdDth bGxvY2F0ZSZuYnNwO2EmbmJzcDtuZXcmbmJzcDthZGRyZXNzJm5ic3A7d2l0aGluJm5ic3A7dGhl Jm5ic3A7bmV3Jm5ic3A7SE5QJm5ic3A7d2l0aCZuYnNwO0RIQ1B2NiZuYnNwO3JlY29uZmlndXJh dGlvbiZuYnNwO21lc3NhZ2VzJnF1b3Q7PC9zcGFuPjwvZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsmZ3Q7IG1h eWJlLCB5b3UgY2FuIGFkZCBhIHJlZmVyZW5jZSB0byB0aGUgREhDUHY2IHJlY29uZmlndXJhdGlv biBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsmZ3Q7IHRoYW5rcyBmb3IgeW91ciBwcm9tcHQg YW5zd2VyDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0i dGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBpZXJyaWNrPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OyZuYnNwOy0tLS0tTWVzc2FnZSZuYnNwO2Qnb3JpZ2luZS0tLS0tPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jmd0OyZuYnNwO0RlJm5ic3A7OiZuYnNwO2RtbSZuYnNwO1s8YSBocmVmPSJtYWlsdG86 ZG1tLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dJm5i c3A7RGUmbmJzcDtsYSZuYnNwO3BhcnQmbmJzcDtkZSZuYnNwO0pvdW5pLm5vc21hcDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDsmbmJzcDtFbnZvecOpJm5ic3A7OiZuYnNwO2x1bmRpJm5ic3A7MjMmbmJzcDttYWkm bmJzcDsyMDE2Jm5ic3A7MTk6MTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jm5ic3A7w4AmbmJzcDs6Jm5ic3A7 PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZndDsmbmJzcDtPYmpldCZuYnNwOzombmJzcDtbRE1NXSZuYnNwO1dHTEMmbmJzcDtyZW1pbmRl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jm5ic3A7Rm9sa3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmbmJzcDtGcmllbmRseSZuYnNwO251ZGdl Jm5ic3A7dG8mbmJzcDtkbyZuYnNwO3Jldmlld3MmbmJzcDtvbiZuYnNwO2RyYWZ0cyZuYnNwO3dl Jm5ic3A7Z290Jm5ic3A7bm93Jm5ic3A7aW4mbmJzcDtXR0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7Jm5ic3A7Sm91bmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jmd0OyZuYnNwO1NlbnQmbmJzcDtmcm9tJm5ic3A7YSZuYnNwO3NtYXJ0Jm5ic3A7cGhv bmUuLiZuYnNwO01pbmQmbmJzcDt0aGUmbmJzcDt0eXBvcy4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmbmJzcDtkbW0mbmJzcDttYWlsaW5nJm5ic3A7 bGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZndDsmbmJzcDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5k bW1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5yPC9zcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNlJm5ic3A7bWVzc2FnZSZuYnNwO2V0Jm5ic3A7 c2VzJm5ic3A7cGllY2VzJm5ic3A7am9pbnRlcyZuYnNwO3BldXZlbnQmbmJzcDtjb250ZW5pciZu YnNwO2RlcyZuYnNwO2luZm9ybWF0aW9ucyZuYnNwO2NvbmZpZGVudGllbGxlcyZuYnNwO291Jm5i c3A7cHJpdmlsZWdpZWVzJm5ic3A7ZXQmbmJzcDtuZSZuYnNwO2RvaXZlbnQmbmJzcDtkb25jPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+cGFzJm5ic3A7ZXRyZSZuYnNwO2RpZmZ1c2VzLCZuYnNwO2V4cGxvaXRlcyZuYnNw O291Jm5ic3A7Y29waWVzJm5ic3A7c2FucyZuYnNwO2F1dG9yaXNhdGlvbi4mbmJzcDtTaSZuYnNw O3ZvdXMmbmJzcDthdmV6Jm5ic3A7cmVjdSZuYnNwO2NlJm5ic3A7bWVzc2FnZSZuYnNwO3BhciZu YnNwO2VycmV1ciwmbmJzcDt2ZXVpbGxleiZuYnNwO2xlJm5ic3A7c2lnbmFsZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5hJm5ic3A7bCdleHBlZGl0ZXVyJm5ic3A7ZXQmbmJzcDtsZSZuYnNwO2RldHJ1aXJlJm5ic3A7 YWluc2kmbmJzcDtxdWUmbmJzcDtsZXMmbmJzcDtwaWVjZXMmbmJzcDtqb2ludGVzLiZuYnNwO0xl cyZuYnNwO21lc3NhZ2VzJm5ic3A7ZWxlY3Ryb25pcXVlcyZuYnNwO2V0YW50Jm5ic3A7c3VzY2Vw dGlibGVzJm5ic3A7ZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9yYW5nZSZuYnNwO2RlY2xpbmUm bmJzcDt0b3V0ZSZuYnNwO3Jlc3BvbnNhYmlsaXRlJm5ic3A7c2kmbmJzcDtjZSZuYnNwO21lc3Nh Z2UmbmJzcDthJm5ic3A7ZXRlJm5ic3A7YWx0ZXJlLCZuYnNwO2RlZm9ybWUmbmJzcDtvdSZuYnNw O2ZhbHNpZmllLiZuYnNwO01lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YW5kJm5ic3A7aXRzJm5ic3A7YXR0YWNobWVudHMmbmJzcDttYXkmbmJzcDtjb250YWluJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7b3ImbmJzcDtwcml2aWxlZ2VkJm5ic3A7aW5mb3JtYXRpb24mbmJz cDt0aGF0Jm5ic3A7bWF5Jm5ic3A7YmUmbmJzcDtwcm90ZWN0ZWQmbmJzcDtieSZuYnNwO2xhdzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij50aGV5Jm5ic3A7c2hvdWxkJm5ic3A7bm90Jm5ic3A7YmUmbmJzcDtkaXN0cmli dXRlZCwmbmJzcDt1c2VkJm5ic3A7b3ImbmJzcDtjb3BpZWQmbmJzcDt3aXRob3V0Jm5ic3A7YXV0 aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3IsJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJm5ic3A7YW5kJm5ic3A7ZGVsZXRlJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthbmQmbmJzcDtpdHMmbmJzcDthdHRhY2htZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5BcyZuYnNwO2VtYWlscyZuYnNwO21heSZuYnNwO2JlJm5ic3A7YWx0ZXJlZCwmbmJz cDtPcmFuZ2UmbmJzcDtpcyZuYnNwO25vdCZuYnNwO2xpYWJsZSZuYnNwO2ZvciZuYnNwO21lc3Nh Z2VzJm5ic3A7dGhhdCZuYnNwO2hhdmUmbmJzcDtiZWVuJm5ic3A7bW9kaWZpZWQsJm5ic3A7Y2hh bmdlZCZuYnNwO29yJm5ic3A7ZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rJm5ic3A7eW91Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+ZG1tJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVm PSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K PC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_81C77F07008CA24F9783A98CFD706F71161B8BD2OPEXCLILM22corp_-- From nobody Wed May 25 18:22:04 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DBF12B058 for ; Wed, 25 May 2016 18:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48DTiD59Anx3 for ; Wed, 25 May 2016 18:21:59 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5E12B044 for ; Wed, 25 May 2016 18:21:49 -0700 (PDT) Received: by ajax-webmail-ocmail02.zx.nicx.cn (Coremail) ; Thu, 26 May 2016 09:21:48 +0800 (GMT+08:00) X-CM-HeaderCharset: UTF-8 X-Originating-IP: [218.241.102.150] Date: Thu, 26 May 2016 09:21:48 +0800 (GMT+08:00) From: =?UTF-8?B?5bu25b+X5Lyf?= To: pierrick.seite@orange.com X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT3.0.5b dev build 20150108(58896.7041) Copyright (c) 2002-2016 www.mailtech.cn cnnic In-Reply-To: <20990_1464168967_57457207_20990_15010_1_81C77F07008CA24F9783A98CFD706F71161B8BD2@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> <201605250923468010774@cnnic.cn> <20990_1464168967_57457207_20990_15010_1_81C77F07008CA24F9783A98CFD706F71161B8BD2@OPEXCLILM22.corporate.adroot.infra.ftgroup> X-SendMailWithSms: false Content-Type: multipart/alternative; boundary="----=_Part_14532_351497706.1464225708001" MIME-Version: 1.0 Message-ID: <646efba8.ffb.154eaa737e2.Coremail.yan@cnnic.cn> X-CM-TRANSID: AQAAf0BpcDisT0ZXUGHWCQ--.8208W X-CM-SenderInfo: x1dqqupqqluhdfq/1tbiAQAGDSVCN0szzQADss X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC reminder X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 01:22:02 -0000 ------=_Part_14532_351497706.1464225708001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T0ssIFBpZXJyaWNrLCB0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuClRoZSBwb2ludHMgeW91 IG1lbnRpb25lZCB3aWxsIGJlIHdlbGwgZml4ZWQuCgoKLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQrl j5Hku7bkuro6cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbQrlj5HpgIHml7bpl7Q6MjAxNi0wNS0y NSAxNzozNjowNyAo5pif5pyf5LiJKQrmlLbku7bkuro6ICJaLlcuIFlhbiIgPHlhbkBjbm5pYy5j bj4sICJKb3VuaS5ub3NtYXAiIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPiwgImRtbUBpZXRmLm9y ZyIgPGRtbUBpZXRmLm9yZz4K5oqE6YCBOgrkuLvpopg6IFJFOiBSZTogW0RNTV0gV0dMQyByZW1p bmRlcgoKCgpIaSwKCiAKCkRlIDogWi5XLiBZYW4gW21haWx0bzp5YW5AY25uaWMuY25dCkVudm95 w6kgOiBtZXJjcmVkaSAyNSBtYWkgMjAxNiAwMzoyNArDgCA6IFNFSVRFIFBpZXJyaWNrIElNVC9P TE47IEpvdW5pLm5vc21hcDsgZG1tQGlldGYub3JnCk9iamV0IDogUmU6IFJlOiBbRE1NXSBXR0xD IHJlbWluZGVyCgogCgpIaSwgUGllcnJpY2ssCgpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuCgpQ bGVhc2Ugc2VlIG15IGlubGluZSBmZWVkYmFjawoKIAoKIAoKMjAxNi0wNS0yNQoKWi5XLiBZYW4K CuWPkeS7tuS6uu+8mnBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20KCuWPkemAgeaXtumXtO+8miAy MDE2LTA1LTI0ICAxODowNjo1NwoK5pS25Lu25Lq677yaIEpvdW5pLm5vc21hcDsgZG1tQGlldGYu b3JnCgrmioTpgIHvvJoKCuS4u+mimO+8miBSZTogW0RNTV0gV0dMQyByZW1pbmRlcgoKSGksCgpJ J3ZlIHJlYWQgZHJhZnQtaWV0Zi1kbW0taG5wcmVudW0gYW5kIEkgdGhpbmsgdGhpcyBkcmFmdCBj YW4gbW92ZSBmb3J3YXJkLgoKSSd2ZSBqdXN0IGNvdXBsZSBvZiBjb21tZW50cy9xdWVzdGlvbnMK CldoYXQgZG8geW91IG1lYW4gYnkgX3VwbGlua18gSVNQPwoKIAoKWWFuOiBJIHVzZSAidXBsaW5r IElTUCIgaW4gdGhlIGRyYWZ0IHRvIGRlbm90ZSB0aGUgSVNQIHdoaWNoIGFsbG9jYXRlcyB0aGUg SE5QIHNldCB0byB0aGUgUE1JUHY2IHNlcnZpY2UgcHJvdmlkZXIuIAoKVGhpcyBpcyBjb25mdXNl ZCBhbmQgSSB3aWxsIHJldmlzZSB0aGlzIGRlc2NyaXB0aW9uIG1heWJlIGFzIGZvbGxvd2luZzoK CiJ0aGUgSE5QIHNldCB1c2VkIGJ5IGEgUE1JUHY2IHNlcnZpY2UgcHJvdmlkZXIgaXMgYXNzaWdu ZWQgYnkgYSBkaWZmZXJlbnQgSW50ZXJuZXQgU2VydmljZSBQcm92aWRlciAoSVNQKSAiCgogCgo+ PiB0aGFua3MgZm9yIGNsYXJpZmljYXRpb24KCiAKCiAKCnMvIHdoaWNoIGRldGVjdGVkIHRoZSBh dHRhY2htZW50LyB3aGljaCBkZXRlY3RzIHRoZSBhdHRhY2htZW50LwoKIAoKWWFuOiAid2hpY2gg ZGV0ZWN0ZWQgdGhlIGF0dGFjaG1lbnQiIHNob3VsZCBiZSAid2hpY2ggZGV0ZWN0cyB0aGUgYXR0 YWNobWVudCIKCiAKCiJbc2ljLl0gYSBzY2hlbWUgaXMgYWxzbyBuZWVkZWQgZm9yIHRoZSBMTUEg dG8gaW1tZWRpYXRlbHkgaW5pdGlhdGUgdGhlIFBNSVB2NiBiaW5kaW5nIHN0YXRlIHJlZnJlc2ht ZW50LltzbmlwXSBUaGUgcmVsYXRlZCBzb2x1dGlvbiBoYXMgbm90IGJlZW4gc3BlY2lmaWVkLiAi IC4gQnV0LCBiaW5kaW5nIHN0YXRlcyBhcmUgdXBkYXRlZCBkdXJpbmcgcmVudW1iZXJpbmcgcHJv Y2VzcyAoZGVwaWN0ZWQgb24gZmlnLiAxKSwgcmlnaHQ/CgogCgpZYW46IFllcywgaXQgc2hvdWxk IGJlICJBIHNjaGVtZSBpcyBhbHNvIG5lZWRlZCBmb3IgdGhlIExNQSB0byBpbW1lZGlhdGVseSBp bml0aWF0ZSB0aGUgUE1JUHY2IGJpbmRpbmcgc3RhdGUgcmVmcmVzaG1lbnQgZHVyaW5nIHRoZSBI TlAgcmVudW1iZXJpbmcgcHJvY2VzcyIKCiAKCiAKCiJhbGxvY2F0ZSBhIG5ldyBhZGRyZXNzIHdp dGhpbiB0aGUgbmV3IEhOUCB3aXRoIGEgREhDUCBtZXNzYWdlIiBEbyB5b3UgbWVhbiBESENQdjYg cmVjb25maWd1cmF0aW9uIG1lc3NhZ2U/CgogCgpZYW46IFllcywgdGhpcyB3aWxsIGJlIHJldmlz ZWQgYXMgImFsbG9jYXRlIGEgbmV3IGFkZHJlc3Mgd2l0aGluIHRoZSBuZXcgSE5QIHdpdGggREhD UHY2IHJlY29uZmlndXJhdGlvbiBtZXNzYWdlcyIKCiAKCj4+IG1heWJlLCB5b3UgY2FuIGFkZCBh IHJlZmVyZW5jZSB0byB0aGUgREhDUHY2IHJlY29uZmlndXJhdGlvbiBSRkMKCj4+IHRoYW5rcyBm b3IgeW91ciBwcm9tcHQgYW5zd2VyCgogCgpQaWVycmljawoKPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0KCj4gRGUgOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCBkZSBKb3VuaS5ub3NtYXAKCj4gRW52b3nDqSA6IGx1bmRpIDIzIG1haSAyMDE2IDE5OjE3 Cgo+IMOAIDogZG1tQGlldGYub3JnCgo+IE9iamV0IDogW0RNTV0gV0dMQyByZW1pbmRlcgoKPiAK Cj4gRm9sa3MsCgo+IAoKPiBGcmllbmRseSBudWRnZSB0byBkbyByZXZpZXdzIG9uIGRyYWZ0cyB3 ZSBnb3Qgbm93IGluIFdHTEMuCgo+IAoKPiBKb3VuaQoKPiAKCj4gU2VudCBmcm9tIGEgc21hcnQg cGhvbmUuLiBNaW5kIHRoZSB0eXBvcy4uCgo+IAoKPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKPiBkbW0gbWFpbGluZyBsaXN0Cgo+IGRtbUBpZXRmLm9y ZwoKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQoKX19fX19fX19f X3JfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwoKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIKCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCgpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OwoK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KClRoYW5rIHlvdS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpkbW0gbWFpbGluZyBsaXN0CgpkbW1AaWV0Zi5vcmcKCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K ------=_Part_14532_351497706.1464225708001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PFA+T0ssIFBpZXJyaWNrLCB0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuPEJSPlRoZSBwb2lu dHMgeW91IG1lbnRpb25lZCB3aWxsIGJlIHdlbGwgZml4ZWQuPEJSPjwvUD4KPEJMT0NLUVVPVEUg c3R5bGU9IkJPUkRFUi1MRUZUOiAjYjZiNmI2IDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7 IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4IiBjbGFzcz0iUmVmZXJlbmNlUXVv dGUiIG5hbWU9InJlcGx5Q29udGVudCI+LS0tLS3ljp/lp4vpgq7ku7YtLS0tLTxCUj48Qj7lj5Hk u7bkuro6PC9CPjxTUEFOIGlkPSJyY19mcm9tIj5waWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPC9T UEFOPjxCUj48Qj7lj5HpgIHml7bpl7Q6PC9CPjxTUEFOIGlkPSJyY19zZW50dGltZSI+MjAxNi0w NS0yNSAxNzozNjowNyAo5pif5pyf5LiJKTwvU1BBTj48QlI+PEI+5pS25Lu25Lq6OjwvQj4gIlou Vy4gWWFuIiAmbHQ7eWFuQGNubmljLmNuJmd0OywgIkpvdW5pLm5vc21hcCIgJmx0O2pvdW5pLm5v c3BhbUBnbWFpbC5jb20mZ3Q7LCAiZG1tQGlldGYub3JnIiAmbHQ7ZG1tQGlldGYub3JnJmd0OzxC Uj48Qj7mioTpgIE6PC9CPiA8QlI+PEI+5Li76aKYOjwvQj4gUkU6IFJlOiBbRE1NXSBXR0xDIHJl bWluZGVyPEJSPjxCUj4KPFNUWUxFPjwvU1RZTEU+Cgo8RElWIGNsYXNzPSJXb3JkU2VjdGlvbjEi Pgo8UCBjbGFzcz0iTXNvTm9ybWFsIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcs J3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+SGksPG86cD48L286 cD48L1NQQU4+PC9QPgo8UCBjbGFzcz0iTXNvTm9ybWFsIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPgo8RElWIHN0eWxlPSJCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctQk9UVE9N OiAwY207IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6 IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogMGNt Ij4KPERJVj4KPERJViBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207 IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPgo8UCBzdHlsZT0iVEVYVC1B TElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxCPjxTUEFOIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkRl Jm5ic3A7OjwvU1BBTj48L0I+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+IFouVy4gWWFuIFttYWlsdG86PEEgaHJlZj0ibWFp bHRvOnlhbkBjbm5pYy5jbiIgdGFyZ2V0PSJfYmxhbmsiPnlhbkBjbm5pYy5jbjwvQT5dIDxCUj48 Qj5FbnZvecOpJm5ic3A7OjwvQj4gbWVyY3JlZGkgMjUgbWFpIDIwMTYgMDM6MjQ8QlI+PEI+w4Am bmJzcDs6PC9CPiBTRUlURSBQaWVycmljayBJTVQvT0xOOyBKb3VuaS5ub3NtYXA7IDxBIGhyZWY9 Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L0E+PEJS PjxCPk9iamV0Jm5ic3A7OjwvQj4gUmU6IFJlOiBbRE1NXSBXR0xDIHJlbWluZGVyPG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPgo8RElWPgo8 UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6 IG5hdnk7IEZPTlQtU0laRTogMTBwdCI+SGksIFBpZXJyaWNrLDwvU1BBTj48U1BBTiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+PG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVm dCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTBwdCI+ VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlmJzsgQ09MT1I6IG5hdnk7IEZPTlQtU0laRTogMTBwdCI+UGxlYXNlIHNlZSBt eSBpbmxpbmUgZmVlZGJhY2s8L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFu YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElW Pgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlm JzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxE SVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBD T0xPUjogc2lsdmVyOyBGT05ULVNJWkU6IDEwcHQiPjIwMTYtMDUtMjUgPC9TUEFOPjxTUEFOIHN0 eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0 Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxESVYgc3R5bGU9IlRFWFQtQUxJR046IGxl ZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IENPTE9SOiBuYXZ5OyBGT05ULVNJWkU6IDEwcHQi Pgo8SFIgc3R5bGU9IldJRFRIOiA3NXB0OyBDT0xPUjogI2I1YzRkZiIgYWxpZ249ImxlZnQiIFNJ WkU9IjEiIHdpZHRoPSIxMDAiIG5vU2hhZGU+CjwvU1BBTj48L0RJVj4KPERJVj4KPFAgc3R5bGU9 IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IENPTE9SOiBzaWx2ZXI7 IEZPTlQtU0laRTogMTBwdCI+Wi5XLiBZYW4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+CjxESVYgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFu YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPgo8SFIgc3R5bGU9IkNPTE9SOiAjYjVj NGRmIiBhbGlnbj0iY2VudGVyIiBTSVpFPSIxIiB3aWR0aD0iMTAwJSIgbm9TaGFkZT4KPC9TUEFO PjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPjxTVFJPTkc+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBNaW5nTGlV OyBGT05ULVNJWkU6IDEwcHQiPuWPkeS7tuS6uu+8mjwvU1BBTj48L1NUUk9ORz48U1BBTiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+ IDxBIGhyZWY9Im1haWx0bzpwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbTwvQT4gPG86cD48L286cD48L1NQQU4+PC9QPjwv RElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiPjxTVFJPTkc+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBNaW5nTGlVOyBG T05ULVNJWkU6IDEwcHQiPuWPkemAgeaXtumXtO+8mjwvU1BBTj48L1NUUk9ORz48U1BBTiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+ IDIwMTYtMDUtMjQmbmJzcDsgMTg6MDY6NTcgPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8 RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiPjxTVFJPTkc+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTVMgR290aGljJzsgRk9O VC1TSVpFOiAxMHB0Ij7mlLbku7bkurrvvJo8L1NQQU4+PC9TVFJPTkc+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiBKb3Vu aS5ub3NtYXA7IDxBIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5k bW1AaWV0Zi5vcmc8L0E+IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5 bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1RS T05HPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ01TIEdvdGhpYyc7IEZPTlQtU0laRTogMTBw dCI+5oqE6YCB77yaPC9TUEFOPjwvU1RST05HPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Zl cmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4gPG86cD48L286cD48L1NQQU4+ PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiPjxTVFJPTkc+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnTVMg R290aGljJzsgRk9OVC1TSVpFOiAxMHB0Ij7kuLs8L1NQQU4+PC9TVFJPTkc+PFNUUk9ORz48U1BB TiBzdHlsZT0iRk9OVC1GQU1JTFk6IE1pbmdMaVU7IEZPTlQtU0laRTogMTBwdCI+6aKY77yaPC9T UEFOPjwvU1RST05HPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNl cmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4gUmU6IFtETU1dIFdHTEMgcmVtaW5kZXIgPG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVm dCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5IaSw8bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVy ZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkkndmUmbmJzcDtyZWFkJm5ic3A7 ZHJhZnQtaWV0Zi1kbW0taG5wcmVudW0mbmJzcDthbmQmbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt0 aGlzJm5ic3A7ZHJhZnQmbmJzcDtjYW4mbmJzcDttb3ZlJm5ic3A7Zm9yd2FyZC48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVy ZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkkndmUmbmJzcDtqdXN0Jm5ic3A7 Y291cGxlJm5ic3A7b2YmbmJzcDtjb21tZW50cy9xdWVzdGlvbnM8bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPldoYXQmbmJzcDtkbyZuYnNwO3lvdSZuYnNwO21l YW4mbmJzcDtieSZuYnNwO191cGxpbmtfJm5ic3A7SVNQPzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElW Pgo8RElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPjxFTT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywn c2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+WWFuOiBJJm5ic3A7dXNlJm5ic3A7InVwbGlu ayZuYnNwO0lTUCImbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7dG8mbmJzcDtkZW5v dGUmbmJzcDt0aGUmbmJzcDtJU1AmbmJzcDt3aGljaCZuYnNwO2FsbG9jYXRlcyZuYnNwO3RoZSZu YnNwO0hOUCZuYnNwO3NldCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7UE1JUHY2Jm5ic3A7c2Vydmlj ZSZuYnNwO3Byb3ZpZGVyLiZuYnNwOzwvU1BBTj48L0VNPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij48bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PEVNPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Zl cmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5UaGlzJm5ic3A7aXMmbmJzcDtj b25mdXNlZCZuYnNwO2FuZCZuYnNwO0kmbmJzcDt3aWxsJm5ic3A7cmV2aXNlJm5ic3A7dGhpcyZu YnNwO2Rlc2NyaXB0aW9uJm5ic3A7bWF5YmUmbmJzcDthcyZuYnNwO2ZvbGxvd2luZzo8L1NQQU4+ PC9FTT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHls ZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxFTT48 U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0la RTogMTBwdCI+InRoZSZuYnNwO0hOUCZuYnNwO3NldCZuYnNwO3VzZWQmbmJzcDtieSZuYnNwO2Em bmJzcDtQTUlQdjYmbmJzcDtzZXJ2aWNlJm5ic3A7cHJvdmlkZXImbmJzcDtpcyZuYnNwO2Fzc2ln bmVkJm5ic3A7YnkmbmJzcDthJm5ic3A7ZGlmZmVyZW50Jm5ic3A7SW50ZXJuZXQmbmJzcDtTZXJ2 aWNlJm5ic3A7UHJvdmlkZXImbmJzcDsoSVNQKSZuYnNwOyI8bzpwPjwvbzpwPjwvU1BBTj48L0VN PjwvUD4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBD T0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q Pgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IENPTE9S OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7Jmd0OyB0aGFua3MgZm9yIGNsYXJpZmljYXRp b248bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJ R046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5zLyZuYnNwO3do aWNoJm5ic3A7ZGV0ZWN0ZWQmbmJzcDt0aGUmbmJzcDthdHRhY2htZW50LyZuYnNwO3doaWNoJm5i c3A7ZGV0ZWN0cyZuYnNwO3RoZSZuYnNwO2F0dGFjaG1lbnQvPG86cD48L286cD48L1NQQU4+PC9Q PjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5z LXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PEVNPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5z LXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5ZYW46ICJ3aGljaCZuYnNwO2RldGVjdGVkJm5ic3A7 dGhlJm5ic3A7YXR0YWNobWVudCImbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwOyJ3aGljaCZuYnNw O2RldGVjdHMmbmJzcDt0aGUmbmJzcDthdHRhY2htZW50IjwvU1BBTj48L0VNPjxTUEFOIHN0eWxl PSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4g PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0 IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiJbc2ljLl0mbmJzcDth Jm5ic3A7c2NoZW1lJm5ic3A7aXMmbmJzcDthbHNvJm5ic3A7bmVlZGVkJm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7TE1BJm5ic3A7dG8mbmJzcDtpbW1lZGlhdGVseSZuYnNwO2luaXRpYXRlJm5ic3A7 dGhlJm5ic3A7UE1JUHY2Jm5ic3A7YmluZGluZyZuYnNwO3N0YXRlJm5ic3A7cmVmcmVzaG1lbnQu W3NuaXBdJm5ic3A7VGhlJm5ic3A7cmVsYXRlZCZuYnNwO3NvbHV0aW9uJm5ic3A7aGFzJm5ic3A7 bm90Jm5ic3A7YmVlbiZuYnNwO3NwZWNpZmllZC4mbmJzcDsiJm5ic3A7LiZuYnNwO0J1dCwmbmJz cDtiaW5kaW5nJm5ic3A7c3RhdGVzJm5ic3A7YXJlJm5ic3A7dXBkYXRlZCZuYnNwO2R1cmluZyZu YnNwO3JlbnVtYmVyaW5nJm5ic3A7cHJvY2VzcyZuYnNwOyhkZXBpY3RlZCZuYnNwO29uJm5ic3A7 ZmlnLiZuYnNwOzEpLCZuYnNwO3JpZ2h0PzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJ Vj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8 UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi PjxFTT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+WWFuOiBZZXMsJm5ic3A7aXQmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNw OyJBJm5ic3A7c2NoZW1lJm5ic3A7aXMmbmJzcDthbHNvJm5ic3A7bmVlZGVkJm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7TE1BJm5ic3A7dG8mbmJzcDtpbW1lZGlhdGVseSZuYnNwO2luaXRpYXRlJm5i c3A7dGhlJm5ic3A7UE1JUHY2Jm5ic3A7YmluZGluZyZuYnNwO3N0YXRlJm5ic3A7cmVmcmVzaG1l bnQmbmJzcDtkdXJpbmcmbmJzcDt0aGUmbmJzcDtITlAmbmJzcDtyZW51bWJlcmluZyZuYnNwO3By b2Nlc3MiPC9TUEFOPjwvRU0+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+ CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJ Vj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8 UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1T SVpFOiAxMHB0Ij4iYWxsb2NhdGUmbmJzcDthJm5ic3A7bmV3Jm5ic3A7YWRkcmVzcyZuYnNwO3dp dGhpbiZuYnNwO3RoZSZuYnNwO25ldyZuYnNwO0hOUCZuYnNwO3dpdGgmbmJzcDthJm5ic3A7REhD UCZuYnNwO21lc3NhZ2UiJm5ic3A7RG8mbmJzcDt5b3UmbmJzcDttZWFuJm5ic3A7REhDUHY2Jm5i c3A7cmVjb25maWd1cmF0aW9uJm5ic3A7bWVzc2FnZT88bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4K PERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0Ij48RU0+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPllhbjogWWVzLCB0aGlzIHdpbGwgYmUgcmV2aXNlZCBhcyAi YWxsb2NhdGUmbmJzcDthJm5ic3A7bmV3Jm5ic3A7YWRkcmVzcyZuYnNwO3dpdGhpbiZuYnNwO3Ro ZSZuYnNwO25ldyZuYnNwO0hOUCZuYnNwO3dpdGgmbmJzcDtESENQdjYmbmJzcDtyZWNvbmZpZ3Vy YXRpb24mbmJzcDttZXNzYWdlcyI8L1NQQU4+PC9FTT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L1A+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0OyBtYXliZSwg eW91IGNhbiBhZGQgYSByZWZlcmVuY2UgdG8gdGhlIERIQ1B2NiByZWNvbmZpZ3VyYXRpb24gUkZD PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFs Jywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1V UyI+Jmd0OyZndDsgdGhhbmtzIGZvciB5b3VyIHByb21wdCBhbnN3ZXIgPG86cD48L286cD48L1NQ QU4+PC9QPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7 IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog J1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5QaWVycmljazxvOnA+PC9v OnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdW ZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyZuYnNwOy0tLS0tTWVz c2FnZSZuYnNwO2Qnb3JpZ2luZS0tLS0tPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElW Pgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9O VC1TSVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7RGUmbmJzcDs6Jm5ic3A7ZG1tJm5ic3A7WzxBIGhyZWY9 Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkbW0t Ym91bmNlc0BpZXRmLm9yZzwvQT5dJm5ic3A7RGUmbmJzcDtsYSZuYnNwO3BhcnQmbmJzcDtkZSZu YnNwO0pvdW5pLm5vc21hcDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5 bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTog MTBwdCI+Jmd0OyZuYnNwO0Vudm95w6kmbmJzcDs6Jm5ic3A7bHVuZGkmbmJzcDsyMyZuYnNwO21h aSZuYnNwOzIwMTYmbmJzcDsxOToxNzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4K PFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQt U0laRTogMTBwdCI+Jmd0OyZuYnNwO8OAJm5ic3A7OiZuYnNwOzxBIGhyZWY9Im1haWx0bzpkbW1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L0E+PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7T2JqZXQmbmJzcDs6Jm5i c3A7W0RNTV0mbmJzcDtXR0xDJm5ic3A7cmVtaW5kZXI8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDtGb2xrcyw8bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDtGcmllbmRseSZuYnNwO251ZGdl Jm5ic3A7dG8mbmJzcDtkbyZuYnNwO3Jldmlld3MmbmJzcDtvbiZuYnNwO2RyYWZ0cyZuYnNwO3dl Jm5ic3A7Z290Jm5ic3A7bm93Jm5ic3A7aW4mbmJzcDtXR0xDLjxvOnA+PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fu cy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fu cy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyZuYnNwO0pvdW5pPG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L1NQ QU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEn LCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7U2VudCZuYnNwO2Zyb20m bmJzcDthJm5ic3A7c21hcnQmbmJzcDtwaG9uZS4uJm5ic3A7TWluZCZuYnNwO3RoZSZuYnNwO3R5 cG9zLi48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFM SUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFM SUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiZndDsm bmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQi IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+Jmd0OyZuYnNwO2RtbSZu YnNwO21haWxpbmcmbmJzcDtsaXN0PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8 UCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1T SVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7PEEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvQT48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxE SVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBG T05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDs8QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG1tPC9BPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJ Vj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+X19fX19fX19fXzxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPnI8L1NQ QU4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5DZSZuYnNwO21l c3NhZ2UmbmJzcDtldCZuYnNwO3NlcyZuYnNwO3BpZWNlcyZuYnNwO2pvaW50ZXMmbmJzcDtwZXV2 ZW50Jm5ic3A7Y29udGVuaXImbmJzcDtkZXMmbmJzcDtpbmZvcm1hdGlvbnMmbmJzcDtjb25maWRl bnRpZWxsZXMmbmJzcDtvdSZuYnNwO3ByaXZpbGVnaWVlcyZuYnNwO2V0Jm5ic3A7bmUmbmJzcDtk b2l2ZW50Jm5ic3A7ZG9uYzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5 bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BB TiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTog MTBwdCI+cGFzJm5ic3A7ZXRyZSZuYnNwO2RpZmZ1c2VzLCZuYnNwO2V4cGxvaXRlcyZuYnNwO291 Jm5ic3A7Y29waWVzJm5ic3A7c2FucyZuYnNwO2F1dG9yaXNhdGlvbi4mbmJzcDtTaSZuYnNwO3Zv dXMmbmJzcDthdmV6Jm5ic3A7cmVjdSZuYnNwO2NlJm5ic3A7bWVzc2FnZSZuYnNwO3BhciZuYnNw O2VycmV1ciwmbmJzcDt2ZXVpbGxleiZuYnNwO2xlJm5ic3A7c2lnbmFsZXI8bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFu YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPmEmbmJzcDtsJ2V4cGVkaXRldXImbmJz cDtldCZuYnNwO2xlJm5ic3A7ZGV0cnVpcmUmbmJzcDthaW5zaSZuYnNwO3F1ZSZuYnNwO2xlcyZu YnNwO3BpZWNlcyZuYnNwO2pvaW50ZXMuJm5ic3A7TGVzJm5ic3A7bWVzc2FnZXMmbmJzcDtlbGVj dHJvbmlxdWVzJm5ic3A7ZXRhbnQmbmJzcDtzdXNjZXB0aWJsZXMmbmJzcDtkJ2FsdGVyYXRpb24s PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5PcmFuZ2UmbmJz cDtkZWNsaW5lJm5ic3A7dG91dGUmbmJzcDtyZXNwb25zYWJpbGl0ZSZuYnNwO3NpJm5ic3A7Y2Um bmJzcDttZXNzYWdlJm5ic3A7YSZuYnNwO2V0ZSZuYnNwO2FsdGVyZSwmbmJzcDtkZWZvcm1lJm5i c3A7b3UmbmJzcDtmYWxzaWZpZS4mbmJzcDtNZXJjaS48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9E SVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPlRoaXMmbmJzcDttZXNzYWdlJm5ic3A7YW5kJm5ic3A7aXRz Jm5ic3A7YXR0YWNobWVudHMmbmJzcDttYXkmbmJzcDtjb250YWluJm5ic3A7Y29uZmlkZW50aWFs Jm5ic3A7b3ImbmJzcDtwcml2aWxlZ2VkJm5ic3A7aW5mb3JtYXRpb24mbmJzcDt0aGF0Jm5ic3A7 bWF5Jm5ic3A7YmUmbmJzcDtwcm90ZWN0ZWQmbmJzcDtieSZuYnNwO2xhdzs8bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFu YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPnRoZXkmbmJzcDtzaG91bGQmbmJzcDtu b3QmbmJzcDtiZSZuYnNwO2Rpc3RyaWJ1dGVkLCZuYnNwO3VzZWQmbmJzcDtvciZuYnNwO2NvcGll ZCZuYnNwO3dpdGhvdXQmbmJzcDthdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1z ZXJpZic7IEZPTlQtU0laRTogMTBwdCI+SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlciZuYnNwO2FuZCZuYnNwO2RlbGV0ZSZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YW5kJm5ic3A7aXRzJm5ic3A7YXR0YWNobWVudHMuPG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElHTjogbGVm dCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5BcyZuYnNwO2VtYWls cyZuYnNwO21heSZuYnNwO2JlJm5ic3A7YWx0ZXJlZCwmbmJzcDtPcmFuZ2UmbmJzcDtpcyZuYnNw O25vdCZuYnNwO2xpYWJsZSZuYnNwO2ZvciZuYnNwO21lc3NhZ2VzJm5ic3A7dGhhdCZuYnNwO2hh dmUmbmJzcDtiZWVuJm5ic3A7bW9kaWZpZWQsJm5ic3A7Y2hhbmdlZCZuYnNwO29yJm5ic3A7ZmFs c2lmaWVkLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQt QUxJR046IGxlZnQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+VGhh bmsmbmJzcDt5b3UuPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0i VEVYVC1BTElHTjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0 eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0 Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9TUEFOPjwvUD48L0RJVj4KPERJVj4KPFAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdW ZXJkYW5hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+ZG1tJm5ic3A7bWFpbGluZyZu YnNwO2xpc3Q8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+CjxESVY+CjxQIHN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+PFNQQU4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjxB IGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8 L0E+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPgo8RElWPgo8UCBzdHlsZT0iVEVYVC1BTElH TjogbGVmdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPjxTUEFOIHN0eWxlPSJGT05U LUZBTUlMWTogJ1ZlcmRhbmEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij48QSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9BPjxvOnA+PC9v OnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj48L0RJVj48UFJFPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91Lgo8L1BSRT48L0JMT0NLUVVPVEU+ ------=_Part_14532_351497706.1464225708001--