From nobody Wed Apr 1 08:02:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730DC1ACCF4 for ; Wed, 1 Apr 2015 08:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Y40BpJqTrdJv for ; Wed, 1 Apr 2015 08:02:27 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 F2F681ACD57 for ; Wed, 1 Apr 2015 08:02:18 -0700 (PDT) Received: by igcau2 with SMTP id au2so50433230igc.0 for ; Wed, 01 Apr 2015 08:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JVCICDCIPZIYqga0eMLQW3RSiwWVBKOpC2UZwLeguEg=; b=u8C7cYjxmhc1+BBB4ZspIjFEfzTyXSWUOlMgokRFC2XMdkccQm2bHLd0oLj/iiyTzs TUqq2lq/kV44mkqcVSXvdi2jo/lqpmjdQPMcbRyj5/e5tMoi8pJVrswez54rrnJY593g N/vSt7t7Tg4xdWeSQtuJ7cNbD9QbU04lOZXBy7HojT6QomOJ3lquFtCyCYiB5ru0AZbB +fNnWptXzuO5xiYvyyvS+LUhfvUowIbBgtvk8xxMoStlIgZ8xAjZmPhxgLXrAX76xoXo M7hYpWLi+az2R16ID0OKDdjuxtOFW1bDGBdFdsBijBN/1t7I0aqqc6gYiKZTaZj4Ho5J a4sA== X-Received: by 10.50.6.4 with SMTP id w4mr12983450igw.36.1427900538200; Wed, 01 Apr 2015 08:02:18 -0700 (PDT) Received: from [10.252.0.48] (host136-111.cablelabs.com. [192.160.73.136]) by mx.google.com with ESMTPSA id x10sm1604421igl.13.2015.04.01.08.02.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 08:02:16 -0700 (PDT) Message-ID: <551C0877.1060100@gmail.com> Date: Wed, 01 Apr 2015 08:02:15 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Jouni , Dapeng Liu , draft-perkins-dmm-4283mnids@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:02:30 -0000 Folks, This emails starts a two week call for the I-D draft-perkins-dmm-4283mnids-01 to confirm the aadoption s a DMM WG document. The call ends April 15th EOB PST. Express your support or opposition to the mailing list. During the IETF92 meeting we got 7 voices for the adoption so at least the same amount supporting emails should be expected. - Jouni & Dapeng From nobody Wed Apr 1 09:11:27 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E111ACEC7 for ; Wed, 1 Apr 2015 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ymketeTwebFi for ; Wed, 1 Apr 2015 09:11:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF161ACED2 for ; Wed, 1 Apr 2015 09:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1427904685; x=1429114285; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=l5Ht1eldsCkR7GotdqcQQBtXI0R4VqTRqF1yOM42iZw=; b=mt9LitPSgEosl6GFglIE5mTalp4HIA7RMLaBNc05XuRgn6ZoKIf9PXR1 KKnkCYomzHb+K5PwNh1YpVMMuQMMLKXj3M3IR+YlrGExmXow4xedDrL3g jF4sUPJ56khlcGwp7WgVhgRMYqAC3gm+3DzlcPjKDLZ+6Mr8QXbKpzvKL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBgDzFxxV/4oNJK1cgwZSXAXDGoIyCoVzAoFBTAEBAQEBAX2EFQEBBAEBARodNB0BCDYxBgslAgQBEogbAxENyRUNhTYBAQEBAQEBAQIBAQEBAQEBAQEVBIspgkeCOYQtAQSQY4gpgU2BHYx2gmWDSCKCAhyBUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,504,1422921600"; d="scan'208";a="137382168" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 01 Apr 2015 16:11:24 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t31GBOvM013420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 16:11:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.108]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 11:11:24 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-perkins-dmm-4283mnids@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 Thread-Index: AQHQbJZ/zE15kOlWN0Kb2hivdDs1dA== Date: Wed, 1 Apr 2015 16:11:24 +0000 Message-ID: In-Reply-To: <551C0877.1060100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:11:26 -0000 I support the adoption of this draft as a WG document; There was good amount of discussion on supporting RFID related identifiers. We need to make sure all of those comments will be addressed in the subsequent revisions. Sri On 4/1/15, 8:02 AM, "Jouni Korhonen" wrote: >Folks, > >This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 >to confirm the aadoption s a DMM WG document. The call ends April 15th >EOB PST. > >Express your support or opposition to the mailing list. During the >IETF92 meeting we got 7 voices for the adoption so at least the same >amount supporting emails should be expected. > >- Jouni & Dapeng > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Apr 2 06:16:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F4F1A8A0B for ; Thu, 2 Apr 2015 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UYhNY1aUM1_Q for ; Thu, 2 Apr 2015 06:16:27 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 938BD1A8A20 for ; Thu, 2 Apr 2015 06:16:27 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 02 Apr 2015 06:16:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,511,1422950400"; d="scan'208,217";a="702228060" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 02 Apr 2015 06:16:25 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 2 Apr 2015 14:16:18 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by HASMSX105.ger.corp.intel.com ([10.184.198.19]) with mapi id 14.03.0224.002; Thu, 2 Apr 2015 16:16:17 +0300 From: "Moses, Danny" To: Seil Jeon Thread-Topic: [DMM] Answer on raised questions for the proposed API Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgC2fzqAAAjVfcAAJcsWAABraEqA Date: Thu, 2 Apr 2015 13:16:16 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> In-Reply-To: <003901d06bad$75307a90$5f916fb0$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490C65AHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:16:35 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490C65AHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request= a sustained IP address more than once after each movement to a new LAN (wi= th a different prefix), than there will be no abuse. Seil -> Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request= a Nomadic IP address and a Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any appl= ications requesting any addresses. This way, whenever an application is lau= nched and requests either a Nomadic or Sustained IP address, the stack can = provide one without having to issue a request to the network. In this case,= there is no need for this flag from the application. Seil -> Decision of which type of IP address by default will be depending o= n the IP pool management policy by operators. You case may correspond to on= e of them. What if only the Nomadic IP address is basically allocated upon = a network attachment? That is, a lot of applications require mere Internet = connectivity without session continuity support. So, the Sustained IP addre= ss will be requested on demand, and the proposed flag will be used to get a= new Sustained IP address by expressing the explicit request by an applicat= ion. >>2 As I mentioned at the beginning of the description - it is a description of= one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this = example, the IP stack in the host pre-allocates both Nomadic and Sustained = IP addresses upon attachment... Yes, we can describe an alternative in which a Nomadic IP address is pre-al= located upon NW connection (and after every movement to a new LAN) and a Su= stained (and/or Fixed) address is allocated on-demand. Even in such a scena= rio, I do not see any use for this flag - see my reply to the second item b= elow... >>2 Another potential implementation of the IP stack in the host is not to requ= est IP addresses in advance. In that case, it will issue a request for a No= madic IP address or a Sustained IP address the first time an application re= quests one and use it for subsequent requests as long as it is not moving t= o a different LAN. Once it moves, it will again request a new IP address (N= omadic or Sustained - according to what is required) after receiving the fi= rst request from any application. In this case as well, there is no need fo= r this flag. Seil -> Another application requested just Sustained IP address while the I= P stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply "Sustained IP addres= s type"? You case took a step towards a solution where you want to draw. I = don't expect the action is generic when a Sustained IP address type is requ= ested. Besides, you assumption on IP address allocation seems not valid. A mobile = host would get an IP address whatever the allocated IP address type is when= it attaches at a network, regardless of an application's IP address reques= t. >>2 Looks like I did not express myself well enough (and did not fully understa= nd your reply). Let me list some events that might help clarify... Initial state: Mobile node is connected to a network; no Sustained IP addre= ss is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indica= ting that if an application requests a Sustained IP address, it will have t= o request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Event2: A new application that also required a Sustained IP address is laun= ched App action: App requests a Sustained IP address from the IP stack using the= proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the A= PI action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustain= ed IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Note that the behavior of the IP stack in Event4 is exactly like the one in= Event1. I believe that this event is the one we have different of opinions: I think= that the default behavior of the IP stack is to request a new Sustained IP= address since it moved to a new LAN, and you think that it should do so on= ly if the application specifically requests a new Sustained IP address via = the flag you are proposing. >>2 As a matter of fact, if such a flag is defined, I cannot think of an exampl= e where it will not be used. It seems to me that applications will always r= equest a refreshed Sustained IP address (when requesting a Sustained IP add= ress). If this is correct, the flag is redundant. Seil -> Some applications, e.g. email, that are not relatively restricted f= rom optimal routing would consider a Sustained IP address without issuing t= he new flag. More applications based on such network characteristic can be = thought more than expected. And such use of existing Sustained IP address is not extraordinary, since I= P address is a resource, even in the consideration of IPv6 deployment. If a= s many as applications require new Sustained IP address, it will end up in = a lot of network resource consumption in the mobility routers where the Sus= tained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an exa= mple of an application that will request a Nomadic address since it does no= t break when the mobile node moves to a new LAN and the source IP address i= s changed. It simply restarts the socket and continue with the new source I= P address (the user will not even notice this). I did not understand the other text regarding resource consumption. I thoug= ht we agreed that even of a new Sustained IP address is requested upon each= movement to a new LAN, the effect on IP address allocation is not signific= ant. Otherwise, my initial comment on applications abusing the network usin= g your proposed flag, becomes valid again >>2 Can you provide a scenario in which an application will not request to refr= esh the Sustained IP address? It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answ= ers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case i= n the draft. On receiving this API with the SUSTAINED IP address type at th= e IP stack, it will try to get a new SUSTAINED IP address if there is no av= ailable in the currently attached access network. So, actual obtaining of t= he IP address will be tried one time while attached at a specific access ne= twork. Even some applications put this API after, the already obtained SUST= AINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the = host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, th= at is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should= show its requirement with an API among them. If it is the SUSTAINED IP add= ress, how do we expect the IP stack will try to get a new SUSTAINED IP addr= ess? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813490C65AHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

See the inline please.

 

 

Seil Jeon

 

 

 

From: Moses, D= anny [mailto:danny.moses@intel.com= ]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

As to the potential of= abuse:

Yes, I see your point = and you are correct. If the IP stack will not request a sustained IP addres= s more than once after each movement to a new LAN (with a different prefix)= , than there will be no abuse.

 

Seil -> Yes, it’s true. Thanks for correction.

 

As to the second comme= nt, please let me elaborate:

One potential implemen= tation of the IP stack in the host, can be to request a Nomadic IP address = and a  Sustained IP address whenever connecting to a network, and when= ever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

 

Seil -> Decision of which type of IP address by default= will be depending on the IP pool management policy by operators. You case = may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot o= f applications require mere Internet connectivity without session continuit= y support. So, the Sustained IP address will be requested on demand, and th= e proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an ap= plication.

 

>>2

As I mentioned at the = beginning of the description – it is a description of one alternative= . I am not assuming it is the only scenario.

Yes, I agree that many= apps require only Nomadic IP addresses, but in this example, the IP stack = in the host pre-allocates both Nomadic and Sustained IP addresses upon atta= chment…

 

Yes, we can describe a= n alternative in which a Nomadic IP address is pre-allocated upon NW connec= tion (and after every movement to a new LAN) and a Sustained (and/or Fixed)= address is allocated on-demand. Even in such a scenario, I do not see any use for this flag – see my repl= y to the second item below…

>>2

 

 

 

 

 

Another potential impl= ementation of the IP stack in the host is not to request IP addresses in ad= vance. In that case, it will issue a request for a Nomadic IP address or a = Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained – according to what is required= ) after receiving the first request from any application. In this case as well, there is no need for this flag.

 

Seil -> Another application requested just Sustained IP= address while the IP stack has already a Sustained IP address. Why should = the IP stack try to get a new one, though the application indicated simply “Sustained IP address type”? You case took a step towar= ds a solution where you want to draw. I don’t expect the action is ge= neric when a Sustained IP address type is requested.

 

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application’s IP address request.

>>2

Looks like I did not express myself well eno= ugh (and did not fully understand your reply). Let me list some events that= might help clarify…

 

Initial state: Mobile node is connected to a= network; no Sustained IP address is allocated. The IP stack sets a flag (S= ustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

 

Event1: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Event2: A new application that also required= a Sustained IP address is launched

App action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAddressNee= ded  is not set, complete the API action and associate the marked Sust= ained IP address with that port (app)

 

Event3: The mobile node moves to a new LAN

IP Stack action: Set a flag indicating that = the currently available Sustained IP address is not optimized

 

Event4: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Note that the behavior of the IP stack in Ev= ent4 is exactly like the one in Event1.

 

I believe that this event is the one we h= ave different of opinions: I think that the default behavior of the IP stac= k is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

 

 

 

 

 

 

As a matter of fact, i= f such a flag is defined, I cannot think of an example where it will not be= used. It seems to me that applications will always request a refreshed Sus= tained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

 

Seil -> Some applications, e.g. email, that are not rel= atively restricted from optimal routing would consider a Sustained IP addre= ss without issuing the new flag. More applications based on such network characteristic can be thought more than expected.<= /span>

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but I disag= ree with the email example. I categorize it as an example of an application= that will request a Nomadic address since it does not break when the mobil= e node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).

 

I did not understand t= he other text regarding resource consumption. I thought we agreed that even= of a new Sustained IP address is requested upon each movement to a new LAN= , the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again=

>>2

 

Can you provide a scen= ario in which an application will not request to refresh the Sustained IP a= ddress?

 

It was mentioned in the former comments.=

 

 

Regards,

   &nbs= p;            /Danny=

From: Seil Jeo= n [mailto:seiljeon@= av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org<= /span>
Subject: FW: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

Any comments?

 

Regards,

Seil Jeon

 

 

From: dmm [mailto:dmm-bounces@= ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org<= /span>
Subject: [DMM] Answer on raised questions for the proposed API<= /o:p>

 

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?=

If the question is right, I don’t understand what th= e question is meant, that is how the host can get a new SUSTAINED IP addres= s?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

 

Besides, the propsoed API is not used alone but with the t= hree type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

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

--_000_F0CF5715D3D1884BAC731EA1103AC2813490C65AHASMSX106gercor_-- From nobody Thu Apr 2 07:21:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804C81B2BEF for ; Thu, 2 Apr 2015 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 RDOfZWEGQtuS for ; Thu, 2 Apr 2015 07:21:56 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 84AA61B2B2B for ; Thu, 2 Apr 2015 07:21:56 -0700 (PDT) Received: by iedm5 with SMTP id m5so70120124ied.3 for ; Thu, 02 Apr 2015 07:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KmDQp2PEIdC8xeIGzcoQn07lpWMtNK/Jcps9TLaYOMI=; b=x8lKzqh305Xg3WDRNMn6frtY/YqOZXUIMgO46co0GUKfmmKvypnqraAmb8TpuUrK1S uvbjI8sWC+6mTVKzYrQ6ZhxYayzAnQ/qQ8vM4qKEgd5fAwOb234a2n+eyLyXcVqRKngK nBa+MUE0UxWHozKzLmxoQgCPUhKG/9KyaN0wPhhPEeP7QQfZshK07qWhx/KNx/kOtsDj noxEL+9R6+gDMpi/j3bG5Zy9abxdRQNyKsjnNBp9dnCTcjrkXSRcQ/xAGDIf4HHwv8k3 EKboCkfTBoqYev2LPX2ZC/14rvN64MMBXeugf8IGLsZeLVzBdSv9QynC55AWnTxfzymo 7kag== X-Received: by 10.107.151.73 with SMTP id z70mr74846726iod.41.1427984515970; Thu, 02 Apr 2015 07:21:55 -0700 (PDT) Received: from [10.252.0.17] (host83-111.cablelabs.com. [192.160.73.83]) by mx.google.com with ESMTPSA id k4sm3672454igf.0.2015.04.02.07.21.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 07:21:54 -0700 (PDT) Message-ID: <551D5082.3050904@gmail.com> Date: Thu, 02 Apr 2015 07:21:54 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Jouni , Dapeng Liu , draft-wt-dmm-fpc-cpdp@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:21:57 -0000 Folks, This emails starts a two week call for the I-D draft-wt-dmm-fpc-cpdp-00 to confirm the adoption as a DMM WG document. The call ends April 16th EOB PDT. Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption so at least the same amount supporting emails should be expected. - Jouni & Dapeng From nobody Thu Apr 2 07:24:48 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30231B2C1A for ; Thu, 2 Apr 2015 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sxIRbJoGEVfC for ; Thu, 2 Apr 2015 07:24:44 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id D817C1AC39F for ; Thu, 2 Apr 2015 07:24:43 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 02 Apr 2015 07:24:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,511,1422950400"; d="scan'208";a="550151622" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 02 Apr 2015 07:24:42 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 2 Apr 2015 15:24:41 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by LCSMSX153.ger.corp.intel.com ([10.186.165.228]) with mapi id 14.03.0224.002; Thu, 2 Apr 2015 17:24:40 +0300 From: "Moses, Danny" To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-wt-dmm-fpc-cpdp@tools.ietf.org" Thread-Topic: Call for adoption: draft-wt-dmm-fpc-cpdp-00 Thread-Index: AQHQbVBtsO+dhTRGgEK4ggH/bEihjJ05xpUw Date: Thu, 2 Apr 2015 14:24:39 +0000 Message-ID: References: <551D5082.3050904@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:24:45 -0000 SSBzdXBwb3J0IGFkb3B0aW5nIGRyYWZ0LXd0LWRtbS1mcGMtY3BkcC0wMCBhcyBhIERNTSBXRyBk b2N1bWVudC4NCg0KUmVnYXJkcywNCgkvRGFubnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEpvdW5pIEtvcmhvbmVuIFttYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbV0g DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDIsIDIwMTUgMTc6MjINClRvOiBkbW1AaWV0Zi5vcmc7 IEpvdW5pOyBEYXBlbmcgTGl1OyBkcmFmdC13dC1kbW0tZnBjLWNwZHBAdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC13dC1kbW0tZnBjLWNwZHAtMDANCg0K Rm9sa3MsDQoNClRoaXMgZW1haWxzIHN0YXJ0cyBhIHR3byB3ZWVrIGNhbGwgZm9yIHRoZSBJLUQN CiAgIGRyYWZ0LXd0LWRtbS1mcGMtY3BkcC0wMA0KdG8gY29uZmlybSB0aGUgYWRvcHRpb24gYXMg YSBETU0gV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGVuZHMgQXByaWwgMTZ0aCBFT0IgUERULg0KDQpF eHByZXNzIHlvdXIgc3VwcG9ydCBvciBvcHBvc2l0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuIER1 cmluZyB0aGUNCklFVEY5MiBtZWV0aW5nIHdlIGdvdCAxMCB2b2ljZXMgZm9yIHRoZSBhZG9wdGlv biBzbyBhdCBsZWFzdCB0aGUgc2FtZSBhbW91bnQgc3VwcG9ydGluZyBlbWFpbHMgc2hvdWxkIGJl IGV4cGVjdGVkLg0KDQoNCg0KLSBKb3VuaSAmIERhcGVuZw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkEgbWVtYmVy IG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXMKClRoaXMgZS1tYWls IGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZv cgp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBv ciBkaXN0cmlidXRpb24KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSBhbGwgY29waWVzLgo= From nobody Thu Apr 2 10:05:24 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259021ACEB8 for ; Thu, 2 Apr 2015 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 HB19QeMsWpUs for ; Thu, 2 Apr 2015 10:05:15 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 46A541ACED8 for ; Thu, 2 Apr 2015 10:05:15 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so47747031lbb.0 for ; Thu, 02 Apr 2015 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Jw8RvE+vH4R7Mhshxb3GbwFnbt277uRkCpkQf55JCFE=; b=cXC6TkdkLQLb0kjfMKOaQMZJalqgmF5haxJ1cXRtLxvVyBzHLhltmz2gnxeT4F6j41 zzt4udaeft9ZQCr6VaBXTfBEaXjmI2t11WZajZjP/OyAjfZ1ev688ai+XAqWaE1r4YtT FLRrhKHUhPAYqP+HcRAC7fnjeaNzYsVJcknyucxan1zc2VRgur5qQ8cChozj1b9r/HXs loPGSAaBtHJrnE/BIsM2l064HEYkfJAKr3Ghx0TG456iRTfXYfrlSZkyleSg1bEO3pV4 u9wYiuYzxhknyZyg+qfMOAMouMAaEYS3tBgabZdc5+s+b+JHXaXA4dxbtQQN0HxfOAnj H51w== MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr7847832lab.119.1427994313811; Thu, 02 Apr 2015 10:05:13 -0700 (PDT) Received: by 10.25.148.131 with HTTP; Thu, 2 Apr 2015 10:05:13 -0700 (PDT) In-Reply-To: <20150402161608.17612.74174.idtracker@ietfa.amsl.com> References: <20150402161608.17612.74174.idtracker@ietfa.amsl.com> Date: Thu, 2 Apr 2015 10:05:13 -0700 Message-ID: From: jouni korhonen To: "dmm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c235dcd0ec750512c0d5db Archived-At: Subject: [DMM] Fwd: New Non-WG Mailing List: Mpvdapi X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:05:22 -0000 --001a11c235dcd0ec750512c0d5db Content-Type: text/plain; charset=UTF-8 FYI.. this might of interest for those working on API extensions for DMM purposes. - Jouni ---------- Forwarded message ---------- From: IETF Secretariat Date: Thu, Apr 2, 2015 at 9:16 AM Subject: New Non-WG Mailing List: Mpvdapi To: IETF Announcement List Cc: denghui02@hotmail.com, MPVDAPI@ietf.org A new IETF non-working group email list has been created. List address: MPVDAPI@ietf.org Archive: http://www.ietf.org/mail-archive/web/mpvdapi/ To subscribe: https://www.ietf.org/mailman/listinfo/MPVDAPI Purpose: MPVD API design is very important for MPVD concept of MIF working group, MIF working group decide to write MPVD API document by build a design team , this mailing list is try to help the design team to discuss the main issues and write the document. -The IETF Area to which the list belongs -The URL or other instructions for subscribing to the listInternet Area For additional information, please contact the list administrators. --001a11c235dcd0ec750512c0d5db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

FYI.. this might of interest for those= working on API extensions for DMM purposes.

- Jouni
<= div>
---------- Forwarded message ----------<= br>From: IETF Secretariat <ietf-secretariat@ietf.o= rg>
Date: Thu, Apr 2, 2015 at 9:16 AM
Subject: New Non-= WG Mailing List: Mpvdapi
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: denghui02@hotmail.com, MPVDAPI@ietf.org


A new IETF non-working gr= oup email list has been created.

List address: MPVDAPI@ietf.org
Archive: http://www.ietf.org/mail-archive/web/mpvdapi/
To subscribe: https://www.ietf.org/mailman/listinfo/MPVDAPI

Purpose:


MPVD API design is very important for MPVD concept of MIF working group, MI= F working group decide to write MPVD API document by build a design team , = this mailing list is try to help the design team to discuss the main issues= and write the document.

-The IETF Area to which the list belongs
-The URL or other instructions for subscribing to the listInternet Area

For additional information, please contact the list administrators.


--001a11c235dcd0ec750512c0d5db-- From nobody Thu Apr 2 14:49:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3041A6FEE for ; Thu, 2 Apr 2015 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RMYwzUEsKYHV for ; Thu, 2 Apr 2015 14:49:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157B81A1AC6 for ; Thu, 2 Apr 2015 14:49:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQZ62685; Thu, 02 Apr 2015 21:49:08 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Apr 2015 22:49:07 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0158.001; Fri, 3 Apr 2015 05:49:03 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: enhanced mobility anchoring Thread-Index: AdBtd4jMiBmEnZN4SYq7vZTr5NU03AAFy13g Date: Thu, 2 Apr 2015 21:49:02 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521F0787@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.203] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521F0787szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:49:12 -0000 --_000_6E31144C030982429702B11D6746B98C521F0787szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please check your availability for teleconference next week. Thanks. http://doodle.com/ex3drz8xt4cc7m9r H Anthony Chan --_000_6E31144C030982429702B11D6746B98C521F0787szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please check your avai= lability for teleconference next week. Thanks.

http:= //doodle.com/ex3drz8xt4cc7m9r

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C521F0787szxeml557mbxchi_-- From nobody Thu Apr 2 19:12:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1851A8AEB for ; Thu, 2 Apr 2015 19:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gl9vGEYiZg4z for ; Thu, 2 Apr 2015 19:12:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9579E1A902D for ; Thu, 2 Apr 2015 19:12:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQZ73224; Fri, 03 Apr 2015 02:12:08 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Apr 2015 03:12:07 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Fri, 3 Apr 2015 10:11:36 +0800 From: h chan To: "Templin, Fred L" Thread-Topic: enhanced mobility anchoring Thread-Index: AdBtd4jM2EAkZ5QP+UmZfjSKm6JQuQAFy13gAABKOYAACNNWMA== Date: Fri, 3 Apr 2015 02:11:35 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521F0814@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521F0787@szxeml557-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832E326F5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E326F5@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.110] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521F0814szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 02:12:11 -0000 --_000_6E31144C030982429702B11D6746B98C521F0814szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The timezone in the doodle is US central time. I tried to enter 8am and 9am= in US Central time, but I am not sure whether you can change the time zone= to view it. H Anthony Chan From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Thursday, April 02, 2015 4:57 PM To: h chan Subject: RE: enhanced mobility anchoring Hi Anthony, What is the timezone represented in the doodle poll? Thanks - Fred From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of h chan Sent: Thursday, April 02, 2015 2:49 PM To: dmm@ietf.org Subject: [DMM] enhanced mobility anchoring Please check your availability for teleconference next week. Thanks. http://doodle.com/ex3drz8xt4cc7m9r H Anthony Chan --_000_6E31144C030982429702B11D6746B98C521F0814szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The timezone in the do= odle is US central time. I tried to enter 8am and 9am in US Central time, b= ut I am not sure whether you can change the time zone to view it.

 

H Anthony Chan

 

From: Templin,= Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, April 02, 2015 4:57 PM
To: h chan
Subject: RE: enhanced mobility anchoring

 

Hi Anthony,=

 

What is the timezone r= epresented in the doodle poll?

 

Thanks - Fred

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of h chan
Sent: Thursday, April 02, 2015 2:49 PM
To: dmm@ietf.org
Subject: [DMM] enhanced mobility anchoring

 

Please check your avai= lability for teleconference next week. Thanks.

http:= //doodle.com/ex3drz8xt4cc7m9r

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C521F0814szxeml557mbxchi_-- From nobody Fri Apr 3 05:39:11 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9061A9173 for ; Fri, 3 Apr 2015 05:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 j4R99Ceq11CZ for ; Fri, 3 Apr 2015 05:39:08 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 D2EEC1A9172 for ; Fri, 3 Apr 2015 05:39:07 -0700 (PDT) Received: by obvd1 with SMTP id d1so170101909obv.0 for ; Fri, 03 Apr 2015 05:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wIOXlfWvggFQtjLgmT4uLTmfdDTBHAvJeCC7eBgAp+s=; b=uhSdf3+inQ0O0UDlaskctXeLRU7FoKUaSotnGtTXM8Y+bwkz69YgaCUh55V0/tIjuT 2FoUmPt27lPa0YxxhFsrTGsnuxGLMDDXcTV5rsYyG64hRd9Hmp2d0Vbx3FlaGElEKMuD bu7iRu7ZsqCTdonsALonzX50M32/5xKvkNFXHTv7VLgPOJO0rdGRsl/Nph8P7aOeh7XM V3Nnzs8sUNEj0f6Ec0V6EbWYTqPCyzmnVHTduDZfNVEKL5DWsfndQdOXDe/To6w+RYG5 9orM6XLpWYk48hlXUs2iSRudG+1IOr07yzlkR5gldVPiHYiZdjoV++zYQfuxFB7JdsIK wuzg== MIME-Version: 1.0 X-Received: by 10.182.91.35 with SMTP id cb3mr2711986obb.87.1428064747335; Fri, 03 Apr 2015 05:39:07 -0700 (PDT) Received: by 10.60.161.109 with HTTP; Fri, 3 Apr 2015 05:39:07 -0700 (PDT) In-Reply-To: <551C0877.1060100@gmail.com> References: <551C0877.1060100@gmail.com> Date: Fri, 3 Apr 2015 07:39:07 -0500 Message-ID: From: Lyle Bertz To: dmm@ietf.org, draft-perkins-dmm-4283mnids@tools.ietf.org Content-Type: multipart/alternative; boundary=e89a8f92414efb4a040512d13b43 Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 12:39:09 -0000 --e89a8f92414efb4a040512d13b43 Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft as a WG document; I only have an editorial comment - Section 2 makes reference to an EPC and a few other acronyms. Expanding a few of these out may help some readers. On Wed, Apr 1, 2015 at 10:02 AM, Jouni Korhonen wrote: > Folks, > > This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 > to confirm the aadoption s a DMM WG document. The call ends April 15th EOB > PST. > > Express your support or opposition to the mailing list. During the IETF92 > meeting we got 7 voices for the adoption so at least the same amount > supporting emails should be expected. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --e89a8f92414efb4a040512d13b43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
I support the adoption of this draft as a =
WG document;

I only have an editorial comment - Section 2 makes refe=
rence to an EPC and a few other acronyms.  Expanding a few of these out may=
 help some readers.
=C2=A0
On Wed, Apr 1, 2015 at 10:02 AM, Jouni Korhone= n <jouni.nospam@gmail.com> wrote:
Folks,

This emails starts a two week call for the I-D
=C2=A0 draft-perkins-dmm-4283mnids-01
to confirm the aadoption s a DMM WG document. The call ends April 15th EOB = PST.

Express your support or opposition to the mailing list. During the IETF92 m= eeting we got 7 voices for the adoption so at least the same amount support= ing emails should be expected.

- Jouni & Dapeng

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--e89a8f92414efb4a040512d13b43-- From nobody Fri Apr 3 09:37:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112761ACD2E for ; Fri, 3 Apr 2015 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.802 X-Spam-Level: ** X-Spam-Status: No, score=2.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 7Mvj4fXhutiE for ; Fri, 3 Apr 2015 09:37:47 -0700 (PDT) Received: from SNT004-OMC4S49.hotmail.com (snt004-omc4s49.hotmail.com [65.54.51.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C901AC43A for ; Fri, 3 Apr 2015 09:37:47 -0700 (PDT) Received: from SNT407-EAS77 ([65.55.90.200]) by SNT004-OMC4S49.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 3 Apr 2015 09:37:46 -0700 X-TMN: [jZDuq/ixrExksiRYGH4eCY38W/bJkFYt] X-Originating-Email: [cmccvic@outlook.com] Message-ID: From: "Vic Liu(CMCC)" To: "'Dapeng Liu'" , Date: Sat, 4 Apr 2015 00:40:10 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D06E6F.E80548B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBuItPK6MREoXqLTWWI4FGokr3stg== Content-Language: zh-cn X-OriginalArrivalTime: 03 Apr 2015 16:37:46.0591 (UTC) FILETIME=[83FF56F0:01D06E2C] Archived-At: Cc: weixinpeng@huawei.com Subject: Re: [DMM] DMM API: http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 16:37:50 -0000 ------=_NextPart_000_0055_01D06E6F.E80548B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi=20 =20 Some comments as follows: =20 In section 3.1 Types of IP Addresses, it=E2=80=99s not very clear to = disclose the relationship between Fix IP Address and DMM. It=E2=80=99s = better to add some discerptions for further clarification.=20 Secondly, for Sustained IP Address and Nomadic IP Address, reachability = is not (not only) the most important point of distinction. So the two = definition seem a little confusion. Hope this could be more specify. =20 Also I have a question as follows: Applications running as servers at a published IP address require a = Fixed IP Address. Long-standing applications (e.g., an SSH session) may = also require this type of address. Those applications could use a = Sustained IP Address, but that can produce sub-optimal results if the = mobile host ends up far from the anchor gateway.>>>>[For the application = point of view, the sustained or fixed IP address is important. Could = this part have more explanations on the balance of the sub-optimal = results and better ways? It=E2=80=99s a little confusing.]<<< = Enterprise applications that connect to an enterprise network via = virtual LAN require a Fixed IP Address. =20 =20 ALL THE BEST! -------------------------------------------------------------------------= -------------------- Vic Liu China Mobile Research Network Dept. Mobile: +86- 13810761678 Email: liuzhiheng@chinamobile.com -------------------------------------------------------------------------= -------------------- =E3=80=8C=E6=A2=A6=E3=81=AF=E9=80=83=E3=81=92=E3=81=AA=E3=81=84=E3=80=81=E9= =80=83=E3=81=92=E3=82=8B=E3=81=AE=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E8=87= =AA=E5=88=86=E3=81=A0=E3=80=8D =20 =20 =20 =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Dapeng Liu [mailto:maxpassion@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2015=E5=B9=B43=E6=9C=8831=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C 17:52 =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm@ietf.org =E6=8A=84=E9=80=81: Alexandru Petrescu; Vic Liu; weixinpeng@huawei.com; = Seil Jeon =E4=B8=BB=E9=A2=98: DMM API: = http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03 =20 Folks, =20 I would like to reaffirm that the technical comments that I made is = individual opinion (without co-chair=E2=80=99s hat).=20 =20 To facilitate the discussion, I have the following suggestions: =20 1. If you are OK with the DMM API approach in general, but you have = comments to this specific proposal: =20 1.1 If you think the proposal can be improved: Then please suggest the changes that you think can improve = the proposal (providing text changes) =20 1.2 If you think we need a new proposal: You can provide the reason why this proposal does not work. and = probably new idea that works. =20 2. Provide other comments if it not belongs to the above case. =20 =20 Thanks, --=20 Dapeng Liu ------=_NextPart_000_0055_01D06E6F.E80548B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

Some comments as = follows:

 

In section 3.1 =C2=A0Types of IP Addresses, it=E2=80=99s = not very clear to disclose the relationship between Fix IP Address and = DMM. It=E2=80=99s better to add some discerptions for further = clarification.

Secondly, for Sustained IP Address and Nomadic IP Address, = reachability is not (not only) the most important point of distinction. = So the two definition seem a little confusion. Hope this could be more = specify.

 

Also I have a question as follows:

=C2=A0=C2=A0 Applications running = as servers at a published IP address require a Fixed IP Address.=C2=A0 = Long-standing applications (e.g., an SSH session) may also require this = type of address.=C2=A0 Those applications could use a Sustained IP = Address, but that can produce sub-optimal results if the mobile host = ends up far from the anchor gateway.>>>>[For the application = point of view, the sustained or fixed IP address is important. Could = this part have more explanations on the balance of the sub-optimal = results and better ways? It=E2=80=99s a little = confusing.]<<<=C2=A0 Enterprise applications that connect to an = enterprise network via virtual LAN require a Fixed IP = Address.

 

 

ALL THE BEST!

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

Vic Liu

China Mobile Research Network Dept.

Mobile: +86- 13810761678

Email: liuzhiheng@chinamobile.com

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

=E3=80=8C= =E6=A2=A6= =E3=81=AF=E9=80=83=E3=81=92=E3=81=AA=E3=81=84=E3=80=81= =E9=80=83= =E3=81=92=E3=82=8B=E3=81=AE=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E8=87=AA=E5= =88=86=E3=81=A0=E3=80=8D=

 

 

 

 

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Dapeng Liu [mailto:maxpassion@gmail.com] =
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8831=E6=97=A5, = =E6=98=9F=E6=9C=9F=E4=BA=8C = 17:52
=E6=94=B6=E4=BB=B6=E4=BA=BA: = dmm@ietf.org
=E6=8A=84=E9=80=81: Alexandru Petrescu; Vic = Liu; weixinpeng@huawei.com; Seil = Jeon
=E4=B8=BB=E9=A2=98: DMM API: = http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03

 

Folks,

 

I would like to reaffirm that the = technical comments that I made is individual opinion (without = co-chair=E2=80=99s hat). 

 

To facilitate the discussion, I = have the following suggestions:

 

1. If you are OK with the DMM API = approach in general, but you have comments to this specific = proposal:

=C2=A0=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0 1.1 If = you think the proposal can be = improved:

      =C2=A0=C2=A0=C2=A0=C2=A0 Then please = suggest the changes that you think can improve the proposal (providing = text changes)

=C2=A0=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0 1.2 If = you think we need a new proposal:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You can provide the reason why this proposal does not work. = and probably new idea that works.

=C2=A0=C2=A0=C2=A0

2. Provide other comments if it not belongs to the above = case.

 

 

Thanks,

-- 

Dapeng = Liu

------=_NextPart_000_0055_01D06E6F.E80548B0-- From nobody Fri Apr 3 10:01:31 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129CD1ACDAB for ; Fri, 3 Apr 2015 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 V-naSEbRAo_r for ; Fri, 3 Apr 2015 10:01:28 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 A16831ACD9C for ; Fri, 3 Apr 2015 10:01:28 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so98632426igb.1 for ; Fri, 03 Apr 2015 10:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GbNCrhYVkTIJ2JKFkLCn2Pr2j5+JhoCGUDh1okuYwqA=; b=AXbVUK54aHeG9PqlwZ7WmyWUOdGZBYu7JAqZ/5flv4fOgv2jRbMp6Exm/8JmXZqNiy JyL1Y3cR3V2iBOQlxvTWCtxHyNm+jORelbmqtLoGu3Fg0GN/ncWHcj6IL7lg97fgqQn6 4pKdxesvyQXiN4QKciWUnu6P1uobePbZ9RWJhJtsS4nBePCQ+Uzk3/ezeAN3MV0mcEQc aKP94RcM7Fe54T53vJtWjMFCLx69BW0JZVbodGPWslof8epWDjAQ4DCwZYlUFsjLQG/V hnEqAJCbI4SnTSZCHhoKB6WmIfaTEp02SV5Ta3hIhjlawHNosUczHDh3CvVTzIDdAlyr 8GDg== X-Received: by 10.50.79.132 with SMTP id j4mr6005161igx.33.1428080488173; Fri, 03 Apr 2015 10:01:28 -0700 (PDT) Received: from ?IPv6:2620:0:2b10:210:5154:a533:88ae:9514? ([2620:0:2b10:210:5154:a533:88ae:9514]) by mx.google.com with ESMTPSA id o5sm1808412igw.11.2015.04.03.10.01.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 10:01:26 -0700 (PDT) Message-ID: <551EC765.4050606@gmail.com> Date: Fri, 03 Apr 2015 10:01:25 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-wt-dmm-fpc-cpdp@tools.ietf.org References: <551D5082.3050904@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:01:30 -0000 [as an individual contributor] I support the adoption of this document. - Jouni 4/2/2015, 7:21 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th > EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption so at least the same > amount supporting emails should be expected. > > > > - Jouni & Dapeng From nobody Fri Apr 3 10:01:54 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE781ACDA2 for ; Fri, 3 Apr 2015 10:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 5vNFUN4Gem4E for ; Fri, 3 Apr 2015 10:01:50 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 4AEB81ACD9E for ; Fri, 3 Apr 2015 10:01:48 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so106680476ied.1 for ; Fri, 03 Apr 2015 10:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7MTymhBZTcVNQBZYjQJfjYM07Ng2iJPTo0q89F+LDkI=; b=wLau44wr0jMXqeTayXmo2+IX58Xrcr3H925B/F3iinPOnQA6o3JWpcO1hNSwYxlTOc 9Njp2CPCC2+a34ATtNUlmfC4W4fN/YtjfqrckoTBup96eJZA4o4lpusNkHPtowVakQGm gw7spL9o5Qsgm8tcs0t9/8jcpcVSksyI3LtZYGhXToaPMdvzsBo/Uda/fBQS8fiSeQ9T AhqgFfWtKQ7tToNEqy+is1RmVNFdRSQQRIbvSU/X42RQiHMlIR0Vy0EosMtSxP7Gq4Jy BRNEEf/TrGZQXo+u9ed9JYm4422AtYzzQt7ItoF+KQmFn9N52y5f8PspRI0M5ppZmwE/ Tu9w== X-Received: by 10.107.169.35 with SMTP id s35mr5239871ioe.46.1428080507837; Fri, 03 Apr 2015 10:01:47 -0700 (PDT) Received: from ?IPv6:2620:0:2b10:210:5154:a533:88ae:9514? ([2620:0:2b10:210:5154:a533:88ae:9514]) by mx.google.com with ESMTPSA id y124sm3614971iod.13.2015.04.03.10.01.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 10:01:46 -0700 (PDT) Message-ID: <551EC779.6070402@gmail.com> Date: Fri, 03 Apr 2015 10:01:45 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-perkins-dmm-4283mnids@tools.ietf.org References: <551C0877.1060100@gmail.com> In-Reply-To: <551C0877.1060100@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:01:52 -0000 [as an individual contributor] I support the adoption of this document. - Jouni 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 > to confirm the aadoption s a DMM WG document. The call ends April 15th > EOB PST. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 7 voices for the adoption so at least the same > amount supporting emails should be expected. > > - Jouni & Dapeng From nobody Fri Apr 3 11:12:58 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896871ACEB0 for ; Fri, 3 Apr 2015 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1CI0rqUOzQmJ for ; Fri, 3 Apr 2015 11:12:56 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6181ACEAD for ; Fri, 3 Apr 2015 11:12:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t33ICteX002552; Fri, 3 Apr 2015 13:12:55 -0500 Received: from XCH-BLV-308.nw.nos.boeing.com (xch-blv-308.nw.nos.boeing.com [130.247.25.220]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t33ICp0V002430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 3 Apr 2015 13:12:52 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.66]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 11:12:51 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Thread-Index: AdBuOH8TeAFQuqtCTx21iPn+L07HKg== Date: Fri, 3 Apr 2015 18:12:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 18:12:57 -0000 Hi Danny and Alper, In this draft, you seem to be considering only DHCPv6 address delegation fo= r when the node is acting as a mobile host. I am wondering if there are simil= ar considerations for DHCPv6 prefix delegation for when the node is acting as a mobile router. But then, I wonder whether any type of prefix delegation other than a fixed prefix makes any sense. For example, if the mobile router received a nomadic prefix delegation, would it need to renumber its connected networks every time it moves and receives a new nomadic prefix? Should this document discuss prefix delegation considerations for mobile routers, or only address delegation for mobile hosts? Thanks - Fred fred.l.templin@boeing.com From nobody Fri Apr 3 13:37:31 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3E1A0318 for ; Fri, 3 Apr 2015 13:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 y81ej6P8j37u for ; Fri, 3 Apr 2015 13:37:28 -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 47D151A1A8F for ; Fri, 3 Apr 2015 13:37:28 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9E4173B4647; Fri, 3 Apr 2015 22:37:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8033F238075; Fri, 3 Apr 2015 22:37:26 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 3 Apr 2015 22:37:26 +0200 From: To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-wt-dmm-fpc-cpdp@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 Thread-Index: AQHQbVBjag4VpIPy7UCeItcURcITEp07Y3uAgABdoDA= Date: Fri, 3 Apr 2015 20:37:26 +0000 Message-ID: <31036_1428093446_551EFA06_31036_14526_1_81C77F07008CA24F9783A98CFD706F7114D0956B@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <551D5082.3050904@gmail.com> <551EC765.4050606@gmail.com> In-Reply-To: <551EC765.4050606@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.3.122720 Archived-At: Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:37:30 -0000 Hi, I support the adoption of this I-D pierrick 4/2/2015, 7:21 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th=20 > EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption so at least the same=20 > amount supporting emails should be expected. > > > > - Jouni & Dapeng _______________________________________________ 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 Fri Apr 3 13:38:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7FF1A0318 for ; Fri, 3 Apr 2015 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 EJM5mRnoRgnl for ; Fri, 3 Apr 2015 13:38:19 -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 80EC11A032D for ; Fri, 3 Apr 2015 13:38:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5464C3B4647; Fri, 3 Apr 2015 22:38:17 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 36CD74C07E; Fri, 3 Apr 2015 22:38:17 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 3 Apr 2015 22:38:17 +0200 From: To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-perkins-dmm-4283mnids@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 Thread-Index: AQHQbIzkTtbxblpyKUa49Nx6ApivaZ07ZRmAgABd63A= Date: Fri, 3 Apr 2015 20:38:15 +0000 Message-ID: <21829_1428093497_551EFA39_21829_13234_1_81C77F07008CA24F9783A98CFD706F7114D09580@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <551C0877.1060100@gmail.com> <551EC779.6070402@gmail.com> In-Reply-To: <551EC779.6070402@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.3.122720 Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:38:21 -0000 I support adoption of this I-D 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 > to confirm the aadoption s a DMM WG document. The call ends April 15th=20 > EOB PST. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 7 voices for the adoption so at least the same=20 > amount supporting emails should be expected. > > - Jouni & Dapeng _______________________________________________ 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 Fri Apr 3 17:04:04 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CFC1A87EC for ; Fri, 3 Apr 2015 17:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 f4ysHNrFl4F2 for ; Fri, 3 Apr 2015 17:04:01 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 AA7871A87E9 for ; Fri, 3 Apr 2015 17:04:01 -0700 (PDT) Received: by igcau2 with SMTP id au2so72130107igc.1 for ; Fri, 03 Apr 2015 17:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=inNvpD8apN4xKliNS1o6hh3HO4c+QBOGzxtn5g0PhuU=; b=mcYD97aIgiTKeRKKN7rP+I+uMJhx1QmsLRnLrXtu1NosnR15A4D78vbSwgHrmRtXZy rFQLZ5UzmPzV3hXe68eUBHzZ4oI72mPIAPzjQ0y0xWKpKv9ZmYDGEi6/EhWu8FC7N+8C 7dnQ9BCxpImjSO4zGjnMtvRDu5iBpwxgWcBhWEIH8Uvkk5pUXzi6GbT/1cP+UiaFDH5v FXW71FpAVfv+VWnvWKLOU61AR6pmMTngI3+vEcUAR3YnQXJW9aP3lOT4iig7JYP8CCvA pBVtjhB/DNn9gqwXPBW0TWQRKUKmQ/Zw0RMwuK55uo0obT0zMyLLEKKg5hgFraC8Ss6p fgsw== X-Received: by 10.50.50.209 with SMTP id e17mr3839204igo.37.1428105841111; Fri, 03 Apr 2015 17:04:01 -0700 (PDT) Received: from [172.29.103.220] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id 37sm2921344ioj.0.2015.04.03.17.03.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 17:04:00 -0700 (PDT) Message-ID: <551F2A6D.6080100@gmail.com> Date: Fri, 03 Apr 2015 17:03:57 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Jouni , Dapeng Liu , draft-yegin-dmm-ondemand-mobility@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 00:04:03 -0000 Folks, This email starts a two week adoption call for the I-D draft-yegin-dmm-ondemand-mobility-03 to confirm its adoption as a DMM WG document and as a basis for the technical solution. The call ends April 17th EOB PDT. Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption and 3 against. we expect at least the same amount of expressed opinions on the list. Notice that version -01 of this I-D had an IPR declared to it. See https://datatracker.ietf.org/ipr/2309/ - Jouni & Dapeng From nobody Fri Apr 3 17:34:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF121A889C for ; Fri, 3 Apr 2015 17:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 VSNPijqBRxG4 for ; Fri, 3 Apr 2015 17:34:49 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 094531A889B for ; Fri, 3 Apr 2015 17:34:49 -0700 (PDT) Received: by patj18 with SMTP id j18so131231592pat.2 for ; Fri, 03 Apr 2015 17:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=USjfQe8rrdNE9l9qQgQ0br1M2pQM4Alw06QdKjeGtcY=; b=aJLXyuNlls6kygX4XHYWrDRchWMP5ZZ9xJBBFAjh7EGeHpwdFuIs6tUk1axUnt2Q3v 6QalNrjmpw10qENRDtCl566ej4kiZqU3nLz4yWMCyrPa4AUqRB7v1QZiq1oPgqjVEy6w /tCeylLhYaV1hfzsy/VYgs6nkK0SzI7S1GZHy+uHtHuyq/0jr+lcTtAu+ahiHlqvQWRq kwgzpxDpXrxyBO+r899UYUNhzjCFYto60tGaVuHx7C0Wrf4CzH8nHqjgYbvq8lYhFNOB 0zKdAz9E+TRvIXqWe2exqGSysG03lFYTwkxafF7lGYqYKbo71deOmrEOuJYpNrElPsB+ gGDQ== X-Received: by 10.66.183.47 with SMTP id ej15mr8231358pac.34.1428107688738; Fri, 03 Apr 2015 17:34:48 -0700 (PDT) Received: from [10.0.1.6] ([121.152.87.242]) by mx.google.com with ESMTPSA id da10sm9254037pac.42.2015.04.03.17.34.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 17:34:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Jong-Hyouk Lee In-Reply-To: <21829_1428093497_551EFA39_21829_13234_1_81C77F07008CA24F9783A98CFD706F7114D09580@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Sat, 4 Apr 2015 09:34:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551C0877.1060100@gmail.com> <551EC779.6070402@gmail.com> <21829_1428093497_551EFA39_21829_13234_1_81C77F07008CA24F9783A98CFD706F7114D09580@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: "dmm@ietf.org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "draft-perkins-dmm-4283mnids@tools.ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 00:34:50 -0000 I support the adoption of this draft. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Apr 4, 2015, at 5:38 AM, pierrick.seite@orange.com wrote: >=20 >=20 > I support adoption of this I-D >=20 > 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >> Folks, >>=20 >> This emails starts a two week call for the I-D >> draft-perkins-dmm-4283mnids-01 >> to confirm the aadoption s a DMM WG document. The call ends April = 15th=20 >> EOB PST. >>=20 >> Express your support or opposition to the mailing list. During the >> IETF92 meeting we got 7 voices for the adoption so at least the same=20= >> amount supporting emails should be expected. >>=20 >> - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information 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 = delete 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. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sat Apr 4 01:08:57 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB01B2A6F for ; Sat, 4 Apr 2015 01:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H0rnTesEs30H for ; Sat, 4 Apr 2015 01:08:55 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 287BC1B2A6C for ; Sat, 4 Apr 2015 01:08:55 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 04 Apr 2015 01:08:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,521,1422950400"; d="scan'208";a="690321260" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga001.fm.intel.com with ESMTP; 04 Apr 2015 01:08:54 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 4 Apr 2015 09:08:53 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by LCSMSX153.ger.corp.intel.com ([10.186.165.228]) with mapi id 14.03.0224.002; Sat, 4 Apr 2015 11:08:52 +0300 From: "Moses, Danny" To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AQHQbmreC26eSvaAWUWZwOIHUZ4JXp08f9Qw Date: Sat, 4 Apr 2015 08:08:51 +0000 Message-ID: References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 08:08:56 -0000 I support adopting draft-yegin-dmm-ondemand-mobility-03 as a DMM WG documen= t. Regards, /Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Saturday, April 04, 2015 03:04 To: dmm@ietf.org; Jouni; Dapeng Liu; draft-yegin-dmm-ondemand-mobility@tool= s.ietf.org Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Folks, This email starts a two week adoption call for the I-D draft-yegin-dmm-ondemand-mobility-03 to confirm its adoption as a DMM WG document and as a basis for the technic= al solution. The call ends April 17th EOB PDT. Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption and 3 against. we expect a= t least the same amount of expressed opinions on the list. Notice that version -01 of this I-D had an IPR declared to it. See https://= datatracker.ietf.org/ipr/2309/ - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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 Sun Apr 5 04:22:54 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116E51AC436 for ; Sun, 5 Apr 2015 04:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7fvcVZRi-eQN for ; Sun, 5 Apr 2015 04:22:44 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id DC0481AC431 for ; Sun, 5 Apr 2015 04:22:43 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 05 Apr 2015 04:22:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,527,1422950400"; d="scan'208,217";a="690599666" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga001.fm.intel.com with ESMTP; 05 Apr 2015 04:22:41 -0700 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 5 Apr 2015 12:22:39 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by hasmsx108.ger.corp.intel.com ([10.184.198.18]) with mapi id 14.03.0224.002; Sun, 5 Apr 2015 14:22:38 +0300 From: "Moses, Danny" To: Seil Jeon Thread-Topic: [DMM] Answer on raised questions for the proposed API Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgIJAtYDAlqa+uYCqJZpkgDQIjNOAPZdtnGbTMJ10JuEMu4w Date: Sun, 5 Apr 2015 11:22:37 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> In-Reply-To: <001d01d06f24$f601c000$e2054000$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490CB7DHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 11:22:53 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490CB7DHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Seil, By now we have been discussing this for quite some time and clearly we did = not succeed in convincing each other. I suggest we try again when we have a chance to meet face to face. Meanwhil= e, let's listen to what other people have to say on this matter. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 01:16 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Resent. Seil From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. I marked current replies with ">>" and previous repl= ies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request= a sustained IP address more than once after each movement to a new LAN (wi= th a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request= a Nomadic IP address and a Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any appl= ications requesting any addresses. This way, whenever an application is lau= nched and requests either a Nomadic or Sustained IP address, the stack can = provide one without having to issue a request to the network. In this case,= there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one of t= hem. What if only the Nomadic IP address is basically allocated upon a netw= ork attachment? That is, a lot of applications require mere Internet connec= tivity without session continuity support. So, the Sustained IP address wil= l be requested on demand, and the proposed flag will be used to get a new S= ustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of= one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this = example, the IP stack in the host pre-allocates both Nomadic and Sustained = IP addresses upon attachment... >> As I said, it could be, but not as general one. The proposed API is usef= ul through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-al= located upon NW connection (and after every movement to a new LAN) and a Su= stained (and/or Fixed) address is allocated on-demand. Even in such a scena= rio, I do not see any use for this flag - see my reply to the second item b= elow... >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to requ= est IP addresses in advance. In that case, it will issue a request for a No= madic IP address or a Sustained IP address the first time an application re= quests one and use it for subsequent requests as long as it is not moving t= o a different LAN. Once it moves, it will again request a new IP address (N= omadic or Sustained - according to what is required) after receiving the fi= rst request from any application. In this case as well, there is no need fo= r this flag. > Another application requested just Sustained IP address while the IP stac= k has already a Sustained IP address. Why should the IP stack try to get a = new one, though the application indicated simply "Sustained IP address type= "? You case took a step towards a solution where you want to draw. I don't = expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile = host would get an IP address whatever the allocated IP address type is when= it attaches at a network, regardless of an application's IP address reques= t. >>2 Looks like I did not express myself well enough (and did not fully understa= nd your reply). Let me list some events that might help clarify... Initial state: Mobile node is connected to a network; no Sustained IP addre= ss is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indica= ting that if an application requests a Sustained IP address, it will have t= o request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Event2: A new application that also required a Sustained IP address is laun= ched App action: App requests a Sustained IP address from the IP stack using the= proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the A= PI action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustain= ed IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Note that the behavior of the IP stack in Event4 is exactly like the one in= Event1. I believe that this event is the one we have different of opinions: I think= that the default behavior of the IP stack is to request a new Sustained IP= address since it moved to a new LAN, and you think that it should do so on= ly if the application specifically requests a new Sustained IP address via = the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an exampl= e where it will not be used. It seems to me that applications will always r= equest a refreshed Sustained IP address (when requesting a Sustained IP add= ress). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from op= timal routing would consider a Sustained IP address without issuing the new= flag. More applications based on such network characteristic can be though= t more than expected. And such use of existing Sustained IP address is not extraordinary, since I= P address is a resource, even in the consideration of IPv6 deployment. If a= s many as applications require new Sustained IP address, it will end up in = a lot of network resource consumption in the mobility routers where the Sus= tained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an exa= mple of an application that will request a Nomadic address since it does no= t break when the mobile node moves to a new LAN and the source IP address i= s changed. It simply restarts the socket and continue with the new source I= P address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP addres= s is used. You could get some insight from such kind of application not car= ing much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thoug= ht we agreed that even of a new Sustained IP address is requested upon each= movement to a new LAN, the effect on IP address allocation is not signific= ant. Otherwise, my initial comment on applications abusing the network usin= g your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address= is requested upon receiving *new* flag from an application, as a preferenc= e for a source address selection. You need to read our draft classifying th= e categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference canno= t be abuse. Regarding "abuse", I see it in your default behavior you're ass= uming here. In your scenario, a new app initiated in a new network will be = forced to use a newly obtained Sustained IP address. You see that? You tota= lly block the possibility to be considered by the default source address se= lection rules defined in RFC6724. But in our draft, in case the need of a n= ewly obtained Sustained IP address is prioritized, the proposed *new* flag = can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refr= esh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answ= ers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case i= n the draft. On receiving this API with the SUSTAINED IP address type at th= e IP stack, it will try to get a new SUSTAINED IP address if there is no av= ailable in the currently attached access network. So, actual obtaining of t= he IP address will be tried one time while attached at a specific access ne= twork. Even some applications put this API after, the already obtained SUST= AINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the = host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, th= at is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should= show its requirement with an API among them. If it is the SUSTAINED IP add= ress, how do we expect the IP stack will try to get a new SUSTAINED IP addr= ess? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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_F0CF5715D3D1884BAC731EA1103AC2813490CB7DHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Seil,

 

By now we have been di= scussing this for quite some time and clearly we did not succeed in convinc= ing each other.

I suggest we try again= when we have a chance to meet face to face. Meanwhile, let's listen to wha= t other people have to say on this matter.

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Resent.

 

Seil

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm@ietf.org'
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

See the inline please. I marked current repl= ies with “>>” and previous replies with “>”= ; for you to catch them easily.

 

Regards,

Seil

 

 

From: Moses, D= anny [mailto:da= nny.moses@intel.com]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@= av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

See the inline please.

 

 

Seil Jeon

 

 

From: Moses, D= anny [mailto:da= nny.moses@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

As to the potential of= abuse:

Yes, I see your point = and you are correct. If the IP stack will not request a sustained IP addres= s more than once after each movement to a new LAN (with a different prefix)= , than there will be no abuse.

 

> Yes, it’s true. Thanks for correction.

 

As to the second comme= nt, please let me elaborate:

One potential implemen= tation of the IP stack in the host, can be to request a Nomadic IP address = and a  Sustained IP address whenever connecting to a network, and when= ever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

 

> Decision of which type of IP address by default will = be depending on the IP pool management policy by operators. You case may co= rrespond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applic= ations require mere Internet connectivity without session continuity suppor= t. So, the Sustained IP address will be requested on demand, and the propos= ed flag will be used to get a new Sustained IP address by expressing the explicit request by an application.=

 

>>2

As I mentioned at the = beginning of the description – it is a description of one alternative= . I am not assuming it is the only scenario.

Yes, I agree that many= apps require only Nomadic IP addresses, but in this example, the IP stack = in the host pre-allocates both Nomadic and Sustained IP addresses upon atta= chment…

 

>> As I said, it could be, but not as general one. T= he proposed API is useful through the explicit expression for any potential= scenarios.

 

Yes, we can describe a= n alternative in which a Nomadic IP address is pre-allocated upon NW connec= tion (and after every movement to a new LAN) and a Sustained (and/or Fixed)= address is allocated on-demand. Even in such a scenario, I do not see any use for this flag – see my repl= y to the second item below…

>>2

 

>> My answer was already given in following answer i= n previous email.

 

Another potential impl= ementation of the IP stack in the host is not to request IP addresses in ad= vance. In that case, it will issue a request for a Nomadic IP address or a = Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained – according to what is required= ) after receiving the first request from any application. In this case as well, there is no need for this flag.

 

> Another application requested just Sustained IP addre= ss while the IP stack has already a Sustained IP address. Why should the IP= stack try to get a new one, though the application indicated simply “Sustained IP address type”? You case took a step towar= ds a solution where you want to draw. I don’t expect the action is ge= neric when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application’s IP address request.

 

>>2

Looks like I did not express myself well eno= ugh (and did not fully understand your reply). Let me list some events that= might help clarify…

 

Initial state: Mobile node is connected to a= network; no Sustained IP address is allocated. The IP stack sets a flag (S= ustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

 

Event1: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Event2: A new application that also required= a Sustained IP address is launched

App action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAddressNee= ded  is not set, complete the API action and associate the marked Sust= ained IP address with that port (app)

 

Event3: The mobile node moves to a new LAN

IP Stack action: Set a flag indicating that = the currently available Sustained IP address is not optimized

 

Event4: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Note that the behavior of the IP stack in Ev= ent4 is exactly like the one in Event1.

 

I believe that this event is the one we h= ave different of opinions: I think that the default behavior of the IP stac= k is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

 

>> You can see my answer at the lowest “>&g= t;” in this mail.

 

As a matter of fact, i= f such a flag is defined, I cannot think of an example where it will not be= used. It seems to me that applications will always request a refreshed Sus= tained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

 

> Some applications, e.g. email, that are not relativel= y restricted from optimal routing would consider a Sustained IP address wit= hout issuing the new flag. More applications based on such network characteristic can be thought more than expected.

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but I disag= ree with the email example. I categorize it as an example of an application= that will request a Nomadic address since it does not break when the mobil= e node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).

 

>> The example was given as a benefit when the exist= ing Sustained IP address is used. You could get some insight from such kind= of application not caring much the routing distance even on the Sustained IP address.

 

I did not understand t= he other text regarding resource consumption. I thought we agreed that even= of a new Sustained IP address is requested upon each movement to a new LAN= , the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again=

>>2

 

>> No, our draft didn’t say so. Our idea is th= at a new Sustained IP address is requested upon receiving *new* flag from a= n application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again.<= o:p>

 

Besides, I don’t understand what is abused. Deliveri= ng its preference cannot be abuse. Regarding “abuse”, I see it = in your default behavior you’re assuming here. In your scenario, a ne= w app initiated in a new network will be forced to use a newly obtained Sustaine= d IP address. You see that? You totally block the possibility to be conside= red by the default source address selection rules defined in RFC6724. But i= n our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* f= lag can be used by app’s request, thus it will be selected with prior= ity.

 

Can you provide a scen= ario in which an application will not request to refresh the Sustained IP a= ddress?

 

> It was mentioned in the former comments.

 

 

Regards,

   &nbs= p;            /Danny=

From: Seil Jeo= n [mailto:seiljeon@= av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org<= /span>
Subject: FW: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

Any comments?

 

Regards,

Seil Jeon

 

 

From: dmm [mailto:dmm-bounces@= ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org<= /span>
Subject: [DMM] Answer on raised questions for the proposed API<= /o:p>

 

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?=

If the question is right, I don’t understand what th= e question is meant, that is how the host can get a new SUSTAINED IP addres= s?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

 

Besides, the propsoed API is not used alone but with the t= hree type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

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

---------------------------------------------------------------------
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_F0CF5715D3D1884BAC731EA1103AC2813490CB7DHASMSX106gercor_-- From nobody Sun Apr 5 04:49:14 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00821A0181 for ; Sun, 5 Apr 2015 04:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Q1G3R50jr2in for ; Sun, 5 Apr 2015 04:49:10 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id B48421A017F for ; Sun, 5 Apr 2015 04:49:10 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 05 Apr 2015 04:49:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,527,1422950400"; d="scan'208,217";a="703663019" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 05 Apr 2015 04:49:10 -0700 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 5 Apr 2015 12:49:08 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by hasmsx109.ger.corp.intel.com ([10.184.198.21]) with mapi id 14.03.0224.002; Sun, 5 Apr 2015 14:49:07 +0300 From: "Moses, Danny" To: "Templin, Fred L" , "dmm@ietf.org" Thread-Topic: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Thread-Index: AdBuOH8TeAFQuqtCTx21iPn+L07HKgBWoBSA Date: Sun, 5 Apr 2015 11:49:07 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490CB9BHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 11:49:12 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490CB9BHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Fred, I think we should explore prefix delegation as well. I am not familiar enou= gh if router requirements for prefix delegation and thus would appreciate y= our help - please describe a use-case and we can evaluate it. I can also think of a use-case for mobile hosts and Sustained IP addresses: In the past, I presented a scenario is which it is preferable to anchor an = IP flow in an anchor that is not necessarily the closest to the mobile node= (please refer to draft-aliahmad-dmm-anchor-selection-01). This situation c= an be detected either by the network or by the mobile node. If we want to enable mobile nodes to select a preferred anchor, we need to = provide means for mobile nodes to express the desired selection. One way is= enable mobile nodes to request a specific anchor by indicating an IP prefi= x that was provided by that anchor in the past. This could be done by 'hint= ing' the preferred IP prefix (rather than a specific IP address). Clearly there is more work to be done on this draft and we are welcoming he= lp from anyone in the group. Can you help us with the router part? Thanks, /Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, April 03, 2015 21:13 To: dmm@ietf.org Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Danny and Alper, In this draft, you seem to be considering only DHCPv6 address delegation fo= r when the node is acting as a mobile host. I am wondering if there are sim= ilar considerations for DHCPv6 prefix delegation for when the node is actin= g as a mobile router. But then, I wonder whether any type of prefix delegation other than a fixed= prefix makes any sense. For example, if the mobile router received a nomad= ic prefix delegation, would it need to renumber its connected networks ever= y time it moves and receives a new nomadic prefix? Should this document discuss prefix delegation considerations for mobile ro= uters, or only address delegation for mobile hosts? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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_F0CF5715D3D1884BAC731EA1103AC2813490CB9BHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Fred,

 

I think we should explore prefix delegation as we= ll. I am not familiar enough if router requirements for prefix delegation a= nd thus would appreciate your help - please describe a use-case and we can = evaluate it.

 

I can also think of a use-case for mobile hosts a= nd Sustained IP addresses:

In the past, I presented a scenario is which it i= s preferable to anchor an IP flow in an anchor that is not necessarily the closest to the mobile node (please refer to draf= t-aliahmad-dmm-anchor-selection-01). This situation can be detected either = by the network or by the mobile node.

 

If we want to enable mobile nodes to select a pre= ferred anchor, we need to provide means for mobile nodes to express the des= ired selection. One way is enable mobile nodes to request a specific anchor= by indicating an IP prefix that was provided by that anchor in the past. This could be done by 'hinting' the p= referred IP prefix (rather than a specific IP address).

 

Clearly there is more work to be done on this dra= ft and we are welcoming help from anyone in the group. Can you help us with= the router part?

 

Thanks,

        &= nbsp;       /Danny

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Friday, April 03, 2015 21:13
To: dmm@ietf.org
Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Danny and Alper,

 

In this draft, you seem to be considering only DH= CPv6 address delegation for when the node is acting as a mobile host. I am = wondering if there are similar considerations for DHCPv6 prefix delegation = for when the node is acting as a mobile router.

 

But then, I wonder whether any type of prefix del= egation other than a fixed prefix makes any sense. For example, if the mobi= le router received a nomadic prefix delegation, would it need to renumber i= ts connected networks every time it moves and receives a new nomadic prefix?

 

Should this document discuss prefix delegation co= nsiderations for mobile routers, or only address delegation for mobile host= s?

 

Thanks - Fred

fred.l.templin@boeing.com=

 

_______________________________________________

dmm mailing list

dmm@ietf.org

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

---------------------------------------------------------------------
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_F0CF5715D3D1884BAC731EA1103AC2813490CB9BHASMSX106gercor_-- From nobody Sun Apr 5 11:42:28 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685EE1ACD1D for ; Sun, 5 Apr 2015 11:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SHIRvqR17Y0a for ; Sun, 5 Apr 2015 11:42:20 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 E3BBD1ACD7B for ; Sun, 5 Apr 2015 11:42:19 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so12373233wgb.1 for ; Sun, 05 Apr 2015 11:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4JT8mjzr8DGO6HtCzdKlvweUnnBV3Inq5xcVRKe9aLo=; b=r5bruB+4LBQM2ErrNl+YF2G1LGMPQGdksLldUzBgY0wdmzBqYfnYhLK3jBl4rKYCZy hsY9uTw2KAJ0fofrhqViKVl3ALEd2An5UyATeBcRDdvvPyXsjJ2PHl3/dNq4p2+jq/lG zBzuI3DNtENJp6AoKnbA3MalRxBliLlWo2bJ2hyS4UqzENNw3THr+MNpDqLxXl8jEO3w KihxEzvXNqnk7OII8ChSflwOBHjvuhExqmWHs44mdJb974jC+vhJuugtSHtIbzjO3KH3 ydqbqPgxlvf3/yqoSctyAa40121Kj+Fvc/1niTVYKSpZ3LgD1/4hTDiyH4/OLzIZGmsb J5Cw== MIME-Version: 1.0 X-Received: by 10.180.83.195 with SMTP id s3mr53505791wiy.54.1428259338643; Sun, 05 Apr 2015 11:42:18 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.28.52.196 with HTTP; Sun, 5 Apr 2015 11:42:18 -0700 (PDT) In-Reply-To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> Date: Sun, 5 Apr 2015 19:42:18 +0100 X-Google-Sender-Auth: 4Ta35DJwYWR4C3-3A-dlqjQg9Yo Message-ID: From: Seil Jeon To: "Moses, Danny" Content-Type: multipart/alternative; boundary=f46d04428d1c86ec9a0512fe8acd Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 18:42:26 -0000 --f46d04428d1c86ec9a0512fe8acd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been experiencing a mail posting problem on the list. It is forwarded with a different mail account. @Danny, Sorry if you got multiple mails. Regards, Seil Jeon On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon wrote: > Hi Danny, > > > > Meeting is always good, even with you by f-to-f. But in the discussion, > the main issue is whether we will allow the default source address > selection rules defined in RFC6724 for selecting a Sustained IP address > among several ones or fundamentally block them for a specific reason rais= ed > by a DMM need. The latter approach is not reasonable no matter how I try = to > think of.it. > > If an application has the specific preference of a newly obtained > Sustained IP address, it uses the proposed API. > > > > Regards. > > Seil > > On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny > wrote: > >> Hi Seil, >> >> >> >> By now we have been discussing this for quite some time and clearly we >> did not succeed in convincing each other. >> >> I suggest we try again when we have a chance to meet face to face. >> Meanwhile, let's listen to what other people have to say on this matter. >> >> >> >> Regards, >> >> /Danny >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt] >> *Sent:* Sunday, April 05, 2015 01:16 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Resent. >> >> >> >> Seil >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Saturday, April 04, 2015 1:35 PM >> *To:* 'Moses, Danny' >> *Cc:* 'dmm@ietf.org' >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> See the inline please. I marked current replies with =E2=80=9C>>=E2=80= =9D and previous >> replies with =E2=80=9C>=E2=80=9D for you to catch them easily. >> >> >> >> Regards, >> >> Seil >> >> >> >> >> >> *From:* Moses, Danny [mailto:danny.moses@intel.com >> ] >> *Sent:* Thursday, April 02, 2015 2:16 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Seil, >> >> >> >> Please see my replies (surrounded by >>2) to yours. >> >> >> >> Regards, >> >> /Danny >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Tuesday, March 31, 2015 15:23 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> See the inline please. >> >> >> >> >> >> Seil Jeon >> >> >> >> >> >> *From:* Moses, Danny [mailto:danny.moses@intel.com >> ] >> *Sent:* Monday, March 30, 2015 4:44 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Seil, >> >> >> >> As to the potential of abuse: >> >> Yes, I see your point and you are correct. If the IP stack will not >> request a sustained IP address more than once after each movement to a n= ew >> LAN (with a different prefix), than there will be no abuse. >> >> >> >> > Yes, it=E2=80=99s true. Thanks for correction. >> >> >> >> As to the second comment, please let me elaborate: >> >> One potential implementation of the IP stack in the host, can be to >> request a Nomadic IP address and a Sustained IP address whenever >> connecting to a network, and whenever moving to a new LAN, regardless if >> there are any applications requesting any addresses. This way, whenever = an >> application is launched and requests either a Nomadic or Sustained IP >> address, the stack can provide one without having to issue a request to = the >> network. In this case, there is no need for this flag from the applicati= on. >> >> >> >> > Decision of which type of IP address by default will be depending on >> the IP pool management policy by operators. You case may correspond to o= ne >> of them. What if only the Nomadic IP address is basically allocated upon= a >> network attachment? That is, a lot of applications require mere Internet >> connectivity without session continuity support. So, the Sustained IP >> address will be requested on demand, and the proposed flag will be used = to >> get a new Sustained IP address by expressing the explicit request by an >> application. >> >> >> >> >>2 >> >> As I mentioned at the beginning of the description =E2=80=93 it is a des= cription >> of one alternative. I am not assuming it is the only scenario. >> >> Yes, I agree that many apps require only Nomadic IP addresses, but in >> this example, the IP stack in the host pre-allocates both Nomadic and >> Sustained IP addresses upon attachment=E2=80=A6 >> >> >> >> >> As I said, it could be, but not as general one. The proposed API is >> useful through the explicit expression for any potential scenarios. >> >> >> >> Yes, we can describe an alternative in which a Nomadic IP address is >> pre-allocated upon NW connection (and after every movement to a new LAN) >> and a Sustained (and/or Fixed) address is allocated on-demand. Even in s= uch >> a scenario, I do not see any use for this flag =E2=80=93 see my reply to= the second >> item below=E2=80=A6 >> >> >>2 >> >> >> >> >> My answer was already given in following answer in previous email. >> >> >> >> Another potential implementation of the IP stack in the host is not to >> request IP addresses in advance. In that case, it will issue a request f= or >> a Nomadic IP address or a Sustained IP address the first time an >> application requests one and use it for subsequent requests as long as i= t >> is not moving to a different LAN. Once it moves, it will again request a >> new IP address (Nomadic or Sustained =E2=80=93 according to what is requ= ired) after >> receiving the first request from any application. In this case as well, >> there is no need for this flag. >> >> >> >> > Another application requested just Sustained IP address while the IP >> stack has already a Sustained IP address. Why should the IP stack try to >> get a new one, though the application indicated simply =E2=80=9CSustaine= d IP >> address type=E2=80=9D? You case took a step towards a solution where you= want to >> draw. I don=E2=80=99t expect the action is generic when a Sustained IP a= ddress type >> is requested. >> >> Besides, you assumption on IP address allocation seems not valid. A >> mobile host would get an IP address whatever the allocated IP address ty= pe >> is when it attaches at a network, regardless of an application=E2=80=99s= IP address >> request. >> >> >> >> >>2 >> >> Looks like I did not express myself well enough (and did not fully >> understand your reply). Let me list some events that might help clarify= =E2=80=A6 >> >> >> >> Initial state: Mobile node is connected to a network; no Sustained IP >> address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded= ) >> indicating that if an application requests a Sustained IP address, it wi= ll >> have to request one from the network. >> >> >> >> Event1: An application that requires a Sustained IP address is launched. >> >> APP action: App requests a Sustained IP address from the IP stack using >> the proposed new API. >> >> IP stack action: Since SustainedIPAddressNeeded is set, request one from >> the network. >> >> Network action: Assigned a Sustained IP address to the mobile node. >> >> IP stack action: (1) Mark the new Sustained IP address as the one to be >> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; >> (3)Complete the API action and associate the marked Sustained IP address >> with that port (app) >> >> >> >> Event2: A new application that also required a Sustained IP address is >> launched >> >> App action: App requests a Sustained IP address from the IP stack using >> the proposed new API >> >> IP Stack action: Since SustainedIPAddressNeeded is not set, complete th= e >> API action and associate the marked Sustained IP address with that port >> (app) >> >> >> >> Event3: The mobile node moves to a new LAN >> >> IP Stack action: Set a flag indicating that the currently available >> Sustained IP address is not optimized >> >> >> >> Event4: An application that requires a Sustained IP address is launched. >> >> APP action: App requests a Sustained IP address from the IP stack using >> the proposed new API. >> >> IP stack action: Since SustainedIPAddressNeeded is set, request one from >> the network. >> >> Network action: Assigned a Sustained IP address to the mobile node. >> >> IP stack action: (1) Mark the new Sustained IP address as the one to be >> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; >> (3)Complete the API action and associate the marked Sustained IP address >> with that port (app) >> >> >> >> Note that the behavior of the IP stack in Event4 is exactly like the one >> in Event1. >> >> >> >> *I believe that this event is the one we have different of opinions: I >> think that the default behavior of the IP stack is to request a new >> Sustained IP address since it moved to a new LAN, and you think that it >> should do so only if the application specifically requests a new Sustain= ed >> IP address via the flag you are proposing.* >> >> >>2 >> >> >> >> >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this mail= . >> >> >> >> As a matter of fact, if such a flag is defined, I cannot think of an >> example where it will not be used. It seems to me that applications will >> always request a refreshed Sustained IP address (when requesting a >> Sustained IP address). If this is correct, the flag is redundant. >> >> >> >> > Some applications, e.g. email, that are not relatively restricted from >> optimal routing would consider a Sustained IP address without issuing th= e >> new flag. More applications based on such network characteristic can be >> thought more than expected. >> >> And such use of existing Sustained IP address is not extraordinary, sinc= e >> IP address is a resource, even in the consideration of IPv6 deployment. = If >> as many as applications require new Sustained IP address, it will end up= in >> a lot of network resource consumption in the mobility routers where the >> Sustained IP addresses are anchored as the terminal moves. >> >> >>2 >> >> I am sorry but I disagree with the email example. I categorize it as an >> example of an application that will request a Nomadic address since it d= oes >> not break when the mobile node moves to a new LAN and the source IP addr= ess >> is changed. It simply restarts the socket and continue with the new sour= ce >> IP address (the user will not even notice this). >> >> >> >> >> The example was given as a benefit when the existing Sustained IP >> address is used. You could get some insight from such kind of applicatio= n >> not caring much the routing distance even on the Sustained IP address. >> >> >> >> I did not understand the other text regarding resource consumption. I >> thought we agreed that even of a new Sustained IP address is requested u= pon >> each movement to a new LAN, the effect on IP address allocation is not >> significant. Otherwise, my initial comment on applications abusing the >> network using your proposed flag, becomes valid again >> >> >>2 >> >> >> >> >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustained= IP >> address is requested upon receiving *new* flag from an application, as a >> preference for a source address selection. You need to read our draft >> classifying the categories of IP address request again. >> >> >> >> Besides, I don=E2=80=99t understand what is abused. Delivering its prefe= rence >> cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it in your def= ault behavior >> you=E2=80=99re assuming here. In your scenario, a new app initiated in a= new >> network will be forced to use a newly obtained Sustained IP address. You >> see that? You totally block the possibility to be considered by the defa= ult >> source address selection rules defined in RFC6724. But in our draft, in >> case the need of a newly obtained Sustained IP address is prioritized, t= he >> proposed *new* flag can be used by app=E2=80=99s request, thus it will b= e selected >> with priority. >> >> >> >> Can you provide a scenario in which an application will not request to >> refresh the Sustained IP address? >> >> >> >> > It was mentioned in the former comments. >> >> >> >> >> >> Regards, >> >> /Danny >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Monday, March 30, 2015 17:08 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* FW: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> Any comments? >> >> >> >> Regards, >> >> Seil Jeon >> >> >> >> >> >> *From:* dmm [mailto:dmm-bounces@ietf.org ] *On >> Behalf Of *Seil Jeon >> *Sent:* Thursday, March 26, 2015 8:08 PM >> *To:* dmm@ietf.org >> *Subject:* [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi, >> >> >> >> I could attend DMM Thursday meeting via MeetEcho. >> >> I could also hear some raised comments by Danny and Someone. Here goes >> answers to the raised questions. >> >> >> >> >> >> First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), >> >> >> >> The use of the proposed API is suggested in the SUSTAINED IP address cas= e >> in the draft. On receiving this API with the SUSTAINED IP address type a= t >> the IP stack, it will try to get a new SUSTAINED IP address if there is = no >> available in the currently attached access network. So, actual obtaining= of >> the IP address will be tried one time while attached at a specific acces= s >> network. Even some applications put this API after, the already obtained >> SUSTAINED IP will be used. So, no worries about abuse. >> >> >> >> Second question sounded to me like that this API is not needed because >> the host can get a new SUSTAINED IP address, right? >> >> If the question is right, I don=E2=80=99t understand what the question i= s meant, >> that is how the host can get a new SUSTAINED IP address? >> >> Based on the definition of three types of IP address, an application >> should show its requirement with an API among them. If it is the SUSTAIN= ED >> IP address, how do we expect the IP stack will try to get a new SUSTAINE= D >> IP address? >> >> >> >> Besides, the propsoed API is not used alone but with the three type APIs= . >> >> >> >> >> >> >> >> Regards, >> >> >> >> Seil Jeon >> >> >> >> >> >> --------------------------------------------------------------------- >> 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. >> >> --------------------------------------------------------------------- >> 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 >> >> > --f46d04428d1c86ec9a0512fe8acd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been experiencing a mail posting problem on th= e list. It is forwarded with a different mail account.

=
@Danny, Sorry if you got multiple mails.

Rega= rds,
Seil Jeon

On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon <seiljeon@av.= it.pt> wrote:

Hi Danny,

=C2= =A0

Meet= ing is always good, even with you by f-to-f. But in the discussion, the main is= sue is whether we will allow the default source address selection rules defined= in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The la= tter approach is not reasonable no matter how I try to think of.it.

If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API.

=C2= =A0

Rega= rds.

Seil=


On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <danny.mose= s@intel.com> wrote:

Hi Seil,=

=C2=A0

By now we have = been discussing this for quite some time and clearly we did not succeed in = convincing each other.

I suggest we tr= y again when we have a chance to meet face to face. Meanwhile, let's li= sten to what other people have to say on this matter.<= /p>

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [m= ailto:seiljeon@av.it= .pt]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Resent.

=C2=A0

Seil

=C2=A0

From: Seil Jeon [<= a href=3D"mailto:seiljeon@av.it.pt" target=3D"_blank">mailto:seiljeon@av.it= .pt]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm@ietf.= org'
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please. I marked curre= nt replies with =E2=80=9C>>=E2=80=9D and previous replies with =E2=80= =9C>=E2=80=9D for you to catch them easily.

=C2=A0

Regards,

Seil

=C2=A0

=C2=A0

From: Moses,= Danny [<= span style=3D"font-family:"Tahoma","sans-serif";font-si= ze:10pt">mailto:danny.moses@intel.com]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

Please see my r= eplies (surrounded by =C2=A0>>2) to yours.

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please.<= /span>

=C2=A0

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

From: Moses, Danny= [mailto:danny.moses@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

As to the poten= tial of abuse:

Yes, I see your= point and you are correct. If the IP stack will not request a sustained IP= address more than once after each movement to a new LAN (with a different = prefix), than there will be no abuse.

=C2=A0

> Yes, it=E2=80=99s true. Thanks for correction.=

=C2=A0

As to the secon= d comment, please let me elaborate:

One potential i= mplementation of the IP stack in the host, can be to request a Nomadic IP a= ddress and a =C2=A0Sustained IP address whenever connecting to a network, a= nd whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

=C2=A0

> Decision of which type of IP address by defaul= t will be depending on the IP pool management policy by operators. You case= may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applic= ations require mere Internet connectivity without session continuity suppor= t. So, the Sustained IP address will be requested on demand, and the propos= ed flag will be used to get a new Sustained IP address by expressing the explicit request by an application.=

=C2=A0

>>2

As I mentioned = at the beginning of the description =E2=80=93 it is a description of one al= ternative. I am not assuming it is the only scenario.<= /p>

Yes, I agree th= at many apps require only Nomadic IP addresses, but in this example, the IP= stack in the host pre-allocates both Nomadic and Sustained IP addresses up= on attachment=E2=80=A6

=C2=A0

>> As I said, it could be, but not as general= one. The proposed API is useful through the explicit expression for any po= tential scenarios.

=C2=A0

Yes, we can des= cribe an alternative in which a Nomadic IP address is pre-allocated upon NW= connection (and after every movement to a new LAN) and a Sustained (and/or= Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag =E2=80=93 see my re= ply to the second item below=E2=80=A6

>>2

=C2=A0

>> My answer was already given in following a= nswer in previous email.=

=C2=A0

Another potenti= al implementation of the IP stack in the host is not to request IP addresse= s in advance. In that case, it will issue a request for a Nomadic IP addres= s or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained =E2=80=93 according to what is requir= ed) after receiving the first request from any application. In this case as well, there is no need for this flag.<= /u>

=C2=A0

> Another application requested just Sustained I= P address while the IP stack has already a Sustained IP address. Why should= the IP stack try to get a new one, though the application indicated simply =E2=80=9CSustained IP address type=E2=80=9D? You case took a step t= owards a solution where you want to draw. I don=E2=80=99t expect the action= is generic when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application=E2=80=99s IP address request.

=C2=A0

>>2

Looks like I did not express myself w= ell enough (and did not fully understand your reply). Let me list some even= ts that might help clarify=E2=80=A6

=C2=A0

Initial state: Mobile node is connect= ed to a network; no Sustained IP address is allocated. The IP stack sets a = flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

=C2=A0

Event1: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Event2: A new application that also r= equired a Sustained IP address is launched

App action: App requests a Sustained = IP address from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAdd= ressNeeded =C2=A0is not set, complete the API action and associate the mark= ed Sustained IP address with that port (app)

=C2=A0

Event3: The mobile node moves to a ne= w LAN

IP Stack action: Set a flag indicatin= g that the currently available Sustained IP address is not optimized

=C2=A0

Event4: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Note that the behavior of the IP stac= k in Event4 is exactly like the one in Event1.

=C2=A0

I believe that this event is the o= ne we have different of opinions: I think that the default behavior of the = IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

=C2=A0

>> You can see my answer at the lowest =E2=80= =9C>>=E2=80=9D in this mail.

=C2=A0

As a matter of = fact, if such a flag is defined, I cannot think of an example where it will= not be used. It seems to me that applications will always request a refres= hed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

=C2=A0

> Some applications, e.g. email, that are not re= latively restricted from optimal routing would consider a Sustained IP addr= ess without issuing the new flag. More applications based on such network characteristic can be thought more than expected.

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but = I disagree with the email example. I categorize it as an example of an appl= ication that will request a Nomadic address since it does not break when th= e mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).<= /span>

=C2=A0

>> The example was given as a benefit when th= e existing Sustained IP address is used. You could get some insight from su= ch kind of application not caring much the routing distance even on the Sustained IP address.

=C2=A0

I did not under= stand the other text regarding resource consumption. I thought we agreed th= at even of a new Sustained IP address is requested upon each movement to a = new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again

>>2

=C2=A0

>> No, our draft didn=E2=80=99t say so. Our i= dea is that a new Sustained IP address is requested upon receiving *new* fl= ag from an application, as a preference for a source address selection. You= need to read our draft classifying the categories of IP address request again.<= u>

=C2=A0

Besides, I don=E2=80=99t understand what is abused. Delive= ring its preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I s= ee it in your default behavior you=E2=80=99re assuming here. In your scenar= io, a new app initiated in a new network will be forced to use a newly obtained Sustaine= d IP address. You see that? You totally block the possibility to be conside= red by the default source address selection rules defined in RFC6724. But i= n our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* f= lag can be used by app=E2=80=99s request, thus it will be selected with pri= ority.

=C2=A0

Can you provide= a scenario in which an application will not request to refresh the Sustain= ed IP address?

=C2=A0

> It was mentioned in the former comments.

=C2=A0

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

Any comments?

=C2=A0

Regards,

Seil Jeon

=C2=A0

=C2=A0

From: dmm [= mailto:= dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi,

=C2=A0

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

=C2=A0

=C2=A0

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

=C2=A0

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

=C2=A0

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?<= /u>

If the question is right, I don=E2=80=99t understand what = the question is meant, that is how the host can get a new SUSTAINED IP addr= ess?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

=C2=A0

Besides, the propsoed API is not used alone but with the t= hree type APIs.

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

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

--------------------------------------------------------------------- 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
htt= ps://www.ietf.org/mailman/listinfo/dmm



--f46d04428d1c86ec9a0512fe8acd-- From nobody Mon Apr 6 03:14:36 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1891D1A7015 for ; Mon, 6 Apr 2015 03:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.227 X-Spam-Level: ** X-Spam-Status: No, score=2.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lLa6upp71tOh for ; Mon, 6 Apr 2015 03:14:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226B51A700F for ; Mon, 6 Apr 2015 03:14:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRB92538; Mon, 06 Apr 2015 10:14:29 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Apr 2015 11:14:28 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 6 Apr 2015 18:14:24 +0800 From: "Weixinpeng (Jackie)" To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AQHQbmrjkg7ViRmxzk+pIbTvRAOX0Z0/x0Y6 Date: Mon, 6 Apr 2015 10:14:24 +0000 Message-ID: References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.18.239] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 10:14:35 -0000 SSB0aGluayB0aGUgZG9jdW1lbnQgaGFzIHNvbWUgYmFzaWMgaXNzdWVzIHRoYXQgaGF2ZSBub3Qg YmUgY2xlYXJpZmllZCwgYW5kIGRvbid0IHRoaW5rIGl0IGlzIHJlYWR5IGZvciBXRyBhZG9wdGlv bi4NCg0KIEkgYW0gc3RpbGwgbm90IGNvbnZpbmNlZCB5ZXQgdGhhdCBnZXQgdGhlIGFwcCBkZXZl bG9wZXIgZ2V0IGludm9sdmVkIGluIHRoZSBjaG9pY2Ugb2YgbW9iaWxpdHkgc2NoZW1lIGlzIGEg Z29vZCBpZGVhLiANCiBCdXQgZXZlbiBoZXJlIHdlIGFzc3VtZSB0aGF0IHdvdWxkIGJlIGFjY2Vw dGFibGUuIHRoZW4gdGhlcmUgYXJlIHN0aWxsIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMuDQoN ClExLiBXaGV0aGVyIGl0IGlzIHN1aXRhYmxlIGZvciBhcHAgdG8gc2VsZWN0IGRpZmZlcmVudCB0 eXBlcyBvZiBJUCBhZGRyZXNzIA0KICgxKVdoYXQgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGNvbW11 bmljYXRlZCBmcm9tIGFwcGxpY2F0aW9uIHRvIHRoZSBob3N0Lg0KIE9uZSBvcHRpb24gaXMgdGhl IGFwcCBvbmx5IGluZGljYXRlcyB3aGV0aGVyIGl0IGNvdWxkIGNvcGUgd2l0aCBtb2JpbGl0eSBv ciBub3QsIGFub3RoZXIgb3B0aW9uIGlzIHRoZSBhcHAgaW5kaWNhdGVzIHNwZWNpZmljIHR5cGUg b2YNCiBJUCBhZGRyZXNzIHR5cGUuIEFsc28gdGhlcmUgbWlnaHQgYmUgc29tZSBvdGhlciBvcHRp b25zLg0KICAoMilJbiB3aGljaCBsZXZlbCB0aGUgb3B0aW9uIHNob3VsZCBiZSBzZXQgYnkgc2V0 c29ja29wdCgpLg0KIEkgdGhpbmsgYXQgbGVhc3QgdGhlcmUgYXJlIHR3byBjaG9pY2VzLCB0aGUg Zmlyc3Qgb25lIGlzIGluIFNPTF9TT0NLRVQsIGFuZCB0aGUgc2Vjb25kIG9uZSBpcyBJUFBST1RP X0lQVjYuDQogTm90IG9ubHkgdGhlIG5ldHdvcmsgbGF5ZXIgY291bGQgcHJvdmlkZSBtb2JpbGl0 eSBzdXBwb3J0IGJ1dCBhbHNvIG90aGVyIGxheWVycyBzdWNoIGFzIHRyYW5zcG9ydCBsYXllci4N CiANCiBRMi4gV2hldGhlciB0aGUgSVAgYWRkcmVzcyBkZWZpbmVkIGhlcmUgaXMgb2s/DQogRm9y IGV4YW1wbGUsIGlmICBub21hZGljIGFkZHJlc3MgaXMgZGVmaW5lZCwgYW5kIHRoZW4gIGFwcGxp Y2F0aW9uIGRldmVsb3BlciBpcyB0b2xkIHRoYXQgdGhlIG5vbWFkaWMgYWRkcmVzcyAicHJvdmlk ZXMgbmVpdGhlciBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgbm9yIElQIGFkZHJlc3MgcmVhY2hhYmls aXR5IiwgdGhlbiBob3cgdGhlIGRldmVsb3ByIHdpbGwgdGhpbmsgb2YgaXQuIEkgYW0gc3VyZSB0 aGV5IHdpbGwgbmV2ZXIgd2FudCB0byB1c2Ugc3VjaCBhbiBhZGRyZXNzLg0KIEZvciB0aGUgZGVm aW5pdGlvbiBvZiBmaXhlZCBhZGRyZXNzIGFuZCBzdXN0YWluZWQgYWRkcmVzcywgSSBkb24ndCBz ZWUgdGhlIHJlYXNvbiB3aHkgd2UgbmVlZCBib3RoIG9mIHRoZW0gaW4gYSBuZXR3b3JrLg0KICAN ClEzLiBIb3cgc2hvdWxkIHRoZSBuZXR3b3JrIHNpZGUgc3VwcG9ydCB0aGUgc29sdXRpb24gaXMg bm90IHF1aXRlIGNsZWFyLiBJcyB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUgZGVmaW5lZCBpbiBv dGhlciB3b3JrIGdyb3VwIGNvdWxkIHN1cHBvcnQgdGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQu DQpRNC4gUGVvcGxlIHNob3VsZCBiZSBhd2FyZSBvZiB0aGVyZSBpcyBhbiBJUFIgaW4gdGhpcyBk b2MuIA0KDQotWGlucGVuZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IGRtbSBbZG1tLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm91bmkgS29yaG9u ZW4gW2pvdW5pLm5vc3BhbUBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNcTqNNTCNMjVIDg6MDMN CsrVvP7IyzogZG1tQGlldGYub3JnOyBKb3VuaTsgRGFwZW5nIExpdTsgZHJhZnQteWVnaW4tZG1t LW9uZGVtYW5kLW1vYmlsaXR5QHRvb2xzLmlldGYub3JnDQrW98ziOiBbRE1NXSBDYWxsIGZvciBh ZG9wdGlvbjogZHJhZnQteWVnaW4tZG1tLW9uZGVtYW5kLW1vYmlsaXR5LTAzDQoNCkZvbGtzLA0K DQpUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3byB3ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIHRoZSBJLUQN CiAgIGRyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS0wMw0KdG8gY29uZmlybSBpdHMg YWRvcHRpb24gYXMgYSBETU0gV0cgZG9jdW1lbnQgYW5kIGFzIGEgYmFzaXMgZm9yIHRoZQ0KdGVj aG5pY2FsIHNvbHV0aW9uLiBUaGUgY2FsbCBlbmRzIEFwcmlsIDE3dGggRU9CIFBEVC4NCg0KRXhw cmVzcyB5b3VyIHN1cHBvcnQgb3Igb3Bwb3NpdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0LiBEdXJp bmcgdGhlDQpJRVRGOTIgbWVldGluZyB3ZSBnb3QgMTAgdm9pY2VzIGZvciB0aGUgYWRvcHRpb24g YW5kIDMgYWdhaW5zdC4gd2UNCmV4cGVjdCBhdCBsZWFzdCB0aGUgc2FtZSBhbW91bnQgb2YgZXhw cmVzc2VkIG9waW5pb25zIG9uIHRoZSBsaXN0Lg0KDQpOb3RpY2UgdGhhdCB2ZXJzaW9uIC0wMSBv ZiB0aGlzIEktRCBoYWQgYW4gSVBSIGRlY2xhcmVkIHRvIGl0LiBTZWUNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzIzMDkvDQoNCi0gSm91bmkgJiBEYXBlbmcNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QN CmRtbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0= From nobody Tue Apr 7 01:44:29 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B71B32E4 for ; Tue, 7 Apr 2015 01:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Pd1JUpLx885s for ; Tue, 7 Apr 2015 01:44:25 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AC01B32E3 for ; Tue, 7 Apr 2015 01:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 21EC9109A7F; Tue, 7 Apr 2015 10:44:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkxYGjB-qYb4; Tue, 7 Apr 2015 10:44:24 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 03A391023C3; Tue, 7 Apr 2015 10:44:16 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.23]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 7 Apr 2015 10:43:56 +0200 From: Marco Liebsch To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-perkins-dmm-4283mnids@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 Thread-Index: AQHQbIzpZR/WdOSeOkKE6FxCJqF77J1BRKGw Date: Tue, 7 Apr 2015 08:43:54 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99A343B9@PALLENE.office.hd> References: <551C0877.1060100@gmail.com> In-Reply-To: <551C0877.1060100@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 08:44:28 -0000 I support the adoption of this Internet draft as DMM WG document. marco >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >Sent: Mittwoch, 1. April 2015 17:02 >To: dmm@ietf.org; Jouni; Dapeng Liu; draft-perkins-dmm- >4283mnids@tools.ietf.org >Subject: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 > >Folks, > >This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 >to confirm the aadoption s a DMM WG document. The call ends April 15th EOB >PST. > >Express your support or opposition to the mailing list. During the >IETF92 meeting we got 7 voices for the adoption so at least the same amoun= t >supporting emails should be expected. > >- Jouni & Dapeng > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Apr 7 06:25:14 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2581B3591 for ; Tue, 7 Apr 2015 06:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.131 X-Spam-Level: ** X-Spam-Status: No, score=2.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_24_48=1.34, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FTyBmM7NMzIQ for ; Tue, 7 Apr 2015 06:24:54 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9821B358C for ; Tue, 7 Apr 2015 06:24:53 -0700 (PDT) Received: from [2.81.151.93] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77447208; Sun, 05 Apr 2015 15:08:16 +0100 From: "Seil Jeon" To: "'Moses, Danny'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> In-Reply-To: Date: Sun, 5 Apr 2015 15:08:16 +0100 Message-ID: <000001d06fa9$f6675e30$e3361a90$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D06FB2.58336750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uYCqJZpkgDQIjNOAdQYy1EBr/T0wps5WoZA Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:25:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D06FB2.58336750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danny, Meeting is always good, even with you by f-to-f. But in the discussion, the main issue is whether we will allow the default source address selection rules defined in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The latter approach is not reasonable no matter how I try to think of.it. If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API. Regards. Seil From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 05, 2015 12:23 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, By now we have been discussing this for quite some time and clearly we did not succeed in convincing each other. I suggest we try again when we have a chance to meet face to face. Meanwhile, let's listen to what other people have to say on this matter. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 01:16 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Resent. Seil From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. I marked current replies with ">>" and previous replies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request a sustained IP address more than once after each movement to a new LAN (with a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request a Nomadic IP address and a Sustained IP address whenever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an application is launched and requests either a Nomadic or Sustained IP address, the stack can provide one without having to issue a request to the network. In this case, there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the IP pool management policy by operators. You case may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applications require mere Internet connectivity without session continuity support. So, the Sustained IP address will be requested on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this example, the IP stack in the host pre-allocates both Nomadic and Sustained IP addresses upon attachment. >> As I said, it could be, but not as general one. The proposed API is useful through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-allocated upon NW connection (and after every movement to a new LAN) and a Sustained (and/or Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag - see my reply to the second item below. >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to request IP addresses in advance. In that case, it will issue a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as it is not moving to a different LAN. Once it moves, it will again request a new IP address (Nomadic or Sustained - according to what is required) after receiving the first request from any application. In this case as well, there is no need for this flag. > Another application requested just Sustained IP address while the IP stack has already a Sustained IP address. Why should the IP stack try to get a new one, though the application indicated simply "Sustained IP address type"? You case took a step towards a solution where you want to draw. I don't expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile host would get an IP address whatever the allocated IP address type is when it attaches at a network, regardless of an application's IP address request. >>2 Looks like I did not express myself well enough (and did not fully understand your reply). Let me list some events that might help clarify. Initial state: Mobile node is connected to a network; no Sustained IP address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Event2: A new application that also required a Sustained IP address is launched App action: App requests a Sustained IP address from the IP stack using the proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the API action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustained IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Note that the behavior of the IP stack in Event4 is exactly like the one in Event1. I believe that this event is the one we have different of opinions: I think that the default behavior of the IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application specifically requests a new Sustained IP address via the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an example where it will not be used. It seems to me that applications will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from optimal routing would consider a Sustained IP address without issuing the new flag. More applications based on such network characteristic can be thought more than expected. And such use of existing Sustained IP address is not extraordinary, since IP address is a resource, even in the consideration of IPv6 deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the mobility routers where the Sustained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an example of an application that will request a Nomadic address since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the new source IP address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP address is used. You could get some insight from such kind of application not caring much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thought we agreed that even of a new Sustained IP address is requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing the network using your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address is requested upon receiving *new* flag from an application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference cannot be abuse. Regarding "abuse", I see it in your default behavior you're assuming here. In your scenario, a new app initiated in a new network will be forced to use a newly obtained Sustained IP address. You see that? You totally block the possibility to be considered by the default source address selection rules defined in RFC6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* flag can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refresh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [ mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. ------=_NextPart_000_0001_01D06FB2.58336750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Danny,

 

Meeting is = always good, even with you by f-to-f. But in the discussion, the main = issue is whether we will allow the default source address selection = rules defined in RFC6724 for selecting a Sustained IP address among = several ones or fundamentally block them for a specific reason raised by = a DMM need. The latter approach is not reasonable no matter how I try to = think of.it.

If an = application has the specific preference of a newly obtained Sustained IP = address, it uses the proposed API.

 

Regards.

Seil<= /span>

 

 

From:= = Moses, Danny [mailto:danny.moses@intel.com]
Sent: Sunday, = April 05, 2015 12:23 PM
To: Seil Jeon
Cc: = dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for = the proposed API

 

Hi Seil,

 

By now we have been = discussing this for quite some time and clearly we did not succeed in = convincing each other.

I suggest we try again when we have a chance to = meet face to face. Meanwhile, let's listen to what other people have to = say on this matter.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Sunday, April 05, 2015 01:16
To: Moses, = Danny
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Resent.

 

Seil

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, = Danny'
Cc: 'dmm@ietf.org'
Subject: RE: [DMM] Answer = on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please. I marked current replies with “>>” and = previous replies with “>” for you to catch them = easily.

 

Regards,

Seil<= /span>

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Tuesday, March 31, 2015 15:23
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please.

 

 

Seil Jeon =

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Monday, March 30, 2015 4:44 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

As to the potential of = abuse:

Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

 

> = Yes, it’s true. Thanks for correction.

 

As to the = second comment, please let me elaborate:

One potential = implementation of the IP stack in the host, can be to request a Nomadic = IP address and a  Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any = applications requesting any addresses. This way, whenever an application = is launched and requests either a Nomadic or Sustained IP address, the = stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the = application.

 

> = Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one = of them. What if only the Nomadic IP address is basically allocated upon = a network attachment? That is, a lot of applications require mere = Internet connectivity without session continuity support. So, the = Sustained IP address will be requested on demand, and the proposed flag = will be used to get a new Sustained IP address by expressing the = explicit request by an application.

 

>>2

As I mentioned at the = beginning of the description – it is a description of one = alternative. I am not assuming it is the only = scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host = pre-allocates both Nomadic and Sustained IP addresses upon = attachment…

 

>> As I said, it could = be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 

Yes, we = can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or Fixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag – see my reply = to the second item below…

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential = implementation of the IP stack in the host is not to request IP = addresses in advance. In that case, it will issue a request for a = Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained – according to what = is required) after receiving the first request from any application. In = this case as well, there is no need for this = flag.

 

> = Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply “Sustained = IP address type”? You case took a step towards a solution where = you want to draw. I don’t expect the action is generic when a = Sustained IP address type is requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application’s IP address = request.

 

>>2 =

Looks like I = did not express myself well enough (and did not fully understand your = reply). Let me list some events that might help = clarify…

 

Initial state: = Mobile node is connected to a network; no Sustained IP address is = allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it = will have to request one from the network.

 

Event1: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Event2: A new = application that also required a Sustained IP address is launched =

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack = action: Since SustainedIPAddressNeeded  is not set, complete the = API action and associate the marked Sustained IP address with that port = (app)

 

Event3: The = mobile node moves to a new LAN

IP Stack = action: Set a flag indicating that the currently available Sustained IP = address is not optimized

 

Event4: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Note that the = behavior of the IP stack in Event4 is exactly like the one in = Event1.

 

I believe that = this event is the one we have different of opinions: I think that the = default behavior of the IP stack is to request a new Sustained IP = address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>>2

 

>> You can see my = answer at the lowest “>>” in this = mail.

 

As a matter of fact, if = such a flag is defined, I cannot think of an example where it will not = be used. It seems to me that applications will always request a = refreshed Sustained IP address (when requesting a Sustained IP address). = If this is correct, the flag is redundant.

 

> = Some applications, e.g. email, that are not relatively restricted from = optimal routing would consider a Sustained IP address without issuing = the new flag. More applications based on such network characteristic can = be thought more than expected.

And = such use of existing Sustained IP address is not extraordinary, since IP = address is a resource, even in the consideration of IPv6 deployment. If = as many as applications require new Sustained IP address, it will end up = in a lot of network resource consumption in the mobility routers where = the Sustained IP addresses are anchored as the terminal = moves.

>>2

I am sorry but I = disagree with the email example. I categorize it as an example of an = application that will request a Nomadic address since it does not break = when the mobile node moves to a new LAN and the source IP address is = changed. It simply restarts the socket and continue with the new source = IP address (the user will not even notice this).

 

>> The example was = given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP = address.

 

I did not = understand the other text regarding resource consumption. I thought we = agreed that even of a new Sustained IP address is requested upon each = movement to a new LAN, the effect on IP address allocation is not = significant. Otherwise, my initial comment on applications abusing the = network using your proposed flag, becomes valid = again

>>2

 

>> No, our draft = didn’t say so. Our idea is that a new Sustained IP address is = requested upon receiving *new* flag from an application, as a preference = for a source address selection. You need to read our draft classifying = the categories of IP address request again.

 

Besides, I don’t = understand what is abused. Delivering its preference cannot be abuse. = Regarding “abuse”, I see it in your default behavior = you’re assuming here. In your scenario, a new app initiated in a = new network will be forced to use a newly obtained Sustained IP address. = You see that? You totally block the possibility to be considered by the = default source address selection rules defined in RFC6724. But in our = draft, in case the need of a newly obtained Sustained IP address is = prioritized, the proposed *new* flag can be used by app’s request, = thus it will be selected with priority.

 

Can you = provide a scenario in which an application will not request to refresh = the Sustained IP address?

 

> It was mentioned in the = former comments.

 

 

Regards,

        &= nbsp;       = /Danny

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Any = comments?

 

Regards,

Seil = Jeon

 

 

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

 

Hi,

 

I = could attend DMM Thursday meeting via MeetEcho.

I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

 

 

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

 

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

 

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?

If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?

Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

 

Besides, the propsoed API is = not used alone but with the three type APIs.

 

 

 

Regards,

=

 

Seil = Jeon

 

 

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

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

------=_NextPart_000_0001_01D06FB2.58336750-- From nobody Tue Apr 7 06:40:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8129D1A870A for ; Tue, 7 Apr 2015 06:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k9NULTJIsrUt for ; Tue, 7 Apr 2015 06:40:41 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7C1B358C for ; Tue, 7 Apr 2015 06:40:09 -0700 (PDT) Received: from [188.80.105.243] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77446130; Sat, 04 Apr 2015 23:16:10 +0100 From: "Seil Jeon" To: "'Moses, Danny'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> In-Reply-To: Date: Sat, 4 Apr 2015 23:16:12 +0100 Message-ID: <001d01d06f24$f601c000$e2054000$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01D06F2D.57CAE2F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uYCqJZpkgDQIjNOAPZdtnGbTMJ10A== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:40:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01D06F2D.57CAE2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent. Seil From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. I marked current replies with ">>" and previous replies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request a sustained IP address more than once after each movement to a new LAN (with a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request a Nomadic IP address and a Sustained IP address whenever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an application is launched and requests either a Nomadic or Sustained IP address, the stack can provide one without having to issue a request to the network. In this case, there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the IP pool management policy by operators. You case may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applications require mere Internet connectivity without session continuity support. So, the Sustained IP address will be requested on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this example, the IP stack in the host pre-allocates both Nomadic and Sustained IP addresses upon attachment. >> As I said, it could be, but not as general one. The proposed API is useful through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-allocated upon NW connection (and after every movement to a new LAN) and a Sustained (and/or Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag - see my reply to the second item below. >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to request IP addresses in advance. In that case, it will issue a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as it is not moving to a different LAN. Once it moves, it will again request a new IP address (Nomadic or Sustained - according to what is required) after receiving the first request from any application. In this case as well, there is no need for this flag. > Another application requested just Sustained IP address while the IP stack has already a Sustained IP address. Why should the IP stack try to get a new one, though the application indicated simply "Sustained IP address type"? You case took a step towards a solution where you want to draw. I don't expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile host would get an IP address whatever the allocated IP address type is when it attaches at a network, regardless of an application's IP address request. >>2 Looks like I did not express myself well enough (and did not fully understand your reply). Let me list some events that might help clarify. Initial state: Mobile node is connected to a network; no Sustained IP address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Event2: A new application that also required a Sustained IP address is launched App action: App requests a Sustained IP address from the IP stack using the proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the API action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustained IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Note that the behavior of the IP stack in Event4 is exactly like the one in Event1. I believe that this event is the one we have different of opinions: I think that the default behavior of the IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application specifically requests a new Sustained IP address via the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an example where it will not be used. It seems to me that applications will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from optimal routing would consider a Sustained IP address without issuing the new flag. More applications based on such network characteristic can be thought more than expected. And such use of existing Sustained IP address is not extraordinary, since IP address is a resource, even in the consideration of IPv6 deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the mobility routers where the Sustained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an example of an application that will request a Nomadic address since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the new source IP address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP address is used. You could get some insight from such kind of application not caring much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thought we agreed that even of a new Sustained IP address is requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing the network using your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address is requested upon receiving *new* flag from an application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference cannot be abuse. Regarding "abuse", I see it in your default behavior you're assuming here. In your scenario, a new app initiated in a new network will be forced to use a newly obtained Sustained IP address. You see that? You totally block the possibility to be considered by the default source address selection rules defined in RFC6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* flag can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refresh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [ mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. ------=_NextPart_000_001E_01D06F2D.57CAE2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resent.

 

Seil

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt]
Sent: Saturday, April = 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: = 'dmm@ietf.org'
Subject: RE: [DMM] Answer on raised questions = for the proposed API

 

Hi = Danny,

 

See the inline = please. I marked current replies with “>>” and = previous replies with “>” for you to catch them = easily.

 

Regards,

Seil<= /span>

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Tuesday, March 31, 2015 15:23
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please.

 

 

Seil Jeon =

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Monday, March 30, 2015 4:44 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

As to the potential of = abuse:

Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

 

> = Yes, it’s true. Thanks for correction.

 

As to the = second comment, please let me elaborate:

One potential = implementation of the IP stack in the host, can be to request a Nomadic = IP address and a  Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any = applications requesting any addresses. This way, whenever an application = is launched and requests either a Nomadic or Sustained IP address, the = stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the = application.

 

> = Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one = of them. What if only the Nomadic IP address is basically allocated upon = a network attachment? That is, a lot of applications require mere = Internet connectivity without session continuity support. So, the = Sustained IP address will be requested on demand, and the proposed flag = will be used to get a new Sustained IP address by expressing the = explicit request by an application.

 

>>2

As I mentioned at the = beginning of the description – it is a description of one = alternative. I am not assuming it is the only = scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host = pre-allocates both Nomadic and Sustained IP addresses upon = attachment…

 

>> As I said, it could = be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 

Yes, we = can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or Fixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag – see my reply = to the second item below…

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential = implementation of the IP stack in the host is not to request IP = addresses in advance. In that case, it will issue a request for a = Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained – according to what = is required) after receiving the first request from any application. In = this case as well, there is no need for this = flag.

 

> = Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply “Sustained = IP address type”? You case took a step towards a solution where = you want to draw. I don’t expect the action is generic when a = Sustained IP address type is requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application’s IP address = request.

 

>>2 =

Looks like I = did not express myself well enough (and did not fully understand your = reply). Let me list some events that might help = clarify…

 

Initial state: = Mobile node is connected to a network; no Sustained IP address is = allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it = will have to request one from the network.

 

Event1: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Event2: A new = application that also required a Sustained IP address is launched =

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack = action: Since SustainedIPAddressNeeded  is not set, complete the = API action and associate the marked Sustained IP address with that port = (app)

 

Event3: The = mobile node moves to a new LAN

IP Stack = action: Set a flag indicating that the currently available Sustained IP = address is not optimized

 

Event4: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Note that the = behavior of the IP stack in Event4 is exactly like the one in = Event1.

 

I believe that = this event is the one we have different of opinions: I think that the = default behavior of the IP stack is to request a new Sustained IP = address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>>2

 

>> You can see my = answer at the lowest “>>” in this = mail.

 

As a matter of fact, if = such a flag is defined, I cannot think of an example where it will not = be used. It seems to me that applications will always request a = refreshed Sustained IP address (when requesting a Sustained IP address). = If this is correct, the flag is redundant.

 

> = Some applications, e.g. email, that are not relatively restricted from = optimal routing would consider a Sustained IP address without issuing = the new flag. More applications based on such network characteristic can = be thought more than expected.

And = such use of existing Sustained IP address is not extraordinary, since IP = address is a resource, even in the consideration of IPv6 deployment. If = as many as applications require new Sustained IP address, it will end up = in a lot of network resource consumption in the mobility routers where = the Sustained IP addresses are anchored as the terminal = moves.

>>2

I am sorry but I = disagree with the email example. I categorize it as an example of an = application that will request a Nomadic address since it does not break = when the mobile node moves to a new LAN and the source IP address is = changed. It simply restarts the socket and continue with the new source = IP address (the user will not even notice this).

 

>> The example was = given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP = address.

 

I did not = understand the other text regarding resource consumption. I thought we = agreed that even of a new Sustained IP address is requested upon each = movement to a new LAN, the effect on IP address allocation is not = significant. Otherwise, my initial comment on applications abusing the = network using your proposed flag, becomes valid = again

>>2

 

>> No, our draft = didn’t say so. Our idea is that a new Sustained IP address is = requested upon receiving *new* flag from an application, as a preference = for a source address selection. You need to read our draft classifying = the categories of IP address request again.

 

Besides, I don’t = understand what is abused. Delivering its preference cannot be abuse. = Regarding “abuse”, I see it in your default behavior = you’re assuming here. In your scenario, a new app initiated in a = new network will be forced to use a newly obtained Sustained IP address. = You see that? You totally block the possibility to be considered by the = default source address selection rules defined in RFC6724. But in our = draft, in case the need of a newly obtained Sustained IP address is = prioritized, the proposed *new* flag can be used by app’s request, = thus it will be selected with priority.

 

Can you = provide a scenario in which an application will not request to refresh = the Sustained IP address?

 

> It was mentioned in the = former comments.

 

 

Regards,

        &= nbsp;       = /Danny

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Any = comments?

 

Regards,

Seil = Jeon

 

 

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

 

Hi,

 

I = could attend DMM Thursday meeting via MeetEcho.

I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

 

 

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

 

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

 

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?

If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?

Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

 

Besides, the propsoed API is = not used alone but with the three type APIs.

 

 

 

Regards,

=

 

Seil = Jeon

 

 

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

------=_NextPart_000_001E_01D06F2D.57CAE2F0-- From nobody Tue Apr 7 06:44:49 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DA01B358F for ; Tue, 7 Apr 2015 06:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.419 X-Spam-Level: X-Spam-Status: No, score=0.419 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, TVD_SPACE_RATIO=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ms4RPawcssdF for ; Tue, 7 Apr 2015 06:44:47 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10D1B358C for ; Tue, 7 Apr 2015 06:44:46 -0700 (PDT) Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77450071 for dmm@ietf.org; Mon, 06 Apr 2015 13:37:29 +0100 From: "Seil Jeon" To: Date: Mon, 6 Apr 2015 13:37:30 +0100 Message-ID: <001801d07066$72a02f60$57e08e20$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D0706E.D4661E00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBwZm2i2ylKNdqARD+V8izx9g6IEg== Content-Language: ko Archived-At: Subject: [DMM] test (ignore) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:44:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01D0706E.D4661E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit test ------=_NextPart_000_0019_01D0706E.D4661E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

test

 

 

------=_NextPart_000_0019_01D0706E.D4661E00-- From nobody Tue Apr 7 06:44:54 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091801B3598 for ; Tue, 7 Apr 2015 06:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 uYyohLsu048x for ; Tue, 7 Apr 2015 06:44:46 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3F1B3589 for ; Tue, 7 Apr 2015 06:44:44 -0700 (PDT) Received: from mail-wg0-f51.google.com (account seiljeon@av.it.pt [74.125.82.51] verified) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77447596 for dmm@ietf.org; Sun, 05 Apr 2015 19:30:54 +0100 Received: by wgra20 with SMTP id a20so12213203wgr.3 for ; Sun, 05 Apr 2015 11:30:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.75.168 with SMTP id d8mr24763631wjw.87.1428258653615; Sun, 05 Apr 2015 11:30:53 -0700 (PDT) Received: by 10.28.52.196 with HTTP; Sun, 5 Apr 2015 11:30:53 -0700 (PDT) In-Reply-To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> Date: Sun, 5 Apr 2015 19:30:53 +0100 Message-ID: From: Seil Jeon To: "Moses, Danny" Content-Type: multipart/alternative; boundary=047d7bb04bc8b23e570512fe61a7 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:44:51 -0000 --047d7bb04bc8b23e570512fe61a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Danny, Meeting is always good, even with you by f-to-f. But in the discussion, the main issue is whether we will allow the default source address selection rules defined in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The latter approach is not reasonable no matter how I try to think of.it. If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API. Regards. Seil On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny wrote= : > Hi Seil, > > > > By now we have been discussing this for quite some time and clearly we di= d > not succeed in convincing each other. > > I suggest we try again when we have a chance to meet face to face. > Meanwhile, let's listen to what other people have to say on this matter. > > > > Regards, > > /Danny > > > > *From:* Seil Jeon [mailto:seiljeon@av.it.pt] > *Sent:* Sunday, April 05, 2015 01:16 > *To:* Moses, Danny > *Cc:* dmm@ietf.org > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Resent. > > > > Seil > > > > *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] > *Sent:* Saturday, April 04, 2015 1:35 PM > *To:* 'Moses, Danny' > *Cc:* 'dmm@ietf.org' > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > See the inline please. I marked current replies with =E2=80=9C>>=E2=80=9D= and previous > replies with =E2=80=9C>=E2=80=9D for you to catch them easily. > > > > Regards, > > Seil > > > > > > *From:* Moses, Danny [mailto:danny.moses@intel.com ] > > *Sent:* Thursday, April 02, 2015 2:16 PM > *To:* Seil Jeon > *Cc:* dmm@ietf.org > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Seil, > > > > Please see my replies (surrounded by >>2) to yours. > > > > Regards, > > /Danny > > > > *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] > *Sent:* Tuesday, March 31, 2015 15:23 > *To:* Moses, Danny > *Cc:* dmm@ietf.org > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > See the inline please. > > > > > > Seil Jeon > > > > > > *From:* Moses, Danny [mailto:danny.moses@intel.com ] > > *Sent:* Monday, March 30, 2015 4:44 PM > *To:* Seil Jeon > *Cc:* dmm@ietf.org > *Subject:* RE: [DMM] Answer on raised questions for the proposed API > > > > Hi Seil, > > > > As to the potential of abuse: > > Yes, I see your point and you are correct. If the IP stack will not > request a sustained IP address more than once after each movement to a ne= w > LAN (with a different prefix), than there will be no abuse. > > > > > Yes, it=E2=80=99s true. Thanks for correction. > > > > As to the second comment, please let me elaborate: > > One potential implementation of the IP stack in the host, can be to > request a Nomadic IP address and a Sustained IP address whenever > connecting to a network, and whenever moving to a new LAN, regardless if > there are any applications requesting any addresses. This way, whenever a= n > application is launched and requests either a Nomadic or Sustained IP > address, the stack can provide one without having to issue a request to t= he > network. In this case, there is no need for this flag from the applicatio= n. > > > > > Decision of which type of IP address by default will be depending on th= e > IP pool management policy by operators. You case may correspond to one of > them. What if only the Nomadic IP address is basically allocated upon a > network attachment? That is, a lot of applications require mere Internet > connectivity without session continuity support. So, the Sustained IP > address will be requested on demand, and the proposed flag will be used t= o > get a new Sustained IP address by expressing the explicit request by an > application. > > > > >>2 > > As I mentioned at the beginning of the description =E2=80=93 it is a desc= ription > of one alternative. I am not assuming it is the only scenario. > > Yes, I agree that many apps require only Nomadic IP addresses, but in thi= s > example, the IP stack in the host pre-allocates both Nomadic and Sustaine= d > IP addresses upon attachment=E2=80=A6 > > > > >> As I said, it could be, but not as general one. The proposed API is > useful through the explicit expression for any potential scenarios. > > > > Yes, we can describe an alternative in which a Nomadic IP address is > pre-allocated upon NW connection (and after every movement to a new LAN) > and a Sustained (and/or Fixed) address is allocated on-demand. Even in su= ch > a scenario, I do not see any use for this flag =E2=80=93 see my reply to = the second > item below=E2=80=A6 > > >>2 > > > > >> My answer was already given in following answer in previous email. > > > > Another potential implementation of the IP stack in the host is not to > request IP addresses in advance. In that case, it will issue a request fo= r > a Nomadic IP address or a Sustained IP address the first time an > application requests one and use it for subsequent requests as long as it > is not moving to a different LAN. Once it moves, it will again request a > new IP address (Nomadic or Sustained =E2=80=93 according to what is requi= red) after > receiving the first request from any application. In this case as well, > there is no need for this flag. > > > > > Another application requested just Sustained IP address while the IP > stack has already a Sustained IP address. Why should the IP stack try to > get a new one, though the application indicated simply =E2=80=9CSustained= IP > address type=E2=80=9D? You case took a step towards a solution where you = want to > draw. I don=E2=80=99t expect the action is generic when a Sustained IP ad= dress type > is requested. > > Besides, you assumption on IP address allocation seems not valid. A mobil= e > host would get an IP address whatever the allocated IP address type is wh= en > it attaches at a network, regardless of an application=E2=80=99s IP addre= ss request. > > > > >>2 > > Looks like I did not express myself well enough (and did not fully > understand your reply). Let me list some events that might help clarify= =E2=80=A6 > > > > Initial state: Mobile node is connected to a network; no Sustained IP > address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) > indicating that if an application requests a Sustained IP address, it wil= l > have to request one from the network. > > > > Event1: An application that requires a Sustained IP address is launched. > > APP action: App requests a Sustained IP address from the IP stack using > the proposed new API. > > IP stack action: Since SustainedIPAddressNeeded is set, request one from > the network. > > Network action: Assigned a Sustained IP address to the mobile node. > > IP stack action: (1) Mark the new Sustained IP address as the one to be > associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; > (3)Complete the API action and associate the marked Sustained IP address > with that port (app) > > > > Event2: A new application that also required a Sustained IP address is > launched > > App action: App requests a Sustained IP address from the IP stack using > the proposed new API > > IP Stack action: Since SustainedIPAddressNeeded is not set, complete the > API action and associate the marked Sustained IP address with that port > (app) > > > > Event3: The mobile node moves to a new LAN > > IP Stack action: Set a flag indicating that the currently available > Sustained IP address is not optimized > > > > Event4: An application that requires a Sustained IP address is launched. > > APP action: App requests a Sustained IP address from the IP stack using > the proposed new API. > > IP stack action: Since SustainedIPAddressNeeded is set, request one from > the network. > > Network action: Assigned a Sustained IP address to the mobile node. > > IP stack action: (1) Mark the new Sustained IP address as the one to be > associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; > (3)Complete the API action and associate the marked Sustained IP address > with that port (app) > > > > Note that the behavior of the IP stack in Event4 is exactly like the one > in Event1. > > > > *I believe that this event is the one we have different of opinions: I > think that the default behavior of the IP stack is to request a new > Sustained IP address since it moved to a new LAN, and you think that it > should do so only if the application specifically requests a new Sustaine= d > IP address via the flag you are proposing.* > > >>2 > > > > >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this mail. > > > > As a matter of fact, if such a flag is defined, I cannot think of an > example where it will not be used. It seems to me that applications will > always request a refreshed Sustained IP address (when requesting a > Sustained IP address). If this is correct, the flag is redundant. > > > > > Some applications, e.g. email, that are not relatively restricted from > optimal routing would consider a Sustained IP address without issuing the > new flag. More applications based on such network characteristic can be > thought more than expected. > > And such use of existing Sustained IP address is not extraordinary, since > IP address is a resource, even in the consideration of IPv6 deployment. I= f > as many as applications require new Sustained IP address, it will end up = in > a lot of network resource consumption in the mobility routers where the > Sustained IP addresses are anchored as the terminal moves. > > >>2 > > I am sorry but I disagree with the email example. I categorize it as an > example of an application that will request a Nomadic address since it do= es > not break when the mobile node moves to a new LAN and the source IP addre= ss > is changed. It simply restarts the socket and continue with the new sourc= e > IP address (the user will not even notice this). > > > > >> The example was given as a benefit when the existing Sustained IP > address is used. You could get some insight from such kind of application > not caring much the routing distance even on the Sustained IP address. > > > > I did not understand the other text regarding resource consumption. I > thought we agreed that even of a new Sustained IP address is requested up= on > each movement to a new LAN, the effect on IP address allocation is not > significant. Otherwise, my initial comment on applications abusing the > network using your proposed flag, becomes valid again > > >>2 > > > > >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustained = IP > address is requested upon receiving *new* flag from an application, as a > preference for a source address selection. You need to read our draft > classifying the categories of IP address request again. > > > > Besides, I don=E2=80=99t understand what is abused. Delivering its prefer= ence > cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it in your defa= ult behavior > you=E2=80=99re assuming here. In your scenario, a new app initiated in a = new > network will be forced to use a newly obtained Sustained IP address. You > see that? You totally block the possibility to be considered by the defau= lt > source address selection rules defined in RFC6724. But in our draft, in > case the need of a newly obtained Sustained IP address is prioritized, th= e > proposed *new* flag can be used by app=E2=80=99s request, thus it will be= selected > with priority. > > > > Can you provide a scenario in which an application will not request to > refresh the Sustained IP address? > > > > > It was mentioned in the former comments. > > > > > > Regards, > > /Danny > > *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] > *Sent:* Monday, March 30, 2015 17:08 > *To:* Moses, Danny > *Cc:* dmm@ietf.org > *Subject:* FW: [DMM] Answer on raised questions for the proposed API > > > > Hi Danny, > > > > Any comments? > > > > Regards, > > Seil Jeon > > > > > > *From:* dmm [mailto:dmm-bounces@ietf.org ] *On > Behalf Of *Seil Jeon > *Sent:* Thursday, March 26, 2015 8:08 PM > *To:* dmm@ietf.org > *Subject:* [DMM] Answer on raised questions for the proposed API > > > > Hi, > > > > I could attend DMM Thursday meeting via MeetEcho. > > I could also hear some raised comments by Danny and Someone. Here goes > answers to the raised questions. > > > > > > First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), > > > > The use of the proposed API is suggested in the SUSTAINED IP address case > in the draft. On receiving this API with the SUSTAINED IP address type at > the IP stack, it will try to get a new SUSTAINED IP address if there is n= o > available in the currently attached access network. So, actual obtaining = of > the IP address will be tried one time while attached at a specific access > network. Even some applications put this API after, the already obtained > SUSTAINED IP will be used. So, no worries about abuse. > > > > Second question sounded to me like that this API is not needed because th= e > host can get a new SUSTAINED IP address, right? > > If the question is right, I don=E2=80=99t understand what the question is= meant, > that is how the host can get a new SUSTAINED IP address? > > Based on the definition of three types of IP address, an application > should show its requirement with an API among them. If it is the SUSTAINE= D > IP address, how do we expect the IP stack will try to get a new SUSTAINED > IP address? > > > > Besides, the propsoed API is not used alone but with the three type APIs. > > > > > > > > Regards, > > > > Seil Jeon > > > > > > --------------------------------------------------------------------- > 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. > > --------------------------------------------------------------------- > 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 > > --047d7bb04bc8b23e570512fe61a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Danny,

=C2= =A0

Meet= ing is always good, even with you by f-to-f. But in the discussion, the main is= sue is whether we will allow the default source address selection rules defined= in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The la= tter approach is not reasonable no matter how I try to think of.it.

If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API.

=C2= =A0

Rega= rds.

Seil=


On Sun, Ap= r 5, 2015 at 12:22 PM, Moses, Danny <danny.moses@intel.com> wrote:

Hi Seil,=

=C2=A0

By now we have = been discussing this for quite some time and clearly we did not succeed in = convincing each other.

I suggest we tr= y again when we have a chance to meet face to face. Meanwhile, let's li= sten to what other people have to say on this matter.<= /p>

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [m= ailto:seiljeon@av.it= .pt]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Resent.

=C2=A0

Seil

=C2=A0

From: Seil Jeon [<= a href=3D"mailto:seiljeon@av.it.pt" target=3D"_blank">mailto:seiljeon@av.it= .pt]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm@ietf.= org'
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please. I marked curre= nt replies with =E2=80=9C>>=E2=80=9D and previous replies with =E2=80= =9C>=E2=80=9D for you to catch them easily.

=C2=A0

Regards,

Seil

=C2=A0

=C2=A0

From: Moses,= Danny [<= span style=3D"font-family:"Tahoma","sans-serif";font-si= ze:10pt">mailto:danny.moses@intel.com]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

Please see my r= eplies (surrounded by =C2=A0>>2) to yours.

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please.<= /span>

=C2=A0

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

From: Moses, Danny= [mailto:danny.moses@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

As to the poten= tial of abuse:

Yes, I see your= point and you are correct. If the IP stack will not request a sustained IP= address more than once after each movement to a new LAN (with a different = prefix), than there will be no abuse.

=C2=A0

> Yes, it=E2=80=99s true. Thanks for correction.=

=C2=A0

As to the secon= d comment, please let me elaborate:

One potential i= mplementation of the IP stack in the host, can be to request a Nomadic IP a= ddress and a =C2=A0Sustained IP address whenever connecting to a network, a= nd whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

=C2=A0

> Decision of which type of IP address by defaul= t will be depending on the IP pool management policy by operators. You case= may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applic= ations require mere Internet connectivity without session continuity suppor= t. So, the Sustained IP address will be requested on demand, and the propos= ed flag will be used to get a new Sustained IP address by expressing the explicit request by an application.=

=C2=A0

>>2

As I mentioned = at the beginning of the description =E2=80=93 it is a description of one al= ternative. I am not assuming it is the only scenario.<= /p>

Yes, I agree th= at many apps require only Nomadic IP addresses, but in this example, the IP= stack in the host pre-allocates both Nomadic and Sustained IP addresses up= on attachment=E2=80=A6

=C2=A0

>> As I said, it could be, but not as general= one. The proposed API is useful through the explicit expression for any po= tential scenarios.

=C2=A0

Yes, we can des= cribe an alternative in which a Nomadic IP address is pre-allocated upon NW= connection (and after every movement to a new LAN) and a Sustained (and/or= Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag =E2=80=93 see my re= ply to the second item below=E2=80=A6

>>2

=C2=A0

>> My answer was already given in following a= nswer in previous email.=

=C2=A0

Another potenti= al implementation of the IP stack in the host is not to request IP addresse= s in advance. In that case, it will issue a request for a Nomadic IP addres= s or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained =E2=80=93 according to what is requir= ed) after receiving the first request from any application. In this case as well, there is no need for this flag.<= /u>

=C2=A0

> Another application requested just Sustained I= P address while the IP stack has already a Sustained IP address. Why should= the IP stack try to get a new one, though the application indicated simply =E2=80=9CSustained IP address type=E2=80=9D? You case took a step t= owards a solution where you want to draw. I don=E2=80=99t expect the action= is generic when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application=E2=80=99s IP address request.

=C2=A0

>>2

Looks like I did not express myself w= ell enough (and did not fully understand your reply). Let me list some even= ts that might help clarify=E2=80=A6

=C2=A0

Initial state: Mobile node is connect= ed to a network; no Sustained IP address is allocated. The IP stack sets a = flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

=C2=A0

Event1: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Event2: A new application that also r= equired a Sustained IP address is launched

App action: App requests a Sustained = IP address from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAdd= ressNeeded =C2=A0is not set, complete the API action and associate the mark= ed Sustained IP address with that port (app)

=C2=A0

Event3: The mobile node moves to a ne= w LAN

IP Stack action: Set a flag indicatin= g that the currently available Sustained IP address is not optimized

=C2=A0

Event4: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Note that the behavior of the IP stac= k in Event4 is exactly like the one in Event1.

=C2=A0

I believe that this event is the o= ne we have different of opinions: I think that the default behavior of the = IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

=C2=A0

>> You can see my answer at the lowest =E2=80= =9C>>=E2=80=9D in this mail.

=C2=A0

As a matter of = fact, if such a flag is defined, I cannot think of an example where it will= not be used. It seems to me that applications will always request a refres= hed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

=C2=A0

> Some applications, e.g. email, that are not re= latively restricted from optimal routing would consider a Sustained IP addr= ess without issuing the new flag. More applications based on such network characteristic can be thought more than expected.

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but = I disagree with the email example. I categorize it as an example of an appl= ication that will request a Nomadic address since it does not break when th= e mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).<= /span>

=C2=A0

>> The example was given as a benefit when th= e existing Sustained IP address is used. You could get some insight from su= ch kind of application not caring much the routing distance even on the Sustained IP address.

=C2=A0

I did not under= stand the other text regarding resource consumption. I thought we agreed th= at even of a new Sustained IP address is requested upon each movement to a = new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again

>>2

=C2=A0

>> No, our draft didn=E2=80=99t say so. Our i= dea is that a new Sustained IP address is requested upon receiving *new* fl= ag from an application, as a preference for a source address selection. You= need to read our draft classifying the categories of IP address request again.<= u>

=C2=A0

Besides, I don=E2=80=99t understand what is abused. Delive= ring its preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I s= ee it in your default behavior you=E2=80=99re assuming here. In your scenar= io, a new app initiated in a new network will be forced to use a newly obtained Sustaine= d IP address. You see that? You totally block the possibility to be conside= red by the default source address selection rules defined in RFC6724. But i= n our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* f= lag can be used by app=E2=80=99s request, thus it will be selected with pri= ority.

=C2=A0

Can you provide= a scenario in which an application will not request to refresh the Sustain= ed IP address?

=C2=A0

> It was mentioned in the former comments.

=C2=A0

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

Any comments?

=C2=A0

Regards,

Seil Jeon

=C2=A0

=C2=A0

From: dmm [= mailto:= dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi,

=C2=A0

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

=C2=A0

=C2=A0

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

=C2=A0

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

=C2=A0

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?<= /u>

If the question is right, I don=E2=80=99t understand what = the question is meant, that is how the host can get a new SUSTAINED IP addr= ess?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

=C2=A0

Besides, the propsoed API is not used alone but with the t= hree type APIs.

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

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

--------------------------------------------------------------------- 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
htt= ps://www.ietf.org/mailman/listinfo/dmm


--047d7bb04bc8b23e570512fe61a7-- From nobody Tue Apr 7 06:56:33 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1E1B35D4 for ; Tue, 7 Apr 2015 06:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 s_w_VWClerYZ for ; Tue, 7 Apr 2015 06:56:26 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D48351B35D1 for ; Tue, 7 Apr 2015 06:56:24 -0700 (PDT) Received: from mail-wg0-f41.google.com (account seiljeon@av.it.pt [74.125.82.41] verified) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77447621 for dmm@ietf.org; Sun, 05 Apr 2015 19:41:17 +0100 Received: by wgyo15 with SMTP id o15so1381221wgy.2 for ; Sun, 05 Apr 2015 11:41:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.75.168 with SMTP id d8mr24828429wjw.87.1428259277144; Sun, 05 Apr 2015 11:41:17 -0700 (PDT) Received: by 10.28.52.196 with HTTP; Sun, 5 Apr 2015 11:41:17 -0700 (PDT) In-Reply-To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> Date: Sun, 5 Apr 2015 19:41:17 +0100 Message-ID: From: Seil Jeon To: "Moses, Danny" Content-Type: multipart/alternative; boundary=047d7bb04bc8dc89520512fe86c5 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:56:31 -0000 --047d7bb04bc8dc89520512fe86c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been experiencing a mail posting problem on the list. It is forwarded with a different mail account. @Danny, Sorry if you got multiple mails. Regards, Seil Jeon On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon wrote: > Hi Danny, > > > > Meeting is always good, even with you by f-to-f. But in the discussion, > the main issue is whether we will allow the default source address > selection rules defined in RFC6724 for selecting a Sustained IP address > among several ones or fundamentally block them for a specific reason rais= ed > by a DMM need. The latter approach is not reasonable no matter how I try = to > think of.it. > > If an application has the specific preference of a newly obtained > Sustained IP address, it uses the proposed API. > > > > Regards. > > Seil > > On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny > wrote: > >> Hi Seil, >> >> >> >> By now we have been discussing this for quite some time and clearly we >> did not succeed in convincing each other. >> >> I suggest we try again when we have a chance to meet face to face. >> Meanwhile, let's listen to what other people have to say on this matter. >> >> >> >> Regards, >> >> /Danny >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt] >> *Sent:* Sunday, April 05, 2015 01:16 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Resent. >> >> >> >> Seil >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Saturday, April 04, 2015 1:35 PM >> *To:* 'Moses, Danny' >> *Cc:* 'dmm@ietf.org' >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> See the inline please. I marked current replies with =E2=80=9C>>=E2=80= =9D and previous >> replies with =E2=80=9C>=E2=80=9D for you to catch them easily. >> >> >> >> Regards, >> >> Seil >> >> >> >> >> >> *From:* Moses, Danny [mailto:danny.moses@intel.com >> ] >> *Sent:* Thursday, April 02, 2015 2:16 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Seil, >> >> >> >> Please see my replies (surrounded by >>2) to yours. >> >> >> >> Regards, >> >> /Danny >> >> >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Tuesday, March 31, 2015 15:23 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> See the inline please. >> >> >> >> >> >> Seil Jeon >> >> >> >> >> >> *From:* Moses, Danny [mailto:danny.moses@intel.com >> ] >> *Sent:* Monday, March 30, 2015 4:44 PM >> *To:* Seil Jeon >> *Cc:* dmm@ietf.org >> *Subject:* RE: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Seil, >> >> >> >> As to the potential of abuse: >> >> Yes, I see your point and you are correct. If the IP stack will not >> request a sustained IP address more than once after each movement to a n= ew >> LAN (with a different prefix), than there will be no abuse. >> >> >> >> > Yes, it=E2=80=99s true. Thanks for correction. >> >> >> >> As to the second comment, please let me elaborate: >> >> One potential implementation of the IP stack in the host, can be to >> request a Nomadic IP address and a Sustained IP address whenever >> connecting to a network, and whenever moving to a new LAN, regardless if >> there are any applications requesting any addresses. This way, whenever = an >> application is launched and requests either a Nomadic or Sustained IP >> address, the stack can provide one without having to issue a request to = the >> network. In this case, there is no need for this flag from the applicati= on. >> >> >> >> > Decision of which type of IP address by default will be depending on >> the IP pool management policy by operators. You case may correspond to o= ne >> of them. What if only the Nomadic IP address is basically allocated upon= a >> network attachment? That is, a lot of applications require mere Internet >> connectivity without session continuity support. So, the Sustained IP >> address will be requested on demand, and the proposed flag will be used = to >> get a new Sustained IP address by expressing the explicit request by an >> application. >> >> >> >> >>2 >> >> As I mentioned at the beginning of the description =E2=80=93 it is a des= cription >> of one alternative. I am not assuming it is the only scenario. >> >> Yes, I agree that many apps require only Nomadic IP addresses, but in >> this example, the IP stack in the host pre-allocates both Nomadic and >> Sustained IP addresses upon attachment=E2=80=A6 >> >> >> >> >> As I said, it could be, but not as general one. The proposed API is >> useful through the explicit expression for any potential scenarios. >> >> >> >> Yes, we can describe an alternative in which a Nomadic IP address is >> pre-allocated upon NW connection (and after every movement to a new LAN) >> and a Sustained (and/or Fixed) address is allocated on-demand. Even in s= uch >> a scenario, I do not see any use for this flag =E2=80=93 see my reply to= the second >> item below=E2=80=A6 >> >> >>2 >> >> >> >> >> My answer was already given in following answer in previous email. >> >> >> >> Another potential implementation of the IP stack in the host is not to >> request IP addresses in advance. In that case, it will issue a request f= or >> a Nomadic IP address or a Sustained IP address the first time an >> application requests one and use it for subsequent requests as long as i= t >> is not moving to a different LAN. Once it moves, it will again request a >> new IP address (Nomadic or Sustained =E2=80=93 according to what is requ= ired) after >> receiving the first request from any application. In this case as well, >> there is no need for this flag. >> >> >> >> > Another application requested just Sustained IP address while the IP >> stack has already a Sustained IP address. Why should the IP stack try to >> get a new one, though the application indicated simply =E2=80=9CSustaine= d IP >> address type=E2=80=9D? You case took a step towards a solution where you= want to >> draw. I don=E2=80=99t expect the action is generic when a Sustained IP a= ddress type >> is requested. >> >> Besides, you assumption on IP address allocation seems not valid. A >> mobile host would get an IP address whatever the allocated IP address ty= pe >> is when it attaches at a network, regardless of an application=E2=80=99s= IP address >> request. >> >> >> >> >>2 >> >> Looks like I did not express myself well enough (and did not fully >> understand your reply). Let me list some events that might help clarify= =E2=80=A6 >> >> >> >> Initial state: Mobile node is connected to a network; no Sustained IP >> address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded= ) >> indicating that if an application requests a Sustained IP address, it wi= ll >> have to request one from the network. >> >> >> >> Event1: An application that requires a Sustained IP address is launched. >> >> APP action: App requests a Sustained IP address from the IP stack using >> the proposed new API. >> >> IP stack action: Since SustainedIPAddressNeeded is set, request one from >> the network. >> >> Network action: Assigned a Sustained IP address to the mobile node. >> >> IP stack action: (1) Mark the new Sustained IP address as the one to be >> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; >> (3)Complete the API action and associate the marked Sustained IP address >> with that port (app) >> >> >> >> Event2: A new application that also required a Sustained IP address is >> launched >> >> App action: App requests a Sustained IP address from the IP stack using >> the proposed new API >> >> IP Stack action: Since SustainedIPAddressNeeded is not set, complete th= e >> API action and associate the marked Sustained IP address with that port >> (app) >> >> >> >> Event3: The mobile node moves to a new LAN >> >> IP Stack action: Set a flag indicating that the currently available >> Sustained IP address is not optimized >> >> >> >> Event4: An application that requires a Sustained IP address is launched. >> >> APP action: App requests a Sustained IP address from the IP stack using >> the proposed new API. >> >> IP stack action: Since SustainedIPAddressNeeded is set, request one from >> the network. >> >> Network action: Assigned a Sustained IP address to the mobile node. >> >> IP stack action: (1) Mark the new Sustained IP address as the one to be >> associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; >> (3)Complete the API action and associate the marked Sustained IP address >> with that port (app) >> >> >> >> Note that the behavior of the IP stack in Event4 is exactly like the one >> in Event1. >> >> >> >> *I believe that this event is the one we have different of opinions: I >> think that the default behavior of the IP stack is to request a new >> Sustained IP address since it moved to a new LAN, and you think that it >> should do so only if the application specifically requests a new Sustain= ed >> IP address via the flag you are proposing.* >> >> >>2 >> >> >> >> >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this mail= . >> >> >> >> As a matter of fact, if such a flag is defined, I cannot think of an >> example where it will not be used. It seems to me that applications will >> always request a refreshed Sustained IP address (when requesting a >> Sustained IP address). If this is correct, the flag is redundant. >> >> >> >> > Some applications, e.g. email, that are not relatively restricted from >> optimal routing would consider a Sustained IP address without issuing th= e >> new flag. More applications based on such network characteristic can be >> thought more than expected. >> >> And such use of existing Sustained IP address is not extraordinary, sinc= e >> IP address is a resource, even in the consideration of IPv6 deployment. = If >> as many as applications require new Sustained IP address, it will end up= in >> a lot of network resource consumption in the mobility routers where the >> Sustained IP addresses are anchored as the terminal moves. >> >> >>2 >> >> I am sorry but I disagree with the email example. I categorize it as an >> example of an application that will request a Nomadic address since it d= oes >> not break when the mobile node moves to a new LAN and the source IP addr= ess >> is changed. It simply restarts the socket and continue with the new sour= ce >> IP address (the user will not even notice this). >> >> >> >> >> The example was given as a benefit when the existing Sustained IP >> address is used. You could get some insight from such kind of applicatio= n >> not caring much the routing distance even on the Sustained IP address. >> >> >> >> I did not understand the other text regarding resource consumption. I >> thought we agreed that even of a new Sustained IP address is requested u= pon >> each movement to a new LAN, the effect on IP address allocation is not >> significant. Otherwise, my initial comment on applications abusing the >> network using your proposed flag, becomes valid again >> >> >>2 >> >> >> >> >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustained= IP >> address is requested upon receiving *new* flag from an application, as a >> preference for a source address selection. You need to read our draft >> classifying the categories of IP address request again. >> >> >> >> Besides, I don=E2=80=99t understand what is abused. Delivering its prefe= rence >> cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it in your def= ault behavior >> you=E2=80=99re assuming here. In your scenario, a new app initiated in a= new >> network will be forced to use a newly obtained Sustained IP address. You >> see that? You totally block the possibility to be considered by the defa= ult >> source address selection rules defined in RFC6724. But in our draft, in >> case the need of a newly obtained Sustained IP address is prioritized, t= he >> proposed *new* flag can be used by app=E2=80=99s request, thus it will b= e selected >> with priority. >> >> >> >> Can you provide a scenario in which an application will not request to >> refresh the Sustained IP address? >> >> >> >> > It was mentioned in the former comments. >> >> >> >> >> >> Regards, >> >> /Danny >> >> *From:* Seil Jeon [mailto:seiljeon@av.it.pt ] >> *Sent:* Monday, March 30, 2015 17:08 >> *To:* Moses, Danny >> *Cc:* dmm@ietf.org >> *Subject:* FW: [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi Danny, >> >> >> >> Any comments? >> >> >> >> Regards, >> >> Seil Jeon >> >> >> >> >> >> *From:* dmm [mailto:dmm-bounces@ietf.org ] *On >> Behalf Of *Seil Jeon >> *Sent:* Thursday, March 26, 2015 8:08 PM >> *To:* dmm@ietf.org >> *Subject:* [DMM] Answer on raised questions for the proposed API >> >> >> >> Hi, >> >> >> >> I could attend DMM Thursday meeting via MeetEcho. >> >> I could also hear some raised comments by Danny and Someone. Here goes >> answers to the raised questions. >> >> >> >> >> >> First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), >> >> >> >> The use of the proposed API is suggested in the SUSTAINED IP address cas= e >> in the draft. On receiving this API with the SUSTAINED IP address type a= t >> the IP stack, it will try to get a new SUSTAINED IP address if there is = no >> available in the currently attached access network. So, actual obtaining= of >> the IP address will be tried one time while attached at a specific acces= s >> network. Even some applications put this API after, the already obtained >> SUSTAINED IP will be used. So, no worries about abuse. >> >> >> >> Second question sounded to me like that this API is not needed because >> the host can get a new SUSTAINED IP address, right? >> >> If the question is right, I don=E2=80=99t understand what the question i= s meant, >> that is how the host can get a new SUSTAINED IP address? >> >> Based on the definition of three types of IP address, an application >> should show its requirement with an API among them. If it is the SUSTAIN= ED >> IP address, how do we expect the IP stack will try to get a new SUSTAINE= D >> IP address? >> >> >> >> Besides, the propsoed API is not used alone but with the three type APIs= . >> >> >> >> >> >> >> >> Regards, >> >> >> >> Seil Jeon >> >> >> >> >> >> --------------------------------------------------------------------- >> 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. >> >> --------------------------------------------------------------------- >> 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 >> >> > --047d7bb04bc8dc89520512fe86c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been experiencing a mail posting problem on th= e list. It is forwarded with a different mail account.

=
@Danny, Sorry if you got multiple mails.

Rega= rds,
Seil Jeon

On Sun, Apr 5, 2015 at 7:30 PM, Seil Jeon <sei= ljeon@av.it.pt> wrote:
<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

Hi Danny,

=C2= =A0

Meet= ing is always good, even with you by f-to-f. But in the discussion, the main is= sue is whether we will allow the default source address selection rules defined= in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The la= tter approach is not reasonable no matter how I try to think of.it.

If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API.

=C2= =A0

Rega= rds.

Seil=


On Sun, Apr 5, 2015 at 12:22 PM, Moses, Danny <danny.mose= s@intel.com> wrote:

Hi Seil,=

=C2=A0

By now we have = been discussing this for quite some time and clearly we did not succeed in = convincing each other.

I suggest we tr= y again when we have a chance to meet face to face. Meanwhile, let's li= sten to what other people have to say on this matter.<= /p>

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [m= ailto:seiljeon@av.it= .pt]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Resent.

=C2=A0

Seil

=C2=A0

From: Seil Jeon [<= a href=3D"mailto:seiljeon@av.it.pt" target=3D"_blank">mailto:seiljeon@av.it= .pt]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm@ietf.= org'
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please. I marked curre= nt replies with =E2=80=9C>>=E2=80=9D and previous replies with =E2=80= =9C>=E2=80=9D for you to catch them easily.

=C2=A0

Regards,

Seil

=C2=A0

=C2=A0

From: Moses,= Danny [<= span style=3D"font-family:"Tahoma","sans-serif";font-si= ze:10pt">mailto:danny.moses@intel.com]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

Please see my r= eplies (surrounded by =C2=A0>>2) to yours.

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

=C2=A0

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

See the inline please.<= /span>

=C2=A0

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

From: Moses, Danny= [mailto:danny.moses@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Seil,=

=C2=A0

As to the poten= tial of abuse:

Yes, I see your= point and you are correct. If the IP stack will not request a sustained IP= address more than once after each movement to a new LAN (with a different = prefix), than there will be no abuse.

=C2=A0

> Yes, it=E2=80=99s true. Thanks for correction.=

=C2=A0

As to the secon= d comment, please let me elaborate:

One potential i= mplementation of the IP stack in the host, can be to request a Nomadic IP a= ddress and a =C2=A0Sustained IP address whenever connecting to a network, a= nd whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

=C2=A0

> Decision of which type of IP address by defaul= t will be depending on the IP pool management policy by operators. You case= may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applic= ations require mere Internet connectivity without session continuity suppor= t. So, the Sustained IP address will be requested on demand, and the propos= ed flag will be used to get a new Sustained IP address by expressing the explicit request by an application.=

=C2=A0

>>2

As I mentioned = at the beginning of the description =E2=80=93 it is a description of one al= ternative. I am not assuming it is the only scenario.<= /p>

Yes, I agree th= at many apps require only Nomadic IP addresses, but in this example, the IP= stack in the host pre-allocates both Nomadic and Sustained IP addresses up= on attachment=E2=80=A6

=C2=A0

>> As I said, it could be, but not as general= one. The proposed API is useful through the explicit expression for any po= tential scenarios.

=C2=A0

Yes, we can des= cribe an alternative in which a Nomadic IP address is pre-allocated upon NW= connection (and after every movement to a new LAN) and a Sustained (and/or= Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag =E2=80=93 see my re= ply to the second item below=E2=80=A6

>>2

=C2=A0

>> My answer was already given in following a= nswer in previous email.=

=C2=A0

Another potenti= al implementation of the IP stack in the host is not to request IP addresse= s in advance. In that case, it will issue a request for a Nomadic IP addres= s or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained =E2=80=93 according to what is requir= ed) after receiving the first request from any application. In this case as well, there is no need for this flag.<= /u>

=C2=A0

> Another application requested just Sustained I= P address while the IP stack has already a Sustained IP address. Why should= the IP stack try to get a new one, though the application indicated simply =E2=80=9CSustained IP address type=E2=80=9D? You case took a step t= owards a solution where you want to draw. I don=E2=80=99t expect the action= is generic when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application=E2=80=99s IP address request.

=C2=A0

>>2

Looks like I did not express myself w= ell enough (and did not fully understand your reply). Let me list some even= ts that might help clarify=E2=80=A6

=C2=A0

Initial state: Mobile node is connect= ed to a network; no Sustained IP address is allocated. The IP stack sets a = flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

=C2=A0

Event1: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Event2: A new application that also r= equired a Sustained IP address is launched

App action: App requests a Sustained = IP address from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAdd= ressNeeded =C2=A0is not set, complete the API action and associate the mark= ed Sustained IP address with that port (app)

=C2=A0

Event3: The mobile node moves to a ne= w LAN

IP Stack action: Set a flag indicatin= g that the currently available Sustained IP address is not optimized

=C2=A0

Event4: An application that requires = a Sustained IP address is launched.

APP action: App requests a Sustained = IP address from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAdd= ressNeeded is set, request one from the network.

Network action: Assigned a Sustained = IP address to the mobile node.

IP stack action: (1) Mark the new Sus= tained IP address as the one to be associated to subsequent apps; (2) Reset= SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)<= /p>

=C2=A0

Note that the behavior of the IP stac= k in Event4 is exactly like the one in Event1.

=C2=A0

I believe that this event is the o= ne we have different of opinions: I think that the default behavior of the = IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

=C2=A0

>> You can see my answer at the lowest =E2=80= =9C>>=E2=80=9D in this mail.

=C2=A0

As a matter of = fact, if such a flag is defined, I cannot think of an example where it will= not be used. It seems to me that applications will always request a refres= hed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

=C2=A0

> Some applications, e.g. email, that are not re= latively restricted from optimal routing would consider a Sustained IP addr= ess without issuing the new flag. More applications based on such network characteristic can be thought more than expected.

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but = I disagree with the email example. I categorize it as an example of an appl= ication that will request a Nomadic address since it does not break when th= e mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).<= /span>

=C2=A0

>> The example was given as a benefit when th= e existing Sustained IP address is used. You could get some insight from su= ch kind of application not caring much the routing distance even on the Sustained IP address.

=C2=A0

I did not under= stand the other text regarding resource consumption. I thought we agreed th= at even of a new Sustained IP address is requested upon each movement to a = new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again

>>2

=C2=A0

>> No, our draft didn=E2=80=99t say so. Our i= dea is that a new Sustained IP address is requested upon receiving *new* fl= ag from an application, as a preference for a source address selection. You= need to read our draft classifying the categories of IP address request again.<= u>

=C2=A0

Besides, I don=E2=80=99t understand what is abused. Delive= ring its preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I s= ee it in your default behavior you=E2=80=99re assuming here. In your scenar= io, a new app initiated in a new network will be forced to use a newly obtained Sustaine= d IP address. You see that? You totally block the possibility to be conside= red by the default source address selection rules defined in RFC6724. But i= n our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* f= lag can be used by app=E2=80=99s request, thus it will be selected with pri= ority.

=C2=A0

Can you provide= a scenario in which an application will not request to refresh the Sustain= ed IP address?

=C2=A0

> It was mentioned in the former comments.

=C2=A0

=C2=A0

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= /Danny

From: Seil Jeon [<= /span>mail= to:seiljeon@av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi Danny,

=C2=A0

Any comments?

=C2=A0

Regards,

Seil Jeon

=C2=A0

=C2=A0

From: dmm [= mailto:= dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API

=C2=A0

Hi,

=C2=A0

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

=C2=A0

=C2=A0

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

=C2=A0

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

=C2=A0

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?<= /u>

If the question is right, I don=E2=80=99t understand what = the question is meant, that is how the host can get a new SUSTAINED IP addr= ess?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

=C2=A0

Besides, the propsoed API is not used alone but with the t= hree type APIs.

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Seil Jeon

=C2=A0

=C2=A0

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

--------------------------------------------------------------------- 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
htt= ps://www.ietf.org/mailman/listinfo/dmm



--047d7bb04bc8dc89520512fe86c5-- From nobody Tue Apr 7 07:01:35 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553211A8839 for ; Tue, 7 Apr 2015 07:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GjHho1_V82y5 for ; Tue, 7 Apr 2015 07:01:26 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D5D891B35EF for ; Tue, 7 Apr 2015 07:01:05 -0700 (PDT) Received: from [188.80.144.210] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77445280; Sat, 04 Apr 2015 13:34:50 +0100 From: "Seil Jeon" To: "'Moses, Danny'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> In-Reply-To: Date: Sat, 4 Apr 2015 13:34:52 +0100 Message-ID: <006901d06ed3$bfaf83d0$3f0e8b70$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01D06EDC.217D88C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uYCqJZpkgDQIjNOm1Dp8+A= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 14:01:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01D06EDC.217D88C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danny, See the inline please. I marked current replies with ">>" and previous replies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request a sustained IP address more than once after each movement to a new LAN (with a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request a Nomadic IP address and a Sustained IP address whenever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an application is launched and requests either a Nomadic or Sustained IP address, the stack can provide one without having to issue a request to the network. In this case, there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the IP pool management policy by operators. You case may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applications require mere Internet connectivity without session continuity support. So, the Sustained IP address will be requested on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this example, the IP stack in the host pre-allocates both Nomadic and Sustained IP addresses upon attachment. >> As I said, it could be, but not as general one. The proposed API is useful through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-allocated upon NW connection (and after every movement to a new LAN) and a Sustained (and/or Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag - see my reply to the second item below. >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to request IP addresses in advance. In that case, it will issue a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as it is not moving to a different LAN. Once it moves, it will again request a new IP address (Nomadic or Sustained - according to what is required) after receiving the first request from any application. In this case as well, there is no need for this flag. > Another application requested just Sustained IP address while the IP stack has already a Sustained IP address. Why should the IP stack try to get a new one, though the application indicated simply "Sustained IP address type"? You case took a step towards a solution where you want to draw. I don't expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile host would get an IP address whatever the allocated IP address type is when it attaches at a network, regardless of an application's IP address request. >>2 Looks like I did not express myself well enough (and did not fully understand your reply). Let me list some events that might help clarify. Initial state: Mobile node is connected to a network; no Sustained IP address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Event2: A new application that also required a Sustained IP address is launched App action: App requests a Sustained IP address from the IP stack using the proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the API action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustained IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Note that the behavior of the IP stack in Event4 is exactly like the one in Event1. I believe that this event is the one we have different of opinions: I think that the default behavior of the IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application specifically requests a new Sustained IP address via the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an example where it will not be used. It seems to me that applications will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from optimal routing would consider a Sustained IP address without issuing the new flag. More applications based on such network characteristic can be thought more than expected. And such use of existing Sustained IP address is not extraordinary, since IP address is a resource, even in the consideration of IPv6 deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the mobility routers where the Sustained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an example of an application that will request a Nomadic address since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the new source IP address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP address is used. You could get some insight from such kind of application not caring much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thought we agreed that even of a new Sustained IP address is requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing the network using your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address is requested upon receiving *new* flag from an application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference cannot be abuse. Regarding "abuse", I see it in your default behavior you're assuming here. In your scenario, a new app initiated in a new network will be forced to use a newly obtained Sustained IP address. You see that? You totally block the possibility to be considered by the default source address selection rules defined in RFC6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* flag can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refresh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [ mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. ------=_NextPart_000_006A_01D06EDC.217D88C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Danny,

 

See the inline = please. I marked current replies with “>>” and = previous replies with “>” for you to catch them = easily.

 

Regards,

Seil

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Tuesday, March 31, 2015 15:23
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please.

 

 

Seil Jeon =

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Monday, March 30, 2015 4:44 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

As to the potential of = abuse:

Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

 

> = Yes, it’s true. Thanks for correction.

 

As to the = second comment, please let me elaborate:

One potential = implementation of the IP stack in the host, can be to request a Nomadic = IP address and a  Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any = applications requesting any addresses. This way, whenever an application = is launched and requests either a Nomadic or Sustained IP address, the = stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the = application.

 

> = Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one = of them. What if only the Nomadic IP address is basically allocated upon = a network attachment? That is, a lot of applications require mere = Internet connectivity without session continuity support. So, the = Sustained IP address will be requested on demand, and the proposed flag = will be used to get a new Sustained IP address by expressing the = explicit request by an application.

 

>>2

As I mentioned at the = beginning of the description – it is a description of one = alternative. I am not assuming it is the only = scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host = pre-allocates both Nomadic and Sustained IP addresses upon = attachment…

 

>> As I said, it could = be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 

Yes, we = can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or Fixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag – see my reply = to the second item below…

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential = implementation of the IP stack in the host is not to request IP = addresses in advance. In that case, it will issue a request for a = Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained – according to what = is required) after receiving the first request from any application. In = this case as well, there is no need for this = flag.

 

> = Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply “Sustained = IP address type”? You case took a step towards a solution where = you want to draw. I don’t expect the action is generic when a = Sustained IP address type is requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application’s IP address = request.

 

>>2 =

Looks like I = did not express myself well enough (and did not fully understand your = reply). Let me list some events that might help = clarify…

 

Initial state: = Mobile node is connected to a network; no Sustained IP address is = allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it = will have to request one from the network.

 

Event1: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Event2: A new = application that also required a Sustained IP address is launched =

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack = action: Since SustainedIPAddressNeeded  is not set, complete the = API action and associate the marked Sustained IP address with that port = (app)

 

Event3: The = mobile node moves to a new LAN

IP Stack = action: Set a flag indicating that the currently available Sustained IP = address is not optimized

 

Event4: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Note that the = behavior of the IP stack in Event4 is exactly like the one in = Event1.

 

I believe that = this event is the one we have different of opinions: I think that the = default behavior of the IP stack is to request a new Sustained IP = address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>>2

 

>> You can see my = answer at the lowest “>>” in this = mail.

 

As a matter of fact, if = such a flag is defined, I cannot think of an example where it will not = be used. It seems to me that applications will always request a = refreshed Sustained IP address (when requesting a Sustained IP address). = If this is correct, the flag is redundant.

 

> = Some applications, e.g. email, that are not relatively restricted from = optimal routing would consider a Sustained IP address without issuing = the new flag. More applications based on such network characteristic can = be thought more than expected.

And = such use of existing Sustained IP address is not extraordinary, since IP = address is a resource, even in the consideration of IPv6 deployment. If = as many as applications require new Sustained IP address, it will end up = in a lot of network resource consumption in the mobility routers where = the Sustained IP addresses are anchored as the terminal = moves.

>>2

I am sorry but I = disagree with the email example. I categorize it as an example of an = application that will request a Nomadic address since it does not break = when the mobile node moves to a new LAN and the source IP address is = changed. It simply restarts the socket and continue with the new source = IP address (the user will not even notice this).

 

>> The example was = given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP = address.

 

I did not = understand the other text regarding resource consumption. I thought we = agreed that even of a new Sustained IP address is requested upon each = movement to a new LAN, the effect on IP address allocation is not = significant. Otherwise, my initial comment on applications abusing the = network using your proposed flag, becomes valid = again

>>2

 

>> No, our draft = didn’t say so. Our idea is that a new Sustained IP address is = requested upon receiving *new* flag from an application, as a preference = for a source address selection. You need to read our draft classifying = the categories of IP address request again.

 

Besides, I don’t = understand what is abused. Delivering its preference cannot be abuse. = Regarding “abuse”, I see it in your default behavior = you’re assuming here. In your scenario, a new app initiated in a = new network will be forced to use a newly obtained Sustained IP address. = You see that? You totally block the possibility to be considered by the = default source address selection rules defined in RFC6724. But in our = draft, in case the need of a newly obtained Sustained IP address is = prioritized, the proposed *new* flag can be used by app’s request, = thus it will be selected with priority.

 

Can you = provide a scenario in which an application will not request to refresh = the Sustained IP address?

 

> It was mentioned in the = former comments.

 

 

Regards,

        &= nbsp;       = /Danny

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Any = comments?

 

Regards,

Seil = Jeon

 

 

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

 

Hi,

 

I = could attend DMM Thursday meeting via MeetEcho.

I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

 

 

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

 

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

 

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?

If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?

Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

 

Besides, the propsoed API is = not used alone but with the three type APIs.

 

 

 

Regards,

=

 

Seil = Jeon

 

 

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

------=_NextPart_000_006A_01D06EDC.217D88C0-- From nobody Tue Apr 7 15:35:55 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31AB1B3CD4 for ; Tue, 7 Apr 2015 15:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Cv35XHyKav-U for ; Tue, 7 Apr 2015 15:35:49 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C5A1B3CD1 for ; Tue, 7 Apr 2015 15:35:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t37MZmFd020799; Tue, 7 Apr 2015 17:35:48 -0500 Received: from XCH-BLV-203.nw.nos.boeing.com (xch-blv-203.nw.nos.boeing.com [10.57.37.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t37MZcPH020738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Apr 2015 17:35:38 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.231]) with mapi id 14.03.0210.002; Tue, 7 Apr 2015 15:35:37 -0700 From: "Templin, Fred L" To: "Moses, Danny" , "dmm@ietf.org" Thread-Topic: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Thread-Index: AdBuOH8TeAFQuqtCTx21iPn+L07HKgBWoBSAAHwB+5A= Date: Tue, 7 Apr 2015 22:35:37 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E37422@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832E37422XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:35:53 -0000 --_000_2134F8430051B64F815C691A62D9831832E37422XCHBLV504nwnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danny, Let me know what I can do to help with the mobile router part. Thanks - Fred fred.l.templin@boeing.com From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 05, 2015 4:49 AM To: Templin, Fred L; dmm@ietf.org Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Fred, I think we should explore prefix delegation as well. I am not familiar enou= gh if router requirements for prefix delegation and thus would appreciate y= our help - please describe a use-case and we can evaluate it. I can also think of a use-case for mobile hosts and Sustained IP addresses: In the past, I presented a scenario is which it is preferable to anchor an = IP flow in an anchor that is not necessarily the closest to the mobile node= (please refer to draft-aliahmad-dmm-anchor-selection-01). This situation c= an be detected either by the network or by the mobile node. If we want to enable mobile nodes to select a preferred anchor, we need to = provide means for mobile nodes to express the desired selection. One way is= enable mobile nodes to request a specific anchor by indicating an IP prefi= x that was provided by that anchor in the past. This could be done by 'hint= ing' the preferred IP prefix (rather than a specific IP address). Clearly there is more work to be done on this draft and we are welcoming he= lp from anyone in the group. Can you help us with the router part? Thanks, /Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, April 03, 2015 21:13 To: dmm@ietf.org Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Danny and Alper, In this draft, you seem to be considering only DHCPv6 address delegation fo= r when the node is acting as a mobile host. I am wondering if there are sim= ilar considerations for DHCPv6 prefix delegation for when the node is actin= g as a mobile router. But then, I wonder whether any type of prefix delegation other than a fixed= prefix makes any sense. For example, if the mobile router received a nomad= ic prefix delegation, would it need to renumber its connected networks ever= y time it moves and receives a new nomadic prefix? Should this document discuss prefix delegation considerations for mobile ro= uters, or only address delegation for mobile hosts? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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_2134F8430051B64F815C691A62D9831832E37422XCHBLV504nwnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Danny,

 

Let me know what I can= do to help with the mobile router part.

 

Thanks – Fred

fred.l.templin@boeing.= com

 

From: Moses, Danny [mailto:danny.moses@intel.= com]
Sent: Sunday, April 05, 2015 4:49 AM
To: Templin, Fred L; dmm@ietf.org
Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Fred,

 

I think we should explore prefix delegation as we= ll. I am not familiar enough if router requirements for prefix delegation a= nd thus would appreciate your help - please describe a use-case and we can = evaluate it.

 

I can also think of a use-case for mobile hosts a= nd Sustained IP addresses:

In the past, I presented a scenario is which it i= s preferable to anchor an IP flow in an anchor that is not necessarily the closest to the mobile node (please refer to draf= t-aliahmad-dmm-anchor-selection-01). This situation can be detected either = by the network or by the mobile node.

 

If we want to enable mobile nodes to select a pre= ferred anchor, we need to provide means for mobile nodes to express the des= ired selection. One way is enable mobile nodes to request a specific anchor= by indicating an IP prefix that was provided by that anchor in the past. This could be done by 'hinting' the p= referred IP prefix (rather than a specific IP address).

 

Clearly there is more work to be done on this dra= ft and we are welcoming help from anyone in the group. Can you help us with= the router part?

 

Thanks,

        &= nbsp;       /Danny

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.= org] On Behalf Of Templin, Fred L
Sent: Friday, April 03, 2015 21:13
To: dmm@ietf.org
Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Danny and Alper,

 

In this draft, you seem to be considering only DH= CPv6 address delegation for when the node is acting as a mobile host. I am = wondering if there are similar considerations for DHCPv6 prefix delegation = for when the node is acting as a mobile router.

 

But then, I wonder whether any type of prefix del= egation other than a fixed prefix makes any sense. For example, if the mobi= le router received a nomadic prefix delegation, would it need to renumber i= ts connected networks every time it moves and receives a new nomadic prefix?

 

Should this document discuss prefix delegation co= nsiderations for mobile routers, or only address delegation for mobile host= s?

 

Thanks - Fred

fred.l.templin@boeing.com=

 

_______________________________________________

dmm mailing list

dmm@ietf.org

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

--------------------------------------------------------------------- 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_2134F8430051B64F815C691A62D9831832E37422XCHBLV504nwnosb_-- From nobody Wed Apr 8 02:01:08 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C611A1A38 for ; Wed, 8 Apr 2015 02:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Qbzpxt18WoEd for ; Wed, 8 Apr 2015 02:01:07 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 83B701A1A2C for ; Wed, 8 Apr 2015 02:01:07 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so2860025pab.2 for ; Wed, 08 Apr 2015 02:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=dPHLjB/QP+YevEXjH0HtnskDQBHQJZfVUFEwxuEDYhg=; b=zv9Igf/WSL0/9j+8MRXhWtngoLA68g9Pws6PlmGJfjyEV7WzwVQraPk7+NmtEslrVr KzRZtw5Z5hEbv6UbbuCaWmu2Q/P5GZBO/xDI7MF1nntYvolWZw0gq7BAKNDzDBpzHtJd 9Rsiq4AID6sN57RfJsSlzRIWEDcCYL0NRJ3vLmhVM1FJSkwZwgj/7AR2iG/1vXxaoL+8 ocxlBnl1CaAWf1nZkNe+OYrBRy78ONGx2i8S0maWI0LqrJSIVOlU9J+yTNEIgR3LQumj Qpx0YI2l35cSH3rHejWLah+hpNKepSW5OByUMIYVoSnbGSkXM+9M4dUMAS9/t9miJxP/ LWyA== X-Received: by 10.70.34.196 with SMTP id b4mr44595194pdj.157.1428483666355; Wed, 08 Apr 2015 02:01:06 -0700 (PDT) Received: from [10.62.54.158] ([202.55.20.10]) by mx.google.com with ESMTPSA id qh9sm10321088pbc.24.2015.04.08.02.01.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Apr 2015 02:01:04 -0700 (PDT) Date: Wed, 8 Apr 2015 17:00:58 +0800 From: Dapeng Liu To: Jouni Korhonen Message-ID: In-Reply-To: <551C0877.1060100@gmail.com> References: <551C0877.1060100@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5524ee4a_3d1b58ba_e7" Archived-At: Cc: draft-perkins-dmm-4283mnids@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 09:01:08 -0000 --5524ee4a_3d1b58ba_e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (As an individual contributor.) I support the adoption of this draft. =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=881=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=8811:02=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF= =BC=9A > =46olks, > =20 > This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 > to confirm the aadoption s a DMM WG document. The call ends April 15th = =20 > EOB PST. > =20 > Express your support or opposition to the mailing list. During the =20 > IET=4692 meeting we got 7 voices for the adoption so at least the same = =20 > amount supporting emails should be expected. > =20 > - Jouni & Dapeng =20 --5524ee4a_3d1b58ba_e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
(As an individual contributor.)  I support the a= doption of this draft.

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=881=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=88= 11:02=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This emails starts a two week call for the I-D
draft-perki= ns-dmm-4283mnids-01
to confirm the aadoption s a DMM WG documen= t. The call ends April 15th
EOB PST.

= Express your support or opposition to the mailing list. During the
=
IET=4692 meeting we got 7 voices for the adoption so at least the sa= me
amount supporting emails should be expected.

=
- Jouni & Dapeng
=20 =20 =20 =20 =20

--5524ee4a_3d1b58ba_e7-- From nobody Thu Apr 9 14:24:31 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B705D1B335A for ; Thu, 9 Apr 2015 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yiFYaxlO6sYb for ; Thu, 9 Apr 2015 14:24:29 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3893A1B3359 for ; Thu, 9 Apr 2015 14:24:29 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 5349B1215B7; Thu, 9 Apr 2015 17:42:28 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id AB2F4FB559; Thu, 9 Apr 2015 17:24:28 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 9 Apr 2015 17:24:28 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: "dmm@ietf.org" , "jouni.nospam@gmail.com" , "maxpassion@gmail.com" , "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" Date: Thu, 9 Apr 2015 17:24:27 -0400 Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AdBzC49aXjudigvpT12qjvRS2T8nbA== Message-ID: <6C4EC8CC-F1D0-4864-8238-217F845C35C9@research.att.com> References: <551F2A6D.6080100@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:24:30 -0000 I support the adoption of this I-D. Byoung-Jo "J" Kim macsbug@research.att.com AT&T Labs - Research http://sites.google.com/site/macsbug/ >> From: Jouni Korhonen >> Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 >> Date: April 4, 2015 3:03:57 AM GMT+03:00 >> To: "dmm@ietf.org" , Jouni , Dapen= g Liu , draft-yegin-dmm-ondemand-mobility@tools.ietf.= org >>=20 >> Folks, >>=20 >> This email starts a two week adoption call for the I-D >> draft-yegin-dmm-ondemand-mobility-03 >> to confirm its adoption as a DMM WG document and as a basis for the tech= nical solution. The call ends April 17th EOB PDT. >>=20 >> Express your support or opposition to the mailing list. During the IETF9= 2 meeting we got 10 voices for the adoption and 3 against. we expect at lea= st the same amount of expressed opinions on the list. >>=20 >> Notice that version -01 of this I-D had an IPR declared to it. See https= ://datatracker.ietf.org/ipr/2309/ >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Apr 9 15:34:46 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7A1B34A8 for ; Thu, 9 Apr 2015 15:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8Mauvhdb-k_u for ; Thu, 9 Apr 2015 15:34:41 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id D458E1B34A5 for ; Thu, 9 Apr 2015 15:34:40 -0700 (PDT) Received: from [82.155.120.93] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77471751; Thu, 09 Apr 2015 23:34:38 +0100 From: "Seil Jeon" To: "'Jouni Korhonen'" , , "'Dapeng Liu'" , References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Date: Thu, 9 Apr 2015 23:34:39 +0100 Message-ID: <004301d07315$5e1d2460$1a576d20$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIT+GPyPzw842pNESLWuuDW7AG57Jy+NtvA Content-Language: ko Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:34:43 -0000 Hi DMMers, I support the adoption of this draft as a WG document in the sense that the three types of IP addresses are needed. But the use of the defined APIs is not clear in the context of the existing source address selection rules defined in RFC 6724, as I had discussed it with Danny several times. Definitely, it should be reviewed through use cases study. Best Regards, Seil Jeon -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Saturday, April 04, 2015 1:04 AM To: dmm@ietf.org; Jouni; Dapeng Liu; draft-yegin-dmm-ondemand-mobility@tools.ietf.org Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Folks, This email starts a two week adoption call for the I-D draft-yegin-dmm-ondemand-mobility-03 to confirm its adoption as a DMM WG document and as a basis for the technical solution. The call ends April 17th EOB PDT. Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption and 3 against. we expect at least the same amount of expressed opinions on the list. Notice that version -01 of this I-D had an IPR declared to it. See https://datatracker.ietf.org/ipr/2309/ - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Apr 9 16:00:12 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7E1B3548 for ; Thu, 9 Apr 2015 15:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QYdkuKyfRINK for ; Thu, 9 Apr 2015 15:59:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6701A9054 for ; Thu, 9 Apr 2015 15:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2110; q=dns/txt; s=iport; t=1428620392; x=1429829992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lhonNj7w+GN+B6MucncNjnIgYrazjW4SZP+nIxZan64=; b=kS0XVN3QrjxzWA2AVgZqJCRayRX4lFZBR/wWX88P0k3YU8W7lmre7K85 cviwnL8Wy+i9Hzdc5QfTGUgAqAdvzfI3dHd7VMsQyVYYPzGmZ4fPgWjow Am9Uwc6cIDkvTmqVgd5FS3LP6tdO5KaqGuEGP1aSDGpIYmYrt46HZ+kbB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhCQANBCdV/4MNJK1cgwhSXMNogjgKhgECgURMAQEBAQEBfoQfAQEBAwEBAQEaHTQLBQcEAgEIEQQBAQEeCQcnCxQJCAIEDgUbiAcIDc5aAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4QZEQEeMwcGgxGBFgWRAYN4hBKCAYEdEY9pg0sig29vgQuBOAEBAQ X-IronPort-AV: E=Sophos;i="5.11,553,1422921600"; d="scan'208";a="410694678" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 09 Apr 2015 22:59:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t39MxoFc024998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 22:59:50 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.108]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 17:59:50 -0500 From: "Sri Gundavelli (sgundave)" To: Seil Jeon Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AQHQbmrgX8LskzxBH06OCmWukAVNxZ1FobaA//+zNxE= Date: Thu, 9 Apr 2015 22:59:49 +0000 Message-ID: <7BD6F922-ED83-44B2-B4FA-8CFE94C7DA33@cisco.com> References: <551F2A6D.6080100@gmail.com>, <004301d07315$5e1d2460$1a576d20$@av.it.pt> In-Reply-To: <004301d07315$5e1d2460$1a576d20$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:59:57 -0000 I support the adoption of this draft as a starting point of a WG document.= =20 I also agree with Seil's comment that the WG document has to resolve the cu= rrently identified open issues; Specially there has to be clear explanation= on how SAS Rules fit in here, or how the address properties defined here i= nterwork with the RFC 6274 Rules. I tag this as a open issue. Sri > On Apr 10, 2015, at 4:04 AM, "Seil Jeon" wrote: >=20 > Hi DMMers, >=20 > I support the adoption of this draft as a WG document in the sense that t= he > three types of IP addresses are needed. > But the use of the defined APIs is not clear in the context of the existi= ng > source address selection rules defined in RFC 6724, as I had discussed it > with Danny several times. Definitely, it should be reviewed through use > cases study. >=20 > Best Regards, > Seil Jeon >=20 >=20 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Saturday, April 04, 2015 1:04 AM > To: dmm@ietf.org; Jouni; Dapeng Liu; > draft-yegin-dmm-ondemand-mobility@tools.ietf.org > Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 >=20 > Folks, >=20 > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the > technical solution. The call ends April 17th EOB PDT. >=20 > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption and 3 against. we expect= at > least the same amount of expressed opinions on the list. >=20 > Notice that version -01 of this I-D had an IPR declared to it. See > https://datatracker.ietf.org/ipr/2309/ >=20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Apr 9 17:45:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695031B3815 for ; Thu, 9 Apr 2015 17:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 luojVHcNI2RK for ; Thu, 9 Apr 2015 17:45:55 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (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 DCE841B3814 for ; Thu, 9 Apr 2015 17:45:55 -0700 (PDT) Received: by pddn5 with SMTP id n5so4706877pdd.2 for ; Thu, 09 Apr 2015 17:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hxLed3iop03DAzSyriDitbJ+3Rrbvomzuoo6oW1ZnAA=; b=Gn+lsuNfVIfGKZ38KF3uCvv8SRBaTM2wgDxynll2uRzmX8ew4gHE1LT5oMOKWDtkZI 7JyyxhR09ekyOK+707MWOpNBWycVaSFYo0SYtBkPagtb/Qruh1HNx/DDKQS5R2vI7hkr rMEDYAegEJqw0nbZxxX1yVdYoeHcDWoGoFeqLjI+ikjry1PUDeE822dA9FDhEP5NbH78 frC6Hs9K9BAMmsiezpP1qJ0MPihP+S7qmRHZrU79bwH1Sc3mBIVSPcqnZtBnJjG9mt3K jqu9csiZOt5JXn3GaiH/7KS1iznlJKPPFTfv4hsCoKjBk5JFy+HB4xww0ia2/dJ+m2OQ /Osw== X-Received: by 10.70.127.138 with SMTP id ng10mr60428013pdb.111.1428626755516; Thu, 09 Apr 2015 17:45:55 -0700 (PDT) Received: from [10.16.10.30] ([216.31.219.19]) by mx.google.com with ESMTPSA id ms7sm245203pdb.8.2015.04.09.17.45.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 17:45:54 -0700 (PDT) Message-ID: <55271D40.2030800@gmail.com> Date: Thu, 09 Apr 2015 17:45:52 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-yegin-dmm-ondemand-mobility@tools.ietf.org References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 00:45:57 -0000 I support the adoption of this I-D.. as a basis for further work done by the WG. We obviously need to address the valid concerns raised on the list by few people. Also, we need to evaluate what parts are covered by the declared IPR and whether the WG agrees to keep those in the solution (the licencing terms are OK, though). - Jouni 4/3/2015, 5:03 PM, Jouni Korhonen kirjoitti: > Folks, > > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the > technical solution. The call ends April 17th EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption and 3 against. we > expect at least the same amount of expressed opinions on the list. > > Notice that version -01 of this I-D had an IPR declared to it. See > https://datatracker.ietf.org/ipr/2309/ > > - Jouni & Dapeng From nobody Thu Apr 9 17:49:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E01A1B28 for ; Thu, 9 Apr 2015 17:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eeuyhjWje9ob for ; Thu, 9 Apr 2015 17:49:28 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C11A1A33 for ; Thu, 9 Apr 2015 17:49:27 -0700 (PDT) Received: from JoyYan (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoHwIHidVRK8sAA--.18125S2; Fri, 10 Apr 2015 08:49:12 +0800 (CST) Date: Fri, 10 Apr 2015 08:49:11 +0800 From: "Z.W. Yan" To: "Sri Gundavelli (sgundave)" , "Seil Jeon" References: <551F2A6D.6080100@gmail.com>, <004301d07315$5e1d2460$1a576d20$@av.it.pt>, <7BD6F922-ED83-44B2-B4FA-8CFE94C7DA33@cisco.com> Message-ID: <201504100849109808934@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon023600206013_=====" X-CM-TRANSID: AQAAf0CZoHwIHidVRK8sAA--.18125S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw4kCr18GFy3Kw47JrWxXrb_yoW5JFy7pa yDKrs5Gr1DAFn3Jw4xGw15Xr1jvFZ8XrZrJr98tryUAFy5J3W0yr1Yy3WFva4DCr1rJF4D Zr17Cr45Cws3CrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Fb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xv F2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcS sGvfC2KfnxnUUI43ZEXa7IU8tfH5UUUUU== X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Cc: "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 00:49:31 -0000 This is a multi-part message in MIME format. --=====003_Dragon023600206013_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQuIA0K DQpaaGl3ZWkgWWFuDQoyMDE1LTA0LTEwIA0KDQoNCg0KDQq3orz+yMujuiBTcmkgR3VuZGF2ZWxs aSAoc2d1bmRhdmUpIA0Kt6LLzcqxvOSjuiAyMDE1LTA0LTEwICAwNzowMDoxNyANCsrVvP7Iy6O6 IFNlaWwgSmVvbiANCrOty82juiBkcmFmdC15ZWdpbi1kbW0tb25kZW1hbmQtbW9iaWxpdHlAdG9v bHMuaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZyANCtb3zOKjuiBSZTogW0RNTV0gQ2FsbCBmb3IgYWRv cHRpb246IGRyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS0wMyANCiANCkkgc3VwcG9y dCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhIHN0YXJ0aW5nIHBvaW50IG9mIGEgV0cg ZG9jdW1lbnQuIA0KSSBhbHNvIGFncmVlIHdpdGggU2VpbCdzIGNvbW1lbnQgdGhhdCB0aGUgV0cg ZG9jdW1lbnQgaGFzIHRvIHJlc29sdmUgdGhlIGN1cnJlbnRseSBpZGVudGlmaWVkIG9wZW4gaXNz dWVzOyBTcGVjaWFsbHkgdGhlcmUgaGFzIHRvIGJlIGNsZWFyIGV4cGxhbmF0aW9uIG9uIGhvdyBT QVMgUnVsZXMgZml0IGluIGhlcmUsIG9yIGhvdyB0aGUgYWRkcmVzcyBwcm9wZXJ0aWVzIGRlZmlu ZWQgaGVyZSBpbnRlcndvcmsgd2l0aCB0aGUgUkZDIDYyNzQgUnVsZXMuIEkgdGFnIHRoaXMgYXMg YSBvcGVuIGlzc3VlLg0KU3JpDQo+IE9uIEFwciAxMCwgMjAxNSwgYXQgNDowNCBBTSwgIlNlaWwg SmVvbiIgPHNlaWxqZW9uQGF2Lml0LnB0PiB3cm90ZToNCj4gDQo+IEhpIERNTWVycywNCj4gDQo+ IEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhIFdHIGRvY3VtZW50IGlu IHRoZSBzZW5zZSB0aGF0IHRoZQ0KPiB0aHJlZSB0eXBlcyBvZiBJUCBhZGRyZXNzZXMgYXJlIG5l ZWRlZC4NCj4gQnV0IHRoZSB1c2Ugb2YgdGhlIGRlZmluZWQgQVBJcyBpcyBub3QgY2xlYXIgaW4g dGhlIGNvbnRleHQgb2YgdGhlIGV4aXN0aW5nDQo+IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBy dWxlcyBkZWZpbmVkIGluIFJGQyA2NzI0LCBhcyBJIGhhZCBkaXNjdXNzZWQgaXQNCj4gd2l0aCBE YW5ueSBzZXZlcmFsIHRpbWVzLiBEZWZpbml0ZWx5LCBpdCBzaG91bGQgYmUgcmV2aWV3ZWQgdGhy b3VnaCB1c2UNCj4gY2FzZXMgc3R1ZHkuDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IFNlaWwgSmVv bg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRtbSBbbWFp bHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm91bmkgS29yaG9uZW4NCj4g U2VudDogU2F0dXJkYXksIEFwcmlsIDA0LCAyMDE1IDE6MDQgQU0NCj4gVG86IGRtbUBpZXRmLm9y ZzsgSm91bmk7IERhcGVuZyBMaXU7DQo+IGRyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0 eUB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbRE1NXSBDYWxsIGZvciBhZG9wdGlvbjogZHJh ZnQteWVnaW4tZG1tLW9uZGVtYW5kLW1vYmlsaXR5LTAzDQo+IA0KPiBGb2xrcywNCj4gDQo+IFRo aXMgZW1haWwgc3RhcnRzIGEgdHdvIHdlZWsgYWRvcHRpb24gY2FsbCBmb3IgdGhlIEktRA0KPiAg IGRyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS0wMw0KPiB0byBjb25maXJtIGl0cyBh ZG9wdGlvbiBhcyBhIERNTSBXRyBkb2N1bWVudCBhbmQgYXMgYSBiYXNpcyBmb3IgdGhlDQo+IHRl Y2huaWNhbCBzb2x1dGlvbi4gVGhlIGNhbGwgZW5kcyBBcHJpbCAxN3RoIEVPQiBQRFQuDQo+IA0K PiBFeHByZXNzIHlvdXIgc3VwcG9ydCBvciBvcHBvc2l0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3Qu IER1cmluZyB0aGUNCj4gSUVURjkyIG1lZXRpbmcgd2UgZ290IDEwIHZvaWNlcyBmb3IgdGhlIGFk b3B0aW9uIGFuZCAzIGFnYWluc3QuIHdlIGV4cGVjdCBhdA0KPiBsZWFzdCB0aGUgc2FtZSBhbW91 bnQgb2YgZXhwcmVzc2VkIG9waW5pb25zIG9uIHRoZSBsaXN0Lg0KPiANCj4gTm90aWNlIHRoYXQg dmVyc2lvbiAtMDEgb2YgdGhpcyBJLUQgaGFkIGFuIElQUiBkZWNsYXJlZCB0byBpdC4gU2VlDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIzMDkvDQo+IA0KPiAtIEpvdW5pICYg RGFwZW5nDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBkbW0gbWFpbGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1tIG1haWxpbmcgbGlzdA0KPiBkbW1AaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBs aXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQo= --=====003_Dragon023600206013_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNzI2NyI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IMvOzOU7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsN Cn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24x IHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAx MC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlm eTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0N CkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0la RTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1 c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0K fQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBs ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglG T05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUt dHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9u MQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0KfQ0KT0wg ew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFSR0lOOiAx MHB4Ij4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+SSZu YnNwO3N1cHBvcnQmbmJzcDt0aGUmbmJzcDthZG9wdGlvbiZuYnNwO29mJm5ic3A7dGhpcyZuYnNw O2RyYWZ0Jm5ic3A7YXMmbmJzcDthJm5ic3A7V0cmbmJzcDtkb2N1bWVudC4gDQo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFu YT5aaGl3ZWkgWWFuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9 MiBmYWNlPVZlcmRhbmE+MjAxNS0wNC0xMCA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KDQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZl cmRhbmE+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUp IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+ t6LLzcqxvOSjujwvU1RST05HPiAyMDE1LTA0LTEwJm5ic3A7IDA3OjAwOjE3IA0KPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+ytW8/sjLo7o8L1NU Uk9ORz4gU2VpbCBKZW9uIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48U1RST05HPrOty82jujwvU1RST05HPiANCmRyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1t b2JpbGl0eUB0b29scy5pZXRmLm9yZzsgZG1tQGlldGYub3JnIDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPtb3zOKjujwvU1RST05HPiBSZTogW0RN TV0gQ2FsbCBmb3IgYWRvcHRpb246IA0KZHJhZnQteWVnaW4tZG1tLW9uZGVtYW5kLW1vYmlsaXR5 LTAzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+ IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5JJm5ic3A7c3Vw cG9ydCZuYnNwO3RoZSZuYnNwO2Fkb3B0aW9uJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7ZHJhZnQm bmJzcDthcyZuYnNwO2EmbmJzcDtzdGFydGluZyZuYnNwO3BvaW50Jm5ic3A7b2YmbmJzcDthJm5i c3A7V0cmbmJzcDtkb2N1bWVudC4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkkmbmJz cDthbHNvJm5ic3A7YWdyZWUmbmJzcDt3aXRoJm5ic3A7U2VpbCdzJm5ic3A7Y29tbWVudCZuYnNw O3RoYXQmbmJzcDt0aGUmbmJzcDtXRyZuYnNwO2RvY3VtZW50Jm5ic3A7aGFzJm5ic3A7dG8mbmJz cDtyZXNvbHZlJm5ic3A7dGhlJm5ic3A7Y3VycmVudGx5Jm5ic3A7aWRlbnRpZmllZCZuYnNwO29w ZW4mbmJzcDtpc3N1ZXM7Jm5ic3A7U3BlY2lhbGx5Jm5ic3A7dGhlcmUmbmJzcDtoYXMmbmJzcDt0 byZuYnNwO2JlJm5ic3A7Y2xlYXImbmJzcDtleHBsYW5hdGlvbiZuYnNwO29uJm5ic3A7aG93Jm5i c3A7U0FTJm5ic3A7UnVsZXMmbmJzcDtmaXQmbmJzcDtpbiZuYnNwO2hlcmUsJm5ic3A7b3ImbmJz cDtob3cmbmJzcDt0aGUmbmJzcDthZGRyZXNzJm5ic3A7cHJvcGVydGllcyZuYnNwO2RlZmluZWQm bmJzcDtoZXJlJm5ic3A7aW50ZXJ3b3JrJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO1JGQyZuYnNw OzYyNzQmbmJzcDtSdWxlcy4mbmJzcDtJJm5ic3A7dGFnJm5ic3A7dGhpcyZuYnNwO2FzJm5ic3A7 YSZuYnNwO29wZW4mbmJzcDtpc3N1ZS48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlNyaTwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDtPbiZuYnNwO0FwciZu YnNwOzEwLCZuYnNwOzIwMTUsJm5ic3A7YXQmbmJzcDs0OjA0Jm5ic3A7QU0sJm5ic3A7IlNlaWwm bmJzcDtKZW9uIiZuYnNwOyZsdDtzZWlsamVvbkBhdi5pdC5wdCZndDsmbmJzcDt3cm90ZTo8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SGkmbmJzcDtETU1lcnMs PC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0kmbmJzcDtzdXBw b3J0Jm5ic3A7dGhlJm5ic3A7YWRvcHRpb24mbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtkcmFmdCZu YnNwO2FzJm5ic3A7YSZuYnNwO1dHJm5ic3A7ZG9jdW1lbnQmbmJzcDtpbiZuYnNwO3RoZSZuYnNw O3NlbnNlJm5ic3A7dGhhdCZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhyZWUmbmJz cDt0eXBlcyZuYnNwO29mJm5ic3A7SVAmbmJzcDthZGRyZXNzZXMmbmJzcDthcmUmbmJzcDtuZWVk ZWQuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtCdXQmbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2RlZmluZWQmbmJzcDtBUElzJm5ic3A7aXMmbmJzcDtub3QmbmJzcDtjbGVh ciZuYnNwO2luJm5ic3A7dGhlJm5ic3A7Y29udGV4dCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7ZXhp c3Rpbmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3NvdXJjZSZuYnNwO2FkZHJlc3MmbmJzcDtzZWxl Y3Rpb24mbmJzcDtydWxlcyZuYnNwO2RlZmluZWQmbmJzcDtpbiZuYnNwO1JGQyZuYnNwOzY3MjQs Jm5ic3A7YXMmbmJzcDtJJm5ic3A7aGFkJm5ic3A7ZGlzY3Vzc2VkJm5ic3A7aXQ8L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO3dpdGgmbmJzcDtEYW5ueSZuYnNwO3NldmVyYWwmbmJzcDt0aW1lcy4mbmJz cDtEZWZpbml0ZWx5LCZuYnNwO2l0Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtyZXZpZXdlZCZu YnNwO3Rocm91Z2gmbmJzcDt1c2U8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2Nhc2VzJm5ic3A7c3R1 ZHkuPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0Jlc3QmbmJz cDtSZWdhcmRzLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U2VpbCZuYnNwO0plb248L0RJVj4NCjxE SVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJz cDstLS0tLU9yaWdpbmFsJm5ic3A7TWVzc2FnZS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDtG cm9tOiZuYnNwO2RtbSZuYnNwO1ttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddJm5ic3A7T24m bmJzcDtCZWhhbGYmbmJzcDtPZiZuYnNwO0pvdW5pJm5ic3A7S29yaG9uZW48L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO1NlbnQ6Jm5ic3A7U2F0dXJkYXksJm5ic3A7QXByaWwmbmJzcDswNCwmbmJzcDsy MDE1Jm5ic3A7MTowNCZuYnNwO0FNPC9ESVY+DQo8RElWPiZndDsmbmJzcDtUbzombmJzcDtkbW1A aWV0Zi5vcmc7Jm5ic3A7Sm91bmk7Jm5ic3A7RGFwZW5nJm5ic3A7TGl1OzwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7ZHJhZnQteWVnaW4tZG1tLW9uZGVtYW5kLW1vYmlsaXR5QHRvb2xzLmlldGYub3Jn PC9ESVY+DQo8RElWPiZndDsmbmJzcDtTdWJqZWN0OiZuYnNwO1tETU1dJm5ic3A7Q2FsbCZuYnNw O2ZvciZuYnNwO2Fkb3B0aW9uOiZuYnNwO2RyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0 eS0wMzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtGb2xrcyw8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7VGhpcyZuYnNwO2Vt YWlsJm5ic3A7c3RhcnRzJm5ic3A7YSZuYnNwO3R3byZuYnNwO3dlZWsmbmJzcDthZG9wdGlvbiZu YnNwO2NhbGwmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtJLUQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwO2RyYWZ0LXllZ2luLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS0wMzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7dG8mbmJzcDtjb25maXJtJm5ic3A7aXRzJm5ic3A7YWRvcHRpb24mbmJz cDthcyZuYnNwO2EmbmJzcDtETU0mbmJzcDtXRyZuYnNwO2RvY3VtZW50Jm5ic3A7YW5kJm5ic3A7 YXMmbmJzcDthJm5ic3A7YmFzaXMmbmJzcDtmb3ImbmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZu YnNwO3RlY2huaWNhbCZuYnNwO3NvbHV0aW9uLiZuYnNwO1RoZSZuYnNwO2NhbGwmbmJzcDtlbmRz Jm5ic3A7QXByaWwmbmJzcDsxN3RoJm5ic3A7RU9CJm5ic3A7UERULjwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtFeHByZXNzJm5ic3A7eW91ciZuYnNwO3N1cHBv cnQmbmJzcDtvciZuYnNwO29wcG9zaXRpb24mbmJzcDt0byZuYnNwO3RoZSZuYnNwO21haWxpbmcm bmJzcDtsaXN0LiZuYnNwO0R1cmluZyZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SUVU RjkyJm5ic3A7bWVldGluZyZuYnNwO3dlJm5ic3A7Z290Jm5ic3A7MTAmbmJzcDt2b2ljZXMmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDthZG9wdGlvbiZuYnNwO2FuZCZuYnNwOzMmbmJzcDthZ2FpbnN0 LiZuYnNwO3dlJm5ic3A7ZXhwZWN0Jm5ic3A7YXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2xlYXN0 Jm5ic3A7dGhlJm5ic3A7c2FtZSZuYnNwO2Ftb3VudCZuYnNwO29mJm5ic3A7ZXhwcmVzc2VkJm5i c3A7b3BpbmlvbnMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2xpc3QuPC9ESVY+DQo8RElWPiZndDsm bmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO05vdGljZSZuYnNwO3RoYXQmbmJzcDt2ZXJzaW9u Jm5ic3A7LTAxJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7SS1EJm5ic3A7aGFkJm5ic3A7YW4mbmJz cDtJUFImbmJzcDtkZWNsYXJlZCZuYnNwO3RvJm5ic3A7aXQuJm5ic3A7U2VlPC9ESVY+DQo8RElW PiZndDsmbmJzcDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMzA5LzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDstJm5ic3A7Sm91bmkmbmJzcDsm YW1wOyZuYnNwO0RhcGVuZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsm bmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7ZG1tJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO2RtbUBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RtbSZuYnNwO21haWxpbmcmbmJzcDtsaXN0 PC9ESVY+DQo8RElWPiZndDsmbmJzcDtkbW1AaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNw O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzwvRElWPg0KPERJVj5kbW0mbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kbW1A aWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbW08L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon023600206013_=====-- From nobody Fri Apr 10 06:43:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB641B35CD for ; Fri, 10 Apr 2015 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oZM3gq8nqyZz for ; Fri, 10 Apr 2015 06:43:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8EA1B35CA for ; Fri, 10 Apr 2015 06:43:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUR98751; Fri, 10 Apr 2015 13:43:07 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 14:43:07 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 06:43:05 -0700 From: John Kaippallimalil To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu , "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AQHQbmrl5rg6HvaQr0KzdcpN/7jjF51F5+YAgABg3yA= Date: Fri, 10 Apr 2015 13:43:03 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA907C2@dfweml703-chm> References: <551F2A6D.6080100@gmail.com> <55271D40.2030800@gmail.com> In-Reply-To: <55271D40.2030800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 13:43:12 -0000 I support the adoption of this draft. We need more work to see how these addresses are selected and handled over = their lifetimes, as well as how this relates to mechanisms between the host= network stack and router. John > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Thursday, April 09, 2015 7:46 PM > To: dmm@ietf.org; Dapeng Liu; draft-yegin-dmm-ondemand- > mobility@tools.ietf.org > Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand- > mobility-03 >=20 > >=20 > I support the adoption of this I-D.. as a basis for further work done > by the WG. We obviously need to address the valid concerns raised on > the list by few people. Also, we need to evaluate what parts are > covered by the declared IPR and whether the WG agrees to keep those in > the solution (the licencing terms are OK, though). >=20 > - Jouni >=20 >=20 >=20 > 4/3/2015, 5:03 PM, Jouni Korhonen kirjoitti: > > Folks, > > > > This email starts a two week adoption call for the I-D > > draft-yegin-dmm-ondemand-mobility-03 > > to confirm its adoption as a DMM WG document and as a basis for the > > technical solution. The call ends April 17th EOB PDT. > > > > Express your support or opposition to the mailing list. During the > > IETF92 meeting we got 10 voices for the adoption and 3 against. we > > expect at least the same amount of expressed opinions on the list. > > > > Notice that version -01 of this I-D had an IPR declared to it. See > > https://datatracker.ietf.org/ipr/2309/ > > > > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Apr 10 07:33:57 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BA31A0177 for ; Fri, 10 Apr 2015 07:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fn4twQntuLE8 for ; Fri, 10 Apr 2015 07:33:53 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8E1A0204 for ; Fri, 10 Apr 2015 07:33:47 -0700 (PDT) Received: from [89.115.53.43] (account sfigueiredo@av.it.pt HELO [127.0.0.1]) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77476175; Fri, 10 Apr 2015 15:33:46 +0100 Message-ID: <5527DF48.10208@av.it.pt> Date: Fri, 10 Apr 2015 15:33:44 +0100 From: =?windows-1252?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmm@ietf.org, jouni.nospam@gmail.com, maxpassion@gmail.com, draft-yegin-dmm-ondemand-mobility@tools.ietf.org References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150410-0, 10/04/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 14:33:55 -0000 Hi all, I support the adoption of this I-D as a WG document, given it provides a good technical starting point for the expected relationship between an application and the IP stack in DMM environments. In my opinion, next steps should include the clarification of MN's default behavior, namely what IP addresses (types) should be configured at boot and after handover, and what exactly is left for the MN / Application decision and action (by usage of the defined API). Best regards, -- S閞gio Figueiredo On 04-04-2015 01:03, Jouni Korhonen wrote: > Folks, > > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the > technical solution. The call ends April 17th EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption and 3 against. we > expect at least the same amount of expressed opinions on the list. > > Notice that version -01 of this I-D had an IPR declared to it. See > https://datatracker.ietf.org/ipr/2309/ > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com From nobody Fri Apr 10 09:19:27 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF30B1A89FF for ; Fri, 10 Apr 2015 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 97uxymrSRsaI for ; Fri, 10 Apr 2015 09:19:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8961A8724 for ; Fri, 10 Apr 2015 09:19:24 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id AD13A264067; Fri, 10 Apr 2015 18:19:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 818CC4C09D; Fri, 10 Apr 2015 18:19:22 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 10 Apr 2015 18:19:21 +0200 From: To: "dmm@ietf.org" , "jouni.nospam@gmail.com" , "maxpassion@gmail.com" , "draft-yegin-dmm-ondemand-mobility@tools.ietf.org" Thread-Topic: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 Thread-Index: AQHQbmreaOlhIER/AUS1f//RA0tasJ1GOFQAgAA+qZA= Date: Fri, 10 Apr 2015 16:19:20 +0000 Message-ID: <11496_1428682762_5527F80A_11496_29_2_81C77F07008CA24F9783A98CFD706F7114D0D496@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <551F2A6D.6080100@gmail.com> <5527DF48.10208@av.it.pt> In-Reply-To: <5527DF48.10208@av.it.pt> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:19:26 -0000 Hi, I support adoption of this I-D, it is a good starting point. Pierrick On 04-04-2015 01:03, Jouni Korhonen wrote: > Folks, > > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the=20 > technical solution. The call ends April 17th EOB PDT. > > Express your support or opposition to the mailing list. During the=20 > IETF92 meeting we got 10 voices for the adoption and 3 against. we=20 > expect at least the same amount of expressed opinions on the list. > > Notice that version -01 of this I-D had an IPR declared to it. See=20 > https://datatracker.ietf.org/ipr/2309/ > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com _______________________________________________ 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 Sun Apr 12 05:49:11 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF51A874C for ; Sun, 12 Apr 2015 05:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 n1O6UXaIsAPH for ; Sun, 12 Apr 2015 05:48:58 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6F1A8743 for ; Sun, 12 Apr 2015 05:48:58 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 12 Apr 2015 05:48:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,565,1422950400"; d="scan'208,217";a="707671639" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga002.fm.intel.com with ESMTP; 12 Apr 2015 05:48:55 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 12 Apr 2015 13:48:54 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by LCSMSX154.ger.corp.intel.com ([169.254.7.139]) with mapi id 14.03.0224.002; Sun, 12 Apr 2015 15:48:53 +0300 From: "Moses, Danny" To: Seil Jeon Thread-Topic: [DMM] Answer on raised questions for the proposed API Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgIJAtYDAlqa+uYCqJZpkgDQIjNOAPZdtnGbTMJ10JuEMu4wyPeW/QD/9OoEcA== Date: Sun, 12 Apr 2015 12:48:52 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> In-Reply-To: <000001d06fa9$f6675e30$e3361a90$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490D90EHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 12:49:09 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490D90EHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable You have a good point here. Now I understand the need for the flag you are proposing !!! We need to take a better look at RFC 6724 and figure out if we need to upda= te it. I am thinking of two places that might require an update: 1. When an application chooses not to specify a source address (but r= equest a specific type) 2. When an application wishes to choose the source address from a pro= vided list. When the application indicates the desired address type, but chooses not to= specify the source address (from a list provided by the IP stack), the sta= ck should allocate a source IP address according to the address-type reques= ted by the application. In this case, we should consider adding text to des= cribe the behavior for Sustained IP addresses. Specifically, if there are s= everal Sustained IP addresses allocated to the mobile host, whether to choo= se one of them, or to have the mobile host request a new one from the netwo= rk (as a result of a mobility event - for example). When an application wishes to chooses the source address from the available= list (obtained by getaddrinfo()), there are some alternative approaches we= should consider: 1. Enhance getaddrinfo() enabling the application to specify the requ= ired address type, and return the list of source addresses that are of that= type (Nomadic, Sustained, Fixed or DontCare), or - 2. Provide the list of addresses with an indication of their type (No= madic, Sustained, Fixed or TypeUnknown) and an indication of whether each a= ddress is New (allocated after the last handoff event) or Old (allocated be= fore the last handoff event) 3. Some other approach... The flag is need here, to enable the application to request a new IP addres= s (if the returned list only contain 'Old' addresses) !!! I agree that we should discuss this. How about bringing it to the next 'Mob= ility Exposure and Selection WT' call? Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, Meeting is always good, even with you by f-to-f. But in the discussion, the= main issue is whether we will allow the default source address selection r= ules defined in RFC6724 for selecting a Sustained IP address among several = ones or fundamentally block them for a specific reason raised by a DMM need= . The latter approach is not reasonable no matter how I try to think of.it. If an application has the specific preference of a newly obtained Sustained= IP address, it uses the proposed API. Regards. Seil From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 05, 2015 12:23 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, By now we have been discussing this for quite some time and clearly we did = not succeed in convincing each other. I suggest we try again when we have a chance to meet face to face. Meanwhil= e, let's listen to what other people have to say on this matter. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 01:16 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Resent. Seil From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. I marked current replies with ">>" and previous repl= ies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request= a sustained IP address more than once after each movement to a new LAN (wi= th a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request= a Nomadic IP address and a Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any appl= ications requesting any addresses. This way, whenever an application is lau= nched and requests either a Nomadic or Sustained IP address, the stack can = provide one without having to issue a request to the network. In this case,= there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one of t= hem. What if only the Nomadic IP address is basically allocated upon a netw= ork attachment? That is, a lot of applications require mere Internet connec= tivity without session continuity support. So, the Sustained IP address wil= l be requested on demand, and the proposed flag will be used to get a new S= ustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of= one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this = example, the IP stack in the host pre-allocates both Nomadic and Sustained = IP addresses upon attachment... >> As I said, it could be, but not as general one. The proposed API is usef= ul through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-al= located upon NW connection (and after every movement to a new LAN) and a Su= stained (and/or Fixed) address is allocated on-demand. Even in such a scena= rio, I do not see any use for this flag - see my reply to the second item b= elow... >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to requ= est IP addresses in advance. In that case, it will issue a request for a No= madic IP address or a Sustained IP address the first time an application re= quests one and use it for subsequent requests as long as it is not moving t= o a different LAN. Once it moves, it will again request a new IP address (N= omadic or Sustained - according to what is required) after receiving the fi= rst request from any application. In this case as well, there is no need fo= r this flag. > Another application requested just Sustained IP address while the IP stac= k has already a Sustained IP address. Why should the IP stack try to get a = new one, though the application indicated simply "Sustained IP address type= "? You case took a step towards a solution where you want to draw. I don't = expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile = host would get an IP address whatever the allocated IP address type is when= it attaches at a network, regardless of an application's IP address reques= t. >>2 Looks like I did not express myself well enough (and did not fully understa= nd your reply). Let me list some events that might help clarify... Initial state: Mobile node is connected to a network; no Sustained IP addre= ss is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indica= ting that if an application requests a Sustained IP address, it will have t= o request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Event2: A new application that also required a Sustained IP address is laun= ched App action: App requests a Sustained IP address from the IP stack using the= proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the A= PI action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustain= ed IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the= proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from th= e network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be ass= ociated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete= the API action and associate the marked Sustained IP address with that por= t (app) Note that the behavior of the IP stack in Event4 is exactly like the one in= Event1. I believe that this event is the one we have different of opinions: I think= that the default behavior of the IP stack is to request a new Sustained IP= address since it moved to a new LAN, and you think that it should do so on= ly if the application specifically requests a new Sustained IP address via = the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an exampl= e where it will not be used. It seems to me that applications will always r= equest a refreshed Sustained IP address (when requesting a Sustained IP add= ress). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from op= timal routing would consider a Sustained IP address without issuing the new= flag. More applications based on such network characteristic can be though= t more than expected. And such use of existing Sustained IP address is not extraordinary, since I= P address is a resource, even in the consideration of IPv6 deployment. If a= s many as applications require new Sustained IP address, it will end up in = a lot of network resource consumption in the mobility routers where the Sus= tained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an exa= mple of an application that will request a Nomadic address since it does no= t break when the mobile node moves to a new LAN and the source IP address i= s changed. It simply restarts the socket and continue with the new source I= P address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP addres= s is used. You could get some insight from such kind of application not car= ing much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thoug= ht we agreed that even of a new Sustained IP address is requested upon each= movement to a new LAN, the effect on IP address allocation is not signific= ant. Otherwise, my initial comment on applications abusing the network usin= g your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address= is requested upon receiving *new* flag from an application, as a preferenc= e for a source address selection. You need to read our draft classifying th= e categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference canno= t be abuse. Regarding "abuse", I see it in your default behavior you're ass= uming here. In your scenario, a new app initiated in a new network will be = forced to use a newly obtained Sustained IP address. You see that? You tota= lly block the possibility to be considered by the default source address se= lection rules defined in RFC6724. But in our draft, in case the need of a n= ewly obtained Sustained IP address is prioritized, the proposed *new* flag = can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refr= esh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answ= ers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case i= n the draft. On receiving this API with the SUSTAINED IP address type at th= e IP stack, it will try to get a new SUSTAINED IP address if there is no av= ailable in the currently attached access network. So, actual obtaining of t= he IP address will be tried one time while attached at a specific access ne= twork. Even some applications put this API after, the already obtained SUST= AINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the = host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, th= at is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should= show its requirement with an API among them. If it is the SUSTAINED IP add= ress, how do we expect the IP stack will try to get a new SUSTAINED IP addr= ess? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813490D90EHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

You have a good point = here.

 

No= w I understand the need for the flag you are proposing !!!

 

 

We need to take a bett= er look at RFC 6724 and figure out if we need to update it.

 

I am thinking of two p= laces that might require an update:

1.&n= bsp;      When an application chooses not to specify a source address (but= request a specific type)

2.&n= bsp;      When an application wishes to choose the source address from a p= rovided list.

 

When the application i= ndicates the desired address type, but chooses not to specify the source ad= dress (from a list provided by the IP stack), the stack should allocate a s= ource IP address according to the address-type requested by the application. In this case, we should consider adding text= to describe the behavior for Sustained IP addresses. Specifically, if ther= e are several Sustained IP addresses allocated to the mobile host, whether = to choose one of them, or to have the mobile host request a new one from the network (as a result of a mobil= ity event – for example).

 

When an application wi= shes to chooses the source address from the available list (obtained by get= addrinfo()), there are some alternative approaches we should consider:=

1.&n= bsp;      Enhance getaddrinfo() enabling the application to specify the re= quired address type, and return the list of source addresses that are of th= at type (Nomadic, Sustained, Fixed or DontCare), or -

2.&n= bsp;      Provide the list of addresses with an indication of their type (= Nomadic, Sustained, Fixed or TypeUnknown) and an indication of whether each= address is New (allocated after the last handoff event) or Old (allocated before the last handoff event)<= /o:p>

3.&n= bsp;      Some other approach…

 

Th= e flag is need here, to enable the application to request a new IP address = (if the returned list only contain 'Old' addresses) !!!

 

I agree that we should= discuss this. How about bringing it to the next 'Mobility Exposure and Selection WT' call?

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

Meeting is always good, even with you by f-t= o-f. But in the discussion, the main issue is whether we will allow the def= ault source address selection rules defined in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block= them for a specific reason raised by a DMM need. The latter approach is no= t reasonable no matter how I try to think of.it.

If an application has the specific preferenc= e of a newly obtained Sustained IP address, it uses the proposed API.<= /o:p>

 

Regards.

Seil

 

 

From: Moses, D= anny [mailto:danny.moses@intel.com= ]
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

By now we have been di= scussing this for quite some time and clearly we did not succeed in convinc= ing each other.

I suggest we try again= when we have a chance to meet face to face. Meanwhile, let's listen to wha= t other people have to say on this matter.

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Resent.

 

Seil

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm@ietf.org'
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

See the inline please. I marked current repl= ies with “>>” and previous replies with “>”= ; for you to catch them easily.

 

Regards,

Seil

 

 

From: Moses, D= anny [mailto:da= nny.moses@intel.com]
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

   &nbs= p;            /Danny=

 

From: Seil Jeo= n [mailto:seiljeon@= av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

See the inline please.

 

 

Seil Jeon

 

 

From: Moses, D= anny [mailto:da= nny.moses@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org<= /span>
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

As to the potential of= abuse:

Yes, I see your point = and you are correct. If the IP stack will not request a sustained IP addres= s more than once after each movement to a new LAN (with a different prefix)= , than there will be no abuse.

 

> Yes, it’s true. Thanks for correction.

 

As to the second comme= nt, please let me elaborate:

One potential implemen= tation of the IP stack in the host, can be to request a Nomadic IP address = and a  Sustained IP address whenever connecting to a network, and when= ever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

 

> Decision of which type of IP address by default will = be depending on the IP pool management policy by operators. You case may co= rrespond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applic= ations require mere Internet connectivity without session continuity suppor= t. So, the Sustained IP address will be requested on demand, and the propos= ed flag will be used to get a new Sustained IP address by expressing the explicit request by an application.=

 

>>2

As I mentioned at the = beginning of the description – it is a description of one alternative= . I am not assuming it is the only scenario.

Yes, I agree that many= apps require only Nomadic IP addresses, but in this example, the IP stack = in the host pre-allocates both Nomadic and Sustained IP addresses upon atta= chment…

 

>> As I said, it could be, but not as general one. T= he proposed API is useful through the explicit expression for any potential= scenarios.

 

Yes, we can describe a= n alternative in which a Nomadic IP address is pre-allocated upon NW connec= tion (and after every movement to a new LAN) and a Sustained (and/or Fixed)= address is allocated on-demand. Even in such a scenario, I do not see any use for this flag – see my repl= y to the second item below…

>>2

 

>> My answer was already given in following answer i= n previous email.

 

Another potential impl= ementation of the IP stack in the host is not to request IP addresses in ad= vance. In that case, it will issue a request for a Nomadic IP address or a = Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained – according to what is required= ) after receiving the first request from any application. In this case as well, there is no need for this flag.

 

> Another application requested just Sustained IP addre= ss while the IP stack has already a Sustained IP address. Why should the IP= stack try to get a new one, though the application indicated simply “Sustained IP address type”? You case took a step towar= ds a solution where you want to draw. I don’t expect the action is ge= neric when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not= valid. A mobile host would get an IP address whatever the allocated IP add= ress type is when it attaches at a network, regardless of an application’s IP address request.

 

>>2

Looks like I did not express myself well eno= ugh (and did not fully understand your reply). Let me list some events that= might help clarify…

 

Initial state: Mobile node is connected to a= network; no Sustained IP address is allocated. The IP stack sets a flag (S= ustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the netw= ork.

 

Event1: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Event2: A new application that also required= a Sustained IP address is launched

App action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API

IP Stack action: Since SustainedIPAddressNee= ded  is not set, complete the API action and associate the marked Sust= ained IP address with that port (app)

 

Event3: The mobile node moves to a new LAN

IP Stack action: Set a flag indicating that = the currently available Sustained IP address is not optimized

 

Event4: An application that requires a Susta= ined IP address is launched.

APP action: App requests a Sustained IP addr= ess from the IP stack using the proposed new API.

IP stack action: Since SustainedIPAddressNee= ded is set, request one from the network.

Network action: Assigned a Sustained IP addr= ess to the mobile node.

IP stack action: (1) Mark the new Sustained = IP address as the one to be associated to subsequent apps; (2) Reset Sustai= nedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app)

 

Note that the behavior of the IP stack in Ev= ent4 is exactly like the one in Event1.

 

I believe that this event is the one we h= ave different of opinions: I think that the default behavior of the IP stac= k is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application s= pecifically requests a new Sustained IP address via the flag you are propos= ing.

>>2

 

>> You can see my answer at the lowest “>&g= t;” in this mail.

 

As a matter of fact, i= f such a flag is defined, I cannot think of an example where it will not be= used. It seems to me that applications will always request a refreshed Sus= tained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

 

> Some applications, e.g. email, that are not relativel= y restricted from optimal routing would consider a Sustained IP address wit= hout issuing the new flag. More applications based on such network characteristic can be thought more than expected.

And such use of existing Sustained IP address is not extra= ordinary, since IP address is a resource, even in the consideration of IPv6= deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the= mobility routers where the Sustained IP addresses are anchored as the term= inal moves.

>>2

I am sorry but I disag= ree with the email example. I categorize it as an example of an application= that will request a Nomadic address since it does not break when the mobil= e node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the= new source IP address (the user will not even notice this).

 

>> The example was given as a benefit when the exist= ing Sustained IP address is used. You could get some insight from such kind= of application not caring much the routing distance even on the Sustained IP address.

 

I did not understand t= he other text regarding resource consumption. I thought we agreed that even= of a new Sustained IP address is requested upon each movement to a new LAN= , the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again=

>>2

 

>> No, our draft didn’t say so. Our idea is th= at a new Sustained IP address is requested upon receiving *new* flag from a= n application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again.<= o:p>

 

Besides, I don’t understand what is abused. Deliveri= ng its preference cannot be abuse. Regarding “abuse”, I see it = in your default behavior you’re assuming here. In your scenario, a ne= w app initiated in a new network will be forced to use a newly obtained Sustaine= d IP address. You see that? You totally block the possibility to be conside= red by the default source address selection rules defined in RFC6724. But i= n our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* f= lag can be used by app’s request, thus it will be selected with prior= ity.

 

Can you provide a scen= ario in which an application will not request to refresh the Sustained IP a= ddress?

 

> It was mentioned in the former comments.

 

 

Regards,

   &nbs= p;            /Danny=

From: Seil Jeo= n [mailto:seiljeon@= av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org<= /span>
Subject: FW: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

Any comments?

 

Regards,

Seil Jeon

 

 

From: dmm [mailto:dmm-bounces@= ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org<= /span>
Subject: [DMM] Answer on raised questions for the proposed API<= /o:p>

 

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?=

If the question is right, I don’t understand what th= e question is meant, that is how the host can get a new SUSTAINED IP addres= s?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

 

Besides, the propsoed API is not used alone but with the t= hree type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

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

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

--_000_F0CF5715D3D1884BAC731EA1103AC2813490D90EHASMSX106gercor_-- From nobody Sun Apr 12 15:03:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACCA1B389B for ; Sun, 12 Apr 2015 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 20tdznomNa4z for ; Sun, 12 Apr 2015 15:03:26 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id BD45D1B3899 for ; Sun, 12 Apr 2015 15:03:23 -0700 (PDT) Received: from [188.80.241.232] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77482954; Sun, 12 Apr 2015 23:03:16 +0100 From: "Seil Jeon" To: "'Moses, Danny'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> In-Reply-To: Date: Sun, 12 Apr 2015 23:03:15 +0100 Message-ID: <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01D07574.DC468690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uYCqJZpkgDQIjNOAdQYy1EBr/T0wgK/SzL8A4QAO4abEr6MYA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 22:03:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01D07574.DC468690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danny, >From your cases specified as follows; "I am thinking of two places that might require an update: 1. When an application chooses not to specify a source address (but request a specific type) 2. When an application wishes to choose the source address from a provided list. " I don't understand the meaning of the second case. Why should an application wish to choose a source address from a list? What I have talked about was about allowing the default source address selection rules, which will be determined in the IP stack when an application is initiated with the destination address. I think we don't need to touch it. The point is an application will totally assign the default source address selection mechanism based on only type request but with no preference, or will request with the preference of a new Sustained IP address as well as type request. In the former case, if there is one or multiple Sustained IP addresses, the IP stack will try to pick up one. Or the IP stack will try to get a new one. In the latter case, the IP stack will consider a newly obtained Sustained IP address all the time, if the requested preference value is not less than other preferences defined in the default source address selection rules. The need of the proposed flag and main criteria to be considered were already covered with case studies in the draft. http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 So, for productive discussion, I would like to suggest that you check our draft again please and bring your questions if there is something weird or should be updated with additional cases. Best Regards, Seil Jeon From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 12, 2015 1:49 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API You have a good point here. Now I understand the need for the flag you are proposing !!! We need to take a better look at RFC 6724 and figure out if we need to update it. I am thinking of two places that might require an update: 1. When an application chooses not to specify a source address (but request a specific type) 2. When an application wishes to choose the source address from a provided list. When the application indicates the desired address type, but chooses not to specify the source address (from a list provided by the IP stack), the stack should allocate a source IP address according to the address-type requested by the application. In this case, we should consider adding text to describe the behavior for Sustained IP addresses. Specifically, if there are several Sustained IP addresses allocated to the mobile host, whether to choose one of them, or to have the mobile host request a new one from the network (as a result of a mobility event - for example). When an application wishes to chooses the source address from the available list (obtained by getaddrinfo()), there are some alternative approaches we should consider: 1. Enhance getaddrinfo() enabling the application to specify the required address type, and return the list of source addresses that are of that type (Nomadic, Sustained, Fixed or DontCare), or - 2. Provide the list of addresses with an indication of their type (Nomadic, Sustained, Fixed or TypeUnknown) and an indication of whether each address is New (allocated after the last handoff event) or Old (allocated before the last handoff event) 3. Some other approach. The flag is need here, to enable the application to request a new IP address (if the returned list only contain 'Old' addresses) !!! I agree that we should discuss this. How about bringing it to the next 'Mobility Exposure and Selection WT' call? Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, Meeting is always good, even with you by f-to-f. But in the discussion, the main issue is whether we will allow the default source address selection rules defined in RFC6724 for selecting a Sustained IP address among several ones or fundamentally block them for a specific reason raised by a DMM need. The latter approach is not reasonable no matter how I try to think of.it. If an application has the specific preference of a newly obtained Sustained IP address, it uses the proposed API. Regards. Seil From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 05, 2015 12:23 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, By now we have been discussing this for quite some time and clearly we did not succeed in convincing each other. I suggest we try again when we have a chance to meet face to face. Meanwhile, let's listen to what other people have to say on this matter. Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Sunday, April 05, 2015 01:16 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Resent. Seil From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. I marked current replies with ">>" and previous replies with ">" for you to catch them easily. Regards, Seil From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, Please see my replies (surrounded by >>2) to yours. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [ mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request a sustained IP address more than once after each movement to a new LAN (with a different prefix), than there will be no abuse. > Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request a Nomadic IP address and a Sustained IP address whenever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an application is launched and requests either a Nomadic or Sustained IP address, the stack can provide one without having to issue a request to the network. In this case, there is no need for this flag from the application. > Decision of which type of IP address by default will be depending on the IP pool management policy by operators. You case may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applications require mere Internet connectivity without session continuity support. So, the Sustained IP address will be requested on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an application. >>2 As I mentioned at the beginning of the description - it is a description of one alternative. I am not assuming it is the only scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in this example, the IP stack in the host pre-allocates both Nomadic and Sustained IP addresses upon attachment. >> As I said, it could be, but not as general one. The proposed API is useful through the explicit expression for any potential scenarios. Yes, we can describe an alternative in which a Nomadic IP address is pre-allocated upon NW connection (and after every movement to a new LAN) and a Sustained (and/or Fixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag - see my reply to the second item below. >>2 >> My answer was already given in following answer in previous email. Another potential implementation of the IP stack in the host is not to request IP addresses in advance. In that case, it will issue a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as it is not moving to a different LAN. Once it moves, it will again request a new IP address (Nomadic or Sustained - according to what is required) after receiving the first request from any application. In this case as well, there is no need for this flag. > Another application requested just Sustained IP address while the IP stack has already a Sustained IP address. Why should the IP stack try to get a new one, though the application indicated simply "Sustained IP address type"? You case took a step towards a solution where you want to draw. I don't expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile host would get an IP address whatever the allocated IP address type is when it attaches at a network, regardless of an application's IP address request. >>2 Looks like I did not express myself well enough (and did not fully understand your reply). Let me list some events that might help clarify. Initial state: Mobile node is connected to a network; no Sustained IP address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating that if an application requests a Sustained IP address, it will have to request one from the network. Event1: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Event2: A new application that also required a Sustained IP address is launched App action: App requests a Sustained IP address from the IP stack using the proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete the API action and associate the marked Sustained IP address with that port (app) Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available Sustained IP address is not optimized Event4: An application that requires a Sustained IP address is launched. APP action: App requests a Sustained IP address from the IP stack using the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API action and associate the marked Sustained IP address with that port (app) Note that the behavior of the IP stack in Event4 is exactly like the one in Event1. I believe that this event is the one we have different of opinions: I think that the default behavior of the IP stack is to request a new Sustained IP address since it moved to a new LAN, and you think that it should do so only if the application specifically requests a new Sustained IP address via the flag you are proposing. >>2 >> You can see my answer at the lowest ">>" in this mail. As a matter of fact, if such a flag is defined, I cannot think of an example where it will not be used. It seems to me that applications will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant. > Some applications, e.g. email, that are not relatively restricted from optimal routing would consider a Sustained IP address without issuing the new flag. More applications based on such network characteristic can be thought more than expected. And such use of existing Sustained IP address is not extraordinary, since IP address is a resource, even in the consideration of IPv6 deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the mobility routers where the Sustained IP addresses are anchored as the terminal moves. >>2 I am sorry but I disagree with the email example. I categorize it as an example of an application that will request a Nomadic address since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts the socket and continue with the new source IP address (the user will not even notice this). >> The example was given as a benefit when the existing Sustained IP address is used. You could get some insight from such kind of application not caring much the routing distance even on the Sustained IP address. I did not understand the other text regarding resource consumption. I thought we agreed that even of a new Sustained IP address is requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comment on applications abusing the network using your proposed flag, becomes valid again >>2 >> No, our draft didn't say so. Our idea is that a new Sustained IP address is requested upon receiving *new* flag from an application, as a preference for a source address selection. You need to read our draft classifying the categories of IP address request again. Besides, I don't understand what is abused. Delivering its preference cannot be abuse. Regarding "abuse", I see it in your default behavior you're assuming here. In your scenario, a new app initiated in a new network will be forced to use a newly obtained Sustained IP address. You see that? You totally block the possibility to be considered by the default source address selection rules defined in RFC6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized, the proposed *new* flag can be used by app's request, thus it will be selected with priority. Can you provide a scenario in which an application will not request to refresh the Sustained IP address? > It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [ mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. ------=_NextPart_000_002B_01D07574.DC468690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Danny,

 

From your cases = specified as follows;

 

“I am thinking = of two places that might require an update:

1.       = When an application chooses not to specify a = source address (but request a specific type)

2.       = When an application wishes to choose the source = address from a provided list.

“

<= p class=3DMsoNormal> 

I don’t = understand the meaning of the second case. Why should an application = wish to choose a source address from a list? What I have talked about = was about allowing the default source address selection rules, which = will be determined in the IP stack when an application is initiated with = the destination address. I think we don’t need to touch = it.

 

The point is an = application will totally assign the default source address selection = mechanism based on only type = request but with no preference, or will = request with the preference = of a new Sustained IP address as well as type request. In the former = case, if there is one or multiple Sustained IP addresses, the IP stack = will try to pick up one. Or the IP stack will try to get a new one. In = the latter case, the IP stack will consider a newly obtained Sustained = IP address all the time, if the requested preference value is not less = than other preferences defined in the default source address selection = rules.

 

The need of the = proposed flag and main criteria to be considered were already covered = with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00

 

So, for = productive discussion, I would like to suggest that you check our draft = again please and bring your questions if there is something weird or = should be updated with additional cases.

 

 

 

 

You have a good point = here.

 

Now = I understand the need for the flag you are proposing !!! =

 

 

We need to take a better = look at RFC 6724 and figure out if we need to update = it.

 

I am thinking of two = places that might require an update:

1.       = When an = application chooses not to specify a source address (but request a = specific type)

2.       = When an = application wishes to choose the source address from a provided = list.

 

When the application = indicates the desired address type, but chooses not to specify the = source address (from a list provided by the IP stack), the stack should = allocate a source IP address according to the address-type requested by = the application. In this case, we should consider adding text to = describe the behavior for Sustained IP addresses. Specifically, if there = are several Sustained IP addresses allocated to the mobile host, whether = to choose one of them, or to have the mobile host request a new one from = the network (as a result of a mobility event – for = example).

 

When an application = wishes to chooses the source address from the available list (obtained = by getaddrinfo()), there are some alternative approaches we should = consider:

1.       = Enhance = getaddrinfo() enabling the application to specify the required address = type, and return the list of source addresses that are of that type = (Nomadic, Sustained, Fixed or DontCare), or -

2.       = Provide the = list of addresses with an indication of their type (Nomadic, Sustained, = Fixed or TypeUnknown) and an indication of whether each address is New = (allocated after the last handoff event) or Old (allocated before the = last handoff event)

3.       = Some other = approach…

 

The = flag is need here, to enable the application to request a new IP address = (if the returned list only contain 'Old' addresses) = !!!

 

I agree that we should = discuss this. How about bringing it to the next 'Mobility Exposure and Selection WT' call?

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Sunday, April 05, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Meeting is = always good, even with you by f-to-f. But in the discussion, the main = issue is whether we will allow the default source address selection = rules defined in RFC6724 for selecting a Sustained IP address among = several ones or fundamentally block them for a specific reason raised by = a DMM need. The latter approach is not reasonable no matter how I try to = think of.it.

If an = application has the specific preference of a newly obtained Sustained IP = address, it uses the proposed API.

 

Regards.

Seil<= /span>

 

 

From:= = Moses, Danny [mailto:danny.moses@intel.com] =
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

By now we have been = discussing this for quite some time and clearly we did not succeed in = convincing each other.

I suggest we try again when we have a chance to = meet face to face. Meanwhile, let's listen to what other people have to = say on this matter.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Sunday, April 05, 2015 01:16
To: Moses, = Danny
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Resent.

 

Seil

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, = Danny'
Cc: 'dmm@ietf.org'
Subject: RE: [DMM] Answer = on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please. I marked current replies with “>>” and = previous replies with “>” for you to catch them = easily.

 

Regards,

Seil<= /span>

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

Please see my replies = (surrounded by  >>2) to yours.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Tuesday, March 31, 2015 15:23
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please.

 

 

Seil Jeon =

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Monday, March 30, 2015 4:44 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

As to the potential of = abuse:

Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

 

> = Yes, it’s true. Thanks for correction.

 

As to the = second comment, please let me elaborate:

One potential = implementation of the IP stack in the host, can be to request a Nomadic = IP address and a  Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any = applications requesting any addresses. This way, whenever an application = is launched and requests either a Nomadic or Sustained IP address, the = stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the = application.

 

> = Decision of which type of IP address by default will be depending on the = IP pool management policy by operators. You case may correspond to one = of them. What if only the Nomadic IP address is basically allocated upon = a network attachment? That is, a lot of applications require mere = Internet connectivity without session continuity support. So, the = Sustained IP address will be requested on demand, and the proposed flag = will be used to get a new Sustained IP address by expressing the = explicit request by an application.

 

>>2

As I mentioned at the = beginning of the description – it is a description of one = alternative. I am not assuming it is the only = scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host = pre-allocates both Nomadic and Sustained IP addresses upon = attachment…

 

>> As I said, it could = be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 

Yes, we = can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or Fixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag – see my reply = to the second item below…

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential = implementation of the IP stack in the host is not to request IP = addresses in advance. In that case, it will issue a request for a = Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained – according to what = is required) after receiving the first request from any application. In = this case as well, there is no need for this = flag.

 

> = Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply “Sustained = IP address type”? You case took a step towards a solution where = you want to draw. I don’t expect the action is generic when a = Sustained IP address type is requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application’s IP address = request.

 

>>2 =

Looks like I = did not express myself well enough (and did not fully understand your = reply). Let me list some events that might help = clarify…

 

Initial state: = Mobile node is connected to a network; no Sustained IP address is = allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it = will have to request one from the network.

 

Event1: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Event2: A new = application that also required a Sustained IP address is launched =

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack = action: Since SustainedIPAddressNeeded  is not set, complete the = API action and associate the marked Sustained IP address with that port = (app)

 

Event3: The = mobile node moves to a new LAN

IP Stack = action: Set a flag indicating that the currently available Sustained IP = address is not optimized

 

Event4: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Note that the = behavior of the IP stack in Event4 is exactly like the one in = Event1.

 

I believe that = this event is the one we have different of opinions: I think that the = default behavior of the IP stack is to request a new Sustained IP = address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>>2

 

>> You can see my = answer at the lowest “>>” in this = mail.

 

As a matter of fact, if = such a flag is defined, I cannot think of an example where it will not = be used. It seems to me that applications will always request a = refreshed Sustained IP address (when requesting a Sustained IP address). = If this is correct, the flag is redundant.

 

> = Some applications, e.g. email, that are not relatively restricted from = optimal routing would consider a Sustained IP address without issuing = the new flag. More applications based on such network characteristic can = be thought more than expected.

And = such use of existing Sustained IP address is not extraordinary, since IP = address is a resource, even in the consideration of IPv6 deployment. If = as many as applications require new Sustained IP address, it will end up = in a lot of network resource consumption in the mobility routers where = the Sustained IP addresses are anchored as the terminal = moves.

>>2

I am sorry but I = disagree with the email example. I categorize it as an example of an = application that will request a Nomadic address since it does not break = when the mobile node moves to a new LAN and the source IP address is = changed. It simply restarts the socket and continue with the new source = IP address (the user will not even notice this).

 

>> The example was = given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP = address.

 

I did not = understand the other text regarding resource consumption. I thought we = agreed that even of a new Sustained IP address is requested upon each = movement to a new LAN, the effect on IP address allocation is not = significant. Otherwise, my initial comment on applications abusing the = network using your proposed flag, becomes valid = again

>>2

 

>> No, our draft = didn’t say so. Our idea is that a new Sustained IP address is = requested upon receiving *new* flag from an application, as a preference = for a source address selection. You need to read our draft classifying = the categories of IP address request again.

 

Besides, I don’t = understand what is abused. Delivering its preference cannot be abuse. = Regarding “abuse”, I see it in your default behavior = you’re assuming here. In your scenario, a new app initiated in a = new network will be forced to use a newly obtained Sustained IP address. = You see that? You totally block the possibility to be considered by the = default source address selection rules defined in RFC6724. But in our = draft, in case the need of a newly obtained Sustained IP address is = prioritized, the proposed *new* flag can be used by app’s request, = thus it will be selected with priority.

 

Can you = provide a scenario in which an application will not request to refresh = the Sustained IP address?

 

> It was mentioned in the = former comments.

 

 

Regards,

        &= nbsp;       = /Danny

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Any = comments?

 

Regards,

Seil = Jeon

 

 

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

 

Hi,

 

I = could attend DMM Thursday meeting via MeetEcho.

I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

 

 

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

 

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

 

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?

If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?

Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

 

Besides, the propsoed API is = not used alone but with the three type APIs.

 

 

 

Regards,

=

 

Seil = Jeon

 

 

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

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

------=_NextPart_000_002B_01D07574.DC468690-- From nobody Sun Apr 12 21:50:19 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA71A899F for ; Sun, 12 Apr 2015 21:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 m6fNJGnGf6C7 for ; Sun, 12 Apr 2015 21:50:15 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (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 3C1D31A8968 for ; Sun, 12 Apr 2015 21:50:15 -0700 (PDT) Received: by wgyo15 with SMTP id o15so68172990wgy.2 for ; Sun, 12 Apr 2015 21:50:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc :in-reply-to:references:organization:content-type:date:mime-version :content-transfer-encoding; bh=vdQa0eVpqMD6Pq4mrLnNcCqpdVBWpSXoNi0ywOIM/ag=; b=hLgBqMcYcAHBH3smS1ZIg+2OAf943vZ45rFPzM5GyopQJPfu2Gxk/dKwUuyyjTpKI9 lUXXqbsvENrzHdMmysiUkuaWS09T+Dlw5fNgfYY+XWRtcUXMhqyVlFnl62ebnh3iD+Iv pzDVgRMYIE0aDGGpyomS9a6wAux/eX6oRxJls0PpYhcneIh9kuZUj5SZ3a/huh2CJH9D ErfEBgN8P8gDfG6MFr9qPQbEbKgef/J1SSktWvimZSv9KGoE53hTTq29/MiJxJSwgbDa TvHw3uaY9B6SD/2UorHe/a2KPvDHX4jO2Lnq5Zte4gDci7Hu2gOoa5Qe1epKQ2BNQZRN gAsA== X-Gm-Message-State: ALoCoQlLW1wmgPdv+VJ6QvriU3gcnRF3c+ojyIzQ+DRzw15QOrSrYkKqve3c6KCck5JBZfuu+QC0 X-Received: by 10.180.107.70 with SMTP id ha6mr17853831wib.20.1428900613945; Sun, 12 Apr 2015 21:50:13 -0700 (PDT) Received: from acorde ([178.139.153.223]) by mx.google.com with ESMTPSA id ju2sm9648648wid.12.2015.04.12.21.50.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 21:50:13 -0700 (PDT) Message-ID: <1428888436.6974.201.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jouni Korhonen In-Reply-To: <551F2A6D.6080100@gmail.com> References: <551F2A6D.6080100@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Apr 2015 03:27:16 +0200 Mime-Version: 1.0 X-Mailer: Evolution 3.12.9-1+b1 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 04:50:18 -0000 Hi, I support adoption of this I-D. I think it is good as a starting point. Carlos On Fri, 2015-04-03 at 17:03 -0700, Jouni Korhonen wrote: > Folks, > > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the > technical solution. The call ends April 17th EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption and 3 against. we > expect at least the same amount of expressed opinions on the list. > > Notice that version -01 of this I-D had an IPR declared to it. See > https://datatracker.ietf.org/ipr/2309/ > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Apr 12 21:50:44 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24901A89AA for ; Sun, 12 Apr 2015 21:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 TwxWKT16w99r for ; Sun, 12 Apr 2015 21:50:32 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 70A421A89A9 for ; Sun, 12 Apr 2015 21:50:32 -0700 (PDT) Received: by widdi4 with SMTP id di4so37927838wid.0 for ; Sun, 12 Apr 2015 21:50:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc :in-reply-to:references:organization:content-type:date:mime-version :content-transfer-encoding; bh=QV8/1KbgpbFUQj1jh5gmyfV7b4XZ0JcbVjGlJD+MGTU=; b=i4pQY1i21QF2dwB314Guy/6yfWgzTAUxhFVPcCdoTTiaRLbWLXQRC2KPWZfrQgeSc8 zclKWcWXygeRvNdaj/gDbTIUOu7ajBM3SAfU9TPHsbbEzQxvKvK/BnSCJxtVI5D7JoOR UTbYQdRX0ANzat/Yxoj0jrSuxbucR6ZZWbUHpP3E2CsdIOLQpkCXhuY2az4qdSfMHMN4 kPaMgixpiXucbZvQWCFHKpimDkIyUfF1WbuYm9XI8un8sj2Rg8D5ft4wvZ3pw/HqIj9n eaFO6N8dY0JbFpIgaTjq3LJKm1ApnuRIrPuBipM30fnC/Q6XaK/pBKjipclTedSptC5t sAAQ== X-Gm-Message-State: ALoCoQmMAaw7ajqloQFEHzNth+e1wcTDVBB+jaIBUnMS9lm0XCe0MFa0Bl2BORb7xUxbn1A99ffM X-Received: by 10.194.90.15 with SMTP id bs15mr24706172wjb.22.1428900631179; Sun, 12 Apr 2015 21:50:31 -0700 (PDT) Received: from acorde ([178.139.153.223]) by mx.google.com with ESMTPSA id eu3sm9662451wjb.16.2015.04.12.21.50.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 21:50:30 -0700 (PDT) Message-ID: <1428888492.6974.203.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jouni Korhonen In-Reply-To: <551D5082.3050904@gmail.com> References: <551D5082.3050904@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Apr 2015 03:28:12 +0200 Mime-Version: 1.0 X-Mailer: Evolution 3.12.9-1+b1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmm@ietf.org" , draft-wt-dmm-fpc-cpdp@tools.ietf.org Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 04:50:42 -0000 Hi, I support adoption of this I-D. I think it is a very good starting point. Carlos On Thu, 2015-04-02 at 07:21 -0700, Jouni Korhonen wrote: > Folks, > > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th > EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption so at least the same > amount supporting emails should be expected. > > > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Apr 12 22:33:56 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202AA1B2CDF for ; Sun, 12 Apr 2015 22:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Pt5q0WJXq7jE for ; Sun, 12 Apr 2015 22:33:53 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFC81B2CDB for ; Sun, 12 Apr 2015 22:33:51 -0700 (PDT) Received: from JoyYan (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BplnE4VStVdFQvAA--.61421S2; Mon, 13 Apr 2015 13:33:44 +0800 (CST) Date: Mon, 13 Apr 2015 13:33:45 +0800 From: "Z.W. Yan" To: "dmm" Message-ID: <201504131333451125705@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon754385771164_=====" X-CM-TRANSID: AQAAf0BplnE4VStVdFQvAA--.61421S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5l7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Cr 1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487McIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4rMxAIw28IcxkI7VAKI48J MxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4 v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07Ui6pPUUUUU= X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: [DMM] New Version Notification for draft-yan-dmm-hnprenum-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 05:33:55 -0000 This is a multi-part message in MIME format. --=====003_Dragon754385771164_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, all, During the Dallas meeting, we introduced the issue of HNP-renumbering in PMIPv6 and heard some positive voices. In order to present it more clearly and collect more comments, we updated the draft with the 01 version. https://tools.ietf.org/html/draft-yan-dmm-hnprenum-01 Any comments from you are all welcome. Thanks. Zhiwei Yan --=====003_Dragon754385771164_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi, all,
During the Dallas meeting, we introduced the issue of HNP-renumbering in PMIPv6 and heard some positive voices.
In order to present it more clearly and collect more comments, 
we updated the draft with the 01 version.
 
Any comments from you are all welcome.
Thanks.
Zhiwei Yan
 
 
--=====003_Dragon754385771164_=====-- From nobody Mon Apr 13 05:54:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D31B2F65 for ; Mon, 13 Apr 2015 05:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 V4uT0n3-A4gk for ; Mon, 13 Apr 2015 05:54:46 -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 DFC821B2F58 for ; Mon, 13 Apr 2015 05:54:45 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so101377734pac.1 for ; Mon, 13 Apr 2015 05:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=EV7lJGnxAwbMrtUL1iDxRgIlL6mux3FmczGwzhFZ3xE=; b=bC1o+xPY4YC0SN0fXIHkmtURz5DZTHtzXIMBOa+jI/80Z2u24qoiC48PVbf2AoLzRv vCs8xtmdP7PYskAtGIPkA5x7bPExHgZLHi2OFRgylaHG5Vg5ETYYcGWKR8SG4WxDCe2o pTlGMkIvFtevnvzpH63aE4AxJUnLoy672UXIlsMA2irtVNCT6wzO/Hdwtowhr5B0KWNy dh1cftkSiyH2RfgRZ/gRs9qs6PD00XNjkt60u97hAJpCcb1ITm29bgyZ0OF0oLp1ieG0 Ce1caZKfm2/pL4bkG6/rVt+hG2AzGRTrPT+FqIU9axv8rVrFb7YRf77TWUQg6s/JcydS eJpQ== X-Received: by 10.66.192.74 with SMTP id he10mr26105139pac.145.1428929685504; Mon, 13 Apr 2015 05:54:45 -0700 (PDT) Received: from [9.3.156.134] ([192.200.112.37]) by mx.google.com with ESMTPSA id np6sm7265792pdb.80.2015.04.13.05.54.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 05:54:43 -0700 (PDT) Date: Mon, 13 Apr 2015 20:53:34 +0800 From: Dapeng Liu To: Seil Jeon Message-ID: In-Reply-To: <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552bbc4f_51d9c564_e7" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 12:54:52 -0000 --552bbc4f_51d9c564_e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Seil, Danny=EF=BC=9A =20 =5Bas an individual contributor=5D You can refer to the following two drafts: https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 Is it the similar idea=3F =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A= > Hi Danny, > =20 > =46rom your cases specified as follows; > =20 > =E2=80=9CI am thinking of two places that might require an update: > 1. When an application chooses not to specify a source address (b= ut request a specific type) > 2. When an application wishes to choose the source address from a= provided list. > =E2=80=9C > =20 > I don=E2=80=99t understand the meaning of the second case. Why should a= n application wish to choose a source address from a list=3F What I have = talked about was about allowing the default source address selection rule= s, which will be determined in the IP stack when an application is initia= ted with the destination address. I think we don=E2=80=99t need to touch = it. > =20 > The point is an application will totally assign the default source addr= ess selection mechanism based on only type request but with no preference= , or will request with the preference of a new Sustained IP address as we= ll as type request. In the former case, if there is one or multiple Susta= ined IP addresses, the IP stack will try to pick up one. Or the IP stack = will try to get a new one. In the latter case, the IP stack will consider= a newly obtained Sustained IP address all the time, if the requested pre= ference value is not less than other preferences defined in the default s= ource address selection rules. > =20 > The need of the proposed flag and main criteria to be considered were a= lready covered with case studies in the draft. > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 > =20 > So, for productive discussion, I would like to suggest that you check o= ur draft again please and bring your questions if there is something weir= d or should be updated with additional cases. > =20 > =20 > Best Regards, > =20 > Seil Jeon > =20 > =20 > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > Sent: Sunday, April 12, 2015 1:49 PM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > You have a good point here. > =20 > Now I understand the need for the flag you are proposing =21=21=21 =20 > =20 > =20 > We need to take a better look at R=46C 6724 and figure out if we need t= o update it. > =20 > I am thinking of two places that might require an update: > 1. When an application chooses not to specify a source address (b= ut request a specific type) > 2. When an application wishes to choose the source address from a= provided list. > =20 > When the application indicates the desired address type, but chooses no= t to specify the source address (from a list provided by the IP stack), t= he stack should allocate a source IP address according to the address-typ= e requested by the application. In this case, we should consider adding t= ext to describe the behavior for Sustained IP addresses. Specifically, if= there are several Sustained IP addresses allocated to the mobile host, w= hether to choose one of them, or to have the mobile host request a new on= e from the network (as a result of a mobility event =E2=80=93 for example= ). > =20 > When an application wishes to chooses the source address from the avail= able list (obtained by getaddrinfo()), there are some alternative approac= hes we should consider: > 1. Enhance getaddrinfo() enabling the application to specify the = required address type, and return the list of source addresses that are o= f that type (Nomadic, Sustained, =46ixed or DontCare), or - =20 > 2. Provide the list of addresses with an indication of their type= (Nomadic, Sustained, =46ixed or TypeUnknown) and an indication of whethe= r each address is New (allocated after the last handoff event) or Old (al= located before the last handoff event) > 3. Some other approach=E2=80=A6 > =20 > The flag is need here, to enable the application to request a new IP ad= dress (if the returned list only contain 'Old' addresses) =21=21=21 > =20 > I agree that we should discuss this. How about bringing it to the next = 'Mobility Exposure and Selection WT' call=3F > =20 > Regards, > /Danny > =20 > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > Sent: Sunday, April 05, 2015 17:08 > To: Moses, Danny > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Danny, > =20 > Meeting is always good, even with you by f-to-f. But in the discussion,= the main issue is whether we will allow the default source address selec= tion rules defined in R=46C6724 for selecting a Sustained IP address amon= g several ones or fundamentally block them for a specific reason raised b= y a DMM need. The latter approach is not reasonable no matter how I try t= o think of.it (http://of.it). > If an application has the specific preference of a newly obtained Susta= ined IP address, it uses the proposed API. > =20 > Regards. > Seil > =20 > =20 > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > Sent: Sunday, April 05, 2015 12:23 PM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Seil, > =20 > By now we have been discussing this for quite some time and clearly we = did not succeed in convincing each other. > I suggest we try again when we have a chance to meet face to face. Mean= while, let's listen to what other people have to say on this matter. > =20 > Regards, > /Danny > =20 > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > Sent: Sunday, April 05, 2015 01:16 > To: Moses, Danny > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Resent. > =20 > Seil > =20 > =20 > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > Sent: Saturday, April 04, 2015 1:35 PM > To: 'Moses, Danny' > Cc: 'dmm=40ietf.org (mailto:dmm=40ietf.org)' > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Danny, > =20 > See the inline please. I marked current replies with =E2=80=9C>>=E2=80=9D= and previous replies with =E2=80=9C>=E2=80=9D for you to catch them easi= ly. > =20 > Regards, > Seil > =20 > =20 > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > Sent: Thursday, April 02, 2015 2:16 PM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Seil, > =20 > Please see my replies (surrounded by >>2) to yours. > =20 > Regards, > /Danny > =20 > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > Sent: Tuesday, March 31, 2015 15:23 > To: Moses, Danny > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Danny, > =20 > See the inline please. > =20 > =20 > Seil Jeon =20 > =20 > =20 > =20 > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > Sent: Monday, March 30, 2015 4:44 PM > To: Seil Jeon > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi Seil, > =20 > As to the potential of abuse: > Yes, I see your point and you are correct. If the IP stack will not req= uest a sustained IP address more than once after each movement to a new L= AN (with a different prefix), than there will be no abuse. > =20 > > Yes, it=E2=80=99s true. Thanks for correction. > =20 > As to the second comment, please let me elaborate: > One potential implementation of the IP stack in the host, can be to req= uest a Nomadic IP address and a Sustained IP address whenever connecting= to a network, and whenever moving to a new LAN, regardless if there are = any applications requesting any addresses. This way, whenever an applicat= ion is launched and requests either a Nomadic or Sustained IP address, th= e stack can provide one without having to issue a request to the network.= In this case, there is no need for this flag from the application. > =20 > > Decision of which type of IP address by default will be depending on = the IP pool management policy by operators. You case may correspond to on= e of them. What if only the Nomadic IP address is basically allocated upo= n a network attachment=3F That is, a lot of applications require mere Int= ernet connectivity without session continuity support. So, the Sustained = IP address will be requested on demand, and the proposed flag will be use= d to get a new Sustained IP address by expressing the explicit request by= an application. > =20 > >>2 > As I mentioned at the beginning of the description =E2=80=93 it is a de= scription of one alternative. I am not assuming it is the only scenario. > Yes, I agree that many apps require only Nomadic IP addresses, but in t= his example, the IP stack in the host pre-allocates both Nomadic and Sust= ained IP addresses upon attachment=E2=80=A6 > =20 > >> As I said, it could be, but not as general one. The proposed API is = useful through the explicit expression for any potential scenarios. > =20 > Yes, we can describe an alternative in which a Nomadic IP address is pr= e-allocated upon NW connection (and after every movement to a new LAN) an= d a Sustained (and/or =46ixed) address is allocated on-demand. Even in su= ch a scenario, I do not see any use for this flag =E2=80=93 see my reply = to the second item below=E2=80=A6 > >>2 > =20 > >> My answer was already given in following answer in previous email. > =20 > Another potential implementation of the IP stack in the host is not to = request IP addresses in advance. In that case, it will issue a request fo= r a Nomadic IP address or a Sustained IP address the first time an applic= ation requests one and use it for subsequent requests as long as it is no= t moving to a different LAN. Once it moves, it will again request a new I= P address (Nomadic or Sustained =E2=80=93 according to what is required) = after receiving the first request from any application. In this case as w= ell, there is no need for this flag. > =20 > > Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply =E2=80=9CSustained= IP address type=E2=80=9D=3F You case took a step towards a solution wher= e you want to draw. I don=E2=80=99t expect the action is generic when a S= ustained IP address type is requested. > Besides, you assumption on IP address allocation seems not valid. A mob= ile host would get an IP address whatever the allocated IP address type i= s when it attaches at a network, regardless of an application=E2=80=99s I= P address request. > =20 > >>2 =20 > Looks like I did not express myself well enough (and did not fully unde= rstand your reply). Let me list some events that might help clarify=E2=80= =A6 > =20 > Initial state: Mobile node is connected to a network; no Sustained IP a= ddress is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it wil= l have to request one from the network. > =20 > Event1: An application that requires a Sustained IP address is launched= . =20 > APP action: App requests a Sustained IP address from the IP stack using= the proposed new API. > IP stack action: Since SustainedIPAddressNeeded is set, request one fro= m the network. > Network action: Assigned a Sustained IP address to the mobile node. > IP stack action: (1) Mark the new Sustained IP address as the one to be= associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Co= mplete the API action and associate the marked Sustained IP address with = that port (app) > =20 > Event2: A new application that also required a Sustained IP address is = launched =20 > App action: App requests a Sustained IP address from the IP stack using= the proposed new API > IP Stack action: Since SustainedIPAddressNeeded is not set, complete t= he API action and associate the marked Sustained IP address with that por= t (app) > =20 > Event3: The mobile node moves to a new LAN > IP Stack action: Set a flag indicating that the currently available Sus= tained IP address is not optimized =20 > =20 > Event4: An application that requires a Sustained IP address is launched= . =20 > APP action: App requests a Sustained IP address from the IP stack using= the proposed new API. > IP stack action: Since SustainedIPAddressNeeded is set, request one fro= m the network. > Network action: Assigned a Sustained IP address to the mobile node. > IP stack action: (1) Mark the new Sustained IP address as the one to be= associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Co= mplete the API action and associate the marked Sustained IP address with = that port (app) > =20 > Note that the behavior of the IP stack in Event4 is exactly like the on= e in Event1. > =20 > I believe that this event is the one we have different of opinions: I t= hink that the default behavior of the IP stack is to request a new Sustai= ned IP address since it moved to a new LAN, and you think that it should = do so only if the application specifically requests a new Sustained IP ad= dress via the flag you are proposing. > >>2 > =20 > >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this mai= l. > =20 > As a matter of fact, if such a flag is defined, I cannot think of an ex= ample where it will not be used. It seems to me that applications will al= ways request a refreshed Sustained IP address (when requesting a Sustaine= d IP address). If this is correct, the flag is redundant. > =20 > > Some applications, e.g. email, that are not relatively restricted fro= m optimal routing would consider a Sustained IP address without issuing t= he new flag. More applications based on such network characteristic can b= e thought more than expected. > And such use of existing Sustained IP address is not extraordinary, sin= ce IP address is a resource, even in the consideration of IPv6 deployment= . If as many as applications require new Sustained IP address, it will en= d up in a lot of network resource consumption in the mobility routers whe= re the Sustained IP addresses are anchored as the terminal moves. > >>2 > I am sorry but I disagree with the email example. I categorize it as an= example of an application that will request a Nomadic address since it d= oes not break when the mobile node moves to a new LAN and the source IP a= ddress is changed. It simply restarts the socket and continue with the ne= w source IP address (the user will not even notice this). > =20 > >> The example was given as a benefit when the existing Sustained IP ad= dress is used. You could get some insight from such kind of application n= ot caring much the routing distance even on the Sustained IP address. > =20 > I did not understand the other text regarding resource consumption. I t= hought we agreed that even of a new Sustained IP address is requested upo= n each movement to a new LAN, the effect on IP address allocation is not = significant. Otherwise, my initial comment on applications abusing the ne= twork using your proposed flag, becomes valid again > >>2 > =20 > >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustaine= d IP address is requested upon receiving *new* flag from an application, = as a preference for a source address selection. You need to read our draf= t classifying the categories of IP address request again. > =20 > Besides, I don=E2=80=99t understand what is abused. Delivering its pref= erence cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it in yo= ur default behavior you=E2=80=99re assuming here. In your scenario, a new= app initiated in a new network will be forced to use a newly obtained Su= stained IP address. You see that=3F You totally block the possibility to = be considered by the default source address selection rules defined in R=46= C6724. But in our draft, in case the need of a newly obtained Sustained I= P address is prioritized, the proposed *new* flag can be used by app=E2=80= =99s request, thus it will be selected with priority. > =20 > Can you provide a scenario in which an application will not request to = refresh the Sustained IP address=3F > =20 > > It was mentioned in the former comments. > =20 > =20 > Regards, > /Danny > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > Sent: Monday, March 30, 2015 17:08 > To: Moses, Danny > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: =46W: =5BDMM=5D Answer on raised questions for the proposed AP= I > =20 > Hi Danny, > =20 > Any comments=3F > =20 > Regards, > Seil Jeon > =20 > =20 > =46rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil Jeon > Sent: Thursday, March 26, 2015 8:08 PM > To: dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: =5BDMM=5D Answer on raised questions for the proposed API > =20 > Hi, > =20 > I could attend DMM Thursday meeting via MeetEcho. > I could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions. > =20 > =20 > =46irst, regarding the need of the proposed API (IPV6=5FPRE=46ER=5FSRC=5F= NEW), > =20 > The use of the proposed API is suggested in the SUSTAINED IP address ca= se in the draft. On receiving this API with the SUSTAINED IP address type= at the IP stack, it will try to get a new SUSTAINED IP address if there = is no available in the currently attached access network. So, actual obta= ining of the IP address will be tried one time while attached at a specif= ic access network. Even some applications put this API after, the already= obtained SUSTAINED IP will be used. So, no worries about abuse. > =20 > Second question sounded to me like that this API is not needed because = the host can get a new SUSTAINED IP address, right=3F > If the question is right, I don=E2=80=99t understand what the question = is meant, that is how the host can get a new SUSTAINED IP address=3F > Based on the definition of three types of IP address, an application sh= ould show its requirement with an API among them. If it is the SUSTAINED = IP address, how do we expect the IP stack will try to get a new SUSTAINED= IP address=3F > =20 > Besides, the propsoed API is not used alone but with the three type API= s. =20 > =20 > =20 > =20 > Regards, > =20 > Seil Jeon > =20 > =20 > --------------------------------------------------------------------- > 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. > --------------------------------------------------------------------- > 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. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > dmm mailing list > dmm=40ietf.org (mailto:dmm=40ietf.org) > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 --552bbc4f_51d9c564_e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Seil, Danny=EF=BC=9A

=5Bas an individual contributor= =5D

You can refer to the following two drafts:


Is it the similar idea=3F<= /div>

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D= =886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

<=21--=5Bif gte mso = 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Hi Danny,

 

=46rom your cases specified as follows;<= /o:p>

&nbs= p;

=E2=80=9CI am thi= nking of two places that might require an update:

<=21--=5Bif =21supportLists=5D-->1.       <=21--=5Bendif=5D-->W= hen an application chooses not to specify a source address (but request a= specific type)

<=21--=5Bif =21= supportLists=5D-->2.     &= nbsp; <=21--=5Bendif=5D-->When an application wishes to cho= ose the source address from a provided list.

=E2=80=9C

 

I don=E2=80=99t understand the meaning of the se= cond case. Why should an application wish to choose a source address from= a list=3F What I have talked about was about allowing the default source= address selection rules, which will be determined in the IP stack when a= n application is initiated with the destination address. I think we don=E2= =80=99t need to touch it.

 

The point is an application will totally assign = the default source address selection mechanism based on = only type request but with no preference, or wil= l request with the preference of a new Sustained IP addr= ess as well as type request. In the former case,= if there is one or multiple Sustained IP addresses, the IP stack will tr= y to pick up one. Or the IP stack will try to get a new one. In the latte= r case, the IP stack will consider a newly obtained Sustained IP address = all the time, if the requested preference value is not less than other pr= eferences defined in the default source address selection rules.

 <= /o:p>

The need = of the proposed flag and main criteria to be considered were already cove= red with case studies in the draft.

http://tools.ietf.org/html/dra= ft-sijeon-dmm-use-cases-api-source-00

 

So, for productive discussion, I = would like to suggest that you check our draft again please and bring you= r questions if there is something weird or should be updated with additio= nal cases.

 

 

Best Regards,

 

Seil Jeon

 

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent= : Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject:= RE: =5BDMM=5D Answer on raised questions for the proposed API

 

= You have a good point here.

 

<= p style=3D=22margin: 0px;=22>Now I understand the need for the flag you are proposing =21=21= =21

 

 

We = need to take a better look at R=46C 6724 and figure out if we need to upd= ate it.

 

I am thinking of two place= s that might require an update:

<=21--=5Bif =21supportLists=5D-->1.       <=21--=5Bendif=5D-->When an application chooses not to specify a source address (but request= a specific type)

<=21= --=5Bif =21supportLists=5D-->2.       <=21--=5Bendif=5D-->When an appl= ication wishes to choose the source address from a provided list.

 

When the application indicates the desired= address type, but chooses not to specify the source address (from a list= provided by the IP stack), the stack should allocate a source IP address= according to the address-type requested by the application. In this case= , we should consider adding text to describe the behavior for Sustained I= P addresses. Specifically, if there are several Sustained IP addresses al= located to the mobile host, whether to choose one of them, or to have the= mobile host request a new one from the network (as a result of a mobilit= y event =E2=80=93 for example).

 <= /p>

Wh= en an application wishes to chooses the source address from the available= list (obtained by getaddrinfo()), there are some alternative approaches = we should consider:

<=21= --=5Bif =21supportLists=5D-->1.       <=21--=5Bendif=5D-->Enhance geta= ddrinfo() enabling the application to specify the required address type, = and return the list of source addresses that are of that type (Nomadic, S= ustained, =46ixed or DontCare), or -

<=21--=5Bif =21supportLists=5D-->2.       = <=21--=5Bendif=5D-->Provide the list of addresses with an indication of their type (Nom= adic, Sustained, =46ixed or TypeUnknown) and an indication of whether eac= h address is New (allocated after the last handoff event) or Old (allocat= ed before the last handoff event)

<=21--=5Bif =21supportLists=5D-->3.       <=21--=5Bendif=5D-->Some other approach=E2=80=A6

 

The flag is need here, to enable the application to reque= st a new IP address (if the returned list only contain 'Old' addresses) =21= =21=21

 

I agree that we should = discuss this. How about bringing it to the next 'Mobility Exposure and Selection WT' call=3F

 

Regards,

     = ;           /Danny=

 

=46rom: Seil Jeon =5Bmailto:seiljeon= =40av.it.pt=5D
Sent: Sunday, April 05, 2015 17:08
To= : Moses, Danny
Cc: dm= m=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questi= ons for the proposed API

 

Hi Danny,

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22> 

Meeting is always good, even with you by f-to-f. But i= n the discussion, the main issue is whether we will allow the default sou= rce address selection rules defined in R=46C6724 for selecting a Sustaine= d IP address among several ones or fundamentally block them for a specifi= c reason raised by a DMM need. The latter approach is not reasonable no m= atter how I try to think of.it.

If an applic= ation has the specific preference of a newly obtained Sustained IP addres= s, it uses the proposed API.

 

Regards.

Seil

 

 

 

Hi Seil,

 

By now w= e have been discussing this for quite some time and clearly we did not su= cceed in convincing each other.

I suggest we try again wh= en we have a chance to meet face to face. Meanwhile, let's listen to what= other people have to say on this matter.

 

Regards,

       = ;         /Danny

=  

=46rom: Seil J= eon =5Bmailto:seiljeon=40av.it= .pt=5D
Sent: Sunday, April 05, 2015 01:16
To: Mo= ses, Danny
Cc: dmm=40ietf= .org
Subject: RE: =5BDMM=5D Answer on raised questions for = the proposed API

 

Resent.

 

Seil<= /span>

&nbs= p;

= =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D=
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, = Danny'
Cc: 'dmm=40ietf.or= g'
Subject: RE: =5BDMM=5D Answer on raised questions for th= e proposed API

 

Hi Danny,

 

See the inline please. I marked current replies with =E2=80=9C>= ;>=E2=80=9D and previous replies with =E2=80=9C>=E2=80=9D for you t= o catch them easily.

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22> 

Regards,

Seil

 

=

 <= /p>

=46rom: Moses, Danny =5Bmailto:danny.moses= =40intel.com=5D
Sent: Thursday, A= pril 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised qu= estions for the proposed API

 

Hi Seil,

 

Please see my replies (surrounded by  >>2) to yours.

 

= Regards,

 &nbs= p;            = ;  /Danny

 

=46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Tuesday, March 31, 2015 15:23
T= o: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed A= PI

&n= bsp;

Hi Danny,

=  

Se= e the inline please.

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22> 

 

Seil Jeon

 

 

= =46rom: Moses, Danny =5Bmailto:danny.moses=40= intel.com=5D
Sent: Monday, March = 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions= for the proposed API

 

Hi Seil,

 

As to the potential of abuse:

Yes, I see your point and = you are correct. If the IP stack will not request a sustained IP address = more than once after each movement to a new LAN (with a different prefix)= , than there will be no abuse.

 

> Yes, it=E2=80=99s true. Thanks for c= orrection.

 

As to the second comment, please let me ela= borate:

One potential implementation of the IP stack in t= he host, can be to request a Nomadic IP address and a  Sustained IP = address whenever connecting to a network, and whenever moving to a new LA= N, regardless if there are any applications requesting any addresses. Thi= s way, whenever an application is launched and requests either a Nomadic = or Sustained IP address, the stack can provide one without having to issu= e a request to the network. In this case, there is no need for this flag = from the application.

=  

> Decision of which type of IP address by defau= lt will be depending on the IP pool management policy by operators. You c= ase may correspond to one of them. What if only the Nomadic IP address is= basically allocated upon a network attachment=3F That is, a lot of appli= cations require mere Internet connectivity without session continuity sup= port. So, the Sustained IP address will be requested on demand, and the p= roposed flag will be used to get a new Sustained IP address by expressing= the explicit request by an application.

 

>>2

As I mentioned at the beginning of the description =E2=80=93 = it is a description of one alternative. I am not assuming it is the only = scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host pre-allocates= both Nomadic and Sustained IP addresses upon attachment=E2=80=A6

 

>>= ; As I said, it could be, but not as general one. The proposed API is use= ful through the explicit expression for any potential scenarios.

 <= /o:p>

Yes, we can describe an alternative in which a Nomadic IP addr= ess is pre-allocated upon NW connection (and after every movement to a ne= w LAN) and a Sustained (and/or =46ixed) address is allocated on-demand. E= ven in such a scenario, I do not see any use for this flag =E2=80=93 see = my reply to the second item below=E2=80=A6

>>2

 

>>= ; My answer was already given in following answer in previous email.

 

Another potential implementation of the IP stack in the host is no= t to request IP addresses in advance. In that case, it will issue a reque= st for a Nomadic IP address or a Sustained IP address the first time an a= pplication requests one and use it for subsequent requests as long as it = is not moving to a different LAN. Once it moves, it will again request a = new IP address (Nomadic or Sustained =E2=80=93 according to what is requi= red) after receiving the first request from any application. In this case= as well, there is no need for this flag.

 

> Another application reques= ted just Sustained IP address while the IP stack has already a Sustained = IP address. Why should the IP stack try to get a new one, though the appl= ication indicated simply =E2=80=9CSustained IP address type=E2=80=9D=3F Y= ou case took a step towards a solution where you want to draw. I don=E2=80= =99t expect the action is generic when a Sustained IP address type is req= uested.

Besides, you a= ssumption on IP address allocation seems not valid. A mobile host would g= et an IP address whatever the allocated IP address type is when it attach= es at a network, regardless of an application=E2=80=99s IP address reques= t.

<= o:p> 

>>2

Looks like I did not express myself well enough (and did not full= y understand your reply). Let me list some events that might help clarify= =E2=80=A6

 

Initial state: Mobile node is connected to a network; no Sustained= IP address is allocated. The IP stack sets a flag (SustainedIPAddressNee= ded) indicating that if an application requests a Sustained IP address, i= t will have to request one from the network.

 

Event1: An application that r= equires a Sustained IP address is launched.

APP action: App requests a Susta= ined IP address from the IP stack using the proposed new API.<= /span>

IP stack action= : Since SustainedIPAddressNeeded is set, request one from the network.

Networ= k action: Assigned a Sustained IP address to the mobile node.<= /span>

IP stack action= : (1) Mark the new Sustained IP address as the one to be associated to su= bsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API ac= tion and associate the marked Sustained IP address with that port (app)

=  

Ev= ent2: A new application that also required a Sustained IP address is laun= ched

App action: App requests a Sustained IP address from the IP stack using = the proposed new API

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22>IP Stack action: Since SustainedIPAddressNeeded  is= not set, complete the API action and associate the marked Sustained IP a= ddress with that port (app)

 

Event3: The mobile node moves to a new LAN

IP Stac= k action: Set a flag indicating that the currently available Sustained IP= address is not optimized

 

Event4: An application that requires a Sustaine= d IP address is launched.

APP action: App requests a Sustained IP address fr= om the IP stack using the proposed new API.

IP stack action: Since SustainedI= PAddressNeeded is set, request one from the network.

Network action: Assigned= a Sustained IP address to the mobile node.

IP stack action: (1) Mark the new= Sustained IP address as the one to be associated to subsequent apps; (2)= Reset SustainedIPAddressNeeded; (3)Complete the API action and associate= the marked Sustained IP address with that port (app)

 

Note that the behavi= or of the IP stack in Event4 is exactly like the one in Event1.

 

I belie= ve that this event is the one we have different of opinions: I think that= the default behavior of the IP stack is to request a new Sustained IP ad= dress since it moved to a new LAN, and you think that it should do so onl= y if the application specifically requests a new Sustained IP address via= the flag you are proposing.

>>2

 

>> You can see my answer at the lowest =E2=80=9C= >>=E2=80=9D in this mail.

 <= /p>

As= a matter of fact, if such a flag is defined, I cannot think of an exampl= e where it will not be used. It seems to me that applications will always= request a refreshed Sustained IP address (when requesting a Sustained IP= address). If this is correct, the flag is redundant.

 

> Some applicat= ions, e.g. email, that are not relatively restricted from optimal routing= would consider a Sustained IP address without issuing the new flag. More= applications based on such network characteristic can be thought more th= an expected.

And such = use of existing Sustained IP address is not extraordinary, since IP addre= ss is a resource, even in the consideration of IPv6 deployment. If as man= y as applications require new Sustained IP address, it will end up in a l= ot of network resource consumption in the mobility routers where the Sust= ained IP addresses are anchored as the terminal moves.<= /p>

&g= t;>2

I am sorry but I disagree with the email example.= I categorize it as an example of an application that will request a Noma= dic address since it does not break when the mobile node moves to a new L= AN and the source IP address is changed. It simply restarts the socket an= d continue with the new source IP address (the user will not even notice = this).

 

>> The example was given as a benefit when the existing Susta= ined IP address is used. You could get some insight from such kind of app= lication not caring much the routing distance even on the Sustained IP ad= dress.

 

I did not understand the other text regarding res= ource consumption. I thought we agreed that even of a new Sustained IP ad= dress is requested upon each movement to a new LAN, the effect on IP addr= ess allocation is not significant. Otherwise, my initial comment on appli= cations abusing the network using your proposed flag, becomes valid again=

>>2

 

>> No, our draft didn=E2=80=99t say so. Our idea is that a = new Sustained IP address is requested upon receiving *new* flag from an a= pplication, as a preference for a source address selection. You need to r= ead our draft classifying the categories of IP address request again.

 <= /p>

Besides, I don=E2=80=99t understand what= is abused. Delivering its preference cannot be abuse. Regarding =E2=80=9C= abuse=E2=80=9D, I see it in your default behavior you=E2=80=99re assuming= here. In your scenario, a new app initiated in a new network will be for= ced to use a newly obtained Sustained IP address. You see that=3F You tot= ally block the possibility to be considered by the default source address= selection rules defined in R=46C6724. But in our draft, in case the need= of a newly obtained Sustained IP address is prioritized, the proposed *n= ew* flag can be used by app=E2=80=99s request, thus it will be selected w= ith priority.

 

Can you provide a scenario in which an app= lication will not request to refresh the Sustained IP address=3F

 <= /o:p>

> It was mentioned in th= e former comments.

 

=  

Regards,

    &nb= sp;           /Danny

= =46rom: Seil Jeon =5Bmailto:= seiljeon=40av.it.pt=5D
Sent: Mond= ay, March 30, 2015 17:08
To: Moses, Danny
Cc: = dmm=40ietf.org
Subject: =46W: =5BDMM=5D Answer on r= aised questions for the proposed API

 

Hi Danny,

 

Any comments=3F

 

<= p style=3D=22margin: 0px;=22>Regards,=

Seil Jeon<= /span>

 

 

=46rom:= dmm =5Bmailto:dmm-bounces=40ietf.org=5D On B= ehalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PMTo: dmm=40ietf.org
Subject: =5BDMM=5D= Answer on raised questions for the proposed API

 

Hi,

 

I could attend DM= M Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someone. H= ere goes answers to the raised questions.

 

 

=46irst, re= garding the need of the proposed API (IPV6=5FPRE=46ER=5FSRC=5FNEW),<= /o:p>

 

The use of the proposed API is suggested i= n the SUSTAINED IP address case in the draft. On receiving this API with = the SUSTAINED IP address type at the IP stack, it will try to get a new S= USTAINED IP address if there is no available in the currently attached ac= cess network. So, actual obtaining of the IP address will be tried one ti= me while attached at a specific access network. Even some applications pu= t this API after, the already obtained SUSTAINED IP will be used. So, no = worries about abuse.

<= span style=3D=22font-family:"Arial","sans-serif"=22><= o:p> 

Second question s= ounded to me like that this API is not needed because the host can get a = new SUSTAINED IP address, right=3F

If the question is right, I don=E2=80=99t understand what th= e question is meant, that is how the host can get a new SUSTAINED IP addr= ess=3F

Based on the defi= nition of three types of IP address, an application should show its requi= rement with an API among them. If it is the SUSTAINED IP address, how do = we expect the IP stack will try to get a new SUSTAINED IP address=3F=

 

Besides, the propsoed API is not used alo= ne but with the three type APIs.

 

 

 <= /span>

Regards,

 

Seil Jeon

=  

 

<= p>---------------------------------------------------------------------A member of the Intel Corporation group of companies

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

-----= ----------------------------------------------------------------
A mem= ber of the Intel Corporation group of companies

This e-m= ail and any attachments may contain confidential material for
the sole= use of the intended recipient(s). Any review or distribution
by other= s is strictly prohibited. If you are not the intended
recipient, pleas= e 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 st= rictly prohibited. If you are not the intended
recipient, please conta= ct the sender and delete all copies.

-------------------= --------------------------------------------------
A member of the Int= el Corporation group of companies

This e-mail and any at= tachments may contain confidential material for
the sole use of the in= tended 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.

=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmm m= ailing list
=20 =20 =20 =20 =20

--552bbc4f_51d9c564_e7-- From nobody Mon Apr 13 06:22:01 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2791A008A for ; Mon, 13 Apr 2015 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8BK-j_tbKJir for ; Mon, 13 Apr 2015 06:21:52 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 51F991A009C for ; Mon, 13 Apr 2015 06:21:50 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 13 Apr 2015 06:21:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,569,1422950400"; d="scan'208,217";a="679309304" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 13 Apr 2015 06:21:46 -0700 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 13 Apr 2015 14:21:45 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by hasmsx109.ger.corp.intel.com ([10.184.198.21]) with mapi id 14.03.0224.002; Mon, 13 Apr 2015 16:21:43 +0300 From: "Moses, Danny" To: Dapeng Liu , Seil Jeon Thread-Topic: =?utf-8?B?5Zue5aSN77yaIFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZv?= =?utf-8?Q?r_the_proposed_API?= Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgIJAtYDAlqa+uYCqJZpkgDQIjNOAPZdtnGbTMJ10JuEMu4wyPeW/QD/9OoEcIAWmwOAgAD4wQD//8YOwA== Date: Mon, 13 Apr 2015 13:21:43 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.11] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490DAD6HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9u?= =?utf-8?q?s_for_the_proposed_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:22:00 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAD6HASMSX106gercor_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V2hhdCBpcyBzaW1wbGVyLiBDYW4geW91IGJlIG1vcmUgc3BlY2lmaWM/IFdoYXQgYXJlIHlvdSBj b21wYXJpbmc/DQoNClRoYW5rcywNCiAgICAgICAgICAgICAgICAvRGFubnkNCg0KRnJvbTogRGFw ZW5nIExpdSBbbWFpbHRvOm1heHBhc3Npb25AZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJp bCAxMywgMjAxNSAxNTo1NA0KVG86IFNlaWwgSmVvbg0KQ2M6IE1vc2VzLCBEYW5ueTsgZG1tQGll dGYub3JnDQpTdWJqZWN0OiDlm57lpI3vvJogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlv bnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkNCg0KSGVsbG8gU2VpbCwgRGFubnnvvJoNCg0KW2FzIGFu IGluZGl2aWR1YWwgY29udHJpYnV0b3JdDQoNCllvdSBjYW4gcmVmZXIgdG8gdGhlIGZvbGxvd2lu ZyB0d28gZHJhZnRzOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWRt bS1hZGRyZXNzLXNlbGVjdGlvbi0wMQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGl1LWRtbS1tb2JpbGl0eS1hcGktMDINCg0KSXMgaXQgdGhlIHNpbWlsYXIgaWRlYT8NCg0KLS0N CkRhcGVuZyBMaXUNCg0KDQrlnKggMjAxNeW5tDTmnIgxM+aXpSDmmJ/mnJ/kuIDvvIzkuIrljYg2 OjAz77yMU2VpbCBKZW9uIOWGmemBk++8mg0KDQpIaSBEYW5ueSwNCg0KDQoNCkZyb20geW91ciBj YXNlcyBzcGVjaWZpZWQgYXMgZm9sbG93czsNCg0KDQoNCuKAnEkgYW0gdGhpbmtpbmcgb2YgdHdv IHBsYWNlcyB0aGF0IG1pZ2h0IHJlcXVpcmUgYW4gdXBkYXRlOg0KDQpXaGVuIGFuIGFwcGxpY2F0 aW9uIGNob29zZXMgbm90IHRvIHNwZWNpZnkgYSBzb3VyY2UgYWRkcmVzcyAoYnV0IHJlcXVlc3Qg YSBzcGVjaWZpYyB0eXBlKQ0KDQpXaGVuIGFuIGFwcGxpY2F0aW9uIHdpc2hlcyB0byBjaG9vc2Ug dGhlIHNvdXJjZSBhZGRyZXNzIGZyb20gYSBwcm92aWRlZCBsaXN0Lg0KDQrigJwNCg0KDQoNCkkg ZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBzZWNvbmQgY2FzZS4gV2h5IHNo b3VsZCBhbiBhcHBsaWNhdGlvbiB3aXNoIHRvIGNob29zZSBhIHNvdXJjZSBhZGRyZXNzIGZyb20g YSBsaXN0PyBXaGF0IEkgaGF2ZSB0YWxrZWQgYWJvdXQgd2FzIGFib3V0IGFsbG93aW5nIHRoZSBk ZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBydWxlcywgd2hpY2ggd2lsbCBiZSBkZXRl cm1pbmVkIGluIHRoZSBJUCBzdGFjayB3aGVuIGFuIGFwcGxpY2F0aW9uIGlzIGluaXRpYXRlZCB3 aXRoIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLiBJIHRoaW5rIHdlIGRvbuKAmXQgbmVlZCB0byB0 b3VjaCBpdC4NCg0KDQoNClRoZSBwb2ludCBpcyBhbiBhcHBsaWNhdGlvbiB3aWxsIHRvdGFsbHkg YXNzaWduIHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBtZWNoYW5pc20gYmFz ZWQgb24gb25seSB0eXBlIHJlcXVlc3QgYnV0IHdpdGggbm8gcHJlZmVyZW5jZSwgb3Igd2lsbCBy ZXF1ZXN0IHdpdGggdGhlIHByZWZlcmVuY2Ugb2YgYSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3Mg YXMgd2VsbCBhcyB0eXBlIHJlcXVlc3QuIEluIHRoZSBmb3JtZXIgY2FzZSwgaWYgdGhlcmUgaXMg b25lIG9yIG11bHRpcGxlIFN1c3RhaW5lZCBJUCBhZGRyZXNzZXMsIHRoZSBJUCBzdGFjayB3aWxs IHRyeSB0byBwaWNrIHVwIG9uZS4gT3IgdGhlIElQIHN0YWNrIHdpbGwgdHJ5IHRvIGdldCBhIG5l dyBvbmUuIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIElQIHN0YWNrIHdpbGwgY29uc2lkZXIgYSBu ZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcyBhbGwgdGhlIHRpbWUsIGlmIHRoZSBy ZXF1ZXN0ZWQgcHJlZmVyZW5jZSB2YWx1ZSBpcyBub3QgbGVzcyB0aGFuIG90aGVyIHByZWZlcmVu Y2VzIGRlZmluZWQgaW4gdGhlIGRlZmF1bHQgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uIHJ1bGVz Lg0KDQoNCg0KVGhlIG5lZWQgb2YgdGhlIHByb3Bvc2VkIGZsYWcgYW5kIG1haW4gY3JpdGVyaWEg dG8gYmUgY29uc2lkZXJlZCB3ZXJlIGFscmVhZHkgY292ZXJlZCB3aXRoIGNhc2Ugc3R1ZGllcyBp biB0aGUgZHJhZnQuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpamVvbi1k bW0tdXNlLWNhc2VzLWFwaS1zb3VyY2UtMDANCg0KDQoNClNvLCBmb3IgcHJvZHVjdGl2ZSBkaXNj dXNzaW9uLCBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHlvdSBjaGVjayBvdXIgZHJhZnQg YWdhaW4gcGxlYXNlIGFuZCBicmluZyB5b3VyIHF1ZXN0aW9ucyBpZiB0aGVyZSBpcyBzb21ldGhp bmcgd2VpcmQgb3Igc2hvdWxkIGJlIHVwZGF0ZWQgd2l0aCBhZGRpdGlvbmFsIGNhc2VzLg0KDQoN Cg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQoNClNlaWwgSmVvbg0KDQoNCg0KRnJvbTogTW9zZXMs IERhbm55IFttYWlsdG86ZGFubnkubW9zZXNAaW50ZWwuY29tXQ0KU2VudDogU3VuZGF5LCBBcHJp bCAxMiwgMjAxNSAxOjQ5IFBNDQpUbzogU2VpbCBKZW9uDQpDYzogZG1tQGlldGYub3JnPG1haWx0 bzpkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVz dGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkNCg0KDQoNCllvdSBoYXZlIGEgZ29vZCBwb2ludCBo ZXJlLg0KDQoNCg0KTm93IEkgdW5kZXJzdGFuZCB0aGUgbmVlZCBmb3IgdGhlIGZsYWcgeW91IGFy ZSBwcm9wb3NpbmcgISEhDQoNCg0KDQoNCg0KV2UgbmVlZCB0byB0YWtlIGEgYmV0dGVyIGxvb2sg YXQgUkZDIDY3MjQgYW5kIGZpZ3VyZSBvdXQgaWYgd2UgbmVlZCB0byB1cGRhdGUgaXQuDQoNCg0K DQpJIGFtIHRoaW5raW5nIG9mIHR3byBwbGFjZXMgdGhhdCBtaWdodCByZXF1aXJlIGFuIHVwZGF0 ZToNCg0KV2hlbiBhbiBhcHBsaWNhdGlvbiBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5IGEgc291cmNl IGFkZHJlc3MgKGJ1dCByZXF1ZXN0IGEgc3BlY2lmaWMgdHlwZSkNCg0KV2hlbiBhbiBhcHBsaWNh dGlvbiB3aXNoZXMgdG8gY2hvb3NlIHRoZSBzb3VyY2UgYWRkcmVzcyBmcm9tIGEgcHJvdmlkZWQg bGlzdC4NCg0KDQoNCldoZW4gdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlcyB0aGUgZGVzaXJlZCBh ZGRyZXNzIHR5cGUsIGJ1dCBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5IHRoZSBzb3VyY2UgYWRkcmVz cyAoZnJvbSBhIGxpc3QgcHJvdmlkZWQgYnkgdGhlIElQIHN0YWNrKSwgdGhlIHN0YWNrIHNob3Vs ZCBhbGxvY2F0ZSBhIHNvdXJjZSBJUCBhZGRyZXNzIGFjY29yZGluZyB0byB0aGUgYWRkcmVzcy10 eXBlIHJlcXVlc3RlZCBieSB0aGUgYXBwbGljYXRpb24uIEluIHRoaXMgY2FzZSwgd2Ugc2hvdWxk IGNvbnNpZGVyIGFkZGluZyB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBiZWhhdmlvciBmb3IgU3VzdGFp bmVkIElQIGFkZHJlc3Nlcy4gU3BlY2lmaWNhbGx5LCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBTdXN0 YWluZWQgSVAgYWRkcmVzc2VzIGFsbG9jYXRlZCB0byB0aGUgbW9iaWxlIGhvc3QsIHdoZXRoZXIg dG8gY2hvb3NlIG9uZSBvZiB0aGVtLCBvciB0byBoYXZlIHRoZSBtb2JpbGUgaG9zdCByZXF1ZXN0 IGEgbmV3IG9uZSBmcm9tIHRoZSBuZXR3b3JrIChhcyBhIHJlc3VsdCBvZiBhIG1vYmlsaXR5IGV2 ZW50IOKAkyBmb3IgZXhhbXBsZSkuDQoNCg0KDQpXaGVuIGFuIGFwcGxpY2F0aW9uIHdpc2hlcyB0 byBjaG9vc2VzIHRoZSBzb3VyY2UgYWRkcmVzcyBmcm9tIHRoZSBhdmFpbGFibGUgbGlzdCAob2J0 YWluZWQgYnkgZ2V0YWRkcmluZm8oKSksIHRoZXJlIGFyZSBzb21lIGFsdGVybmF0aXZlIGFwcHJv YWNoZXMgd2Ugc2hvdWxkIGNvbnNpZGVyOg0KDQpFbmhhbmNlIGdldGFkZHJpbmZvKCkgZW5hYmxp bmcgdGhlIGFwcGxpY2F0aW9uIHRvIHNwZWNpZnkgdGhlIHJlcXVpcmVkIGFkZHJlc3MgdHlwZSwg YW5kIHJldHVybiB0aGUgbGlzdCBvZiBzb3VyY2UgYWRkcmVzc2VzIHRoYXQgYXJlIG9mIHRoYXQg dHlwZSAoTm9tYWRpYywgU3VzdGFpbmVkLCBGaXhlZCBvciBEb250Q2FyZSksIG9yIC0NCg0KUHJv dmlkZSB0aGUgbGlzdCBvZiBhZGRyZXNzZXMgd2l0aCBhbiBpbmRpY2F0aW9uIG9mIHRoZWlyIHR5 cGUgKE5vbWFkaWMsIFN1c3RhaW5lZCwgRml4ZWQgb3IgVHlwZVVua25vd24pIGFuZCBhbiBpbmRp Y2F0aW9uIG9mIHdoZXRoZXIgZWFjaCBhZGRyZXNzIGlzIE5ldyAoYWxsb2NhdGVkIGFmdGVyIHRo ZSBsYXN0IGhhbmRvZmYgZXZlbnQpIG9yIE9sZCAoYWxsb2NhdGVkIGJlZm9yZSB0aGUgbGFzdCBo YW5kb2ZmIGV2ZW50KQ0KDQpTb21lIG90aGVyIGFwcHJvYWNo4oCmDQoNCg0KDQpUaGUgZmxhZyBp cyBuZWVkIGhlcmUsIHRvIGVuYWJsZSB0aGUgYXBwbGljYXRpb24gdG8gcmVxdWVzdCBhIG5ldyBJ UCBhZGRyZXNzIChpZiB0aGUgcmV0dXJuZWQgbGlzdCBvbmx5IGNvbnRhaW4gJ09sZCcgYWRkcmVz c2VzKSAhISENCg0KDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgZGlzY3VzcyB0aGlzLiBIb3cg YWJvdXQgYnJpbmdpbmcgaXQgdG8gdGhlIG5leHQgJ01vYmlsaXR5IEV4cG9zdXJlIGFuZCBTZWxl Y3Rpb24gV1QnIGNhbGw/DQoNCg0KDQpSZWdhcmRzLA0KDQogICAgICAgICAgICAgICAgL0Rhbm55 DQoNCg0KDQpGcm9tOiBTZWlsIEplb24gW21haWx0bzpzZWlsamVvbkBhdi5pdC5wdF0NClNlbnQ6 IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTc6MDgNClRvOiBNb3NlcywgRGFubnkNCkNjOiBkbW1A aWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRE1NXSBBbnN3ZXIg b24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkgRGFubnks DQoNCg0KDQpNZWV0aW5nIGlzIGFsd2F5cyBnb29kLCBldmVuIHdpdGggeW91IGJ5IGYtdG8tZi4g QnV0IGluIHRoZSBkaXNjdXNzaW9uLCB0aGUgbWFpbiBpc3N1ZSBpcyB3aGV0aGVyIHdlIHdpbGwg YWxsb3cgdGhlIGRlZmF1bHQgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uIHJ1bGVzIGRlZmluZWQg aW4gUkZDNjcyNCBmb3Igc2VsZWN0aW5nIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgYW1vbmcgc2V2 ZXJhbCBvbmVzIG9yIGZ1bmRhbWVudGFsbHkgYmxvY2sgdGhlbSBmb3IgYSBzcGVjaWZpYyByZWFz b24gcmFpc2VkIGJ5IGEgRE1NIG5lZWQuIFRoZSBsYXR0ZXIgYXBwcm9hY2ggaXMgbm90IHJlYXNv bmFibGUgbm8gbWF0dGVyIGhvdyBJIHRyeSB0byB0aGluayBvZi5pdDxodHRwOi8vb2YuaXQ+Lg0K DQpJZiBhbiBhcHBsaWNhdGlvbiBoYXMgdGhlIHNwZWNpZmljIHByZWZlcmVuY2Ugb2YgYSBuZXds eSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgdXNlcyB0aGUgcHJvcG9zZWQgQVBJ Lg0KDQoNCg0KUmVnYXJkcy4NCg0KU2VpbA0KDQoNCg0KDQoNCkZyb206IE1vc2VzLCBEYW5ueSBb bWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbV0NClNlbnQ6IFN1bmRheSwgQXByaWwgMDUsIDIw MTUgMTI6MjMgUE0NClRvOiBTZWlsIEplb24NCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBm b3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkgU2VpbCwNCg0KDQoNCkJ5IG5vdyB3ZSBoYXZl IGJlZW4gZGlzY3Vzc2luZyB0aGlzIGZvciBxdWl0ZSBzb21lIHRpbWUgYW5kIGNsZWFybHkgd2Ug ZGlkIG5vdCBzdWNjZWVkIGluIGNvbnZpbmNpbmcgZWFjaCBvdGhlci4NCg0KSSBzdWdnZXN0IHdl IHRyeSBhZ2FpbiB3aGVuIHdlIGhhdmUgYSBjaGFuY2UgdG8gbWVldCBmYWNlIHRvIGZhY2UuIE1l YW53aGlsZSwgbGV0J3MgbGlzdGVuIHRvIHdoYXQgb3RoZXIgcGVvcGxlIGhhdmUgdG8gc2F5IG9u IHRoaXMgbWF0dGVyLg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICAgICAgICAgICAgIC9EYW5ueQ0K DQoNCg0KRnJvbTogU2VpbCBKZW9uIFttYWlsdG86c2VpbGplb25AYXYuaXQucHRdDQpTZW50OiBT dW5kYXksIEFwcmlsIDA1LCAyMDE1IDAxOjE2DQpUbzogTW9zZXMsIERhbm55DQpDYzogZG1tQGll dGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RNTV0gQW5zd2VyIG9u IHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkNCg0KDQoNClJlc2VudC4NCg0K DQoNClNlaWwNCg0KDQoNCkZyb206IFNlaWwgSmVvbiBbbWFpbHRvOnNlaWxqZW9uQGF2Lml0LnB0 XQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA0LCAyMDE1IDE6MzUgUE0NClRvOiAnTW9zZXMsIERh bm55Jw0KQ2M6ICdkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4nDQpTdWJqZWN0OiBS RTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkN Cg0KDQoNCkhpIERhbm55LA0KDQoNCg0KU2VlIHRoZSBpbmxpbmUgcGxlYXNlLiBJIG1hcmtlZCBj dXJyZW50IHJlcGxpZXMgd2l0aCDigJw+PuKAnSBhbmQgcHJldmlvdXMgcmVwbGllcyB3aXRoIOKA nD7igJ0gZm9yIHlvdSB0byBjYXRjaCB0aGVtIGVhc2lseS4NCg0KDQoNClJlZ2FyZHMsDQoNClNl aWwNCg0KDQoNCg0KDQpGcm9tOiBNb3NlcywgRGFubnkgW21haWx0bzpkYW5ueS5tb3Nlc0BpbnRl bC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDIsIDIwMTUgMjoxNiBQTQ0KVG86IFNlaWwg SmVvbg0KQ2M6IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJDQoN Cg0KDQpIaSBTZWlsLA0KDQoNCg0KUGxlYXNlIHNlZSBteSByZXBsaWVzIChzdXJyb3VuZGVkIGJ5 ICA+PjIpIHRvIHlvdXJzLg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICAgICAgICAgICAgIC9EYW5u eQ0KDQoNCg0KRnJvbTogU2VpbCBKZW9uIFttYWlsdG86c2VpbGplb25AYXYuaXQucHRdDQpTZW50 OiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAxNSAxNToyMw0KVG86IE1vc2VzLCBEYW5ueQ0KQ2M6IGRt bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtETU1dIEFuc3dl ciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJDQoNCg0KDQpIaSBEYW5u eSwNCg0KDQoNClNlZSB0aGUgaW5saW5lIHBsZWFzZS4NCg0KDQoNCg0KDQpTZWlsIEplb24NCg0K DQoNCg0KDQpGcm9tOiBNb3NlcywgRGFubnkgW21haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb21d DQpTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDQ6NDQgUE0NClRvOiBTZWlsIEplb24NCkNj OiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRE1NXSBB bnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkg U2VpbCwNCg0KDQoNCkFzIHRvIHRoZSBwb3RlbnRpYWwgb2YgYWJ1c2U6DQoNClllcywgSSBzZWUg eW91ciBwb2ludCBhbmQgeW91IGFyZSBjb3JyZWN0LiBJZiB0aGUgSVAgc3RhY2sgd2lsbCBub3Qg cmVxdWVzdCBhIHN1c3RhaW5lZCBJUCBhZGRyZXNzIG1vcmUgdGhhbiBvbmNlIGFmdGVyIGVhY2gg bW92ZW1lbnQgdG8gYSBuZXcgTEFOICh3aXRoIGEgZGlmZmVyZW50IHByZWZpeCksIHRoYW4gdGhl cmUgd2lsbCBiZSBubyBhYnVzZS4NCg0KDQoNCj4gWWVzLCBpdOKAmXMgdHJ1ZS4gVGhhbmtzIGZv ciBjb3JyZWN0aW9uLg0KDQoNCg0KQXMgdG8gdGhlIHNlY29uZCBjb21tZW50LCBwbGVhc2UgbGV0 IG1lIGVsYWJvcmF0ZToNCg0KT25lIHBvdGVudGlhbCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgSVAg c3RhY2sgaW4gdGhlIGhvc3QsIGNhbiBiZSB0byByZXF1ZXN0IGEgTm9tYWRpYyBJUCBhZGRyZXNz IGFuZCBhICBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aGVuZXZlciBjb25uZWN0aW5nIHRvIGEgbmV0 d29yaywgYW5kIHdoZW5ldmVyIG1vdmluZyB0byBhIG5ldyBMQU4sIHJlZ2FyZGxlc3MgaWYgdGhl cmUgYXJlIGFueSBhcHBsaWNhdGlvbnMgcmVxdWVzdGluZyBhbnkgYWRkcmVzc2VzLiBUaGlzIHdh eSwgd2hlbmV2ZXIgYW4gYXBwbGljYXRpb24gaXMgbGF1bmNoZWQgYW5kIHJlcXVlc3RzIGVpdGhl ciBhIE5vbWFkaWMgb3IgU3VzdGFpbmVkIElQIGFkZHJlc3MsIHRoZSBzdGFjayBjYW4gcHJvdmlk ZSBvbmUgd2l0aG91dCBoYXZpbmcgdG8gaXNzdWUgYSByZXF1ZXN0IHRvIHRoZSBuZXR3b3JrLiBJ biB0aGlzIGNhc2UsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgZmxhZyBmcm9tIHRoZSBhcHBs aWNhdGlvbi4NCg0KDQoNCj4gRGVjaXNpb24gb2Ygd2hpY2ggdHlwZSBvZiBJUCBhZGRyZXNzIGJ5 IGRlZmF1bHQgd2lsbCBiZSBkZXBlbmRpbmcgb24gdGhlIElQIHBvb2wgbWFuYWdlbWVudCBwb2xp Y3kgYnkgb3BlcmF0b3JzLiBZb3UgY2FzZSBtYXkgY29ycmVzcG9uZCB0byBvbmUgb2YgdGhlbS4g V2hhdCBpZiBvbmx5IHRoZSBOb21hZGljIElQIGFkZHJlc3MgaXMgYmFzaWNhbGx5IGFsbG9jYXRl ZCB1cG9uIGEgbmV0d29yayBhdHRhY2htZW50PyBUaGF0IGlzLCBhIGxvdCBvZiBhcHBsaWNhdGlv bnMgcmVxdWlyZSBtZXJlIEludGVybmV0IGNvbm5lY3Rpdml0eSB3aXRob3V0IHNlc3Npb24gY29u dGludWl0eSBzdXBwb3J0LiBTbywgdGhlIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHdpbGwgYmUgcmVx dWVzdGVkIG9uIGRlbWFuZCwgYW5kIHRoZSBwcm9wb3NlZCBmbGFnIHdpbGwgYmUgdXNlZCB0byBn ZXQgYSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3MgYnkgZXhwcmVzc2luZyB0aGUgZXhwbGljaXQg cmVxdWVzdCBieSBhbiBhcHBsaWNhdGlvbi4NCg0KDQoNCj4+Mg0KDQpBcyBJIG1lbnRpb25lZCBh dCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBkZXNjcmlwdGlvbiDigJMgaXQgaXMgYSBkZXNjcmlwdGlv biBvZiBvbmUgYWx0ZXJuYXRpdmUuIEkgYW0gbm90IGFzc3VtaW5nIGl0IGlzIHRoZSBvbmx5IHNj ZW5hcmlvLg0KDQpZZXMsIEkgYWdyZWUgdGhhdCBtYW55IGFwcHMgcmVxdWlyZSBvbmx5IE5vbWFk aWMgSVAgYWRkcmVzc2VzLCBidXQgaW4gdGhpcyBleGFtcGxlLCB0aGUgSVAgc3RhY2sgaW4gdGhl IGhvc3QgcHJlLWFsbG9jYXRlcyBib3RoIE5vbWFkaWMgYW5kIFN1c3RhaW5lZCBJUCBhZGRyZXNz ZXMgdXBvbiBhdHRhY2htZW504oCmDQoNCg0KDQo+PiBBcyBJIHNhaWQsIGl0IGNvdWxkIGJlLCBi dXQgbm90IGFzIGdlbmVyYWwgb25lLiBUaGUgcHJvcG9zZWQgQVBJIGlzIHVzZWZ1bCB0aHJvdWdo IHRoZSBleHBsaWNpdCBleHByZXNzaW9uIGZvciBhbnkgcG90ZW50aWFsIHNjZW5hcmlvcy4NCg0K DQoNClllcywgd2UgY2FuIGRlc2NyaWJlIGFuIGFsdGVybmF0aXZlIGluIHdoaWNoIGEgTm9tYWRp YyBJUCBhZGRyZXNzIGlzIHByZS1hbGxvY2F0ZWQgdXBvbiBOVyBjb25uZWN0aW9uIChhbmQgYWZ0 ZXIgZXZlcnkgbW92ZW1lbnQgdG8gYSBuZXcgTEFOKSBhbmQgYSBTdXN0YWluZWQgKGFuZC9vciBG aXhlZCkgYWRkcmVzcyBpcyBhbGxvY2F0ZWQgb24tZGVtYW5kLiBFdmVuIGluIHN1Y2ggYSBzY2Vu YXJpbywgSSBkbyBub3Qgc2VlIGFueSB1c2UgZm9yIHRoaXMgZmxhZyDigJMgc2VlIG15IHJlcGx5 IHRvIHRoZSBzZWNvbmQgaXRlbSBiZWxvd+KApg0KDQo+PjINCg0KDQoNCj4+IE15IGFuc3dlciB3 YXMgYWxyZWFkeSBnaXZlbiBpbiBmb2xsb3dpbmcgYW5zd2VyIGluIHByZXZpb3VzIGVtYWlsLg0K DQoNCg0KQW5vdGhlciBwb3RlbnRpYWwgaW1wbGVtZW50YXRpb24gb2YgdGhlIElQIHN0YWNrIGlu IHRoZSBob3N0IGlzIG5vdCB0byByZXF1ZXN0IElQIGFkZHJlc3NlcyBpbiBhZHZhbmNlLiBJbiB0 aGF0IGNhc2UsIGl0IHdpbGwgaXNzdWUgYSByZXF1ZXN0IGZvciBhIE5vbWFkaWMgSVAgYWRkcmVz cyBvciBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHRoZSBmaXJzdCB0aW1lIGFuIGFwcGxpY2F0aW9u IHJlcXVlc3RzIG9uZSBhbmQgdXNlIGl0IGZvciBzdWJzZXF1ZW50IHJlcXVlc3RzIGFzIGxvbmcg YXMgaXQgaXMgbm90IG1vdmluZyB0byBhIGRpZmZlcmVudCBMQU4uIE9uY2UgaXQgbW92ZXMsIGl0 IHdpbGwgYWdhaW4gcmVxdWVzdCBhIG5ldyBJUCBhZGRyZXNzIChOb21hZGljIG9yIFN1c3RhaW5l ZCDigJMgYWNjb3JkaW5nIHRvIHdoYXQgaXMgcmVxdWlyZWQpIGFmdGVyIHJlY2VpdmluZyB0aGUg Zmlyc3QgcmVxdWVzdCBmcm9tIGFueSBhcHBsaWNhdGlvbi4gSW4gdGhpcyBjYXNlIGFzIHdlbGws IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgZmxhZy4NCg0KDQoNCj4gQW5vdGhlciBhcHBsaWNh dGlvbiByZXF1ZXN0ZWQganVzdCBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aGlsZSB0aGUgSVAgc3Rh Y2sgaGFzIGFscmVhZHkgYSBTdXN0YWluZWQgSVAgYWRkcmVzcy4gV2h5IHNob3VsZCB0aGUgSVAg c3RhY2sgdHJ5IHRvIGdldCBhIG5ldyBvbmUsIHRob3VnaCB0aGUgYXBwbGljYXRpb24gaW5kaWNh dGVkIHNpbXBseSDigJxTdXN0YWluZWQgSVAgYWRkcmVzcyB0eXBl4oCdPyBZb3UgY2FzZSB0b29r IGEgc3RlcCB0b3dhcmRzIGEgc29sdXRpb24gd2hlcmUgeW91IHdhbnQgdG8gZHJhdy4gSSBkb27i gJl0IGV4cGVjdCB0aGUgYWN0aW9uIGlzIGdlbmVyaWMgd2hlbiBhIFN1c3RhaW5lZCBJUCBhZGRy ZXNzIHR5cGUgaXMgcmVxdWVzdGVkLg0KDQpCZXNpZGVzLCB5b3UgYXNzdW1wdGlvbiBvbiBJUCBh ZGRyZXNzIGFsbG9jYXRpb24gc2VlbXMgbm90IHZhbGlkLiBBIG1vYmlsZSBob3N0IHdvdWxkIGdl dCBhbiBJUCBhZGRyZXNzIHdoYXRldmVyIHRoZSBhbGxvY2F0ZWQgSVAgYWRkcmVzcyB0eXBlIGlz IHdoZW4gaXQgYXR0YWNoZXMgYXQgYSBuZXR3b3JrLCByZWdhcmRsZXNzIG9mIGFuIGFwcGxpY2F0 aW9u4oCZcyBJUCBhZGRyZXNzIHJlcXVlc3QuDQoNCg0KDQo+PjINCg0KTG9va3MgbGlrZSBJIGRp ZCBub3QgZXhwcmVzcyBteXNlbGYgd2VsbCBlbm91Z2ggKGFuZCBkaWQgbm90IGZ1bGx5IHVuZGVy c3RhbmQgeW91ciByZXBseSkuIExldCBtZSBsaXN0IHNvbWUgZXZlbnRzIHRoYXQgbWlnaHQgaGVs cCBjbGFyaWZ54oCmDQoNCg0KDQpJbml0aWFsIHN0YXRlOiBNb2JpbGUgbm9kZSBpcyBjb25uZWN0 ZWQgdG8gYSBuZXR3b3JrOyBubyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBhbGxvY2F0ZWQuIFRo ZSBJUCBzdGFjayBzZXRzIGEgZmxhZyAoU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkKSBpbmRpY2F0 aW5nIHRoYXQgaWYgYW4gYXBwbGljYXRpb24gcmVxdWVzdHMgYSBTdXN0YWluZWQgSVAgYWRkcmVz cywgaXQgd2lsbCBoYXZlIHRvIHJlcXVlc3Qgb25lIGZyb20gdGhlIG5ldHdvcmsuDQoNCg0KDQpF dmVudDE6IEFuIGFwcGxpY2F0aW9uIHRoYXQgcmVxdWlyZXMgYSBTdXN0YWluZWQgSVAgYWRkcmVz cyBpcyBsYXVuY2hlZC4NCg0KQVBQIGFjdGlvbjogQXBwIHJlcXVlc3RzIGEgU3VzdGFpbmVkIElQ IGFkZHJlc3MgZnJvbSB0aGUgSVAgc3RhY2sgdXNpbmcgdGhlIHByb3Bvc2VkIG5ldyBBUEkuDQoN CklQIHN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkIGlzIHNldCwg cmVxdWVzdCBvbmUgZnJvbSB0aGUgbmV0d29yay4NCg0KTmV0d29yayBhY3Rpb246IEFzc2lnbmVk IGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgdG8gdGhlIG1vYmlsZSBub2RlLg0KDQpJUCBzdGFjayBh Y3Rpb246ICgxKSBNYXJrIHRoZSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3MgYXMgdGhlIG9uZSB0 byBiZSBhc3NvY2lhdGVkIHRvIHN1YnNlcXVlbnQgYXBwczsgKDIpIFJlc2V0IFN1c3RhaW5lZElQ QWRkcmVzc05lZWRlZDsgKDMpQ29tcGxldGUgdGhlIEFQSSBhY3Rpb24gYW5kIGFzc29jaWF0ZSB0 aGUgbWFya2VkIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHdpdGggdGhhdCBwb3J0IChhcHApDQoNCg0K DQpFdmVudDI6IEEgbmV3IGFwcGxpY2F0aW9uIHRoYXQgYWxzbyByZXF1aXJlZCBhIFN1c3RhaW5l ZCBJUCBhZGRyZXNzIGlzIGxhdW5jaGVkDQoNCkFwcCBhY3Rpb246IEFwcCByZXF1ZXN0cyBhIFN1 c3RhaW5lZCBJUCBhZGRyZXNzIGZyb20gdGhlIElQIHN0YWNrIHVzaW5nIHRoZSBwcm9wb3NlZCBu ZXcgQVBJDQoNCklQIFN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVk ICBpcyBub3Qgc2V0LCBjb21wbGV0ZSB0aGUgQVBJIGFjdGlvbiBhbmQgYXNzb2NpYXRlIHRoZSBt YXJrZWQgU3VzdGFpbmVkIElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBvcnQgKGFwcCkNCg0KDQoNCkV2 ZW50MzogVGhlIG1vYmlsZSBub2RlIG1vdmVzIHRvIGEgbmV3IExBTg0KDQpJUCBTdGFjayBhY3Rp b246IFNldCBhIGZsYWcgaW5kaWNhdGluZyB0aGF0IHRoZSBjdXJyZW50bHkgYXZhaWxhYmxlIFN1 c3RhaW5lZCBJUCBhZGRyZXNzIGlzIG5vdCBvcHRpbWl6ZWQNCg0KDQoNCkV2ZW50NDogQW4gYXBw bGljYXRpb24gdGhhdCByZXF1aXJlcyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIGxhdW5jaGVk Lg0KDQpBUFAgYWN0aW9uOiBBcHAgcmVxdWVzdHMgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyBmcm9t IHRoZSBJUCBzdGFjayB1c2luZyB0aGUgcHJvcG9zZWQgbmV3IEFQSS4NCg0KSVAgc3RhY2sgYWN0 aW9uOiBTaW5jZSBTdXN0YWluZWRJUEFkZHJlc3NOZWVkZWQgaXMgc2V0LCByZXF1ZXN0IG9uZSBm cm9tIHRoZSBuZXR3b3JrLg0KDQpOZXR3b3JrIGFjdGlvbjogQXNzaWduZWQgYSBTdXN0YWluZWQg SVAgYWRkcmVzcyB0byB0aGUgbW9iaWxlIG5vZGUuDQoNCklQIHN0YWNrIGFjdGlvbjogKDEpIE1h cmsgdGhlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBhcyB0aGUgb25lIHRvIGJlIGFzc29jaWF0 ZWQgdG8gc3Vic2VxdWVudCBhcHBzOyAoMikgUmVzZXQgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVk OyAoMylDb21wbGV0ZSB0aGUgQVBJIGFjdGlvbiBhbmQgYXNzb2NpYXRlIHRoZSBtYXJrZWQgU3Vz dGFpbmVkIElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBvcnQgKGFwcCkNCg0KDQoNCk5vdGUgdGhhdCB0 aGUgYmVoYXZpb3Igb2YgdGhlIElQIHN0YWNrIGluIEV2ZW50NCBpcyBleGFjdGx5IGxpa2UgdGhl IG9uZSBpbiBFdmVudDEuDQoNCg0KDQpJIGJlbGlldmUgdGhhdCB0aGlzIGV2ZW50IGlzIHRoZSBv bmUgd2UgaGF2ZSBkaWZmZXJlbnQgb2Ygb3BpbmlvbnM6IEkgdGhpbmsgdGhhdCB0aGUgZGVmYXVs dCBiZWhhdmlvciBvZiB0aGUgSVAgc3RhY2sgaXMgdG8gcmVxdWVzdCBhIG5ldyBTdXN0YWluZWQg SVAgYWRkcmVzcyBzaW5jZSBpdCBtb3ZlZCB0byBhIG5ldyBMQU4sIGFuZCB5b3UgdGhpbmsgdGhh dCBpdCBzaG91bGQgZG8gc28gb25seSBpZiB0aGUgYXBwbGljYXRpb24gc3BlY2lmaWNhbGx5IHJl cXVlc3RzIGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzIHZpYSB0aGUgZmxhZyB5b3UgYXJlIHBy b3Bvc2luZy4NCg0KPj4yDQoNCg0KDQo+PiBZb3UgY2FuIHNlZSBteSBhbnN3ZXIgYXQgdGhlIGxv d2VzdCDigJw+PuKAnSBpbiB0aGlzIG1haWwuDQoNCg0KDQpBcyBhIG1hdHRlciBvZiBmYWN0LCBp ZiBzdWNoIGEgZmxhZyBpcyBkZWZpbmVkLCBJIGNhbm5vdCB0aGluayBvZiBhbiBleGFtcGxlIHdo ZXJlIGl0IHdpbGwgbm90IGJlIHVzZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQgYXBwbGljYXRpb25z IHdpbGwgYWx3YXlzIHJlcXVlc3QgYSByZWZyZXNoZWQgU3VzdGFpbmVkIElQIGFkZHJlc3MgKHdo ZW4gcmVxdWVzdGluZyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzKS4gSWYgdGhpcyBpcyBjb3JyZWN0 LCB0aGUgZmxhZyBpcyByZWR1bmRhbnQuDQoNCg0KDQo+IFNvbWUgYXBwbGljYXRpb25zLCBlLmcu IGVtYWlsLCB0aGF0IGFyZSBub3QgcmVsYXRpdmVseSByZXN0cmljdGVkIGZyb20gb3B0aW1hbCBy b3V0aW5nIHdvdWxkIGNvbnNpZGVyIGEgU3VzdGFpbmVkIElQIGFkZHJlc3Mgd2l0aG91dCBpc3N1 aW5nIHRoZSBuZXcgZmxhZy4gTW9yZSBhcHBsaWNhdGlvbnMgYmFzZWQgb24gc3VjaCBuZXR3b3Jr IGNoYXJhY3RlcmlzdGljIGNhbiBiZSB0aG91Z2h0IG1vcmUgdGhhbiBleHBlY3RlZC4NCg0KQW5k IHN1Y2ggdXNlIG9mIGV4aXN0aW5nIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIG5vdCBleHRyYW9y ZGluYXJ5LCBzaW5jZSBJUCBhZGRyZXNzIGlzIGEgcmVzb3VyY2UsIGV2ZW4gaW4gdGhlIGNvbnNp ZGVyYXRpb24gb2YgSVB2NiBkZXBsb3ltZW50LiBJZiBhcyBtYW55IGFzIGFwcGxpY2F0aW9ucyBy ZXF1aXJlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgd2lsbCBlbmQgdXAgaW4gYSBsb3Qg b2YgbmV0d29yayByZXNvdXJjZSBjb25zdW1wdGlvbiBpbiB0aGUgbW9iaWxpdHkgcm91dGVycyB3 aGVyZSB0aGUgU3VzdGFpbmVkIElQIGFkZHJlc3NlcyBhcmUgYW5jaG9yZWQgYXMgdGhlIHRlcm1p bmFsIG1vdmVzLg0KDQo+PjINCg0KSSBhbSBzb3JyeSBidXQgSSBkaXNhZ3JlZSB3aXRoIHRoZSBl bWFpbCBleGFtcGxlLiBJIGNhdGVnb3JpemUgaXQgYXMgYW4gZXhhbXBsZSBvZiBhbiBhcHBsaWNh dGlvbiB0aGF0IHdpbGwgcmVxdWVzdCBhIE5vbWFkaWMgYWRkcmVzcyBzaW5jZSBpdCBkb2VzIG5v dCBicmVhayB3aGVuIHRoZSBtb2JpbGUgbm9kZSBtb3ZlcyB0byBhIG5ldyBMQU4gYW5kIHRoZSBz b3VyY2UgSVAgYWRkcmVzcyBpcyBjaGFuZ2VkLiBJdCBzaW1wbHkgcmVzdGFydHMgdGhlIHNvY2tl dCBhbmQgY29udGludWUgd2l0aCB0aGUgbmV3IHNvdXJjZSBJUCBhZGRyZXNzICh0aGUgdXNlciB3 aWxsIG5vdCBldmVuIG5vdGljZSB0aGlzKS4NCg0KDQoNCj4+IFRoZSBleGFtcGxlIHdhcyBnaXZl biBhcyBhIGJlbmVmaXQgd2hlbiB0aGUgZXhpc3RpbmcgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMg dXNlZC4gWW91IGNvdWxkIGdldCBzb21lIGluc2lnaHQgZnJvbSBzdWNoIGtpbmQgb2YgYXBwbGlj YXRpb24gbm90IGNhcmluZyBtdWNoIHRoZSByb3V0aW5nIGRpc3RhbmNlIGV2ZW4gb24gdGhlIFN1 c3RhaW5lZCBJUCBhZGRyZXNzLg0KDQoNCg0KSSBkaWQgbm90IHVuZGVyc3RhbmQgdGhlIG90aGVy IHRleHQgcmVnYXJkaW5nIHJlc291cmNlIGNvbnN1bXB0aW9uLiBJIHRob3VnaHQgd2UgYWdyZWVk IHRoYXQgZXZlbiBvZiBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyByZXF1ZXN0ZWQgdXBv biBlYWNoIG1vdmVtZW50IHRvIGEgbmV3IExBTiwgdGhlIGVmZmVjdCBvbiBJUCBhZGRyZXNzIGFs bG9jYXRpb24gaXMgbm90IHNpZ25pZmljYW50LiBPdGhlcndpc2UsIG15IGluaXRpYWwgY29tbWVu dCBvbiBhcHBsaWNhdGlvbnMgYWJ1c2luZyB0aGUgbmV0d29yayB1c2luZyB5b3VyIHByb3Bvc2Vk IGZsYWcsIGJlY29tZXMgdmFsaWQgYWdhaW4NCg0KPj4yDQoNCg0KDQo+PiBObywgb3VyIGRyYWZ0 IGRpZG7igJl0IHNheSBzby4gT3VyIGlkZWEgaXMgdGhhdCBhIG5ldyBTdXN0YWluZWQgSVAgYWRk cmVzcyBpcyByZXF1ZXN0ZWQgdXBvbiByZWNlaXZpbmcgKm5ldyogZmxhZyBmcm9tIGFuIGFwcGxp Y2F0aW9uLCBhcyBhIHByZWZlcmVuY2UgZm9yIGEgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uLiBZ b3UgbmVlZCB0byByZWFkIG91ciBkcmFmdCBjbGFzc2lmeWluZyB0aGUgY2F0ZWdvcmllcyBvZiBJ UCBhZGRyZXNzIHJlcXVlc3QgYWdhaW4uDQoNCg0KDQpCZXNpZGVzLCBJIGRvbuKAmXQgdW5kZXJz dGFuZCB3aGF0IGlzIGFidXNlZC4gRGVsaXZlcmluZyBpdHMgcHJlZmVyZW5jZSBjYW5ub3QgYmUg YWJ1c2UuIFJlZ2FyZGluZyDigJxhYnVzZeKAnSwgSSBzZWUgaXQgaW4geW91ciBkZWZhdWx0IGJl aGF2aW9yIHlvdeKAmXJlIGFzc3VtaW5nIGhlcmUuIEluIHlvdXIgc2NlbmFyaW8sIGEgbmV3IGFw cCBpbml0aWF0ZWQgaW4gYSBuZXcgbmV0d29yayB3aWxsIGJlIGZvcmNlZCB0byB1c2UgYSBuZXds eSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcy4gWW91IHNlZSB0aGF0PyBZb3UgdG90YWxs eSBibG9jayB0aGUgcG9zc2liaWxpdHkgdG8gYmUgY29uc2lkZXJlZCBieSB0aGUgZGVmYXVsdCBz b3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMgZGVmaW5lZCBpbiBSRkM2NzI0LiBCdXQgaW4g b3VyIGRyYWZ0LCBpbiBjYXNlIHRoZSBuZWVkIG9mIGEgbmV3bHkgb2J0YWluZWQgU3VzdGFpbmVk IElQIGFkZHJlc3MgaXMgcHJpb3JpdGl6ZWQsIHRoZSBwcm9wb3NlZCAqbmV3KiBmbGFnIGNhbiBi ZSB1c2VkIGJ5IGFwcOKAmXMgcmVxdWVzdCwgdGh1cyBpdCB3aWxsIGJlIHNlbGVjdGVkIHdpdGgg cHJpb3JpdHkuDQoNCg0KDQpDYW4geW91IHByb3ZpZGUgYSBzY2VuYXJpbyBpbiB3aGljaCBhbiBh cHBsaWNhdGlvbiB3aWxsIG5vdCByZXF1ZXN0IHRvIHJlZnJlc2ggdGhlIFN1c3RhaW5lZCBJUCBh ZGRyZXNzPw0KDQoNCg0KPiBJdCB3YXMgbWVudGlvbmVkIGluIHRoZSBmb3JtZXIgY29tbWVudHMu DQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICAgICAgICAgICAgIC9EYW5ueQ0KDQpGcm9tOiBT ZWlsIEplb24gW21haWx0bzpzZWlsamVvbkBhdi5pdC5wdF0NClNlbnQ6IE1vbmRheSwgTWFyY2gg MzAsIDIwMTUgMTc6MDgNClRvOiBNb3NlcywgRGFubnkNCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRv OmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IEZXOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0 aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkgRGFubnksDQoNCg0KDQpBbnkgY29t bWVudHM/DQoNCg0KDQpSZWdhcmRzLA0KDQpTZWlsIEplb24NCg0KDQoNCg0KDQpGcm9tOiBkbW0g W21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNlaWwgSmVvbg0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDg6MDggUE0NClRvOiBkbW1AaWV0Zi5vcmc8bWFp bHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rp b25zIGZvciB0aGUgcHJvcG9zZWQgQVBJDQoNCg0KDQpIaSwNCg0KDQoNCkkgY291bGQgYXR0ZW5k IERNTSBUaHVyc2RheSBtZWV0aW5nIHZpYSBNZWV0RWNoby4NCg0KSSBjb3VsZCBhbHNvIGhlYXIg c29tZSByYWlzZWQgY29tbWVudHMgYnkgRGFubnkgYW5kIFNvbWVvbmUuIEhlcmUgZ29lcyBhbnN3 ZXJzIHRvIHRoZSByYWlzZWQgcXVlc3Rpb25zLg0KDQoNCg0KDQoNCkZpcnN0LCByZWdhcmRpbmcg dGhlIG5lZWQgb2YgdGhlIHByb3Bvc2VkIEFQSSAoSVBWNl9QUkVGRVJfU1JDX05FVyksDQoNCg0K DQpUaGUgdXNlIG9mIHRoZSBwcm9wb3NlZCBBUEkgaXMgc3VnZ2VzdGVkIGluIHRoZSBTVVNUQUlO RUQgSVAgYWRkcmVzcyBjYXNlIGluIHRoZSBkcmFmdC4gT24gcmVjZWl2aW5nIHRoaXMgQVBJIHdp dGggdGhlIFNVU1RBSU5FRCBJUCBhZGRyZXNzIHR5cGUgYXQgdGhlIElQIHN0YWNrLCBpdCB3aWxs IHRyeSB0byBnZXQgYSBuZXcgU1VTVEFJTkVEIElQIGFkZHJlc3MgaWYgdGhlcmUgaXMgbm8gYXZh aWxhYmxlIGluIHRoZSBjdXJyZW50bHkgYXR0YWNoZWQgYWNjZXNzIG5ldHdvcmsuIFNvLCBhY3R1 YWwgb2J0YWluaW5nIG9mIHRoZSBJUCBhZGRyZXNzIHdpbGwgYmUgdHJpZWQgb25lIHRpbWUgd2hp bGUgYXR0YWNoZWQgYXQgYSBzcGVjaWZpYyBhY2Nlc3MgbmV0d29yay4gRXZlbiBzb21lIGFwcGxp Y2F0aW9ucyBwdXQgdGhpcyBBUEkgYWZ0ZXIsIHRoZSBhbHJlYWR5IG9idGFpbmVkIFNVU1RBSU5F RCBJUCB3aWxsIGJlIHVzZWQuIFNvLCBubyB3b3JyaWVzIGFib3V0IGFidXNlLg0KDQoNCg0KU2Vj b25kIHF1ZXN0aW9uIHNvdW5kZWQgdG8gbWUgbGlrZSB0aGF0IHRoaXMgQVBJIGlzIG5vdCBuZWVk ZWQgYmVjYXVzZSB0aGUgaG9zdCBjYW4gZ2V0IGEgbmV3IFNVU1RBSU5FRCBJUCBhZGRyZXNzLCBy aWdodD8NCg0KSWYgdGhlIHF1ZXN0aW9uIGlzIHJpZ2h0LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3 aGF0IHRoZSBxdWVzdGlvbiBpcyBtZWFudCwgdGhhdCBpcyBob3cgdGhlIGhvc3QgY2FuIGdldCBh IG5ldyBTVVNUQUlORUQgSVAgYWRkcmVzcz8NCg0KQmFzZWQgb24gdGhlIGRlZmluaXRpb24gb2Yg dGhyZWUgdHlwZXMgb2YgSVAgYWRkcmVzcywgYW4gYXBwbGljYXRpb24gc2hvdWxkIHNob3cgaXRz IHJlcXVpcmVtZW50IHdpdGggYW4gQVBJIGFtb25nIHRoZW0uIElmIGl0IGlzIHRoZSBTVVNUQUlO RUQgSVAgYWRkcmVzcywgaG93IGRvIHdlIGV4cGVjdCB0aGUgSVAgc3RhY2sgd2lsbCB0cnkgdG8g Z2V0IGEgbmV3IFNVU1RBSU5FRCBJUCBhZGRyZXNzPw0KDQoNCg0KQmVzaWRlcywgdGhlIHByb3Bz b2VkIEFQSSBpcyBub3QgdXNlZCBhbG9uZSBidXQgd2l0aCB0aGUgdGhyZWUgdHlwZSBBUElzLg0K DQoNCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KU2VpbCBKZW9uDQoNCg0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFu aWVzDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG1hdGVyaWFsIGZvcg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQpieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQsIHBsZWFz ZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXMN Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgbWF0ZXJpYWwgZm9yDQp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24NCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K QSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllcw0KDQpU aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBt YXRlcmlhbCBmb3INCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbg0KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFj dCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBIG1l bWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzDQoNClRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVy aWFsIGZvcg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxt YWlsdG86ZG1tQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbW0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBn cm91cCBvZiBjb21wYW5pZXMKClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcgp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24KYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGll bnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLgo= --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAD6HASMSX106gercor_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgVUkgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIFVJIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldoYXQgaXMgc2ltcGxlci4gQ2FuIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBXaGF0IGFyZSB5 b3UgY29tcGFyaW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL0Rhbm55PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYXBlbmcgTGl1IFttYWlsdG86bWF4cGFz c2lvbkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxMywgMjAx NSAxNTo1NDxicj4NCjxiPlRvOjwvYj4gU2VpbCBKZW9uPGJyPg0KPGI+Q2M6PC9iPiBNb3Nlcywg RGFubnk7IGRtbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiA8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgVUkgR290aGljJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuWbnuWkje+8mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJv cG9zZWQgQVBJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gU2Vp bCwgRGFubnk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7v vJo8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W2FzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3JdPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4gcmVmZXIgdG8gdGhl IGZvbGxvd2luZyB0d28gZHJhZnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbGl1LWRtbS1hZGRyZXNzLXNlbGVjdGlvbi0wMSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWxpdS1kbW0tYWRkcmVzcy1zZWxlY3Rpb24tMDE8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtZG1tLW1vYmlsaXR5LWFwaS0wMiI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWRtbS1tb2JpbGl0eS1hcGktMDI8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0 IHRoZSBzaW1pbGFyIGlkZWE/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFwZW5nIExpdTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90Oztjb2xvcjojQTBBMEE4Ij7lnKg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEw QTgiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm cXVvdDs7Y29sb3I6I0EwQTBBOCI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojQTBBMEE4 Ij40PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 Y29sb3I6I0EwQTBBOCI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojQTBBMEE4Ij4xMzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9y OiNBMEEwQTgiPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6I0EwQTBBOCI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBB MEE4Ij7mmJ/mnJ/kuIDvvIzkuIrljYg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgi PjY6MDM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 Oztjb2xvcjojQTBBMEE4Ij7vvIw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPlNl aWwgSmVvbg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm cXVvdDs7Y29sb3I6I0EwQTBBOCI+5YaZ6YGT77yaPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj QTBBMEE4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDguMHB0O21hcmdpbi1sZWZ0OjBpbjttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBEYW5ueSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RnJvbSB5b3VyIGNhc2VzIHNwZWNpZmllZCBhcyBmb2xsb3dzOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCc PC9zcGFuPkkgYW0gdGhpbmtpbmcgb2YgdHdvIHBsYWNlcyB0aGF0IG1pZ2h0IHJlcXVpcmUgYW4g dXBkYXRlOjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij5XaGVuIGFuIGFwcGxpY2F0aW9uIGNob29zZXMgbm90IHRvIHNwZWNpZnkgYSBz b3VyY2UgYWRkcmVzcyAoYnV0IHJlcXVlc3QgYSBzcGVjaWZpYyB0eXBlKTxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij5XaGVuIGFuIGFw cGxpY2F0aW9uIHdpc2hlcyB0byBjaG9vc2UgdGhlIHNvdXJjZSBhZGRyZXNzIGZyb20gYSBwcm92 aWRlZCBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCcPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB1 bmRlcnN0YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBzZWNvbmQgY2FzZS4gV2h5IHNob3VsZCBhbiBh cHBsaWNhdGlvbiB3aXNoIHRvIGNob29zZSBhIHNvdXJjZSBhZGRyZXNzIGZyb20gYSBsaXN0PyBX aGF0IEkgaGF2ZSB0YWxrZWQgYWJvdXQgd2FzIGFib3V0DQogYWxsb3dpbmcgdGhlIGRlZmF1bHQg c291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uIHJ1bGVzLCB3aGljaCB3aWxsIGJlIGRldGVybWluZWQg aW4gdGhlIElQIHN0YWNrIHdoZW4gYW4gYXBwbGljYXRpb24gaXMgaW5pdGlhdGVkIHdpdGggdGhl IGRlc3RpbmF0aW9uIGFkZHJlc3MuIEkgdGhpbmsgd2UgZG9u4oCZdCBuZWVkIHRvIHRvdWNoIGl0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcG9pbnQgaXMgYW4gYXBwbGljYXRpb24gd2lsbCB0b3Rh bGx5IGFzc2lnbiB0aGUgZGVmYXVsdCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gbWVjaGFuaXNt DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5iYXNlZCBvbiBvbmx5IHR5cGUgcmVxdWVzdCBi dXQgd2l0aCBubyBwcmVmZXJlbmNlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiwgb3Ig d2lsbCByZXF1ZXN0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj53aXRoIHRoZSBwcmVmZXJl bmNlIG9mIGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzIGFzIHdlbGwgYXMgdHlwZSByZXF1ZXN0 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4gSW4gdGhlIGZvcm1lciBjYXNlLCBpZiB0 aGVyZSBpcyBvbmUgb3IgbXVsdGlwbGUgU3VzdGFpbmVkDQogSVAgYWRkcmVzc2VzLCB0aGUgSVAg c3RhY2sgd2lsbCB0cnkgdG8gcGljayB1cCBvbmUuIE9yIHRoZSBJUCBzdGFjayB3aWxsIHRyeSB0 byBnZXQgYSBuZXcgb25lLiBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBJUCBzdGFjayB3aWxsIGNv bnNpZGVyIGEgbmV3bHkgb2J0YWluZWQgU3VzdGFpbmVkIElQIGFkZHJlc3MgYWxsIHRoZSB0aW1l LCBpZiB0aGUgcmVxdWVzdGVkIHByZWZlcmVuY2UgdmFsdWUgaXMgbm90IGxlc3MgdGhhbiBvdGhl ciBwcmVmZXJlbmNlcw0KIGRlZmluZWQgaW4gdGhlIGRlZmF1bHQgc291cmNlIGFkZHJlc3Mgc2Vs ZWN0aW9uIHJ1bGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgbmVlZCBvZiB0aGUgcHJvcG9zZWQg ZmxhZyBhbmQgbWFpbiBjcml0ZXJpYSB0byBiZSBjb25zaWRlcmVkIHdlcmUgYWxyZWFkeSBjb3Zl cmVkIHdpdGggY2FzZSBzdHVkaWVzIGluIHRoZSBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNp amVvbi1kbW0tdXNlLWNhc2VzLWFwaS1zb3VyY2UtMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNpamVvbi1kbW0tdXNlLWNhc2VzLWFwaS1zb3VyY2UtMDA8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNvLCBmb3IgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uLCBJIHdvdWxkIGxpa2UgdG8g c3VnZ2VzdCB0aGF0IHlvdSBjaGVjayBvdXIgZHJhZnQgYWdhaW4gcGxlYXNlIGFuZCBicmluZyB5 b3VyIHF1ZXN0aW9ucyBpZiB0aGVyZSBpcyBzb21ldGhpbmcgd2VpcmQgb3Igc2hvdWxkDQogYmUg dXBkYXRlZCB3aXRoIGFkZGl0aW9uYWwgY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U2VpbCBKZW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNb3NlcywgRGFubnkgWzxhIGhyZWY9Im1haWx0bzpkYW5u eS5tb3Nlc0BpbnRlbC5jb20iPm1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMTIsIDIwMTUgMTo0OSBQTTxicj4NCjxiPlRv OjwvYj4gU2VpbCBKZW9uPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYu b3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRE1NXSBBbnN3 ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91IGhh dmUgYSBnb29kIHBvaW50IGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Tm93IEkg dW5kZXJzdGFuZCB0aGUgbmVlZCBmb3IgdGhlIGZsYWcgeW91IGFyZSBwcm9wb3NpbmcgISEhDQo8 L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+V2UgbmVlZCB0byB0YWtlIGEgYmV0dGVyIGxvb2sgYXQgUkZDIDY3 MjQgYW5kIGZpZ3VyZSBvdXQgaWYgd2UgbmVlZCB0byB1cGRhdGUgaXQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SSBhbSB0aGlua2luZyBvZiB0d28gcGxhY2VzIHRoYXQgbWlnaHQgcmVxdWly ZSBhbiB1cGRhdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hlbiBh biBhcHBsaWNhdGlvbiBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5IGEgc291cmNlIGFkZHJlc3MgKGJ1 dCByZXF1ZXN0IGEgc3BlY2lmaWMgdHlwZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5XaGVuIGFuIGFwcGxpY2F0aW9uIHdpc2hlcyB0byBjaG9vc2UgdGhlIHNvdXJjZSBh ZGRyZXNzIGZyb20gYSBwcm92aWRlZCBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldo ZW4gdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlcyB0aGUgZGVzaXJlZCBhZGRyZXNzIHR5cGUsIGJ1 dCBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5IHRoZSBzb3VyY2UgYWRkcmVzcyAoZnJvbSBhIGxpc3Qg cHJvdmlkZWQgYnkgdGhlIElQIHN0YWNrKSwgdGhlIHN0YWNrIHNob3VsZCBhbGxvY2F0ZSBhIHNv dXJjZSBJUCBhZGRyZXNzDQogYWNjb3JkaW5nIHRvIHRoZSBhZGRyZXNzLXR5cGUgcmVxdWVzdGVk IGJ5IHRoZSBhcHBsaWNhdGlvbi4gSW4gdGhpcyBjYXNlLCB3ZSBzaG91bGQgY29uc2lkZXIgYWRk aW5nIHRleHQgdG8gZGVzY3JpYmUgdGhlIGJlaGF2aW9yIGZvciBTdXN0YWluZWQgSVAgYWRkcmVz c2VzLiBTcGVjaWZpY2FsbHksIGlmIHRoZXJlIGFyZSBzZXZlcmFsIFN1c3RhaW5lZCBJUCBhZGRy ZXNzZXMgYWxsb2NhdGVkIHRvIHRoZSBtb2JpbGUgaG9zdCwgd2hldGhlciB0bw0KIGNob29zZSBv bmUgb2YgdGhlbSwgb3IgdG8gaGF2ZSB0aGUgbW9iaWxlIGhvc3QgcmVxdWVzdCBhIG5ldyBvbmUg ZnJvbSB0aGUgbmV0d29yayAoYXMgYSByZXN1bHQgb2YgYSBtb2JpbGl0eSBldmVudCDigJMgZm9y IGV4YW1wbGUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoZW4gYW4gYXBwbGljYXRpb24g d2lzaGVzIHRvIGNob29zZXMgdGhlIHNvdXJjZSBhZGRyZXNzIGZyb20gdGhlIGF2YWlsYWJsZSBs aXN0IChvYnRhaW5lZCBieSBnZXRhZGRyaW5mbygpKSwgdGhlcmUgYXJlIHNvbWUgYWx0ZXJuYXRp dmUgYXBwcm9hY2hlcyB3ZSBzaG91bGQgY29uc2lkZXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+RW5oYW5jZSBnZXRhZGRyaW5mbygpIGVuYWJsaW5nIHRoZSBhcHBsaWNh dGlvbiB0byBzcGVjaWZ5IHRoZSByZXF1aXJlZCBhZGRyZXNzIHR5cGUsIGFuZCByZXR1cm4gdGhl IGxpc3Qgb2Ygc291cmNlIGFkZHJlc3NlcyB0aGF0IGFyZSBvZiB0aGF0IHR5cGUgKE5vbWFkaWMs IFN1c3RhaW5lZCwgRml4ZWQgb3IgRG9udENhcmUpLA0KIG9yIC0gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+UHJvdmlkZSB0aGUgbGlzdCBvZiBhZGRyZXNzZXMgd2l0aCBh biBpbmRpY2F0aW9uIG9mIHRoZWlyIHR5cGUgKE5vbWFkaWMsIFN1c3RhaW5lZCwgRml4ZWQgb3Ig VHlwZVVua25vd24pIGFuZCBhbiBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgZWFjaCBhZGRyZXNzIGlz IE5ldyAoYWxsb2NhdGVkIGFmdGVyIHRoZSBsYXN0IGhhbmRvZmYNCiBldmVudCkgb3IgT2xkIChh bGxvY2F0ZWQgYmVmb3JlIHRoZSBsYXN0IGhhbmRvZmYgZXZlbnQpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U29tZSBvdGhlciBhcHByb2FjaOKApjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlRoZSBmbGFnIGlzIG5lZWQgaGVyZSwgdG8gZW5hYmxlIHRoZSBhcHBs aWNhdGlvbiB0byByZXF1ZXN0IGEgbmV3IElQIGFkZHJlc3MgKGlmIHRoZSByZXR1cm5lZCBsaXN0 IG9ubHkgY29udGFpbiAnT2xkJyBhZGRyZXNzZXMpICEhITwvc3Bhbj48L2I+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5JIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGRpc2N1c3MgdGhpcy4gSG93IGFib3V0IGJy aW5naW5nIGl0IHRvIHRoZSBuZXh0ICc8L3NwYW4+PHNwYW4gbGFuZz0iVFIiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5Nb2JpbGl0eSBFeHBvc3VyZSBhbmQgU2VsZWN0aW9uIFdUPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4nDQogY2FsbD88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvRGFubnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2VpbCBKZW9uIFs8YSBocmVmPSJtYWlsdG86c2Vp bGplb25AYXYuaXQucHQiPm1haWx0bzpzZWlsamVvbkBhdi5pdC5wdDwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAwNSwgMjAxNSAxNzowODxicj4NCjxiPlRvOjwvYj4gTW9z ZXMsIERhbm55PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5k bW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRE1NXSBBbnN3ZXIgb24g cmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBEYW5ueSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+TWVldGluZyBpcyBhbHdheXMgZ29vZCwgZXZlbiB3aXRoIHlvdSBieSBmLXRv LWYuIEJ1dCBpbiB0aGUgZGlzY3Vzc2lvbiwgdGhlIG1haW4gaXNzdWUgaXMgd2hldGhlciB3ZSB3 aWxsIGFsbG93IHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBydWxlcw0KIGRl ZmluZWQgaW4gUkZDNjcyNCBmb3Igc2VsZWN0aW5nIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgYW1v bmcgc2V2ZXJhbCBvbmVzIG9yIGZ1bmRhbWVudGFsbHkgYmxvY2sgdGhlbSBmb3IgYSBzcGVjaWZp YyByZWFzb24gcmFpc2VkIGJ5IGEgRE1NIG5lZWQuIFRoZSBsYXR0ZXIgYXBwcm9hY2ggaXMgbm90 IHJlYXNvbmFibGUgbm8gbWF0dGVyIGhvdyBJIHRyeSB0byB0aGluaw0KPGEgaHJlZj0iaHR0cDov L29mLml0Ij5vZi5pdDwvYT4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBh biBhcHBsaWNhdGlvbiBoYXMgdGhlIHNwZWNpZmljIHByZWZlcmVuY2Ugb2YgYSBuZXdseSBvYnRh aW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgdXNlcyB0aGUgcHJvcG9zZWQgQVBJLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U2VpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1vc2VzLCBEYW5ueSBbPGEg aHJlZj0ibWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbSI+bWFpbHRvOmRhbm55Lm1vc2VzQGlu dGVsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAwNSwgMjAxNSAx MjoyMyBQTTxicj4NCjxiPlRvOjwvYj4gU2VpbCBKZW9uPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVm PSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2Vk IEFQSTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SGkgU2VpbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CeSBub3cgd2Ug aGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBmb3IgcXVpdGUgc29tZSB0aW1lIGFuZCBjbGVhcmx5 IHdlIGRpZCBub3Qgc3VjY2VlZCBpbiBjb252aW5jaW5nIGVhY2ggb3RoZXIuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBzdWdnZXN0IHdlIHRyeSBhZ2FpbiB3aGVuIHdl IGhhdmUgYSBjaGFuY2UgdG8gbWVldCBmYWNlIHRvIGZhY2UuIE1lYW53aGlsZSwgbGV0J3MgbGlz dGVuIHRvIHdoYXQgb3RoZXIgcGVvcGxlIGhhdmUgdG8gc2F5IG9uIHRoaXMgbWF0dGVyLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9EYW5ueTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTZWlsIEplb24g WzxhIGhyZWY9Im1haWx0bzpzZWlsamVvbkBhdi5pdC5wdCI+bWFpbHRvOnNlaWxqZW9uQGF2Lml0 LnB0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEFwcmlsIDA1LCAyMDE1IDAxOjE2 PGJyPg0KPGI+VG86PC9iPiBNb3NlcywgRGFubnk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlc2VudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNlaWwgSmVvbiBbPGEgaHJl Zj0ibWFpbHRvOnNlaWxqZW9uQGF2Lml0LnB0Ij5tYWlsdG86c2VpbGplb25AYXYuaXQucHQ8L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAwNCwgMjAxNSAxOjM1IFBNPGJy Pg0KPGI+VG86PC9iPiAnTW9zZXMsIERhbm55Jzxicj4NCjxiPkNjOjwvYj4gJzxhIGhyZWY9Im1h aWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4nPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQ STwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBEYW5ueSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VlIHRoZSBpbmxpbmUgcGxlYXNlLiBJ IG1hcmtlZCBjdXJyZW50IHJlcGxpZXMgd2l0aCDigJwmZ3Q7Jmd0O+KAnSBhbmQgcHJldmlvdXMg cmVwbGllcyB3aXRoIOKAnCZndDvigJ0gZm9yIHlvdSB0byBjYXRjaCB0aGVtIGVhc2lseS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNlaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNb3NlcywgRGFubnkgWzwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZGFubnkubW9zZXNAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+bWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbTwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg QXByaWwgMDIsIDIwMTUgMjoxNiBQTTxicj4NCjxiPlRvOjwvYj4gU2VpbCBKZW9uPGJyPg0KPGI+ Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RNTV0gQW5zd2VyIG9uIHJhaXNl ZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIFNlaWwsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBteSByZXBsaWVzIChzdXJyb3VuZGVkIGJ5ICZu YnNwOyZndDsmZ3Q7MikgdG8geW91cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgL0Rhbm55PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFNlaWwgSmVvbiBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZWls amVvbkBhdi5pdC5wdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpzZWlsamVv bkBhdi5pdC5wdDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAxNSAxNToyMzxicj4NCjxiPlRvOjwv Yj4gTW9zZXMsIERhbm55PGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRt bUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS RTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgRGFubnksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlZSB0aGUgaW5saW5lIHBsZWFzZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2VpbCBKZW9uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g TW9zZXMsIERhbm55IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNv bSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5j b208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBNYXJjaCAzMCwgMjAxNSA0OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBTZWls IEplb248YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRE1NXSBB bnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkg U2VpbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcyB0byB0aGUgcG90ZW50aWFsIG9mIGFi dXNlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlllcywgSSBzZWUgeW91 ciBwb2ludCBhbmQgeW91IGFyZSBjb3JyZWN0LiBJZiB0aGUgSVAgc3RhY2sgd2lsbCBub3QgcmVx dWVzdCBhIHN1c3RhaW5lZCBJUCBhZGRyZXNzIG1vcmUgdGhhbiBvbmNlIGFmdGVyIGVhY2ggbW92 ZW1lbnQgdG8gYSBuZXcgTEFOICh3aXRoIGEgZGlmZmVyZW50IHByZWZpeCksIHRoYW4gdGhlcmUN CiB3aWxsIGJlIG5vIGFidXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgWWVzLCBpdOKAmXMgdHJ1ZS4gVGhhbmtz IGZvciBjb3JyZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgdG8gdGhlIHNlY29uZCBj b21tZW50LCBwbGVhc2UgbGV0IG1lIGVsYWJvcmF0ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5PbmUgcG90ZW50aWFsIGltcGxlbWVudGF0aW9uIG9mIHRoZSBJUCBzdGFj ayBpbiB0aGUgaG9zdCwgY2FuIGJlIHRvIHJlcXVlc3QgYSBOb21hZGljIElQIGFkZHJlc3MgYW5k IGEgJm5ic3A7U3VzdGFpbmVkIElQIGFkZHJlc3Mgd2hlbmV2ZXIgY29ubmVjdGluZyB0byBhIG5l dHdvcmssIGFuZCB3aGVuZXZlciBtb3ZpbmcgdG8gYSBuZXcNCiBMQU4sIHJlZ2FyZGxlc3MgaWYg dGhlcmUgYXJlIGFueSBhcHBsaWNhdGlvbnMgcmVxdWVzdGluZyBhbnkgYWRkcmVzc2VzLiBUaGlz IHdheSwgd2hlbmV2ZXIgYW4gYXBwbGljYXRpb24gaXMgbGF1bmNoZWQgYW5kIHJlcXVlc3RzIGVp dGhlciBhIE5vbWFkaWMgb3IgU3VzdGFpbmVkIElQIGFkZHJlc3MsIHRoZSBzdGFjayBjYW4gcHJv dmlkZSBvbmUgd2l0aG91dCBoYXZpbmcgdG8gaXNzdWUgYSByZXF1ZXN0IHRvIHRoZSBuZXR3b3Jr LiBJbiB0aGlzDQogY2FzZSwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyBmbGFnIGZyb20gdGhl IGFwcGxpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgRGVjaXNpb24gb2Ygd2hpY2ggdHlwZSBvZiBJUCBh ZGRyZXNzIGJ5IGRlZmF1bHQgd2lsbCBiZSBkZXBlbmRpbmcgb24gdGhlIElQIHBvb2wgbWFuYWdl bWVudCBwb2xpY3kgYnkgb3BlcmF0b3JzLiBZb3UgY2FzZSBtYXkgY29ycmVzcG9uZCB0byBvbmUg b2YgdGhlbS4gV2hhdCBpZiBvbmx5DQogdGhlIE5vbWFkaWMgSVAgYWRkcmVzcyBpcyBiYXNpY2Fs bHkgYWxsb2NhdGVkIHVwb24gYSBuZXR3b3JrIGF0dGFjaG1lbnQ/IFRoYXQgaXMsIGEgbG90IG9m IGFwcGxpY2F0aW9ucyByZXF1aXJlIG1lcmUgSW50ZXJuZXQgY29ubmVjdGl2aXR5IHdpdGhvdXQg c2Vzc2lvbiBjb250aW51aXR5IHN1cHBvcnQuIFNvLCB0aGUgU3VzdGFpbmVkIElQIGFkZHJlc3Mg d2lsbCBiZSByZXF1ZXN0ZWQgb24gZGVtYW5kLCBhbmQgdGhlIHByb3Bvc2VkIGZsYWcgd2lsbA0K IGJlIHVzZWQgdG8gZ2V0IGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzIGJ5IGV4cHJlc3Npbmcg dGhlIGV4cGxpY2l0IHJlcXVlc3QgYnkgYW4gYXBwbGljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7Jmd0OzI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcyBJ IG1lbnRpb25lZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBkZXNjcmlwdGlvbiDigJMgaXQgaXMg YSBkZXNjcmlwdGlvbiBvZiBvbmUgYWx0ZXJuYXRpdmUuIEkgYW0gbm90IGFzc3VtaW5nIGl0IGlz IHRoZSBvbmx5IHNjZW5hcmlvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlllcywgSSBhZ3JlZSB0aGF0IG1hbnkgYXBwcyByZXF1aXJlIG9ubHkgTm9tYWRpYyBJUCBhZGRy ZXNzZXMsIGJ1dCBpbiB0aGlzIGV4YW1wbGUsIHRoZSBJUCBzdGFjayBpbiB0aGUgaG9zdCBwcmUt YWxsb2NhdGVzIGJvdGggTm9tYWRpYyBhbmQgU3VzdGFpbmVkIElQIGFkZHJlc3NlcyB1cG9uIGF0 dGFjaG1lbnTigKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jmd0OyBBcyBJIHNhaWQsIGl0IGNvdWxkIGJlLCBidXQg bm90IGFzIGdlbmVyYWwgb25lLiBUaGUgcHJvcG9zZWQgQVBJIGlzIHVzZWZ1bCB0aHJvdWdoIHRo ZSBleHBsaWNpdCBleHByZXNzaW9uIGZvciBhbnkgcG90ZW50aWFsIHNjZW5hcmlvcy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlllcywgd2UgY2FuIGRlc2NyaWJlIGFuIGFsdGVybmF0aXZlIGluIHdo aWNoIGEgTm9tYWRpYyBJUCBhZGRyZXNzIGlzIHByZS1hbGxvY2F0ZWQgdXBvbiBOVyBjb25uZWN0 aW9uIChhbmQgYWZ0ZXIgZXZlcnkgbW92ZW1lbnQgdG8gYSBuZXcgTEFOKSBhbmQgYSBTdXN0YWlu ZWQgKGFuZC9vciBGaXhlZCkgYWRkcmVzcyBpcyBhbGxvY2F0ZWQNCiBvbi1kZW1hbmQuIEV2ZW4g aW4gc3VjaCBhIHNjZW5hcmlvLCBJIGRvIG5vdCBzZWUgYW55IHVzZSBmb3IgdGhpcyBmbGFnIOKA kyBzZWUgbXkgcmVwbHkgdG8gdGhlIHNlY29uZCBpdGVtIGJlbG934oCmPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyZndDsyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZndDsgTXkgYW5z d2VyIHdhcyBhbHJlYWR5IGdpdmVuIGluIGZvbGxvd2luZyBhbnN3ZXIgaW4gcHJldmlvdXMgZW1h aWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5vdGhlciBwb3RlbnRpYWwgaW1wbGVtZW50 YXRpb24gb2YgdGhlIElQIHN0YWNrIGluIHRoZSBob3N0IGlzIG5vdCB0byByZXF1ZXN0IElQIGFk ZHJlc3NlcyBpbiBhZHZhbmNlLiBJbiB0aGF0IGNhc2UsIGl0IHdpbGwgaXNzdWUgYSByZXF1ZXN0 IGZvciBhIE5vbWFkaWMgSVAgYWRkcmVzcyBvciBhIFN1c3RhaW5lZCBJUA0KIGFkZHJlc3MgdGhl IGZpcnN0IHRpbWUgYW4gYXBwbGljYXRpb24gcmVxdWVzdHMgb25lIGFuZCB1c2UgaXQgZm9yIHN1 YnNlcXVlbnQgcmVxdWVzdHMgYXMgbG9uZyBhcyBpdCBpcyBub3QgbW92aW5nIHRvIGEgZGlmZmVy ZW50IExBTi4gT25jZSBpdCBtb3ZlcywgaXQgd2lsbCBhZ2FpbiByZXF1ZXN0IGEgbmV3IElQIGFk ZHJlc3MgKE5vbWFkaWMgb3IgU3VzdGFpbmVkIOKAkyBhY2NvcmRpbmcgdG8gd2hhdCBpcyByZXF1 aXJlZCkgYWZ0ZXIgcmVjZWl2aW5nDQogdGhlIGZpcnN0IHJlcXVlc3QgZnJvbSBhbnkgYXBwbGlj YXRpb24uIEluIHRoaXMgY2FzZSBhcyB3ZWxsLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIGZs YWcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jmd0OyBBbm90aGVyIGFwcGxpY2F0aW9uIHJlcXVlc3RlZCBqdXN0IFN1c3Rh aW5lZCBJUCBhZGRyZXNzIHdoaWxlIHRoZSBJUCBzdGFjayBoYXMgYWxyZWFkeSBhIFN1c3RhaW5l ZCBJUCBhZGRyZXNzLiBXaHkgc2hvdWxkIHRoZSBJUCBzdGFjayB0cnkgdG8gZ2V0IGEgbmV3IG9u ZSwgdGhvdWdoDQogdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlZCBzaW1wbHkg4oCcU3VzdGFpbmVk IElQIGFkZHJlc3MgdHlwZeKAnT8gWW91IGNhc2UgdG9vayBhIHN0ZXAgdG93YXJkcyBhIHNvbHV0 aW9uIHdoZXJlIHlvdSB3YW50IHRvIGRyYXcuIEkgZG9u4oCZdCBleHBlY3QgdGhlIGFjdGlvbiBp cyBnZW5lcmljIHdoZW4gYSBTdXN0YWluZWQgSVAgYWRkcmVzcyB0eXBlIGlzIHJlcXVlc3RlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXNpZGVzLCB5b3UgYXNzdW1wdGlvbiBvbiBJUCBhZGRyZXNz IGFsbG9jYXRpb24gc2VlbXMgbm90IHZhbGlkLiBBIG1vYmlsZSBob3N0IHdvdWxkIGdldCBhbiBJ UCBhZGRyZXNzIHdoYXRldmVyIHRoZSBhbGxvY2F0ZWQgSVAgYWRkcmVzcyB0eXBlIGlzIHdoZW4g aXQgYXR0YWNoZXMgYXQNCiBhIG5ldHdvcmssIHJlZ2FyZGxlc3Mgb2YgYW4gYXBwbGljYXRpb27i gJlzIElQIGFkZHJlc3MgcmVxdWVzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsyDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tzIGxpa2UgSSBkaWQgbm90IGV4cHJl c3MgbXlzZWxmIHdlbGwgZW5vdWdoIChhbmQgZGlkIG5vdCBmdWxseSB1bmRlcnN0YW5kIHlvdXIg cmVwbHkpLiBMZXQgbWUgbGlzdCBzb21lIGV2ZW50cyB0aGF0IG1pZ2h0IGhlbHAgY2xhcmlmeeKA pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Jbml0aWFsIHN0YXRlOiBNb2JpbGUgbm9kZSBpcyBjb25uZWN0 ZWQgdG8gYSBuZXR3b3JrOyBubyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBhbGxvY2F0ZWQuIFRo ZSBJUCBzdGFjayBzZXRzIGEgZmxhZyAoU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkKSBpbmRpY2F0 aW5nDQogdGhhdCBpZiBhbiBhcHBsaWNhdGlvbiByZXF1ZXN0cyBhIFN1c3RhaW5lZCBJUCBhZGRy ZXNzLCBpdCB3aWxsIGhhdmUgdG8gcmVxdWVzdCBvbmUgZnJvbSB0aGUgbmV0d29yay48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RXZlbnQxOiBBbiBhcHBsaWNhdGlvbiB0aGF0IHJlcXVpcmVzIGEgU3VzdGFp bmVkIElQIGFkZHJlc3MgaXMgbGF1bmNoZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFQUCBhY3Rpb246IEFwcCByZXF1ZXN0cyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGZy b20gdGhlIElQIHN0YWNrIHVzaW5nIHRoZSBwcm9wb3NlZCBuZXcgQVBJLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SVAgc3RhY2sgYWN0aW9uOiBTaW5jZSBTdXN0YWluZWRJUEFk ZHJlc3NOZWVkZWQgaXMgc2V0LCByZXF1ZXN0IG9uZSBmcm9tIHRoZSBuZXR3b3JrLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TmV0d29yayBhY3Rpb246IEFzc2lnbmVkIGEgU3Vz dGFpbmVkIElQIGFkZHJlc3MgdG8gdGhlIG1vYmlsZSBub2RlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SVAgc3RhY2sgYWN0aW9uOiAoMSkgTWFyayB0aGUgbmV3IFN1c3RhaW5l ZCBJUCBhZGRyZXNzIGFzIHRoZSBvbmUgdG8gYmUgYXNzb2NpYXRlZCB0byBzdWJzZXF1ZW50IGFw cHM7ICgyKSBSZXNldCBTdXN0YWluZWRJUEFkZHJlc3NOZWVkZWQ7ICgzKUNvbXBsZXRlIHRoZQ0K IEFQSSBhY3Rpb24gYW5kIGFzc29jaWF0ZSB0aGUgbWFya2VkIFN1c3RhaW5lZCBJUCBhZGRyZXNz IHdpdGggdGhhdCBwb3J0IChhcHApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV2ZW50MjogQSBuZXcgYXBw bGljYXRpb24gdGhhdCBhbHNvIHJlcXVpcmVkIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMgbGF1 bmNoZWQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXBwIGFjdGlvbjogQXBw IHJlcXVlc3RzIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgZnJvbSB0aGUgSVAgc3RhY2sgdXNpbmcg dGhlIHByb3Bvc2VkIG5ldyBBUEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklQ IFN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkICZuYnNwO2lzIG5v dCBzZXQsIGNvbXBsZXRlIHRoZSBBUEkgYWN0aW9uIGFuZCBhc3NvY2lhdGUgdGhlIG1hcmtlZCBT dXN0YWluZWQgSVAgYWRkcmVzcyB3aXRoIHRoYXQgcG9ydCAoYXBwKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5FdmVudDM6IFRoZSBtb2JpbGUgbm9kZSBtb3ZlcyB0byBhIG5ldyBMQU48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklQIFN0YWNrIGFjdGlvbjogU2V0IGEgZmxhZyBpbmRpY2F0 aW5nIHRoYXQgdGhlIGN1cnJlbnRseSBhdmFpbGFibGUgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMg bm90IG9wdGltaXplZA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV2ZW50NDogQW4gYXBwbGljYXRpb24g dGhhdCByZXF1aXJlcyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIGxhdW5jaGVkLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BUFAgYWN0aW9uOiBBcHAgcmVxdWVzdHMgYSBT dXN0YWluZWQgSVAgYWRkcmVzcyBmcm9tIHRoZSBJUCBzdGFjayB1c2luZyB0aGUgcHJvcG9zZWQg bmV3IEFQSS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklQIHN0YWNrIGFjdGlv bjogU2luY2UgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkIGlzIHNldCwgcmVxdWVzdCBvbmUgZnJv bSB0aGUgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5ldHdvcmsg YWN0aW9uOiBBc3NpZ25lZCBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHRvIHRoZSBtb2JpbGUgbm9k ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklQIHN0YWNrIGFjdGlvbjogKDEp IE1hcmsgdGhlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBhcyB0aGUgb25lIHRvIGJlIGFzc29j aWF0ZWQgdG8gc3Vic2VxdWVudCBhcHBzOyAoMikgUmVzZXQgU3VzdGFpbmVkSVBBZGRyZXNzTmVl ZGVkOyAoMylDb21wbGV0ZSB0aGUNCiBBUEkgYWN0aW9uIGFuZCBhc3NvY2lhdGUgdGhlIG1hcmtl ZCBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aXRoIHRoYXQgcG9ydCAoYXBwKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Ob3RlIHRoYXQgdGhlIGJlaGF2aW9yIG9mIHRoZSBJUCBzdGFjayBpbiBFdmVudDQgaXMg ZXhhY3RseSBsaWtlIHRoZSBvbmUgaW4gRXZlbnQxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGJl bGlldmUgdGhhdCB0aGlzIGV2ZW50IGlzIHRoZSBvbmUgd2UgaGF2ZSBkaWZmZXJlbnQgb2Ygb3Bp bmlvbnM6IEkgdGhpbmsgdGhhdCB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgSVAgc3RhY2sg aXMgdG8gcmVxdWVzdCBhIG5ldyBTdXN0YWluZWQgSVANCiBhZGRyZXNzIHNpbmNlIGl0IG1vdmVk IHRvIGEgbmV3IExBTiwgYW5kIHlvdSB0aGluayB0aGF0IGl0IHNob3VsZCBkbyBzbyBvbmx5IGlm IHRoZSBhcHBsaWNhdGlvbiBzcGVjaWZpY2FsbHkgcmVxdWVzdHMgYSBuZXcgU3VzdGFpbmVkIElQ IGFkZHJlc3MgdmlhIHRoZSBmbGFnIHlvdSBhcmUgcHJvcG9zaW5nLjwvc3Bhbj48L2I+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZndDsgWW91IGNhbiBzZWUg bXkgYW5zd2VyIGF0IHRoZSBsb3dlc3Qg4oCcJmd0OyZndDvigJ0gaW4gdGhpcyBtYWlsLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzIGEgbWF0dGVyIG9mIGZhY3QsIGlmIHN1Y2ggYSBmbGFn IGlzIGRlZmluZWQsIEkgY2Fubm90IHRoaW5rIG9mIGFuIGV4YW1wbGUgd2hlcmUgaXQgd2lsbCBu b3QgYmUgdXNlZC4gSXQgc2VlbXMgdG8gbWUgdGhhdCBhcHBsaWNhdGlvbnMgd2lsbCBhbHdheXMg cmVxdWVzdCBhIHJlZnJlc2hlZCBTdXN0YWluZWQgSVAgYWRkcmVzcw0KICh3aGVuIHJlcXVlc3Rp bmcgYSBTdXN0YWluZWQgSVAgYWRkcmVzcykuIElmIHRoaXMgaXMgY29ycmVjdCwgdGhlIGZsYWcg aXMgcmVkdW5kYW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgU29tZSBhcHBsaWNhdGlvbnMsIGUuZy4gZW1haWws IHRoYXQgYXJlIG5vdCByZWxhdGl2ZWx5IHJlc3RyaWN0ZWQgZnJvbSBvcHRpbWFsIHJvdXRpbmcg d291bGQgY29uc2lkZXIgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aXRob3V0IGlzc3VpbmcgdGhl IG5ldyBmbGFnLiBNb3JlIGFwcGxpY2F0aW9ucw0KIGJhc2VkIG9uIHN1Y2ggbmV0d29yayBjaGFy YWN0ZXJpc3RpYyBjYW4gYmUgdGhvdWdodCBtb3JlIHRoYW4gZXhwZWN0ZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+QW5kIHN1Y2ggdXNlIG9mIGV4aXN0aW5nIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlz IG5vdCBleHRyYW9yZGluYXJ5LCBzaW5jZSBJUCBhZGRyZXNzIGlzIGEgcmVzb3VyY2UsIGV2ZW4g aW4gdGhlIGNvbnNpZGVyYXRpb24gb2YgSVB2NiBkZXBsb3ltZW50LiBJZiBhcyBtYW55IGFzIGFw cGxpY2F0aW9ucw0KIHJlcXVpcmUgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzLCBpdCB3aWxsIGVu ZCB1cCBpbiBhIGxvdCBvZiBuZXR3b3JrIHJlc291cmNlIGNvbnN1bXB0aW9uIGluIHRoZSBtb2Jp bGl0eSByb3V0ZXJzIHdoZXJlIHRoZSBTdXN0YWluZWQgSVAgYWRkcmVzc2VzIGFyZSBhbmNob3Jl ZCBhcyB0aGUgdGVybWluYWwgbW92ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jmd0OyZndDsyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBh bSBzb3JyeSBidXQgSSBkaXNhZ3JlZSB3aXRoIHRoZSBlbWFpbCBleGFtcGxlLiBJIGNhdGVnb3Jp emUgaXQgYXMgYW4gZXhhbXBsZSBvZiBhbiBhcHBsaWNhdGlvbiB0aGF0IHdpbGwgcmVxdWVzdCBh IE5vbWFkaWMgYWRkcmVzcyBzaW5jZSBpdCBkb2VzIG5vdCBicmVhayB3aGVuIHRoZSBtb2JpbGUg bm9kZSBtb3Zlcw0KIHRvIGEgbmV3IExBTiBhbmQgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIGlzIGNo YW5nZWQuIEl0IHNpbXBseSByZXN0YXJ0cyB0aGUgc29ja2V0IGFuZCBjb250aW51ZSB3aXRoIHRo ZSBuZXcgc291cmNlIElQIGFkZHJlc3MgKHRoZSB1c2VyIHdpbGwgbm90IGV2ZW4gbm90aWNlIHRo aXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsmZ3Q7IFRoZSBleGFtcGxlIHdhcyBnaXZlbiBhcyBhIGJlbmVmaXQg d2hlbiB0aGUgZXhpc3RpbmcgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMgdXNlZC4gWW91IGNvdWxk IGdldCBzb21lIGluc2lnaHQgZnJvbSBzdWNoIGtpbmQgb2YgYXBwbGljYXRpb24gbm90IGNhcmlu ZyBtdWNoIHRoZSByb3V0aW5nDQogZGlzdGFuY2UgZXZlbiBvbiB0aGUgU3VzdGFpbmVkIElQIGFk ZHJlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgb3Ro ZXIgdGV4dCByZWdhcmRpbmcgcmVzb3VyY2UgY29uc3VtcHRpb24uIEkgdGhvdWdodCB3ZSBhZ3Jl ZWQgdGhhdCBldmVuIG9mIGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIHJlcXVlc3RlZCB1 cG9uIGVhY2ggbW92ZW1lbnQgdG8gYSBuZXcgTEFOLCB0aGUgZWZmZWN0DQogb24gSVAgYWRkcmVz cyBhbGxvY2F0aW9uIGlzIG5vdCBzaWduaWZpY2FudC4gT3RoZXJ3aXNlLCBteSBpbml0aWFsIGNv bW1lbnQgb24gYXBwbGljYXRpb25zIGFidXNpbmcgdGhlIG5ldHdvcmsgdXNpbmcgeW91ciBwcm9w b3NlZCBmbGFnLCBiZWNvbWVzIHZhbGlkIGFnYWluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0OyZndDsyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jmd0OyBObywgb3VyIGRyYWZ0IGRpZG7igJl0 IHNheSBzby4gT3VyIGlkZWEgaXMgdGhhdCBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBy ZXF1ZXN0ZWQgdXBvbiByZWNlaXZpbmcgKm5ldyogZmxhZyBmcm9tIGFuIGFwcGxpY2F0aW9uLCBh cyBhIHByZWZlcmVuY2UgZm9yIGEgc291cmNlIGFkZHJlc3MNCiBzZWxlY3Rpb24uIFlvdSBuZWVk IHRvIHJlYWQgb3VyIGRyYWZ0IGNsYXNzaWZ5aW5nIHRoZSBjYXRlZ29yaWVzIG9mIElQIGFkZHJl c3MgcmVxdWVzdCBhZ2Fpbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5CZXNpZGVzLCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aGF0IGlzIGFidXNlZC4gRGVs aXZlcmluZyBpdHMgcHJlZmVyZW5jZSBjYW5ub3QgYmUgYWJ1c2UuIFJlZ2FyZGluZyDigJxhYnVz ZeKAnSwgSSBzZWUgaXQgaW4geW91ciBkZWZhdWx0IGJlaGF2aW9yIHlvdeKAmXJlIGFzc3VtaW5n IGhlcmUuIEluIHlvdXINCiBzY2VuYXJpbywgYSBuZXcgYXBwIGluaXRpYXRlZCBpbiBhIG5ldyBu ZXR3b3JrIHdpbGwgYmUgZm9yY2VkIHRvIHVzZSBhIG5ld2x5IG9idGFpbmVkIFN1c3RhaW5lZCBJ UCBhZGRyZXNzLiBZb3Ugc2VlIHRoYXQ/IFlvdSB0b3RhbGx5IGJsb2NrIHRoZSBwb3NzaWJpbGl0 eSB0byBiZSBjb25zaWRlcmVkIGJ5IHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlv biBydWxlcyBkZWZpbmVkIGluIFJGQzY3MjQuIEJ1dCBpbiBvdXIgZHJhZnQsDQogaW4gY2FzZSB0 aGUgbmVlZCBvZiBhIG5ld2x5IG9idGFpbmVkIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIHByaW9y aXRpemVkLCB0aGUgcHJvcG9zZWQgKm5ldyogZmxhZyBjYW4gYmUgdXNlZCBieSBhcHDigJlzIHJl cXVlc3QsIHRodXMgaXQgd2lsbCBiZSBzZWxlY3RlZCB3aXRoIHByaW9yaXR5Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Q2FuIHlvdSBwcm92aWRlIGEgc2NlbmFyaW8gaW4gd2hpY2ggYW4gYXBwbGlj YXRpb24gd2lsbCBub3QgcmVxdWVzdCB0byByZWZyZXNoIHRoZSBTdXN0YWluZWQgSVAgYWRkcmVz cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZndDsgSXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgZm9ybWVyIGNvbW1lbnRzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgL0Rhbm55PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNlaWwgSmVvbiBbPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzZWlsamVvbkBhdi5pdC5wdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzpz ZWlsamVvbkBhdi5pdC5wdDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDE3OjA4PGJyPg0KPGI+ VG86PC9iPiBNb3NlcywgRGFubnk8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWls dG86ZG1tQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZG1tQGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IEZXOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2Vk IEFQSTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSBEYW5ueSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55IGNvbW1lbnRzPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2Vp bCBKZW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZG1tIFs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TZWlsIEplb248YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDg6MDggUE08YnI+DQo8Yj5Ubzo8L2I+ IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25z IGZvciB0aGUgcHJvcG9zZWQgQVBJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JIGNvdWxkIGF0dGVuZCBETU0gVGh1cnNkYXkgbWVldGluZyB2aWEgTWVldEVjaG8uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SSBjb3VsZCBhbHNvIGhlYXIgc29tZSByYWlzZWQgY29tbWVudHMg YnkgRGFubnkgYW5kIFNvbWVvbmUuIEhlcmUgZ29lcyBhbnN3ZXJzIHRvIHRoZSByYWlzZWQgcXVl c3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZpcnN0LCByZWdhcmRpbmcgdGhlIG5lZWQgb2YgdGhl IHByb3Bvc2VkIEFQSSAoSVBWNl9QUkVGRVJfU1JDX05FVyksPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHVzZSBvZiB0aGUgcHJvcG9zZWQgQVBJIGlz IHN1Z2dlc3RlZCBpbiB0aGUgU1VTVEFJTkVEIElQIGFkZHJlc3MgY2FzZSBpbiB0aGUgZHJhZnQu IE9uIHJlY2VpdmluZyB0aGlzIEFQSSB3aXRoIHRoZSBTVVNUQUlORUQgSVAgYWRkcmVzcyB0eXBl IGF0IHRoZSBJUCBzdGFjaywgaXQgd2lsbA0KIHRyeSB0byBnZXQgYSBuZXcgU1VTVEFJTkVEIElQ IGFkZHJlc3MgaWYgdGhlcmUgaXMgbm8gYXZhaWxhYmxlIGluIHRoZSBjdXJyZW50bHkgYXR0YWNo ZWQgYWNjZXNzIG5ldHdvcmsuIFNvLCBhY3R1YWwgb2J0YWluaW5nIG9mIHRoZSBJUCBhZGRyZXNz IHdpbGwgYmUgdHJpZWQgb25lIHRpbWUgd2hpbGUgYXR0YWNoZWQgYXQgYSBzcGVjaWZpYyBhY2Nl c3MgbmV0d29yay4gRXZlbiBzb21lIGFwcGxpY2F0aW9ucyBwdXQgdGhpcyBBUEkgYWZ0ZXIsIHRo ZQ0KIGFscmVhZHkgb2J0YWluZWQgU1VTVEFJTkVEIElQIHdpbGwgYmUgdXNlZC4gU28sIG5vIHdv cnJpZXMgYWJvdXQgYWJ1c2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+U2Vjb25kIHF1ZXN0aW9uIHNvdW5kZWQgdG8gbWUgbGlrZSB0aGF0IHRoaXMgQVBJ IGlzIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgaG9zdCBjYW4gZ2V0IGEgbmV3IFNVU1RBSU5FRCBJ UCBhZGRyZXNzLCByaWdodD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB0aGUgcXVlc3Rpb24gaXMg cmlnaHQsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhlIHF1ZXN0aW9uIGlzIG1lYW50LCB0 aGF0IGlzIGhvdyB0aGUgaG9zdCBjYW4gZ2V0IGEgbmV3IFNVU1RBSU5FRCBJUCBhZGRyZXNzPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIG9mIHRocmVlIHR5cGVz IG9mIElQIGFkZHJlc3MsIGFuIGFwcGxpY2F0aW9uIHNob3VsZCBzaG93IGl0cyByZXF1aXJlbWVu dCB3aXRoIGFuIEFQSSBhbW9uZyB0aGVtLiBJZiBpdCBpcyB0aGUgU1VTVEFJTkVEIElQIGFkZHJl c3MsIGhvdyBkbyB3ZQ0KIGV4cGVjdCB0aGUgSVAgc3RhY2sgd2lsbCB0cnkgdG8gZ2V0IGEgbmV3 IFNVU1RBSU5FRCBJUCBhZGRyZXNzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkJlc2lkZXMsIHRoZSBwcm9wc29lZCBBUEkgaXMgbm90IHVzZWQgYWxvbmUg YnV0IHdpdGggdGhlIHRocmVlIHR5cGUgQVBJcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+U2VpbCBKZW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpBIG1lbWJlciBvZiB0aGUgSW50ZWwg Q29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzPG86cD48L286cD48L3A+DQo8cD5UaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlh bCBmb3I8YnI+DQp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldyBvciBkaXN0cmlidXRpb248YnI+DQpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50LCBwbGVhc2Ug Y29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy48bzpwPjwvbzpwPjwvcD4N CjxwPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBn cm91cCBvZiBjb21wYW5pZXM8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcjxicj4NCnRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRp c3RyaWJ1dGlvbjxicj4NCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBh bmllczxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yPGJyPg0KdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uPGJy Pg0KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZDxicj4NCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIGFsbCBjb3BpZXMuPG86cD48L286cD48L3A+DQo8cD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpBIG1l bWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzPG86cD48L286 cD48L3A+DQo8cD5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+DQp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb248YnI+DQpieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0K cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5k bW0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPgpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFu aWVzPC9wPgoKPHA+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yPGJyPgp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb248YnI+CmJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+CnJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMu PC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAD6HASMSX106gercor_-- From nobody Mon Apr 13 06:28:02 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB11A00C3 for ; Mon, 13 Apr 2015 06:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 36g0BaewsTeo for ; Mon, 13 Apr 2015 06:27:54 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 C8A171A00CD for ; Mon, 13 Apr 2015 06:27:53 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so102169291pab.2 for ; Mon, 13 Apr 2015 06:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=+79Bq/eQmm0v7Nq+hHyvOuz88G9XhFynmP81JZEn3E8=; b=lDfuQk+vEyCSuc62vRv60SP67hsYxh4HMe4qcroKtQ+rsmW7YpjCs2gAE4jT1yZIPS 2RbjZrdu1+d2a/RpmuBC7lhhL746sNJn6LzbNN93g2x678twaf5Ogb2UH3RhC1JwF64+ WbC2UzoEWAth4U7uJc1DiRY7iov1NRtqjI71G8H3pjDnjbg57BP6zWoQYF9xghVx+pF2 rqFYgzsTtH2Km6LZUSyesciMSO0X7hXUl9NWIIh3P0GzrHYr1Mvumd/8z4EfxV/V7CP2 e6HSNJZ5C9CTD/tNSA8d+3rIayawSfFs+1FsmgRU1gT43SmV6Rit1JAYz6QXoehdmZVg x+PA== X-Received: by 10.68.218.103 with SMTP id pf7mr12689012pbc.32.1428931673407; Mon, 13 Apr 2015 06:27:53 -0700 (PDT) Received: from [9.3.156.134] ([192.200.112.37]) by mx.google.com with ESMTPSA id je11sm7326859pbd.65.2015.04.13.06.27.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 06:27:51 -0700 (PDT) Date: Mon, 13 Apr 2015 21:27:43 +0800 From: Dapeng Liu To: =?utf-8?Q?Moses=2C_Danny?= Message-ID: <3255582297BB4CA98657F833BECF9AFE@gmail.com> In-Reply-To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552bc44f_39ee015c_e7" Archived-At: Cc: "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:28:01 -0000 --552bc44f_39ee015c_e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC= =9A > What is simpler. Can you be more specific=3F What are you comparing=3F > =20 > =20 > =20 =E2=80=9Csimilar=22 not =E2=80=9Csimpler=E2=80=9D. Regards, Dapeng Liu =20 > =20 > =20 > Thanks, > /Danny > =20 > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > Sent: Monday, April 13, 2015 15:54 > To: Seil Jeon > Cc: Moses, Danny; dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised questio= ns for the proposed API =20 > =20 > Hello Seil, Danny=EF=BC=9A =20 > =20 > =20 > =20 > =5Bas an individual contributor=5D > =20 > =20 > =20 > You can refer to the following two drafts: > =20 > =20 > =20 > https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 > =20 > http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > =20 > =20 > =20 > Is it the similar idea=3F > =20 > =20 > =20 > -- =20 > =20 > Dapeng Liu > =20 > =20 > =20 > =20 > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC= =9A > > =20 > > Hi Danny, > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom your cases specified as follows; > > =20 > > =20 > > =20 > > =20 > > =20 > > =E2=80=9CI am thinking of two places that might require an update: > > =20 > > =20 > > When an application chooses not to specify a source address (but requ= est a specific type) > > =20 > > =20 > > When an application wishes to choose the source address from a provid= ed list. > > =20 > > =20 > > =E2=80=9C > > =20 > > =20 > > =20 > > =20 > > =20 > > I don=E2=80=99t understand the meaning of the second case. Why should= an application wish to choose a source address from a list=3F What I hav= e talked about was about allowing the default source address selection ru= les, which will be determined in the IP stack when an application is init= iated with the destination address. I think we don=E2=80=99t need to touc= h it. > > =20 > > =20 > > =20 > > =20 > > =20 > > The point is an application will totally assign the default source ad= dress selection mechanism based on only type request but with no preferen= ce, or will request with the preference of a new Sustained IP address as = well as type request. In the former case, if there is one or multiple Sus= tained IP addresses, the IP stack will try to pick up one. Or the IP stac= k will try to get a new one. In the latter case, the IP stack will consid= er a newly obtained Sustained IP address all the time, if the requested p= reference value is not less than other preferences defined in the default= source address selection rules. > > =20 > > =20 > > =20 > > =20 > > =20 > > The need of the proposed flag and main criteria to be considered were= already covered with case studies in the draft. > > =20 > > =20 > > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 > > =20 > > =20 > > =20 > > =20 > > =20 > > So, for productive discussion, I would like to suggest that you check= our draft again please and bring your questions if there is something we= ird or should be updated with additional cases. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Best Regards, > > =20 > > =20 > > =20 > > =20 > > =20 > > Seil Jeon > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > Sent: Sunday, April 12, 2015 1:49 PM > > To: Seil Jeon > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > You have a good point here. > > =20 > > =20 > > =20 > > =20 > > =20 > > Now I understand the need for the flag you are proposing =21=21=21 =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > We need to take a better look at R=46C 6724 and figure out if we need= to update it. > > =20 > > =20 > > =20 > > =20 > > =20 > > I am thinking of two places that might require an update: > > =20 > > =20 > > When an application chooses not to specify a source address (but requ= est a specific type) > > =20 > > =20 > > When an application wishes to choose the source address from a provid= ed list. > > =20 > > =20 > > =20 > > =20 > > =20 > > When the application indicates the desired address type, but chooses = not to specify the source address (from a list provided by the IP stack),= the stack should allocate a source IP address according to the address-t= ype requested by the application. In this case, we should consider adding= text to describe the behavior for Sustained IP addresses. Specifically, = if there are several Sustained IP addresses allocated to the mobile host,= whether to choose one of them, or to have the mobile host request a new = one from the network (as a result of a mobility event =E2=80=93 for examp= le). > > =20 > > =20 > > =20 > > =20 > > =20 > > When an application wishes to chooses the source address from the ava= ilable list (obtained by getaddrinfo()), there are some alternative appro= aches we should consider: > > =20 > > =20 > > Enhance getaddrinfo() enabling the application to specify the require= d address type, and return the list of source addresses that are of that = type (Nomadic, Sustained, =46ixed or DontCare), or - =20 > > =20 > > =20 > > Provide the list of addresses with an indication of their type (Nomad= ic, Sustained, =46ixed or TypeUnknown) and an indication of whether each = address is New (allocated after the last handoff event) or Old (allocated= before the last handoff event) > > =20 > > =20 > > Some other approach=E2=80=A6 > > =20 > > =20 > > =20 > > =20 > > =20 > > The flag is need here, to enable the application to request a new IP = address (if the returned list only contain 'Old' addresses) =21=21=21 > > =20 > > =20 > > =20 > > =20 > > =20 > > I agree that we should discuss this. How about bringing it to the nex= t 'Mobility Exposure and Selection WT' call=3F > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > /Danny > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > Sent: Sunday, April 05, 2015 17:08 > > To: Moses, Danny > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Danny, > > =20 > > =20 > > =20 > > =20 > > =20 > > Meeting is always good, even with you by f-to-f. But in the discussio= n, the main issue is whether we will allow the default source address sel= ection rules defined in R=46C6724 for selecting a Sustained IP address am= ong several ones or fundamentally block them for a specific reason raised= by a DMM need. The latter approach is not reasonable no matter how I try= to think of.it (http://of.it). > > =20 > > =20 > > If an application has the specific preference of a newly obtained Sus= tained IP address, it uses the proposed API. > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards. > > =20 > > =20 > > Seil > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > Sent: Sunday, April 05, 2015 12:23 PM > > To: Seil Jeon > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Seil, > > =20 > > =20 > > =20 > > =20 > > =20 > > By now we have been discussing this for quite some time and clearly w= e did not succeed in convincing each other. > > =20 > > =20 > > I suggest we try again when we have a chance to meet face to face. Me= anwhile, let's listen to what other people have to say on this matter. > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > /Danny > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > Sent: Sunday, April 05, 2015 01:16 > > To: Moses, Danny > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Resent. > > =20 > > =20 > > =20 > > =20 > > =20 > > Seil > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > Sent: Saturday, April 04, 2015 1:35 PM > > To: 'Moses, Danny' > > Cc: 'dmm=40ietf.org (mailto:dmm=40ietf.org)' > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Danny, > > =20 > > =20 > > =20 > > =20 > > =20 > > See the inline please. I marked current replies with =E2=80=9C>>=E2=80= =9D and previous replies with =E2=80=9C>=E2=80=9D for you to catch them e= asily. > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > Seil > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > Sent: Thursday, April 02, 2015 2:16 PM > > To: Seil Jeon > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Seil, > > =20 > > =20 > > =20 > > =20 > > =20 > > Please see my replies (surrounded by >>2) to yours. > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > /Danny > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > Sent: Tuesday, March 31, 2015 15:23 > > To: Moses, Danny > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Danny, > > =20 > > =20 > > =20 > > =20 > > =20 > > See the inline please. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Seil Jeon =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > Sent: Monday, March 30, 2015 4:44 PM > > To: Seil Jeon > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed AP= I > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Seil, > > =20 > > =20 > > =20 > > =20 > > =20 > > As to the potential of abuse: > > =20 > > =20 > > Yes, I see your point and you are correct. If the IP stack will not r= equest a sustained IP address more than once after each movement to a new= LAN (with a different prefix), than there will be no abuse. > > =20 > > =20 > > =20 > > =20 > > =20 > > > Yes, it=E2=80=99s true. Thanks for correction. > > =20 > > =20 > > =20 > > =20 > > =20 > > As to the second comment, please let me elaborate: > > =20 > > =20 > > One potential implementation of the IP stack in the host, can be to r= equest a Nomadic IP address and a Sustained IP address whenever connecti= ng to a network, and whenever moving to a new LAN, regardless if there ar= e any applications requesting any addresses. This way, whenever an applic= ation is launched and requests either a Nomadic or Sustained IP address, = the stack can provide one without having to issue a request to the networ= k. In this case, there is no need for this flag from the application. > > =20 > > =20 > > =20 > > =20 > > =20 > > > Decision of which type of IP address by default will be depending o= n the IP pool management policy by operators. You case may correspond to = one of them. What if only the Nomadic IP address is basically allocated u= pon a network attachment=3F That is, a lot of applications require mere I= nternet connectivity without session continuity support. So, the Sustaine= d IP address will be requested on demand, and the proposed flag will be u= sed to get a new Sustained IP address by expressing the explicit request = by an application. > > =20 > > =20 > > =20 > > =20 > > =20 > > >>2 > > =20 > > =20 > > As I mentioned at the beginning of the description =E2=80=93 it is a = description of one alternative. I am not assuming it is the only scenario= . > > =20 > > =20 > > Yes, I agree that many apps require only Nomadic IP addresses, but in= this example, the IP stack in the host pre-allocates both Nomadic and Su= stained IP addresses upon attachment=E2=80=A6 > > =20 > > =20 > > =20 > > =20 > > =20 > > >> As I said, it could be, but not as general one. The proposed API i= s useful through the explicit expression for any potential scenarios. > > =20 > > =20 > > =20 > > =20 > > =20 > > Yes, we can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or =46ixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag =E2=80=93 see my repl= y to the second item below=E2=80=A6 > > =20 > > =20 > > >>2 > > =20 > > =20 > > =20 > > =20 > > =20 > > >> My answer was already given in following answer in previous email.= > > =20 > > =20 > > =20 > > =20 > > =20 > > Another potential implementation of the IP stack in the host is not t= o request IP addresses in advance. In that case, it will issue a request = for a Nomadic IP address or a Sustained IP address the first time an appl= ication requests one and use it for subsequent requests as long as it is = not moving to a different LAN. Once it moves, it will again request a new= IP address (Nomadic or Sustained =E2=80=93 according to what is required= ) after receiving the first request from any application. In this case as= well, there is no need for this flag. > > =20 > > =20 > > =20 > > =20 > > =20 > > > Another application requested just Sustained IP address while the I= P stack has already a Sustained IP address. Why should the IP stack try t= o get a new one, though the application indicated simply =E2=80=9CSustain= ed IP address type=E2=80=9D=3F You case took a step towards a solution wh= ere you want to draw. I don=E2=80=99t expect the action is generic when a= Sustained IP address type is requested. > > =20 > > =20 > > Besides, you assumption on IP address allocation seems not valid. A m= obile host would get an IP address whatever the allocated IP address type= is when it attaches at a network, regardless of an application=E2=80=99s= IP address request. > > =20 > > =20 > > =20 > > =20 > > =20 > > >>2 =20 > > =20 > > =20 > > Looks like I did not express myself well enough (and did not fully un= derstand your reply). Let me list some events that might help clarify=E2=80= =A6 > > =20 > > =20 > > =20 > > =20 > > =20 > > Initial state: Mobile node is connected to a network; no Sustained IP= address is allocated. The IP stack sets a flag (SustainedIPAddressNeeded= ) indicating that if an application requests a Sustained IP address, it w= ill have to request one from the network. > > =20 > > =20 > > =20 > > =20 > > =20 > > Event1: An application that requires a Sustained IP address is launch= ed. =20 > > =20 > > =20 > > APP action: App requests a Sustained IP address from the IP stack usi= ng the proposed new API. > > =20 > > =20 > > IP stack action: Since SustainedIPAddressNeeded is set, request one f= rom the network. > > =20 > > =20 > > Network action: Assigned a Sustained IP address to the mobile node. > > =20 > > =20 > > IP stack action: (1) Mark the new Sustained IP address as the one to = be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)= Complete the API action and associate the marked Sustained IP address wit= h that port (app) > > =20 > > =20 > > =20 > > =20 > > =20 > > Event2: A new application that also required a Sustained IP address i= s launched =20 > > =20 > > =20 > > App action: App requests a Sustained IP address from the IP stack usi= ng the proposed new API > > =20 > > =20 > > IP Stack action: Since SustainedIPAddressNeeded is not set, complete= the API action and associate the marked Sustained IP address with that p= ort (app) > > =20 > > =20 > > =20 > > =20 > > =20 > > Event3: The mobile node moves to a new LAN > > =20 > > =20 > > IP Stack action: Set a flag indicating that the currently available S= ustained IP address is not optimized =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Event4: An application that requires a Sustained IP address is launch= ed. =20 > > =20 > > =20 > > APP action: App requests a Sustained IP address from the IP stack usi= ng the proposed new API. > > =20 > > =20 > > IP stack action: Since SustainedIPAddressNeeded is set, request one f= rom the network. > > =20 > > =20 > > Network action: Assigned a Sustained IP address to the mobile node. > > =20 > > =20 > > IP stack action: (1) Mark the new Sustained IP address as the one to = be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)= Complete the API action and associate the marked Sustained IP address wit= h that port (app) > > =20 > > =20 > > =20 > > =20 > > =20 > > Note that the behavior of the IP stack in Event4 is exactly like the = one in Event1. > > =20 > > =20 > > =20 > > =20 > > =20 > > I believe that this event is the one we have different of opinions: I= think that the default behavior of the IP stack is to request a new Sust= ained IP address since it moved to a new LAN, and you think that it shoul= d do so only if the application specifically requests a new Sustained IP = address via the flag you are proposing. > > =20 > > =20 > > >>2 > > =20 > > =20 > > =20 > > =20 > > =20 > > >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this m= ail. > > =20 > > =20 > > =20 > > =20 > > =20 > > As a matter of fact, if such a flag is defined, I cannot think of an = example where it will not be used. It seems to me that applications will = always request a refreshed Sustained IP address (when requesting a Sustai= ned IP address). If this is correct, the flag is redundant. > > =20 > > =20 > > =20 > > =20 > > =20 > > > Some applications, e.g. email, that are not relatively restricted f= rom optimal routing would consider a Sustained IP address without issuing= the new flag. More applications based on such network characteristic can= be thought more than expected. > > =20 > > =20 > > And such use of existing Sustained IP address is not extraordinary, s= ince IP address is a resource, even in the consideration of IPv6 deployme= nt. If as many as applications require new Sustained IP address, it will = end up in a lot of network resource consumption in the mobility routers w= here the Sustained IP addresses are anchored as the terminal moves. > > =20 > > =20 > > >>2 > > =20 > > =20 > > I am sorry but I disagree with the email example. I categorize it as = an example of an application that will request a Nomadic address since it= does not break when the mobile node moves to a new LAN and the source IP= address is changed. It simply restarts the socket and continue with the = new source IP address (the user will not even notice this). > > =20 > > =20 > > =20 > > =20 > > =20 > > >> The example was given as a benefit when the existing Sustained IP = address is used. You could get some insight from such kind of application= not caring much the routing distance even on the Sustained IP address. > > =20 > > =20 > > =20 > > =20 > > =20 > > I did not understand the other text regarding resource consumption. I= thought we agreed that even of a new Sustained IP address is requested u= pon each movement to a new LAN, the effect on IP address allocation is no= t significant. Otherwise, my initial comment on applications abusing the = network using your proposed flag, becomes valid again > > =20 > > =20 > > >>2 > > =20 > > =20 > > =20 > > =20 > > =20 > > >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustai= ned IP address is requested upon receiving *new* flag from an application= , as a preference for a source address selection. You need to read our dr= aft classifying the categories of IP address request again. > > =20 > > =20 > > =20 > > =20 > > =20 > > Besides, I don=E2=80=99t understand what is abused. Delivering its pr= eference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it in = your default behavior you=E2=80=99re assuming here. In your scenario, a n= ew app initiated in a new network will be forced to use a newly obtained = Sustained IP address. You see that=3F You totally block the possibility t= o be considered by the default source address selection rules defined in = R=46C6724. But in our draft, in case the need of a newly obtained Sustain= ed IP address is prioritized, the proposed *new* flag can be used by app=E2= =80=99s request, thus it will be selected with priority. > > =20 > > =20 > > =20 > > =20 > > =20 > > Can you provide a scenario in which an application will not request t= o refresh the Sustained IP address=3F > > =20 > > =20 > > =20 > > =20 > > =20 > > > It was mentioned in the former comments. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > /Danny > > =20 > > =20 > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > Sent: Monday, March 30, 2015 17:08 > > To: Moses, Danny > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: =46W: =5BDMM=5D Answer on raised questions for the proposed = API > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi Danny, > > =20 > > =20 > > =20 > > =20 > > =20 > > Any comments=3F > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > Seil Jeon > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil Jeo= n > > Sent: Thursday, March 26, 2015 8:08 PM > > To: dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: =5BDMM=5D Answer on raised questions for the proposed API > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Hi, > > =20 > > =20 > > =20 > > =20 > > =20 > > I could attend DMM Thursday meeting via MeetEcho. > > =20 > > =20 > > I could also hear some raised comments by Danny and Someone. Here goe= s answers to the raised questions. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =46irst, regarding the need of the proposed API (IPV6=5FPRE=46ER=5FSR= C=5FNEW), > > =20 > > =20 > > =20 > > =20 > > =20 > > The use of the proposed API is suggested in the SUSTAINED IP address = case in the draft. On receiving this API with the SUSTAINED IP address ty= pe at the IP stack, it will try to get a new SUSTAINED IP address if ther= e is no available in the currently attached access network. So, actual ob= taining of the IP address will be tried one time while attached at a spec= ific access network. Even some applications put this API after, the alrea= dy obtained SUSTAINED IP will be used. So, no worries about abuse. > > =20 > > =20 > > =20 > > =20 > > =20 > > Second question sounded to me like that this API is not needed becaus= e the host can get a new SUSTAINED IP address, right=3F > > =20 > > =20 > > If the question is right, I don=E2=80=99t understand what the questio= n is meant, that is how the host can get a new SUSTAINED IP address=3F > > =20 > > =20 > > Based on the definition of three types of IP address, an application = should show its requirement with an API among them. If it is the SUSTAINE= D IP address, how do we expect the IP stack will try to get a new SUSTAIN= ED IP address=3F > > =20 > > =20 > > =20 > > =20 > > =20 > > Besides, the propsoed API is not used alone but with the three type A= PIs. =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > =20 > > =20 > > =20 > > Seil Jeon > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > ---------------------------------------------------------------------= > > A member of the Intel Corporation group of companies =20 > > 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. =20 > > ---------------------------------------------------------------------= > > A member of the Intel Corporation group of companies =20 > > 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. =20 > > ---------------------------------------------------------------------= > > A member of the Intel Corporation group of companies =20 > > 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. =20 > > ---------------------------------------------------------------------= > > A member of the Intel Corporation group of companies =20 > > 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. =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > =20 > > dmm mailing list > > =20 > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > =20 > > https://www.ietf.org/mailman/listinfo/dmm > > =20 > > =20 > > =20 > =20 > =20 > =20 > =20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies =20 > 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. =20 --552bc44f_39ee015c_e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D= =889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC=9A

<=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

What i= s simpler. Can you be more specific=3F What are you comparing=3F

=E2=80=9Csimilar=22 not =E2=80= =9Csimpler=E2=80=9D.


Regards,
Dapeng Liu
 

&= nbsp;

Thanks= ,

 =             &= nbsp;  /Danny

&= nbsp;

=46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; dmm=40ietf= .org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A= =5BDMM=5D Answer on raised questions for the pr= oposed API

 

Hello Seil, Danny=EF=BC=9A

 

=5Bas an individual contributor=5D

 

You can refer to the following two drafts:<= o:p>

 

 

Is it the similar idea=3F

 

-- 

Dapeng Liu

 

= =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

Hi Da= nny,

 = ;

=46ro= m your cases specified as follows;

 = ;

=E2=80=9CI am th= inking of two places that might require an update:

When an application cho= oses not to specify a source address (but request a specific type)

When an application wis= hes to choose the source address from a provided list.

=E2=80=9C

 = ;

I don= =E2=80=99t understand the meaning of the second case. Why should an appli= cation wish to choose a source address from a list=3F What I have talked = about was about allowing the default source address selection rules, which will be deter= mined in the IP stack when an application is initiated with the destinati= on address. I think we don=E2=80=99t need to touch it.<= /p>

 = ;

The p= oint is an application will totally assign the default source address sel= ection mechanism based on only type request but with no preference= , or will request with the preference of a new Sustained IP address as wel= l as type request. In the former case, if there = is one or multiple Sustained IP addresses, the IP stack will try to pick up one. Or the IP stack will= try to get a new one. In the latter case, the IP stack will consider a n= ewly obtained Sustained IP address all the time, if the requested prefere= nce value is not less than other preferences defined in the default source address selection rules.=

 = ;

The n= eed of the proposed flag and main criteria to be considered were already = covered with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00=

 = ;

So, f= or productive discussion, I would like to suggest that you check our draf= t again please and bring your questions if there is something weird or sh= ould be updated with additional cases.

 = ;

 = ;

Best = Regards,

 = ;

Seil = Jeon

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

You have a good point here.

 

Now I understand the need for the flag you are proposin= g =21=21=21

 

 

We need to take a better look at R=46C 6724 and figure out= if we need to update it.

 

I am thinking of two places that might require an update:<= /span>

When an application chooses not to specify a source addres= s (but request a specific type)

When an application wishes to choose the source address fr= om a provided list.

 

When the application indicates the desired address type, b= ut chooses not to specify the source address (from a list provided by the= IP stack), the stack should allocate a source IP address according to the address-type requested by the application. In this case= , we should consider adding text to describe the behavior for Sustained I= P addresses. Specifically, if there are several Sustained IP addresses al= located to the mobile host, whether to choose one of them, or to have the mobile host request a new one from th= e network (as a result of a mobility event =E2=80=93 for example).=

 

When an application wishes to chooses the source address f= rom the available list (obtained by getaddrinfo()), there are some altern= ative approaches we should consider:

Enhance getaddrinfo() enabling the application to specify = the required address type, and return the list of source addresses that a= re of that type (Nomadic, Sustained, =46ixed or DontCare), or -

Provide the list of addresses with an indication of their = type (Nomadic, Sustained, =46ixed or TypeUnknown) and an indication of wh= ether each address is New (allocated after the last handoff event) or Old (allocated before the last handoff event)

Some other approach=E2=80=A6

 

The flag is need here, to enable the application to req= uest a new IP address (if the returned list only contain 'Old' addresses)= =21=21=21

 

I agree that we should discuss this. How about bringing it= to the next 'Mobility Exposure and Selection WT' call=3F

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

Meeti= ng is always good, even with you by f-to-f. But in the discussion, the ma= in issue is whether we will allow the default source address selection ru= les defined in R=46C6724 for selecting a Sustained IP address among several = ones or fundamentally block them for a specific reason raised by a DMM ne= ed. The latter approach is not reasonable no matter how I try to think of.it.

If an= application has the specific preference of a newly obtained Sustained IP= address, it uses the proposed API.

 = ;

Regar= ds.

Seil<= /span>

 

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

By now we have been discussing this for quite some time an= d clearly we did not succeed in convincing each other.<= /p>

I suggest we try again when we have a chance to meet face = to face. Meanwhile, let's listen to what other people have to say on this= matter.

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Resen= t.

 = ;

Seil<= /span>

 = ;

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm=40ietf.org'
= Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

See t= he inline please. I marked current replies with =E2=80=9C>>=E2=80=9D= and previous replies with =E2=80=9C>=E2=80=9D for you to catch them e= asily.

 = ;

Regar= ds,

Seil<= /span>

 

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40int= el.com=5D
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

Please see my replies (surrounded by  >>2) to y= ours.

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

See t= he inline please.

 = ;

 = ;

Seil = Jeon

 = ;

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40int= el.com=5D
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

As to the potential of abuse:

Yes, I see your point and you are correct. If the IP stack= will not request a sustained IP address more than once after each moveme= nt to a new LAN (with a different prefix), than there will be no abuse.

 

> Yes, it=E2=80=99s = true. Thanks for correction.

 = ;

As to the second comment, please let me elaborate:<= o:p>

One potential implementation of the IP stack in the host, = can be to request a Nomadic IP address and a  Sustained IP address w= henever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. = This way, whenever an application is launched and requests either a Nomad= ic or Sustained IP address, the stack can provide one without having to i= ssue a request to the network. In this case, there is no need for this flag from the application.

 

> Decision of which = type of IP address by default will be depending on the IP pool management= policy by operators. You case may correspond to one of them. What if onl= y the Nomadic IP address is basically allocated upon a network attachment=3F= That is, a lot of applications require mere Internet connectivity withou= t session continuity support. So, the Sustained IP address will be reques= ted on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit req= uest by an application.

 = ;

>>2

As I mentioned at the beginning of the description =E2=80=93= it is a description of one alternative. I am not assuming it is the only= scenario.

Yes, I agree that many apps require only Nomadic IP addres= ses, but in this example, the IP stack in the host pre-allocates both Nom= adic and Sustained IP addresses upon attachment=E2=80=A6

 

>> As I said, it = could be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 = ;

Yes, we can describe an alternative in which a Nomadic IP = address is pre-allocated upon NW connection (and after every movement to = a new LAN) and a Sustained (and/or =46ixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag =E2= =80=93 see my reply to the second item below=E2=80=A6

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential implementation of the IP stack in the ho= st is not to request IP addresses in advance. In that case, it will issue= a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subseq= uent requests as long as it is not moving to a different LAN. Once it mov= es, it will again request a new IP address (Nomadic or Sustained =E2=80=93= according to what is required) after receiving the first request from any application. In this case as well, there is n= o need for this flag.

 

> Another applicatio= n requested just Sustained IP address while the IP stack has already a Su= stained IP address. Why should the IP stack try to get a new one, though the application indicated simply =E2=80=9CSustained IP address type=E2=80= =9D=3F You case took a step towards a solution where you want to draw. I = don=E2=80=99t expect the action is generic when a Sustained IP address ty= pe is requested.

Besides, you assumption= on IP address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a network, regardless of an application=E2=80=99s IP address request.

 = ;

>&= gt;2

Looks= like I did not express myself well enough (and did not fully understand = your reply). Let me list some events that might help clarify=E2=80=A6

 = ;

Initi= al state: Mobile node is connected to a network; no Sustained IP address = is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicat= ing that if an application requests a Sustained IP address, it will have to = request one from the network.

 = ;

Event= 1: An application that requires a Sustained IP address is launched.

APP a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API.

IP st= ack action: Since SustainedIPAddressNeeded is set, request one from the n= etwork.

Netwo= rk action: Assigned a Sustained IP address to the mobile node.

IP st= ack action: (1) Mark the new Sustained IP address as the one to be associ= ated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete = the API action and associate the marked Sustained IP address with that port = (app)

 = ;

Event= 2: A new application that also required a Sustained IP address is launche= d

App a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API

IP St= ack action: Since SustainedIPAddressNeeded  is not set, complete the= API action and associate the marked Sustained IP address with that port = (app)

 = ;

Event= 3: The mobile node moves to a new LAN

IP St= ack action: Set a flag indicating that the currently available Sustained = IP address is not optimized

 = ;

Event= 4: An application that requires a Sustained IP address is launched.

APP a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API.

IP st= ack action: Since SustainedIPAddressNeeded is set, request one from the n= etwork.

Netwo= rk action: Assigned a Sustained IP address to the mobile node.

IP st= ack action: (1) Mark the new Sustained IP address as the one to be associ= ated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete = the API action and associate the marked Sustained IP address with that port = (app)

 = ;

Note = that the behavior of the IP stack in Event4 is exactly like the one in Ev= ent1.

 = ;

I = believe that this event is the one we have different of opinions: I think= that the default behavior of the IP stack is to request a new Sustained = IP address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>&= gt;2

 = ;

>> You can see my= answer at the lowest =E2=80=9C>>=E2=80=9D in this mail.

 

As a matter of fact, if such a flag is defined, I cannot t= hink of an example where it will not be used. It seems to me that applica= tions will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag i= s redundant.

 

> Some applications,= e.g. email, that are not relatively restricted from optimal routing woul= d consider a Sustained IP address without issuing the new flag. More appl= ications based on such network characteristic can be thought more than expected.<= /span>

And such use of existin= g Sustained IP address is not extraordinary, since IP address is a resour= ce, even in the consideration of IPv6 deployment. If as many as applicati= ons require new Sustained IP address, it will end up in a lot of network res= ource consumption in the mobility routers where the Sustained IP addresse= s are anchored as the terminal moves.

>>2

I am sorry but I disagree with the email example. I catego= rize it as an example of an application that will request a Nomadic addre= ss since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts th= e socket and continue with the new source IP address (the user will not e= ven notice this).

 

>> The example wa= s given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP address.

 = ;

I did not understand the other text regarding resource con= sumption. I thought we agreed that even of a new Sustained IP address is = requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comme= nt on applications abusing the network using your proposed flag, becomes = valid again

>>2

 = ;

>> No, our draft = didn=E2=80=99t say so. Our idea is that a new Sustained IP address is req= uested upon receiving *new* flag from an application, as a preference for= a source address selection. You need to read our draft classifying the categories of IP a= ddress request again.

 

Besides, I don=E2=80=99= t understand what is abused. Delivering its preference cannot be abuse. R= egarding =E2=80=9Cabuse=E2=80=9D, I see it in your default behavior you=E2= =80=99re assuming here. In your scenario, a new app initiated in a new network will be forced to use a n= ewly obtained Sustained IP address. You see that=3F You totally block the= possibility to be considered by the default source address selection rul= es defined in R=46C6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized= , the proposed *new* flag can be used by app=E2=80=99s request, thus it w= ill be selected with priority.

 = ;

Can you provide a scenario in which an application will no= t request to refresh the Sustained IP address=3F

 = ;

> It was mentioned i= n the former comments.

 

 = ;

Regards,

         &nbs= p;      /Danny

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: =46W: =5BDMM=5D Answer on raised questions for the propos= ed API

 

Hi Da= nny,

 = ;

Any c= omments=3F

 = ;

Regar= ds,

Seil = Jeon

 

 = ;

=46= rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm=40ietf.org
Subject: =5BDMM=5D Answer on raised questions for the proposed API=

 

Hi,

 

I could attend DMM Thur= sday meeting via MeetEcho.

I could also hear some = raised comments by Danny and Someone. Here goes answers to the raised que= stions.

 

 

=46irst, regarding the = need of the proposed API (IPV6=5FPRE=46ER=5FSRC=5FNEW),=

 

The use of the proposed= API is suggested in the SUSTAINED IP address case in the draft. On recei= ving this API with the SUSTAINED IP address type at the IP stack, it will= try to get a new SUSTAINED IP address if there is no available in the cu= rrently attached access network. So, actual obtaining of the IP address w= ill be tried one time while attached at a specific access network. Even s= ome applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse.<= /span>

 

Second question sounded= to me like that this API is not needed because the host can get a new SU= STAINED IP address, right=3F

If the question is righ= t, I don=E2=80=99t understand what the question is meant, that is how the= host can get a new SUSTAINED IP address=3F

Based on the definition= of three types of IP address, an application should show its requirement= with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address=3F=

 

Besides, the propsoed A= PI is not used alone but with the three type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F

dmm mailing list

 

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

 =20 =20 =20 =20
=20

--552bc44f_39ee015c_e7-- From nobody Mon Apr 13 06:31:56 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D121A0103 for ; Mon, 13 Apr 2015 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 17zevph8gJYS for ; Mon, 13 Apr 2015 06:31:46 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3EA1A00B6 for ; Mon, 13 Apr 2015 06:31:46 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 13 Apr 2015 06:31:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,570,1422950400"; d="scan'208,217";a="708113840" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 13 Apr 2015 06:31:44 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 13 Apr 2015 14:31:39 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by HASMSX105.ger.corp.intel.com ([169.254.1.224]) with mapi id 14.03.0224.002; Mon, 13 Apr 2015 16:31:38 +0300 From: "Moses, Danny" To: Dapeng Liu Thread-Topic: =?utf-8?B?5Zue5aSN77yaIFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZv?= =?utf-8?Q?r_the_proposed_API?= Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgIJAtYDAlqa+uYCqJZpkgDQIjNOAPZdtnGbTMJ10JuEMu4wyPeW/QD/9OoEcIAWmwOAgAD4wQD//8YOwIAAQ3yA///Mz+A= Date: Mon, 13 Apr 2015 13:31:37 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> <3255582297BB4CA98657F833BECF9AFE@gmail.com> In-Reply-To: <3255582297BB4CA98657F833BECF9AFE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.11] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490DAF6HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9u?= =?utf-8?q?s_for_the_proposed_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:31:53 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAF6HASMSX106gercor_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 QWdhaW4g4oCTIHdoYXQgZXhhY3RseSBhcmUgeW91IGNvbXBhcmluZz8gUGxlYXNlIGJlIG1vcmUg c3BlY2lmaWMuDQoNCkZyb206IERhcGVuZyBMaXUgW21haWx0bzptYXhwYXNzaW9uQGdtYWlsLmNv bV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMTMsIDIwMTUgMTY6MjgNClRvOiBNb3NlcywgRGFubnkN CkNjOiBTZWlsIEplb247IGRtbUBpZXRmLm9yZw0KU3ViamVjdDog5Zue5aSN77yaIFtETU1dIEFu c3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJDQoNCg0KDQrlnKgg MjAxNeW5tDTmnIgxM+aXpSDmmJ/mnJ/kuIDvvIzkuIvljYg5OjIx77yMTW9zZXMsIERhbm55IOWG memBk++8mg0KDQpXaGF0IGlzIHNpbXBsZXIuIENhbiB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gV2hh dCBhcmUgeW91IGNvbXBhcmluZz8NCuKAnHNpbWlsYXIiIG5vdCDigJxzaW1wbGVy4oCdLg0KDQoN ClJlZ2FyZHMsDQpEYXBlbmcgTGl1DQoNCg0KDQoNClRoYW5rcywNCg0KICAgICAgICAgICAgICAg IC9EYW5ueQ0KDQoNCg0KRnJvbTogRGFwZW5nIExpdSBbbWFpbHRvOm1heHBhc3Npb25AZ21haWwu Y29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMywgMjAxNSAxNTo1NA0KVG86IFNlaWwgSmVvbg0K Q2M6IE1vc2VzLCBEYW5ueTsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpTdWJq ZWN0OiDlm57lpI3vvJogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBw cm9wb3NlZCBBUEkNCg0KDQoNCkhlbGxvIFNlaWwsIERhbm5577yaDQoNCg0KDQpbYXMgYW4gaW5k aXZpZHVhbCBjb250cmlidXRvcl0NCg0KDQoNCllvdSBjYW4gcmVmZXIgdG8gdGhlIGZvbGxvd2lu ZyB0d28gZHJhZnRzOg0KDQoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxp dS1kbW0tYWRkcmVzcy1zZWxlY3Rpb24tMDENCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbGl1LWRtbS1tb2JpbGl0eS1hcGktMDINCg0KDQoNCklzIGl0IHRoZSBzaW1pbGFyIGlk ZWE/DQoNCg0KDQotLQ0KDQpEYXBlbmcgTGl1DQoNCg0KDQrlnKggMjAxNeW5tDTmnIgxM+aXpSDm mJ/mnJ/kuIDvvIzkuIrljYg2OjAz77yMU2VpbCBKZW9uIOWGmemBk++8mg0KDQpIaSBEYW5ueSwN Cg0KDQoNCkZyb20geW91ciBjYXNlcyBzcGVjaWZpZWQgYXMgZm9sbG93czsNCg0KDQoNCuKAnEkg YW0gdGhpbmtpbmcgb2YgdHdvIHBsYWNlcyB0aGF0IG1pZ2h0IHJlcXVpcmUgYW4gdXBkYXRlOg0K DQpXaGVuIGFuIGFwcGxpY2F0aW9uIGNob29zZXMgbm90IHRvIHNwZWNpZnkgYSBzb3VyY2UgYWRk cmVzcyAoYnV0IHJlcXVlc3QgYSBzcGVjaWZpYyB0eXBlKQ0KDQpXaGVuIGFuIGFwcGxpY2F0aW9u IHdpc2hlcyB0byBjaG9vc2UgdGhlIHNvdXJjZSBhZGRyZXNzIGZyb20gYSBwcm92aWRlZCBsaXN0 Lg0KDQrigJwNCg0KDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBz ZWNvbmQgY2FzZS4gV2h5IHNob3VsZCBhbiBhcHBsaWNhdGlvbiB3aXNoIHRvIGNob29zZSBhIHNv dXJjZSBhZGRyZXNzIGZyb20gYSBsaXN0PyBXaGF0IEkgaGF2ZSB0YWxrZWQgYWJvdXQgd2FzIGFi b3V0IGFsbG93aW5nIHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBydWxlcywg d2hpY2ggd2lsbCBiZSBkZXRlcm1pbmVkIGluIHRoZSBJUCBzdGFjayB3aGVuIGFuIGFwcGxpY2F0 aW9uIGlzIGluaXRpYXRlZCB3aXRoIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLiBJIHRoaW5rIHdl IGRvbuKAmXQgbmVlZCB0byB0b3VjaCBpdC4NCg0KDQoNClRoZSBwb2ludCBpcyBhbiBhcHBsaWNh dGlvbiB3aWxsIHRvdGFsbHkgYXNzaWduIHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVj dGlvbiBtZWNoYW5pc20gYmFzZWQgb24gb25seSB0eXBlIHJlcXVlc3QgYnV0IHdpdGggbm8gcHJl ZmVyZW5jZSwgb3Igd2lsbCByZXF1ZXN0IHdpdGggdGhlIHByZWZlcmVuY2Ugb2YgYSBuZXcgU3Vz dGFpbmVkIElQIGFkZHJlc3MgYXMgd2VsbCBhcyB0eXBlIHJlcXVlc3QuIEluIHRoZSBmb3JtZXIg Y2FzZSwgaWYgdGhlcmUgaXMgb25lIG9yIG11bHRpcGxlIFN1c3RhaW5lZCBJUCBhZGRyZXNzZXMs IHRoZSBJUCBzdGFjayB3aWxsIHRyeSB0byBwaWNrIHVwIG9uZS4gT3IgdGhlIElQIHN0YWNrIHdp bGwgdHJ5IHRvIGdldCBhIG5ldyBvbmUuIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIElQIHN0YWNr IHdpbGwgY29uc2lkZXIgYSBuZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcyBhbGwg dGhlIHRpbWUsIGlmIHRoZSByZXF1ZXN0ZWQgcHJlZmVyZW5jZSB2YWx1ZSBpcyBub3QgbGVzcyB0 aGFuIG90aGVyIHByZWZlcmVuY2VzIGRlZmluZWQgaW4gdGhlIGRlZmF1bHQgc291cmNlIGFkZHJl c3Mgc2VsZWN0aW9uIHJ1bGVzLg0KDQoNCg0KVGhlIG5lZWQgb2YgdGhlIHByb3Bvc2VkIGZsYWcg YW5kIG1haW4gY3JpdGVyaWEgdG8gYmUgY29uc2lkZXJlZCB3ZXJlIGFscmVhZHkgY292ZXJlZCB3 aXRoIGNhc2Ugc3R1ZGllcyBpbiB0aGUgZHJhZnQuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNpamVvbi1kbW0tdXNlLWNhc2VzLWFwaS1zb3VyY2UtMDANCg0KDQoNClNvLCBm b3IgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uLCBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHlv dSBjaGVjayBvdXIgZHJhZnQgYWdhaW4gcGxlYXNlIGFuZCBicmluZyB5b3VyIHF1ZXN0aW9ucyBp ZiB0aGVyZSBpcyBzb21ldGhpbmcgd2VpcmQgb3Igc2hvdWxkIGJlIHVwZGF0ZWQgd2l0aCBhZGRp dGlvbmFsIGNhc2VzLg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQoNClNlaWwgSmVvbg0K DQoNCg0KRnJvbTogTW9zZXMsIERhbm55IFttYWlsdG86ZGFubnkubW9zZXNAaW50ZWwuY29tXQ0K U2VudDogU3VuZGF5LCBBcHJpbCAxMiwgMjAxNSAxOjQ5IFBNDQpUbzogU2VpbCBKZW9uDQpDYzog ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RNTV0gQW5z d2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkNCg0KDQoNCllvdSBo YXZlIGEgZ29vZCBwb2ludCBoZXJlLg0KDQoNCg0KTm93IEkgdW5kZXJzdGFuZCB0aGUgbmVlZCBm b3IgdGhlIGZsYWcgeW91IGFyZSBwcm9wb3NpbmcgISEhDQoNCg0KDQoNCg0KV2UgbmVlZCB0byB0 YWtlIGEgYmV0dGVyIGxvb2sgYXQgUkZDIDY3MjQgYW5kIGZpZ3VyZSBvdXQgaWYgd2UgbmVlZCB0 byB1cGRhdGUgaXQuDQoNCg0KDQpJIGFtIHRoaW5raW5nIG9mIHR3byBwbGFjZXMgdGhhdCBtaWdo dCByZXF1aXJlIGFuIHVwZGF0ZToNCg0KV2hlbiBhbiBhcHBsaWNhdGlvbiBjaG9vc2VzIG5vdCB0 byBzcGVjaWZ5IGEgc291cmNlIGFkZHJlc3MgKGJ1dCByZXF1ZXN0IGEgc3BlY2lmaWMgdHlwZSkN Cg0KV2hlbiBhbiBhcHBsaWNhdGlvbiB3aXNoZXMgdG8gY2hvb3NlIHRoZSBzb3VyY2UgYWRkcmVz cyBmcm9tIGEgcHJvdmlkZWQgbGlzdC4NCg0KDQoNCldoZW4gdGhlIGFwcGxpY2F0aW9uIGluZGlj YXRlcyB0aGUgZGVzaXJlZCBhZGRyZXNzIHR5cGUsIGJ1dCBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5 IHRoZSBzb3VyY2UgYWRkcmVzcyAoZnJvbSBhIGxpc3QgcHJvdmlkZWQgYnkgdGhlIElQIHN0YWNr KSwgdGhlIHN0YWNrIHNob3VsZCBhbGxvY2F0ZSBhIHNvdXJjZSBJUCBhZGRyZXNzIGFjY29yZGlu ZyB0byB0aGUgYWRkcmVzcy10eXBlIHJlcXVlc3RlZCBieSB0aGUgYXBwbGljYXRpb24uIEluIHRo aXMgY2FzZSwgd2Ugc2hvdWxkIGNvbnNpZGVyIGFkZGluZyB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBi ZWhhdmlvciBmb3IgU3VzdGFpbmVkIElQIGFkZHJlc3Nlcy4gU3BlY2lmaWNhbGx5LCBpZiB0aGVy ZSBhcmUgc2V2ZXJhbCBTdXN0YWluZWQgSVAgYWRkcmVzc2VzIGFsbG9jYXRlZCB0byB0aGUgbW9i aWxlIGhvc3QsIHdoZXRoZXIgdG8gY2hvb3NlIG9uZSBvZiB0aGVtLCBvciB0byBoYXZlIHRoZSBt b2JpbGUgaG9zdCByZXF1ZXN0IGEgbmV3IG9uZSBmcm9tIHRoZSBuZXR3b3JrIChhcyBhIHJlc3Vs dCBvZiBhIG1vYmlsaXR5IGV2ZW50IOKAkyBmb3IgZXhhbXBsZSkuDQoNCg0KDQpXaGVuIGFuIGFw cGxpY2F0aW9uIHdpc2hlcyB0byBjaG9vc2VzIHRoZSBzb3VyY2UgYWRkcmVzcyBmcm9tIHRoZSBh dmFpbGFibGUgbGlzdCAob2J0YWluZWQgYnkgZ2V0YWRkcmluZm8oKSksIHRoZXJlIGFyZSBzb21l IGFsdGVybmF0aXZlIGFwcHJvYWNoZXMgd2Ugc2hvdWxkIGNvbnNpZGVyOg0KDQpFbmhhbmNlIGdl dGFkZHJpbmZvKCkgZW5hYmxpbmcgdGhlIGFwcGxpY2F0aW9uIHRvIHNwZWNpZnkgdGhlIHJlcXVp cmVkIGFkZHJlc3MgdHlwZSwgYW5kIHJldHVybiB0aGUgbGlzdCBvZiBzb3VyY2UgYWRkcmVzc2Vz IHRoYXQgYXJlIG9mIHRoYXQgdHlwZSAoTm9tYWRpYywgU3VzdGFpbmVkLCBGaXhlZCBvciBEb250 Q2FyZSksIG9yIC0NCg0KUHJvdmlkZSB0aGUgbGlzdCBvZiBhZGRyZXNzZXMgd2l0aCBhbiBpbmRp Y2F0aW9uIG9mIHRoZWlyIHR5cGUgKE5vbWFkaWMsIFN1c3RhaW5lZCwgRml4ZWQgb3IgVHlwZVVu a25vd24pIGFuZCBhbiBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgZWFjaCBhZGRyZXNzIGlzIE5ldyAo YWxsb2NhdGVkIGFmdGVyIHRoZSBsYXN0IGhhbmRvZmYgZXZlbnQpIG9yIE9sZCAoYWxsb2NhdGVk IGJlZm9yZSB0aGUgbGFzdCBoYW5kb2ZmIGV2ZW50KQ0KDQpTb21lIG90aGVyIGFwcHJvYWNo4oCm DQoNCg0KDQpUaGUgZmxhZyBpcyBuZWVkIGhlcmUsIHRvIGVuYWJsZSB0aGUgYXBwbGljYXRpb24g dG8gcmVxdWVzdCBhIG5ldyBJUCBhZGRyZXNzIChpZiB0aGUgcmV0dXJuZWQgbGlzdCBvbmx5IGNv bnRhaW4gJ09sZCcgYWRkcmVzc2VzKSAhISENCg0KDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQg ZGlzY3VzcyB0aGlzLiBIb3cgYWJvdXQgYnJpbmdpbmcgaXQgdG8gdGhlIG5leHQgJ01vYmlsaXR5 IEV4cG9zdXJlIGFuZCBTZWxlY3Rpb24gV1QnIGNhbGw/DQoNCg0KDQpSZWdhcmRzLA0KDQogICAg ICAgICAgICAgICAgL0Rhbm55DQoNCg0KDQpGcm9tOiBTZWlsIEplb24gW21haWx0bzpzZWlsamVv bkBhdi5pdC5wdF0NClNlbnQ6IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTc6MDgNClRvOiBNb3Nl cywgRGFubnkNCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQ SQ0KDQoNCg0KSGkgRGFubnksDQoNCg0KDQpNZWV0aW5nIGlzIGFsd2F5cyBnb29kLCBldmVuIHdp dGggeW91IGJ5IGYtdG8tZi4gQnV0IGluIHRoZSBkaXNjdXNzaW9uLCB0aGUgbWFpbiBpc3N1ZSBp cyB3aGV0aGVyIHdlIHdpbGwgYWxsb3cgdGhlIGRlZmF1bHQgc291cmNlIGFkZHJlc3Mgc2VsZWN0 aW9uIHJ1bGVzIGRlZmluZWQgaW4gUkZDNjcyNCBmb3Igc2VsZWN0aW5nIGEgU3VzdGFpbmVkIElQ IGFkZHJlc3MgYW1vbmcgc2V2ZXJhbCBvbmVzIG9yIGZ1bmRhbWVudGFsbHkgYmxvY2sgdGhlbSBm b3IgYSBzcGVjaWZpYyByZWFzb24gcmFpc2VkIGJ5IGEgRE1NIG5lZWQuIFRoZSBsYXR0ZXIgYXBw cm9hY2ggaXMgbm90IHJlYXNvbmFibGUgbm8gbWF0dGVyIGhvdyBJIHRyeSB0byB0aGluayBvZi5p dDxodHRwOi8vb2YuaXQ+Lg0KDQpJZiBhbiBhcHBsaWNhdGlvbiBoYXMgdGhlIHNwZWNpZmljIHBy ZWZlcmVuY2Ugb2YgYSBuZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgdXNl cyB0aGUgcHJvcG9zZWQgQVBJLg0KDQoNCg0KUmVnYXJkcy4NCg0KU2VpbA0KDQoNCg0KDQoNCkZy b206IE1vc2VzLCBEYW5ueSBbbWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbV0NClNlbnQ6IFN1 bmRheSwgQXByaWwgMDUsIDIwMTUgMTI6MjMgUE0NClRvOiBTZWlsIEplb24NCkNjOiBkbW1AaWV0 Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRE1NXSBBbnN3ZXIgb24g cmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkgU2VpbCwNCg0K DQoNCkJ5IG5vdyB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIGZvciBxdWl0ZSBzb21lIHRp bWUgYW5kIGNsZWFybHkgd2UgZGlkIG5vdCBzdWNjZWVkIGluIGNvbnZpbmNpbmcgZWFjaCBvdGhl ci4NCg0KSSBzdWdnZXN0IHdlIHRyeSBhZ2FpbiB3aGVuIHdlIGhhdmUgYSBjaGFuY2UgdG8gbWVl dCBmYWNlIHRvIGZhY2UuIE1lYW53aGlsZSwgbGV0J3MgbGlzdGVuIHRvIHdoYXQgb3RoZXIgcGVv cGxlIGhhdmUgdG8gc2F5IG9uIHRoaXMgbWF0dGVyLg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICAg ICAgICAgICAgIC9EYW5ueQ0KDQoNCg0KRnJvbTogU2VpbCBKZW9uIFttYWlsdG86c2VpbGplb25A YXYuaXQucHRdDQpTZW50OiBTdW5kYXksIEFwcmlsIDA1LCAyMDE1IDAxOjE2DQpUbzogTW9zZXMs IERhbm55DQpDYzogZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBS RTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEkN Cg0KDQoNClJlc2VudC4NCg0KDQoNClNlaWwNCg0KDQoNCkZyb206IFNlaWwgSmVvbiBbbWFpbHRv OnNlaWxqZW9uQGF2Lml0LnB0XQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA0LCAyMDE1IDE6MzUg UE0NClRvOiAnTW9zZXMsIERhbm55Jw0KQ2M6ICdkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRm Lm9yZz4nDQpTdWJqZWN0OiBSRTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9y IHRoZSBwcm9wb3NlZCBBUEkNCg0KDQoNCkhpIERhbm55LA0KDQoNCg0KU2VlIHRoZSBpbmxpbmUg cGxlYXNlLiBJIG1hcmtlZCBjdXJyZW50IHJlcGxpZXMgd2l0aCDigJw+PuKAnSBhbmQgcHJldmlv dXMgcmVwbGllcyB3aXRoIOKAnD7igJ0gZm9yIHlvdSB0byBjYXRjaCB0aGVtIGVhc2lseS4NCg0K DQoNClJlZ2FyZHMsDQoNClNlaWwNCg0KDQoNCg0KDQpGcm9tOiBNb3NlcywgRGFubnkgW21haWx0 bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDIsIDIwMTUg MjoxNiBQTQ0KVG86IFNlaWwgSmVvbg0KQ2M6IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0 aGUgcHJvcG9zZWQgQVBJDQoNCg0KDQpIaSBTZWlsLA0KDQoNCg0KUGxlYXNlIHNlZSBteSByZXBs aWVzIChzdXJyb3VuZGVkIGJ5ICA+PjIpIHRvIHlvdXJzLg0KDQoNCg0KUmVnYXJkcywNCg0KICAg ICAgICAgICAgICAgIC9EYW5ueQ0KDQoNCg0KRnJvbTogU2VpbCBKZW9uIFttYWlsdG86c2VpbGpl b25AYXYuaXQucHRdDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAxNSAxNToyMw0KVG86IE1v c2VzLCBEYW5ueQ0KQ2M6IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVj dDogUkU6IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQg QVBJDQoNCg0KDQpIaSBEYW5ueSwNCg0KDQoNClNlZSB0aGUgaW5saW5lIHBsZWFzZS4NCg0KDQoN Cg0KDQpTZWlsIEplb24NCg0KDQoNCg0KDQpGcm9tOiBNb3NlcywgRGFubnkgW21haWx0bzpkYW5u eS5tb3Nlc0BpbnRlbC5jb21dDQpTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDQ6NDQgUE0N ClRvOiBTZWlsIEplb24NCkNjOiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bv c2VkIEFQSQ0KDQoNCg0KSGkgU2VpbCwNCg0KDQoNCkFzIHRvIHRoZSBwb3RlbnRpYWwgb2YgYWJ1 c2U6DQoNClllcywgSSBzZWUgeW91ciBwb2ludCBhbmQgeW91IGFyZSBjb3JyZWN0LiBJZiB0aGUg SVAgc3RhY2sgd2lsbCBub3QgcmVxdWVzdCBhIHN1c3RhaW5lZCBJUCBhZGRyZXNzIG1vcmUgdGhh biBvbmNlIGFmdGVyIGVhY2ggbW92ZW1lbnQgdG8gYSBuZXcgTEFOICh3aXRoIGEgZGlmZmVyZW50 IHByZWZpeCksIHRoYW4gdGhlcmUgd2lsbCBiZSBubyBhYnVzZS4NCg0KDQoNCj4gWWVzLCBpdOKA mXMgdHJ1ZS4gVGhhbmtzIGZvciBjb3JyZWN0aW9uLg0KDQoNCg0KQXMgdG8gdGhlIHNlY29uZCBj b21tZW50LCBwbGVhc2UgbGV0IG1lIGVsYWJvcmF0ZToNCg0KT25lIHBvdGVudGlhbCBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgSVAgc3RhY2sgaW4gdGhlIGhvc3QsIGNhbiBiZSB0byByZXF1ZXN0IGEg Tm9tYWRpYyBJUCBhZGRyZXNzIGFuZCBhICBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aGVuZXZlciBj b25uZWN0aW5nIHRvIGEgbmV0d29yaywgYW5kIHdoZW5ldmVyIG1vdmluZyB0byBhIG5ldyBMQU4s IHJlZ2FyZGxlc3MgaWYgdGhlcmUgYXJlIGFueSBhcHBsaWNhdGlvbnMgcmVxdWVzdGluZyBhbnkg YWRkcmVzc2VzLiBUaGlzIHdheSwgd2hlbmV2ZXIgYW4gYXBwbGljYXRpb24gaXMgbGF1bmNoZWQg YW5kIHJlcXVlc3RzIGVpdGhlciBhIE5vbWFkaWMgb3IgU3VzdGFpbmVkIElQIGFkZHJlc3MsIHRo ZSBzdGFjayBjYW4gcHJvdmlkZSBvbmUgd2l0aG91dCBoYXZpbmcgdG8gaXNzdWUgYSByZXF1ZXN0 IHRvIHRoZSBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMg ZmxhZyBmcm9tIHRoZSBhcHBsaWNhdGlvbi4NCg0KDQoNCj4gRGVjaXNpb24gb2Ygd2hpY2ggdHlw ZSBvZiBJUCBhZGRyZXNzIGJ5IGRlZmF1bHQgd2lsbCBiZSBkZXBlbmRpbmcgb24gdGhlIElQIHBv b2wgbWFuYWdlbWVudCBwb2xpY3kgYnkgb3BlcmF0b3JzLiBZb3UgY2FzZSBtYXkgY29ycmVzcG9u ZCB0byBvbmUgb2YgdGhlbS4gV2hhdCBpZiBvbmx5IHRoZSBOb21hZGljIElQIGFkZHJlc3MgaXMg YmFzaWNhbGx5IGFsbG9jYXRlZCB1cG9uIGEgbmV0d29yayBhdHRhY2htZW50PyBUaGF0IGlzLCBh IGxvdCBvZiBhcHBsaWNhdGlvbnMgcmVxdWlyZSBtZXJlIEludGVybmV0IGNvbm5lY3Rpdml0eSB3 aXRob3V0IHNlc3Npb24gY29udGludWl0eSBzdXBwb3J0LiBTbywgdGhlIFN1c3RhaW5lZCBJUCBh ZGRyZXNzIHdpbGwgYmUgcmVxdWVzdGVkIG9uIGRlbWFuZCwgYW5kIHRoZSBwcm9wb3NlZCBmbGFn IHdpbGwgYmUgdXNlZCB0byBnZXQgYSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3MgYnkgZXhwcmVz c2luZyB0aGUgZXhwbGljaXQgcmVxdWVzdCBieSBhbiBhcHBsaWNhdGlvbi4NCg0KDQoNCj4+Mg0K DQpBcyBJIG1lbnRpb25lZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBkZXNjcmlwdGlvbiDigJMg aXQgaXMgYSBkZXNjcmlwdGlvbiBvZiBvbmUgYWx0ZXJuYXRpdmUuIEkgYW0gbm90IGFzc3VtaW5n IGl0IGlzIHRoZSBvbmx5IHNjZW5hcmlvLg0KDQpZZXMsIEkgYWdyZWUgdGhhdCBtYW55IGFwcHMg cmVxdWlyZSBvbmx5IE5vbWFkaWMgSVAgYWRkcmVzc2VzLCBidXQgaW4gdGhpcyBleGFtcGxlLCB0 aGUgSVAgc3RhY2sgaW4gdGhlIGhvc3QgcHJlLWFsbG9jYXRlcyBib3RoIE5vbWFkaWMgYW5kIFN1 c3RhaW5lZCBJUCBhZGRyZXNzZXMgdXBvbiBhdHRhY2htZW504oCmDQoNCg0KDQo+PiBBcyBJIHNh aWQsIGl0IGNvdWxkIGJlLCBidXQgbm90IGFzIGdlbmVyYWwgb25lLiBUaGUgcHJvcG9zZWQgQVBJ IGlzIHVzZWZ1bCB0aHJvdWdoIHRoZSBleHBsaWNpdCBleHByZXNzaW9uIGZvciBhbnkgcG90ZW50 aWFsIHNjZW5hcmlvcy4NCg0KDQoNClllcywgd2UgY2FuIGRlc2NyaWJlIGFuIGFsdGVybmF0aXZl IGluIHdoaWNoIGEgTm9tYWRpYyBJUCBhZGRyZXNzIGlzIHByZS1hbGxvY2F0ZWQgdXBvbiBOVyBj b25uZWN0aW9uIChhbmQgYWZ0ZXIgZXZlcnkgbW92ZW1lbnQgdG8gYSBuZXcgTEFOKSBhbmQgYSBT dXN0YWluZWQgKGFuZC9vciBGaXhlZCkgYWRkcmVzcyBpcyBhbGxvY2F0ZWQgb24tZGVtYW5kLiBF dmVuIGluIHN1Y2ggYSBzY2VuYXJpbywgSSBkbyBub3Qgc2VlIGFueSB1c2UgZm9yIHRoaXMgZmxh ZyDigJMgc2VlIG15IHJlcGx5IHRvIHRoZSBzZWNvbmQgaXRlbSBiZWxvd+KApg0KDQo+PjINCg0K DQoNCj4+IE15IGFuc3dlciB3YXMgYWxyZWFkeSBnaXZlbiBpbiBmb2xsb3dpbmcgYW5zd2VyIGlu IHByZXZpb3VzIGVtYWlsLg0KDQoNCg0KQW5vdGhlciBwb3RlbnRpYWwgaW1wbGVtZW50YXRpb24g b2YgdGhlIElQIHN0YWNrIGluIHRoZSBob3N0IGlzIG5vdCB0byByZXF1ZXN0IElQIGFkZHJlc3Nl cyBpbiBhZHZhbmNlLiBJbiB0aGF0IGNhc2UsIGl0IHdpbGwgaXNzdWUgYSByZXF1ZXN0IGZvciBh IE5vbWFkaWMgSVAgYWRkcmVzcyBvciBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHRoZSBmaXJzdCB0 aW1lIGFuIGFwcGxpY2F0aW9uIHJlcXVlc3RzIG9uZSBhbmQgdXNlIGl0IGZvciBzdWJzZXF1ZW50 IHJlcXVlc3RzIGFzIGxvbmcgYXMgaXQgaXMgbm90IG1vdmluZyB0byBhIGRpZmZlcmVudCBMQU4u IE9uY2UgaXQgbW92ZXMsIGl0IHdpbGwgYWdhaW4gcmVxdWVzdCBhIG5ldyBJUCBhZGRyZXNzIChO b21hZGljIG9yIFN1c3RhaW5lZCDigJMgYWNjb3JkaW5nIHRvIHdoYXQgaXMgcmVxdWlyZWQpIGFm dGVyIHJlY2VpdmluZyB0aGUgZmlyc3QgcmVxdWVzdCBmcm9tIGFueSBhcHBsaWNhdGlvbi4gSW4g dGhpcyBjYXNlIGFzIHdlbGwsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgZmxhZy4NCg0KDQoN Cj4gQW5vdGhlciBhcHBsaWNhdGlvbiByZXF1ZXN0ZWQganVzdCBTdXN0YWluZWQgSVAgYWRkcmVz cyB3aGlsZSB0aGUgSVAgc3RhY2sgaGFzIGFscmVhZHkgYSBTdXN0YWluZWQgSVAgYWRkcmVzcy4g V2h5IHNob3VsZCB0aGUgSVAgc3RhY2sgdHJ5IHRvIGdldCBhIG5ldyBvbmUsIHRob3VnaCB0aGUg YXBwbGljYXRpb24gaW5kaWNhdGVkIHNpbXBseSDigJxTdXN0YWluZWQgSVAgYWRkcmVzcyB0eXBl 4oCdPyBZb3UgY2FzZSB0b29rIGEgc3RlcCB0b3dhcmRzIGEgc29sdXRpb24gd2hlcmUgeW91IHdh bnQgdG8gZHJhdy4gSSBkb27igJl0IGV4cGVjdCB0aGUgYWN0aW9uIGlzIGdlbmVyaWMgd2hlbiBh IFN1c3RhaW5lZCBJUCBhZGRyZXNzIHR5cGUgaXMgcmVxdWVzdGVkLg0KDQpCZXNpZGVzLCB5b3Ug YXNzdW1wdGlvbiBvbiBJUCBhZGRyZXNzIGFsbG9jYXRpb24gc2VlbXMgbm90IHZhbGlkLiBBIG1v YmlsZSBob3N0IHdvdWxkIGdldCBhbiBJUCBhZGRyZXNzIHdoYXRldmVyIHRoZSBhbGxvY2F0ZWQg SVAgYWRkcmVzcyB0eXBlIGlzIHdoZW4gaXQgYXR0YWNoZXMgYXQgYSBuZXR3b3JrLCByZWdhcmRs ZXNzIG9mIGFuIGFwcGxpY2F0aW9u4oCZcyBJUCBhZGRyZXNzIHJlcXVlc3QuDQoNCg0KDQo+PjIN Cg0KTG9va3MgbGlrZSBJIGRpZCBub3QgZXhwcmVzcyBteXNlbGYgd2VsbCBlbm91Z2ggKGFuZCBk aWQgbm90IGZ1bGx5IHVuZGVyc3RhbmQgeW91ciByZXBseSkuIExldCBtZSBsaXN0IHNvbWUgZXZl bnRzIHRoYXQgbWlnaHQgaGVscCBjbGFyaWZ54oCmDQoNCg0KDQpJbml0aWFsIHN0YXRlOiBNb2Jp bGUgbm9kZSBpcyBjb25uZWN0ZWQgdG8gYSBuZXR3b3JrOyBubyBTdXN0YWluZWQgSVAgYWRkcmVz cyBpcyBhbGxvY2F0ZWQuIFRoZSBJUCBzdGFjayBzZXRzIGEgZmxhZyAoU3VzdGFpbmVkSVBBZGRy ZXNzTmVlZGVkKSBpbmRpY2F0aW5nIHRoYXQgaWYgYW4gYXBwbGljYXRpb24gcmVxdWVzdHMgYSBT dXN0YWluZWQgSVAgYWRkcmVzcywgaXQgd2lsbCBoYXZlIHRvIHJlcXVlc3Qgb25lIGZyb20gdGhl IG5ldHdvcmsuDQoNCg0KDQpFdmVudDE6IEFuIGFwcGxpY2F0aW9uIHRoYXQgcmVxdWlyZXMgYSBT dXN0YWluZWQgSVAgYWRkcmVzcyBpcyBsYXVuY2hlZC4NCg0KQVBQIGFjdGlvbjogQXBwIHJlcXVl c3RzIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgZnJvbSB0aGUgSVAgc3RhY2sgdXNpbmcgdGhlIHBy b3Bvc2VkIG5ldyBBUEkuDQoNCklQIHN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFpbmVkSVBBZGRy ZXNzTmVlZGVkIGlzIHNldCwgcmVxdWVzdCBvbmUgZnJvbSB0aGUgbmV0d29yay4NCg0KTmV0d29y ayBhY3Rpb246IEFzc2lnbmVkIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgdG8gdGhlIG1vYmlsZSBu b2RlLg0KDQpJUCBzdGFjayBhY3Rpb246ICgxKSBNYXJrIHRoZSBuZXcgU3VzdGFpbmVkIElQIGFk ZHJlc3MgYXMgdGhlIG9uZSB0byBiZSBhc3NvY2lhdGVkIHRvIHN1YnNlcXVlbnQgYXBwczsgKDIp IFJlc2V0IFN1c3RhaW5lZElQQWRkcmVzc05lZWRlZDsgKDMpQ29tcGxldGUgdGhlIEFQSSBhY3Rp b24gYW5kIGFzc29jaWF0ZSB0aGUgbWFya2VkIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHdpdGggdGhh dCBwb3J0IChhcHApDQoNCg0KDQpFdmVudDI6IEEgbmV3IGFwcGxpY2F0aW9uIHRoYXQgYWxzbyBy ZXF1aXJlZCBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIGxhdW5jaGVkDQoNCkFwcCBhY3Rpb246 IEFwcCByZXF1ZXN0cyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGZyb20gdGhlIElQIHN0YWNrIHVz aW5nIHRoZSBwcm9wb3NlZCBuZXcgQVBJDQoNCklQIFN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFp bmVkSVBBZGRyZXNzTmVlZGVkICBpcyBub3Qgc2V0LCBjb21wbGV0ZSB0aGUgQVBJIGFjdGlvbiBh bmQgYXNzb2NpYXRlIHRoZSBtYXJrZWQgU3VzdGFpbmVkIElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBv cnQgKGFwcCkNCg0KDQoNCkV2ZW50MzogVGhlIG1vYmlsZSBub2RlIG1vdmVzIHRvIGEgbmV3IExB Tg0KDQpJUCBTdGFjayBhY3Rpb246IFNldCBhIGZsYWcgaW5kaWNhdGluZyB0aGF0IHRoZSBjdXJy ZW50bHkgYXZhaWxhYmxlIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIG5vdCBvcHRpbWl6ZWQNCg0K DQoNCkV2ZW50NDogQW4gYXBwbGljYXRpb24gdGhhdCByZXF1aXJlcyBhIFN1c3RhaW5lZCBJUCBh ZGRyZXNzIGlzIGxhdW5jaGVkLg0KDQpBUFAgYWN0aW9uOiBBcHAgcmVxdWVzdHMgYSBTdXN0YWlu ZWQgSVAgYWRkcmVzcyBmcm9tIHRoZSBJUCBzdGFjayB1c2luZyB0aGUgcHJvcG9zZWQgbmV3IEFQ SS4NCg0KSVAgc3RhY2sgYWN0aW9uOiBTaW5jZSBTdXN0YWluZWRJUEFkZHJlc3NOZWVkZWQgaXMg c2V0LCByZXF1ZXN0IG9uZSBmcm9tIHRoZSBuZXR3b3JrLg0KDQpOZXR3b3JrIGFjdGlvbjogQXNz aWduZWQgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyB0byB0aGUgbW9iaWxlIG5vZGUuDQoNCklQIHN0 YWNrIGFjdGlvbjogKDEpIE1hcmsgdGhlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBhcyB0aGUg b25lIHRvIGJlIGFzc29jaWF0ZWQgdG8gc3Vic2VxdWVudCBhcHBzOyAoMikgUmVzZXQgU3VzdGFp bmVkSVBBZGRyZXNzTmVlZGVkOyAoMylDb21wbGV0ZSB0aGUgQVBJIGFjdGlvbiBhbmQgYXNzb2Np YXRlIHRoZSBtYXJrZWQgU3VzdGFpbmVkIElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBvcnQgKGFwcCkN Cg0KDQoNCk5vdGUgdGhhdCB0aGUgYmVoYXZpb3Igb2YgdGhlIElQIHN0YWNrIGluIEV2ZW50NCBp cyBleGFjdGx5IGxpa2UgdGhlIG9uZSBpbiBFdmVudDEuDQoNCg0KDQpJIGJlbGlldmUgdGhhdCB0 aGlzIGV2ZW50IGlzIHRoZSBvbmUgd2UgaGF2ZSBkaWZmZXJlbnQgb2Ygb3BpbmlvbnM6IEkgdGhp bmsgdGhhdCB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgSVAgc3RhY2sgaXMgdG8gcmVxdWVz dCBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBzaW5jZSBpdCBtb3ZlZCB0byBhIG5ldyBMQU4s IGFuZCB5b3UgdGhpbmsgdGhhdCBpdCBzaG91bGQgZG8gc28gb25seSBpZiB0aGUgYXBwbGljYXRp b24gc3BlY2lmaWNhbGx5IHJlcXVlc3RzIGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNzIHZpYSB0 aGUgZmxhZyB5b3UgYXJlIHByb3Bvc2luZy4NCg0KPj4yDQoNCg0KDQo+PiBZb3UgY2FuIHNlZSBt eSBhbnN3ZXIgYXQgdGhlIGxvd2VzdCDigJw+PuKAnSBpbiB0aGlzIG1haWwuDQoNCg0KDQpBcyBh IG1hdHRlciBvZiBmYWN0LCBpZiBzdWNoIGEgZmxhZyBpcyBkZWZpbmVkLCBJIGNhbm5vdCB0aGlu ayBvZiBhbiBleGFtcGxlIHdoZXJlIGl0IHdpbGwgbm90IGJlIHVzZWQuIEl0IHNlZW1zIHRvIG1l IHRoYXQgYXBwbGljYXRpb25zIHdpbGwgYWx3YXlzIHJlcXVlc3QgYSByZWZyZXNoZWQgU3VzdGFp bmVkIElQIGFkZHJlc3MgKHdoZW4gcmVxdWVzdGluZyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzKS4g SWYgdGhpcyBpcyBjb3JyZWN0LCB0aGUgZmxhZyBpcyByZWR1bmRhbnQuDQoNCg0KDQo+IFNvbWUg YXBwbGljYXRpb25zLCBlLmcuIGVtYWlsLCB0aGF0IGFyZSBub3QgcmVsYXRpdmVseSByZXN0cmlj dGVkIGZyb20gb3B0aW1hbCByb3V0aW5nIHdvdWxkIGNvbnNpZGVyIGEgU3VzdGFpbmVkIElQIGFk ZHJlc3Mgd2l0aG91dCBpc3N1aW5nIHRoZSBuZXcgZmxhZy4gTW9yZSBhcHBsaWNhdGlvbnMgYmFz ZWQgb24gc3VjaCBuZXR3b3JrIGNoYXJhY3RlcmlzdGljIGNhbiBiZSB0aG91Z2h0IG1vcmUgdGhh biBleHBlY3RlZC4NCg0KQW5kIHN1Y2ggdXNlIG9mIGV4aXN0aW5nIFN1c3RhaW5lZCBJUCBhZGRy ZXNzIGlzIG5vdCBleHRyYW9yZGluYXJ5LCBzaW5jZSBJUCBhZGRyZXNzIGlzIGEgcmVzb3VyY2Us IGV2ZW4gaW4gdGhlIGNvbnNpZGVyYXRpb24gb2YgSVB2NiBkZXBsb3ltZW50LiBJZiBhcyBtYW55 IGFzIGFwcGxpY2F0aW9ucyByZXF1aXJlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgd2ls bCBlbmQgdXAgaW4gYSBsb3Qgb2YgbmV0d29yayByZXNvdXJjZSBjb25zdW1wdGlvbiBpbiB0aGUg bW9iaWxpdHkgcm91dGVycyB3aGVyZSB0aGUgU3VzdGFpbmVkIElQIGFkZHJlc3NlcyBhcmUgYW5j aG9yZWQgYXMgdGhlIHRlcm1pbmFsIG1vdmVzLg0KDQo+PjINCg0KSSBhbSBzb3JyeSBidXQgSSBk aXNhZ3JlZSB3aXRoIHRoZSBlbWFpbCBleGFtcGxlLiBJIGNhdGVnb3JpemUgaXQgYXMgYW4gZXhh bXBsZSBvZiBhbiBhcHBsaWNhdGlvbiB0aGF0IHdpbGwgcmVxdWVzdCBhIE5vbWFkaWMgYWRkcmVz cyBzaW5jZSBpdCBkb2VzIG5vdCBicmVhayB3aGVuIHRoZSBtb2JpbGUgbm9kZSBtb3ZlcyB0byBh IG5ldyBMQU4gYW5kIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBpcyBjaGFuZ2VkLiBJdCBzaW1wbHkg cmVzdGFydHMgdGhlIHNvY2tldCBhbmQgY29udGludWUgd2l0aCB0aGUgbmV3IHNvdXJjZSBJUCBh ZGRyZXNzICh0aGUgdXNlciB3aWxsIG5vdCBldmVuIG5vdGljZSB0aGlzKS4NCg0KDQoNCj4+IFRo ZSBleGFtcGxlIHdhcyBnaXZlbiBhcyBhIGJlbmVmaXQgd2hlbiB0aGUgZXhpc3RpbmcgU3VzdGFp bmVkIElQIGFkZHJlc3MgaXMgdXNlZC4gWW91IGNvdWxkIGdldCBzb21lIGluc2lnaHQgZnJvbSBz dWNoIGtpbmQgb2YgYXBwbGljYXRpb24gbm90IGNhcmluZyBtdWNoIHRoZSByb3V0aW5nIGRpc3Rh bmNlIGV2ZW4gb24gdGhlIFN1c3RhaW5lZCBJUCBhZGRyZXNzLg0KDQoNCg0KSSBkaWQgbm90IHVu ZGVyc3RhbmQgdGhlIG90aGVyIHRleHQgcmVnYXJkaW5nIHJlc291cmNlIGNvbnN1bXB0aW9uLiBJ IHRob3VnaHQgd2UgYWdyZWVkIHRoYXQgZXZlbiBvZiBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVz cyBpcyByZXF1ZXN0ZWQgdXBvbiBlYWNoIG1vdmVtZW50IHRvIGEgbmV3IExBTiwgdGhlIGVmZmVj dCBvbiBJUCBhZGRyZXNzIGFsbG9jYXRpb24gaXMgbm90IHNpZ25pZmljYW50LiBPdGhlcndpc2Us IG15IGluaXRpYWwgY29tbWVudCBvbiBhcHBsaWNhdGlvbnMgYWJ1c2luZyB0aGUgbmV0d29yayB1 c2luZyB5b3VyIHByb3Bvc2VkIGZsYWcsIGJlY29tZXMgdmFsaWQgYWdhaW4NCg0KPj4yDQoNCg0K DQo+PiBObywgb3VyIGRyYWZ0IGRpZG7igJl0IHNheSBzby4gT3VyIGlkZWEgaXMgdGhhdCBhIG5l dyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyByZXF1ZXN0ZWQgdXBvbiByZWNlaXZpbmcgKm5ldyog ZmxhZyBmcm9tIGFuIGFwcGxpY2F0aW9uLCBhcyBhIHByZWZlcmVuY2UgZm9yIGEgc291cmNlIGFk ZHJlc3Mgc2VsZWN0aW9uLiBZb3UgbmVlZCB0byByZWFkIG91ciBkcmFmdCBjbGFzc2lmeWluZyB0 aGUgY2F0ZWdvcmllcyBvZiBJUCBhZGRyZXNzIHJlcXVlc3QgYWdhaW4uDQoNCg0KDQpCZXNpZGVz LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aGF0IGlzIGFidXNlZC4gRGVsaXZlcmluZyBpdHMgcHJl ZmVyZW5jZSBjYW5ub3QgYmUgYWJ1c2UuIFJlZ2FyZGluZyDigJxhYnVzZeKAnSwgSSBzZWUgaXQg aW4geW91ciBkZWZhdWx0IGJlaGF2aW9yIHlvdeKAmXJlIGFzc3VtaW5nIGhlcmUuIEluIHlvdXIg c2NlbmFyaW8sIGEgbmV3IGFwcCBpbml0aWF0ZWQgaW4gYSBuZXcgbmV0d29yayB3aWxsIGJlIGZv cmNlZCB0byB1c2UgYSBuZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcy4gWW91IHNl ZSB0aGF0PyBZb3UgdG90YWxseSBibG9jayB0aGUgcG9zc2liaWxpdHkgdG8gYmUgY29uc2lkZXJl ZCBieSB0aGUgZGVmYXVsdCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMgZGVmaW5lZCBp biBSRkM2NzI0LiBCdXQgaW4gb3VyIGRyYWZ0LCBpbiBjYXNlIHRoZSBuZWVkIG9mIGEgbmV3bHkg b2J0YWluZWQgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMgcHJpb3JpdGl6ZWQsIHRoZSBwcm9wb3Nl ZCAqbmV3KiBmbGFnIGNhbiBiZSB1c2VkIGJ5IGFwcOKAmXMgcmVxdWVzdCwgdGh1cyBpdCB3aWxs IGJlIHNlbGVjdGVkIHdpdGggcHJpb3JpdHkuDQoNCg0KDQpDYW4geW91IHByb3ZpZGUgYSBzY2Vu YXJpbyBpbiB3aGljaCBhbiBhcHBsaWNhdGlvbiB3aWxsIG5vdCByZXF1ZXN0IHRvIHJlZnJlc2gg dGhlIFN1c3RhaW5lZCBJUCBhZGRyZXNzPw0KDQoNCg0KPiBJdCB3YXMgbWVudGlvbmVkIGluIHRo ZSBmb3JtZXIgY29tbWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KICAgICAgICAgICAgICAg IC9EYW5ueQ0KDQpGcm9tOiBTZWlsIEplb24gW21haWx0bzpzZWlsamVvbkBhdi5pdC5wdF0NClNl bnQ6IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgMTc6MDgNClRvOiBNb3NlcywgRGFubnkNCkNjOiBk bW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IEZXOiBbRE1NXSBBbnN3 ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSQ0KDQoNCg0KSGkgRGFu bnksDQoNCg0KDQpBbnkgY29tbWVudHM/DQoNCg0KDQpSZWdhcmRzLA0KDQpTZWlsIEplb24NCg0K DQoNCg0KDQpGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFNlaWwgSmVvbg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDg6MDggUE0NClRv OiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFtETU1dIEFuc3dl ciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJDQoNCg0KDQpIaSwNCg0K DQoNCkkgY291bGQgYXR0ZW5kIERNTSBUaHVyc2RheSBtZWV0aW5nIHZpYSBNZWV0RWNoby4NCg0K SSBjb3VsZCBhbHNvIGhlYXIgc29tZSByYWlzZWQgY29tbWVudHMgYnkgRGFubnkgYW5kIFNvbWVv bmUuIEhlcmUgZ29lcyBhbnN3ZXJzIHRvIHRoZSByYWlzZWQgcXVlc3Rpb25zLg0KDQoNCg0KDQoN CkZpcnN0LCByZWdhcmRpbmcgdGhlIG5lZWQgb2YgdGhlIHByb3Bvc2VkIEFQSSAoSVBWNl9QUkVG RVJfU1JDX05FVyksDQoNCg0KDQpUaGUgdXNlIG9mIHRoZSBwcm9wb3NlZCBBUEkgaXMgc3VnZ2Vz dGVkIGluIHRoZSBTVVNUQUlORUQgSVAgYWRkcmVzcyBjYXNlIGluIHRoZSBkcmFmdC4gT24gcmVj ZWl2aW5nIHRoaXMgQVBJIHdpdGggdGhlIFNVU1RBSU5FRCBJUCBhZGRyZXNzIHR5cGUgYXQgdGhl IElQIHN0YWNrLCBpdCB3aWxsIHRyeSB0byBnZXQgYSBuZXcgU1VTVEFJTkVEIElQIGFkZHJlc3Mg aWYgdGhlcmUgaXMgbm8gYXZhaWxhYmxlIGluIHRoZSBjdXJyZW50bHkgYXR0YWNoZWQgYWNjZXNz IG5ldHdvcmsuIFNvLCBhY3R1YWwgb2J0YWluaW5nIG9mIHRoZSBJUCBhZGRyZXNzIHdpbGwgYmUg dHJpZWQgb25lIHRpbWUgd2hpbGUgYXR0YWNoZWQgYXQgYSBzcGVjaWZpYyBhY2Nlc3MgbmV0d29y ay4gRXZlbiBzb21lIGFwcGxpY2F0aW9ucyBwdXQgdGhpcyBBUEkgYWZ0ZXIsIHRoZSBhbHJlYWR5 IG9idGFpbmVkIFNVU1RBSU5FRCBJUCB3aWxsIGJlIHVzZWQuIFNvLCBubyB3b3JyaWVzIGFib3V0 IGFidXNlLg0KDQoNCg0KU2Vjb25kIHF1ZXN0aW9uIHNvdW5kZWQgdG8gbWUgbGlrZSB0aGF0IHRo aXMgQVBJIGlzIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgaG9zdCBjYW4gZ2V0IGEgbmV3IFNVU1RB SU5FRCBJUCBhZGRyZXNzLCByaWdodD8NCg0KSWYgdGhlIHF1ZXN0aW9uIGlzIHJpZ2h0LCBJIGRv buKAmXQgdW5kZXJzdGFuZCB3aGF0IHRoZSBxdWVzdGlvbiBpcyBtZWFudCwgdGhhdCBpcyBob3cg dGhlIGhvc3QgY2FuIGdldCBhIG5ldyBTVVNUQUlORUQgSVAgYWRkcmVzcz8NCg0KQmFzZWQgb24g dGhlIGRlZmluaXRpb24gb2YgdGhyZWUgdHlwZXMgb2YgSVAgYWRkcmVzcywgYW4gYXBwbGljYXRp b24gc2hvdWxkIHNob3cgaXRzIHJlcXVpcmVtZW50IHdpdGggYW4gQVBJIGFtb25nIHRoZW0uIElm IGl0IGlzIHRoZSBTVVNUQUlORUQgSVAgYWRkcmVzcywgaG93IGRvIHdlIGV4cGVjdCB0aGUgSVAg c3RhY2sgd2lsbCB0cnkgdG8gZ2V0IGEgbmV3IFNVU1RBSU5FRCBJUCBhZGRyZXNzPw0KDQoNCg0K QmVzaWRlcywgdGhlIHByb3Bzb2VkIEFQSSBpcyBub3QgdXNlZCBhbG9uZSBidXQgd2l0aCB0aGUg dGhyZWUgdHlwZSBBUElzLg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KU2VpbCBKZW9u DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRp b24gZ3JvdXAgb2YgY29tcGFuaWVzDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcg0KdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQpieSBv dGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk DQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29w aWVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBn cm91cCBvZiBjb21wYW5pZXMNCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yDQp0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb24NCmJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3Vw IG9mIGNvbXBhbmllcw0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3INCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbg0KYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2Yg Y29tcGFuaWVzDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQpieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkbW0gbWFpbGlu ZyBsaXN0DQoNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBIG1l bWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzDQoNClRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVy aWFsIGZvcg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIg b2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllcwoKVGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9y CnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9y IGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBh bmQgZGVsZXRlIGFsbCBjb3BpZXMuCg== --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAF6HASMSX106gercor_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgVUkgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIFVJIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFnYWluIOKAkyB3aGF0IGV4YWN0bHkgYXJlIHlvdSBjb21wYXJpbmc/IFBsZWFzZSBiZSBt b3JlIHNwZWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g RGFwZW5nIExpdSBbbWFpbHRvOm1heHBhc3Npb25AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgQXByaWwgMTMsIDIwMTUgMTY6Mjg8YnI+DQo8Yj5Ubzo8L2I+IE1vc2VzLCBE YW5ueTxicj4NCjxiPkNjOjwvYj4gU2VpbCBKZW9uOyBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01TIFVJIEdvdGhpYyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lm57lpI3v vJo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBbRE1NXSBBbnN3ZXIgb24gcmFp c2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiNBMEEwQTgiPuWc qDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6I0EwQTBBOCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7lubQ8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7mnIg8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPjEzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6I0EwQTBBOCI+5pelPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojQTBBMEE4Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiNBMEEwQTgiPuaYn+acn+S4gO+8jOS4i+WNiDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6I0EwQTBBOCI+OToyMTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiNBMEEwQTgiPu+8jDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6I0EwQTBBOCI+TW9zZXMsIERhbm55DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7l hpnpgZPvvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxlZnQ6 MGluO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGlzIHNpbXBsZXIuIENh biB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gV2hhdCBhcmUgeW91IGNvbXBhcmluZz88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcc2ltaWxhciZxdW90OyBub3Qg4oCcc2ltcGxlcuKA nS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RGFwZW5nIExpdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxlZnQ6MGluO21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9E YW5ueTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhcGVuZyBMaXUgWzxhIGhyZWY9 Im1haWx0bzptYXhwYXNzaW9uQGdtYWlsLmNvbSI+bWFpbHRvOm1heHBhc3Npb25AZ21haWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDEzLCAyMDE1IDE1OjU0PGJy Pg0KPGI+VG86PC9iPiBTZWlsIEplb248YnI+DQo8Yj5DYzo8L2I+IE1vc2VzLCBEYW5ueTsgPGEg aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgVUkgR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuWbnuWkje+8 mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFtETU1dIEFuc3dlciBvbiByYWlz ZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPkhlbGxvIFNlaWwsIERhbm55PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdv dGhpYyZxdW90OyI+77yaPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij5bYXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvcl08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPllvdSBjYW4gcmVmZXIgdG8gdGhlIGZvbGxvd2lu ZyB0d28gZHJhZnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1kbW0tYWRkcmVz cy1zZWxlY3Rpb24tMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtZG1t LWFkZHJlc3Mtc2VsZWN0aW9uLTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtZG1tLW1vYmlsaXR5LWFwaS0wMiI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWRtbS1tb2JpbGl0eS1hcGktMDI8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij5JcyBpdCB0aGUgc2lt aWxhciBpZGVhPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPkRhcGVuZyBMaXU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7lnKg8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6I0EwQTBBOCI+5bm0PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojQTBBMEE4Ij40PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6I0EwQTBBOCI+5pyIPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojQTBBMEE4Ij4xMzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiNBMEEwQTgiPuaXpTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6I0EwQTBBOCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7mmJ/mnJ/kuIDvvIzkuIrljYg8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPjY6MDM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojQTBBMEE4Ij7vvIw8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiNBMEEwQTgiPlNlaWwgSmVvbg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6I0EwQTBBOCI+5YaZ6YGT77ya PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA4LjBw dDttYXJnaW4tbGVmdDowaW47bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRGFubnksPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkZyb20geW91ciBjYXNlcyBzcGVjaWZpZWQgYXMgZm9sbG93czs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAnDwvc3Bhbj5J IGFtIHRoaW5raW5nIG9mIHR3byBwbGFjZXMgdGhhdCBtaWdodCByZXF1aXJlIGFuIHVwZGF0ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+V2hlbiBhbiBhcHBsaWNhdGlvbiBjaG9vc2VzIG5vdCB0byBzcGVjaWZ5IGEgc291cmNlIGFk ZHJlc3MgKGJ1dCByZXF1ZXN0IGEgc3BlY2lmaWMgdHlwZSk8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+V2hlbiBhbiBhcHBsaWNhdGlv biB3aXNoZXMgdG8gY2hvb3NlIHRoZSBzb3VyY2UgYWRkcmVzcyBmcm9tIGEgcHJvdmlkZWQgbGlz dC48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPuKAnDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdW5kZXJzdGFu ZCB0aGUgbWVhbmluZyBvZiB0aGUgc2Vjb25kIGNhc2UuIFdoeSBzaG91bGQgYW4gYXBwbGljYXRp b24gd2lzaCB0byBjaG9vc2UgYSBzb3VyY2UgYWRkcmVzcyBmcm9tIGEgbGlzdD8gV2hhdCBJIGhh dmUgdGFsa2VkIGFib3V0IHdhcyBhYm91dA0KIGFsbG93aW5nIHRoZSBkZWZhdWx0IHNvdXJjZSBh ZGRyZXNzIHNlbGVjdGlvbiBydWxlcywgd2hpY2ggd2lsbCBiZSBkZXRlcm1pbmVkIGluIHRoZSBJ UCBzdGFjayB3aGVuIGFuIGFwcGxpY2F0aW9uIGlzIGluaXRpYXRlZCB3aXRoIHRoZSBkZXN0aW5h dGlvbiBhZGRyZXNzLiBJIHRoaW5rIHdlIGRvbuKAmXQgbmVlZCB0byB0b3VjaCBpdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIHBvaW50IGlzIGFuIGFwcGxpY2F0aW9uIHdpbGwgdG90YWxseSBhc3Np Z24gdGhlIGRlZmF1bHQgc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uIG1lY2hhbmlzbQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOnJlZCI+YmFzZWQgb24gb25seSB0eXBlIHJlcXVlc3QgYnV0IHdpdGgg bm8gcHJlZmVyZW5jZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4sIG9yIHdpbGwgcmVx dWVzdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+d2l0aCB0aGUgcHJlZmVyZW5jZSBvZiBh IG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBhcyB3ZWxsIGFzIHR5cGUgcmVxdWVzdDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4uIEluIHRoZSBmb3JtZXIgY2FzZSwgaWYgdGhlcmUgaXMg b25lIG9yIG11bHRpcGxlIFN1c3RhaW5lZA0KIElQIGFkZHJlc3NlcywgdGhlIElQIHN0YWNrIHdp bGwgdHJ5IHRvIHBpY2sgdXAgb25lLiBPciB0aGUgSVAgc3RhY2sgd2lsbCB0cnkgdG8gZ2V0IGEg bmV3IG9uZS4gSW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgSVAgc3RhY2sgd2lsbCBjb25zaWRlciBh IG5ld2x5IG9idGFpbmVkIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGFsbCB0aGUgdGltZSwgaWYgdGhl IHJlcXVlc3RlZCBwcmVmZXJlbmNlIHZhbHVlIGlzIG5vdCBsZXNzIHRoYW4gb3RoZXIgcHJlZmVy ZW5jZXMNCiBkZWZpbmVkIGluIHRoZSBkZWZhdWx0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBy dWxlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG5lZWQgb2YgdGhlIHByb3Bvc2VkIGZsYWcgYW5k IG1haW4gY3JpdGVyaWEgdG8gYmUgY29uc2lkZXJlZCB3ZXJlIGFscmVhZHkgY292ZXJlZCB3aXRo IGNhc2Ugc3R1ZGllcyBpbiB0aGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWplb24tZG1t LXVzZS1jYXNlcy1hcGktc291cmNlLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zaWplb24tZG1tLXVzZS1jYXNlcy1hcGktc291cmNlLTAwPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TbywgZm9yIHByb2R1Y3RpdmUgZGlzY3Vzc2lvbiwgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qg dGhhdCB5b3UgY2hlY2sgb3VyIGRyYWZ0IGFnYWluIHBsZWFzZSBhbmQgYnJpbmcgeW91ciBxdWVz dGlvbnMgaWYgdGhlcmUgaXMgc29tZXRoaW5nIHdlaXJkIG9yIHNob3VsZA0KIGJlIHVwZGF0ZWQg d2l0aCBhZGRpdGlvbmFsIGNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNlaWwgSmVvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTW9zZXMsIERhbm55IFs8YSBocmVmPSJtYWlsdG86ZGFubnkubW9zZXNA aW50ZWwuY29tIj5tYWlsdG86ZGFubnkubW9zZXNAaW50ZWwuY29tPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBTdW5kYXksIEFwcmlsIDEyLCAyMDE1IDE6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IFNl aWwgSmVvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1t QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RNTV0gQW5zd2VyIG9uIHJh aXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdSBoYXZlIGEgZ29v ZCBwb2ludCBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdyBJIHVuZGVyc3Rh bmQgdGhlIG5lZWQgZm9yIHRoZSBmbGFnIHlvdSBhcmUgcHJvcG9zaW5nICEhIQ0KPC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPldlIG5lZWQgdG8gdGFrZSBhIGJldHRlciBsb29rIGF0IFJGQyA2NzI0IGFuZCBm aWd1cmUgb3V0IGlmIHdlIG5lZWQgdG8gdXBkYXRlIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkkgYW0gdGhpbmtpbmcgb2YgdHdvIHBsYWNlcyB0aGF0IG1pZ2h0IHJlcXVpcmUgYW4gdXBk YXRlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoZW4gYW4gYXBwbGlj YXRpb24gY2hvb3NlcyBub3QgdG8gc3BlY2lmeSBhIHNvdXJjZSBhZGRyZXNzIChidXQgcmVxdWVz dCBhIHNwZWNpZmljIHR5cGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ V2hlbiBhbiBhcHBsaWNhdGlvbiB3aXNoZXMgdG8gY2hvb3NlIHRoZSBzb3VyY2UgYWRkcmVzcyBm cm9tIGEgcHJvdmlkZWQgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGVuIHRoZSBh cHBsaWNhdGlvbiBpbmRpY2F0ZXMgdGhlIGRlc2lyZWQgYWRkcmVzcyB0eXBlLCBidXQgY2hvb3Nl cyBub3QgdG8gc3BlY2lmeSB0aGUgc291cmNlIGFkZHJlc3MgKGZyb20gYSBsaXN0IHByb3ZpZGVk IGJ5IHRoZSBJUCBzdGFjayksIHRoZSBzdGFjayBzaG91bGQgYWxsb2NhdGUgYSBzb3VyY2UgSVAg YWRkcmVzcw0KIGFjY29yZGluZyB0byB0aGUgYWRkcmVzcy10eXBlIHJlcXVlc3RlZCBieSB0aGUg YXBwbGljYXRpb24uIEluIHRoaXMgY2FzZSwgd2Ugc2hvdWxkIGNvbnNpZGVyIGFkZGluZyB0ZXh0 IHRvIGRlc2NyaWJlIHRoZSBiZWhhdmlvciBmb3IgU3VzdGFpbmVkIElQIGFkZHJlc3Nlcy4gU3Bl Y2lmaWNhbGx5LCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBTdXN0YWluZWQgSVAgYWRkcmVzc2VzIGFs bG9jYXRlZCB0byB0aGUgbW9iaWxlIGhvc3QsIHdoZXRoZXIgdG8NCiBjaG9vc2Ugb25lIG9mIHRo ZW0sIG9yIHRvIGhhdmUgdGhlIG1vYmlsZSBob3N0IHJlcXVlc3QgYSBuZXcgb25lIGZyb20gdGhl IG5ldHdvcmsgKGFzIGEgcmVzdWx0IG9mIGEgbW9iaWxpdHkgZXZlbnQg4oCTIGZvciBleGFtcGxl KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGVuIGFuIGFwcGxpY2F0aW9uIHdpc2hlcyB0 byBjaG9vc2VzIHRoZSBzb3VyY2UgYWRkcmVzcyBmcm9tIHRoZSBhdmFpbGFibGUgbGlzdCAob2J0 YWluZWQgYnkgZ2V0YWRkcmluZm8oKSksIHRoZXJlIGFyZSBzb21lIGFsdGVybmF0aXZlIGFwcHJv YWNoZXMgd2Ugc2hvdWxkIGNvbnNpZGVyOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkVuaGFuY2UgZ2V0YWRkcmluZm8oKSBlbmFibGluZyB0aGUgYXBwbGljYXRpb24gdG8g c3BlY2lmeSB0aGUgcmVxdWlyZWQgYWRkcmVzcyB0eXBlLCBhbmQgcmV0dXJuIHRoZSBsaXN0IG9m IHNvdXJjZSBhZGRyZXNzZXMgdGhhdCBhcmUgb2YgdGhhdCB0eXBlIChOb21hZGljLCBTdXN0YWlu ZWQsIEZpeGVkIG9yIERvbnRDYXJlKSwNCiBvciAtIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlByb3ZpZGUgdGhlIGxpc3Qgb2YgYWRkcmVzc2VzIHdpdGggYW4gaW5kaWNh dGlvbiBvZiB0aGVpciB0eXBlIChOb21hZGljLCBTdXN0YWluZWQsIEZpeGVkIG9yIFR5cGVVbmtu b3duKSBhbmQgYW4gaW5kaWNhdGlvbiBvZiB3aGV0aGVyIGVhY2ggYWRkcmVzcyBpcyBOZXcgKGFs bG9jYXRlZCBhZnRlciB0aGUgbGFzdCBoYW5kb2ZmDQogZXZlbnQpIG9yIE9sZCAoYWxsb2NhdGVk IGJlZm9yZSB0aGUgbGFzdCBoYW5kb2ZmIGV2ZW50KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlNvbWUgb3RoZXIgYXBwcm9hY2jigKY8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5UaGUgZmxhZyBpcyBuZWVkIGhlcmUsIHRvIGVuYWJsZSB0aGUgYXBwbGljYXRpb24g dG8gcmVxdWVzdCBhIG5ldyBJUCBhZGRyZXNzIChpZiB0aGUgcmV0dXJuZWQgbGlzdCBvbmx5IGNv bnRhaW4gJ09sZCcgYWRkcmVzc2VzKSAhISE8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBkaXNjdXNzIHRoaXMuIEhvdyBhYm91dCBicmluZ2luZyBp dCB0byB0aGUgbmV4dCAnPC9zcGFuPjxzcGFuIGxhbmc9IlRSIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+TW9iaWxpdHkgRXhwb3N1cmUgYW5kIFNlbGVjdGlvbiBXVDwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jw0KIGNhbGw/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgL0Rhbm55PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFNlaWwgSmVvbiBbPGEgaHJlZj0ibWFpbHRvOnNlaWxqZW9uQGF2 Lml0LnB0Ij5tYWlsdG86c2VpbGplb25AYXYuaXQucHQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTc6MDg8YnI+DQo8Yj5Ubzo8L2I+IE1vc2VzLCBEYW5u eTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBx dWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRGFubnksPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk1lZXRpbmcgaXMgYWx3YXlzIGdvb2QsIGV2ZW4gd2l0aCB5b3UgYnkgZi10by1mLiBCdXQg aW4gdGhlIGRpc2N1c3Npb24sIHRoZSBtYWluIGlzc3VlIGlzIHdoZXRoZXIgd2Ugd2lsbCBhbGxv dyB0aGUgZGVmYXVsdCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMNCiBkZWZpbmVkIGlu IFJGQzY3MjQgZm9yIHNlbGVjdGluZyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGFtb25nIHNldmVy YWwgb25lcyBvciBmdW5kYW1lbnRhbGx5IGJsb2NrIHRoZW0gZm9yIGEgc3BlY2lmaWMgcmVhc29u IHJhaXNlZCBieSBhIERNTSBuZWVkLiBUaGUgbGF0dGVyIGFwcHJvYWNoIGlzIG5vdCByZWFzb25h YmxlIG5vIG1hdHRlciBob3cgSSB0cnkgdG8gdGhpbmsNCjxhIGhyZWY9Imh0dHA6Ly9vZi5pdCI+ b2YuaXQ8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYW4gYXBwbGlj YXRpb24gaGFzIHRoZSBzcGVjaWZpYyBwcmVmZXJlbmNlIG9mIGEgbmV3bHkgb2J0YWluZWQgU3Vz dGFpbmVkIElQIGFkZHJlc3MsIGl0IHVzZXMgdGhlIHByb3Bvc2VkIEFQSS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmVnYXJkcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNb3NlcywgRGFubnkgWzxhIGhyZWY9Im1h aWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb20iPm1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTI6MjMgUE08 YnI+DQo8Yj5Ubzo8L2I+IFNlaWwgSmVvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv OmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkhpIFNlaWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Qnkgbm93IHdlIGhhdmUgYmVl biBkaXNjdXNzaW5nIHRoaXMgZm9yIHF1aXRlIHNvbWUgdGltZSBhbmQgY2xlYXJseSB3ZSBkaWQg bm90IHN1Y2NlZWQgaW4gY29udmluY2luZyBlYWNoIG90aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkgc3VnZ2VzdCB3ZSB0cnkgYWdhaW4gd2hlbiB3ZSBoYXZlIGEg Y2hhbmNlIHRvIG1lZXQgZmFjZSB0byBmYWNlLiBNZWFud2hpbGUsIGxldCdzIGxpc3RlbiB0byB3 aGF0IG90aGVyIHBlb3BsZSBoYXZlIHRvIHNheSBvbiB0aGlzIG1hdHRlci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvRGFubnk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2VpbCBKZW9uIFs8YSBocmVm PSJtYWlsdG86c2VpbGplb25AYXYuaXQucHQiPm1haWx0bzpzZWlsamVvbkBhdi5pdC5wdDwvYT5d DQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAwNSwgMjAxNSAwMToxNjxicj4NCjxi PlRvOjwvYj4gTW9zZXMsIERhbm55PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZG1t QGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRE1N XSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhlIHByb3Bvc2VkIEFQSTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXNl bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTZWlsIEplb24gWzxhIGhyZWY9Im1haWx0 bzpzZWlsamVvbkBhdi5pdC5wdCI+bWFpbHRvOnNlaWxqZW9uQGF2Lml0LnB0PC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXByaWwgMDQsIDIwMTUgMTozNSBQTTxicj4NCjxiPlRv OjwvYj4gJ01vc2VzLCBEYW5ueSc8YnI+DQo8Yj5DYzo8L2I+ICc8YSBocmVmPSJtYWlsdG86ZG1t QGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+Jzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RN TV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg RGFubnksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlZSB0aGUgaW5saW5lIHBsZWFzZS4gSSBtYXJrZWQg Y3VycmVudCByZXBsaWVzIHdpdGgg4oCcJmd0OyZndDvigJ0gYW5kIHByZXZpb3VzIHJlcGxpZXMg d2l0aCDigJwmZ3Q74oCdIGZvciB5b3UgdG8gY2F0Y2ggdGhlbSBlYXNpbHkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWlsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW9zZXMsIERhbm55IFs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPm1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDAy LCAyMDE1IDI6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IFNlaWwgSmVvbjxicj4NCjxiPkNjOjwvYj4g PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtETU1dIEFuc3dlciBvbiByYWlzZWQgcXVlc3Rp b25zIGZvciB0aGUgcHJvcG9zZWQgQVBJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBTZWlsLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlBsZWFzZSBzZWUgbXkgcmVwbGllcyAoc3Vycm91bmRlZCBieSAmbmJzcDsmZ3Q7 Jmd0OzIpIHRvIHlvdXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC9EYW5ueTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBTZWlsIEplb24gWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2VpbGplb25AYXYu aXQucHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86c2VpbGplb25AYXYuaXQu cHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgMTU6MjM8YnI+DQo8Yj5Ubzo8L2I+IE1vc2Vz LCBEYW5ueTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kbW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtETU1d IEFuc3dlciBvbiByYWlzZWQgcXVlc3Rpb25zIGZvciB0aGUgcHJvcG9zZWQgQVBJPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIERh bm55LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWUgdGhlIGlubGluZSBwbGVhc2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNl aWwgSmVvbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1vc2VzLCBE YW5ueSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkYW5ueS5tb3Nlc0BpbnRlbC5jb20iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZGFubnkubW9zZXNAaW50ZWwuY29tPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgTWFyY2ggMzAsIDIwMTUgNDo0NCBQTTxicj4NCjxiPlRvOjwvYj4gU2VpbCBKZW9uPGJy Pg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RNTV0gQW5zd2VyIG9u IHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIFNlaWwsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgdG8gdGhlIHBvdGVudGlhbCBvZiBhYnVzZTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZZXMsIEkgc2VlIHlvdXIgcG9pbnQg YW5kIHlvdSBhcmUgY29ycmVjdC4gSWYgdGhlIElQIHN0YWNrIHdpbGwgbm90IHJlcXVlc3QgYSBz dXN0YWluZWQgSVAgYWRkcmVzcyBtb3JlIHRoYW4gb25jZSBhZnRlciBlYWNoIG1vdmVtZW50IHRv IGEgbmV3IExBTiAod2l0aCBhIGRpZmZlcmVudCBwcmVmaXgpLCB0aGFuIHRoZXJlDQogd2lsbCBi ZSBubyBhYnVzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IFllcywgaXTigJlzIHRydWUuIFRoYW5rcyBmb3IgY29y cmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzIHRvIHRoZSBzZWNvbmQgY29tbWVudCwg cGxlYXNlIGxldCBtZSBlbGFib3JhdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+T25lIHBvdGVudGlhbCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgSVAgc3RhY2sgaW4gdGhl IGhvc3QsIGNhbiBiZSB0byByZXF1ZXN0IGEgTm9tYWRpYyBJUCBhZGRyZXNzIGFuZCBhICZuYnNw O1N1c3RhaW5lZCBJUCBhZGRyZXNzIHdoZW5ldmVyIGNvbm5lY3RpbmcgdG8gYSBuZXR3b3JrLCBh bmQgd2hlbmV2ZXIgbW92aW5nIHRvIGEgbmV3DQogTEFOLCByZWdhcmRsZXNzIGlmIHRoZXJlIGFy ZSBhbnkgYXBwbGljYXRpb25zIHJlcXVlc3RpbmcgYW55IGFkZHJlc3Nlcy4gVGhpcyB3YXksIHdo ZW5ldmVyIGFuIGFwcGxpY2F0aW9uIGlzIGxhdW5jaGVkIGFuZCByZXF1ZXN0cyBlaXRoZXIgYSBO b21hZGljIG9yIFN1c3RhaW5lZCBJUCBhZGRyZXNzLCB0aGUgc3RhY2sgY2FuIHByb3ZpZGUgb25l IHdpdGhvdXQgaGF2aW5nIHRvIGlzc3VlIGEgcmVxdWVzdCB0byB0aGUgbmV0d29yay4gSW4gdGhp cw0KIGNhc2UsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgZmxhZyBmcm9tIHRoZSBhcHBsaWNh dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7IERlY2lzaW9uIG9mIHdoaWNoIHR5cGUgb2YgSVAgYWRkcmVzcyBi eSBkZWZhdWx0IHdpbGwgYmUgZGVwZW5kaW5nIG9uIHRoZSBJUCBwb29sIG1hbmFnZW1lbnQgcG9s aWN5IGJ5IG9wZXJhdG9ycy4gWW91IGNhc2UgbWF5IGNvcnJlc3BvbmQgdG8gb25lIG9mIHRoZW0u IFdoYXQgaWYgb25seQ0KIHRoZSBOb21hZGljIElQIGFkZHJlc3MgaXMgYmFzaWNhbGx5IGFsbG9j YXRlZCB1cG9uIGEgbmV0d29yayBhdHRhY2htZW50PyBUaGF0IGlzLCBhIGxvdCBvZiBhcHBsaWNh dGlvbnMgcmVxdWlyZSBtZXJlIEludGVybmV0IGNvbm5lY3Rpdml0eSB3aXRob3V0IHNlc3Npb24g Y29udGludWl0eSBzdXBwb3J0LiBTbywgdGhlIFN1c3RhaW5lZCBJUCBhZGRyZXNzIHdpbGwgYmUg cmVxdWVzdGVkIG9uIGRlbWFuZCwgYW5kIHRoZSBwcm9wb3NlZCBmbGFnIHdpbGwNCiBiZSB1c2Vk IHRvIGdldCBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBieSBleHByZXNzaW5nIHRoZSBleHBs aWNpdCByZXF1ZXN0IGJ5IGFuIGFwcGxpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 OyZndDsyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgSSBtZW50aW9u ZWQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgZGVzY3JpcHRpb24g4oCTIGl0IGlzIGEgZGVzY3Jp cHRpb24gb2Ygb25lIGFsdGVybmF0aXZlLiBJIGFtIG5vdCBhc3N1bWluZyBpdCBpcyB0aGUgb25s eSBzY2VuYXJpby48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZZXMsIEkg YWdyZWUgdGhhdCBtYW55IGFwcHMgcmVxdWlyZSBvbmx5IE5vbWFkaWMgSVAgYWRkcmVzc2VzLCBi dXQgaW4gdGhpcyBleGFtcGxlLCB0aGUgSVAgc3RhY2sgaW4gdGhlIGhvc3QgcHJlLWFsbG9jYXRl cyBib3RoIE5vbWFkaWMgYW5kIFN1c3RhaW5lZCBJUCBhZGRyZXNzZXMgdXBvbiBhdHRhY2htZW50 4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jmd0OyZndDsgQXMgSSBzYWlkLCBpdCBjb3VsZCBiZSwgYnV0IG5vdCBhcyBn ZW5lcmFsIG9uZS4gVGhlIHByb3Bvc2VkIEFQSSBpcyB1c2VmdWwgdGhyb3VnaCB0aGUgZXhwbGlj aXQgZXhwcmVzc2lvbiBmb3IgYW55IHBvdGVudGlhbCBzY2VuYXJpb3MuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5ZZXMsIHdlIGNhbiBkZXNjcmliZSBhbiBhbHRlcm5hdGl2ZSBpbiB3aGljaCBhIE5v bWFkaWMgSVAgYWRkcmVzcyBpcyBwcmUtYWxsb2NhdGVkIHVwb24gTlcgY29ubmVjdGlvbiAoYW5k IGFmdGVyIGV2ZXJ5IG1vdmVtZW50IHRvIGEgbmV3IExBTikgYW5kIGEgU3VzdGFpbmVkIChhbmQv b3IgRml4ZWQpIGFkZHJlc3MgaXMgYWxsb2NhdGVkDQogb24tZGVtYW5kLiBFdmVuIGluIHN1Y2gg YSBzY2VuYXJpbywgSSBkbyBub3Qgc2VlIGFueSB1c2UgZm9yIHRoaXMgZmxhZyDigJMgc2VlIG15 IHJlcGx5IHRvIHRoZSBzZWNvbmQgaXRlbSBiZWxvd+KApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmZ3Q7IE15IGFuc3dlciB3YXMg YWxyZWFkeSBnaXZlbiBpbiBmb2xsb3dpbmcgYW5zd2VyIGluIHByZXZpb3VzIGVtYWlsLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFub3RoZXIgcG90ZW50aWFsIGltcGxlbWVudGF0aW9uIG9m IHRoZSBJUCBzdGFjayBpbiB0aGUgaG9zdCBpcyBub3QgdG8gcmVxdWVzdCBJUCBhZGRyZXNzZXMg aW4gYWR2YW5jZS4gSW4gdGhhdCBjYXNlLCBpdCB3aWxsIGlzc3VlIGEgcmVxdWVzdCBmb3IgYSBO b21hZGljIElQIGFkZHJlc3Mgb3IgYSBTdXN0YWluZWQgSVANCiBhZGRyZXNzIHRoZSBmaXJzdCB0 aW1lIGFuIGFwcGxpY2F0aW9uIHJlcXVlc3RzIG9uZSBhbmQgdXNlIGl0IGZvciBzdWJzZXF1ZW50 IHJlcXVlc3RzIGFzIGxvbmcgYXMgaXQgaXMgbm90IG1vdmluZyB0byBhIGRpZmZlcmVudCBMQU4u IE9uY2UgaXQgbW92ZXMsIGl0IHdpbGwgYWdhaW4gcmVxdWVzdCBhIG5ldyBJUCBhZGRyZXNzIChO b21hZGljIG9yIFN1c3RhaW5lZCDigJMgYWNjb3JkaW5nIHRvIHdoYXQgaXMgcmVxdWlyZWQpIGFm dGVyIHJlY2VpdmluZw0KIHRoZSBmaXJzdCByZXF1ZXN0IGZyb20gYW55IGFwcGxpY2F0aW9uLiBJ biB0aGlzIGNhc2UgYXMgd2VsbCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyBmbGFnLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDsgQW5vdGhlciBhcHBsaWNhdGlvbiByZXF1ZXN0ZWQganVzdCBTdXN0YWluZWQgSVAg YWRkcmVzcyB3aGlsZSB0aGUgSVAgc3RhY2sgaGFzIGFscmVhZHkgYSBTdXN0YWluZWQgSVAgYWRk cmVzcy4gV2h5IHNob3VsZCB0aGUgSVAgc3RhY2sgdHJ5IHRvIGdldCBhIG5ldyBvbmUsIHRob3Vn aA0KIHRoZSBhcHBsaWNhdGlvbiBpbmRpY2F0ZWQgc2ltcGx5IOKAnFN1c3RhaW5lZCBJUCBhZGRy ZXNzIHR5cGXigJ0/IFlvdSBjYXNlIHRvb2sgYSBzdGVwIHRvd2FyZHMgYSBzb2x1dGlvbiB3aGVy ZSB5b3Ugd2FudCB0byBkcmF3LiBJIGRvbuKAmXQgZXhwZWN0IHRoZSBhY3Rpb24gaXMgZ2VuZXJp YyB3aGVuIGEgU3VzdGFpbmVkIElQIGFkZHJlc3MgdHlwZSBpcyByZXF1ZXN0ZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+QmVzaWRlcywgeW91IGFzc3VtcHRpb24gb24gSVAgYWRkcmVzcyBhbGxvY2F0 aW9uIHNlZW1zIG5vdCB2YWxpZC4gQSBtb2JpbGUgaG9zdCB3b3VsZCBnZXQgYW4gSVAgYWRkcmVz cyB3aGF0ZXZlciB0aGUgYWxsb2NhdGVkIElQIGFkZHJlc3MgdHlwZSBpcyB3aGVuIGl0IGF0dGFj aGVzIGF0DQogYSBuZXR3b3JrLCByZWdhcmRsZXNzIG9mIGFuIGFwcGxpY2F0aW9u4oCZcyBJUCBh ZGRyZXNzIHJlcXVlc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7Mg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Mb29rcyBsaWtlIEkgZGlkIG5vdCBleHByZXNzIG15c2Vs ZiB3ZWxsIGVub3VnaCAoYW5kIGRpZCBub3QgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIHJlcGx5KS4g TGV0IG1lIGxpc3Qgc29tZSBldmVudHMgdGhhdCBtaWdodCBoZWxwIGNsYXJpZnnigKY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SW5pdGlhbCBzdGF0ZTogTW9iaWxlIG5vZGUgaXMgY29ubmVjdGVkIHRvIGEg bmV0d29yazsgbm8gU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMgYWxsb2NhdGVkLiBUaGUgSVAgc3Rh Y2sgc2V0cyBhIGZsYWcgKFN1c3RhaW5lZElQQWRkcmVzc05lZWRlZCkgaW5kaWNhdGluZw0KIHRo YXQgaWYgYW4gYXBwbGljYXRpb24gcmVxdWVzdHMgYSBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQg d2lsbCBoYXZlIHRvIHJlcXVlc3Qgb25lIGZyb20gdGhlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkV2ZW50MTogQW4gYXBwbGljYXRpb24gdGhhdCByZXF1aXJlcyBhIFN1c3RhaW5lZCBJUCBh ZGRyZXNzIGlzIGxhdW5jaGVkLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B UFAgYWN0aW9uOiBBcHAgcmVxdWVzdHMgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyBmcm9tIHRoZSBJ UCBzdGFjayB1c2luZyB0aGUgcHJvcG9zZWQgbmV3IEFQSS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklQIHN0YWNrIGFjdGlvbjogU2luY2UgU3VzdGFpbmVkSVBBZGRyZXNzTmVl ZGVkIGlzIHNldCwgcmVxdWVzdCBvbmUgZnJvbSB0aGUgbmV0d29yay48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk5ldHdvcmsgYWN0aW9uOiBBc3NpZ25lZCBhIFN1c3RhaW5lZCBJ UCBhZGRyZXNzIHRvIHRoZSBtb2JpbGUgbm9kZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPklQIHN0YWNrIGFjdGlvbjogKDEpIE1hcmsgdGhlIG5ldyBTdXN0YWluZWQgSVAgYWRk cmVzcyBhcyB0aGUgb25lIHRvIGJlIGFzc29jaWF0ZWQgdG8gc3Vic2VxdWVudCBhcHBzOyAoMikg UmVzZXQgU3VzdGFpbmVkSVBBZGRyZXNzTmVlZGVkOyAoMylDb21wbGV0ZSB0aGUNCiBBUEkgYWN0 aW9uIGFuZCBhc3NvY2lhdGUgdGhlIG1hcmtlZCBTdXN0YWluZWQgSVAgYWRkcmVzcyB3aXRoIHRo YXQgcG9ydCAoYXBwKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVudDI6IEEgbmV3IGFwcGxpY2F0aW9u IHRoYXQgYWxzbyByZXF1aXJlZCBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIGxhdW5jaGVkDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFwcCBhY3Rpb246IEFwcCByZXF1ZXN0 cyBhIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGZyb20gdGhlIElQIHN0YWNrIHVzaW5nIHRoZSBwcm9w b3NlZCBuZXcgQVBJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JUCBTdGFjayBh Y3Rpb246IFNpbmNlIFN1c3RhaW5lZElQQWRkcmVzc05lZWRlZCAmbmJzcDtpcyBub3Qgc2V0LCBj b21wbGV0ZSB0aGUgQVBJIGFjdGlvbiBhbmQgYXNzb2NpYXRlIHRoZSBtYXJrZWQgU3VzdGFpbmVk IElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBvcnQgKGFwcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXZlbnQz OiBUaGUgbW9iaWxlIG5vZGUgbW92ZXMgdG8gYSBuZXcgTEFOPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JUCBTdGFjayBhY3Rpb246IFNldCBhIGZsYWcgaW5kaWNhdGluZyB0aGF0 IHRoZSBjdXJyZW50bHkgYXZhaWxhYmxlIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIG5vdCBvcHRp bWl6ZWQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVudDQ6IEFuIGFwcGxpY2F0aW9uIHRoYXQgcmVx dWlyZXMgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBsYXVuY2hlZC4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QVBQIGFjdGlvbjogQXBwIHJlcXVlc3RzIGEgU3VzdGFpbmVk IElQIGFkZHJlc3MgZnJvbSB0aGUgSVAgc3RhY2sgdXNpbmcgdGhlIHByb3Bvc2VkIG5ldyBBUEku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JUCBzdGFjayBhY3Rpb246IFNpbmNl IFN1c3RhaW5lZElQQWRkcmVzc05lZWRlZCBpcyBzZXQsIHJlcXVlc3Qgb25lIGZyb20gdGhlIG5l dHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OZXR3b3JrIGFjdGlvbjog QXNzaWduZWQgYSBTdXN0YWluZWQgSVAgYWRkcmVzcyB0byB0aGUgbW9iaWxlIG5vZGUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JUCBzdGFjayBhY3Rpb246ICgxKSBNYXJrIHRo ZSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3MgYXMgdGhlIG9uZSB0byBiZSBhc3NvY2lhdGVkIHRv IHN1YnNlcXVlbnQgYXBwczsgKDIpIFJlc2V0IFN1c3RhaW5lZElQQWRkcmVzc05lZWRlZDsgKDMp Q29tcGxldGUgdGhlDQogQVBJIGFjdGlvbiBhbmQgYXNzb2NpYXRlIHRoZSBtYXJrZWQgU3VzdGFp bmVkIElQIGFkZHJlc3Mgd2l0aCB0aGF0IHBvcnQgKGFwcCk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm90 ZSB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgSVAgc3RhY2sgaW4gRXZlbnQ0IGlzIGV4YWN0bHkg bGlrZSB0aGUgb25lIGluIEV2ZW50MS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRo YXQgdGhpcyBldmVudCBpcyB0aGUgb25lIHdlIGhhdmUgZGlmZmVyZW50IG9mIG9waW5pb25zOiBJ IHRoaW5rIHRoYXQgdGhlIGRlZmF1bHQgYmVoYXZpb3Igb2YgdGhlIElQIHN0YWNrIGlzIHRvIHJl cXVlc3QgYSBuZXcgU3VzdGFpbmVkIElQDQogYWRkcmVzcyBzaW5jZSBpdCBtb3ZlZCB0byBhIG5l dyBMQU4sIGFuZCB5b3UgdGhpbmsgdGhhdCBpdCBzaG91bGQgZG8gc28gb25seSBpZiB0aGUgYXBw bGljYXRpb24gc3BlY2lmaWNhbGx5IHJlcXVlc3RzIGEgbmV3IFN1c3RhaW5lZCBJUCBhZGRyZXNz IHZpYSB0aGUgZmxhZyB5b3UgYXJlIHByb3Bvc2luZy48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OzI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmZ3Q7IFlvdSBjYW4gc2VlIG15IGFuc3dl ciBhdCB0aGUgbG93ZXN0IOKAnCZndDsmZ3Q74oCdIGluIHRoaXMgbWFpbC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5BcyBhIG1hdHRlciBvZiBmYWN0LCBpZiBzdWNoIGEgZmxhZyBpcyBkZWZp bmVkLCBJIGNhbm5vdCB0aGluayBvZiBhbiBleGFtcGxlIHdoZXJlIGl0IHdpbGwgbm90IGJlIHVz ZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQgYXBwbGljYXRpb25zIHdpbGwgYWx3YXlzIHJlcXVlc3Qg YSByZWZyZXNoZWQgU3VzdGFpbmVkIElQIGFkZHJlc3MNCiAod2hlbiByZXF1ZXN0aW5nIGEgU3Vz dGFpbmVkIElQIGFkZHJlc3MpLiBJZiB0aGlzIGlzIGNvcnJlY3QsIHRoZSBmbGFnIGlzIHJlZHVu ZGFudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7IFNvbWUgYXBwbGljYXRpb25zLCBlLmcuIGVtYWlsLCB0aGF0IGFy ZSBub3QgcmVsYXRpdmVseSByZXN0cmljdGVkIGZyb20gb3B0aW1hbCByb3V0aW5nIHdvdWxkIGNv bnNpZGVyIGEgU3VzdGFpbmVkIElQIGFkZHJlc3Mgd2l0aG91dCBpc3N1aW5nIHRoZSBuZXcgZmxh Zy4gTW9yZSBhcHBsaWNhdGlvbnMNCiBiYXNlZCBvbiBzdWNoIG5ldHdvcmsgY2hhcmFjdGVyaXN0 aWMgY2FuIGJlIHRob3VnaHQgbW9yZSB0aGFuIGV4cGVjdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkFuZCBzdWNoIHVzZSBvZiBleGlzdGluZyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBub3QgZXh0 cmFvcmRpbmFyeSwgc2luY2UgSVAgYWRkcmVzcyBpcyBhIHJlc291cmNlLCBldmVuIGluIHRoZSBj b25zaWRlcmF0aW9uIG9mIElQdjYgZGVwbG95bWVudC4gSWYgYXMgbWFueSBhcyBhcHBsaWNhdGlv bnMNCiByZXF1aXJlIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcywgaXQgd2lsbCBlbmQgdXAgaW4g YSBsb3Qgb2YgbmV0d29yayByZXNvdXJjZSBjb25zdW1wdGlvbiBpbiB0aGUgbW9iaWxpdHkgcm91 dGVycyB3aGVyZSB0aGUgU3VzdGFpbmVkIElQIGFkZHJlc3NlcyBhcmUgYW5jaG9yZWQgYXMgdGhl IHRlcm1pbmFsIG1vdmVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDsmZ3Q7Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYW0gc29ycnkg YnV0IEkgZGlzYWdyZWUgd2l0aCB0aGUgZW1haWwgZXhhbXBsZS4gSSBjYXRlZ29yaXplIGl0IGFz IGFuIGV4YW1wbGUgb2YgYW4gYXBwbGljYXRpb24gdGhhdCB3aWxsIHJlcXVlc3QgYSBOb21hZGlj IGFkZHJlc3Mgc2luY2UgaXQgZG9lcyBub3QgYnJlYWsgd2hlbiB0aGUgbW9iaWxlIG5vZGUgbW92 ZXMNCiB0byBhIG5ldyBMQU4gYW5kIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBpcyBjaGFuZ2VkLiBJ dCBzaW1wbHkgcmVzdGFydHMgdGhlIHNvY2tldCBhbmQgY29udGludWUgd2l0aCB0aGUgbmV3IHNv dXJjZSBJUCBhZGRyZXNzICh0aGUgdXNlciB3aWxsIG5vdCBldmVuIG5vdGljZSB0aGlzKS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mZ3Q7Jmd0OyBUaGUgZXhhbXBsZSB3YXMgZ2l2ZW4gYXMgYSBiZW5lZml0IHdoZW4gdGhl IGV4aXN0aW5nIFN1c3RhaW5lZCBJUCBhZGRyZXNzIGlzIHVzZWQuIFlvdSBjb3VsZCBnZXQgc29t ZSBpbnNpZ2h0IGZyb20gc3VjaCBraW5kIG9mIGFwcGxpY2F0aW9uIG5vdCBjYXJpbmcgbXVjaCB0 aGUgcm91dGluZw0KIGRpc3RhbmNlIGV2ZW4gb24gdGhlIFN1c3RhaW5lZCBJUCBhZGRyZXNzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SSBkaWQgbm90IHVuZGVyc3RhbmQgdGhlIG90aGVyIHRleHQg cmVnYXJkaW5nIHJlc291cmNlIGNvbnN1bXB0aW9uLiBJIHRob3VnaHQgd2UgYWdyZWVkIHRoYXQg ZXZlbiBvZiBhIG5ldyBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyByZXF1ZXN0ZWQgdXBvbiBlYWNo IG1vdmVtZW50IHRvIGEgbmV3IExBTiwgdGhlIGVmZmVjdA0KIG9uIElQIGFkZHJlc3MgYWxsb2Nh dGlvbiBpcyBub3Qgc2lnbmlmaWNhbnQuIE90aGVyd2lzZSwgbXkgaW5pdGlhbCBjb21tZW50IG9u IGFwcGxpY2F0aW9ucyBhYnVzaW5nIHRoZSBuZXR3b3JrIHVzaW5nIHlvdXIgcHJvcG9zZWQgZmxh ZywgYmVjb21lcyB2YWxpZCBhZ2Fpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZndDsmZ3Q7Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZndDsgTm8sIG91ciBkcmFmdCBkaWRu4oCZdCBzYXkgc28u IE91ciBpZGVhIGlzIHRoYXQgYSBuZXcgU3VzdGFpbmVkIElQIGFkZHJlc3MgaXMgcmVxdWVzdGVk IHVwb24gcmVjZWl2aW5nICpuZXcqIGZsYWcgZnJvbSBhbiBhcHBsaWNhdGlvbiwgYXMgYSBwcmVm ZXJlbmNlIGZvciBhIHNvdXJjZSBhZGRyZXNzDQogc2VsZWN0aW9uLiBZb3UgbmVlZCB0byByZWFk IG91ciBkcmFmdCBjbGFzc2lmeWluZyB0aGUgY2F0ZWdvcmllcyBvZiBJUCBhZGRyZXNzIHJlcXVl c3QgYWdhaW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QmVzaWRlcywgSSBkb27igJl0IHVuZGVyc3RhbmQgd2hhdCBpcyBhYnVzZWQuIERlbGl2ZXJpbmcg aXRzIHByZWZlcmVuY2UgY2Fubm90IGJlIGFidXNlLiBSZWdhcmRpbmcg4oCcYWJ1c2XigJ0sIEkg c2VlIGl0IGluIHlvdXIgZGVmYXVsdCBiZWhhdmlvciB5b3XigJlyZSBhc3N1bWluZyBoZXJlLiBJ biB5b3VyDQogc2NlbmFyaW8sIGEgbmV3IGFwcCBpbml0aWF0ZWQgaW4gYSBuZXcgbmV0d29yayB3 aWxsIGJlIGZvcmNlZCB0byB1c2UgYSBuZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVz cy4gWW91IHNlZSB0aGF0PyBZb3UgdG90YWxseSBibG9jayB0aGUgcG9zc2liaWxpdHkgdG8gYmUg Y29uc2lkZXJlZCBieSB0aGUgZGVmYXVsdCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMg ZGVmaW5lZCBpbiBSRkM2NzI0LiBCdXQgaW4gb3VyIGRyYWZ0LA0KIGluIGNhc2UgdGhlIG5lZWQg b2YgYSBuZXdseSBvYnRhaW5lZCBTdXN0YWluZWQgSVAgYWRkcmVzcyBpcyBwcmlvcml0aXplZCwg dGhlIHByb3Bvc2VkICpuZXcqIGZsYWcgY2FuIGJlIHVzZWQgYnkgYXBw4oCZcyByZXF1ZXN0LCB0 aHVzIGl0IHdpbGwgYmUgc2VsZWN0ZWQgd2l0aCBwcmlvcml0eS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkNhbiB5b3UgcHJvdmlkZSBhIHNjZW5hcmlvIGluIHdoaWNoIGFuIGFwcGxpY2F0aW9uIHdp bGwgbm90IHJlcXVlc3QgdG8gcmVmcmVzaCB0aGUgU3VzdGFpbmVkIElQIGFkZHJlc3M/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7IEl0IHdhcyBtZW50aW9uZWQgaW4gdGhlIGZvcm1lciBjb21tZW50cy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC9EYW5ueTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBTZWlsIEplb24gWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2VpbGpl b25AYXYuaXQucHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86c2VpbGplb25A YXYuaXQucHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAzMCwgMjAxNSAxNzowODxicj4NCjxiPlRvOjwvYj4g TW9zZXMsIERhbm55PGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRtbUBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRtbUBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBGVzog W0RNTV0gQW5zd2VyIG9uIHJhaXNlZCBxdWVzdGlvbnMgZm9yIHRoZSBwcm9wb3NlZCBBUEk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgRGFubnksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFueSBjb21tZW50cz88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlaWwgSmVvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRtbSBbPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1h aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2VpbCBKZW9uPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSA4OjA4IFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBbRE1NXSBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9ucyBmb3IgdGhl IHByb3Bvc2VkIEFQSTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBj b3VsZCBhdHRlbmQgRE1NIFRodXJzZGF5IG1lZXRpbmcgdmlhIE1lZXRFY2hvLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkkgY291bGQgYWxzbyBoZWFyIHNvbWUgcmFpc2VkIGNvbW1lbnRzIGJ5IERhbm55 IGFuZCBTb21lb25lLiBIZXJlIGdvZXMgYW5zd2VycyB0byB0aGUgcmFpc2VkIHF1ZXN0aW9ucy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5GaXJzdCwgcmVnYXJkaW5nIHRoZSBuZWVkIG9mIHRoZSBwcm9wb3Nl ZCBBUEkgKElQVjZfUFJFRkVSX1NSQ19ORVcpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSB1c2Ugb2YgdGhlIHByb3Bvc2VkIEFQSSBpcyBzdWdnZXN0 ZWQgaW4gdGhlIFNVU1RBSU5FRCBJUCBhZGRyZXNzIGNhc2UgaW4gdGhlIGRyYWZ0LiBPbiByZWNl aXZpbmcgdGhpcyBBUEkgd2l0aCB0aGUgU1VTVEFJTkVEIElQIGFkZHJlc3MgdHlwZSBhdCB0aGUg SVAgc3RhY2ssIGl0IHdpbGwNCiB0cnkgdG8gZ2V0IGEgbmV3IFNVU1RBSU5FRCBJUCBhZGRyZXNz IGlmIHRoZXJlIGlzIG5vIGF2YWlsYWJsZSBpbiB0aGUgY3VycmVudGx5IGF0dGFjaGVkIGFjY2Vz cyBuZXR3b3JrLiBTbywgYWN0dWFsIG9idGFpbmluZyBvZiB0aGUgSVAgYWRkcmVzcyB3aWxsIGJl IHRyaWVkIG9uZSB0aW1lIHdoaWxlIGF0dGFjaGVkIGF0IGEgc3BlY2lmaWMgYWNjZXNzIG5ldHdv cmsuIEV2ZW4gc29tZSBhcHBsaWNhdGlvbnMgcHV0IHRoaXMgQVBJIGFmdGVyLCB0aGUNCiBhbHJl YWR5IG9idGFpbmVkIFNVU1RBSU5FRCBJUCB3aWxsIGJlIHVzZWQuIFNvLCBubyB3b3JyaWVzIGFi b3V0IGFidXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlNlY29uZCBxdWVzdGlvbiBzb3VuZGVkIHRvIG1lIGxpa2UgdGhhdCB0aGlzIEFQSSBpcyBub3Qg bmVlZGVkIGJlY2F1c2UgdGhlIGhvc3QgY2FuIGdldCBhIG5ldyBTVVNUQUlORUQgSVAgYWRkcmVz cywgcmlnaHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgdGhlIHF1ZXN0aW9uIGlzIHJpZ2h0LCBJ IGRvbuKAmXQgdW5kZXJzdGFuZCB3aGF0IHRoZSBxdWVzdGlvbiBpcyBtZWFudCwgdGhhdCBpcyBo b3cgdGhlIGhvc3QgY2FuIGdldCBhIG5ldyBTVVNUQUlORUQgSVAgYWRkcmVzcz88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5CYXNlZCBvbiB0aGUgZGVmaW5pdGlvbiBvZiB0aHJlZSB0eXBlcyBvZiBJUCBh ZGRyZXNzLCBhbiBhcHBsaWNhdGlvbiBzaG91bGQgc2hvdyBpdHMgcmVxdWlyZW1lbnQgd2l0aCBh biBBUEkgYW1vbmcgdGhlbS4gSWYgaXQgaXMgdGhlIFNVU1RBSU5FRCBJUCBhZGRyZXNzLCBob3cg ZG8gd2UNCiBleHBlY3QgdGhlIElQIHN0YWNrIHdpbGwgdHJ5IHRvIGdldCBhIG5ldyBTVVNUQUlO RUQgSVAgYWRkcmVzcz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5CZXNpZGVzLCB0aGUgcHJvcHNvZWQgQVBJIGlzIG5vdCB1c2VkIGFsb25lIGJ1dCB3aXRo IHRoZSB0aHJlZSB0eXBlIEFQSXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlNlaWwgSmVvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0 aW9uIGdyb3VwIG9mIGNvbXBhbmllczxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yPGJy Pg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcg b3IgZGlzdHJpYnV0aW9uPGJyPg0KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuPG86cD48L286cD48L3A+DQo8cD4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2Yg Y29tcGFuaWVzPG86cD48L286cD48L3A+DQo8cD5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+DQp0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRp b248YnI+DQpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgYWxsIGNvcGllcy48bzpwPjwvbzpwPjwvcD4NCjxwPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXM8bzpw PjwvbzpwPjwvcD4NCjxwPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcjxicj4NCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbjxicj4NCmJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8 YnI+DQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg Y29waWVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQSBtZW1iZXIgb2Yg dGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllczxvOnA+PC9vOnA+PC9wPg0K PHA+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgbWF0ZXJpYWwgZm9yPGJyPg0KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uPGJyPg0KYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPmRtbSBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k bW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzPG86 cD48L286cD48L3A+DQo8cD5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+DQp0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmlidXRpb248YnI+DQpieSBv dGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk PGJyPg0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxs IGNvcGllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPgpBIG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9y YXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzPC9wPgoKPHA+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yPGJyPgp0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldyBvciBkaXN0cmli dXRpb248YnI+CmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBh bmQgZGVsZXRlIGFsbCBjb3BpZXMuPC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F0CF5715D3D1884BAC731EA1103AC2813490DAF6HASMSX106gercor_-- From nobody Mon Apr 13 06:47:09 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3E1A1A68 for ; Mon, 13 Apr 2015 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 6m2M4g9b5OvC for ; Mon, 13 Apr 2015 06:47:00 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 287F81A1A39 for ; Mon, 13 Apr 2015 06:47:00 -0700 (PDT) Received: by pddn5 with SMTP id n5so107730298pdd.2 for ; Mon, 13 Apr 2015 06:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=WWFBh72j/qNo15w7PGBQZ9NWB9Tspcpz/xFhmqxZ4Po=; b=n3n4HMTSLAsC71g+19NZEoIfnCEuL2640pX6Wi2X6fOrWNVd4JRxt/UkrGTXnkfCmQ yE3WGfoMhOOFJJeq74YRaI2oxLaCQcW0lHOjqjX93Glh+eNA3dDz4fwncEyJsyKAR71Q pOxU3T2qtVL7OTPqWOKICELoxZtIF6DJMmT4hhL5iPzT5VkAExQKnrZ5pfdlHEBE2/ac zV0OEvhVsEogfSRKv7zwpGu8w1NXTm6NDc+1CfgL20o/zvrqlKkyKGzijd/BDUsLOxCP DYSqh/Gex8tf1g5WJf2Ud/3N73V2Hl65FgUkRBLg17toVnpDNrvTXUTIWf8sp7YwAtaA x81w== X-Received: by 10.70.48.177 with SMTP id m17mr27195312pdn.115.1428932819796; Mon, 13 Apr 2015 06:46:59 -0700 (PDT) Received: from [9.3.156.134] ([192.200.112.37]) by mx.google.com with ESMTPSA id fz1sm7392125pbb.12.2015.04.13.06.46.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 06:46:57 -0700 (PDT) Date: Mon, 13 Apr 2015 21:46:52 +0800 From: Dapeng Liu To: =?utf-8?Q?Moses=2C_Danny?= Message-ID: <2453D5F265B7470B910A9161862188B0@gmail.com> In-Reply-To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> <3255582297BB4CA98657F833BECF9AFE@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552bc8cc_78df6a55_e7" Archived-At: Cc: "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:47:08 -0000 --552bc8cc_78df6a55_e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Danny, =20 If you have read http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-ap= i-source-00, =20 The main idea of the draft is proposing to define the following flag: 3.1 (http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00=23= section-3.1). Suggested indication flag IPV6=5FPRE=46ER=5FSRC=5FNEW /* Pr= efer a new IP address based on a requested IP address type as source */ T= his flag is proposed to be added in R=46C5014 (http://tools.ietf.org/html= /rfc5014), and aims to express the preference for enabling differentiated= per-flow anchoring. The use of the flag can be combined together with th= e three types of IP address defined in =5Bdraft-yegin-dmm-ondemand-mobili= ty (http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility)=5D. It = is in equal degree and orthogonal with the defined flag-set in IPv6 socke= t API for source address selection =5BR=46C5014 (http://tools.ietf.org/ht= ml/rfc5014)=5D. =20 What I=E2=80=99m asking to Seil is: is this proposal has similarity with = the main idea of the following two drafts: https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 In the above drafts, the main idea is to define: IPV6=5FPRE=46ER=5FSRC=5FLOCAL=5FHNP /* Prefer a local home prefix */ IPV6= =5FPRE=46ER=5FSRC=5FREMOTE=5FHNP /* Prefer a remote home prefix */ Regards, -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=889:31=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC= =9A > Again =E2=80=93 what exactly are you comparing=3F Please be more specif= ic. > =20 > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > Sent: Monday, April 13, 2015 16:28 > To: Moses, Danny > Cc: Seil Jeon; dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised questio= ns for the proposed API =20 > =20 > =20 > =20 > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8C=E4=B8=8B=E5=8D=889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF= =BC=9A > > =20 > > What is simpler. Can you be more specific=3F What are you comparing=3F= > > =20 > > =20 > > =20 > > =20 > =20 > =E2=80=9Csimilar=22 not =E2=80=9Csimpler=E2=80=9D. > =20 > =20 > =20 > =20 > =20 > Regards, > =20 > Dapeng Liu > =20 > =20 > =20 > > =20 > > =20 > > =20 > > =20 > > Thanks, > > =20 > > =20 > > /Danny > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > > Sent: Monday, April 13, 2015 15:54 > > To: Seil Jeon > > Cc: Moses, Danny; dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised quest= ions for the proposed API > > =20 > > =20 > > =20 > > =20 > > =20 > > Hello Seil, Danny=EF=BC=9A =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =5Bas an individual contributor=5D > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > You can refer to the following two drafts: > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 > > =20 > > =20 > > =20 > > http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Is it the similar idea=3F > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > -- =20 > > =20 > > =20 > > =20 > > Dapeng Liu > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF= =BC=9A > > > =20 > > > Hi Danny, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom your cases specified as follows; > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =E2=80=9CI am thinking of two places that might require an update: > > > =20 > > > =20 > > > When an application chooses not to specify a source address (but re= quest a specific type) > > > =20 > > > =20 > > > When an application wishes to choose the source address from a prov= ided list. > > > =20 > > > =20 > > > =E2=80=9C > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I don=E2=80=99t understand the meaning of the second case. Why shou= ld an application wish to choose a source address from a list=3F What I h= ave talked about was about allowing the default source address selection = rules, which will be determined in the IP stack when an application is in= itiated with the destination address. I think we don=E2=80=99t need to to= uch it. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > The point is an application will totally assign the default source = address selection mechanism based on only type request but with no prefer= ence, or will request with the preference of a new Sustained IP address a= s well as type request. In the former case, if there is one or multiple S= ustained IP addresses, the IP stack will try to pick up one. Or the IP st= ack will try to get a new one. In the latter case, the IP stack will cons= ider a newly obtained Sustained IP address all the time, if the requested= preference value is not less than other preferences defined in the defau= lt source address selection rules. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > The need of the proposed flag and main criteria to be considered we= re already covered with case studies in the draft. > > > =20 > > > =20 > > > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00= > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > So, for productive discussion, I would like to suggest that you che= ck our draft again please and bring your questions if there is something = weird or should be updated with additional cases. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Best Regards, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Seil Jeon > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > Sent: Sunday, April 12, 2015 1:49 PM > > > To: Seil Jeon > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > You have a good point here. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Now I understand the need for the flag you are proposing =21=21=21 = =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > We need to take a better look at R=46C 6724 and figure out if we ne= ed to update it. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I am thinking of two places that might require an update: > > > =20 > > > =20 > > > When an application chooses not to specify a source address (but re= quest a specific type) > > > =20 > > > =20 > > > When an application wishes to choose the source address from a prov= ided list. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > When the application indicates the desired address type, but choose= s not to specify the source address (from a list provided by the IP stack= ), the stack should allocate a source IP address according to the address= -type requested by the application. In this case, we should consider addi= ng text to describe the behavior for Sustained IP addresses. Specifically= , if there are several Sustained IP addresses allocated to the mobile hos= t, whether to choose one of them, or to have the mobile host request a ne= w one from the network (as a result of a mobility event =E2=80=93 for exa= mple). > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > When an application wishes to chooses the source address from the a= vailable list (obtained by getaddrinfo()), there are some alternative app= roaches we should consider: > > > =20 > > > =20 > > > Enhance getaddrinfo() enabling the application to specify the requi= red address type, and return the list of source addresses that are of tha= t type (Nomadic, Sustained, =46ixed or DontCare), or - =20 > > > =20 > > > =20 > > > Provide the list of addresses with an indication of their type (Nom= adic, Sustained, =46ixed or TypeUnknown) and an indication of whether eac= h address is New (allocated after the last handoff event) or Old (allocat= ed before the last handoff event) > > > =20 > > > =20 > > > Some other approach=E2=80=A6 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > The flag is need here, to enable the application to request a new I= P address (if the returned list only contain 'Old' addresses) =21=21=21 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I agree that we should discuss this. How about bringing it to the n= ext 'Mobility Exposure and Selection WT' call=3F > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > /Danny > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > Sent: Sunday, April 05, 2015 17:08 > > > To: Moses, Danny > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Danny, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Meeting is always good, even with you by f-to-f. But in the discuss= ion, the main issue is whether we will allow the default source address s= election rules defined in R=46C6724 for selecting a Sustained IP address = among several ones or fundamentally block them for a specific reason rais= ed by a DMM need. The latter approach is not reasonable no matter how I t= ry to think of.it (http://of.it). > > > =20 > > > =20 > > > If an application has the specific preference of a newly obtained S= ustained IP address, it uses the proposed API. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards. > > > =20 > > > =20 > > > Seil > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > Sent: Sunday, April 05, 2015 12:23 PM > > > To: Seil Jeon > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Seil, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > By now we have been discussing this for quite some time and clearly= we did not succeed in convincing each other. > > > =20 > > > =20 > > > I suggest we try again when we have a chance to meet face to face. = Meanwhile, let's listen to what other people have to say on this matter. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > /Danny > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > Sent: Sunday, April 05, 2015 01:16 > > > To: Moses, Danny > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Resent. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Seil > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > Sent: Saturday, April 04, 2015 1:35 PM > > > To: 'Moses, Danny' > > > Cc: 'dmm=40ietf.org (mailto:dmm=40ietf.org)' > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Danny, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > See the inline please. I marked current replies with =E2=80=9C>>=E2= =80=9D and previous replies with =E2=80=9C>=E2=80=9D for you to catch the= m easily. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > Seil > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > Sent: Thursday, April 02, 2015 2:16 PM > > > To: Seil Jeon > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Seil, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Please see my replies (surrounded by >>2) to yours. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > /Danny > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > Sent: Tuesday, March 31, 2015 15:23 > > > To: Moses, Danny > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Danny, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > See the inline please. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Seil Jeon =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > Sent: Monday, March 30, 2015 4:44 PM > > > To: Seil Jeon > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: RE: =5BDMM=5D Answer on raised questions for the proposed = API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Seil, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > As to the potential of abuse: > > > =20 > > > =20 > > > Yes, I see your point and you are correct. If the IP stack will not= request a sustained IP address more than once after each movement to a n= ew LAN (with a different prefix), than there will be no abuse. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > > Yes, it=E2=80=99s true. Thanks for correction. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > As to the second comment, please let me elaborate: > > > =20 > > > =20 > > > One potential implementation of the IP stack in the host, can be to= request a Nomadic IP address and a Sustained IP address whenever connec= ting to a network, and whenever moving to a new LAN, regardless if there = are any applications requesting any addresses. This way, whenever an appl= ication is launched and requests either a Nomadic or Sustained IP address= , the stack can provide one without having to issue a request to the netw= ork. In this case, there is no need for this flag from the application. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > > Decision of which type of IP address by default will be depending= on the IP pool management policy by operators. You case may correspond t= o one of them. What if only the Nomadic IP address is basically allocated= upon a network attachment=3F That is, a lot of applications require mere= Internet connectivity without session continuity support. So, the Sustai= ned IP address will be requested on demand, and the proposed flag will be= used to get a new Sustained IP address by expressing the explicit reques= t by an application. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >>2 > > > =20 > > > =20 > > > As I mentioned at the beginning of the description =E2=80=93 it is = a description of one alternative. I am not assuming it is the only scenar= io. > > > =20 > > > =20 > > > Yes, I agree that many apps require only Nomadic IP addresses, but = in this example, the IP stack in the host pre-allocates both Nomadic and = Sustained IP addresses upon attachment=E2=80=A6 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >> As I said, it could be, but not as general one. The proposed API= is useful through the explicit expression for any potential scenarios. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Yes, we can describe an alternative in which a Nomadic IP address i= s pre-allocated upon NW connection (and after every movement to a new LAN= ) and a Sustained (and/or =46ixed) address is allocated on-demand. Even i= n such a scenario, I do not see any use for this flag =E2=80=93 see my re= ply to the second item below=E2=80=A6 > > > =20 > > > =20 > > > >>2 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >> My answer was already given in following answer in previous emai= l. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Another potential implementation of the IP stack in the host is not= to request IP addresses in advance. In that case, it will issue a reques= t for a Nomadic IP address or a Sustained IP address the first time an ap= plication requests one and use it for subsequent requests as long as it i= s not moving to a different LAN. Once it moves, it will again request a n= ew IP address (Nomadic or Sustained =E2=80=93 according to what is requir= ed) after receiving the first request from any application. In this case = as well, there is no need for this flag. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > > Another application requested just Sustained IP address while the= IP stack has already a Sustained IP address. Why should the IP stack try= to get a new one, though the application indicated simply =E2=80=9CSusta= ined IP address type=E2=80=9D=3F You case took a step towards a solution = where you want to draw. I don=E2=80=99t expect the action is generic when= a Sustained IP address type is requested. > > > =20 > > > =20 > > > Besides, you assumption on IP address allocation seems not valid. A= mobile host would get an IP address whatever the allocated IP address ty= pe is when it attaches at a network, regardless of an application=E2=80=99= s IP address request. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >>2 =20 > > > =20 > > > =20 > > > Looks like I did not express myself well enough (and did not fully = understand your reply). Let me list some events that might help clarify=E2= =80=A6 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Initial state: Mobile node is connected to a network; no Sustained = IP address is allocated. The IP stack sets a flag (SustainedIPAddressNeed= ed) indicating that if an application requests a Sustained IP address, it= will have to request one from the network. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Event1: An application that requires a Sustained IP address is laun= ched. =20 > > > =20 > > > =20 > > > APP action: App requests a Sustained IP address from the IP stack u= sing the proposed new API. > > > =20 > > > =20 > > > IP stack action: Since SustainedIPAddressNeeded is set, request one= from the network. > > > =20 > > > =20 > > > Network action: Assigned a Sustained IP address to the mobile node.= > > > =20 > > > =20 > > > IP stack action: (1) Mark the new Sustained IP address as the one t= o be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (= 3)Complete the API action and associate the marked Sustained IP address w= ith that port (app) > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Event2: A new application that also required a Sustained IP address= is launched =20 > > > =20 > > > =20 > > > App action: App requests a Sustained IP address from the IP stack u= sing the proposed new API > > > =20 > > > =20 > > > IP Stack action: Since SustainedIPAddressNeeded is not set, comple= te the API action and associate the marked Sustained IP address with that= port (app) > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Event3: The mobile node moves to a new LAN > > > =20 > > > =20 > > > IP Stack action: Set a flag indicating that the currently available= Sustained IP address is not optimized =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Event4: An application that requires a Sustained IP address is laun= ched. =20 > > > =20 > > > =20 > > > APP action: App requests a Sustained IP address from the IP stack u= sing the proposed new API. > > > =20 > > > =20 > > > IP stack action: Since SustainedIPAddressNeeded is set, request one= from the network. > > > =20 > > > =20 > > > Network action: Assigned a Sustained IP address to the mobile node.= > > > =20 > > > =20 > > > IP stack action: (1) Mark the new Sustained IP address as the one t= o be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (= 3)Complete the API action and associate the marked Sustained IP address w= ith that port (app) > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Note that the behavior of the IP stack in Event4 is exactly like th= e one in Event1. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I believe that this event is the one we have different of opinions:= I think that the default behavior of the IP stack is to request a new Su= stained IP address since it moved to a new LAN, and you think that it sho= uld do so only if the application specifically requests a new Sustained I= P address via the flag you are proposing. > > > =20 > > > =20 > > > >>2 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this= mail. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > As a matter of fact, if such a flag is defined, I cannot think of a= n example where it will not be used. It seems to me that applications wil= l always request a refreshed Sustained IP address (when requesting a Sust= ained IP address). If this is correct, the flag is redundant. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > > Some applications, e.g. email, that are not relatively restricted= from optimal routing would consider a Sustained IP address without issui= ng the new flag. More applications based on such network characteristic c= an be thought more than expected. > > > =20 > > > =20 > > > And such use of existing Sustained IP address is not extraordinary,= since IP address is a resource, even in the consideration of IPv6 deploy= ment. If as many as applications require new Sustained IP address, it wil= l end up in a lot of network resource consumption in the mobility routers= where the Sustained IP addresses are anchored as the terminal moves. > > > =20 > > > =20 > > > >>2 > > > =20 > > > =20 > > > I am sorry but I disagree with the email example. I categorize it a= s an example of an application that will request a Nomadic address since = it does not break when the mobile node moves to a new LAN and the source = IP address is changed. It simply restarts the socket and continue with th= e new source IP address (the user will not even notice this). > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >> The example was given as a benefit when the existing Sustained I= P address is used. You could get some insight from such kind of applicati= on not caring much the routing distance even on the Sustained IP address.= > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I did not understand the other text regarding resource consumption.= I thought we agreed that even of a new Sustained IP address is requested= upon each movement to a new LAN, the effect on IP address allocation is = not significant. Otherwise, my initial comment on applications abusing th= e network using your proposed flag, becomes valid again > > > =20 > > > =20 > > > >>2 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sust= ained IP address is requested upon receiving *new* flag from an applicati= on, as a preference for a source address selection. You need to read our = draft classifying the categories of IP address request again. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Besides, I don=E2=80=99t understand what is abused. Delivering its = preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it i= n your default behavior you=E2=80=99re assuming here. In your scenario, a= new app initiated in a new network will be forced to use a newly obtaine= d Sustained IP address. You see that=3F You totally block the possibility= to be considered by the default source address selection rules defined i= n R=46C6724. But in our draft, in case the need of a newly obtained Susta= ined IP address is prioritized, the proposed *new* flag can be used by ap= p=E2=80=99s request, thus it will be selected with priority. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Can you provide a scenario in which an application will not request= to refresh the Sustained IP address=3F > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > > It was mentioned in the former comments. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > /Danny > > > =20 > > > =20 > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > Sent: Monday, March 30, 2015 17:08 > > > To: Moses, Danny > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: =46W: =5BDMM=5D Answer on raised questions for the propose= d API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi Danny, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Any comments=3F > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > Seil Jeon > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil J= eon > > > Sent: Thursday, March 26, 2015 8:08 PM > > > To: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: =5BDMM=5D Answer on raised questions for the proposed API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hi, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > I could attend DMM Thursday meeting via MeetEcho. > > > =20 > > > =20 > > > I could also hear some raised comments by Danny and Someone. Here g= oes answers to the raised questions. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46irst, regarding the need of the proposed API (IPV6=5FPRE=46ER=5F= SRC=5FNEW), > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > The use of the proposed API is suggested in the SUSTAINED IP addres= s case in the draft. On receiving this API with the SUSTAINED IP address = type at the IP stack, it will try to get a new SUSTAINED IP address if th= ere is no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a sp= ecific access network. Even some applications put this API after, the alr= eady obtained SUSTAINED IP will be used. So, no worries about abuse. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Second question sounded to me like that this API is not needed beca= use the host can get a new SUSTAINED IP address, right=3F > > > =20 > > > =20 > > > If the question is right, I don=E2=80=99t understand what the quest= ion is meant, that is how the host can get a new SUSTAINED IP address=3F > > > =20 > > > =20 > > > Based on the definition of three types of IP address, an applicatio= n should show its requirement with an API among them. If it is the SUSTAI= NED IP address, how do we expect the IP stack will try to get a new SUSTA= INED IP address=3F > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Besides, the propsoed API is not used alone but with the three type= APIs. =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Regards, > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Seil Jeon > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > -------------------------------------------------------------------= -- > > > A member of the Intel Corporation group of companies =20 > > > This e-mail and any attachments may contain confidential material f= or > > > the sole use of the intended recipient(s). Any review or distributi= on > > > by others is strictly prohibited. If you are not the intended > > > recipient, please contact the sender and delete all copies. =20 > > > -------------------------------------------------------------------= -- > > > A member of the Intel Corporation group of companies =20 > > > This e-mail and any attachments may contain confidential material f= or > > > the sole use of the intended recipient(s). Any review or distributi= on > > > by others is strictly prohibited. If you are not the intended > > > recipient, please contact the sender and delete all copies. =20 > > > -------------------------------------------------------------------= -- > > > A member of the Intel Corporation group of companies =20 > > > This e-mail and any attachments may contain confidential material f= or > > > the sole use of the intended recipient(s). Any review or distributi= on > > > by others is strictly prohibited. If you are not the intended > > > recipient, please contact the sender and delete all copies. =20 > > > -------------------------------------------------------------------= -- > > > A member of the Intel Corporation group of companies =20 > > > This e-mail and any attachments may contain confidential material f= or > > > the sole use of the intended recipient(s). Any review or distributi= on > > > by others is strictly prohibited. If you are not the intended > > > recipient, please contact the sender and delete all copies. =20 > > > =20 > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > =20 > > > =20 > > > =20 > > > dmm mailing list > > > =20 > > > =20 > > > =20 > > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > > =20 > > > =20 > > > =20 > > > https://www.ietf.org/mailman/listinfo/dmm > > > =20 > > > =20 > > > =20 > > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > ---------------------------------------------------------------------= > > A member of the Intel Corporation group of companies =20 > > 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. =20 > =20 > =20 > =20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies =20 > 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. =20 --552bc8cc_78df6a55_e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Danny,


The main idea of the draft is proposing t= o define the following flag:

3.1. Suggested=
 indication flag


   IPV6=5FPRE=46ER=5FSRC=5FNEW

   /* Prefer a new IP address based on a requested IP address type as
   source */

   This flag is proposed to be added in R=46C5014, and aims to express
   the preference for enabling differentiated per-flow anchoring. The
   use of the flag can be combined together with the three types of IP
   address defined in =5Bdraft-yegin-dmm-ondemand-mobility=5D. It=
 is in
   equal degree and orthogonal with the defined flag-set in IPv6 socket
   API for source address selection =5BR=46C5014=5D.


What I=E2=80=99m = asking to Seil is: is this proposal has similarity with the main idea of = the following two drafts:


= In the above drafts, the main idea is to define:

IPV6=5FPRE=46ER=5FSRC=5F=
LOCAL=5FHNP  /* Prefer a local home prefix */
IPV6=5FPRE=46ER=5FSRC=5FREMOTE=5FHNP /* Prefer a remote home prefix */


Regards,
-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D= =889:31=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC=9A

<=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Again = =E2=80=93 what exactly are you comparing=3F Please be more specific.=

&= nbsp;

=46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D
Sent: Monday, April 13, 2015 16:28
To: Moses, Danny
Cc: Seil Jeon; dmm=40ietf.or= g
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A= =5BDMM=5D Answer on raised questions for the pr= oposed API

 

 

= =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC=9A

What is simpler. Can you be more specific=3F What are you com= paring=3F

=E2=80=9Csimilar=22 not =E2=80=9Csimpler=E2= =80=9D.

 

 

Regards,

Dapeng Liu

 

 

Thanks,

          &= nbsp;     /Danny

 

=46= rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; dmm=40ietf= .org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A= =5BDMM=5D Answer on raised questions for the pr= oposed API

 

Hello Seil, Danny=EF=BC=9A

 

=5Bas an individual con= tributor=5D

 

You can refer to the fo= llowing two drafts:

 

 

Is it the similar idea=3F=

 

-- 

=

Dapeng Liu

 

= =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

Hi Da= nny,

 = ;

=46ro= m your cases specified as follows;

 = ;

=E2=80=9CI am th= inking of two places that might require an update:

When an application cho= oses not to specify a source address (but request a specific type)

When an application wis= hes to choose the source address from a provided list.

=E2=80=9C

 = ;

I don= =E2=80=99t understand the meaning of the second case. Why should an appli= cation wish to choose a source address from a list=3F What I have talked = about was about allowing the default source address selection rules, which will be deter= mined in the IP stack when an application is initiated with the destinati= on address. I think we don=E2=80=99t need to touch it.<= /p>

 = ;

The p= oint is an application will totally assign the default source address sel= ection mechanism based on only type request but with no preference= , or will request with the preference of a new Sustained IP address as wel= l as type request. In the former case, if there = is one or multiple Sustained IP addresses, the IP stack will try to pick up one. Or the IP stack will= try to get a new one. In the latter case, the IP stack will consider a n= ewly obtained Sustained IP address all the time, if the requested prefere= nce value is not less than other preferences defined in the default source address selection rules.=

 = ;

The n= eed of the proposed flag and main criteria to be considered were already = covered with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00=

 = ;

So, f= or productive discussion, I would like to suggest that you check our draf= t again please and bring your questions if there is something weird or sh= ould be updated with additional cases.

 = ;

 = ;

Best = Regards,

 = ;

Seil = Jeon

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

You have a good point here.

 

Now I understand the need for the flag you are proposin= g =21=21=21

 

 

We need to take a better look at R=46C 6724 and figure out= if we need to update it.

 

I am thinking of two places that might require an update:<= /span>

When an application chooses not to specify a source addres= s (but request a specific type)

When an application wishes to choose the source address fr= om a provided list.

 

When the application indicates the desired address type, b= ut chooses not to specify the source address (from a list provided by the= IP stack), the stack should allocate a source IP address according to the address-type requested by the application. In this case= , we should consider adding text to describe the behavior for Sustained I= P addresses. Specifically, if there are several Sustained IP addresses al= located to the mobile host, whether to choose one of them, or to have the mobile host request a new one from th= e network (as a result of a mobility event =E2=80=93 for example).=

 

When an application wishes to chooses the source address f= rom the available list (obtained by getaddrinfo()), there are some altern= ative approaches we should consider:

Enhance getaddrinfo() enabling the application to specify = the required address type, and return the list of source addresses that a= re of that type (Nomadic, Sustained, =46ixed or DontCare), or -

Provide the list of addresses with an indication of their = type (Nomadic, Sustained, =46ixed or TypeUnknown) and an indication of wh= ether each address is New (allocated after the last handoff event) or Old (allocated before the last handoff event)

Some other approach=E2=80=A6

 

The flag is need here, to enable the application to req= uest a new IP address (if the returned list only contain 'Old' addresses)= =21=21=21

 

I agree that we should discuss this. How about bringing it= to the next 'Mobility Exposure and Selection WT' call=3F

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

Meeti= ng is always good, even with you by f-to-f. But in the discussion, the ma= in issue is whether we will allow the default source address selection ru= les defined in R=46C6724 for selecting a Sustained IP address among several = ones or fundamentally block them for a specific reason raised by a DMM ne= ed. The latter approach is not reasonable no matter how I try to think of.it.

If an= application has the specific preference of a newly obtained Sustained IP= address, it uses the proposed API.

 = ;

Regar= ds.

Seil<= /span>

 

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

By now we have been discussing this for quite some time an= d clearly we did not succeed in convincing each other.<= /p>

I suggest we try again when we have a chance to meet face = to face. Meanwhile, let's listen to what other people have to say on this= matter.

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Sunday, April 05, 2015 01:16
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Resen= t.

 = ;

Seil<= /span>

 = ;

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, Danny'
Cc: 'dmm=40ietf.org'
= Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

See t= he inline please. I marked current replies with =E2=80=9C>>=E2=80=9D= and previous replies with =E2=80=9C>=E2=80=9D for you to catch them e= asily.

 = ;

Regar= ds,

Seil<= /span>

 

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40int= el.com=5D
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

Please see my replies (surrounded by  >>2) to y= ours.

 

Regards,

         &nbs= p;      /Danny

 

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Da= nny,

 = ;

See t= he inline please.

 = ;

 = ;

Seil = Jeon

 = ;

 = ;

=46= rom: Moses, Danny =5Bmailto:danny.moses=40int= el.com=5D
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the proposed= API

 

Hi Seil,

 

As to the potential of abuse:

Yes, I see your point and you are correct. If the IP stack= will not request a sustained IP address more than once after each moveme= nt to a new LAN (with a different prefix), than there will be no abuse.

 

> Yes, it=E2=80=99s = true. Thanks for correction.

 = ;

As to the second comment, please let me elaborate:<= o:p>

One potential implementation of the IP stack in the host, = can be to request a Nomadic IP address and a  Sustained IP address w= henever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. = This way, whenever an application is launched and requests either a Nomad= ic or Sustained IP address, the stack can provide one without having to i= ssue a request to the network. In this case, there is no need for this flag from the application.

 

> Decision of which = type of IP address by default will be depending on the IP pool management= policy by operators. You case may correspond to one of them. What if onl= y the Nomadic IP address is basically allocated upon a network attachment=3F= That is, a lot of applications require mere Internet connectivity withou= t session continuity support. So, the Sustained IP address will be reques= ted on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit req= uest by an application.

 = ;

>>2

As I mentioned at the beginning of the description =E2=80=93= it is a description of one alternative. I am not assuming it is the only= scenario.

Yes, I agree that many apps require only Nomadic IP addres= ses, but in this example, the IP stack in the host pre-allocates both Nom= adic and Sustained IP addresses upon attachment=E2=80=A6

 

>> As I said, it = could be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 = ;

Yes, we can describe an alternative in which a Nomadic IP = address is pre-allocated upon NW connection (and after every movement to = a new LAN) and a Sustained (and/or =46ixed) address is allocated on-demand. Even in such a scenario, I do not see any use for this flag =E2= =80=93 see my reply to the second item below=E2=80=A6

>>2

 

>> My answer was = already given in following answer in previous email.

 

Another potential implementation of the IP stack in the ho= st is not to request IP addresses in advance. In that case, it will issue= a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subseq= uent requests as long as it is not moving to a different LAN. Once it mov= es, it will again request a new IP address (Nomadic or Sustained =E2=80=93= according to what is required) after receiving the first request from any application. In this case as well, there is n= o need for this flag.

 

> Another applicatio= n requested just Sustained IP address while the IP stack has already a Su= stained IP address. Why should the IP stack try to get a new one, though the application indicated simply =E2=80=9CSustained IP address type=E2=80= =9D=3F You case took a step towards a solution where you want to draw. I = don=E2=80=99t expect the action is generic when a Sustained IP address ty= pe is requested.

Besides, you assumption= on IP address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a network, regardless of an application=E2=80=99s IP address request.

 = ;

>&= gt;2

Looks= like I did not express myself well enough (and did not fully understand = your reply). Let me list some events that might help clarify=E2=80=A6

 = ;

Initi= al state: Mobile node is connected to a network; no Sustained IP address = is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicat= ing that if an application requests a Sustained IP address, it will have to = request one from the network.

 = ;

Event= 1: An application that requires a Sustained IP address is launched.

APP a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API.

IP st= ack action: Since SustainedIPAddressNeeded is set, request one from the n= etwork.

Netwo= rk action: Assigned a Sustained IP address to the mobile node.

IP st= ack action: (1) Mark the new Sustained IP address as the one to be associ= ated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete = the API action and associate the marked Sustained IP address with that port = (app)

 = ;

Event= 2: A new application that also required a Sustained IP address is launche= d

App a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API

IP St= ack action: Since SustainedIPAddressNeeded  is not set, complete the= API action and associate the marked Sustained IP address with that port = (app)

 = ;

Event= 3: The mobile node moves to a new LAN

IP St= ack action: Set a flag indicating that the currently available Sustained = IP address is not optimized

 = ;

Event= 4: An application that requires a Sustained IP address is launched.

APP a= ction: App requests a Sustained IP address from the IP stack using the pr= oposed new API.

IP st= ack action: Since SustainedIPAddressNeeded is set, request one from the n= etwork.

Netwo= rk action: Assigned a Sustained IP address to the mobile node.

IP st= ack action: (1) Mark the new Sustained IP address as the one to be associ= ated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete = the API action and associate the marked Sustained IP address with that port = (app)

 = ;

Note = that the behavior of the IP stack in Event4 is exactly like the one in Ev= ent1.

 = ;

I = believe that this event is the one we have different of opinions: I think= that the default behavior of the IP stack is to request a new Sustained = IP address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>&= gt;2

 = ;

>> You can see my= answer at the lowest =E2=80=9C>>=E2=80=9D in this mail.

 

As a matter of fact, if such a flag is defined, I cannot t= hink of an example where it will not be used. It seems to me that applica= tions will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag i= s redundant.

 

> Some applications,= e.g. email, that are not relatively restricted from optimal routing woul= d consider a Sustained IP address without issuing the new flag. More appl= ications based on such network characteristic can be thought more than expected.<= /span>

And such use of existin= g Sustained IP address is not extraordinary, since IP address is a resour= ce, even in the consideration of IPv6 deployment. If as many as applicati= ons require new Sustained IP address, it will end up in a lot of network res= ource consumption in the mobility routers where the Sustained IP addresse= s are anchored as the terminal moves.

>>2

I am sorry but I disagree with the email example. I catego= rize it as an example of an application that will request a Nomadic addre= ss since it does not break when the mobile node moves to a new LAN and the source IP address is changed. It simply restarts th= e socket and continue with the new source IP address (the user will not e= ven notice this).

 

>> The example wa= s given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP address.

 = ;

I did not understand the other text regarding resource con= sumption. I thought we agreed that even of a new Sustained IP address is = requested upon each movement to a new LAN, the effect on IP address allocation is not significant. Otherwise, my initial comme= nt on applications abusing the network using your proposed flag, becomes = valid again

>>2

 = ;

>> No, our draft = didn=E2=80=99t say so. Our idea is that a new Sustained IP address is req= uested upon receiving *new* flag from an application, as a preference for= a source address selection. You need to read our draft classifying the categories of IP a= ddress request again.

 

Besides, I don=E2=80=99= t understand what is abused. Delivering its preference cannot be abuse. R= egarding =E2=80=9Cabuse=E2=80=9D, I see it in your default behavior you=E2= =80=99re assuming here. In your scenario, a new app initiated in a new network will be forced to use a n= ewly obtained Sustained IP address. You see that=3F You totally block the= possibility to be considered by the default source address selection rul= es defined in R=46C6724. But in our draft, in case the need of a newly obtained Sustained IP address is prioritized= , the proposed *new* flag can be used by app=E2=80=99s request, thus it w= ill be selected with priority.

 = ;

Can you provide a scenario in which an application will no= t request to refresh the Sustained IP address=3F

 = ;

> It was mentioned i= n the former comments.

 

 = ;

Regards,

         &nbs= p;      /Danny

=46= rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: =46W: =5BDMM=5D Answer on raised questions for the propos= ed API

 

Hi Da= nny,

 = ;

Any c= omments=3F

 = ;

Regar= ds,

Seil = Jeon

 

 = ;

=46= rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm=40ietf.org
Subject: =5BDMM=5D Answer on raised questions for the proposed API=

 

Hi,

 

I could attend DMM Thur= sday meeting via MeetEcho.

I could also hear some = raised comments by Danny and Someone. Here goes answers to the raised que= stions.

 

 

=46irst, regarding the = need of the proposed API (IPV6=5FPRE=46ER=5FSRC=5FNEW),=

 

The use of the proposed= API is suggested in the SUSTAINED IP address case in the draft. On recei= ving this API with the SUSTAINED IP address type at the IP stack, it will= try to get a new SUSTAINED IP address if there is no available in the cu= rrently attached access network. So, actual obtaining of the IP address w= ill be tried one time while attached at a specific access network. Even s= ome applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse.<= /span>

 

Second question sounded= to me like that this API is not needed because the host can get a new SU= STAINED IP address, right=3F

If the question is righ= t, I don=E2=80=99t understand what the question is meant, that is how the= host can get a new SUSTAINED IP address=3F

Based on the definition= of three types of IP address, an application should show its requirement= with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address=3F=

 

Besides, the propsoed A= PI is not used alone but with the three type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

dmm mailing list

 

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

 

---------------------------------------------------------------------<= br> A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for<= br> 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.

 =20 =20 =20 =20
=20

--552bc8cc_78df6a55_e7-- From nobody Mon Apr 13 07:02:30 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B761A7018 for ; Mon, 13 Apr 2015 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 au2ShPFHn3w8 for ; Mon, 13 Apr 2015 07:02:14 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id DE7011A6FF7 for ; Mon, 13 Apr 2015 07:02:12 -0700 (PDT) Received: from [192.168.22.75] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77486820; Mon, 13 Apr 2015 15:02:10 +0100 From: "Seil Jeon" To: "'Dapeng Liu'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> <3255582297BB4CA98657F833BECF9AFE@gmail.com> <2453D5F265B7470B910A9161862188B0@gmail.com> In-Reply-To: <2453D5F265B7470B910A9161862188B0@gmail.com> Date: Mon, 13 Apr 2015 15:02:11 +0100 Message-ID: <004401d075f2$7030dbd0$50929370$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01D075FA.D2012AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uYCqJZpkgDQIjNOAdQYy1EBr/T0wgK/SzL8A4QAO4YCnWFt8wF3KLLPAhhjTzYB/hC1twD7cJRnAXnlf1OavtGoUA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBBbnN3ZXIgb24gcmFpc2VkIHF1ZXN0aW9u?= =?utf-8?q?s_for_the_proposed_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:02:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0045_01D075FA.D2012AB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dapeng, =20 I think your draft should not be compared with our draft. Our draft is = proposing some missing points through case study based on the on-demand = mobility draft. Your draft seems proposing a different way, which is away from the = on-demand mobility draft, from the definition of the proposed flags for = local HNP and remote HNP. It should be checked first. =20 --------- The local home prefix may be preferred by applications which are likely to discontinue operations before the device travels to distant networks. On the other hand, a remote home prefix may be more suitable for continued operation over wide areas, but at potentially increased cost for mobiilty management. --------- =20 =20 Best Regards, =20 Seil Jeon =20 From: Dapeng Liu [mailto:maxpassion@gmail.com]=20 Sent: Monday, April 13, 2015 2:47 PM To: Moses, Danny Cc: Seil Jeon; dmm@ietf.org Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] Answer on raised questions = for the proposed API =20 Hi Danny,=20 =20 If you have read = http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,=20 =20 The main idea of the draft is proposing to define the following flag: =20 = 3.1. Suggested indication flag =20 =20 IPV6_PREFER_SRC_NEW =20 /* Prefer a new IP address based on a requested IP address type as source */ =20 This flag is proposed to be added in RFC5014 = , and aims to express the preference for enabling differentiated per-flow anchoring. The use of the flag can be combined together with the three types of IP address defined in [draft-yegin-dmm-ondemand-mobility = ]. It is = in equal degree and orthogonal with the defined flag-set in IPv6 socket API for source address selection [RFC5014 = ]. =20 =20 What I=E2=80=99m asking to Seil is: is this proposal has similarity with = the main idea of the following two drafts: =20 https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 =20 In the above drafts, the main idea is to define: =20 IPV6_PREFER_SRC_LOCAL_HNP /* Prefer a local home prefix */ IPV6_PREFER_SRC_REMOTE_HNP /* Prefer a remote home prefix */ =20 =20 Regards, --=20 Dapeng Liu =20 =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=889:31=EF=BC=8CMoses,= Danny =E5=86=99=E9=81=93=EF=BC=9A Again =E2=80=93 what exactly are you comparing? Please be more specific. =20 From: Dapeng Liu [mailto:maxpassion@gmail.com]=20 Sent: Monday, April 13, 2015 16:28 To: Moses, Danny Cc: Seil Jeon; dmm@ietf.org Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] Answer on raised questions = for the proposed API =20 =20 =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=889:21=EF=BC=8CMoses,= Danny =E5=86=99=E9=81=93=EF=BC=9A What is simpler. Can you be more specific? What are you comparing? =E2=80=9Csimilar" not =E2=80=9Csimpler=E2=80=9D. =20 =20 Regards, Dapeng Liu =20 =20 Thanks, /Danny =20 From: Dapeng Liu [mailto:maxpassion@gmail.com]=20 Sent: Monday, April 13, 2015 15:54 To: Seil Jeon Cc: Moses, Danny; dmm@ietf.org Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] Answer on raised questions = for the proposed API =20 Hello Seil, Danny=EF=BC=9A=20 =20 [as an individual contributor] =20 You can refer to the following two drafts: =20 https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 =20 Is it the similar idea? =20 --=20 Dapeng Liu =20 =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil = Jeon =E5=86=99=E9=81=93=EF=BC=9A Hi Danny, =20 >From your cases specified as follows; =20 =E2=80=9CI am thinking of two places that might require an update: When an application chooses not to specify a source address (but request = a specific type) When an application wishes to choose the source address from a provided = list. =E2=80=9C =20 I don=E2=80=99t understand the meaning of the second case. Why should an = application wish to choose a source address from a list? What I have = talked about was about allowing the default source address selection = rules, which will be determined in the IP stack when an application is = initiated with the destination address. I think we don=E2=80=99t need to = touch it. =20 The point is an application will totally assign the default source = address selection mechanism based on only type request but with no = preference, or will request with the preference of a new Sustained IP = address as well as type request. In the former case, if there is one or = multiple Sustained IP addresses, the IP stack will try to pick up one. = Or the IP stack will try to get a new one. In the latter case, the IP = stack will consider a newly obtained Sustained IP address all the time, = if the requested preference value is not less than other preferences = defined in the default source address selection rules. =20 The need of the proposed flag and main criteria to be considered were = already covered with case studies in the draft. http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 =20 So, for productive discussion, I would like to suggest that you check = our draft again please and bring your questions if there is something = weird or should be updated with additional cases. =20 =20 Best Regards, =20 Seil Jeon =20 From: Moses, Danny [mailto:danny.moses@intel.com]=20 Sent: Sunday, April 12, 2015 1:49 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 You have a good point here. =20 Now I understand the need for the flag you are proposing !!!=20 =20 =20 We need to take a better look at RFC 6724 and figure out if we need to = update it. =20 I am thinking of two places that might require an update: When an application chooses not to specify a source address (but request = a specific type) When an application wishes to choose the source address from a provided = list. =20 When the application indicates the desired address type, but chooses not = to specify the source address (from a list provided by the IP stack), = the stack should allocate a source IP address according to the = address-type requested by the application. In this case, we should = consider adding text to describe the behavior for Sustained IP = addresses. Specifically, if there are several Sustained IP addresses = allocated to the mobile host, whether to choose one of them, or to have = the mobile host request a new one from the network (as a result of a = mobility event =E2=80=93 for example). =20 When an application wishes to chooses the source address from the = available list (obtained by getaddrinfo()), there are some alternative = approaches we should consider: Enhance getaddrinfo() enabling the application to specify the required = address type, and return the list of source addresses that are of that = type (Nomadic, Sustained, Fixed or DontCare), or -=20 Provide the list of addresses with an indication of their type (Nomadic, = Sustained, Fixed or TypeUnknown) and an indication of whether each = address is New (allocated after the last handoff event) or Old = (allocated before the last handoff event) Some other approach=E2=80=A6 =20 The flag is need here, to enable the application to request a new IP = address (if the returned list only contain 'Old' addresses) !!! =20 I agree that we should discuss this. How about bringing it to the next = 'Mobility Exposure and Selection WT' call? =20 Regards, /Danny =20 From: Seil Jeon [mailto:seiljeon@av.it.pt]=20 Sent: Sunday, April 05, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Danny, =20 Meeting is always good, even with you by f-to-f. But in the discussion, = the main issue is whether we will allow the default source address = selection rules defined in RFC6724 for selecting a Sustained IP address = among several ones or fundamentally block them for a specific reason = raised by a DMM need. The latter approach is not reasonable no matter = how I try to think of.it. If an application has the specific preference of a newly obtained = Sustained IP address, it uses the proposed API. =20 Regards. Seil =20 =20 From: Moses, Danny [mailto:danny.moses@intel.com]=20 Sent: Sunday, April 05, 2015 12:23 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Seil, =20 By now we have been discussing this for quite some time and clearly we = did not succeed in convincing each other. I suggest we try again when we have a chance to meet face to face. = Meanwhile, let's listen to what other people have to say on this matter. =20 Regards, /Danny =20 From: Seil Jeon [mailto:seiljeon@av.it.pt]=20 Sent: Sunday, April 05, 2015 01:16 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Resent. =20 Seil =20 From: Seil Jeon [mailto:seiljeon@av.it.pt]=20 Sent: Saturday, April 04, 2015 1:35 PM To: 'Moses, Danny' Cc: 'dmm@ietf.org' Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Danny, =20 See the inline please. I marked current replies with = =E2=80=9C>>=E2=80=9D and previous replies with =E2=80=9C>=E2=80=9D for = you to catch them easily. =20 Regards, Seil =20 =20 From: Moses, Danny [ = mailto:danny.moses@intel.com]=20 Sent: Thursday, April 02, 2015 2:16 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Seil, =20 Please see my replies (surrounded by >>2) to yours. =20 Regards, /Danny =20 From: Seil Jeon [ mailto:seiljeon@av.it.pt]=20 Sent: Tuesday, March 31, 2015 15:23 To: Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Danny, =20 See the inline please. =20 =20 Seil Jeon=20 =20 =20 From: Moses, Danny [ = mailto:danny.moses@intel.com]=20 Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API =20 Hi Seil, =20 As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not = request a sustained IP address more than once after each movement to a = new LAN (with a different prefix), than there will be no abuse. =20 > Yes, it=E2=80=99s true. Thanks for correction. =20 As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to = request a Nomadic IP address and a Sustained IP address whenever = connecting to a network, and whenever moving to a new LAN, regardless if = there are any applications requesting any addresses. This way, whenever = an application is launched and requests either a Nomadic or Sustained IP = address, the stack can provide one without having to issue a request to = the network. In this case, there is no need for this flag from the = application. =20 > Decision of which type of IP address by default will be depending on = the IP pool management policy by operators. You case may correspond to = one of them. What if only the Nomadic IP address is basically allocated = upon a network attachment? That is, a lot of applications require mere = Internet connectivity without session continuity support. So, the = Sustained IP address will be requested on demand, and the proposed flag = will be used to get a new Sustained IP address by expressing the = explicit request by an application. =20 >>2 As I mentioned at the beginning of the description =E2=80=93 it is a = description of one alternative. I am not assuming it is the only = scenario. Yes, I agree that many apps require only Nomadic IP addresses, but in = this example, the IP stack in the host pre-allocates both Nomadic and = Sustained IP addresses upon attachment=E2=80=A6 =20 >> As I said, it could be, but not as general one. The proposed API is = useful through the explicit expression for any potential scenarios. =20 Yes, we can describe an alternative in which a Nomadic IP address is = pre-allocated upon NW connection (and after every movement to a new LAN) = and a Sustained (and/or Fixed) address is allocated on-demand. Even in = such a scenario, I do not see any use for this flag =E2=80=93 see my = reply to the second item below=E2=80=A6 >>2 =20 >> My answer was already given in following answer in previous email. =20 Another potential implementation of the IP stack in the host is not to = request IP addresses in advance. In that case, it will issue a request = for a Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained =E2=80=93 according to = what is required) after receiving the first request from any = application. In this case as well, there is no need for this flag. =20 > Another application requested just Sustained IP address while the IP = stack has already a Sustained IP address. Why should the IP stack try to = get a new one, though the application indicated simply = =E2=80=9CSustained IP address type=E2=80=9D? You case took a step = towards a solution where you want to draw. I don=E2=80=99t expect the = action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A = mobile host would get an IP address whatever the allocated IP address = type is when it attaches at a network, regardless of an = application=E2=80=99s IP address request. =20 >>2=20 Looks like I did not express myself well enough (and did not fully = understand your reply). Let me list some events that might help = clarify=E2=80=A6 =20 Initial state: Mobile node is connected to a network; no Sustained IP = address is allocated. The IP stack sets a flag = (SustainedIPAddressNeeded) indicating that if an application requests a = Sustained IP address, it will have to request one from the network. =20 Event1: An application that requires a Sustained IP address is launched. = APP action: App requests a Sustained IP address from the IP stack using = the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from = the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app) =20 Event2: A new application that also required a Sustained IP address is = launched=20 App action: App requests a Sustained IP address from the IP stack using = the proposed new API IP Stack action: Since SustainedIPAddressNeeded is not set, complete = the API action and associate the marked Sustained IP address with that = port (app) =20 Event3: The mobile node moves to a new LAN IP Stack action: Set a flag indicating that the currently available = Sustained IP address is not optimized=20 =20 Event4: An application that requires a Sustained IP address is launched. = APP action: App requests a Sustained IP address from the IP stack using = the proposed new API. IP stack action: Since SustainedIPAddressNeeded is set, request one from = the network. Network action: Assigned a Sustained IP address to the mobile node. IP stack action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app) =20 Note that the behavior of the IP stack in Event4 is exactly like the one = in Event1. =20 I believe that this event is the one we have different of opinions: I = think that the default behavior of the IP stack is to request a new = Sustained IP address since it moved to a new LAN, and you think that it = should do so only if the application specifically requests a new = Sustained IP address via the flag you are proposing. >>2 =20 >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in this = mail. =20 As a matter of fact, if such a flag is defined, I cannot think of an = example where it will not be used. It seems to me that applications will = always request a refreshed Sustained IP address (when requesting a = Sustained IP address). If this is correct, the flag is redundant. =20 > Some applications, e.g. email, that are not relatively restricted from = optimal routing would consider a Sustained IP address without issuing = the new flag. More applications based on such network characteristic can = be thought more than expected. And such use of existing Sustained IP address is not extraordinary, = since IP address is a resource, even in the consideration of IPv6 = deployment. If as many as applications require new Sustained IP address, = it will end up in a lot of network resource consumption in the mobility = routers where the Sustained IP addresses are anchored as the terminal = moves. >>2 I am sorry but I disagree with the email example. I categorize it as an = example of an application that will request a Nomadic address since it = does not break when the mobile node moves to a new LAN and the source IP = address is changed. It simply restarts the socket and continue with the = new source IP address (the user will not even notice this). =20 >> The example was given as a benefit when the existing Sustained IP = address is used. You could get some insight from such kind of = application not caring much the routing distance even on the Sustained = IP address. =20 I did not understand the other text regarding resource consumption. I = thought we agreed that even of a new Sustained IP address is requested = upon each movement to a new LAN, the effect on IP address allocation is = not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again >>2 =20 >> No, our draft didn=E2=80=99t say so. Our idea is that a new Sustained = IP address is requested upon receiving *new* flag from an application, = as a preference for a source address selection. You need to read our = draft classifying the categories of IP address request again. =20 Besides, I don=E2=80=99t understand what is abused. Delivering its = preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it = in your default behavior you=E2=80=99re assuming here. In your scenario, = a new app initiated in a new network will be forced to use a newly = obtained Sustained IP address. You see that? You totally block the = possibility to be considered by the default source address selection = rules defined in RFC6724. But in our draft, in case the need of a newly = obtained Sustained IP address is prioritized, the proposed *new* flag = can be used by app=E2=80=99s request, thus it will be selected with = priority. =20 Can you provide a scenario in which an application will not request to = refresh the Sustained IP address? =20 > It was mentioned in the former comments. =20 =20 Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt]=20 Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API =20 Hi Danny, =20 Any comments? =20 Regards, Seil Jeon =20 =20 From: dmm [ mailto:dmm-bounces@ietf.org] = On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API =20 Hi, =20 I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions. =20 =20 First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), =20 The use of the proposed API is suggested in the SUSTAINED IP address = case in the draft. On receiving this API with the SUSTAINED IP address = type at the IP stack, it will try to get a new SUSTAINED IP address if = there is no available in the currently attached access network. So, = actual obtaining of the IP address will be tried one time while attached = at a specific access network. Even some applications put this API after, = the already obtained SUSTAINED IP will be used. So, no worries about = abuse. =20 Second question sounded to me like that this API is not needed because = the host can get a new SUSTAINED IP address, right? If the question is right, I don=E2=80=99t understand what the question = is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application = should show its requirement with an API among them. If it is the = SUSTAINED IP address, how do we expect the IP stack will try to get a = new SUSTAINED IP address? =20 Besides, the propsoed API is not used alone but with the three type = APIs.=20 =20 =20 =20 Regards, =20 Seil Jeon =20 =20 --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm =20 --------------------------------------------------------------------- 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. =20 --------------------------------------------------------------------- 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. =20 ------=_NextPart_000_0045_01D075FA.D2012AB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Dapeng,

 

I think your draft should not be compared with our draft. Our draft is = proposing some missing points through case study based on the on-demand = mobility draft.

Your draft seems proposing a different way, which is away from the = on-demand mobility draft, from the definition of the proposed flags for = local HNP and remote HNP. It should be checked = first.

 

---------

The local home prefix may be = preferred by applications which are

=C2=A0=C2=A0 likely to discontinue = operations before the device travels to distant

=C2=A0=C2=A0 networks.=C2=A0 On the = other hand, a remote home prefix may be more

=C2=A0=C2=A0 suitable for continued = operation over wide areas, but at potentially

=C2=A0=C2=A0 increased cost for = mobiilty management.

---------

 

 

Best Regards,

 

Seil Jeon

 

From:= = Dapeng Liu [mailto:maxpassion@gmail.com]
Sent: Monday, April = 13, 2015 2:47 PM
To: Moses, Danny
Cc: Seil Jeon; = dmm@ietf.org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] = Answer on raised questions for the proposed API

 

Hi = Danny,

 

3.1. Suggested = indication flag

 
 
=C2=A0=C2=A0 =
IPV6_PREFER_SRC_NEW
 
=C2=A0=C2=A0 /* Prefer a new IP address based =
on a requested IP address type as
=C2=A0=C2=A0 source =
*/
 
=C2=A0=C2=A0 This flag is proposed to be =
added in RFC5014, and =
aims to express
=C2=A0=C2=A0 the preference for enabling =
differentiated per-flow anchoring. The
=C2=A0=C2=A0 use of the flag can be combined =
together with the three types of IP
=C2=A0=C2=A0 address defined in [dra=
ft-yegin-dmm-ondemand-mobility]. It is =
in
=C2=A0=C2=A0 equal degree and orthogonal with =
the defined flag-set in IPv6 socket
=C2=A0=C2=A0 API for source address selection =
[RFC5014].
 

 

What I=E2=80=99m asking to Seil is: is this proposal = has similarity with the main idea of the following two = drafts:

 

http://= tools.ietf.org/html/draft-liu-dmm-mobility-api-02

 

In the above drafts, the main idea is to = define:

 

IPV6_PREFER_SRC_LOCAL_HNP=C2=A0 /* Prefer a =
local home prefix */
IPV6_PREFER_SRC_REMOTE_HNP /* Prefer a remote =
home prefix */

 

 

Regards,

-- 

Dapeng Liu

 

=E5=9C=A8= 2015=E5=B9=B4= 4=E6=9C=88= 13=E6=97=A5= =E6=98=9F= =E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B= =E5=8D=889:31=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC=9A

Again =E2=80=93 what exactly are you comparing? Please be more = specific.

 

From:= = Dapeng Liu [mailto:maxpassion@gmail.com] =
Sent: Monday, April 13, 2015 16:28
To: Moses, = Danny
Cc: Seil Jeon; dmm@ietf.org
Subject: = =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] = Answer on raised questions for the proposed API

 

 

= =E5=9C=A8 = 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D= =889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC=9A

<= blockquote style=3D'border:none;border-left:solid windowtext = 1.0pt;padding:0cm 0cm 0cm = 8.0pt;margin-left:0cm;margin-top:5.0pt;margin-bottom:5.0pt'>

What is simpler. Can you be more specific? What are you = comparing?

=E2=80=9Csimilar" not = =E2=80=9Csimpler=E2=80=9D.

 

 

Regards,

<= div>

Dapeng = Liu

 

 

Thanks,

           &nbs= p;    /Danny

 

From:= = Dapeng Liu [mailto:maxpassion@gmail.com] =
Sent: Monday, April 13, 2015 15:54
To: Seil = Jeon
Cc: Moses, Danny; dmm@ietf.org
Subject: = =E5=9B=9E=E5=A4=8D=EF=BC=9A [DMM] = Answer on raised questions for the proposed API

 

Hello Seil, Danny=EF=BC=9A

 

[as an individual = contributor]

 

You can refer to the = following two drafts:

 

h= ttps://tools.ietf.org/html/draft-liu-dmm-address-selection-01

 

-- 

<= div>

Dapeng = Liu

 

=E5=9C=A8 = 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D= =886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

<= blockquote style=3D'border:none;border-left:solid windowtext = 1.0pt;padding:0cm 0cm 0cm = 8.0pt;margin-left:0cm;margin-top:5.0pt;margin-bottom:5.0pt'>

Hi = Danny,

 

From your cases = specified as follows;

 

=E2=80=9CI am thinking = of two places that might require an update:

When an application chooses = not to specify a source address (but request a specific = type)

When = an application wishes to choose the source address from a provided = list.

=E2=80=9C

 

I don=E2=80=99t = understand the meaning of the second case. Why should an application = wish to choose a source address from a list? What I have talked about = was about allowing the default source address selection rules, which = will be determined in the IP stack when an application is initiated with = the destination address. I think we don=E2=80=99t need to touch = it.

 

The point is an = application will totally assign the default source address selection = mechanism based on only type = request but with no preference, or will = request with the preference = of a new Sustained IP address as well as type request. In the former = case, if there is one or multiple Sustained IP addresses, the IP stack = will try to pick up one. Or the IP stack will try to get a new one. In = the latter case, the IP stack will consider a newly obtained Sustained = IP address all the time, if the requested preference value is not less = than other preferences defined in the default source address selection = rules.

 

The need of the = proposed flag and main criteria to be considered were already covered = with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00

 

So, for = productive discussion, I would like to suggest that you check our draft = again please and bring your questions if there is something weird or = should be updated with additional cases.

 

 

 

From:= = Moses, Danny [mailto:danny.moses@intel.com] =
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

You have a good point = here.

 

Now I understand the need for the flag you are = proposing !!!

 

 

We need to take a better look at RFC 6724 and = figure out if we need to update it.

 

I am thinking of two places that might require = an update:

When an application chooses not to specify a = source address (but request a specific type)

When an application wishes to choose the source = address from a provided list.

 

When the application indicates the desired = address type, but chooses not to specify the source address (from a list = provided by the IP stack), the stack should allocate a source IP address = according to the address-type requested by the application. In this = case, we should consider adding text to describe the behavior for = Sustained IP addresses. Specifically, if there are several Sustained IP = addresses allocated to the mobile host, whether to choose one of them, = or to have the mobile host request a new one from the network (as a = result of a mobility event =E2=80=93 for = example).

 

When an application wishes to chooses the source = address from the available list (obtained by getaddrinfo()), there are = some alternative approaches we should consider:

Enhance getaddrinfo() enabling the application = to specify the required address type, and return the list of source = addresses that are of that type (Nomadic, Sustained, Fixed or DontCare), = or -

Provide the list of addresses with an indication = of their type (Nomadic, Sustained, Fixed or TypeUnknown) and an = indication of whether each address is New (allocated after the last = handoff event) or Old (allocated before the last handoff = event)

Some other = approach=E2=80=A6

 

The flag is need here, to enable the application = to request a new IP address (if the returned list only contain 'Old' = addresses) !!!

 

I agree that we should discuss this. How about = bringing it to the next 'Mobility Exposure and Selection WT' call?

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Sunday, April 05, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Meeting is = always good, even with you by f-to-f. But in the discussion, the main = issue is whether we will allow the default source address selection = rules defined in RFC6724 for selecting a Sustained IP address among = several ones or fundamentally block them for a specific reason raised by = a DMM need. The latter approach is not reasonable no matter how I try to = think of.it.

If an = application has the specific preference of a newly obtained Sustained IP = address, it uses the proposed API.

 

Regards.<= o:p>

Seil=

 

 

From:= = Moses, Danny [mailto:danny.moses@intel.com] =
Sent: Sunday, April 05, 2015 12:23 PM
To: Seil = Jeon
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

By now we have been discussing this for quite = some time and clearly we did not succeed in convincing each = other.

I suggest we try again when we have a chance to = meet face to face. Meanwhile, let's listen to what other people have to = say on this matter.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Sunday, April 05, 2015 01:16
To: Moses, = Danny
Cc: dmm@ietf.org
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Resent.

 

Seil=

 

From:= = Seil Jeon [mailto:seiljeon@av.it.pt] =
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, = Danny'
Cc: 'dmm@ietf.org'
Subject: RE: = [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please. I marked current replies with =E2=80=9C>>=E2=80=9D and = previous replies with =E2=80=9C>=E2=80=9D for you to catch them = easily.

 

Regards,<= o:p>

Seil=

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Thursday, April 02, 2015 2:16 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

Please see my replies (surrounded by =  >>2) to yours.

 

Regards,

        &= nbsp;       /Danny

 

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Tuesday, March 31, 2015 15:23
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

See the inline = please.

 

 

Seil Jeon =

 

 

From:= = Moses, Danny [mailto:danny= .moses@intel.com] =
Sent: Monday, March 30, 2015 4:44 PM
To: Seil = Jeon
Cc: dmm@ietf.org=
Subje= ct: RE: [DMM] Answer on raised questions for the proposed = API

 

Hi Seil,

 

As to the potential of = abuse:

Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

 

> Yes, it=E2=80=99s true. = Thanks for correction.

 

As to the second comment, please let me = elaborate:

One potential implementation of the IP stack in = the host, can be to request a Nomadic IP address and a  Sustained = IP address whenever connecting to a network, and whenever moving to a = new LAN, regardless if there are any applications requesting any = addresses. This way, whenever an application is launched and requests = either a Nomadic or Sustained IP address, the stack can provide one = without having to issue a request to the network. In this case, there is = no need for this flag from the application.

 

> Decision of which type = of IP address by default will be depending on the IP pool management = policy by operators. You case may correspond to one of them. What if = only the Nomadic IP address is basically allocated upon a network = attachment? That is, a lot of applications require mere Internet = connectivity without session continuity support. So, the Sustained IP = address will be requested on demand, and the proposed flag will be used = to get a new Sustained IP address by expressing the explicit request by = an application.

 

>>2

As I mentioned at the beginning of the = description =E2=80=93 it is a description of one alternative. I am not = assuming it is the only scenario.

Yes, I agree that many apps require only Nomadic = IP addresses, but in this example, the IP stack in the host = pre-allocates both Nomadic and Sustained IP addresses upon = attachment=E2=80=A6

 

>> As I said, it could = be, but not as general one. The proposed API is useful through the = explicit expression for any potential scenarios.

 

Yes, we can describe an alternative in which a = Nomadic IP address is pre-allocated upon NW connection (and after every = movement to a new LAN) and a Sustained (and/or Fixed) address is = allocated on-demand. Even in such a scenario, I do not see any use for = this flag =E2=80=93 see my reply to the second item = below=E2=80=A6

>>2

 

>> My answer was = already given in following answer in previous = email.

 

Another potential implementation of the IP stack = in the host is not to request IP addresses in advance. In that case, it = will issue a request for a Nomadic IP address or a Sustained IP address = the first time an application requests one and use it for subsequent = requests as long as it is not moving to a different LAN. Once it moves, = it will again request a new IP address (Nomadic or Sustained =E2=80=93 = according to what is required) after receiving the first request from = any application. In this case as well, there is no need for this = flag.

 

> Another application = requested just Sustained IP address while the IP stack has already a = Sustained IP address. Why should the IP stack try to get a new one, = though the application indicated simply =E2=80=9CSustained IP address = type=E2=80=9D? You case took a step towards a solution where you want to = draw. I don=E2=80=99t expect the action is generic when a Sustained IP = address type is requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application=E2=80=99s IP address = request.

 

>>2 =

Looks like I = did not express myself well enough (and did not fully understand your = reply). Let me list some events that might help = clarify=E2=80=A6

 

Initial state: = Mobile node is connected to a network; no Sustained IP address is = allocated. The IP stack sets a flag (SustainedIPAddressNeeded) = indicating that if an application requests a Sustained IP address, it = will have to request one from the network.

 

Event1: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Event2: A new = application that also required a Sustained IP address is launched =

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack = action: Since SustainedIPAddressNeeded  is not set, complete the = API action and associate the marked Sustained IP address with that port = (app)

 

Event3: The = mobile node moves to a new LAN

IP Stack = action: Set a flag indicating that the currently available Sustained IP = address is not optimized

 

Event4: An = application that requires a Sustained IP address is launched. =

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack = action: Since SustainedIPAddressNeeded is set, request one from the = network.

Network action: = Assigned a Sustained IP address to the mobile = node.

IP stack = action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; = (3)Complete the API action and associate the marked Sustained IP address = with that port (app)

 

Note that the = behavior of the IP stack in Event4 is exactly like the one in = Event1.

 

I believe that = this event is the one we have different of opinions: I think that the = default behavior of the IP stack is to request a new Sustained IP = address since it moved to a new LAN, and you think that it should do so = only if the application specifically requests a new Sustained IP address = via the flag you are proposing.

>>2=

 

>> You can see my = answer at the lowest =E2=80=9C>>=E2=80=9D in this = mail.

 

As a matter of fact, if such a flag is defined, = I cannot think of an example where it will not be used. It seems to me = that applications will always request a refreshed Sustained IP address = (when requesting a Sustained IP address). If this is correct, the flag = is redundant.

 

> Some applications, e.g. = email, that are not relatively restricted from optimal routing would = consider a Sustained IP address without issuing the new flag. More = applications based on such network characteristic can be thought more = than expected.

And such use of existing = Sustained IP address is not extraordinary, since IP address is a = resource, even in the consideration of IPv6 deployment. If as many as = applications require new Sustained IP address, it will end up in a lot = of network resource consumption in the mobility routers where the = Sustained IP addresses are anchored as the terminal = moves.

>>2

I am sorry but I disagree with the email = example. I categorize it as an example of an application that will = request a Nomadic address since it does not break when the mobile node = moves to a new LAN and the source IP address is changed. It simply = restarts the socket and continue with the new source IP address (the = user will not even notice this).

 

>> The example was = given as a benefit when the existing Sustained IP address is used. You = could get some insight from such kind of application not caring much the = routing distance even on the Sustained IP = address.

 

I did not understand the other text regarding = resource consumption. I thought we agreed that even of a new Sustained = IP address is requested upon each movement to a new LAN, the effect on = IP address allocation is not significant. Otherwise, my initial comment = on applications abusing the network using your proposed flag, becomes = valid again

>>2

 

>> No, our draft = didn=E2=80=99t say so. Our idea is that a new Sustained IP address is = requested upon receiving *new* flag from an application, as a preference = for a source address selection. You need to read our draft classifying = the categories of IP address request again.

 

Besides, I don=E2=80=99t = understand what is abused. Delivering its preference cannot be abuse. = Regarding =E2=80=9Cabuse=E2=80=9D, I see it in your default behavior = you=E2=80=99re assuming here. In your scenario, a new app initiated in a = new network will be forced to use a newly obtained Sustained IP address. = You see that? You totally block the possibility to be considered by the = default source address selection rules defined in RFC6724. But in our = draft, in case the need of a newly obtained Sustained IP address is = prioritized, the proposed *new* flag can be used by app=E2=80=99s = request, thus it will be selected with priority.

 

Can you provide a scenario in which an = application will not request to refresh the Sustained IP = address?

 

> It was mentioned in the = former comments.

 

 

Regards,

        &= nbsp;       = /Danny

From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

 

Hi = Danny,

 

Any = comments?

 

Regards,<= o:p>

Seil = Jeon

 

 

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

 

Hi,

 

I could attend DMM Thursday = meeting via MeetEcho.

I could also hear some raised = comments by Danny and Someone. Here goes answers to the raised = questions.

 

 

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

 

The use of the proposed API = is suggested in the SUSTAINED IP address case in the draft. On receiving = this API with the SUSTAINED IP address type at the IP stack, it will try = to get a new SUSTAINED IP address if there is no available in the = currently attached access network. So, actual obtaining of the IP = address will be tried one time while attached at a specific access = network. Even some applications put this API after, the already obtained = SUSTAINED IP will be used. So, no worries about = abuse.

 

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?

If the question is right, I = don=E2=80=99t understand what the question is meant, that is how the = host can get a new SUSTAINED IP address?

Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

 

Besides, the propsoed API is = not used alone but with the three type APIs.

 

 

 

Regards,

=

 

Seil = Jeon

 

 

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

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

______________________________= _________________

dmm mailing = list

 

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

 

------=_NextPart_000_0045_01D075FA.D2012AB0-- From nobody Mon Apr 13 09:03:26 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41B91ACE12 for ; Mon, 13 Apr 2015 09:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 rw2gJxcVhwb2 for ; Mon, 13 Apr 2015 09:03:18 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 07E3C1ACE0D for ; Mon, 13 Apr 2015 09:03:18 -0700 (PDT) Received: by paboj16 with SMTP id oj16so106583482pab.0 for ; Mon, 13 Apr 2015 09:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=jSs8p6NydoV6u2PnWbYNhD2gMhSL5fKDtt34OZe/yM0=; b=jOKNHdNgSwbd5AGMB0ZdHyOZFjwbL0jejpM/Kxo4v89a6LLiRgcQeIXSF5gzzqTFt9 9a0lmup4sXUeIw2JfQC++EXz6OSA/Ta1ROVoBHbKll64h1lRo1pzkhNrnjUFChSscwPI EI7HRaYXeF+LcR1cc1bQPUrKh3eNUmXA+mYImo82aPv/gUgaauoRwtNwxvCPzdcpQu0t NQDoxXtRiNHkMJ0ElBNwTUIawPjyyPim8Bfcj+HJT3rAmNdZ5+qs3wQIMQK1x0Uyz5sy W+TvWgC8/wJgEyGQfeKyo8yElWB7qHO+bRxRysi1jXP8j2k0XeMJhRGA3+29SLpDI79U zFSg== X-Received: by 10.68.65.38 with SMTP id u6mr26931821pbs.41.1428940997644; Mon, 13 Apr 2015 09:03:17 -0700 (PDT) Received: from [9.3.151.196] ([192.200.112.37]) by mx.google.com with ESMTPSA id gy3sm7689997pbb.42.2015.04.13.09.03.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 09:03:15 -0700 (PDT) Date: Tue, 14 Apr 2015 00:02:05 +0800 From: Dapeng Liu To: Seil Jeon Message-ID: <2779B8311BDA43BB8FFDEE2D8E7AF875@gmail.com> In-Reply-To: <004401d075f2$7030dbd0$50929370$@av.it.pt> References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <003901d06bad$75307a90$5f916fb0$@av.it.pt> <001d01d06f24$f601c000$e2054000$@av.it.pt> <000001d06fa9$f6675e30$e3361a90$@av.it.pt> <002a01d0756c$7a7637b0$6f62a710$@av.it.pt> <3255582297BB4CA98657F833BECF9AFE@gmail.com> <2453D5F265B7470B910A9161862188B0@gmail.com> <004401d075f2$7030dbd0$50929370$@av.it.pt> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552be87d_754342_e7" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 16:03:25 -0000 --552be87d_754342_e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Seil, =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=8810:02=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A= > Hi Dapeng, > =20 > I think your draft should not be compared with our draft. Our draft is = proposing some missing points through case study based on the on-demand m= obility draft. > Your draft seems proposing a different way, which is away from the on-d= emand mobility draft, from the definition of the proposed flags for local= HNP and remote HNP. It should be checked first. > =20 > =20 > =20 OK. I see your point. Then they aim to solve different problems. Regards, Dapeng Liu > =20 > =20 > --------- > The local home prefix may be preferred by applications which are > likely to discontinue operations before the device travels to distan= t > networks. On the other hand, a remote home prefix may be more > suitable for continued operation over wide areas, but at potentially= > increased cost for mobiilty management. > --------- > =20 > =20 > Best Regards, > =20 > Seil Jeon > =20 > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > Sent: Monday, April 13, 2015 2:47 PM > To: Moses, Danny > Cc: Seil Jeon; dmm=40ietf.org (mailto:dmm=40ietf.org) > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised questio= ns for the proposed API > =20 > Hi Danny, =20 > =20 > =20 > =20 > If you have read http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-= api-source-00, =20 > =20 > =20 > =20 > The main idea of the draft is proposing to define the following flag: > =20 > =20 > =20 > 3.1 (http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-0= 0=23section-3.1). Suggested indication flag > =20 > =20 > IPV6=5FPRE=46ER=5FSRC=5FNEW > =20 > /* Prefer a new IP address based on a requested IP address type as > source */ > =20 > This flag is proposed to be added in R=46C5014 (http://tools.ietf.or= g/html/rfc5014), and aims to express > the preference for enabling differentiated per-flow anchoring. The > use of the flag can be combined together with the three types of IP > address defined in =5Bdraft-yegin-dmm-ondemand-mobility (http://tool= s.ietf.org/html/draft-yegin-dmm-ondemand-mobility)=5D. It is in > equal degree and orthogonal with the defined flag-set in IPv6 socket= > API for source address selection =5BR=46C5014 (http://tools.ietf.org= /html/rfc5014)=5D. > =20 > =20 > =20 > =20 > =20 > What I=E2=80=99m asking to Seil is: is this proposal has similarity wit= h the main idea of the following two drafts: > =20 > =20 > =20 > https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 > =20 > http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > =20 > =20 > =20 > In the above drafts, the main idea is to define: > =20 > =20 > =20 > IPV6=5FPRE=46ER=5FSRC=5FLOCAL=5FHNP /* Prefer a local home prefix */ > IPV6=5FPRE=46ER=5FSRC=5FREMOTE=5FHNP /* Prefer a remote home prefix */ > =20 > =20 > =20 > =20 > =20 > Regards, > =20 > -- =20 > =20 > Dapeng Liu > =20 > =20 > =20 > =20 > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8C=E4=B8=8B=E5=8D=889:31=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF= =BC=9A > > =20 > > Again =E2=80=93 what exactly are you comparing=3F Please be more spec= ific. > > =20 > > =20 > > =20 > > =20 > > =20 > > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > > Sent: Monday, April 13, 2015 16:28 > > To: Moses, Danny > > Cc: Seil Jeon; dmm=40ietf.org (mailto:dmm=40ietf.org) > > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised quest= ions for the proposed API > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =80=EF=BC=8C=E4=B8=8B=E5=8D=889:21=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93= =EF=BC=9A > > > =20 > > > What is simpler. Can you be more specific=3F What are you comparing= =3F > > > =20 > > > =20 > > > =20 > > > =20 > > =20 > > =20 > > =E2=80=9Csimilar=22 not =E2=80=9Csimpler=E2=80=9D. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > Regards, > > =20 > > =20 > > =20 > > Dapeng Liu > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Thanks, > > > =20 > > > =20 > > > /Danny > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D =20 > > > Sent: Monday, April 13, 2015 15:54 > > > To: Seil Jeon > > > Cc: Moses, Danny; dmm=40ietf.org (mailto:dmm=40ietf.org) > > > Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer on raised que= stions for the proposed API > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Hello Seil, Danny=EF=BC=9A =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =5Bas an individual contributor=5D > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > You can refer to the following two drafts: > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > https://tools.ietf.org/html/draft-liu-dmm-address-selection-01 > > > =20 > > > =20 > > > =20 > > > http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Is it the similar idea=3F > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > -- =20 > > > =20 > > > =20 > > > =20 > > > Dapeng Liu > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF= =BC=9A > > > > =20 > > > > Hi Danny, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom your cases specified as follows; > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =E2=80=9CI am thinking of two places that might require an update= : > > > > =20 > > > > =20 > > > > When an application chooses not to specify a source address (but = request a specific type) > > > > =20 > > > > =20 > > > > When an application wishes to choose the source address from a pr= ovided list. > > > > =20 > > > > =20 > > > > =E2=80=9C > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I don=E2=80=99t understand the meaning of the second case. Why sh= ould an application wish to choose a source address from a list=3F What I= have talked about was about allowing the default source address selectio= n rules, which will be determined in the IP stack when an application is = initiated with the destination address. I think we don=E2=80=99t need to = touch it. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > The point is an application will totally assign the default sourc= e address selection mechanism based on only type request but with no pref= erence, or will request with the preference of a new Sustained IP address= as well as type request. In the former case, if there is one or multiple= Sustained IP addresses, the IP stack will try to pick up one. Or the IP = stack will try to get a new one. In the latter case, the IP stack will co= nsider a newly obtained Sustained IP address all the time, if the request= ed preference value is not less than other preferences defined in the def= ault source address selection rules. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > The need of the proposed flag and main criteria to be considered = were already covered with case studies in the draft. > > > > =20 > > > > =20 > > > > http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-= 00 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > So, for productive discussion, I would like to suggest that you c= heck our draft again please and bring your questions if there is somethin= g weird or should be updated with additional cases. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Best Regards, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Seil Jeon > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > > Sent: Sunday, April 12, 2015 1:49 PM > > > > To: Seil Jeon > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > You have a good point here. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Now I understand the need for the flag you are proposing =21=21=21= =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > We need to take a better look at R=46C 6724 and figure out if we = need to update it. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I am thinking of two places that might require an update: > > > > =20 > > > > =20 > > > > When an application chooses not to specify a source address (but = request a specific type) > > > > =20 > > > > =20 > > > > When an application wishes to choose the source address from a pr= ovided list. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > When the application indicates the desired address type, but choo= ses not to specify the source address (from a list provided by the IP sta= ck), the stack should allocate a source IP address according to the addre= ss-type requested by the application. In this case, we should consider ad= ding text to describe the behavior for Sustained IP addresses. Specifical= ly, if there are several Sustained IP addresses allocated to the mobile h= ost, whether to choose one of them, or to have the mobile host request a = new one from the network (as a result of a mobility event =E2=80=93 for e= xample). > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > When an application wishes to chooses the source address from the= available list (obtained by getaddrinfo()), there are some alternative a= pproaches we should consider: > > > > =20 > > > > =20 > > > > Enhance getaddrinfo() enabling the application to specify the req= uired address type, and return the list of source addresses that are of t= hat type (Nomadic, Sustained, =46ixed or DontCare), or - =20 > > > > =20 > > > > =20 > > > > Provide the list of addresses with an indication of their type (N= omadic, Sustained, =46ixed or TypeUnknown) and an indication of whether e= ach address is New (allocated after the last handoff event) or Old (alloc= ated before the last handoff event) > > > > =20 > > > > =20 > > > > Some other approach=E2=80=A6 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > The flag is need here, to enable the application to request a new= IP address (if the returned list only contain 'Old' addresses) =21=21=21= > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I agree that we should discuss this. How about bringing it to the= next 'Mobility Exposure and Selection WT' call=3F > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > /Danny > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > > Sent: Sunday, April 05, 2015 17:08 > > > > To: Moses, Danny > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Danny, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Meeting is always good, even with you by f-to-f. But in the discu= ssion, the main issue is whether we will allow the default source address= selection rules defined in R=46C6724 for selecting a Sustained IP addres= s among several ones or fundamentally block them for a specific reason ra= ised by a DMM need. The latter approach is not reasonable no matter how I= try to think of.it (http://of.it). > > > > =20 > > > > =20 > > > > If an application has the specific preference of a newly obtained= Sustained IP address, it uses the proposed API. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards. > > > > =20 > > > > =20 > > > > Seil > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > > Sent: Sunday, April 05, 2015 12:23 PM > > > > To: Seil Jeon > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Seil, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > By now we have been discussing this for quite some time and clear= ly we did not succeed in convincing each other. > > > > =20 > > > > =20 > > > > I suggest we try again when we have a chance to meet face to face= . Meanwhile, let's listen to what other people have to say on this matter= . > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > /Danny > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > > Sent: Sunday, April 05, 2015 01:16 > > > > To: Moses, Danny > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Resent. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Seil > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > > Sent: Saturday, April 04, 2015 1:35 PM > > > > To: 'Moses, Danny' > > > > Cc: 'dmm=40ietf.org (mailto:dmm=40ietf.org)' > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Danny, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > See the inline please. I marked current replies with =E2=80=9C>>=E2= =80=9D and previous replies with =E2=80=9C>=E2=80=9D for you to catch the= m easily. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > Seil > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > > Sent: Thursday, April 02, 2015 2:16 PM > > > > To: Seil Jeon > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Seil, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Please see my replies (surrounded by >>2) to yours. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > /Danny > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > > Sent: Tuesday, March 31, 2015 15:23 > > > > To: Moses, Danny > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Danny, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > See the inline please. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Seil Jeon =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D =20 > > > > Sent: Monday, March 30, 2015 4:44 PM > > > > To: Seil Jeon > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: RE: =5BDMM=5D Answer on raised questions for the propose= d API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Seil, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > As to the potential of abuse: > > > > =20 > > > > =20 > > > > Yes, I see your point and you are correct. If the IP stack will n= ot request a sustained IP address more than once after each movement to a= new LAN (with a different prefix), than there will be no abuse. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > > Yes, it=E2=80=99s true. Thanks for correction. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > As to the second comment, please let me elaborate: > > > > =20 > > > > =20 > > > > One potential implementation of the IP stack in the host, can be = to request a Nomadic IP address and a Sustained IP address whenever conn= ecting to a network, and whenever moving to a new LAN, regardless if ther= e are any applications requesting any addresses. This way, whenever an ap= plication is launched and requests either a Nomadic or Sustained IP addre= ss, the stack can provide one without having to issue a request to the ne= twork. In this case, there is no need for this flag from the application.= > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > > Decision of which type of IP address by default will be dependi= ng on the IP pool management policy by operators. You case may correspond= to one of them. What if only the Nomadic IP address is basically allocat= ed upon a network attachment=3F That is, a lot of applications require me= re Internet connectivity without session continuity support. So, the Sust= ained IP address will be requested on demand, and the proposed flag will = be used to get a new Sustained IP address by expressing the explicit requ= est by an application. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >>2 > > > > =20 > > > > =20 > > > > As I mentioned at the beginning of the description =E2=80=93 it i= s a description of one alternative. I am not assuming it is the only scen= ario. > > > > =20 > > > > =20 > > > > Yes, I agree that many apps require only Nomadic IP addresses, bu= t in this example, the IP stack in the host pre-allocates both Nomadic an= d Sustained IP addresses upon attachment=E2=80=A6 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >> As I said, it could be, but not as general one. The proposed A= PI is useful through the explicit expression for any potential scenarios.= > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Yes, we can describe an alternative in which a Nomadic IP address= is pre-allocated upon NW connection (and after every movement to a new L= AN) and a Sustained (and/or =46ixed) address is allocated on-demand. Even= in such a scenario, I do not see any use for this flag =E2=80=93 see my = reply to the second item below=E2=80=A6 > > > > =20 > > > > =20 > > > > >>2 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >> My answer was already given in following answer in previous em= ail. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Another potential implementation of the IP stack in the host is n= ot to request IP addresses in advance. In that case, it will issue a requ= est for a Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as it= is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained =E2=80=93 according to what is requ= ired) after receiving the first request from any application. In this cas= e as well, there is no need for this flag. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > > Another application requested just Sustained IP address while t= he IP stack has already a Sustained IP address. Why should the IP stack t= ry to get a new one, though the application indicated simply =E2=80=9CSus= tained IP address type=E2=80=9D=3F You case took a step towards a solutio= n where you want to draw. I don=E2=80=99t expect the action is generic wh= en a Sustained IP address type is requested. > > > > =20 > > > > =20 > > > > Besides, you assumption on IP address allocation seems not valid.= A mobile host would get an IP address whatever the allocated IP address = type is when it attaches at a network, regardless of an application=E2=80= =99s IP address request. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >>2 =20 > > > > =20 > > > > =20 > > > > Looks like I did not express myself well enough (and did not full= y understand your reply). Let me list some events that might help clarify= =E2=80=A6 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Initial state: Mobile node is connected to a network; no Sustaine= d IP address is allocated. The IP stack sets a flag (SustainedIPAddressNe= eded) indicating that if an application requests a Sustained IP address, = it will have to request one from the network. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Event1: An application that requires a Sustained IP address is la= unched. =20 > > > > =20 > > > > =20 > > > > APP action: App requests a Sustained IP address from the IP stack= using the proposed new API. > > > > =20 > > > > =20 > > > > IP stack action: Since SustainedIPAddressNeeded is set, request o= ne from the network. > > > > =20 > > > > =20 > > > > Network action: Assigned a Sustained IP address to the mobile nod= e. > > > > =20 > > > > =20 > > > > IP stack action: (1) Mark the new Sustained IP address as the one= to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded;= (3)Complete the API action and associate the marked Sustained IP address= with that port (app) > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Event2: A new application that also required a Sustained IP addre= ss is launched =20 > > > > =20 > > > > =20 > > > > App action: App requests a Sustained IP address from the IP stack= using the proposed new API > > > > =20 > > > > =20 > > > > IP Stack action: Since SustainedIPAddressNeeded is not set, comp= lete the API action and associate the marked Sustained IP address with th= at port (app) > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Event3: The mobile node moves to a new LAN > > > > =20 > > > > =20 > > > > IP Stack action: Set a flag indicating that the currently availab= le Sustained IP address is not optimized =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Event4: An application that requires a Sustained IP address is la= unched. =20 > > > > =20 > > > > =20 > > > > APP action: App requests a Sustained IP address from the IP stack= using the proposed new API. > > > > =20 > > > > =20 > > > > IP stack action: Since SustainedIPAddressNeeded is set, request o= ne from the network. > > > > =20 > > > > =20 > > > > Network action: Assigned a Sustained IP address to the mobile nod= e. > > > > =20 > > > > =20 > > > > IP stack action: (1) Mark the new Sustained IP address as the one= to be associated to subsequent apps; (2) Reset SustainedIPAddressNeeded;= (3)Complete the API action and associate the marked Sustained IP address= with that port (app) > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Note that the behavior of the IP stack in Event4 is exactly like = the one in Event1. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I believe that this event is the one we have different of opinion= s: I think that the default behavior of the IP stack is to request a new = Sustained IP address since it moved to a new LAN, and you think that it s= hould do so only if the application specifically requests a new Sustained= IP address via the flag you are proposing. > > > > =20 > > > > =20 > > > > >>2 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >> You can see my answer at the lowest =E2=80=9C>>=E2=80=9D in th= is mail. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > As a matter of fact, if such a flag is defined, I cannot think of= an example where it will not be used. It seems to me that applications w= ill always request a refreshed Sustained IP address (when requesting a Su= stained IP address). If this is correct, the flag is redundant. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > > Some applications, e.g. email, that are not relatively restrict= ed from optimal routing would consider a Sustained IP address without iss= uing the new flag. More applications based on such network characteristic= can be thought more than expected. > > > > =20 > > > > =20 > > > > And such use of existing Sustained IP address is not extraordinar= y, since IP address is a resource, even in the consideration of IPv6 depl= oyment. If as many as applications require new Sustained IP address, it w= ill end up in a lot of network resource consumption in the mobility route= rs where the Sustained IP addresses are anchored as the terminal moves. > > > > =20 > > > > =20 > > > > >>2 > > > > =20 > > > > =20 > > > > I am sorry but I disagree with the email example. I categorize it= as an example of an application that will request a Nomadic address sinc= e it does not break when the mobile node moves to a new LAN and the sourc= e IP address is changed. It simply restarts the socket and continue with = the new source IP address (the user will not even notice this). > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >> The example was given as a benefit when the existing Sustained= IP address is used. You could get some insight from such kind of applica= tion not caring much the routing distance even on the Sustained IP addres= s. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I did not understand the other text regarding resource consumptio= n. I thought we agreed that even of a new Sustained IP address is request= ed upon each movement to a new LAN, the effect on IP address allocation i= s not significant. Otherwise, my initial comment on applications abusing = the network using your proposed flag, becomes valid again > > > > =20 > > > > =20 > > > > >>2 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > >> No, our draft didn=E2=80=99t say so. Our idea is that a new Su= stained IP address is requested upon receiving *new* flag from an applica= tion, as a preference for a source address selection. You need to read ou= r draft classifying the categories of IP address request again. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Besides, I don=E2=80=99t understand what is abused. Delivering it= s preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, I see it= in your default behavior you=E2=80=99re assuming here. In your scenario,= a new app initiated in a new network will be forced to use a newly obtai= ned Sustained IP address. You see that=3F You totally block the possibili= ty to be considered by the default source address selection rules defined= in R=46C6724. But in our draft, in case the need of a newly obtained Sus= tained IP address is prioritized, the proposed *new* flag can be used by = app=E2=80=99s request, thus it will be selected with priority. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Can you provide a scenario in which an application will not reque= st to refresh the Sustained IP address=3F > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > > It was mentioned in the former comments. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > /Danny > > > > =20 > > > > =20 > > > > =46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =20 > > > > Sent: Monday, March 30, 2015 17:08 > > > > To: Moses, Danny > > > > Cc: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: =46W: =5BDMM=5D Answer on raised questions for the propo= sed API > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi Danny, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Any comments=3F > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > Seil Jeon > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46rom: dmm =5Bmailto:dmm-bounces=40ietf.org=5D On Behalf Of Seil= Jeon > > > > Sent: Thursday, March 26, 2015 8:08 PM > > > > To: dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > Subject: =5BDMM=5D Answer on raised questions for the proposed AP= I > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Hi, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > I could attend DMM Thursday meeting via MeetEcho. > > > > =20 > > > > =20 > > > > I could also hear some raised comments by Danny and Someone. Here= goes answers to the raised questions. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =46irst, regarding the need of the proposed API (IPV6=5FPRE=46ER=5F= SRC=5FNEW), > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > The use of the proposed API is suggested in the SUSTAINED IP addr= ess case in the draft. On receiving this API with the SUSTAINED IP addres= s type at the IP stack, it will try to get a new SUSTAINED IP address if = there is no available in the currently attached access network. So, actua= l obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the a= lready obtained SUSTAINED IP will be used. So, no worries about abuse. > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Second question sounded to me like that this API is not needed be= cause the host can get a new SUSTAINED IP address, right=3F > > > > =20 > > > > =20 > > > > If the question is right, I don=E2=80=99t understand what the que= stion is meant, that is how the host can get a new SUSTAINED IP address=3F= > > > > =20 > > > > =20 > > > > Based on the definition of three types of IP address, an applicat= ion should show its requirement with an API among them. If it is the SUST= AINED IP address, how do we expect the IP stack will try to get a new SUS= TAINED IP address=3F > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Besides, the propsoed API is not used alone but with the three ty= pe APIs. =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Regards, > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > Seil Jeon > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > > -----------------------------------------------------------------= ---- > > > > 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 distribu= tion > > > > 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 distribu= tion > > > > 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 distribu= tion > > > > 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 distribu= tion > > > > by others is strictly prohibited. If you are not the intended > > > > recipient, please contact the sender and delete all copies. > > > > =20 > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > =20 > > > > =20 > > > > =20 > > > > dmm mailing list > > > > =20 > > > > =20 > > > > =20 > > > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > > > =20 > > > > =20 > > > > =20 > > > > https://www.ietf.org/mailman/listinfo/dmm > > > > =20 > > > > =20 > > > > =20 > > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > -------------------------------------------------------------------= -- > > > A member of the Intel Corporation group of companies > > > This e-mail and any attachments may contain confidential material f= or > > > the sole use of the intended recipient(s). Any review or distributi= on > > > by others is strictly prohibited. If you are not the intended > > > recipient, please contact the sender and delete all copies. > > =20 > > =20 > > =20 > > =20 > > =20 > > ---------------------------------------------------------------------= > > 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. > =20 > =20 > =20 > =20 > =20 --552be87d_754342_e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Seil,
=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D= =8810:02=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

<=21--=5Bif gte mso 9= =5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Hi Dapeng,

 

I think your draft should not be compared with our draft. Our draf= t is proposing some missing points through case study based on the on-dem= and mobility draft.

Your draft seems proposing a different w= ay, which is away from the on-demand mobility draft, from the definition = of the proposed flags for local HNP and remote HNP. It should be checked = first.

OK.  I s= ee your point.

Then they aim to solve different = problems.

Regards,
Dapeng Liu

=

 

---------

The local home prefix may be pr= eferred by applications which are

   likely to discontinue = operations before the device travels to distant

   networks.=   On the other hand, a remote home prefix may be more

 &nbs= p; suitable for continued operation over wide areas, but at potentially

   increased cost for mobiilty management.

------= ---

 

 

Best Regards,<= /o:p>

 

Seil Jeon

 

=46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com=5D
Sent: Monday, Apr= il 13, 2015 2:47 PM
To: Moses, Danny
Cc: Seil Jeon; <= a href=3D=22mailto:dmm=40ietf.org=22>dmm=40ietf.org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D Answer = on raised questions for the proposed API

 

Hi Danny,

&= nbsp;

 

The mai= n idea of the draft is proposing to define the following flag:=

 

<= div>

3.1. Suggested indication flag

 
 
   IPV6=5FPRE=46ER=5FSRC=5FNEW
 
   /* Pre=
fer a new IP address based on a requested IP address type as
   source */
=
 
   This flag is proposed =
to be added in R=46C50=
14, and aims to express
   t=
he preference for enabling differentiated per-flow anchoring. The
   use of the flag can be combined toget=
her with the three types of IP
  =
; address defined in =5Bdraft-yegin-dmm-ondemand-mobility=5D. It =
is in
=
   equal degree and orthog=
onal with the defined flag-set in IPv6 socket
   API for source address selection =5BR=46C5014=5D.

 

 

What I=E2=80=99m asking to Seil is: is this proposa= l has similarity with the main idea of the following two drafts:

 

=E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5= =8D=889:31=EF=BC=8CMoses, Danny =E5=86=99=E9=81=93=EF=BC= =9A

Again =E2=80=93 what exactly are you compar= ing=3F Please be more specific.

 =

<= b>=46rom: Dapeng Liu =5Bmailto:maxpassion=40gmail.com= =5D
Sent: Monday, April 13, 2015 16:28
To: Moses= , Danny
Cc: Seil Jeon; dm= m=40ietf.org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D = Answer on raised questions for the proposed API

 

<= p style=3D=22margin:0cm;margin-bottom:.0001pt=22> 

=E5=9C=A8 2= 015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C= =E4=B8=8B=E5=8D=889:21<= span lang=3D=22KO=22 style=3D=22font-family:"MS Gothic";color:=23= A0A0A8=22>=EF=BC=8CMoses, Dann= y =E5=86=99=E9=81=93=EF=BC=9A

What is simpler. Can you be more specifi= c=3F What are you comparing=3F

=E2=80=9C= similar=22 not =E2=80=9Csimpler=E2=80=9D.

 

 

Regards,

= Dapeng Liu

 

=  

Thanks,

          &= nbsp;     /Danny

&= nbsp;

=46rom: Dapeng Liu = =5Bmailto:maxpassion=40gmai= l.com=5D
Sent: Monday, April 13, 2015 15:54
To: = Seil Jeon
Cc: Moses, Danny; dmm=40ietf.org
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9A =5BDMM=5D= Answer on raised questions for the proposed API

 

=

Hello Seil, Danny=EF=BC=9A=

 

=5Bas an individual contr= ibutor=5D

 

You can refer to the following two drafts:

 <= o:p>

 

= Is it the similar idea=3F

 

-- 

Dapeng Liu

 <= o:p>

=E5=9C=A8 2015=E5=B9=B44=E6=9C=8813=E6=97=A5 =E6=98=9F=E6=9C= =9F=E4=B8=80=EF=BC=8C=E4=B8=8A=E5=8D=886:03=EF=BC=8CSeil Jeon =E5=86=99=E9=81=93=EF=BC=9A

Hi Danny,

 

=46rom your cases specified as follows;

 

=E2=80= =9CI am thinking of two places that might require an update:<= /o:p>

When an applic= ation chooses not to specify a source address (but request a specific typ= e)

When a= n application wishes to choose the source address from a provided list.

=E2=80=9C<= /span>

 

I don=E2=80=99t understand the mea= ning of the second case. Why should an application wish to choose a sourc= e address from a list=3F What I have talked about was about allowing the = default source address selection rules, which will be determined in the I= P stack when an application is initiated with the destination address. I = think we don=E2=80=99t need to touch it.

 

The point is an application will totally assign the default source= address selection mechanism based on only type request = but with no preference, or will request <= span style=3D=22font-family:"Arial","sans-serif";colo= r:red=22>with the preference of a new Sustained IP address as well as typ= e request. In the former case, if there is one o= r multiple Sustained IP addresses, the IP stack will try to pick up one. = Or the IP stack will try to get a new one. In the latter case, the IP sta= ck will consider a newly obtained Sustained IP address all the time, if t= he requested preference value is not less than other preferences defined = in the default source address selection rules.

 

The need of the proposed flag and main criteria to be conside= red were already covered with case studies in the draft.

= http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-sour= ce-00

 

So, for productive discu= ssion, I would like to suggest that you check our draft again please and = bring your questions if there is something weird or should be updated wit= h additional cases.

 

 

Best Regards,

 

Seil Jeo= n

 

=46= rom: Moses, Danny =5Bmailto:danny.moses=40intel.com=5D
Sent= : Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject:= RE: =5BDMM=5D Answer on raised questions for the proposed API=

 

You have a good point here.=

 

Now I understand the need for the flag you are proposing =21=21=21

 

 

We need to take a better l= ook at R=46C 6724 and figure out if we need to update it.

 

I am thin= king of two places that might require an update:

When an application chooses not to specify a source address (= but request a specific type)

When an = application wishes to choose the source address from a provided list.

 

When the application indicates the desired address type, but chooses not= to specify the source address (from a list provided by the IP stack), th= e stack should allocate a source IP address according to the address-type= requested by the application. In this case, we should consider adding te= xt to describe the behavior for Sustained IP addresses. Specifically, if = there are several Sustained IP addresses allocated to the mobile host, wh= ether to choose one of them, or to have the mobile host request a new one= from the network (as a result of a mobility event =E2=80=93 for example)= .

=  

When an application wishes to chooses the source address from the= available list (obtained by getaddrinfo()), there are some alternative a= pproaches we should consider:

Enhance= getaddrinfo() enabling the application to specify the required address t= ype, and return the list of source addresses that are of that type (Nomad= ic, Sustained, =46ixed or DontCare), or -

Provide the list of addresses with an indication of their type (Nomad= ic, Sustained, =46ixed or TypeUnknown) and an indication of whether each = address is New (allocated after the last handoff event) or Old (allocated= before the last handoff event)

Some = other approach=E2=80=A6

 =

The flag is need here, to enable the app= lication to request a new IP address (if the returned list only contain '= Old' addresses) =21=21=21

 <= /span>

I agree that we should discuss this. = How about bringing it to the next 'Mobility Exposure and Selection WT' call=3F

=  

Regards,

=

         &nbs= p;      /Danny

 

=46rom: Seil Jeon =5Bma= ilto:seiljeon=40av.it.pt=5D
Sent: Sunday, April 05, 2015 1= 7:08
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on = raised questions for the proposed API

 

Hi Danny,=

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22> 

Meeting is always good, even with= you by f-to-f. But in the discussion, the main issue is whether we will = allow the default source address selection rules defined in R=46C6724 for= selecting a Sustained IP address among several ones or fundamentally blo= ck them for a specific reason raised by a DMM need. The latter approach i= s not reasonable no matter how I try to think of.it.

If an application has the specific preference= of a newly obtained Sustained IP address, it uses the proposed API.

 

Regards.

Seil

 

 

=46rom: Moses, D= anny =5Bmailto:danny.moses= =40intel.com=5D
Sent: Sunday, April 05, 2015 12:23 PM
<= b>To: Seil Jeon
Cc: d= mm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised quest= ions for the proposed API

 

H= i Seil,

 

<= p style=3D=22margin:0cm;margin-bottom:.0001pt=22>By now we have been discussing this for quite some time and c= learly we did not succeed in convincing each other.

=

I suggest we try again when we have a chance to meet face = to face. Meanwhile, let's listen to what other people have to say on this= matter.

 

=

Regards,

  &= nbsp;           &n= bsp; /Danny

 <= /p>

=46rom: Seil Jeon =5B= mailto:seiljeon=40av.it.pt= =5D
Sent: Sunday, April 05, 2015 01:16
To: Moses, Da= nny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for the pro= posed API

 

Resent.

 =

 

=46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D =
Sent: Saturday, April 04, 2015 1:35 PM
To: 'Moses, D= anny'
Cc: 'dmm=40ietf.org= '
Subject: RE: =5BDMM=5D Answer on raised questions for the= proposed API

 

Hi Danny,

 <= /span>

See the inline please. I marked current replies with =E2=80= =9C>>=E2=80=9D and previous replies with =E2=80=9C>=E2=80=9D for= you to catch them easily.

 

Regards= ,

= Seil

 <= o:p>

 

=46rom: Moses, Danny =5Bmailto:danny.moses=40intel.com= =5D
Sent: Thursday, April 02, 2015 2:16 = PM
To: Seil Jeon
Cc: dmm=40ietf.org=
Subject: RE: =5BDMM=5D Answer on raised questions for the prop= osed API

 

Hi Seil,

 

Ple= ase see my replies (surrounded by  >>2) to yours.<= /o:p>

 

Regard= s,

     &nbs= p;          /Danny

 

=46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.p= t=5D
Sent: Tuesday, March 31, 201= 5 15:23
To: Moses, Danny
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions for= the proposed API

 

Hi Danny,

&nb= sp;

See the inline please.

 

 

Seil Jeon

 

=  

=46ro= m: Moses, Danny =5Bmailto:danny.moses=40intel= .com=5D
Sent: Monday, March 30, 2= 015 4:44 PM
To: Seil Jeon
Cc: dmm=40ietf.org
Subject: RE: =5BDMM=5D Answer on raised questions fo= r the proposed API

 

Hi Seil,=

<= span style=3D=22color:=231=46497D=22> 

As to the potential of abuse:

= Yes, I see your point and you are correct. If the IP stack will not reque= st a sustained IP address more than once after each movement to a new LAN= (with a different prefix), than there will be no abuse.

 

> Yes, it=E2=80=99s true. Thanks for correcti= on.

 

As to the s= econd comment, please let me elaborate:

One potential implementation of the IP stack in the host, can be to requ= est a Nomadic IP address and a  Sustained IP address whenever connec= ting to a network, and whenever moving to a new LAN, regardless if there = are any applications requesting any addresses. This way, whenever an appl= ication is launched and requests either a Nomadic or Sustained IP address= , the stack can provide one without having to issue a request to the netw= ork. In this case, there is no need for this flag from the application.

 

> Decision of which type of IP = address by default will be depending on the IP pool management policy by = operators. You case may correspond to one of them. What if only the Nomad= ic IP address is basically allocated upon a network attachment=3F That is= , a lot of applications require mere Internet connectivity without sessio= n continuity support. So, the Sustained IP address will be requested on d= emand, and the proposed flag will be used to get a new Sustained IP addre= ss by expressing the explicit request by an application.

=  

>>2

As I mentioned at the beginning of the description =E2=80= =93 it is a description of one alternative. I am not assuming it is the o= nly scenario.

Yes, I agree that many = apps require only Nomadic IP addresses, but in this example, the IP stack= in the host pre-allocates both Nomadic and Sustained IP addresses upon a= ttachment=E2=80=A6

 =

>> As I = said, it could be, but not as general one. The proposed API is useful thr= ough the explicit expression for any potential scenarios.

 

Yes, we can describe an alter= native in which a Nomadic IP address is pre-allocated upon NW connection = (and after every movement to a new LAN) and a Sustained (and/or =46ixed) = address is allocated on-demand. Even in such a scenario, I do not see any= use for this flag =E2=80=93 see my reply to the second item below=E2=80=A6=

<= span style=3D=22color:=231=46497D=22>>>2

 

>> My answer was already given in following answer in = previous email.

 

Another potential implementation of the IP stack in = the host is not to request IP addresses in advance. In that case, it will= issue a request for a Nomadic IP address or a Sustained IP address the f= irst time an application requests one and use it for subsequent requests = as long as it is not moving to a different LAN. Once it moves, it will ag= ain request a new IP address (Nomadic or Sustained =E2=80=93 according to= what is required) after receiving the first request from any application= . In this case as well, there is no need for this flag.=

 

> Another application requested just Sustained= IP address while the IP stack has already a Sustained IP address. Why sh= ould the IP stack try to get a new one, though the application indicated = simply =E2=80=9CSustained IP address type=E2=80=9D=3F You case took a ste= p towards a solution where you want to draw. I don=E2=80=99t expect the a= ction is generic when a Sustained IP address type is requested.

Besides, yo= u assumption on IP address allocation seems not valid. A mobile host woul= d get an IP address whatever the allocated IP address type is when it att= aches at a network, regardless of an application=E2=80=99s IP address req= uest.

 

>>2 =

L= ooks like I did not express myself well enough (and did not fully underst= and your reply). Let me list some events that might help clarify=E2=80=A6=

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22> 

Initial state: Mobile node is con= nected to a network; no Sustained IP address is allocated. The IP stack s= ets a flag (SustainedIPAddressNeeded) indicating that if an application r= equests a Sustained IP address, it will have to request one from the netw= ork.

 

Event1: An application that req= uires a Sustained IP address is launched.

APP action: App = requests a Sustained IP address from the IP stack using the proposed new = API.

IP stack action: Since SustainedIPAddressNeeded is set= , request one from the network.

Network action: Assigned = a Sustained IP address to the mobile node.

IP stack action:= (1) Mark the new Sustained IP address as the one to be associated to sub= sequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete the API act= ion and associate the marked Sustained IP address with that port (app)

 

Event2: A new application that also re= quired a Sustained IP address is launched

App action: App = requests a Sustained IP address from the IP stack using the proposed new = API

IP Stack action: Since SustainedIPAddressNeeded  = is not set, complete the API action and associate the marked Sustained IP= address with that port (app)

 

Even= t3: The mobile node moves to a new LAN

IP Stack action: Se= t a flag indicating that the currently available Sustained IP address is = not optimized

 

Event4: An applicat= ion that requires a Sustained IP address is launched. <= /p>

AP= P action: App requests a Sustained IP address from the IP stack using the= proposed new API.

IP stack action: Since SustainedIPAddr= essNeeded is set, request one from the network.

Network a= ction: Assigned a Sustained IP address to the mobile node.

IP stack action: (1) Mark the new Sustained IP address as the one to be = associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Com= plete the API action and associate the marked Sustained IP address with t= hat port (app)

 

Note that the behav= ior of the IP stack in Event4 is exactly like the one in Event1.

 

I believe that this event is the one we= have different of opinions: I think that the default behavior of the IP = stack is to request a new Sustained IP address since it moved to a new LA= N, and you think that it should do so only if the application specificall= y requests a new Sustained IP address via the flag you are proposing.

<= span style=3D=22font-family:"Arial","sans-serif";colo= r:=231=46497D=22>>>2

 

>> You can see my a= nswer at the lowest =E2=80=9C>>=E2=80=9D in this mail.<= /o:p>

 

As a m= atter of fact, if such a flag is defined, I cannot think of an example wh= ere it will not be used. It seems to me that applications will always req= uest a refreshed Sustained IP address (when requesting a Sustained IP add= ress). If this is correct, the flag is redundant.

 

> Some applications, e.g. email, that are not relativ= ely restricted from optimal routing would consider a Sustained IP address= without issuing the new flag. More applications based on such network ch= aracteristic can be thought more than expected.

And such use of existing Su= stained IP address is not extraordinary, since IP address is a resource, = even in the consideration of IPv6 deployment. If as many as applications = require new Sustained IP address, it will end up in a lot of network reso= urce consumption in the mobility routers where the Sustained IP addresses= are anchored as the terminal moves.

= >>2

I am sorry but I disagree w= ith the email example. I categorize it as an example of an application th= at will request a Nomadic address since it does not break when the mobile= node moves to a new LAN and the source IP address is changed. It simply = restarts the socket and continue with the new source IP address (the user= will not even notice this).

 

>= ;> The example was given as a benefit when the existing Sustained IP a= ddress is used. You could get some insight from such kind of application = not caring much the routing distance even on the Sustained IP address.

 

I did not understa= nd the other text regarding resource consumption. I thought we agreed tha= t even of a new Sustained IP address is requested upon each movement to a= new LAN, the effect on IP address allocation is not significant. Otherwi= se, my initial comment on applications abusing the network using your pro= posed flag, becomes valid again

>&= gt;2

 

>> No, our draft didn=E2=80=99t say so. Our= idea is that a new Sustained IP address is requested upon receiving *new= * flag from an application, as a preference for a source address selectio= n. You need to read our draft classifying the categories of IP address re= quest again.

 

Besides, I don=E2=80=99t understand what is abused. Deliv= ering its preference cannot be abuse. Regarding =E2=80=9Cabuse=E2=80=9D, = I see it in your default behavior you=E2=80=99re assuming here. In your s= cenario, a new app initiated in a new network will be forced to use a new= ly obtained Sustained IP address. You see that=3F You totally block the p= ossibility to be considered by the default source address selection rules= defined in R=46C6724. But in our draft, in case the need of a newly obta= ined Sustained IP address is prioritized, the proposed *new* flag can be = used by app=E2=80=99s request, thus it will be selected with priority.

 

Can you provide a = scenario in which an application will not request to refresh the Sustaine= d IP address=3F

 

> It was mentioned in the former c= omments.

 

 

= Regards,

    &nbs= p;           /Danny

=46rom: Seil Jeon =5Bmailto:seiljeon=40av.it.pt=5D
= Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
<= b>Cc: = dmm=40ietf.org
Subject: =46W: =5BD= MM=5D Answer on raised questions for the proposed API

 

Hi Danny,

 

Any comments=3F

 

Regards,

Seil Jeon

 

 <= /o:p>

=46rom: dmm =5B= ma= ilto:dmm-bounces=40ietf.org=5D On Behalf = Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
T= o: dmm= =40ietf.org
Subject: =5BDMM=5D Ans= wer on raised questions for the proposed API

<= /div>

 <= /p>

Hi,

 =

I could attend= DMM Thursday meeting via MeetEcho.

I could also hear some raised comments = by Danny and Someone. Here goes answers to the raised questions.

 

 = ;

= = =46irst, regarding the need of the proposed API (IPV6=5FPRE=46ER=5FSRC=5F= NEW),

 

The use of the proposed API is suggested in the SUSTAINED IP add= ress case in the draft. On receiving this API with the SUSTAINED IP addre= ss type at the IP stack, it will try to get a new SUSTAINED IP address if= there is no available in the currently attached access network. So, actu= al obtaining of the IP address will be tried one time while attached at a= specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about abuse.

&nb= sp;

Second question sounded to me like that this API is not needed because t= he host can get a new SUSTAINED IP address, right=3F

If the question is rig= ht, I don=E2=80=99t understand what the question is meant, that is how th= e host can get a new SUSTAINED IP address=3F

Based on the definition of thr= ee types of IP address, an application should show its requirement with a= n API among them. If it is the SUSTAINED IP address, how do we expect the= IP stack will try to get a new SUSTAINED IP address=3F=

 <= /o:p>

Besides, the p= ropsoed API is not used alone but with the three type APIs. <= /o:p>

 <= o:p>

 

&nbs= p;

Regards,

 

Seil Jeon

 

 

------------------------------= ---------------------------------------
A member of the Intel Corporat= ion group of companies

This e-mail and any attachments m= ay contain confidential material for
the sole use of the intended reci= pient(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 gro= up of companies

This e-mail and any attachments may cont= ain 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 c= ompanies

This e-mail and any attachments may contain con= fidential material for
the sole use of the intended recipient(s). Any = review or distribution
by others is strictly prohibited. If you are no= t the intended
recipient, please contact the sender and delete all cop= ies.

---------------------------------------------------= ------------------
A member of the Intel Corporation group of companie= s

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F

dmm mailing list

&nbs= p;

-----------------------------------------= ----------------------------
A member of the Intel Corporation group o= f companies

This e-mail and any attachments may contain = confidential material for
the sole use of the intended recipient(s). A= ny 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 us= e of the intended recipient(s). Any review or distribution
by others i= s strictly prohibited. If you are not the intended
recipient, please c= ontact the sender and delete all copies.

 

 =20 =20 =20 =20 =20

--552be87d_754342_e7-- From nobody Tue Apr 14 01:06:44 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19B1B3524 for ; Tue, 14 Apr 2015 01:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mpt90QN3GldY for ; Tue, 14 Apr 2015 01:06:37 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF51B3520 for ; Tue, 14 Apr 2015 01:06:36 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 14 Apr 2015 01:06:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,575,1422950400"; d="scan'208,217";a="708614590" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 14 Apr 2015 01:06:34 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 14 Apr 2015 09:06:32 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by hasmsx107.ger.corp.intel.com ([10.184.198.27]) with mapi id 14.03.0224.002; Tue, 14 Apr 2015 11:06:31 +0300 From: "Moses, Danny" To: "Templin, Fred L" , "dmm@ietf.org" Thread-Topic: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Thread-Index: AdBuOH8TeAFQuqtCTx21iPn+L07HKgBWoBSAAHwB+5ABQadoAA== Date: Tue, 14 Apr 2015 08:06:31 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E37422@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E37422@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813490DD5CHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 08:06:40 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813490DD5CHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Can you please provide text that describes the use-case and the proposed te= chnical modifications/additions to support the use-case? Thanks, /Danny From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Wednesday, April 08, 2015 01:36 To: Moses, Danny; dmm@ietf.org Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Danny, Let me know what I can do to help with the mobile router part. Thanks - Fred fred.l.templin@boeing.com From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Sunday, April 05, 2015 4:49 AM To: Templin, Fred L; dmm@ietf.org Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Fred, I think we should explore prefix delegation as well. I am not familiar enou= gh if router requirements for prefix delegation and thus would appreciate y= our help - please describe a use-case and we can evaluate it. I can also think of a use-case for mobile hosts and Sustained IP addresses: In the past, I presented a scenario is which it is preferable to anchor an = IP flow in an anchor that is not necessarily the closest to the mobile node= (please refer to draft-aliahmad-dmm-anchor-selection-01). This situation c= an be detected either by the network or by the mobile node. If we want to enable mobile nodes to select a preferred anchor, we need to = provide means for mobile nodes to express the desired selection. One way is= enable mobile nodes to request a specific anchor by indicating an IP prefi= x that was provided by that anchor in the past. This could be done by 'hint= ing' the preferred IP prefix (rather than a specific IP address). Clearly there is more work to be done on this draft and we are welcoming he= lp from anyone in the group. Can you help us with the router part? Thanks, /Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, April 03, 2015 21:13 To: dmm@ietf.org Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' Hi Danny and Alper, In this draft, you seem to be considering only DHCPv6 address delegation fo= r when the node is acting as a mobile host. I am wondering if there are sim= ilar considerations for DHCPv6 prefix delegation for when the node is actin= g as a mobile router. But then, I wonder whether any type of prefix delegation other than a fixed= prefix makes any sense. For example, if the mobile router received a nomad= ic prefix delegation, would it need to renumber its connected networks ever= y time it moves and receives a new nomadic prefix? Should this document discuss prefix delegation considerations for mobile ro= uters, or only address delegation for mobile hosts? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813490DD5CHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Can you please provide= text that describes the use-case and the proposed technical modifications/= additions to support the use-case?

 

Thanks,

   &nbs= p;            /Danny=

 

From: Templin,= Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Wednesday, April 08, 2015 01:36
To: Moses, Danny; dmm@ietf.org
Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Danny,

 

Let me know what I can= do to help with the mobile router part.

 

Thanks – Fred

fred.l.templin@boeing.com

 

From: Moses, Danny [mailto:danny.moses@intel.com]
Sent: Sunday, April 05, 2015 4:49 AM
To: Templin, Fred L; dmm@ietf.org
Subject: RE: question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Fred,

 

I think we should explore prefix delegation as we= ll. I am not familiar enough if router requirements for prefix delegation a= nd thus would appreciate your help - please describe a use-case and we can = evaluate it.

 

I can also think of a use-case for mobile hosts a= nd Sustained IP addresses:

In the past, I presented a scenario is which it i= s preferable to anchor an IP flow in an anchor that is not necessarily the closest to the mobile node (please refer to draf= t-aliahmad-dmm-anchor-selection-01). This situation can be detected either = by the network or by the mobile node.

 

If we want to enable mobile nodes to select a pre= ferred anchor, we need to provide means for mobile nodes to express the des= ired selection. One way is enable mobile nodes to request a specific anchor= by indicating an IP prefix that was provided by that anchor in the past. This could be done by 'hinting' the p= referred IP prefix (rather than a specific IP address).

 

Clearly there is more work to be done on this dra= ft and we are welcoming help from anyone in the group. Can you help us with= the router part?

 

Thanks,

        &= nbsp;       /Danny

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.= org] On Behalf Of Templin, Fred L
Sent: Friday, April 03, 2015 21:13
To: dmm@ietf.org
Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility'

 

Hi Danny and Alper,

 

In this draft, you seem to be considering only DH= CPv6 address delegation for when the node is acting as a mobile host. I am = wondering if there are similar considerations for DHCPv6 prefix delegation = for when the node is acting as a mobile router.

 

But then, I wonder whether any type of prefix del= egation other than a fixed prefix makes any sense. For example, if the mobi= le router received a nomadic prefix delegation, would it need to renumber i= ts connected networks every time it moves and receives a new nomadic prefix?

 

Should this document discuss prefix delegation co= nsiderations for mobile routers, or only address delegation for mobile host= s?

 

Thanks - Fred

fred.l.templin@boeing.com=

 

_______________________________________________

dmm mailing list

dmm@ietf.org

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

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

--_000_F0CF5715D3D1884BAC731EA1103AC2813490DD5CHASMSX106gercor_-- From nobody Tue Apr 14 18:46:35 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE411B2B42 for ; Tue, 14 Apr 2015 18:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 S852j8j0kye6 for ; Tue, 14 Apr 2015 18:45:38 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 E36591A049A for ; Tue, 14 Apr 2015 18:45:37 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so30140735igb.1 for ; Tue, 14 Apr 2015 18:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y6gVT4jMaFTyUeVcjac8WYggrQQk0H50KFUpGwgh0aw=; b=blJlI0A2geGrrWDdVYXke72j+gsaaD53Y8+u8Bh6u0bLOsHyMyDUjwqESVTAI0Mz1b iEE3Y4P4zVtxgQ7IGwZeZHfm4ojoad9eFP19joE8y+Pk4OzdxkhcYI0Hfa//GvAKmUZ9 0mp5bQLO+cmOqPHkQMMD5aKo/GypgPjTNN9Z6qfAZuFwKA+7ovvcHGwTWJ+vJD4BAPfC 9Y9uwC7IpfOI7Tj5Ig3GehNNbDBlZMWT5Oni603USW1CORIHUbukFV2ADs9mj0iKIzw0 og5igsqoSlUx5PwpotGhGFC04LpQhOhx04ybEvggJJhxrEAC0j5umX9CBzpEAn0aJ4Oy lBnw== MIME-Version: 1.0 X-Received: by 10.50.221.98 with SMTP id qd2mr28260368igc.37.1429062337368; Tue, 14 Apr 2015 18:45:37 -0700 (PDT) Received: by 10.36.65.134 with HTTP; Tue, 14 Apr 2015 18:45:37 -0700 (PDT) In-Reply-To: <551D5082.3050904@gmail.com> References: <551D5082.3050904@gmail.com> Date: Wed, 15 Apr 2015 10:45:37 +0900 Message-ID: From: Satoru Matsushima To: "dmm@ietf.org" Content-Type: multipart/alternative; boundary=001a11347f20fb1b670513b98064 Archived-At: Cc: draft-wt-dmm-fpc-cpdp@tools.ietf.org Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:46:35 -0000 --001a11347f20fb1b670513b98064 Content-Type: text/plain; charset=UTF-8 As a coauthor I support to adopt this draft as a WG doc. Regards, --satoru On Thu, Apr 2, 2015 at 11:21 PM, Jouni Korhonen wrote: > Folks, > > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th EOB > PDT. > > Express your support or opposition to the mailing list. During the IETF92 > meeting we got 10 voices for the adoption so at least the same amount > supporting emails should be expected. > > > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a11347f20fb1b670513b98064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a coauthor I support to adopt this draft as a WG doc.
Regards,
--satoru

On Thu, Apr 2, 2015 at 11:21 PM, Jo= uni Korhonen <jouni.nospam@gmail.com> wrote:
Folks,

This emails starts a two week call for the I-D
=C2=A0 draft-wt-dmm-fpc-cpdp-00
to confirm the adoption as a DMM WG document. The call ends April 16th EOB = PDT.

Express your support or opposition to the mailing list. During the IETF92 m= eeting we got 10 voices for the adoption so at least the same amount suppor= ting emails should be expected.



- Jouni & Dapeng

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--001a11347f20fb1b670513b98064-- From nobody Wed Apr 15 01:25:11 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30071B3307 for ; Wed, 15 Apr 2015 01:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 97XSX1irJR-x for ; Wed, 15 Apr 2015 01:25:08 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F211B32E7 for ; Wed, 15 Apr 2015 01:24:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DC41D109B66; Wed, 15 Apr 2015 10:24:30 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYc1BprHDhBV; Wed, 15 Apr 2015 10:24:30 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id B7E6B109B70; Wed, 15 Apr 2015 10:24:20 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.23]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 10:24:20 +0200 From: Marco Liebsch To: Satoru Matsushima , "dmm@ietf.org" Thread-Topic: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 Thread-Index: AQHQbVBoH1RXadekb0KAfjV2koo7QJ1NP5WAgACQtjA= Date: Wed, 15 Apr 2015 08:24:20 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99A41258@PALLENE.office.hd> References: <551D5082.3050904@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99A41258PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Cc: "draft-wt-dmm-fpc-cpdp@tools.ietf.org" Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 08:25:10 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99A41258PALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtZSBoZXJlLCBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgV0cgZG9j dW1lbnQuDQoNCm1hcmNvDQoNCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hIFttYWlsdG86c2F0b3J1 Lm1hdHN1c2hpbWFAZ21haWwuY29tXQ0KU2VudDogTWl0dHdvY2gsIDE1LiBBcHJpbCAyMDE1IDAz OjQ2DQpUbzogZG1tQGlldGYub3JnDQpDYzogRGFwZW5nIExpdTsgZHJhZnQtd3QtZG1tLWZwYy1j cGRwQHRvb2xzLmlldGYub3JnOyBKb3VuaSBLb3Job25lbg0KU3ViamVjdDogUmU6IFtETU1dIENh bGwgZm9yIGFkb3B0aW9uOiBkcmFmdC13dC1kbW0tZnBjLWNwZHAtMDANCg0KQXMgYSBjb2F1dGhv ciBJIHN1cHBvcnQgdG8gYWRvcHQgdGhpcyBkcmFmdCBhcyBhIFdHIGRvYy4NCg0KUmVnYXJkcywN Ci0tc2F0b3J1DQoNCk9uIFRodSwgQXByIDIsIDIwMTUgYXQgMTE6MjEgUE0sIEpvdW5pIEtvcmhv bmVuIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29t Pj4gd3JvdGU6DQpGb2xrcywNCg0KVGhpcyBlbWFpbHMgc3RhcnRzIGEgdHdvIHdlZWsgY2FsbCBm b3IgdGhlIEktRA0KICBkcmFmdC13dC1kbW0tZnBjLWNwZHAtMDANCnRvIGNvbmZpcm0gdGhlIGFk b3B0aW9uIGFzIGEgRE1NIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBlbmRzIEFwcmlsIDE2dGggRU9C IFBEVC4NCg0KRXhwcmVzcyB5b3VyIHN1cHBvcnQgb3Igb3Bwb3NpdGlvbiB0byB0aGUgbWFpbGlu ZyBsaXN0LiBEdXJpbmcgdGhlIElFVEY5MiBtZWV0aW5nIHdlIGdvdCAxMCB2b2ljZXMgZm9yIHRo ZSBhZG9wdGlvbiBzbyBhdCBsZWFzdCB0aGUgc2FtZSBhbW91bnQgc3VwcG9ydGluZyBlbWFpbHMg c2hvdWxkIGJlIGV4cGVjdGVkLg0KDQoNCg0KLSBKb3VuaSAmIERhcGVuZw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0K ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQo= --_000_69756203DDDDE64E987BC4F70B71A26D99A41258PALLENEofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbWUgaGVy ZSwgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIFdHIGRvY3VtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+bWFyY288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gU2F0b3J1IE1hdHN1c2hpbWEgW21haWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDE1LiBBcHJpbCAyMDE1IDAzOjQ2PGJyPg0K PGI+VG86PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IERhcGVuZyBMaXU7IGRyYWZ0 LXd0LWRtbS1mcGMtY3BkcEB0b29scy5pZXRmLm9yZzsgSm91bmkgS29yaG9uZW48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtETU1dIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC13dC1kbW0tZnBj LWNwZHAtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgYSBjb2F1dGhvciBJIHN1cHBvcnQgdG8gYWRvcHQgdGhpcyBkcmFmdCBhcyBhIFdH IGRvYy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LXNhdG9ydTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIEFwciAyLCAyMDE1IGF0IDExOjIxIFBNLCBKb3VuaSBLb3Job25lbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5q b3VuaS5ub3NwYW1AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyw8YnI+DQo8YnI+DQpUaGlzIGVtYWlscyBzdGFydHMgYSB0 d28gd2VlayBjYWxsIGZvciB0aGUgSS1EPGJyPg0KJm5ic3A7IGRyYWZ0LXd0LWRtbS1mcGMtY3Bk cC0wMDxicj4NCnRvIGNvbmZpcm0gdGhlIGFkb3B0aW9uIGFzIGEgRE1NIFdHIGRvY3VtZW50LiBU aGUgY2FsbCBlbmRzIEFwcmlsIDE2dGggRU9CIFBEVC48YnI+DQo8YnI+DQpFeHByZXNzIHlvdXIg c3VwcG9ydCBvciBvcHBvc2l0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuIER1cmluZyB0aGUgSUVU RjkyIG1lZXRpbmcgd2UgZ290IDEwIHZvaWNlcyBmb3IgdGhlIGFkb3B0aW9uIHNvIGF0IGxlYXN0 IHRoZSBzYW1lIGFtb3VudCBzdXBwb3J0aW5nIGVtYWlscyBzaG91bGQgYmUgZXhwZWN0ZWQuPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KLSBKb3VuaSAmYW1wOyBEYXBlbmc8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+ZG1tQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_69756203DDDDE64E987BC4F70B71A26D99A41258PALLENEofficehd_-- From nobody Wed Apr 15 10:20:09 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC761B2E7F for ; Wed, 15 Apr 2015 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 vBfhubnOusdB for ; Wed, 15 Apr 2015 10:20:06 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (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 8BEC81B2E76 for ; Wed, 15 Apr 2015 10:20:06 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so59432371pdb.0 for ; Wed, 15 Apr 2015 10:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=3UEq2sQzVTQEGOdXHp9Zar1sHvW3mhIStNdqpWv3V4c=; b=LyTxCcDKUANq4G7yjtK7I/JetUW159pddBljUVwYRyUJU0RhUO3UyqanHFvLG0naE8 XweMdLJwaivn5DwgDIsUexa7y4Z9c4jt5M/Us4bhvRtJpkl1aDOmbvsIhHgW3giM07NH HclUk3JphDizwAmYe+UqtyH5tzkuXsXILgGEaRHkcNBUymgn5SWY1BSMO5f9tp012G1q sRzyBTlrH/dicBhqDbQW460d4vSfmHoP+AlSyVuh3u+oBVX5Q5pFv4mA38cuNH8SjptY CByz53DXCa+IpsS1PzxhViWMfNPGHV8j+5Y1VqLl14KIZqS7YPr2TMdFLzdmO1kEhshX Chiw== X-Received: by 10.66.162.165 with SMTP id yb5mr48990948pab.32.1429118406194; Wed, 15 Apr 2015 10:20:06 -0700 (PDT) Received: from [192.168.86.85] ([124.160.35.235]) by mx.google.com with ESMTPSA id he9sm4705017pbc.7.2015.04.15.10.20.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Apr 2015 10:20:04 -0700 (PDT) Date: Thu, 16 Apr 2015 01:16:47 +0800 From: Dapeng Liu To: Jouni Korhonen Message-ID: <06492330EB164417B87FC298A79A7569@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> References: <551D5082.3050904@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552e9d78_4db127f8_228" Archived-At: Cc: draft-wt-dmm-fpc-cpdp@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 17:20:08 -0000 --552e9d78_4db127f8_228 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =5Bas an individual contributor=5D =20 I support the adoption of this I-D. =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF= =BC=8C=E4=B8=8B=E5=8D=8810:21=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF= =BC=9A > =46olks, > =20 > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th = =20 > EOB PDT. > =20 > Express your support or opposition to the mailing list. During the =20 > IET=4692 meeting we got 10 voices for the adoption so at least the same= =20 > amount supporting emails should be expected. > =20 > =20 > =20 > - Jouni & Dapeng =20 --552e9d78_4db127f8_228 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=5Bas an individual contributor=5D

I support the adoption of this = I-D.

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C=E4=B8=8B=E5=8D=88= 10:21=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This emails starts a two week call for the I-D
draft-wt-dm= m-fpc-cpdp-00
to confirm the adoption as a DMM WG document. The= call ends April 16th
EOB PDT.

Expres= s your support or opposition to the mailing list. During the
I= ET=4692 meeting we got 10 voices for the adoption so at least the same
amount supporting emails should be expected.



- Jouni & Dapeng
=20 =20 =20 =20
=20

--552e9d78_4db127f8_228-- From nobody Wed Apr 15 10:22:37 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157011B2EA0 for ; Wed, 15 Apr 2015 10:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 FiyjZyHkP1fO for ; Wed, 15 Apr 2015 10:22:35 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 4C05D1B2E9C for ; Wed, 15 Apr 2015 10:22:35 -0700 (PDT) Received: by pdea3 with SMTP id a3so59459349pde.3 for ; Wed, 15 Apr 2015 10:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=3XQ+cLQLhDXU0vDu2xOpeqehhHUGGb7I535z9DanNkI=; b=ncl3W/ifvuhRDjDnoAdIyED03aL1Av7k7qk8/4amufC2CcsgxgaNS3knojdRUfa+1V JWChcI76LfQ3avDXxwe9rzATG4CHK463V1LvTqMQV7iNLEWaXOIsBpZgXxtMT1yfPqYj UioH/Iu+DyqXzq4DHLU7drU8N56PFBCcOlR3APSD3Q9MykDZqQ3/Fw15Q5V+2a7muSr6 JuVQlIE5NRxfLZjxbhaBvs5x73yiOAAAdnVlxTo8Rh0ltMiDN4ZXZQFX90jnKTcGUNq6 cQwx1EOLR/wCn/Opa//wHgLj5eSS4DSW7rr0aGtY9PreBzm7astGUkhylW80mI2n6N0X HlYA== X-Received: by 10.68.244.233 with SMTP id xj9mr33383803pbc.35.1429118555001; Wed, 15 Apr 2015 10:22:35 -0700 (PDT) Received: from [192.168.86.85] ([124.160.35.235]) by mx.google.com with ESMTPSA id y13sm4714416pas.37.2015.04.15.10.22.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Apr 2015 10:22:33 -0700 (PDT) Date: Thu, 16 Apr 2015 01:17:15 +0800 From: Dapeng Liu To: Jouni Korhonen Message-ID: <3675F37C1D1641D296E98B8281899D8D@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> References: <551D5082.3050904@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552e9e4a_25e45d32_228" Archived-At: Cc: draft-wt-dmm-fpc-cpdp@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 17:22:36 -0000 --552e9e4a_25e45d32_228 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =5Bas an individual contributor=5D =20 I support the adoption of this I-D. =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF= =BC=8C=E4=B8=8B=E5=8D=8810:21=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF= =BC=9A > =46olks, > =20 > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th = =20 > EOB PDT. > =20 > Express your support or opposition to the mailing list. During the =20 > IET=4692 meeting we got 10 voices for the adoption so at least the same= =20 > amount supporting emails should be expected. > =20 > =20 > =20 > - Jouni & Dapeng =20 --552e9e4a_25e45d32_228 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=5Bas an individual contributor=5D

I support the adoption of this = I-D.

-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C=E4=B8=8B=E5=8D=88= 10:21=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This emails starts a two week call for the I-D
draft-wt-dm= m-fpc-cpdp-00
to confirm the adoption as a DMM WG document. The= call ends April 16th
EOB PDT.

Expres= s your support or opposition to the mailing list. During the
I= ET=4692 meeting we got 10 voices for the adoption so at least the same
amount supporting emails should be expected.



- Jouni & Dapeng
=20 =20 =20 =20

--552e9e4a_25e45d32_228-- From nobody Wed Apr 15 16:50:44 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FC41ACD91 for ; Wed, 15 Apr 2015 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SREHJYJeaqfS for ; Wed, 15 Apr 2015 16:50:40 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12C1ACD92 for ; Wed, 15 Apr 2015 16:50:26 -0700 (PDT) Received: from [188.81.213.68] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77509271; Thu, 16 Apr 2015 00:50:23 +0100 From: "Seil Jeon" To: "'Jouni Korhonen'" , "'Dapeng Liu'" References: <551D5082.3050904@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> Date: Thu, 16 Apr 2015 00:50:24 +0100 Message-ID: <001801d077d6$f1a7d840$d4f788c0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHst65MOKYIgteTLsQOtSC4KRkszZ0WKqww Content-Language: ko Archived-At: Cc: draft-wt-dmm-fpc-cpdp@tools.ietf.org, dmm@ietf.org Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 23:50:42 -0000 Hi Jouni and Dapeng, I support this draft as "a" solution draft for now in the WT. Looking at this draft, it is definitely great, though it should be tailored as more revisions are proceeded. But regarding the adoption of this draft, I have some questions to chairs. This draft is sketched based on a deployment model, which has not been given by a draft in the relevant WT. Of course, the main idea and concept were presented by Sri in the past meetings. In this case, does the adoption of this draft mean that we will go with the deployment model in other WTs? Because deployment model affects other WTs' progresses and results. That needs to be clearly arranged. Best Regards, Seil Jeon -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Thursday, April 02, 2015 3:22 PM To: dmm@ietf.org; Jouni; Dapeng Liu; draft-wt-dmm-fpc-cpdp@tools.ietf.org Subject: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 Folks, This emails starts a two week call for the I-D draft-wt-dmm-fpc-cpdp-00 to confirm the adoption as a DMM WG document. The call ends April 16th EOB PDT. Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption so at least the same amount supporting emails should be expected. - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Apr 15 21:58:18 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858311B2FAF for ; Wed, 15 Apr 2015 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 5LcfUZCSmaPG for ; Wed, 15 Apr 2015 21:58:16 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::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 8249B1B2FAA for ; Wed, 15 Apr 2015 21:58:16 -0700 (PDT) Received: by pdea3 with SMTP id a3so78164142pde.3 for ; Wed, 15 Apr 2015 21:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bukh/pX0uIB6BmXKPxaxiDa5tcbgmmTa3CDfL4Nh4ug=; b=K/sLu13pIiBE8GHvVHQ/LwrlKqXynWn2vmPETXvDhO22AIcSztz/NZC2GsTJ293jbF lKcdbdR+149goJHOcBTZYlIMrjszGb/5y07Df6nTLYB6KuqVqTXGQJuTIuS4rT/vtYA7 uGfMV5LXQG9tlMsgcIOOh8yIU5UfP3oYEycezLPUHfVSOX/MtefiRGfcFxahOVyFl/aD /cDrOuzErCJe0kPaGBI/9QTpxjLS5MharqmjcmleCC2yceS1YyCUSQ570y6/JLU15Ga8 VpZhtrOpHkifa3AQBonkPIFSIY+VuIZdJ6f1mEhN9UyH1sd17lGPqiWKXaYTk815k60b FDnQ== X-Received: by 10.68.202.234 with SMTP id kl10mr51956706pbc.37.1429160296244; Wed, 15 Apr 2015 21:58:16 -0700 (PDT) Received: from ?IPv6:2601:9:3400:6c:e807:cefa:2bc7:b8de? ([2601:9:3400:6c:e807:cefa:2bc7:b8de]) by mx.google.com with ESMTPSA id in4sm5672800pbd.40.2015.04.15.21.58.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 21:58:14 -0700 (PDT) Message-ID: <552F4165.9020300@gmail.com> Date: Wed, 15 Apr 2015 21:58:13 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-perkins-dmm-4283mnids@tools.ietf.org References: <551C0877.1060100@gmail.com> In-Reply-To: <551C0877.1060100@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 04:58:17 -0000 Folks, The adoption call for this I-D has ended. There is a clear concensus to adopt the I-D as a working group item. - Jouni & Dapeng 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-perkins-dmm-4283mnids-01 > to confirm the aadoption s a DMM WG document. The call ends April 15th > EOB PST. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 7 voices for the adoption so at least the same > amount supporting emails should be expected. > > - Jouni & Dapeng From nobody Thu Apr 16 08:32:48 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10081A893B for ; Thu, 16 Apr 2015 08:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 rMvbLbUCnGGp for ; Thu, 16 Apr 2015 08:32:43 -0700 (PDT) Received: from mail-pd0-x244.google.com (mail-pd0-x244.google.com [IPv6:2607:f8b0:400e:c02::244]) (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 010291A89A7 for ; Thu, 16 Apr 2015 08:31:37 -0700 (PDT) Received: by pdjp10 with SMTP id p10so17751326pdj.1 for ; Thu, 16 Apr 2015 08:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=i6SUr8BdJDGZXSCmskgs0LYAAaeUKgIkGgLDNPE9DPo=; b=ZMB4QGqUhO4bjhUwpSN+pnwwETyFTJjQwGgAWdqOUDaJNGx8t6z7HybXvfj0wGA+h1 Ehs6SFIHRroDo6NbPSKY1UAEAfyoJwnNf+AVHQKWrEoa6kAOpXkjJ6aT2XabT/BohV/O 7PV6mfsyq6BWMo+5Qf7WLFH7xLISA3UkVNiTxMm1JUaiSu0agcub7JX3CJoWzScWRCvZ qlFqSpPLhaYCVfJaimqQQDj+VSwXWaGb78oJPgjFanormUaAstXlfk6qEGg+YQkhfwTT r5Kh+Qh8pzbcJo3Py/ufPjc+Ltm9SCcXuMIK8BIyntbwbJ9ScrAj2Zy5Dmd5RP/X8o1t gXrA== X-Received: by 10.68.216.99 with SMTP id op3mr57637436pbc.69.1429198296126; Thu, 16 Apr 2015 08:31:36 -0700 (PDT) Received: from [9.3.86.225] ([192.200.112.37]) by mx.google.com with ESMTPSA id nl16sm7511123pdb.56.2015.04.16.08.31.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 Apr 2015 08:31:30 -0700 (PDT) Date: Thu, 16 Apr 2015 23:21:42 +0800 From: Dapeng Liu To: Jouni Korhonen Message-ID: In-Reply-To: <551F2A6D.6080100@gmail.com> References: <551F2A6D.6080100@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552fd58f_4a2ac315_228" Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:32:47 -0000 --552fd58f_4a2ac315_228 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =5Bas an individual contributor=5D I support the idea of =E2=80=9CExposing mobility state to mobile nodes an= d network nodes=E2=80=9D as described in our charter. =46or this particular draft, after some offline discussion with the autho= rs, I still have the following comments/suggestions: 1. Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9CSust= ained IP=E2=80=9D should be clear, more clarification text would be helpf= ul. 2. Since we are trying to define API, opinion from application developers= or OS vendors would be helpful. We can invite some of those experts to j= oin the discussion. 3. Agree with Jouni=E2=80=99s opinion regarding the IPR, the group need t= o evaluate it. -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF= =BC=8C=E4=B8=8A=E5=8D=888:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF= =BC=9A > =46olks, > =20 > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the =20 > technical solution. The call ends April 17th EOB PDT. > =20 > Express your support or opposition to the mailing list. During the =20 > IET=4692 meeting we got 10 voices for the adoption and 3 against. we =20 > expect at least the same amount of expressed opinions on the list. > =20 > Notice that version -01 of this I-D had an IPR declared to it. See =20 > https://datatracker.ietf.org/ipr/2309/ > =20 > - Jouni & Dapeng =20 --552fd58f_4a2ac315_228 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=5Bas an individual contributor=5D
I support the idea of =E2=80=9CExposing mobility state to mobile nodes and network nodes=E2=80=9D as described in our charter.

=46or t= his particular draft, after some offline discussion with the authors, I s= till have the following comments/suggestions:

1.= Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9CSustai= ned IP=E2=80=9D should be clear, more clarification text would be helpful= .
2. Since we are trying to define API, opinion from applicatio= n developers or OS vendors would be helpful. We can invite some of those = experts to join the discussion.
3. Agree with Jouni=E2=80= =99s opinion regarding the IPR, the group need to evaluate it.
=
-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=88= 8:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This email starts a two week adoption call for the I-D
dra= ft-yegin-dmm-ondemand-mobility-03
to confirm its adoption as a = DMM WG document and as a basis for the
technical solution. The= call ends April 17th EOB PDT.

Express your supp= ort or opposition to the mailing list. During the
IET=4692 mee= ting we got 10 voices for the adoption and 3 against. we
expec= t at least the same amount of expressed opinions on the list.
<= br>
Notice that version -01 of this I-D had an IPR declared to = it. See

- Jo= uni & Dapeng
=20 =20 =20 =20

--552fd58f_4a2ac315_228-- From nobody Thu Apr 16 08:34:56 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B51A896D for ; Thu, 16 Apr 2015 08:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 FOcizEyv1X3i for ; Thu, 16 Apr 2015 08:34:53 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (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 5DD911A89FB for ; Thu, 16 Apr 2015 08:34:41 -0700 (PDT) Received: by pablj1 with SMTP id lj1so23141735pab.3 for ; Thu, 16 Apr 2015 08:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=rCoKXhU0iYlLO0stMSGR0P+qrBcU8g7+46VHhbxBsqI=; b=CQzMeuLvUGGTsa6pTp+dcWlSRwgPPJrpWxb0S039lz3ZHp1Otb4D6+jIiLFpOAJKmq cIZEwAim/BGu0FB5IMklkzy73AVDr/EeLGqnSFdbs3PcloEN4khV8olWLxWgq/EVkq1F HX8gywCBoJHHxxQa8qcyZABb15IOQvmfgHXZbygP8mslqvM/pmXzra2/SZvnJna9Ux0Z tR+K57+dJryiZ7s0zTeQm66q9hHqhRDlNLA9OYp+osQCl1xb5JBzgEQ3KtTZxSjUCbtD /AX+aoKVo63OC4d3xGXNT5tGecSy/ooqcRjN7KTg99l4FKOINeYotBfaTMcCm2haf0WJ Xf5g== X-Received: by 10.70.53.40 with SMTP id y8mr57750860pdo.61.1429198481117; Thu, 16 Apr 2015 08:34:41 -0700 (PDT) Received: from [9.3.86.225] ([192.200.112.37]) by mx.google.com with ESMTPSA id dc8sm7535874pdb.23.2015.04.16.08.34.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 Apr 2015 08:34:39 -0700 (PDT) Date: Thu, 16 Apr 2015 23:34:35 +0800 From: Dapeng Liu To: Jouni Korhonen Message-ID: <828E5EA5082945DDB07641DEA71523EE@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> References: <551F2A6D.6080100@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="552fd68b_6b8b4567_12b2" Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:34:54 -0000 --552fd68b_6b8b4567_12b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =5Bas an individual contributor=5D I support the idea of =E2=80=9CExposing mobility state to mobile nodes an= d network nodes=E2=80=9D as described in our charter. =46or this particular draft, after some offline discussion with the autho= rs, I still have the following comments/suggestions: 1. Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9CSust= ained IP=E2=80=9D should be clear, more clarification text would be helpf= ul. 2. Since we are trying to define API, opinion from application developers= or OS vendors would be helpful. We can invite some of those experts to j= oin the discussion. 3. Agree with Jouni=E2=80=99s opinion regarding the IPR, the group need t= o evaluate it. -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF= =BC=8C=E4=B8=8A=E5=8D=888:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF= =BC=9A > =46olks, > =20 > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the =20 > technical solution. The call ends April 17th EOB PDT. > =20 > Express your support or opposition to the mailing list. During the =20 > IET=4692 meeting we got 10 voices for the adoption and 3 against. we =20 > expect at least the same amount of expressed opinions on the list. > =20 > Notice that version -01 of this I-D had an IPR declared to it. See =20 > https://datatracker.ietf.org/ipr/2309/ > =20 > - Jouni & Dapeng =20 --552fd68b_6b8b4567_12b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=5Bas an individual contributor=5D
I support the idea of =E2=80=9CExposing mobility state to mobile nodes and network nodes=E2=80=9D as described in our charter.

=46or t= his particular draft, after some offline discussion with the authors, I s= till have the following comments/suggestions:

1.= Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9CSustai= ned IP=E2=80=9D should be clear, more clarification text would be helpful= .
2. Since we are trying to define API, opinion from applicatio= n developers or OS vendors would be helpful. We can invite some of those = experts to join the discussion.
3. Agree with Jouni=E2=80= =99s opinion regarding the IPR, the group need to evaluate it.
=
-- 
Dapeng Liu

=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=88= 8:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This email starts a two week adoption call for the I-D
dra= ft-yegin-dmm-ondemand-mobility-03
to confirm its adoption as a = DMM WG document and as a basis for the
technical solution. The= call ends April 17th EOB PDT.

Express your supp= ort or opposition to the mailing list. During the
IET=4692 mee= ting we got 10 voices for the adoption and 3 against. we
expec= t at least the same amount of expressed opinions on the list.
<= br>
Notice that version -01 of this I-D had an IPR declared to = it. See

- Jo= uni & Dapeng
=20 =20 =20 =20

--552fd68b_6b8b4567_12b2-- From nobody Thu Apr 16 09:24:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5F1B32C5 for ; Thu, 16 Apr 2015 09:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 OLr8YJi3JdaB for ; Thu, 16 Apr 2015 09:24:39 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010: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 E823C1B32A3 for ; Thu, 16 Apr 2015 09:24:34 -0700 (PDT) Received: by labbd9 with SMTP id bd9so60848351lab.2 for ; Thu, 16 Apr 2015 09:24:33 -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-type; bh=mdvjvCciIlsuI9JYdW/FTkWZdNZOzBUUf2N868Sdq4Q=; b=PToPIRtZ+KTcb/iIdLy/Tv5vW4sk762NjVmhesR75XTbQZTTvBY1/7wWQ9xR5/mLHI QIK2YlzwpwhkcIjSZpORERLvrNgdr5M6JQk3uTrwh/8psP8I4IlGMYr30ea3UQoYw25R BAR8POPpAPfWpsR4IHtgcKnzJHGYELAxewGp5vLGsgr057XxmeKIUcuijilMBDrjDl0E zKR+gIQkhE3bpPVD7Dqtm8Dh26u/ENUQj501feSBRUqW9LLJXlhUt9a3+Z39EfiOUpPh P5WdSb7M+k0tB1n21aYnaJJQbDosOrqcwbwAkJRu8QlrzNLMvdxtjclBt1qlT8Mqs9Hq V+PQ== MIME-Version: 1.0 X-Received: by 10.112.181.68 with SMTP id du4mr28301212lbc.11.1429201473444; Thu, 16 Apr 2015 09:24:33 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Thu, 16 Apr 2015 09:24:33 -0700 (PDT) In-Reply-To: <001801d077d6$f1a7d840$d4f788c0$@av.it.pt> References: <551D5082.3050904@gmail.com> <001801d077d6$f1a7d840$d4f788c0$@av.it.pt> Date: Thu, 16 Apr 2015 11:24:33 -0500 Message-ID: From: Behcet Sarikaya To: Seil Jeon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-wt-dmm-fpc-cpdp@tools.ietf.org, "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 16 Apr 2015 16:24:40 -0000 On Wed, Apr 15, 2015 at 6:50 PM, Seil Jeon wrote: > This draft is sketched based on a deployment model, which has not been given > by a draft in the relevant WT. Of course, the main idea and concept were > presented by Sri in the past meetings. In this case, does the adoption of > this draft mean that we will go with the deployment model in other WTs? > Because deployment model affects other WTs' progresses and results. That > needs to be clearly arranged. > As I said before, having WTs work on pieces of the problem without agreeing on a base protocol is not the right way to go. How could a WT improve an aspect without agreeing on what to improve? FWIW, let me say it again. Regards, Behcet From nobody Thu Apr 16 11:59:50 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B041B34B5 for ; Thu, 16 Apr 2015 11:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fGgc8tLt_JNX for ; Thu, 16 Apr 2015 11:59:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F04A1B34AE for ; Thu, 16 Apr 2015 11:59:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUY59852; Thu, 16 Apr 2015 18:59:39 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 19:59:38 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0158.001; Fri, 17 Apr 2015 02:59:34 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgCEBEbA= Date: Thu, 16 Apr 2015 18:59:34 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521F17CE@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.215] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521F17CEszxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:59:48 -0000 --_000_6E31144C030982429702B11D6746B98C521F17CEszxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZyBkcmFmdCBoYXMgYmVlbiByZXZpc2VkIGFu ZCBwb3N0ZWQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hhbi1kbW0tZGlz dHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLTAyDQoNCkNoYW5nZXMgaW5jbHVkZSB0aGUgZm9s bG93aW5nOg0KDQpyZW1vdmVkIHRoZSB3b3JkcyDigJxhbmNob3Jpbmcgb2YgYSBzZXNzaW9u4oCd IHRvIGF2b2lkIGRpc2FncmVlbWVudCBvbiBpdHMgbWVhbmluZy4gVGhhbmtzIHRvIG9mZmxpbmUg c3VnZ2VzdGlvbiBmcm9tIERhbm55IGR1cmluZyBJRVRGIG1lZXRpbmcuDQoNClVzZSB0aGUgd2Vs bCBkZWZpbmVkIHRlcm0g4oCcZmxvd+KAnS4gKFNlc3Npb24gYW5kIGZsb3cgd2VyZSB1c2VkIGlu dGVyY2hhbmdlYWJseSBpbiBwcmV2aW91cyB2ZXJzaW9uLikgVGhhbmtzIHRvIG9mZmxpbmUgc3Vn Z2VzdGlvbiBmcm9tIEpvaG4uDQoNClJlZmVyZW5jZSB0byBvdGhlciBtb2JpbGl0eSBzb2x1dGlv biBkcmFmdHMgYXJlIGV4cGxpY2l0bHkgbWFkZSwgdGhleSBoYWQgYmVlbiBjb25zaWRlcmVkIGZy b20gdGhlIHBlcnNwZWN0aXZlIG9mIGFuY2hvcmluZy4NCg0KU2VjdXJpdHkgdGV4dHMgaGF2ZSBi ZWVuIGltcHJvdmVkLg0KDQpBbGwgMyBjby1hdXRob3JzIGhhdmUgY2FyZWZ1bGx5IGNoZWNrZWQg YmVmb3JlIHdlIHVwbG9hZC4gV2UgYXJlIG5vdyB3YWl0aW5nIGZvciB5b3VyIGZlZWRiYWNrLg0K DQpUaGFua3MuDQoNCkggQW50aG9ueSBDaGFuDQoNCkZyb206IGggY2hhbg0KU2VudDogVGh1cnNk YXksIE1hcmNoIDI2LCAyMDE1IDU6NTUgUE0NClRvOiBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IEVu aGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZw0KDQpJIHdhcyBhc2tlZCB0byBwcm92aWRlIG1vcmUg ZXhwbGFuYXRpb24gYWJvdXQgYW5jaG9yaW5nLg0KDQpEaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5h Z2VtZW50IG1heSBoYXZlIGFuY2hvcmluZyBmdW5jdGlvbmFsaXR5IGluIGRpZmZlcmVudCBuZXR3 b3JrcyBzbyB0aGF0IHJvdXRlcyBkbyBub3QgbmVlZCB0byB0cmF2ZXJzZSBhIGNlbnRyYWxpemVk IGFuY2hvci4NCg0KWWV0LCB0aGUgZGVmaW5pdGlvbiBvZiAiYW5jaG9yaW5nIGZ1bmN0aW9uIiAo QUYpIGluIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlzZW1lbnQgZm9yIHRo ZSBJUCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoIGZ1bmN0aW9uIGlzIGF2YWlsYWJsZSBpbiBtdWx0 aXBsZSBuZXR3b3JrLg0KDQpTbyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB0aGUgZnVuY3Rpb25zPw0K DQpTdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0aGUgcGFja2V0cyB0byB0cmF2ZXJz ZSBjZXJ0YWluIG5vZGVzLg0KDQpDb25zaWRlciBhIHR5cGljYWwgaGFuZG92ZXIgc2NlbmFyaW86 IE1OIG1vdmVzIGZyb20gTmV0MSBtb3ZlcyB0byBOZXQyLCBhbmQgQ04gaXMgaW4gTmV0Mw0KDQpU aGUgb2xkIEFSIChBUjEpIG9mIE1OIGluIE5ldDEgcGVyZm9ybXMgUkEgZm9yIElQMTsgdGhlIG5l dyBBUiAoQVIyKSBvZiBNTiBpbiBOZXQyIHBlcmZvcm1zIFJBIGZvciBJUDI7IHRoZSBBUiAoQVIz KSBvZiBDTiBpbiBOZXQzIHBlcmZvcm1zIFJBIGZvciBJUDMuDQoNClRoZSBhZGRpdGlvbmFsIGZ1 bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0 aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBjYWxsIHRoZXNlIGFkZGl0aW9uYWwgZnVu Y3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9yaW5nIGZ1bmN0aW9uLCB0aGUgcXVlc3Rp b24gaXMgd2hhdCB0aGV5IGFyZSBhbmNob3JpbmcuDQoNClNvIGFjY29yZGluZyB0byB0aGUgZGVm aW5pdGlvbiBvZiBBRiwgQVIxIHBlcmZvcm1zIEFGIGZvciBJUDE7IEFSMiBwZXJmb3JtcyBBRiBm b3IgSVAyIChub3QgSVAxKTsgYW5kIEFSMyBwZXJmb3JtcyBBRiBmb3IgSVAzLg0KDQpPbmUgYXBw cm9hY2ggaXMgdG8gYm9ycm93IHRoZSB3ZWxsIGtub3duIGNvbmNlcHQgb2Ygc2VwYXJhdGlvbiBv ZiBzZXNzaW9uIElEIChTSUQpIGZyb20gcm91dGluZyBhZGRyZXNzLiBUaGVyZSBhcmUgdG9ucyBv ZiBwYXBlcnMgYWRkcmVzc2luZyBzdWNoIHNlcGFyYXRpb24sIGFuZCB0aGUgbGFjayBvZiBzdWNo IHNlcGFyYXRpb24gaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbSBvZiBicmVh a2luZyBzZXNzaW9uIGFzIGFuIElQIGFkZHJlc3MgY2hhbmdlcyBkdXJpbmcgaGFuZG92ZXIuDQoN CkluIGxpbmUgd2l0aCB0aGlzIHNlcGFyYXRpb24sIHRoZSBmdW5jdGlvbiBvZiBhbmNob3Jpbmcg b2YgYSBzZXNzaW9uL2Zsb3cgY2FuIGJlIHNlcGFyYXRlZCBmcm9tIHRoYXQgb2YgYW5jaG9yaW5n IGFuIElQIGFkZHJlc3MuDQoNClRoZSBzZXBhcmF0aW9uIG9mIHNlc3Npb24gSUQgYW5kIHJvdXRp bmcgYWRkcmVzcyBjYW4gYmUgY29uc2lkZXJlZCBhIGdlbmVyYWxpemF0aW9uLCBiZWNhdXNlIHRo ZSBzZXNzaW9uIElEIGNhbiBiZSBhbnl0aGluZy4gQW4gZXhhbXBsZSBpcyBISVQgaW4gdGhlIElF VEYgcHJvdG9jb2wgSElQLg0KDQpUaGUgdXNlIG9mIEhvQSBhbmQgQ29BIGNhbiBiZSBjb25zaWRl cmVkIGEgcGFydGljdWxhciBjYXNlIG9mIFNJRCBhbmQgcm91dGluZyBhZGRyZXNzIHNlcGFyYXRp b24uIEluIHVzaW5nIGluZGlyZWN0aW9uLCBvbmUgSVAgYWRkcmVzcyAoQ29BKSBpcyB1c2VkIGZv ciByb3V0aW5nLCB3aGVyZWFzIGFub3RoZXIgSVAgYWRkcmVzcyAoSG9BKSBpcyB1c2VkIGluIHRo ZSBzb2NrZXQgYXMgcGFydCBvZiB0aGUgU0lEIGlkZW50aWZpY2F0aW9uLg0KDQpBbm90aGVyIElF VEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1AuDQoNCkluIG9uZSBleGFtcGxl IG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNpcmVkIHBhdGggY2FuIGJlOg0KDQpwYWNrZXQg ZnJvbSBDTiBmaXJzdCBnb2VzIHRvIEFSMywgdG8gd2hpY2ggSVAzIGlzIGFuY2hvcmVkLg0KDQpp dCB0aGVuIGdvZXMgdG8gQVIxLCB0byB3aGljaCBJUDEgaXMgYW5jaG9yZWQuDQoNCml0IHRoZW4g Z29lcyB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC4NCg0KV2hhdCBjYXVzZXMgdGhl IHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gZ28gdGhpcyB3YXkgbWF5IGJlOg0KDQpBUjIgaGFzIHRo ZSBsb2NhdGlvbiBpbmZvcm1hdGlvbjogdGhlIGJpbmRpbmcgb2YgU0lEIG9mIHRoZSBmbG93IChJ UDEpIHRvIElQIGFkZHJlc3Mgb2YgQVIyLiBJdCBzZW5kcyB0aGlzIGluZm9ybWF0aW9uIHRvIEFS MS4NCg0KU3VjaCBhZGRpdGlvbmFsIGZ1bmN0aW9uIGJhc2ljYWxseSB0cmllcyB0byBjYXVzZSB0 aGUgcGFja2V0cyBvZiB0aGUgZmxvdyAoSVAxKSB0byB0cmF2ZXJzZSBBUjEgYW5kIEFSMi4NCg0K SW4gYW5vdGhlciBleGFtcGxlIG9mIHRoaXMgc2FtZSBzY2VuYXJpbywgdGhlIGRlc2lyZWQgcGF0 aCBpczoNCg0KcGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBp cyBhbmNob3JlZC4NCg0KaXQgdGhlbiBnb2VzIGRpcmVjdGx5IHRvIEFSMiwgdG8gd2hpY2ggSVAy IGlzIGFuY2hvcmVkLg0KDQpXaGF0IGNhdXNlcyB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byBn byB0aGlzIHdheSBtYXkgYmU6DQoNCkFSMyBoYXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uOiB0 aGUgYmluZGluZyBvZiBTSUQgb2YgdGhlIGZsb3cgKElQMSkgdG8gSVAgYWRkcmVzcyBvZiBBUjIu DQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBhbnkgb2YgdGhlc2UgaXMgbm90IGNsZWFyIGVub3Vn aC4gVGhhbmsgeW91Lg0KDQpIIEFudGhvbnkgQ2hhbg0KDQoNCg0KDQoNCg0K --_000_6E31144C030982429702B11D6746B98C521F17CEszxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSBlbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcgZHJhZnQgaGFzIGJlZW4gcmV2aXNlZCBh bmQgcG9zdGVkOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGFuLWRtbS1kaXN0cmlidXRlZC1tb2JpbGl0 eS1hbmNob3JpbmctMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGFuLWRt bS1kaXN0cmlidXRlZC1tb2JpbGl0eS1hbmNob3JpbmctMDI8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGFuZ2Vz IGluY2x1ZGUgdGhlIGZvbGxvd2luZzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cmVtb3ZlZCB0aGUgd29yZHMg4oCc YW5jaG9yaW5nIG9mIGEgc2Vzc2lvbuKAnSB0byBhdm9pZCBkaXNhZ3JlZW1lbnQgb24gaXRzIG1l YW5pbmcuIFRoYW5rcyB0byBvZmZsaW5lIHN1Z2dlc3Rpb24gZnJvbSBEYW5ueSBkdXJpbmcgSUVU RiBtZWV0aW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vc2UgdGhlIHdlbGwgZGVmaW5lZCB0ZXJtIOKAnGZsb3fi gJ0uIChTZXNzaW9uIGFuZCBmbG93IHdlcmUgdXNlZCBpbnRlcmNoYW5nZWFibHkgaW4gcHJldmlv dXMgdmVyc2lvbi4pIFRoYW5rcyB0byBvZmZsaW5lIHN1Z2dlc3Rpb24gZnJvbSBKb2huLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmVmZXJlbmNlIHRvIG90aGVyIG1vYmlsaXR5IHNvbHV0aW9uIGRyYWZ0cyBhcmUgZXhw bGljaXRseSBtYWRlLCB0aGV5IGhhZCBiZWVuIGNvbnNpZGVyZWQgZnJvbSB0aGUgcGVyc3BlY3Rp dmUgb2YgYW5jaG9yaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdXJpdHkgdGV4dHMgaGF2ZSBiZWVuIGltcHJv dmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbGwgMyBjby1hdXRob3JzIGhhdmUgY2FyZWZ1bGx5IGNoZWNrZWQg YmVmb3JlIHdlIHVwbG9hZC4gV2UgYXJlIG5vdyB3YWl0aW5nIGZvciB5b3VyIGZlZWRiYWNrLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SCBBbnRob255IENoYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGggY2hhbg0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBNYXJjaCAyNiwgMjAxNSA1OjU1IFBNPGJyPg0KPGI+VG86PC9iPiBkbW1AaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg d2FzIGFza2VkIHRvIHByb3ZpZGUgbW9yZSBleHBsYW5hdGlvbiBhYm91dCBhbmNob3Jpbmc8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRpc3RyaWJ1 dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgbWF5IGhhdmUgYW5jaG9yaW5nIGZ1bmN0aW9uYWxpdHkg aW4gZGlmZmVyZW50IG5ldHdvcmtzIHNvIHRoYXQgcm91dGVzIGRvIG5vdCBuZWVkIHRvIHRyYXZl cnNlIGEgY2VudHJhbGl6ZWQgYW5jaG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWV0LCB0aGUgZGVmaW5p dGlvbiBvZiAmcXVvdDthbmNob3JpbmcgZnVuY3Rpb24mcXVvdDsgKEFGKSZuYnNwO2luIFJGQyA3 MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlzZW1lbnQgZm9yIHRoZSBJUCBhZGRyZXNz IG9ubHksIGFuZCBzdWNoJm5ic3A7ZnVuY3Rpb24gaXMgYXZhaWxhYmxlIGluIG11bHRpcGxlIG5l dHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB0aGUgZnVuY3Rp b25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0 aGUgcGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5D b25zaWRlciBhIHR5cGljYWwgaGFuZG92ZXImbmJzcDtzY2VuYXJpbzogTU4gbW92ZXMgZnJvbSBO ZXQxIG1vdmVzIHRvIE5ldDIsIGFuZCBDTiBpcyBpbiBOZXQzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUg b2xkIEFSIChBUjEpIG9mIE1OJm5ic3A7aW4gTmV0MSBwZXJmb3JtcyBSQSBmb3IgSVAxOyB0aGUg bmV3IEFSIChBUjIpIG9mIE1OIGluIE5ldDIgcGVyZm9ybXMgUkEgZm9yIElQMjsgdGhlIEFSIChB UjMpIG9mIENOIGluIE5ldDMgcGVyZm9ybXMgUkEgZm9yIElQMy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo ZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0byBjYXVzZSB0 aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBjYWxsIHRoZXNl IGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9yaW5nIGZ1bmN0 aW9uLCB0aGUgcXVlc3Rpb24NCiBpcyB3aGF0IHRoZXkgYXJlIGFuY2hvcmluZy4gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+U28gYWNjb3JkaW5nIHRvIHRoZSZuYnNwO2RlZmluaXRpb24gb2YgQUYs IEFSMSBwZXJmb3JtcyBBRiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQMiAobm90IElQ MSk7IGFuZCBBUjMgcGVyZm9ybXMgQUYgZm9yIElQMy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T25lIGFw cHJvYWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBrbm93biBjb25jZXB0IG9mIHNlcGFyYXRpb24g b2Ygc2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRpbmcgYWRkcmVzcy4gVGhlcmUgYXJlIHRvbnMg b2YgcGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBhcmF0aW9uLCBhbmQgdGhlIGxhY2sgb2Ygc3Vj aCBzZXBhcmF0aW9uDQogaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbSBvZiBi cmVha2luZyBzZXNzaW9uJm5ic3A7YXMgYW4gSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyBoYW5k b3Zlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gbGluZSB3aXRoIHRoaXMgc2VwYXJhdGlvbiwgdGhl IGZ1bmN0aW9uIG9mIGFuY2hvcmluZyBvZiBhIHNlc3Npb24vZmxvdyBjYW4gYmUgc2VwYXJhdGVk IGZyb20gdGhhdCBvZiBhbmNob3JpbmcgYW4gSVAgYWRkcmVzcy4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhlIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCBhbmQgcm91dGluZyBhZGRyZXNzIGNhbiBiZSBj b25zaWRlcmVkIGEgZ2VuZXJhbGl6YXRpb24sIGJlY2F1c2UgdGhlIHNlc3Npb24gSUQgY2FuIGJl IGFueXRoaW5nLiBBbiBleGFtcGxlIGlzIEhJVCBpbiB0aGUgSUVURiBwcm90b2NvbCBISVAuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRoZSB1c2Ugb2YgSG9BIGFuZCBDb0EgY2FuIGJlIGNvbnNpZGVyZWQg YSBwYXJ0aWN1bGFyIGNhc2Ugb2YgU0lEIGFuZCByb3V0aW5nIGFkZHJlc3Mgc2VwYXJhdGlvbi4g SW4gdXNpbmcgaW5kaXJlY3Rpb24sIG9uZSBJUCBhZGRyZXNzIChDb0EpIGlzIHVzZWQgZm9yIHJv dXRpbmcsIHdoZXJlYXMgYW5vdGhlciBJUCBhZGRyZXNzDQogKEhvQSkgaXMgdXNlZCBpbiB0aGUg c29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBpZGVudGlmaWNhdGlvbi4gPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Bbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1AuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNp cmVkIHBhdGggY2FuIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZyb20gQ04gZmlyc3QgZ29l cyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aXQg dGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2ggSVAxIGlzIGFuY2hvcmVkLg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5pdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMgYW5jaG9yZWQuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdvIHRo aXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMiBoYXMgdGhlIGxvY2F0aW9uIGluZm9y bWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBh ZGRyZXNzIG9mIEFSMi4gSXQgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TdWNoIGFkZGl0aW9uYWwgZnVuY3Rpb24gYmFzaWNhbGx5IHRyaWVzIHRvIGNhdXNl IHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IChJUDEpIHRvIHRyYXZlcnNlIEFSMSBhbmQgQVIyLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JbiBhbm90aGVyIGV4YW1wbGUgb2YgdGhpcyBzYW1lIHNjZW5hcmlv LCB0aGUgZGVzaXJlZCBwYXRoIGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZyb20gQ04gZmly c3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pml0IHRoZW4gZ29lcyBkaXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdv IHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMyBoYXMgdGhlIGxvY2F0aW9uIGlu Zm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJ UCBhZGRyZXNzIG9mIEFSMi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxlYXNlIGxldCBtZSBrbm93IGlm IGFueSBvZiB0aGVzZSBpcyBub3QgY2xlYXIgZW5vdWdoLiBUaGFuayB5b3UuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C521F17CEszxeml557mbxchi_-- From nobody Thu Apr 16 14:20:48 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42C31A1B00 for ; Thu, 16 Apr 2015 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=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 b3wL7B-uEACj for ; Thu, 16 Apr 2015 14:20:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B1A1B3708 for ; Thu, 16 Apr 2015 14:20:33 -0700 (PDT) Received: from [192.168.3.233] ([88.235.187.9]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MeRoX-1Z0GhI35QN-00Q8e2; Thu, 16 Apr 2015 23:20:21 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_80E4FBB6-1614-4BB1-9C6F-BB0F8840FFF1" From: Alper Yegin In-Reply-To: <828E5EA5082945DDB07641DEA71523EE@gmail.com> Date: Fri, 17 Apr 2015 00:20:01 +0300 Message-Id: <9B5B2768-A34E-4262-9BD6-AE6D1DD900D4@yegin.org> References: <551F2A6D.6080100@gmail.com> <828E5EA5082945DDB07641DEA71523EE@gmail.com> To: Dapeng Liu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:8pwoWRuW609D5f37uyrFpWahOyuDVmWHvNd6KUyrj6NYWEBfjJ0 CPx0OK86o/8QzdX0Rg9Zh/AmR10JnEgUhbFxTrCuNdIks9Y+MaDvgiNAMu0ijgDUQsItzH4 5DiWNWFwvaVr2WdYPsihBWthYJAxvHRPLvhNPPcEocj0tv6cvhESROSqimS/QZourwsdwXR +ytVRWQihy7a42ovDS5zw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC15?= =?utf-8?q?egin-dmm-ondemand-mobility-03?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:20:47 -0000 --Apple-Mail=_80E4FBB6-1614-4BB1-9C6F-BB0F8840FFF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dapeng, On Apr 16, 2015, at 6:34 PM, Dapeng Liu wrote: > [as an individual contributor] >=20 > I support the idea of =E2=80=9CExposing mobility state to mobile nodes = and network nodes=E2=80=9D as described in our charter. >=20 > For this particular draft, after some offline discussion with the = authors, I still have the following comments/suggestions: >=20 > 1. Definition and distinction of "Fixed IP=E2=80=9D and =E2=80=9CSustain= ed IP=E2=80=9D should be clear, more clarification text would be = helpful. After rounds of online and offline discussions, I'm still not clear = where the issue is. Could you please explain what exactly is this issue with the current = definitions?=20 So that we can understand the residual unclarity in your mind, and we = let other people also weigh in on the matter. > 2. Since we are trying to define API, opinion from application = developers or OS vendors would be helpful. We can invite some of those = experts to join the discussion. Sure.=20 > 3. Agree with Jouni=E2=80=99s opinion regarding the IPR, the group = need to evaluate it. I really don't understand what exact "IPR evaluation" process you are = referring to. I'm not familiar with such a thing in IETF. Alper >=20 > --=20 > Dapeng Liu >=20 > =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5 = =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=888:03=EF=BC=8CJouni = Korhonen =E5=86=99=E9=81=93=EF=BC=9A >=20 >> Folks, >>=20 >> This email starts a two week adoption call for the I-D >> draft-yegin-dmm-ondemand-mobility-03 >> to confirm its adoption as a DMM WG document and as a basis for the >> technical solution. The call ends April 17th EOB PDT. >>=20 >> Express your support or opposition to the mailing list. During the >> IETF92 meeting we got 10 voices for the adoption and 3 against. we >> expect at least the same amount of expressed opinions on the list. >>=20 >> Notice that version -01 of this I-D had an IPR declared to it. See >> https://datatracker.ietf.org/ipr/2309/ >>=20 >> - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_80E4FBB6-1614-4BB1-9C6F-BB0F8840FFF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dapeng,

On Apr 16, 2015, at 6:34 PM, Dapeng Liu = wrote:

[as an individual = contributor]

I support the idea of =E2=80=9CExposing mobility state to mobile nodes = and network nodes=E2=80=9D as described in our = charter.

For this particular draft, after some = offline discussion with the authors, I still have the following = comments/suggestions:

1. Definition and = distinction of "Fixed IP=E2=80=9D and =E2=80=9CSustained IP=E2=80=9D = should be clear, more clarification text would be = helpful.

After rounds of = online and offline discussions, I'm still not clear where the issue = is.
Could you please explain what exactly is this issue with = the current definitions? 
So that we can understand the = residual unclarity in your mind, and we let other people also weigh in = on the matter.

2. = Since we are trying to define API, opinion from application developers = or OS vendors would be helpful. We can invite some of those experts to = join the = discussion.

Sure. 
<= br>
3. Agree with Jouni=E2=80=99s opinion = regarding the IPR, the group need to evaluate = it.

I really don't understand what = exact "IPR evaluation" process you are referring to.
I'm not = familiar with such a thing in = IETF.

Alper



-- 
Dapeng = Liu

=E5=9C=A8 = 2015=E5=B9=B44=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8= =8A=E5=8D=888:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=
Folks,

This email starts a = two week adoption call for the I-D
= draft-yegin-dmm-ondemand-mobility-03
to confirm its adoption = as a DMM WG document and as a basis for the
technical = solution. The call ends April 17th EOB = PDT.

Express your support or opposition to the = mailing list. During the
IETF92 meeting we got 10 voices for = the adoption and 3 against. we
expect at least the same = amount of expressed opinions on the = list.

Notice that version -01 of this I-D had = an IPR declared to it. See

- Jouni & = Dapeng
 =20 =20 =20 =20

_______________________________________________
dmm = mailing list
dmm@ietf.org
https://www.ietf.org/mail= man/listinfo/dmm

= --Apple-Mail=_80E4FBB6-1614-4BB1-9C6F-BB0F8840FFF1-- From nobody Fri Apr 17 00:04:50 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827111AD061 for ; Fri, 17 Apr 2015 00:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 Dq7syNOWAaOp for ; Fri, 17 Apr 2015 00:04:47 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 C84C71AD060 for ; Fri, 17 Apr 2015 00:04:47 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so116150579pab.3 for ; Fri, 17 Apr 2015 00:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=CiB7HKdiyCYROdqzsdFH3RwDqGCTGVqj7I6z/MhQJ7s=; b=CHlDfhi00GL/85t4Ae9vVgQxfO0vw20Ce7KbOCXgsjUIUmQGMoQVSPAA7/EZUXmFV1 pRNDHOZOUbyVYkIr3rD1YlMnXCkpGI/24q7Gq5+17e/giv5UquilOLLiLwEFgQhuj6s0 VUWNr+bl6D+xghCuVoJZHKB8rxfZ5i5UIoaAh5L8NZiUTp/lGgO2o3mQBkoefmGfvx9x 2Y4Ce/7jek/NEnNXdMs2I7oBZ5n44uFVi4wkuwDg1EZxFsxfapjlvm57zYEA9WF+oaDv UB6NTp2tHyjv/u3NOCRh5WdELiBfMvECFwjolJA74KXb8z+KB0pXVTT1Yd4qF4gs/T9H 7Vxg== X-Received: by 10.70.140.171 with SMTP id rh11mr2983447pdb.39.1429254286915; Fri, 17 Apr 2015 00:04:46 -0700 (PDT) Received: from [10.1.2.61] ([202.55.20.10]) by mx.google.com with ESMTPSA id df7sm9098773pdb.32.2015.04.17.00.04.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 Apr 2015 00:04:45 -0700 (PDT) Date: Fri, 17 Apr 2015 15:04:36 +0800 From: Dapeng Liu To: Alper Yegin Message-ID: In-Reply-To: <9B5B2768-A34E-4262-9BD6-AE6D1DD900D4@yegin.org> References: <551F2A6D.6080100@gmail.com> <828E5EA5082945DDB07641DEA71523EE@gmail.com> <9B5B2768-A34E-4262-9BD6-AE6D1DD900D4@yegin.org> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5530b084_5b25ace2_12b2" Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 07:04:49 -0000 --5530b084_5b25ace2_12b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alper, =E5=9C=A8 2015=E5=B9=B44=E6=9C=8817=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94=EF= =BC=8C=E4=B8=8A=E5=8D=885:20=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > Hi Dapeng, > =20 > On Apr 16, 2015, at 6:34 PM, Dapeng Liu wrote: > > =5Bas an individual contributor=5D > > =20 > > I support the idea of =E2=80=9CExposing mobility state to mobile node= s and network nodes=E2=80=9D as described in our charter. > > =20 > > =46or this particular draft, after some offline discussion with the a= uthors, I still have the following comments/suggestions: > > =20 > > 1. Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9C= Sustained IP=E2=80=9D should be clear, more clarification text would be h= elpful. > =20 > After rounds of online and offline discussions, I'm still not clear whe= re the issue is. > Could you please explain what exactly is this issue with the current de= finitions=3F =20 > =20 > =20 > =20 > =20 > =20 Some information is not obvious from the draft text. More explanatory tex= t will at least help the application developer to know whether this is us= eful for them. =46or example, as you said, HoA can either be =E2=80=9Cfixed IP=E2=80=9D = or =E2=80=9Csustained IP=E2=80=9D, then when HoA become =22fixed IP=22 an= d when it becomes =22sustained IP=22=3F Another example/question: Is there any =E2=80=9Cfixed IP=E2=80=9D that do= es not belong to the type of HoA=3F =20 In section 3.1: =E2=80=9C The mobile host is configures a HoA from a centrally-located Ho= me..=E2=80=9D, do you mean =E2=80=9CThe mobile host is configured a HoA = from a centrally-located Home..=E2=80=9D=3F In section 3.1: =E2=80=9CApplications running as servers at a published IP address requir= e a =46ixed IP Address.=E2=80=9D.. =20 Is there any real-life example for this requirement=3F Most server only = need static public IP address instead of =E2=80=9Cfixed IP address=E2=80=9D= (providing mobility) =3F In section 3.1: =E2=80=9CEnterprise applications that connect to an enterprise network vi= a virtual LAN require a =46ixed IP Address.=E2=80=9D can you explain the = reason=3F > So that we can understand the residual unclarity in your mind, and we l= et other people also weigh in on the matter. > =20 > > 2. Since we are trying to define API, opinion from application develo= pers or OS vendors would be helpful. We can invite some of those experts = to join the discussion. > =20 > Sure. =20 > > 3. Agree with Jouni=E2=80=99s opinion regarding the IPR, the group ne= ed to evaluate it. > =20 > I really don't understand what exact =22IPR evaluation=22 process you a= re referring to. > I'm not familiar with such a thing in IET=46. > =20 > =20 > =20 > =20 > =20 =5Bquote from Jouni=E2=80=99s mail=5D =E2=80=9Cwe need to evaluate what parts are covered by the declared IPR a= nd whether the WG agrees to keep those in the solution=E2=80=9D.. -- Dapeng =20 > =20 > Alper > =20 > =20 > > =20 > > -- =20 > > Dapeng Liu > > =20 > > =20 > > =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD= =EF=BC=8C=E4=B8=8A=E5=8D=888:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93= =EF=BC=9A > > =20 > > > =46olks, > > > =20 > > > This email starts a two week adoption call for the I-D > > > draft-yegin-dmm-ondemand-mobility-03 > > > to confirm its adoption as a DMM WG document and as a basis for the= =20 > > > technical solution. The call ends April 17th EOB PDT. > > > =20 > > > Express your support or opposition to the mailing list. During the = =20 > > > IET=4692 meeting we got 10 voices for the adoption and 3 against. w= e =20 > > > expect at least the same amount of expressed opinions on the list. > > > =20 > > > Notice that version -01 of this I-D had an IPR declared to it. See = =20 > > > https://datatracker.ietf.org/ipr/2309/ > > > =20 > > > - Jouni & Dapeng =20 > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > dmm mailing list > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > https://www.ietf.org/mailman/listinfo/dmm > =20 --5530b084_5b25ace2_12b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Alper,
=20

=E5=9C=A8 2015=E5=B9=B4= 4=E6=9C=8817=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94=EF=BC=8C=E4=B8=8A=E5=8D= =885:20=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hi Dapeng,

On Apr 1= 6, 2015, at 6:34 PM, Dapeng Liu wrote:

=5Bas an individual contributor=5D
I support the idea of =E2=80=9CExposing mobility state to mobile nodes and network nodes=E2=80=9D as described in our charter.

=46or t= his particular draft, after some offline discussion with the authors, I s= till have the following comments/suggestions:

1.= Definition and distinction of =22=46ixed IP=E2=80=9D and =E2=80=9CSustai= ned IP=E2=80=9D should be clear, more clarification text would be helpful= .

After rounds of onlin= e and offline discussions, I'm still not clear where the issue is.
<= div>Could you please explain what exactly is this issue with the current = definitions=3F 
Some information is not obvious from the draft text. More ex= planatory text will at least help the application developer to know wheth= er this is useful for them.
=46or example, as you said, HoA can= either be =E2=80=9Cfixed IP=E2=80=9D or =E2=80=9Csustained IP=E2=80=9D, = then when HoA become =22fixed IP=22 and when it becomes =22sustained IP=22= =3F
Another example/question: Is there any =E2=80=9Cfixed= IP=E2=80=9D that does not belong to the type of HoA=3F  
=

In section 3.1:
=E2=80=9C The mobile host is co= nfigures a HoA from a centrally-located Home..=E2=80=9D,  do = you mean =E2=80=9CThe mobile h= ost is configured a HoA from a centrally-located Home..=E2=80=9D=3F=

In section 3.1:
=E2=80=9CApplications running as serv= ers at a published IP address require a =46ixed IP Address.=E2=80=9D..&nb= sp;
Is there any real-life example for this requirement=3F &nbs= p;Most server only need static public IP address instead of =E2=80=9Cfixe= d IP address=E2=80=9D (providing mobility) =3F

I= n section 3.1:
=E2=80=9CEnterprise applications that connect to an enterprise networ= k via virtual LAN require a =46ixed IP Address.=E2=80=9D can you exp= lain the reason=3F


So that we can understand = the residual unclarity in your mind, and we let other people also weigh i= n on the matter.

<= div>2. Since we are trying to define API, opinion from application develo= pers or OS vendors would be helpful. We can invite some of those experts = to join the discussion.

Sure.=  

3. Agree with Jouni=E2= =80=99s opinion regarding the IPR, the group need to evaluate it.

I really don't understand what exact =22IP= R evaluation=22 process you are referring to.
I'm not familiar = with such a thing in IET=46.
=5Bquote from Jouni=E2=80=99s mail=5D
=E2=80= =9Cwe need to evaluate what parts are covered by the declared IPR and whe= ther the WG agrees to keep those in the solution=E2=80=9D..


--
Dapeng
 

<= /div>
Alper



-- 
Dapeng Liu

=E5=9C=A8 2015=E5=B9=B44=E6=9C= =884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=888:03=EF= =BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

This email starts a two week adoption call for the I-D
dra= ft-yegin-dmm-ondemand-mobility-03
to confirm its adoption as a = DMM WG document and as a basis for the
technical solution. The= call ends April 17th EOB PDT.

Express your supp= ort or opposition to the mailing list. During the
IET=4692 mee= ting we got 10 voices for the adoption and 3 against. we
expec= t at least the same amount of expressed opinions on the list.
<= br>
Notice that version -01 of this I-D had an IPR declared to = it. See

- Jo= uni & Dapeng
=20 =20 =20 =20

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
dmm mailing list
dmm=40ie= tf.org
h= ttps://www.ietf.org/mailman/listinfo/dmm
=
=20 =20 =20 =20

--5530b084_5b25ace2_12b2-- From nobody Fri Apr 17 00:50:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D01B2A28 for ; Fri, 17 Apr 2015 00:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=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 17Z1OXZywWwy for ; Fri, 17 Apr 2015 00:50:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4B71B2A7E for ; Fri, 17 Apr 2015 00:50:45 -0700 (PDT) Received: from [192.168.3.233] ([88.235.187.9]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MYuNZ-1YoFpm0fWF-00VgEm; Fri, 17 Apr 2015 09:50:31 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_08BF1E51-C185-4A93-906C-2B9656A72491" From: Alper Yegin In-Reply-To: Date: Fri, 17 Apr 2015 10:50:05 +0300 Message-Id: <2BE0495E-D92E-452A-9547-59DF7BCD03AD@yegin.org> References: <551F2A6D.6080100@gmail.com> <828E5EA5082945DDB07641DEA71523EE@gmail.com> <9B5B2768-A34E-4262-9BD6-AE6D1DD900D4@yegin.org> To: Dapeng Liu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:0NuEHdQALxQugZ6K3pbeqw62KFAhLqJnsx6XiRwG9RtHD/SAc3R C3GktPa7uz1j0USsvlhayAX5WtLpitWkOYxtV888ZTB3SLMTQHIT3vUErJvIU73wGIK03La VE70o98uO4g+En0sHXo4wg5dBAIKcn0A1jWvkAx7zSiQQcwkhZgk6LjJJV6I8IbVMqBR9Ur 97u+lGr+a27tNQ2D5NUrA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-yegin-dmm-ondemand-mobility@tools.ietf.org, "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICDlm57lpI3vvJogQ2FsbCBmb3IgYWRvcHRp?= =?utf-8?q?on=3A_draft-yegin-dmm-ondemand-mobility-03?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 07:50:49 -0000 --Apple-Mail=_08BF1E51-C185-4A93-906C-2B9656A72491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dapeng, >>=20 >>> [as an individual contributor] >>>=20 >>> I support the idea of =E2=80=9CExposing mobility state to mobile = nodes and network nodes=E2=80=9D as described in our charter. >>>=20 >>> For this particular draft, after some offline discussion with the = authors, I still have the following comments/suggestions: >>>=20 >>> 1. Definition and distinction of "Fixed IP=E2=80=9D and =E2=80=9CSusta= ined IP=E2=80=9D should be clear, more clarification text would be = helpful. >>=20 >> After rounds of online and offline discussions, I'm still not clear = where the issue is. >> Could you please explain what exactly is this issue with the current = definitions?=20 > Some information is not obvious from the draft text. More explanatory = text will at least help the application developer to know whether this = is useful for them. > For example, as you said, HoA can either be =E2=80=9Cfixed IP=E2=80=9D = or =E2=80=9Csustained IP=E2=80=9D, then when HoA become "fixed IP" and = when it becomes "sustained IP"? When a HoA is called "fixed" vs "sustained" is already provided by the = respective definitions in the I-D: - Fixed IP Address This is what standard Mobile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP address of the mobile host. - Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. A sustained IP address may be configured and maintained by using access network anchoring, corresponding network anchoring, or some other solution. If these definitions are not clear, please recommend improvement. If you are asking about "how the IP stack on the mobile node" configures = such IP addresses, as you know this is not in the scope of this API = document, but that'll be addressed by the protocol solutions in DMM. If you are asking about something else, please clarify that too. I tried = to answer your question based on my understanding of what it might be. > Another example/question: Is there any =E2=80=9Cfixed IP=E2=80=9D that = does not belong to the type of HoA? =20 >=20 What do you mean? >=20 > In section 3.1: > =E2=80=9C The mobile host is configures a HoA from a centrally-located = Home..=E2=80=9D, do you mean =E2=80=9CThe mobile host is configured a = HoA from a centrally-located Home..=E2=80=9D? >=20 Yes, it's a typo. (is configured with, or configures). > In section 3.1: > =E2=80=9CApplications running as servers at a published IP address = require a Fixed IP Address.=E2=80=9D..=20 > Is there any real-life example for this requirement? =20 This is by definition, right? If you are running a server, you need need to publish its IP address (in = DNS, for example). And you want that address to be "fixed" (i.e., not changing). And that's = what we call "Fixed IP address" in this I-D. Please see the below links for real-life examples of how operators are = already marketing such things: = https://www.wireless.att.com/businesscenter/popups/general/custom-ip-addre= ssing.jsp = http://www.verizonwireless.com/businessportals/support/faqs/DataServices/f= aq_static_ip.html > Most server only need static public IP address instead of =E2=80=9Cfixed= IP address=E2=80=9D (providing mobility) ? >=20 Please see the examples on the links above. > In section 3.1: > =E2=80=9CEnterprise applications that connect to an enterprise network = via virtual LAN require a Fixed IP Address.=E2=80=9D can you explain the = reason? >=20 This is about Enterprise APN. Or, for example, what AT&T refers to as "customer-provided IP = addresses". See the above link, and the below text: Customer-provided IP addresses: If you decide to provide your own IP = address block for your mobile data configuration, you will essentially = extend your company's wide area network to include the AT&T cellular = network. This allows for simpler firewall configuration, as well as = mobile device identification. >=20 >> So that we can understand the residual unclarity in your mind, and we = let other people also weigh in on the matter. >>=20 >>> 2. Since we are trying to define API, opinion from application = developers or OS vendors would be helpful. We can invite some of those = experts to join the discussion. >>=20 >> Sure.=20 >>=20 >>> 3. Agree with Jouni=E2=80=99s opinion regarding the IPR, the group = need to evaluate it. >>=20 >> I really don't understand what exact "IPR evaluation" process you are = referring to. >> I'm not familiar with such a thing in IETF. > [quote from Jouni=E2=80=99s mail] > =E2=80=9Cwe need to evaluate what parts are covered by the declared = IPR and whether the WG agrees to keep those in the solution=E2=80=9D.. >=20 Yeah, I know. I also told Jouni that I don't know what exact process = he's referring to. Anyways, if any of the chairs are referring to some IETF process, I'd = like to know what that is. I'm not familiar with it. If there's such a thing, we need to make sure = it's an official IETF process, and it'll be applied to all docs across = the DMM, and already being applied across the IETF.=20 Regards, Alper >=20 > -- > Dapeng > =20 >>=20 >> Alper >>=20 >>=20 >>>=20 >>> --=20 >>> Dapeng Liu >>>=20 >>> =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5 = =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=888:03=EF=BC=8CJouni = Korhonen =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>>> Folks, >>>>=20 >>>> This email starts a two week adoption call for the I-D >>>> draft-yegin-dmm-ondemand-mobility-03 >>>> to confirm its adoption as a DMM WG document and as a basis for the >>>> technical solution. The call ends April 17th EOB PDT. >>>>=20 >>>> Express your support or opposition to the mailing list. During the >>>> IETF92 meeting we got 10 voices for the adoption and 3 against. we >>>> expect at least the same amount of expressed opinions on the list. >>>>=20 >>>> Notice that version -01 of this I-D had an IPR declared to it. See >>>> https://datatracker.ietf.org/ipr/2309/ >>>>=20 >>>> - Jouni & Dapeng >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 --Apple-Mail=_08BF1E51-C185-4A93-906C-2B9656A72491 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dapeng,


[as an individual = contributor]

I support the idea of =E2=80=9CExposing mobility state to mobile nodes = and network nodes=E2=80=9D as described in our = charter.

For this particular draft, after some = offline discussion with the authors, I still have the following = comments/suggestions:

1. Definition and = distinction of "Fixed IP=E2=80=9D and =E2=80=9CSustained IP=E2=80=9D = should be clear, more clarification text would be = helpful.

After rounds = of online and offline discussions, I'm still not clear where the issue = is.
Could you please explain what exactly is this issue with = the current = definitions? 
=
Some information is not obvious from the draft text. More = explanatory text will at least help the application developer to know = whether this is useful for them.

For example, as you said, HoA can either be = =E2=80=9Cfixed IP=E2=80=9D or =E2=80=9Csustained IP=E2=80=9D, then when = HoA become "fixed IP" and when it becomes "sustained = IP"?

When a HoA is called = "fixed" vs "sustained" is already provided by the respective definitions = in the I-D:

- Fixed IP Address

   This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP
   address of the mobile host.

   - Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.

   A sustained IP address may be configured and maintained by using
   access network anchoring, corresponding network anchoring, or some
   other solution.

If these definitions are not = clear, please recommend improvement.

If you are = asking about "how the IP stack on the mobile node" configures such IP = addresses, as you know this is not in the scope of this API document, = but that'll be addressed by the protocol solutions in = DMM.

If you are asking about something else, = please clarify that too. I tried to answer your question based on my = understanding of what it might be.

Another example/question: Is there any =E2=80=9Cfixed = IP=E2=80=9D that does not belong to the type of HoA? =  


What do you = mean?



In section 3.1:
=E2=80=9C The mobile host is = configures a HoA from a centrally-located Home..=E2=80=9D, =  do you mean =E2=80=9CThe = mobile host is configured a HoA from a centrally-located = Home..=E2=80=9D?


Yes, it's a typo. (is configured with, or = configures).


In = section 3.1:
=E2=80=9CApplications running as servers at a published = IP address require a Fixed IP Address.=E2=80=9D.. 
Is there = any real-life example for this requirement? =  

This is by definition, = right?
If you are running a server, you need need to publish = its IP address (in DNS, for example).
And you want that = address to be "fixed" (i.e., not changing). And that's what we call = "Fixed IP address" in this I-D.

Please see the = below links for real-life examples of how operators are already = marketing such things:



=


Most server only need static public IP address = instead of =E2=80=9Cfixed IP address=E2=80=9D (providing mobility) = ?



Plea= se see the examples on the links = above.


In section 3.1:
=E2=80=9CEnterprise applications that = connect to an enterprise network via virtual LAN require a Fixed IP = Address.=E2=80=9D can you explain the = reason?


This is = about Enterprise APN.
Or, for example, what AT&T refers to = as "customer-provided IP addresses". See the above link, and the below = text:

Customer-provided IP = addresses: If you decide to = provide your own IP address block for your mobile data configuration, = you will essentially extend your company's wide area network to include = the AT&T cellular network. This allows for simpler firewall = configuration, as well as mobile device = identification.



So that we can = understand the residual unclarity in your mind, and we let other people = also weigh in on the matter.

2. Since we are trying to define API, opinion = from application developers or OS vendors would be helpful. We can = invite some of those experts to join the = discussion.

Sure. 
<= br>
3. Agree with Jouni=E2=80=99s opinion = regarding the IPR, the group need to evaluate = it.

I really don't understand what = exact "IPR evaluation" process you are referring to.
I'm not = familiar with such a thing in = IETF.
[quote = from Jouni=E2=80=99s mail]
=E2=80=9Cwe need to evaluate = what parts are covered by the declared IPR and whether the WG agrees to = keep those in the = solution=E2=80=9D..


=
Yeah, I know. I also told Jouni that I don't know what exact = process he's referring to.
Anyways, if any of the chairs are = referring to some IETF process, I'd like to know what that = is.

I'm not familiar with it. If there's such a = thing, we need to make sure it's an official IETF process, and it'll be = applied to all docs across the DMM, and already being applied across the = IETF. 

Regards,

Alp= er




<= br>


--
Dapeng
 

Alper



-- 
Dapeng = Liu

=E5=9C=A8 = 2015=E5=B9=B44=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD=EF=BC=8C=E4=B8= =8A=E5=8D=888:03=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=
Folks,

This email starts a = two week adoption call for the I-D
= draft-yegin-dmm-ondemand-mobility-03
to confirm its adoption = as a DMM WG document and as a basis for the
technical = solution. The call ends April 17th EOB = PDT.

Express your support or opposition to the = mailing list. During the
IETF92 meeting we got 10 voices for = the adoption and 3 against. we
expect at least the same = amount of expressed opinions on the = list.

Notice that version -01 of this I-D had = an IPR declared to it. See

- Jouni & = Dapeng
 =20 =20 =20 =20

_______________________________________________
dmm = mailing list
dmm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dmm

<= /span> =20 =20 =20 =20


= --Apple-Mail=_08BF1E51-C185-4A93-906C-2B9656A72491-- From nobody Fri Apr 17 09:27:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627051A1B7A for ; Fri, 17 Apr 2015 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9kRNKQhPZIfq for ; Fri, 17 Apr 2015 09:27:37 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C73B1A0262 for ; Fri, 17 Apr 2015 09:27:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3HGRaki008460; Fri, 17 Apr 2015 09:27:36 -0700 Received: from XCH-BLV-104.nw.nos.boeing.com (xch-blv-104.nw.nos.boeing.com [130.247.25.120]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3HGRWGp008437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 17 Apr 2015 09:27:33 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.139]) with mapi id 14.03.0235.001; Fri, 17 Apr 2015 09:27:32 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: AERO as DMM working group item Thread-Index: AdB5KtmwGS4RWcPtRAGuebRvwStgRg== Date: Fri, 17 Apr 2015 16:27:31 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4B634@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [DMM] AERO as DMM working group item X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 16:27:38 -0000 Hello, I would like to request adoption of AERO as a DMM working group item as a solution for enhanced mobility anchoring in particular and distributed mobility management in general. The latest draft version of AERO is here: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thank you for your consideration, Fred Templin fred.l.templin@boeing.com From nobody Fri Apr 17 10:31:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75D91A9043 for ; Fri, 17 Apr 2015 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 H7r45yOG28t5 for ; Fri, 17 Apr 2015 10:31:36 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 B78081A903F for ; Fri, 17 Apr 2015 10:31:36 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so134372038pdb.1 for ; Fri, 17 Apr 2015 10:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0SsYXquOidNQdK10Z8Jr/V3tIKIN+pJrQbL815HaQrE=; b=ubtz9katpkdnhyN6kv4otiqio1ltATPT/1j93pyzPI+MX3Rc2vVtdwdl3biLf9OVwV TIBP+snK3Imj96AIt8BW7EVC+lxRzkzuPg/45XBd8IPtfRL/p0H4K9pES65hy+cdmCB5 V70+G8Mu31RADIHjo/PQwS8OFy1yxpMN2M9DTRbKqtUG+xPUAGn5PX1GIhDcgmY1rGRm da1QH7XUiz0gUmqcK8KqNKha8t7xKF5fgaEfoz3KxExMvQtbfnuiNqPsejtSWA3MN+AF fBPod9sxrLD/JzThj3O7nnyH07GQ/WT9YWoIbB2/ymk+l9rNPw9v9FYrBMKoF4E6oMSt kE+Q== X-Received: by 10.66.188.107 with SMTP id fz11mr7342548pac.85.1429291896437; Fri, 17 Apr 2015 10:31:36 -0700 (PDT) Received: from [10.16.10.132] ([216.31.219.19]) by mx.google.com with ESMTPSA id sb4sm10714225pbb.5.2015.04.17.10.31.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 10:31:35 -0700 (PDT) Message-ID: <55314374.8040700@gmail.com> Date: Fri, 17 Apr 2015 10:31:32 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-wt-dmm-fpc-cpdp@tools.ietf.org, Jouni References: <551D5082.3050904@gmail.com> In-Reply-To: <551D5082.3050904@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 17:31:38 -0000 Folks, The call for this I-D has ended and confirms the show of hands we had in Dallas meeting. The I-D will be adopted as a WG document. Just to remind that this document serves as a basis for WG to continue to work on. The Forwarding Policy Configuration document describes on an example/reference architecture and there is still room for specific deployment architectures to be documented using the building blocks described in this documents. - Jouni & Dapeng 4/2/2015, 7:21 AM, Jouni Korhonen kirjoitti: > Folks, > > This emails starts a two week call for the I-D > draft-wt-dmm-fpc-cpdp-00 > to confirm the adoption as a DMM WG document. The call ends April 16th > EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption so at least the same > amount supporting emails should be expected. > > > > - Jouni & Dapeng From nobody Sun Apr 19 17:24:55 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA571A907C for ; Sun, 19 Apr 2015 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 wJq7CFmZZe0J for ; Sun, 19 Apr 2015 17:24:50 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 DBB341A907B for ; Sun, 19 Apr 2015 17:24:49 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so189295460pab.2 for ; Sun, 19 Apr 2015 17:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qkYEO6gRCC1dty4FkFG7umrczTSaQfMWIPNpNpMwMvU=; b=w5RouexEjK9OjV4Z/N1b3fNTjXEG29EF6MRaDKIBM/oGFF1FeqsNJdfGFWtVlgdl0o RBsdnLxOc+FaJ33/AAOZyQqKbXMUrKiK99GYLr7U6RiMP5B//bA+FNpLbqAtNfXj0qVs l4SIN3OnYhTbS6sbQxsg8jlnKNDqMW33IMC6jHjNw6cfG++Ehk7WfANP3XQnyAFgdVwT HSO7a2JbbphCQisqcMUBleX0Rb6l5eFcHkQXye3M2NHcskmY4f1aqMjPbJbGSPsLCgSq QA0nFSWiMXnTNY6WbBdBv6Djts3SrXR9lFzJDdt1nFDWQ6qJ2MUDBk/PkrCyfwfRFX6n NduQ== X-Received: by 10.67.22.72 with SMTP id hq8mr24089219pad.154.1429489489522; Sun, 19 Apr 2015 17:24:49 -0700 (PDT) Received: from ?IPv6:2601:9:3400:6c:71d8:32f1:987f:8a1a? ([2601:9:3400:6c:71d8:32f1:987f:8a1a]) by mx.google.com with ESMTPSA id ml6sm16239643pdb.69.2015.04.19.17.24.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 17:24:48 -0700 (PDT) Message-ID: <5534474F.2060604@gmail.com> Date: Sun, 19 Apr 2015 17:24:47 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , draft-yegin-dmm-ondemand-mobility@tools.ietf.org, Jouni References: <551F2A6D.6080100@gmail.com> In-Reply-To: <551F2A6D.6080100@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 00:24:51 -0000 Folks, The call for this I-D has ended and the document will be adopted as a WG item. Note that there were still few concerns expressed and it is WG's duty to fix and/or reach a rought concensus on those. As usual, the I-D serves as a starting point for the WG approved solution. - Jouni & Dapeng 4/3/2015, 5:03 PM, Jouni Korhonen kirjoitti: > Folks, > > This email starts a two week adoption call for the I-D > draft-yegin-dmm-ondemand-mobility-03 > to confirm its adoption as a DMM WG document and as a basis for the > technical solution. The call ends April 17th EOB PDT. > > Express your support or opposition to the mailing list. During the > IETF92 meeting we got 10 voices for the adoption and 3 against. we > expect at least the same amount of expressed opinions on the list. > > Notice that version -01 of this I-D had an IPR declared to it. See > https://datatracker.ietf.org/ipr/2309/ > > - Jouni & Dapeng From nobody Tue Apr 21 12:42:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32C11B2AE2 for ; Tue, 21 Apr 2015 12:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 pZx69ROk1qoG for ; Tue, 21 Apr 2015 12:42:37 -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 897A21B2AD8 for ; Tue, 21 Apr 2015 12:42:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3LJgUs5010310; Tue, 21 Apr 2015 21:42:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 84254205FD7; Tue, 21 Apr 2015 21:43:54 +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 760F8204D89; Tue, 21 Apr 2015 21:43:54 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.190]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3LJgSot012443; Tue, 21 Apr 2015 21:42:29 +0200 Message-ID: <5536A823.9070803@gmail.com> Date: Tue, 21 Apr 2015 21:42:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Jouni Korhonen , "dmm@ietf.org" References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:42:40 -0000 Le 31/03/2015 00:42, Templin, Fred L a 閏rit : > Hi Alex, > >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 >> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility >> Exposure and Selection WT call >> >> Le 26/03/2015 13:17, Jouni Korhonen a 閏rit : >>> Alex, >>> >>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: >>> >>> [snip] >>> >>>>> I thought by "fixed" you meant it stays the same wherever the >>>>> Host goes (something like the Home Address). >>>> >>>> Alper - I think a LL address can also be qualified as 'fixed' - >>>> it never changes. >>> >>> Does LL here mean link-local or link-layer? If it is the former >>> one, then the above assertion is not correct. >> >> Link-local. >> >> And you seem to say a link-local address is not fixed? I think >> link-local addresses _are_ fixed set in stone. They are formed >> locally without need of help from router. > > AERO provides a fixed link-local address that is formed from a > prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). > Once the AERO Client is given a PD (either IPv6 or IPv4) it can form > an AERO link-local address that stays the same wherever the Client > moves and with no need to perform Duplicate Address Detection (DAD). > It makes IPv6 ND simple and seamless. Is that prefix fe80::/10? Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> - Jouni >>> >>>> >>>> I think it's hard to disagree with that, no? >>>> >>>> Alex >>>> >>>>> >>>>> So, I guess, I should have referred to the "nomadic" address >>>>> to mean the one that is constant, wherever the Host goes. >>>>> >>>>> As such, my suggestion is that a "nomadic" address can never >>>>> be an RFC7217 address. >>>>> >>>>> In practice that would mean that if you configure an address >>>>> to be "nomadic" you must also tell the kernel to not run >>>>> RFC7217 on it. >>>>> >>>>> But ok, one might think that these two aspects ("nomadic" and >>>>> RFC7217) are orthogonal at this point in time. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> I don't know if it makes sense to request a fixed and >>>>>> random-based IP address. But if someone does it, it works. >>>>> >>>>> >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or >>>>>>>>> registered (RFC 6775). >>>>>>>>> >>>>>>>> >>>>>>>> Orthogonal. >>>>>>>> >>>>>>>> >>>>>>>>> E.g. a nomadic address could never be a link-local >>>>>>>>> address. >>>>>>>>> >>>>>>>>>> #2. Describe how IP address type information is >>>>>>>>>> conveyed from network to MN. >>>>>>>>> >>>>>>>>> If one designs a protocol to convey address type >>>>>>>>> information from the network to the end node, then >>>>>>>>> one could also add the other types mentioned above. >>>>>>>>> >>>>>>>>> SLAAC could never 'convey' the address type to the >>>>>>>>> end-node, because SLAAC is an operation happening >>>>>>>>> with as heavy weight from the Server (router) as from >>>>>>>>> the Client (Host): the Router decides the prefix but >>>>>>>>> the Client decides the Interface ID. >>>>>>>>> >>>>>>>> >>>>>>>> Still, the network can convey the type of IP address to >>>>>>>> the host. Also, one can imagine augmenting Router >>>>>>>> Solicitation to let the host convey its requested >>>>>>>> type. >>>>>>> >>>>>>> I agree. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>>>> Address Registration Option of 6lo and BTLE would >>>>>>>>> have the Host conveying this information to the >>>>>>>>> Router (and not vice-versa). >>>>>>>>> >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>>> Yours, >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility >>>>>>>>>> as the baseline for item#1 (the API). A revision of >>>>>>>>>> the draft will also include a new section to cover >>>>>>>>>> backward compatibility (Danny will provide the >>>>>>>>>> draft text). Comments on the draft are welcome. >>>>>>>>>> >>>>>>>>>> The next call will be about items #2/#3 (IP >>>>>>>>>> address configuration enhancements associated with >>>>>>>>>> the API). We intend to schedule that one in about 2 >>>>>>>>>> weeks. >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> See below for the Webex details. Remember, the >>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't >>>>>>>>>>> forget to read the documents in the reading list >>>>>>>>>>> prior to the call. >>>>>>>>>>> >>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>> the discussions: >>>>>>>>>>>> >>>>>>>>>>>> 1. >>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>> 3. >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>> 5. >>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Alper >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* >>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time >>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min >>>>>>>>>>> >>>>>>>>>>>> *Join WebEx meeting* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Meeting number:641 085 326 >>>>>>>>>>>> Meeting password:dmm1911 >>>>>>>>>>>> >>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll >>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* >>>>>>>>>>>> Call-in toll number (US/Canada) Access code: >>>>>>>>>>>> 641 085 326 Toll-free calling restrictions >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Add this meeting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to your calendar. >>>>>>>>>>>> >>>>>>>>>>>> Can't join the meeting? Contact support. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx >>>>>>>>>>>> service allows audio and other information sent >>>>>>>>>>>> during the session to be recorded, which may be >>>>>>>>>>>> discoverable in a legal matter. By joining this >>>>>>>>>>>> session, you automatically consent to such >>>>>>>>>>>> recordings. If you do not consent to being >>>>>>>>>>>> recorded, discuss your concerns with the host >>>>>>>>>>>> or do not join the session. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>>>>>> >>>>>>>>>>>> Poll is closed, and majority selected the >>>>>>>>>>>> following date for the call: >>>>>>>>>>>> >>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>>>>>> >>>>>>>>>>>> Please mark your calendars. >>>>>>>>>>>> >>>>>>>>>>>> In this call, we'll aim making progress on the >>>>>>>>>>>> I-D for item#1 (an API for source address >>>>>>>>>>>> selection). >>>>>>>>>>>> >>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>> the discussions: >>>>>>>>>>>> >>>>>>>>>>>> 1. >>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>> 3. >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>> 5. >>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Alper >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Folks, >>>>>>>>>>>>> >>>>>>>>>>>>> Please mark your availability on the >>>>>>>>>>>>> following doodle for our next DMM WG Mobility >>>>>>>>>>>>> Exposure and Selection WT call: >>>>>>>>>>>>> >>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>>>>>> >>>>>>>>>>>>> Register your availability no later than the >>>>>>>>>>>>> end of Monday (Jan 26). >>>>>>>>>>>>> >>>>>>>>>>>>> Alper >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ dmm >>>>>>>>>> mailing list dmm@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ dmm >>>>>>>>> mailing list dmm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ dmm mailing >>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ dmm mailing >>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>> >> >> >> _______________________________________________ dmm mailing list >> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > From nobody Tue Apr 21 12:45:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B182B1B2AEC for ; Tue, 21 Apr 2015 12:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 Y_9HoOvPeo0r for ; Tue, 21 Apr 2015 12:45:49 -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 7484B1B2AE2 for ; Tue, 21 Apr 2015 12:45:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3LJjkKw031558 for ; Tue, 21 Apr 2015 21:45:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0AA9C205FC9 for ; Tue, 21 Apr 2015 21:47:10 +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 F0B05204BDE for ; Tue, 21 Apr 2015 21:47:09 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.190]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3LJjigx013628 for ; Tue, 21 Apr 2015 21:45:45 +0200 Message-ID: <5536A8E8.5000705@gmail.com> Date: Tue, 21 Apr 2015 21:45:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E32EBA@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility' X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:45:50 -0000 Le 03/04/2015 20:12, Templin, Fred L a 閏rit : > Hi Danny and Alper, > > In this draft, you seem to be considering only DHCPv6 address delegation for > when the node is acting as a mobile host. I am wondering if there are similar > considerations for DHCPv6 prefix delegation for when the node is acting as > a mobile router. > > But then, I wonder whether any type of prefix delegation other than a > fixed prefix makes any sense. For example, if the mobile router received > a nomadic prefix delegation, would it need to renumber its connected > networks every time it moves and receives a new nomadic prefix? > > Should this document discuss prefix delegation considerations for mobile > routers, or only address delegation for mobile hosts? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > I second this question. I have already tried to raise this issue to authors and believe they have an oppinion on it. Alex From nobody Tue Apr 21 12:55:28 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC681A0277 for ; Tue, 21 Apr 2015 12:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 OQ0Qqg40RtMn for ; Tue, 21 Apr 2015 12:55:24 -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 5EDA91A00BD for ; Tue, 21 Apr 2015 12:55:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3LJtL8T019127; Tue, 21 Apr 2015 21:55:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E9920206003; Tue, 21 Apr 2015 21:56:44 +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 D46E6205FF2; Tue, 21 Apr 2015 21:56:44 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.190]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3LJtAOV019482; Tue, 21 Apr 2015 21:55:20 +0200 Message-ID: <5536AB1E.6060507@gmail.com> Date: Tue, 21 Apr 2015 21:55:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> In-Reply-To: <552F4165.9020300@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sofiane.imadali@gmail.com Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:55:26 -0000 Le 16/04/2015 06:58, Jouni Korhonen a 閏rit : > Folks, > > The adoption call for this I-D has ended. There is a clear concensus to > adopt the I-D as a working group item. I support its adoption. We have been working with an identifier specific to automobiles to use to realize access control. Identifying an entire set of IP nodes deployed in a vehicle is different than identifying an end-user like address@realm. We looked for such an identifier and believe the VIN (Vehicle Identification Number) be a good candidate. One would consider using one type, like type 40, to encode the VIN or parts of it, into an MN-ID. The questions to the group are the following: - is VIN considered private information? (in deployments it is private to a certain extent, but publicly avaliable to cameras or in public databases to another extent). - is the MN-ID type 40 ok for it. - is one type sufficient or should there be subtypes. Yours, Alex > > - Jouni & Dapeng > > 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> This emails starts a two week call for the I-D >> draft-perkins-dmm-4283mnids-01 >> to confirm the aadoption s a DMM WG document. The call ends April 15th >> EOB PST. >> >> Express your support or opposition to the mailing list. During the >> IETF92 meeting we got 7 voices for the adoption so at least the same >> amount supporting emails should be expected. >> >> - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From nobody Tue Apr 21 13:00:01 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD381A19E4 for ; Tue, 21 Apr 2015 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 RsqouqmgnumV for ; Tue, 21 Apr 2015 12:59:57 -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 3EDCB1A0439 for ; Tue, 21 Apr 2015 12:59:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3LJxtJb013217 for ; Tue, 21 Apr 2015 21:59:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A6AF205F8E for ; Tue, 21 Apr 2015 22:01:19 +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 35C7D204BDE for ; Tue, 21 Apr 2015 22:01:19 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.190]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3LJxrpi024172 for ; Tue, 21 Apr 2015 21:59:54 +0200 Message-ID: <5536AC39.1020005@gmail.com> Date: Tue, 21 Apr 2015 21:59:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <551F2A6D.6080100@gmail.com> <828E5EA5082945DDB07641DEA71523EE@gmail.com> <9B5B2768-A34E-4262-9BD6-AE6D1DD900D4@yegin.org> <2BE0495E-D92E-452A-9547-59DF7BCD03AD@yegin.org> In-Reply-To: <2BE0495E-D92E-452A-9547-59DF7BCD03AD@yegin.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICDlm57lpI3vvJogQ2FsbCBmb3IgYWRvcHRp?= =?utf-8?q?on=3A_draft-yegin-dmm-ondemand-mobility-03?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:00:00 -0000 Le 17/04/2015 09:50, Alper Yegin a 茅crit : > Hi Dapeng, > >>> >>>> [as an individual contributor] >>>> >>>> I support the idea of 鈥淓xposing mobility state to mobile nodes and >>>> network nodes鈥 as described in our charter. >>>> >>>> For this particular draft, after some offline discussion with the >>>> authors, I still have the following comments/suggestions: >>>> >>>> 1. Definition and distinction of "Fixed IP鈥 and 鈥淪ustained IP鈥 >>>> should be clear, more clarification text would be helpful. >>> >>> After rounds of online and offline discussions, I'm still not clear >>> where the issue is. >>> Could you please explain what exactly is this issue with the current >>> definitions? >> Some information is not obvious from the draft text. More explanatory >> text will at least help the application developer to know whether this >> is useful for them. > >> For example, as you said, HoA can either be 鈥渇ixed IP鈥 or 鈥渟ustained >> IP鈥, then when HoA become "fixed IP" and when it becomes "sustained IP"? > > When a HoA is called "fixed" vs "sustained" is already provided by the > respective definitions in the I-D: > > - Fixed IP Address > > This is what standard Mobile IP provides with a Home Address (HoA). But fixed IP addresses are also provided locally as link-local addresses not only by MIP, so that could be integrated as such. Fixed IP addresses are also provided by VPN and DHCP. So maybe we could say that a "Fixed Global IP Address is provided by MIP, VPN and DHCP". Alex > The mobile host is configures a HoA from a centrally-located Home > Network. Both IP session continuity and IP address reachability are > provided to the mobile host with the help of a router in the Home > Network (Home Agent, HA). This router acts as an anchor for the IP > address of the mobile host. > > - Sustained IP Address > > This type of IP address provides IP session continuity but not IP > address reachability. It is achieved by ensuring that the IP address > used at the beginning of the session remains usable despite the > movement of the mobile host. The IP address may change after the > termination of the IP session(s), therefore it does not exhibit > persistence. > > A sustained IP address may be configured and maintained by using > access network anchoring, corresponding network anchoring, or some > other solution. > > > If these definitions are not clear, please recommend improvement. > > If you are asking about "how the IP stack on the mobile node" configures > such IP addresses, as you know this is not in the scope of this API > document, but that'll be addressed by the protocol solutions in DMM. > > If you are asking about something else, please clarify that too. I tried > to answer your question based on my understanding of what it might be. > >> Another example/question: Is there any 鈥渇ixed IP鈥 that does not belong >> to the type of HoA? >> > > What do you mean? > > >> >> In section 3.1: >> 鈥淭he mobile host is configures a HoA from a centrally-located Home..鈥, >> do you mean 鈥淭he mobile host is configured a HoA from a >> centrally-located Home..鈥? >> > > Yes, it's a typo. (is configured with, or configures). > > >> In section 3.1: >> 鈥淎pplications running as servers at a published IP address require >> aFixed IP Address.鈥.. >> Is there any real-life example for this requirement? > > This is by definition, right? > If you are running a server, you need need to publish its IP address (in > DNS, for example). > And you want that address to be "fixed" (i.e., not changing). And that's > what we call "Fixed IP address" in this I-D. > > Please see the below links for real-life examples of how operators are > already marketing such things: > > https://www.wireless.att.com/businesscenter/popups/general/custom-ip-addressing.jsp > > http://www.verizonwireless.com/businessportals/support/faqs/DataServices/faq_static_ip.html > > > > >> Most server only need static public IP address instead of 鈥渇ixed IP >> address鈥 (providing mobility) ? >> > > > Please see the examples on the links above. > > >> In section 3.1: >> 鈥淓nterprise applications that connect to an enterprise network via >> virtual LAN require a Fixed IP Address.鈥 can you explain the reason? >> > > This is about Enterprise APN. > Or, for example, what AT&T refers to as "customer-provided IP > addresses". See the above link, and the below text: > > *Customer-provided IP addresses:* If you decide to provide your own IP > address block for your mobile data configuration, you will essentially > extend your company's wide area network to include the AT&T cellular > network. This allows for simpler firewall configuration, as well as > mobile device identification. > > >> >>> So that we can understand the residual unclarity in your mind, and we >>> let other people also weigh in on the matter. >>> >>>> 2. Since we are trying to define API, opinion from application >>>> developers or OS vendors would be helpful. We can invite some of >>>> those experts to join the discussion. >>> >>> Sure. >>> >>>> 3. Agree with Jouni鈥檚 opinion regarding the IPR, the group need to >>>> evaluate it. >>> >>> I really don't understand what exact "IPR evaluation" process you are >>> referring to. >>> I'm not familiar with such a thing in IETF. >> [quote from Jouni鈥檚 mail] >> 鈥渨e need to evaluate what parts are covered by the declared IPR and >> whether the WG agrees to keep those in the solution鈥.. >> > > Yeah, I know. I also told Jouni that I don't know what exact process > he's referring to. > Anyways, if any of the chairs are referring to some IETF process, I'd > like to know what that is. > > I'm not familiar with it. If there's such a thing, we need to make sure > it's an official IETF process, and it'll be applied to all docs across > the DMM, and already being applied across the IETF. > > Regards, > > Alper > > > > > > >> >> -- >> Dapeng >>> >>> Alper >>> >>> >>>> >>>> -- >>>> Dapeng Liu >>>> >>>> 鍦 2015骞4鏈4鏃 鏄熸湡鍏紝涓婂崍8:03锛孞ouni Korhonen 鍐欓亾锛 >>>> >>>>> Folks, >>>>> >>>>> This email starts a two week adoption call for the I-D >>>>> draft-yegin-dmm-ondemand-mobility-03 >>>>> to confirm its adoption as a DMM WG document and as a basis for the >>>>> technical solution. The call ends April 17th EOB PDT. >>>>> >>>>> Express your support or opposition to the mailing list. During the >>>>> IETF92 meeting we got 10 voices for the adoption and 3 against. we >>>>> expect at least the same amount of expressed opinions on the list. >>>>> >>>>> Notice that version -01 of this I-D had an IPR declared to it. See >>>>> https://datatracker.ietf.org/ipr/2309/ >>>>> >>>>> - Jouni & Dapeng >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Tue Apr 21 13:14:58 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45D01A875D for ; Tue, 21 Apr 2015 13:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 N8yxuL6Bs96J for ; Tue, 21 Apr 2015 13:14:53 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 EC5F61A6F38 for ; Tue, 21 Apr 2015 13:14:52 -0700 (PDT) Received: by wiax7 with SMTP id x7so115341526wia.0 for ; Tue, 21 Apr 2015 13:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B4amDO8oUnh6mbU0L2SM0Tem+BCwGmnnmVNLEYBkW0c=; b=MT9Fr4ZpbmzVhmu2VNzrYSqnLGz3jtG7aHB4T/lqNK4+1TaFNc7y90OxpwHUuc70wl ELhBnUr9Fl2YCc2Ij0fSoM+x0W6jHudP5fVf6LBgW/v9A24yY2znuPj879cAkUiea/sW 24PWR+htTo5aFQAd8Kxa+sBxAadlojo/i94VRocPRlbMWOm+4r37eZeuZuNjF7wKIwDQ sV+SpS2zHNX8FfF+BdjvR5h9lPXW0cwPGcoU/W9O/Nz91dW1kA3uYlA2Ihy9OGV7SKq4 Nt1gTF0G70nGUx3qJ9Y342hDSC3gslJYloof7jV8ytiAnj7FYCuuLt0NWFXneZCLXTSr 9zUA== X-Received: by 10.180.99.42 with SMTP id en10mr9060953wib.83.1429647291577; Tue, 21 Apr 2015 13:14:51 -0700 (PDT) Received: from [192.168.182.166] (AGrenoble-257-1-173-34.w90-42.abo.wanadoo.fr. [90.42.20.34]) by mx.google.com with ESMTPSA id hy7sm4116042wjb.1.2015.04.21.13.14.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 13:14:50 -0700 (PDT) Message-ID: <5536AFB6.2040305@gmail.com> Date: Tue, 21 Apr 2015 22:14:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <201504131333451125705@cnnic.cn> In-Reply-To: <201504131333451125705@cnnic.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] New Version Notification for draft-yan-dmm-hnprenum-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:14:55 -0000 Le 13/04/2015 07:33, Z.W. Yan a 閏rit : > Hi, all, > During the Dallas meeting, we introduced the issue of HNP-renumbering in PMIPv6 and heard some positive voices. > In order to present it more clearly and collect more comments, > we updated the draft with the 01 version. > https://tools.ietf.org/html/draft-yan-dmm-hnprenum-01 > Any comments from you are all welcome. > Thanks. > Zhiwei Yan > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > Hi, The idea of renumbering a PMIPv6 network (update each prefix for each MN-ID) makes sense. The use-cases described in the draft are necessary. In other WGs like Homenet and Anima, there is ongoing discussion about new Renumbering procedures in Enterprise and in Home, whereas this would be in a Mobile network like 3GPP. The draft presents diagrams of message exchanges as well as brief descriptions of message formats; this is to be implemented with DHCPv6 and RA, among others. I would like to ask you this: when a Host is renumbered, will the new address become Fixed, Sustained or Nomadic? I would also like to ask this: is this breaking ondemand mobility, or supporting ondemand mobility? There is a nit "Trigged". Alex From nobody Tue Apr 21 13:55:47 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8AD1B2B2B for ; Tue, 21 Apr 2015 13:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DLOF1REt3scd for ; Tue, 21 Apr 2015 13:55:44 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE71A8FD2 for ; Tue, 21 Apr 2015 13:55:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WMT650vHG7sTcCrfjClKL1OH+nK8oVB4hTC9+0OyqVJLSYnYwI36Tm9qxwAIYhmr; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.252.133]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1YkfCp-00033g-MM; Tue, 21 Apr 2015 16:55:43 -0400 Message-ID: <5536B94B.2090800@earthlink.net> Date: Tue, 21 Apr 2015 13:55:39 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> In-Reply-To: <5536AB1E.6060507@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac770993d24ae474ae7d1454dcb28fbb3e8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: sofiane.imadali@gmail.com Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:55:46 -0000 Hello folks, The ...-00 document draft-dmm-4283mnids-00.txt has been submitted. I'll make a new draft with VIN as a type of MNID as soon as Alex's questions have proposed answers. Regards, Charlie P. On 4/21/2015 12:55 PM, Alexandru Petrescu wrote: > Le 16/04/2015 06:58, Jouni Korhonen a 閏rit : >> Folks, >> >> The adoption call for this I-D has ended. There is a clear concensus to >> adopt the I-D as a working group item. > > I support its adoption. > > We have been working with an identifier specific to automobiles to use > to realize access control. Identifying an entire set of IP nodes > deployed in a vehicle is different than identifying an end-user like > address@realm. > > We looked for such an identifier and believe the VIN (Vehicle > Identification Number) be a good candidate. > > One would consider using one type, like type 40, to encode the VIN or > parts of it, into an MN-ID. > > The questions to the group are the following: > - is VIN considered private information? (in deployments it is private > to a certain extent, but publicly avaliable to cameras or in public > databases to another extent). > - is the MN-ID type 40 ok for it. > - is one type sufficient or should there be subtypes. > > Yours, > > Alex > >> >> - Jouni & Dapeng >> >> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>> Folks, >>> >>> This emails starts a two week call for the I-D >>> draft-perkins-dmm-4283mnids-01 >>> to confirm the aadoption s a DMM WG document. The call ends April 15th >>> EOB PST. >>> >>> Express your support or opposition to the mailing list. During the >>> IETF92 meeting we got 7 voices for the adoption so at least the same >>> amount supporting emails should be expected. >>> >>> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Apr 22 09:07:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF501B36E5 for ; Wed, 22 Apr 2015 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 zK9WsNPBlLfd for ; Wed, 22 Apr 2015 09:07:13 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 4E07E1ACE8E for ; Wed, 22 Apr 2015 09:06:11 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so183852452lbb.3 for ; Wed, 22 Apr 2015 09:06:09 -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-type:content-transfer-encoding; bh=up1YtU5YlT8oEme0eLMkO9npRGfPnmCChf+G3EkJOwk=; b=QdT73fN1WvmK5K2H+e8EIcWjaOf6m89o7ol3/kkpbYDrS7GE/g46zJZCd5bDWhtNVF Ht1bH/tZC793j6BmCdW7n4QIYzY7dIAwmfK2BscNoJfs502YkRNolF72m4+Ov3qvr/pt 4k7IlZHiaFV4E1/V1foCWCewQ0kc229YsYkhYgKwA/VOJBornBI7Y0B/TRXLimCUVM+V TaCGWD+np/7SI0Z0AD6PjUd/+s4slaW7fxiWZ3Ji011Lyc7OX8W1NHj3/QPYE+sgG7R6 Rz2p06Nn3BbU11KtErCN/HJWZlL3PDU2zpk60KCqNfbAOEkiHefesf91QjBKZgVlRYIi 58rQ== MIME-Version: 1.0 X-Received: by 10.112.93.72 with SMTP id cs8mr25412997lbb.15.1429718769746; Wed, 22 Apr 2015 09:06:09 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Wed, 22 Apr 2015 09:06:09 -0700 (PDT) In-Reply-To: <5536AB1E.6060507@gmail.com> References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> Date: Wed, 22 Apr 2015 11:06:09 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 22 Apr 2015 16:07:14 -0000 Hi Alex, On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu wrote: > Le 16/04/2015 06:58, Jouni Korhonen a =C3=A9crit : >> >> Folks, >> >> The adoption call for this I-D has ended. There is a clear concensus to >> adopt the I-D as a working group item. > > > I support its adoption. > > We have been working with an identifier specific to automobiles to use to > realize access control. Identifying an entire set of IP nodes deployed i= n a > vehicle is different than identifying an end-user like address@realm. > > We looked for such an identifier and believe the VIN (Vehicle Identificat= ion > Number) be a good candidate. > > One would consider using one type, like type 40, to encode the VIN or par= ts > of it, into an MN-ID. > > The questions to the group are the following: > - is VIN considered private information? (in deployments it is private > to a certain extent, but publicly avaliable to cameras or in public > databases to another extent). > - is the MN-ID type 40 ok for it. > - is one type sufficient or should there be subtypes. What is your model here in providing Internet access to the car? As you may know, operators in US are deploying systems that connect the car to their LTE network upstream and downstream is the passengers in the car that access over Wi-Fi. With LTE, you get mobility support which is based on fixed anchoring. I cc'ed to Raj who works on these types of technologies. The ID there is the IMSI. I don't think vin is used. Regards, Behcet > > Yours, > > Alex > > >> >> - Jouni & Dapeng >> >> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>> >>> Folks, >>> >>> This emails starts a two week call for the I-D >>> draft-perkins-dmm-4283mnids-01 >>> to confirm the aadoption s a DMM WG document. The call ends April 15th >>> EOB PST. >>> >>> Express your support or opposition to the mailing list. During the >>> IETF92 meeting we got 7 voices for the adoption so at least the same >>> amount supporting emails should be expected. >>> >>> - Jouni & Dapeng >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Apr 22 09:46:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58A1B37B0 for ; Wed, 22 Apr 2015 09:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 mnrc_ztJoDcv for ; Wed, 22 Apr 2015 09:46:13 -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 C33A21B36E1 for ; Wed, 22 Apr 2015 09:46:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3MGk22u008802; Wed, 22 Apr 2015 18:46:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C89A0202A08; Wed, 22 Apr 2015 18:47:27 +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 B89962029BD; Wed, 22 Apr 2015 18:47:27 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3MGk1cK015297; Wed, 22 Apr 2015 18:46:02 +0200 Message-ID: <5537D047.5040502@gmail.com> Date: Wed, 22 Apr 2015 18:45:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:46:15 -0000 Le 22/04/2015 18:06, Behcet Sarikaya a 茅crit : > Hi Alex, > > On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu > wrote: >> Le 16/04/2015 06:58, Jouni Korhonen a 茅crit : >>> >>> Folks, >>> >>> The adoption call for this I-D has ended. There is a clear concensus to >>> adopt the I-D as a working group item. >> >> >> I support its adoption. >> >> We have been working with an identifier specific to automobiles to use to >> realize access control. Identifying an entire set of IP nodes deployed in a >> vehicle is different than identifying an end-user like address@realm. >> >> We looked for such an identifier and believe the VIN (Vehicle Identification >> Number) be a good candidate. >> >> One would consider using one type, like type 40, to encode the VIN or parts >> of it, into an MN-ID. >> >> The questions to the group are the following: >> - is VIN considered private information? (in deployments it is private >> to a certain extent, but publicly avaliable to cameras or in public >> databases to another extent). >> - is the MN-ID type 40 ok for it. >> - is one type sufficient or should there be subtypes. > > What is your model here in providing Internet access to the car? > As you may know, operators in US are deploying systems that connect > the car to their LTE network upstream and downstream is the passengers > in the car that access over Wi-Fi. > With LTE, you get mobility support which is based on fixed anchoring. > I cc'ed to Raj who works on these types of technologies. > The ID there is the IMSI. I don't think vin is used. The model of Internet access to the cars for cars currently on market in Europe is the same - the LTE technology is used, using the IMSI as an identifier. However, that does not use MN-ID, is only IPv4, is not WiFi and does not resist to cellular generation upgrades to 5G and beyond. Newer models will feature IPv6 in addition to IPv4, WiFi handover from LTE to house's hotspot, continuous sessions, and over-the-air software update for cheap upgradeability to future generation 5G and beyond. In this context it is hard to imagine IMSI will be there for a long time in a given car, and a more permanent identifier is needed. To Raj - is LTE considering other kinds of identifiers for access control (other than IMSI) for vehicular environments, like V2X? Alex > > Regards, > > Behcet >> >> Yours, >> >> Alex >> >> >>> >>> - Jouni & Dapeng >>> >>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>> >>>> Folks, >>>> >>>> This emails starts a two week call for the I-D >>>> draft-perkins-dmm-4283mnids-01 >>>> to confirm the aadoption s a DMM WG document. The call ends April 15th >>>> EOB PST. >>>> >>>> Express your support or opposition to the mailing list. During the >>>> IETF92 meeting we got 7 voices for the adoption so at least the same >>>> amount supporting emails should be expected. >>>> >>>> - Jouni & Dapeng >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > From nobody Wed Apr 22 09:51:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3991A0033 for ; Wed, 22 Apr 2015 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZpmwIfM00xJ5 for ; Wed, 22 Apr 2015 09:51:49 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830A51B3804 for ; Wed, 22 Apr 2015 09:51:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3MGphLC031782; Wed, 22 Apr 2015 09:51:43 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3MGpaNV031735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 22 Apr 2015 09:51:36 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.126]) with mapi id 14.03.0235.001; Wed, 22 Apr 2015 09:51:35 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgA== Date: Wed, 22 Apr 2015 16:51:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> In-Reply-To: <5536A823.9070803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:51:51 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 21, 2015 12:42 PM > To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 > Le 31/03/2015 00:42, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] > >> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 > >> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility > >> Exposure and Selection WT call > >> > >> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : > >>> Alex, > >>> > >>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > >>> > >>> [snip] > >>> > >>>>> I thought by "fixed" you meant it stays the same wherever the > >>>>> Host goes (something like the Home Address). > >>>> > >>>> Alper - I think a LL address can also be qualified as 'fixed' - > >>>> it never changes. > >>> > >>> Does LL here mean link-local or link-layer? If it is the former > >>> one, then the above assertion is not correct. > >> > >> Link-local. > >> > >> And you seem to say a link-local address is not fixed? I think > >> link-local addresses _are_ fixed set in stone. They are formed > >> locally without need of help from router. > > > > AERO provides a fixed link-local address that is formed from a > > prefix received by DHCPv6 Prefix Delegation (PD). >=20 > Fred - but why should this ll prefix be provided by DHCP? Is it of > variable value? Or is the link-local constant all the time? (in which > case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). Once the prefix delegation and AERO address configuration are done, they stay fixes as long as the Client remains associated with the same AERO link. > > Once the AERO Client is given a PD (either IPv6 or IPv4) it can form > > an AERO link-local address that stays the same wherever the Client > > moves and with no need to perform Duplicate Address Detection (DAD). > > It makes IPv6 ND simple and seamless. >=20 > Is that prefix fe80::/10? No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which longer global IPv6 prefixes are delegated to each Client. The Client then gets to keep and continually use its prefix delegation as long as it stays associated with the same AERO link. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> Alex > >> > >>> > >>> - Jouni > >>> > >>>> > >>>> I think it's hard to disagree with that, no? > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> So, I guess, I should have referred to the "nomadic" address > >>>>> to mean the one that is constant, wherever the Host goes. > >>>>> > >>>>> As such, my suggestion is that a "nomadic" address can never > >>>>> be an RFC7217 address. > >>>>> > >>>>> In practice that would mean that if you configure an address > >>>>> to be "nomadic" you must also tell the kernel to not run > >>>>> RFC7217 on it. > >>>>> > >>>>> But ok, one might think that these two aspects ("nomadic" and > >>>>> RFC7217) are orthogonal at this point in time. > >>>>> > >>>>> Alex > >>>>> > >>>>>> > >>>>>> I don't know if it makes sense to request a fixed and > >>>>>> random-based IP address. But if someone does it, it works. > >>>>> > >>>>> > >>>>>> > >>>>>> Alper > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or > >>>>>>>>> registered (RFC 6775). > >>>>>>>>> > >>>>>>>> > >>>>>>>> Orthogonal. > >>>>>>>> > >>>>>>>> > >>>>>>>>> E.g. a nomadic address could never be a link-local > >>>>>>>>> address. > >>>>>>>>> > >>>>>>>>>> #2. Describe how IP address type information is > >>>>>>>>>> conveyed from network to MN. > >>>>>>>>> > >>>>>>>>> If one designs a protocol to convey address type > >>>>>>>>> information from the network to the end node, then > >>>>>>>>> one could also add the other types mentioned above. > >>>>>>>>> > >>>>>>>>> SLAAC could never 'convey' the address type to the > >>>>>>>>> end-node, because SLAAC is an operation happening > >>>>>>>>> with as heavy weight from the Server (router) as from > >>>>>>>>> the Client (Host): the Router decides the prefix but > >>>>>>>>> the Client decides the Interface ID. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Still, the network can convey the type of IP address to > >>>>>>>> the host. Also, one can imagine augmenting Router > >>>>>>>> Solicitation to let the host convey its requested > >>>>>>>> type. > >>>>>>> > >>>>>>> I agree. > >>>>>>> > >>>>>>> Alex > >>>>>>> > >>>>>>> > >>>>>>>>> Address Registration Option of 6lo and BTLE would > >>>>>>>>> have the Host conveying this information to the > >>>>>>>>> Router (and not vice-versa). > >>>>>>>>> > >>>>>>>> > >>>>>>>> OK. > >>>>>>>> > >>>>>>>> Alper > >>>>>>>> > >>>>>>>> > >>>>>>>>> Yours, > >>>>>>>>> > >>>>>>>>> Alex > >>>>>>>>> > >>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility > >>>>>>>>>> as the baseline for item#1 (the API). A revision of > >>>>>>>>>> the draft will also include a new section to cover > >>>>>>>>>> backward compatibility (Danny will provide the > >>>>>>>>>> draft text). Comments on the draft are welcome. > >>>>>>>>>> > >>>>>>>>>> The next call will be about items #2/#3 (IP > >>>>>>>>>> address configuration enhancements associated with > >>>>>>>>>> the API). We intend to schedule that one in about 2 > >>>>>>>>>> weeks. > >>>>>>>>>> > >>>>>>>>>> Alper > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: > >>>>>>>>>> > >>>>>>>>>>> Folks, > >>>>>>>>>>> > >>>>>>>>>>> See below for the Webex details. Remember, the > >>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't > >>>>>>>>>>> forget to read the documents in the reading list > >>>>>>>>>>> prior to the call. > >>>>>>>>>>> > >>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>> the discussions: > >>>>>>>>>>>> > >>>>>>>>>>>> 1. > >>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pd= f > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>> > 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>> 3. > >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mo= bility/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>> > 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>> 5. > >>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > Alper > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* > >>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time > >>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min > >>>>>>>>>>> > >>>>>>>>>>>> *Join WebEx meeting* > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>> > Meeting number:641 085 326 > >>>>>>>>>>>> Meeting password:dmm1911 > >>>>>>>>>>>> > >>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll > >>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* > >>>>>>>>>>>> Call-in toll number (US/Canada) Access code: > >>>>>>>>>>>> 641 085 326 Toll-free calling restrictions > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Add this meeting > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > to your calendar. > >>>>>>>>>>>> > >>>>>>>>>>>> Can't join the meeting? Contact support. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx > >>>>>>>>>>>> service allows audio and other information sent > >>>>>>>>>>>> during the session to be recorded, which may be > >>>>>>>>>>>> discoverable in a legal matter. By joining this > >>>>>>>>>>>> session, you automatically consent to such > >>>>>>>>>>>> recordings. If you do not consent to being > >>>>>>>>>>>> recorded, discuss your concerns with the host > >>>>>>>>>>>> or do not join the session. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Poll is closed, and majority selected the > >>>>>>>>>>>> following date for the call: > >>>>>>>>>>>> > >>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. > >>>>>>>>>>>> > >>>>>>>>>>>> Please mark your calendars. > >>>>>>>>>>>> > >>>>>>>>>>>> In this call, we'll aim making progress on the > >>>>>>>>>>>> I-D for item#1 (an API for source address > >>>>>>>>>>>> selection). > >>>>>>>>>>>> > >>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>> the discussions: > >>>>>>>>>>>> > >>>>>>>>>>>> 1. > >>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pd= f > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>> > 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>> 3. > >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mo= bility/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>> > 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>> 5. > >>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Alper > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Folks, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please mark your availability on the > >>>>>>>>>>>>> following doodle for our next DMM WG Mobility > >>>>>>>>>>>>> Exposure and Selection WT call: > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur > >>>>>>>>>>>>> > >>>>>>>>>>>>> Register your availability no later than the > >>>>>>>>>>>>> end of Monday (Jan 26). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alper > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ dmm > >>>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ dmm > >>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ dmm mailing > >>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ dmm mailing > >>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > >> > >> _______________________________________________ dmm mailing list > >> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > > > >=20 From nobody Wed Apr 22 10:00:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1A1B3859 for ; Wed, 22 Apr 2015 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 W_9-lKGhC9SI for ; Wed, 22 Apr 2015 10:00:19 -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 3D5291B385B for ; Wed, 22 Apr 2015 09:59:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3MGxHIs011627; Wed, 22 Apr 2015 18:59:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5BBF52029F1; Wed, 22 Apr 2015 19:00:42 +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 4DADB202988; Wed, 22 Apr 2015 19:00:42 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3MGxGxO030781; Wed, 22 Apr 2015 18:59:17 +0200 Message-ID: <5537D364.1010906@gmail.com> Date: Wed, 22 Apr 2015 18:59:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Jouni Korhonen , "dmm@ietf.org" References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:00:22 -0000 Le 22/04/2015 18:51, Templin, Fred L a 閏rit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Tuesday, April 21, 2015 12:42 PM >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org >> Subject: Re: [DMM] Mobility Exposure and Selection WT call >> >> Le 31/03/2015 00:42, Templin, Fred L a 閏rit : >>> Hi Alex, >>> >>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 >>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility >>>> Exposure and Selection WT call >>>> >>>> Le 26/03/2015 13:17, Jouni Korhonen a 閏rit : >>>>> Alex, >>>>> >>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: >>>>> >>>>> [snip] >>>>> >>>>>>> I thought by "fixed" you meant it stays the same wherever the >>>>>>> Host goes (something like the Home Address). >>>>>> >>>>>> Alper - I think a LL address can also be qualified as 'fixed' - >>>>>> it never changes. >>>>> >>>>> Does LL here mean link-local or link-layer? If it is the former >>>>> one, then the above assertion is not correct. >>>> >>>> Link-local. >>>> >>>> And you seem to say a link-local address is not fixed? I think >>>> link-local addresses _are_ fixed set in stone. They are formed >>>> locally without need of help from router. >>> >>> AERO provides a fixed link-local address that is formed from a >>> prefix received by DHCPv6 Prefix Delegation (PD). >> >> Fred - but why should this ll prefix be provided by DHCP? Is it of >> variable value? Or is the link-local constant all the time? (in which >> case it could be hardcoded everywhere). > > DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO > Client (e.g., 2001:db8:1:2::/64). The Client then constructs an > AERO link-local address from the prefix as fe80::2001:db8:1:2 > (i.e., it embeds the 64-bit prefix from the prefix delegation in > the 64-bit interface identifier of an IPv6 link-local address). Fred, that looks weird. Never saw a prefix to be used as an Interface Identifier. I guess this breaks the DHCP prefix delegation specification. Why does not the DHCPv6 server assign a link-local address altogether (rather than assigning a prefix, to be used as an IID). Alex > Once the prefix delegation and AERO address configuration > are done, they stay fixes as long as the Client remains > associated with the same AERO link. > >>> Once the AERO Client is given a PD (either IPv6 or IPv4) it can form >>> an AERO link-local address that stays the same wherever the Client >>> moves and with no need to perform Duplicate Address Detection (DAD). >>> It makes IPv6 ND simple and seamless. >> >> Is that prefix fe80::/10? > > No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link > has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which > longer global IPv6 prefixes are delegated to each Client. The Client then > gets to keep and continually use its prefix delegation as long as it stays > associated with the same AERO link. > > Thanks - Fred > fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> Alex >>>> >>>>> >>>>> - Jouni >>>>> >>>>>> >>>>>> I think it's hard to disagree with that, no? >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> So, I guess, I should have referred to the "nomadic" address >>>>>>> to mean the one that is constant, wherever the Host goes. >>>>>>> >>>>>>> As such, my suggestion is that a "nomadic" address can never >>>>>>> be an RFC7217 address. >>>>>>> >>>>>>> In practice that would mean that if you configure an address >>>>>>> to be "nomadic" you must also tell the kernel to not run >>>>>>> RFC7217 on it. >>>>>>> >>>>>>> But ok, one might think that these two aspects ("nomadic" and >>>>>>> RFC7217) are orthogonal at this point in time. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> I don't know if it makes sense to request a fixed and >>>>>>>> random-based IP address. But if someone does it, it works. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or >>>>>>>>>>> registered (RFC 6775). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Orthogonal. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> E.g. a nomadic address could never be a link-local >>>>>>>>>>> address. >>>>>>>>>>> >>>>>>>>>>>> #2. Describe how IP address type information is >>>>>>>>>>>> conveyed from network to MN. >>>>>>>>>>> >>>>>>>>>>> If one designs a protocol to convey address type >>>>>>>>>>> information from the network to the end node, then >>>>>>>>>>> one could also add the other types mentioned above. >>>>>>>>>>> >>>>>>>>>>> SLAAC could never 'convey' the address type to the >>>>>>>>>>> end-node, because SLAAC is an operation happening >>>>>>>>>>> with as heavy weight from the Server (router) as from >>>>>>>>>>> the Client (Host): the Router decides the prefix but >>>>>>>>>>> the Client decides the Interface ID. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Still, the network can convey the type of IP address to >>>>>>>>>> the host. Also, one can imagine augmenting Router >>>>>>>>>> Solicitation to let the host convey its requested >>>>>>>>>> type. >>>>>>>>> >>>>>>>>> I agree. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Address Registration Option of 6lo and BTLE would >>>>>>>>>>> have the Host conveying this information to the >>>>>>>>>>> Router (and not vice-versa). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK. >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility >>>>>>>>>>>> as the baseline for item#1 (the API). A revision of >>>>>>>>>>>> the draft will also include a new section to cover >>>>>>>>>>>> backward compatibility (Danny will provide the >>>>>>>>>>>> draft text). Comments on the draft are welcome. >>>>>>>>>>>> >>>>>>>>>>>> The next call will be about items #2/#3 (IP >>>>>>>>>>>> address configuration enhancements associated with >>>>>>>>>>>> the API). We intend to schedule that one in about 2 >>>>>>>>>>>> weeks. >>>>>>>>>>>> >>>>>>>>>>>> Alper >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Folks, >>>>>>>>>>>>> >>>>>>>>>>>>> See below for the Webex details. Remember, the >>>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't >>>>>>>>>>>>> forget to read the documents in the reading list >>>>>>>>>>>>> prior to the call. >>>>>>>>>>>>> >>>>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>>>> the discussions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. >>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>>>> 3. >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>>>> 5. >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >> Alper >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* >>>>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time >>>>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min >>>>>>>>>>>>> >>>>>>>>>>>>>> *Join WebEx meeting* >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >> Meeting number:641 085 326 >>>>>>>>>>>>>> Meeting password:dmm1911 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll >>>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* >>>>>>>>>>>>>> Call-in toll number (US/Canada) Access code: >>>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> Add this meeting >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> to your calendar. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can't join the meeting? Contact support. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx >>>>>>>>>>>>>> service allows audio and other information sent >>>>>>>>>>>>>> during the session to be recorded, which may be >>>>>>>>>>>>>> discoverable in a legal matter. By joining this >>>>>>>>>>>>>> session, you automatically consent to such >>>>>>>>>>>>>> recordings. If you do not consent to being >>>>>>>>>>>>>> recorded, discuss your concerns with the host >>>>>>>>>>>>>> or do not join the session. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Poll is closed, and majority selected the >>>>>>>>>>>>>> following date for the call: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please mark your calendars. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this call, we'll aim making progress on the >>>>>>>>>>>>>> I-D for item#1 (an API for source address >>>>>>>>>>>>>> selection). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>>>> the discussions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. >>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>>>> 3. >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>>>> 5. >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> Alper >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Folks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please mark your availability on the >>>>>>>>>>>>>>> following doodle for our next DMM WG Mobility >>>>>>>>>>>>>>> Exposure and Selection WT call: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Register your availability no later than the >>>>>>>>>>>>>>> end of Monday (Jan 26). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Alper >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ dmm >>>>>>>>>>>> mailing list dmm@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ dmm >>>>>>>>>>> mailing list dmm@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm mailing >>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm mailing >>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>>> >>>> _______________________________________________ dmm mailing list >>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> > > > From nobody Wed Apr 22 10:22:38 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7891B38B4 for ; Wed, 22 Apr 2015 10:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O0h7wGmt1pfB for ; Wed, 22 Apr 2015 10:22:33 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65EA1A8857 for ; Wed, 22 Apr 2015 10:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3MHMXGV026288; Wed, 22 Apr 2015 10:22:33 -0700 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3MHMO3S026223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 22 Apr 2015 10:22:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.26]) with mapi id 14.03.0235.001; Wed, 22 Apr 2015 10:22:24 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgIAAeiAA//+OQbA= Date: Wed, 22 Apr 2015 17:22:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4FB26@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <5537D364.1010906@gmail.com> In-Reply-To: <5537D364.1010906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:22:37 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, April 22, 2015 9:59 AM > To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 > Le 22/04/2015 18:51, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Tuesday, April 21, 2015 12:42 PM > >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > >> Subject: Re: [DMM] Mobility Exposure and Selection WT call > >> > >> Le 31/03/2015 00:42, Templin, Fred L a =E9crit : > >>> Hi Alex, > >>> > >>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] > >>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 > >>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility > >>>> Exposure and Selection WT call > >>>> > >>>> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : > >>>>> Alex, > >>>>> > >>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > >>>>> > >>>>> [snip] > >>>>> > >>>>>>> I thought by "fixed" you meant it stays the same wherever the > >>>>>>> Host goes (something like the Home Address). > >>>>>> > >>>>>> Alper - I think a LL address can also be qualified as 'fixed' - > >>>>>> it never changes. > >>>>> > >>>>> Does LL here mean link-local or link-layer? If it is the former > >>>>> one, then the above assertion is not correct. > >>>> > >>>> Link-local. > >>>> > >>>> And you seem to say a link-local address is not fixed? I think > >>>> link-local addresses _are_ fixed set in stone. They are formed > >>>> locally without need of help from router. > >>> > >>> AERO provides a fixed link-local address that is formed from a > >>> prefix received by DHCPv6 Prefix Delegation (PD). > >> > >> Fred - but why should this ll prefix be provided by DHCP? Is it of > >> variable value? Or is the link-local constant all the time? (in which > >> case it could be hardcoded everywhere). > > > > DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO > > Client (e.g., 2001:db8:1:2::/64). The Client then constructs an > > AERO link-local address from the prefix as fe80::2001:db8:1:2 > > (i.e., it embeds the 64-bit prefix from the prefix delegation in > > the 64-bit interface identifier of an IPv6 link-local address). >=20 > Fred, that looks weird. Never saw a prefix to be used as an Interface > Identifier. It is specified in the AERO document and also cited in RFC7421. There are lots of weird "address within address" encapsulations in common use within the IPv6 interface identifier (e.g., ISATAP address, etc.) and this I think is in some ways less weird than some of the others. > I guess this breaks the DHCP prefix delegation specification. Not at all; I have running code that uses unmodified public domain DHCPv6 clients and servers. On the server side, I was using ISC DHCP but have recently moved over to a great new server package called Kea (also from ISC). > Why does not the DHCPv6 server assign a link-local address altogether > (rather than assigning a prefix, to be used as an IID). Because the prefix length may be different than /64; hence, the Client needs to receive the prefix in a DHCPv6 IA_PD option. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > Once the prefix delegation and AERO address configuration > > are done, they stay fixes as long as the Client remains > > associated with the same AERO link. > > > >>> Once the AERO Client is given a PD (either IPv6 or IPv4) it can form > >>> an AERO link-local address that stays the same wherever the Client > >>> moves and with no need to perform Duplicate Address Detection (DAD). > >>> It makes IPv6 ND simple and seamless. > >> > >> Is that prefix fe80::/10? > > > > No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO l= ink > > has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which > > longer global IPv6 prefixes are delegated to each Client. The Client th= en > > gets to keep and continually use its prefix delegation as long as it st= ays > > associated with the same AERO link. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Alex > >> > >>> > >>> Thanks - Fred fred.l.templin@boeing.com > >>> > >>>> Alex > >>>> > >>>>> > >>>>> - Jouni > >>>>> > >>>>>> > >>>>>> I think it's hard to disagree with that, no? > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> So, I guess, I should have referred to the "nomadic" address > >>>>>>> to mean the one that is constant, wherever the Host goes. > >>>>>>> > >>>>>>> As such, my suggestion is that a "nomadic" address can never > >>>>>>> be an RFC7217 address. > >>>>>>> > >>>>>>> In practice that would mean that if you configure an address > >>>>>>> to be "nomadic" you must also tell the kernel to not run > >>>>>>> RFC7217 on it. > >>>>>>> > >>>>>>> But ok, one might think that these two aspects ("nomadic" and > >>>>>>> RFC7217) are orthogonal at this point in time. > >>>>>>> > >>>>>>> Alex > >>>>>>> > >>>>>>>> > >>>>>>>> I don't know if it makes sense to request a fixed and > >>>>>>>> random-based IP address. But if someone does it, it works. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Alper > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or > >>>>>>>>>>> registered (RFC 6775). > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Orthogonal. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> E.g. a nomadic address could never be a link-local > >>>>>>>>>>> address. > >>>>>>>>>>> > >>>>>>>>>>>> #2. Describe how IP address type information is > >>>>>>>>>>>> conveyed from network to MN. > >>>>>>>>>>> > >>>>>>>>>>> If one designs a protocol to convey address type > >>>>>>>>>>> information from the network to the end node, then > >>>>>>>>>>> one could also add the other types mentioned above. > >>>>>>>>>>> > >>>>>>>>>>> SLAAC could never 'convey' the address type to the > >>>>>>>>>>> end-node, because SLAAC is an operation happening > >>>>>>>>>>> with as heavy weight from the Server (router) as from > >>>>>>>>>>> the Client (Host): the Router decides the prefix but > >>>>>>>>>>> the Client decides the Interface ID. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Still, the network can convey the type of IP address to > >>>>>>>>>> the host. Also, one can imagine augmenting Router > >>>>>>>>>> Solicitation to let the host convey its requested > >>>>>>>>>> type. > >>>>>>>>> > >>>>>>>>> I agree. > >>>>>>>>> > >>>>>>>>> Alex > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Address Registration Option of 6lo and BTLE would > >>>>>>>>>>> have the Host conveying this information to the > >>>>>>>>>>> Router (and not vice-versa). > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> OK. > >>>>>>>>>> > >>>>>>>>>> Alper > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Yours, > >>>>>>>>>>> > >>>>>>>>>>> Alex > >>>>>>>>>>> > >>>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility > >>>>>>>>>>>> as the baseline for item#1 (the API). A revision of > >>>>>>>>>>>> the draft will also include a new section to cover > >>>>>>>>>>>> backward compatibility (Danny will provide the > >>>>>>>>>>>> draft text). Comments on the draft are welcome. > >>>>>>>>>>>> > >>>>>>>>>>>> The next call will be about items #2/#3 (IP > >>>>>>>>>>>> address configuration enhancements associated with > >>>>>>>>>>>> the API). We intend to schedule that one in about 2 > >>>>>>>>>>>> weeks. > >>>>>>>>>>>> > >>>>>>>>>>>> Alper > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Folks, > >>>>>>>>>>>>> > >>>>>>>>>>>>> See below for the Webex details. Remember, the > >>>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't > >>>>>>>>>>>>> forget to read the documents in the reading list > >>>>>>>>>>>>> prior to the call. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>>>> the discussions: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. > >>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.= pdf > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> > >> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>>>> 3. > >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-= mobility/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> > >> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>>>> 5. > >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> Alper > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* > >>>>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time > >>>>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min > >>>>>>>>>>>>> > >>>>>>>>>>>>>> *Join WebEx meeting* > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> > >> Meeting number:641 085 326 > >>>>>>>>>>>>>> Meeting password:dmm1911 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll > >>>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* > >>>>>>>>>>>>>> Call-in toll number (US/Canada) Access code: > >>>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> Add this meeting > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> to your calendar. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can't join the meeting? Contact support. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx > >>>>>>>>>>>>>> service allows audio and other information sent > >>>>>>>>>>>>>> during the session to be recorded, which may be > >>>>>>>>>>>>>> discoverable in a legal matter. By joining this > >>>>>>>>>>>>>> session, you automatically consent to such > >>>>>>>>>>>>>> recordings. If you do not consent to being > >>>>>>>>>>>>>> recorded, discuss your concerns with the host > >>>>>>>>>>>>>> or do not join the session. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Poll is closed, and majority selected the > >>>>>>>>>>>>>> following date for the call: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please mark your calendars. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In this call, we'll aim making progress on the > >>>>>>>>>>>>>> I-D for item#1 (an API for source address > >>>>>>>>>>>>>> selection). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>>>> the discussions: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. > >>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.= pdf > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> > >> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>>>> 3. > >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-= mobility/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> > >> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>>>> 5. > >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> Alper > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Folks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Please mark your availability on the > >>>>>>>>>>>>>>> following doodle for our next DMM WG Mobility > >>>>>>>>>>>>>>> Exposure and Selection WT call: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Register your availability no later than the > >>>>>>>>>>>>>>> end of Monday (Jan 26). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Alper > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ dmm > >>>>>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ dmm > >>>>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ dmm mailing > >>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ dmm mailing > >>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>> > >>>> > >>>> > >>>> _______________________________________________ dmm mailing list > >>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>> > >>> > >> > > > > > > >=20 From nobody Wed Apr 22 10:49:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3A1A1A33; Wed, 22 Apr 2015 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZYkXPE7RmPI4; Wed, 22 Apr 2015 10:49:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B91961A700D; Wed, 22 Apr 2015 10:49:32 -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.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422174932.10286.13372.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 10:49:32 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-4283mnids-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:49:36 -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 Working Group of the IETF. Title : MN Identifier Types for RFC 4283 Mobile Node Identifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-00.txt Pages : 7 Date : 2015-04-22 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-4283mnids-00 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 Wed Apr 22 20:48:26 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3AE1B2E8C for ; Wed, 22 Apr 2015 20:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.939 X-Spam-Level: * X-Spam-Status: No, score=1.939 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eLg1CZgnO06H for ; Wed, 22 Apr 2015 20:48:23 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 70D691B2DFD for ; Wed, 22 Apr 2015 20:48:21 -0700 (PDT) Received: from JoyYan (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0D5JXF_azhVgqw3AA--.13354S2; Thu, 23 Apr 2015 11:48:15 +0800 (CST) Date: Thu, 23 Apr 2015 11:48:12 +0800 From: "Z.W. Yan" To: "Alexandru Petrescu" , "dmm" References: <201504131333451125705@cnnic.cn> Message-ID: <201504231148123033203@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon508785571843_=====" X-CM-TRANSID: AQAAf0D5JXF_azhVgqw3AA--.13354S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar17KF43Kw1fAw4fJw1UWrg_yoW8Kr4fpF s0vr1rCrn5C3WIy3ykuw12qa1jkFZ5ZrZrG34Ygr1Yka45JF10yr10ka1akFWUuwn5JF15 tr4a9r4DA3Z0qrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Yb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I2 6xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI 67k04243AVC20s07MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E 3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCT nIWIevJa73UjIFyTuYvjxU4AhLDUUUU X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Cc: Jong-Hyouk Lee , xl Subject: Re: [DMM] New Version Notification for draft-yan-dmm-hnprenum-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 03:48:25 -0000 This is a multi-part message in MIME format. --=====003_Dragon508785571843_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsZXgsDQpUaGFuayB5b3UgZm9yIHlvdXIgYXR0ZW50aW9uLg0KRXhlY3RseSwgSVB2NiBh ZGRyZXNzIChvciBwcmVmaXgpIHJlbnVtYmVyaW5nIGlzIHZlcnkgbmVjZXNhcnkgdG8gDQpiZSBj b25zaWRlcmVkIGluIG1hbnkgc2NlbmFyaW9zIChlc3BlY2lhbGx5IHdoZW4gd2UgdGFsayBhYm91 dCBtb2JpbGl0eSBtYW5hZ2VtZW50KS4NCg0KQWJvdXQgeW91ciBjb25jZXJuczoNCjEpd2hlbiBh IEhvc3QgaXMgcmVudW1iZXJlZCwgd2lsbCB0aGUgbmV3IGFkZHJlc3MgYmVjb21lIEZpeGVkLCBT dXN0YWluZWQgb3IgTm9tYWRpYz8NCldlIG1lbnRpb25lZCBoZXJlIGlzIHRoZSBGaXhlZCBJUCBh ZGRyZXNzICh0aGUgSG9BKS4NCg0KMilpcyB0aGlzIGJyZWFraW5nIG9uZGVtYW5kIG1vYmlsaXR5 LCBvciBzdXBwb3J0aW5nIG9uZGVtYW5kIG1vYmlsaXR5Pw0KSW4gYSB3YXksIHRoaXMgaXMgYSBz dXBwb3J0aW5nIG9mIHRoZSBvbmRlbWFuZCBtb2JpbGl0eSBiZWNhdXNlIHRoaXMgZHJhZnQgYWlt cyB0byBub3RpZnkgb3IgY29uZmlndXJlIHRoZSBuZXcgSG9BIG9uIHRoZSBNTiBBU0FQLg0KDQpC ZXNpZGVzLCB3ZSBhcmUgbm93IHBvbGlzaGluZyBvdXIgZHJhZnQgdG8gYWRkcmVzcyB0aGUgc2Vz c2lvbiBjb25uZWNuaXZpdHkgYW5kIA0KaGFuZG92ZXIgb2YgdGhlIGFkZHJlc3MocHJlZml4KS4N Cg0KVGhhbmsgeW91Lg0KWmhpd2VpICANCg0KDQoNCjIwMTUtMDQtMjMgDQoNCg0KDQpaLlcuIFlh biANCg0KDQoNCreivP7Iy6O6IEFsZXhhbmRydSBQZXRyZXNjdSANCreiy83Ksbzko7ogMjAxNS0w NC0yMiAgMDQ6MTU6MDEgDQrK1bz+yMujuiBkbW0gDQqzrcvNo7ogDQrW98zio7ogUmU6IFtETU1d IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFuLWRtbS1obnByZW51bS0wMS50 eHQgDQogDQpMZSAxMy8wNC8yMDE1IDA3OjMzLCBaLlcuIFlhbiBhIKimY3JpdCA6DQo+IEhpLCBh bGwsDQo+IER1cmluZyB0aGUgRGFsbGFzIG1lZXRpbmcsIHdlIGludHJvZHVjZWQgdGhlIGlzc3Vl IG9mIEhOUC1yZW51bWJlcmluZyBpbiBQTUlQdjYgYW5kIGhlYXJkIHNvbWUgcG9zaXRpdmUgdm9p Y2VzLg0KPiBJbiBvcmRlciB0byBwcmVzZW50IGl0IG1vcmUgY2xlYXJseSBhbmQgY29sbGVjdCBt b3JlIGNvbW1lbnRzLA0KPiB3ZSB1cGRhdGVkIHRoZSBkcmFmdCB3aXRoIHRoZSAwMSB2ZXJzaW9u Lg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWRtbS1obnByZW51bS0w MQ0KPiBBbnkgY29tbWVudHMgZnJvbSB5b3UgYXJlIGFsbCB3ZWxjb21lLg0KPiBUaGFua3MuDQo+ IFpoaXdlaSBZYW4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gZG1tIG1haWxpbmcgbGlzdA0KPiBkbW1AaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4NCkhpLA0KVGhlIGlkZWEgb2Yg cmVudW1iZXJpbmcgYSBQTUlQdjYgbmV0d29yayAodXBkYXRlIGVhY2ggcHJlZml4IGZvciBlYWNo IA0KTU4tSUQpIG1ha2VzIHNlbnNlLiAgVGhlIHVzZS1jYXNlcyBkZXNjcmliZWQgaW4gdGhlIGRy YWZ0IGFyZSBuZWNlc3NhcnkuDQpJbiBvdGhlciBXR3MgbGlrZSBIb21lbmV0IGFuZCBBbmltYSwg dGhlcmUgaXMgb25nb2luZyBkaXNjdXNzaW9uIGFib3V0IA0KbmV3IFJlbnVtYmVyaW5nIHByb2Nl ZHVyZXMgaW4gRW50ZXJwcmlzZSBhbmQgaW4gSG9tZSwgd2hlcmVhcyB0aGlzIHdvdWxkIA0KYmUg aW4gYSBNb2JpbGUgbmV0d29yayBsaWtlIDNHUFAuDQpUaGUgZHJhZnQgcHJlc2VudHMgZGlhZ3Jh bXMgb2YgbWVzc2FnZSBleGNoYW5nZXMgYXMgd2VsbCBhcyBicmllZiANCmRlc2NyaXB0aW9ucyBv ZiBtZXNzYWdlIGZvcm1hdHM7IHRoaXMgaXMgdG8gYmUgaW1wbGVtZW50ZWQgd2l0aCBESENQdjYg DQphbmQgUkEsIGFtb25nIG90aGVycy4NCkkgd291bGQgbGlrZSB0byBhc2sgeW91IHRoaXM6IHdo ZW4gYSBIb3N0IGlzIHJlbnVtYmVyZWQsIHdpbGwgdGhlIG5ldyANCmFkZHJlc3MgYmVjb21lIEZp eGVkLCBTdXN0YWluZWQgb3IgTm9tYWRpYz8NCkkgd291bGQgYWxzbyBsaWtlIHRvIGFzayB0aGlz OiBpcyB0aGlzIGJyZWFraW5nIG9uZGVtYW5kIG1vYmlsaXR5LCBvciANCnN1cHBvcnRpbmcgb25k ZW1hbmQgbW9iaWxpdHk/DQpUaGVyZSBpcyBhIG5pdCAiVHJpZ2dlZCIuDQpBbGV4DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlz dA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt bQ0K --=====003_Dragon508785571843_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNzI5NiI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IMvOzOU7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsN Cn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24x IHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAx MC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlm eTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0N CkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0la RTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1 c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0K fQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBs ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglG T05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUt dHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9u MQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0KfQ0KT0wg ew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFSR0lOOiAx MHB4Ij4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJ Vj5IaSwmbmJzcDtBbGV4LDwvRElWPg0KPERJVj5UaGFuayZuYnNwO3lvdSZuYnNwO2ZvciZuYnNw O3lvdXImbmJzcDthdHRlbnRpb24uPC9ESVY+DQo8RElWPkV4ZWN0bHksJm5ic3A7SVB2NiZuYnNw O2FkZHJlc3MmbmJzcDsob3ImbmJzcDtwcmVmaXgpJm5ic3A7cmVudW1iZXJpbmcmbmJzcDtpcyZu YnNwO3ZlcnkmbmJzcDtuZWNlc2FyeSZuYnNwO3RvJm5ic3A7PC9ESVY+DQo8RElWPmJlJm5ic3A7 Y29uc2lkZXJlZCZuYnNwO2luJm5ic3A7bWFueSZuYnNwO3NjZW5hcmlvcyZuYnNwOyhlc3BlY2lh bGx5Jm5ic3A7d2hlbiZuYnNwO3dlJm5ic3A7dGFsayZuYnNwO2Fib3V0Jm5ic3A7bW9iaWxpdHkm bmJzcDttYW5hZ2VtZW50KS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFib3V0Jm5i c3A7eW91ciZuYnNwO2NvbmNlcm5zOjwvRElWPg0KPERJVj4xKXdoZW4mbmJzcDthJm5ic3A7SG9z dCZuYnNwO2lzJm5ic3A7cmVudW1iZXJlZCwmbmJzcDt3aWxsJm5ic3A7dGhlJm5ic3A7bmV3Jm5i c3A7YWRkcmVzcyZuYnNwO2JlY29tZSZuYnNwO0ZpeGVkLCZuYnNwO1N1c3RhaW5lZCZuYnNwO29y Jm5ic3A7Tm9tYWRpYz88L0RJVj4NCjxESVY+V2UmbmJzcDttZW50aW9uZWQmbmJzcDtoZXJlJm5i c3A7aXMmbmJzcDt0aGUmbmJzcDtGaXhlZCZuYnNwO0lQJm5ic3A7YWRkcmVzcyZuYnNwOyh0aGUm bmJzcDtIb0EpLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjIp aXMmbmJzcDt0aGlzJm5ic3A7YnJlYWtpbmcmbmJzcDtvbmRlbWFuZCZuYnNwO21vYmlsaXR5LCZu YnNwO29yJm5ic3A7c3VwcG9ydGluZyZuYnNwO29uZGVtYW5kJm5ic3A7bW9iaWxpdHk/PC9ESVY+ DQo8RElWPkluJm5ic3A7YSZuYnNwO3dheSwmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDthJm5ic3A7 c3VwcG9ydGluZyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7b25kZW1hbmQmbmJzcDttb2JpbGl0eSZu YnNwO2JlY2F1c2UmbmJzcDt0aGlzJm5ic3A7ZHJhZnQmbmJzcDthaW1zJm5ic3A7dG8mbmJzcDtu b3RpZnkmbmJzcDtvciZuYnNwO2NvbmZpZ3VyZSZuYnNwO3RoZSZuYnNwO25ldyZuYnNwO0hvQSZu YnNwO29uJm5ic3A7dGhlJm5ic3A7TU4mbmJzcDtBU0FQLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc2lkZXMsJm5ic3A7d2UmbmJzcDthcmUmbmJzcDtub3cm bmJzcDtwb2xpc2hpbmcmbmJzcDtvdXImbmJzcDtkcmFmdCZuYnNwO3RvJm5ic3A7YWRkcmVzcyZu YnNwO3RoZSZuYnNwO3Nlc3Npb24mbmJzcDtjb25uZWNuaXZpdHkmbmJzcDthbmQmbmJzcDs8L0RJ Vj4NCjxESVY+aGFuZG92ZXImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2FkZHJlc3MocHJlZml4KS48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rJm5ic3A7eW91LjwvRElWPg0KPERJ Vj5aaGl3ZWkmbmJzcDsmbmJzcDs8L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9y PSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNp emU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxNS0wNC0yMyA8L0ZPTlQ+PC9E SVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9 IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4N CjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPlouVy4g WWFuPC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxE SVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IEFs ZXhhbmRydSBQZXRyZXNjdSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9 VmVyZGFuYT48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gMjAxNS0wNC0yMiZuYnNwOyAwNDox NTowMSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RS T05HPsrVvP7Iy6O6PC9TVFJPTkc+IGRtbSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IFJlOiBb RE1NXSBOZXcgVmVyc2lvbiANCk5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFuLWRtbS1obnByZW51 bS0wMS50eHQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwv Rk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPkxlJm5i c3A7MTMvMDQvMjAxNSZuYnNwOzA3OjMzLCZuYnNwO1ouVy4mbmJzcDtZYW4mbmJzcDthJm5ic3A7 qKZjcml0Jm5ic3A7OjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SGksJm5ic3A7YWxsLDwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7RHVyaW5nJm5ic3A7dGhlJm5ic3A7RGFsbGFzJm5ic3A7bWVldGluZywm bmJzcDt3ZSZuYnNwO2ludHJvZHVjZWQmbmJzcDt0aGUmbmJzcDtpc3N1ZSZuYnNwO29mJm5ic3A7 SE5QLXJlbnVtYmVyaW5nJm5ic3A7aW4mbmJzcDtQTUlQdjYmbmJzcDthbmQmbmJzcDtoZWFyZCZu YnNwO3NvbWUmbmJzcDtwb3NpdGl2ZSZuYnNwO3ZvaWNlcy48L0RJVj4NCjxESVY+Jmd0OyZuYnNw O0luJm5ic3A7b3JkZXImbmJzcDt0byZuYnNwO3ByZXNlbnQmbmJzcDtpdCZuYnNwO21vcmUmbmJz cDtjbGVhcmx5Jm5ic3A7YW5kJm5ic3A7Y29sbGVjdCZuYnNwO21vcmUmbmJzcDtjb21tZW50cyw8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3dlJm5ic3A7dXBkYXRlZCZuYnNwO3RoZSZuYnNwO2RyYWZ0 Jm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwOzAxJm5ic3A7dmVyc2lvbi48L0RJVj4NCjxESVY+Jmd0 OyZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW4tZG1tLWhucHJlbnVt LTAxPC9ESVY+DQo8RElWPiZndDsmbmJzcDtBbnkmbmJzcDtjb21tZW50cyZuYnNwO2Zyb20mbmJz cDt5b3UmbmJzcDthcmUmbmJzcDthbGwmbmJzcDt3ZWxjb21lLjwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7VGhhbmtzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Wmhpd2VpJm5ic3A7WWFuPC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+Jmd0OyZu YnNwO2RtbSZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPiZndDsmbmJzcDtkbW1A aWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1tPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElW PkhpLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5ic3A7aWRlYSZuYnNwO29mJm5ic3A7 cmVudW1iZXJpbmcmbmJzcDthJm5ic3A7UE1JUHY2Jm5ic3A7bmV0d29yayZuYnNwOyh1cGRhdGUm bmJzcDtlYWNoJm5ic3A7cHJlZml4Jm5ic3A7Zm9yJm5ic3A7ZWFjaCZuYnNwOzwvRElWPg0KPERJ Vj5NTi1JRCkmbmJzcDttYWtlcyZuYnNwO3NlbnNlLiZuYnNwOyZuYnNwO1RoZSZuYnNwO3VzZS1j YXNlcyZuYnNwO2Rlc2NyaWJlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7ZHJhZnQmbmJzcDthcmUm bmJzcDtuZWNlc3NhcnkuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JbiZuYnNwO290aGVyJm5i c3A7V0dzJm5ic3A7bGlrZSZuYnNwO0hvbWVuZXQmbmJzcDthbmQmbmJzcDtBbmltYSwmbmJzcDt0 aGVyZSZuYnNwO2lzJm5ic3A7b25nb2luZyZuYnNwO2Rpc2N1c3Npb24mbmJzcDthYm91dCZuYnNw OzwvRElWPg0KPERJVj5uZXcmbmJzcDtSZW51bWJlcmluZyZuYnNwO3Byb2NlZHVyZXMmbmJzcDtp biZuYnNwO0VudGVycHJpc2UmbmJzcDthbmQmbmJzcDtpbiZuYnNwO0hvbWUsJm5ic3A7d2hlcmVh cyZuYnNwO3RoaXMmbmJzcDt3b3VsZCZuYnNwOzwvRElWPg0KPERJVj5iZSZuYnNwO2luJm5ic3A7 YSZuYnNwO01vYmlsZSZuYnNwO25ldHdvcmsmbmJzcDtsaWtlJm5ic3A7M0dQUC48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO2RyYWZ0Jm5ic3A7cHJlc2VudHMmbmJzcDtkaWFncmFt cyZuYnNwO29mJm5ic3A7bWVzc2FnZSZuYnNwO2V4Y2hhbmdlcyZuYnNwO2FzJm5ic3A7d2VsbCZu YnNwO2FzJm5ic3A7YnJpZWYmbmJzcDs8L0RJVj4NCjxESVY+ZGVzY3JpcHRpb25zJm5ic3A7b2Ym bmJzcDttZXNzYWdlJm5ic3A7Zm9ybWF0czsmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDt0byZuYnNw O2JlJm5ic3A7aW1wbGVtZW50ZWQmbmJzcDt3aXRoJm5ic3A7REhDUHY2Jm5ic3A7PC9ESVY+DQo8 RElWPmFuZCZuYnNwO1JBLCZuYnNwO2Ftb25nJm5ic3A7b3RoZXJzLjwvRElWPg0KPERJVj48L0RJ Vj4NCjxESVY+SSZuYnNwO3dvdWxkJm5ic3A7bGlrZSZuYnNwO3RvJm5ic3A7YXNrJm5ic3A7eW91 Jm5ic3A7dGhpczombmJzcDt3aGVuJm5ic3A7YSZuYnNwO0hvc3QmbmJzcDtpcyZuYnNwO3JlbnVt YmVyZWQsJm5ic3A7d2lsbCZuYnNwO3RoZSZuYnNwO25ldyZuYnNwOzwvRElWPg0KPERJVj5hZGRy ZXNzJm5ic3A7YmVjb21lJm5ic3A7Rml4ZWQsJm5ic3A7U3VzdGFpbmVkJm5ic3A7b3ImbmJzcDtO b21hZGljPzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SSZuYnNwO3dvdWxkJm5ic3A7YWxzbyZu YnNwO2xpa2UmbmJzcDt0byZuYnNwO2FzayZuYnNwO3RoaXM6Jm5ic3A7aXMmbmJzcDt0aGlzJm5i c3A7YnJlYWtpbmcmbmJzcDtvbmRlbWFuZCZuYnNwO21vYmlsaXR5LCZuYnNwO29yJm5ic3A7PC9E SVY+DQo8RElWPnN1cHBvcnRpbmcmbmJzcDtvbmRlbWFuZCZuYnNwO21vYmlsaXR5PzwvRElWPg0K PERJVj48L0RJVj4NCjxESVY+VGhlcmUmbmJzcDtpcyZuYnNwO2EmbmJzcDtuaXQmbmJzcDsiVHJp Z2dlZCIuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5BbGV4PC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElW Pg0KPERJVj5kbW0mbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kbW1AaWV0Zi5v cmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08 L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon508785571843_=====-- From nobody Thu Apr 23 10:11:48 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C021ACDA7 for ; Thu, 23 Apr 2015 10:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 Y2SjOjeJ9ZWo for ; Thu, 23 Apr 2015 10:11:45 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 EA1571ACDBC for ; Thu, 23 Apr 2015 10:11:33 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so18227278lbb.0 for ; Thu, 23 Apr 2015 10:11:32 -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-type:content-transfer-encoding; bh=XdGok+txuIuQEAUzxHC8KyCBwbwENWdWK6UiR/L6SfA=; b=omjPDra+HPByCn+vsWcNXRurLtb3WlAC3eBeBJBrrjCEK2TpaU2YE0mwSw8i+AH2kB 0TlAE59wXoK5nVK5xkU7i6sH78gi5/MiIp7ZMqAf7Ax/8zR7S7w5OkvWGcFQLd4rso6O ixwXRWbJeBfJjO3oPos6x1jJUUcwIUThiVkiEg2Vxty+vz/iuyG0ko/kmixMurJdBPOk MYZjIe2QPEEn0XHnULmVA0zFlpDUzLLq2eewdD1xUXA9fcgcTN4pchj8rl2oImy7oGQr 4yYAJ2pM3B17BzyT/gy0/d1XilnzzMtmmPASMy1ho32lbRTu8DjO8hSdkcGwINomrwxy /U8Q== MIME-Version: 1.0 X-Received: by 10.152.37.69 with SMTP id w5mr3317968laj.15.1429809092396; Thu, 23 Apr 2015 10:11:32 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Thu, 23 Apr 2015 10:11:32 -0700 (PDT) In-Reply-To: <5537D047.5040502@gmail.com> References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> Date: Thu, 23 Apr 2015 12:11:32 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 23 Apr 2015 17:11:47 -0000 On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu wrote: > Le 22/04/2015 18:06, Behcet Sarikaya a =C3=A9crit : >> >> Hi Alex, >> >> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu >> wrote: >>> >>> Le 16/04/2015 06:58, Jouni Korhonen a =C3=A9crit : >>>> >>>> >>>> Folks, >>>> >>>> The adoption call for this I-D has ended. There is a clear concensus t= o >>>> adopt the I-D as a working group item. >>> >>> >>> >>> I support its adoption. >>> >>> We have been working with an identifier specific to automobiles to use = to >>> realize access control. Identifying an entire set of IP nodes deployed >>> in a >>> vehicle is different than identifying an end-user like address@realm. >>> >>> We looked for such an identifier and believe the VIN (Vehicle >>> Identification >>> Number) be a good candidate. >>> >>> One would consider using one type, like type 40, to encode the VIN or >>> parts >>> of it, into an MN-ID. >>> >>> The questions to the group are the following: >>> - is VIN considered private information? (in deployments it is private >>> to a certain extent, but publicly avaliable to cameras or in public >>> databases to another extent). >>> - is the MN-ID type 40 ok for it. >>> - is one type sufficient or should there be subtypes. >> >> >> What is your model here in providing Internet access to the car? >> As you may know, operators in US are deploying systems that connect >> the car to their LTE network upstream and downstream is the passengers >> in the car that access over Wi-Fi. >> With LTE, you get mobility support which is based on fixed anchoring. >> I cc'ed to Raj who works on these types of technologies. >> The ID there is the IMSI. I don't think vin is used. > > > The model of Internet access to the cars for cars currently on market in > Europe is the same - the LTE technology is used, using the IMSI as an > identifier. However, that does not use MN-ID, is only IPv4, is not WiFi = and > does not resist to cellular generation upgrades to 5G and beyond. I don't understand the handover scenario. I think you are mixing the car and the passengers in the car. LTE is available on a large geography, why should you handover the upstream traffic to Wi-Fi? Behcet > > Newer models will feature IPv6 in addition to IPv4, WiFi handover from LT= E > to house's hotspot, continuous sessions, and over-the-air software update > for cheap upgradeability to future generation 5G and beyond. > > In this context it is hard to imagine IMSI will be there for a long time = in > a given car, and a more permanent identifier is needed. > > To Raj - is LTE considering other kinds of identifiers for access control > (other than IMSI) for vehicular environments, like V2X? > > Alex > > > >> >> Regards, >> >> Behcet >>> >>> >>> Yours, >>> >>> Alex >>> >>> >>>> >>>> - Jouni & Dapeng >>>> >>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>> >>>>> >>>>> Folks, >>>>> >>>>> This emails starts a two week call for the I-D >>>>> draft-perkins-dmm-4283mnids-01 >>>>> to confirm the aadoption s a DMM WG document. The call ends April 15t= h >>>>> EOB PST. >>>>> >>>>> Express your support or opposition to the mailing list. During the >>>>> IETF92 meeting we got 7 voices for the adoption so at least the same >>>>> amount supporting emails should be expected. >>>>> >>>>> - Jouni & Dapeng >>>> >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> >> > > From nobody Thu Apr 23 10:32:55 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60951ACE1D for ; Thu, 23 Apr 2015 10:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HOh7J4CX4qww for ; Thu, 23 Apr 2015 10:32:52 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A96741B30F0 for ; Thu, 23 Apr 2015 10:32:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rKTh0z1CjbyCNk7ksBpRsUA4vRCOLMXib4ET16ezxSB4bc84NwZnKkL6++pq95Fw; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.252.133]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1YlKz1-0000FU-5u; Thu, 23 Apr 2015 13:32:15 -0400 Message-ID: <55392C9D.5040407@earthlink.net> Date: Thu, 23 Apr 2015 10:32:13 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac79affbbb65bf699ef5d7ac6bbe2068f8d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:32:54 -0000 Hello Behcet, On 4/23/2015 10:11 AM, Behcet Sarikaya wrote: >> The model of Internet access to the cars for cars currently on market in >> Europe is the same - the LTE technology is used, using the IMSI as an >> identifier. However, that does not use MN-ID, is only IPv4, is not WiFi and >> does not resist to cellular generation upgrades to 5G and beyond. > I don't understand the handover scenario. I think you are mixing the > car and the passengers in the car. > LTE is available on a large geography, why should you handover the > upstream traffic to Wi-Fi? > > I think the IETF should be enabling solutions that do not presume the availability of LTE. There are likely to be applications for which reduced (or zero) cost is important. Regards, Charlie P. From nobody Fri Apr 24 01:28:43 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A221B35ED for ; Fri, 24 Apr 2015 01:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 xR1WyjUthdsp for ; Fri, 24 Apr 2015 01:28:36 -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 599E21B35D3 for ; Fri, 24 Apr 2015 01:27:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3O8RmNB011998; Fri, 24 Apr 2015 10:27:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 58C0A203136; Fri, 24 Apr 2015 10:29:15 +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 48A70203027; Fri, 24 Apr 2015 10:29:15 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3O8R0fl014310; Fri, 24 Apr 2015 10:27:47 +0200 Message-ID: <5539FE54.2030103@gmail.com> Date: Fri, 24 Apr 2015 10:27:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:28:42 -0000 Le 23/04/2015 19:11, Behcet Sarikaya a 茅crit : > On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu > wrote: >> Le 22/04/2015 18:06, Behcet Sarikaya a 茅crit : >>> >>> Hi Alex, >>> >>> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu >>> wrote: >>>> >>>> Le 16/04/2015 06:58, Jouni Korhonen a 茅crit : >>>>> >>>>> >>>>> Folks, >>>>> >>>>> The adoption call for this I-D has ended. There is a clear concensus to >>>>> adopt the I-D as a working group item. >>>> >>>> >>>> >>>> I support its adoption. >>>> >>>> We have been working with an identifier specific to automobiles to use to >>>> realize access control. Identifying an entire set of IP nodes deployed >>>> in a >>>> vehicle is different than identifying an end-user like address@realm. >>>> >>>> We looked for such an identifier and believe the VIN (Vehicle >>>> Identification >>>> Number) be a good candidate. >>>> >>>> One would consider using one type, like type 40, to encode the VIN or >>>> parts >>>> of it, into an MN-ID. >>>> >>>> The questions to the group are the following: >>>> - is VIN considered private information? (in deployments it is private >>>> to a certain extent, but publicly avaliable to cameras or in public >>>> databases to another extent). >>>> - is the MN-ID type 40 ok for it. >>>> - is one type sufficient or should there be subtypes. >>> >>> >>> What is your model here in providing Internet access to the car? >>> As you may know, operators in US are deploying systems that connect >>> the car to their LTE network upstream and downstream is the passengers >>> in the car that access over Wi-Fi. >>> With LTE, you get mobility support which is based on fixed anchoring. >>> I cc'ed to Raj who works on these types of technologies. >>> The ID there is the IMSI. I don't think vin is used. >> >> >> The model of Internet access to the cars for cars currently on market in >> Europe is the same - the LTE technology is used, using the IMSI as an >> identifier. However, that does not use MN-ID, is only IPv4, is not WiFi and >> does not resist to cellular generation upgrades to 5G and beyond. > > I don't understand the handover scenario. I think you are mixing the > car and the passengers in the car. > LTE is available on a large geography, why should you handover the > upstream traffic to Wi-Fi? When the car arrives home it connects to the WiFi available in home, thus handing over from LTE. This is a sold use-case at e.g. Tesla. The WiFi hotspot can be the one deployed in-house, in-garage, or the WiFi offered by the electrical recharging stations. Other manufacturers propose scenarios in which car's WiFi antenna switches from being an in-car hotspot to being a Client to outside wifi. Some consider 802.11p (wifi for vehicles) to be deployed along highways and cars to perform handovers between these 802.11p access points. Next time on highway scan for WiFi - one is surprised by the number of hotspots driving around, even though often they use portals. There are many commercially considered scenarios involving WiFi handovers for cars. Alex > > Behcet >> >> Newer models will feature IPv6 in addition to IPv4, WiFi handover from LTE >> to house's hotspot, continuous sessions, and over-the-air software update >> for cheap upgradeability to future generation 5G and beyond. >> >> In this context it is hard to imagine IMSI will be there for a long time in >> a given car, and a more permanent identifier is needed. >> >> To Raj - is LTE considering other kinds of identifiers for access control >> (other than IMSI) for vehicular environments, like V2X? >> >> Alex >> >> >> >>> >>> Regards, >>> >>> Behcet >>>> >>>> >>>> Yours, >>>> >>>> Alex >>>> >>>> >>>>> >>>>> - Jouni & Dapeng >>>>> >>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> This emails starts a two week call for the I-D >>>>>> draft-perkins-dmm-4283mnids-01 >>>>>> to confirm the aadoption s a DMM WG document. The call ends April 15th >>>>>> EOB PST. >>>>>> >>>>>> Express your support or opposition to the mailing list. During the >>>>>> IETF92 meeting we got 7 voices for the adoption so at least the same >>>>>> amount supporting emails should be expected. >>>>>> >>>>>> - Jouni & Dapeng >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >>> >> >> > > From nobody Fri Apr 24 08:14:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2F1A905B for ; Fri, 24 Apr 2015 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UnR-GwUvkqis for ; Fri, 24 Apr 2015 08:14:11 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE5E1A8955 for ; Fri, 24 Apr 2015 08:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3OFEAtx002864; Fri, 24 Apr 2015 08:14:11 -0700 Received: from XCH-BLV-208.nw.nos.boeing.com (xch-blv-208.nw.nos.boeing.com [10.57.37.5]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3OFE8Sr002854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Apr 2015 08:14:09 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.252]) with mapi id 14.03.0235.001; Fri, 24 Apr 2015 08:14:08 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "sarikaya@ieee.org" Thread-Topic: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 Thread-Index: AQHQfmiwz2AmdzZKBUK31k0rrjXXiZ1cRUvA Date: Fri, 24 Apr 2015 15:14:07 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E511BD@XCH-BLV-504.nw.nos.boeing.com> References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> <5539FE54.2030103@gmail.com> In-Reply-To: <5539FE54.2030103@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "sofiane.imadali@gmail.com" , Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 15:14:15 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbW0gW21h aWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRydSBQZXRyZXNj dQ0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDE1IDE6MjcgQU0NCj4gVG86IHNhcmlrYXlh QGllZWUub3JnDQo+IENjOiBzb2ZpYW5lLmltYWRhbGlAZ21haWwuY29tOyBCYXNhdmFyYWogUGF0 aWw7IGRtbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RNTV0gQ2FsbCBmb3IgYWRvcHRpb246 IGRyYWZ0LXBlcmtpbnMtZG1tLTQyODNtbmlkcy0wMQ0KPiANCj4gTGUgMjMvMDQvMjAxNSAxOTox MSwgQmVoY2V0IFNhcmlrYXlhIGEgw6ljcml0IDoNCj4gPiBPbiBXZWQsIEFwciAyMiwgMjAxNSBh dCAxMTo0NSBBTSwgQWxleGFuZHJ1IFBldHJlc2N1DQo+ID4gPGFsZXhhbmRydS5wZXRyZXNjdUBn bWFpbC5jb20+IHdyb3RlOg0KPiA+PiBMZSAyMi8wNC8yMDE1IDE4OjA2LCBCZWhjZXQgU2FyaWth eWEgYSDDqWNyaXQgOg0KPiA+Pj4NCj4gPj4+ICAgIEhpIEFsZXgsDQo+ID4+Pg0KPiA+Pj4gT24g VHVlLCBBcHIgMjEsIDIwMTUgYXQgMjo1NSBQTSwgQWxleGFuZHJ1IFBldHJlc2N1DQo+ID4+PiA8 YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBMZSAx Ni8wNC8yMDE1IDA2OjU4LCBKb3VuaSBLb3Job25lbiBhIMOpY3JpdCA6DQo+ID4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4+IEZvbGtzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgYWRvcHRpb24gY2FsbCBm b3IgdGhpcyBJLUQgaGFzIGVuZGVkLiBUaGVyZSBpcyBhIGNsZWFyIGNvbmNlbnN1cyB0bw0KPiA+ Pj4+PiBhZG9wdCB0aGUgSS1EIGFzIGEgd29ya2luZyBncm91cCBpdGVtLg0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IEkgc3VwcG9ydCBpdHMgYWRvcHRpb24uDQo+ID4+Pj4NCj4gPj4+ PiBXZSBoYXZlIGJlZW4gd29ya2luZyB3aXRoIGFuIGlkZW50aWZpZXIgc3BlY2lmaWMgdG8gYXV0 b21vYmlsZXMgdG8gdXNlIHRvDQo+ID4+Pj4gcmVhbGl6ZSBhY2Nlc3MgY29udHJvbC4gIElkZW50 aWZ5aW5nIGFuIGVudGlyZSBzZXQgb2YgSVAgbm9kZXMgZGVwbG95ZWQNCj4gPj4+PiBpbiBhDQo+ ID4+Pj4gdmVoaWNsZSBpcyBkaWZmZXJlbnQgdGhhbiBpZGVudGlmeWluZyBhbiBlbmQtdXNlciBs aWtlIGFkZHJlc3NAcmVhbG0uDQo+ID4+Pj4NCj4gPj4+PiBXZSBsb29rZWQgZm9yIHN1Y2ggYW4g aWRlbnRpZmllciBhbmQgYmVsaWV2ZSB0aGUgVklOIChWZWhpY2xlDQo+ID4+Pj4gSWRlbnRpZmlj YXRpb24NCj4gPj4+PiBOdW1iZXIpIGJlIGEgZ29vZCBjYW5kaWRhdGUuDQo+ID4+Pj4NCj4gPj4+ PiBPbmUgd291bGQgY29uc2lkZXIgdXNpbmcgb25lIHR5cGUsIGxpa2UgdHlwZSA0MCwgdG8gZW5j b2RlIHRoZSBWSU4gb3INCj4gPj4+PiBwYXJ0cw0KPiA+Pj4+IG9mIGl0LCBpbnRvIGFuIE1OLUlE Lg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIHF1ZXN0aW9ucyB0byB0aGUgZ3JvdXAgYXJlIHRoZSBmb2xs b3dpbmc6DQo+ID4+Pj4gLSBpcyBWSU4gY29uc2lkZXJlZCBwcml2YXRlIGluZm9ybWF0aW9uPyAo aW4gZGVwbG95bWVudHMgaXQgaXMgcHJpdmF0ZQ0KPiA+Pj4+ICAgICB0byBhIGNlcnRhaW4gZXh0 ZW50LCBidXQgcHVibGljbHkgYXZhbGlhYmxlIHRvIGNhbWVyYXMgb3IgaW4gcHVibGljDQo+ID4+ Pj4gICAgIGRhdGFiYXNlcyB0byBhbm90aGVyIGV4dGVudCkuDQo+ID4+Pj4gLSBpcyB0aGUgTU4t SUQgdHlwZSA0MCBvayBmb3IgaXQuDQo+ID4+Pj4gLSBpcyBvbmUgdHlwZSBzdWZmaWNpZW50IG9y IHNob3VsZCB0aGVyZSBiZSBzdWJ0eXBlcy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gV2hhdCBpcyB5 b3VyIG1vZGVsIGhlcmUgaW4gcHJvdmlkaW5nIEludGVybmV0IGFjY2VzcyB0byB0aGUgY2FyPw0K PiA+Pj4gQXMgeW91IG1heSBrbm93LCBvcGVyYXRvcnMgaW4gVVMgYXJlIGRlcGxveWluZyBzeXN0 ZW1zIHRoYXQgY29ubmVjdA0KPiA+Pj4gdGhlIGNhciB0byB0aGVpciBMVEUgbmV0d29yayB1cHN0 cmVhbSBhbmQgZG93bnN0cmVhbSBpcyB0aGUgcGFzc2VuZ2Vycw0KPiA+Pj4gaW4gdGhlIGNhciB0 aGF0IGFjY2VzcyBvdmVyIFdpLUZpLg0KPiA+Pj4gV2l0aCBMVEUsIHlvdSBnZXQgbW9iaWxpdHkg c3VwcG9ydCB3aGljaCBpcyBiYXNlZCBvbiBmaXhlZCBhbmNob3JpbmcuDQo+ID4+PiBJIGNjJ2Vk IHRvIFJhaiB3aG8gd29ya3Mgb24gdGhlc2UgdHlwZXMgb2YgdGVjaG5vbG9naWVzLg0KPiA+Pj4g VGhlIElEIHRoZXJlIGlzIHRoZSBJTVNJLiBJIGRvbid0IHRoaW5rIHZpbiBpcyB1c2VkLg0KPiA+ Pg0KPiA+Pg0KPiA+PiBUaGUgbW9kZWwgb2YgSW50ZXJuZXQgYWNjZXNzIHRvIHRoZSBjYXJzIGZv ciBjYXJzIGN1cnJlbnRseSBvbiBtYXJrZXQgaW4NCj4gPj4gRXVyb3BlIGlzIHRoZSBzYW1lIC0g dGhlIExURSB0ZWNobm9sb2d5IGlzIHVzZWQsIHVzaW5nIHRoZSBJTVNJIGFzIGFuDQo+ID4+IGlk ZW50aWZpZXIuICBIb3dldmVyLCB0aGF0IGRvZXMgbm90IHVzZSBNTi1JRCwgaXMgb25seSBJUHY0 LCBpcyBub3QgV2lGaSBhbmQNCj4gPj4gZG9lcyBub3QgcmVzaXN0IHRvIGNlbGx1bGFyIGdlbmVy YXRpb24gdXBncmFkZXMgdG8gNUcgYW5kIGJleW9uZC4NCj4gPg0KPiA+IEkgZG9uJ3QgdW5kZXJz dGFuZCB0aGUgaGFuZG92ZXIgc2NlbmFyaW8uIEkgdGhpbmsgeW91IGFyZSBtaXhpbmcgdGhlDQo+ ID4gY2FyIGFuZCB0aGUgcGFzc2VuZ2VycyBpbiB0aGUgY2FyLg0KPiA+IExURSBpcyBhdmFpbGFi bGUgb24gYSBsYXJnZSBnZW9ncmFwaHksIHdoeSBzaG91bGQgeW91IGhhbmRvdmVyIHRoZQ0KPiA+ IHVwc3RyZWFtIHRyYWZmaWMgdG8gV2ktRmk/DQo+IA0KPiBXaGVuIHRoZSBjYXIgYXJyaXZlcyBo b21lIGl0IGNvbm5lY3RzIHRvIHRoZSBXaUZpIGF2YWlsYWJsZSBpbiBob21lLA0KPiB0aHVzIGhh bmRpbmcgb3ZlciBmcm9tIExURS4gIFRoaXMgaXMgYSBzb2xkIHVzZS1jYXNlIGF0IGUuZy4gVGVz bGEuICBUaGUNCj4gV2lGaSBob3RzcG90IGNhbiBiZSB0aGUgb25lIGRlcGxveWVkIGluLWhvdXNl LCBpbi1nYXJhZ2UsIG9yIHRoZSBXaUZpDQo+IG9mZmVyZWQgYnkgdGhlIGVsZWN0cmljYWwgcmVj aGFyZ2luZyBzdGF0aW9ucy4NCg0KSW4gdGhlIGF2aWF0aW9uIGRvbWFpbiwgdGhlIHRlcm0gImdh dGVsaW5rIiBpcyBvZnRlbiB1c2VkIHRvIGRlc2NyaWJlDQp0aGlzIGtpbmQgb2YgV2lGaSBoYW5k b3Zlci4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IE90 aGVyIG1hbnVmYWN0dXJlcnMgcHJvcG9zZSBzY2VuYXJpb3MgaW4gd2hpY2ggY2FyJ3MgV2lGaSBh bnRlbm5hDQo+IHN3aXRjaGVzIGZyb20gYmVpbmcgYW4gaW4tY2FyIGhvdHNwb3QgdG8gYmVpbmcg YSBDbGllbnQgdG8gb3V0c2lkZSB3aWZpLg0KPiANCj4gU29tZSBjb25zaWRlciA4MDIuMTFwICh3 aWZpIGZvciB2ZWhpY2xlcykgdG8gYmUgZGVwbG95ZWQgYWxvbmcgaGlnaHdheXMNCj4gYW5kIGNh cnMgdG8gcGVyZm9ybSBoYW5kb3ZlcnMgYmV0d2VlbiB0aGVzZSA4MDIuMTFwIGFjY2VzcyBwb2lu dHMuDQo+IA0KPiBOZXh0IHRpbWUgb24gaGlnaHdheSBzY2FuIGZvciBXaUZpIC0gb25lIGlzIHN1 cnByaXNlZCBieSB0aGUgbnVtYmVyIG9mDQo+IGhvdHNwb3RzIGRyaXZpbmcgYXJvdW5kLCBldmVu IHRob3VnaCBvZnRlbiB0aGV5IHVzZSBwb3J0YWxzLg0KPiANCj4gVGhlcmUgYXJlIG1hbnkgY29t bWVyY2lhbGx5IGNvbnNpZGVyZWQgc2NlbmFyaW9zIGludm9sdmluZyBXaUZpDQo+IGhhbmRvdmVy cyBmb3IgY2Fycy4NCj4gDQo+IEFsZXgNCj4gDQo+ID4NCj4gPiBCZWhjZXQNCj4gPj4NCj4gPj4g TmV3ZXIgbW9kZWxzIHdpbGwgZmVhdHVyZSBJUHY2IGluIGFkZGl0aW9uIHRvIElQdjQsIFdpRmkg aGFuZG92ZXIgZnJvbSBMVEUNCj4gPj4gdG8gaG91c2UncyBob3RzcG90LCBjb250aW51b3VzIHNl c3Npb25zLCBhbmQgb3Zlci10aGUtYWlyIHNvZnR3YXJlIHVwZGF0ZQ0KPiA+PiBmb3IgY2hlYXAg dXBncmFkZWFiaWxpdHkgdG8gZnV0dXJlIGdlbmVyYXRpb24gNUcgYW5kIGJleW9uZC4NCj4gPj4N Cj4gPj4gSW4gdGhpcyBjb250ZXh0IGl0IGlzIGhhcmQgdG8gaW1hZ2luZSBJTVNJIHdpbGwgYmUg dGhlcmUgZm9yIGEgbG9uZyB0aW1lIGluDQo+ID4+IGEgZ2l2ZW4gY2FyLCBhbmQgYSBtb3JlIHBl cm1hbmVudCBpZGVudGlmaWVyIGlzIG5lZWRlZC4NCj4gPj4NCj4gPj4gVG8gUmFqIC0gaXMgTFRF IGNvbnNpZGVyaW5nIG90aGVyIGtpbmRzIG9mIGlkZW50aWZpZXJzIGZvciBhY2Nlc3MgY29udHJv bA0KPiA+PiAob3RoZXIgdGhhbiBJTVNJKSBmb3IgdmVoaWN1bGFyIGVudmlyb25tZW50cywgbGlr ZSBWMlg/DQo+ID4+DQo+ID4+IEFsZXgNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+DQo+ID4+PiBS ZWdhcmRzLA0KPiA+Pj4NCj4gPj4+IEJlaGNldA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBZb3Vy cywNCj4gPj4+Pg0KPiA+Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+ IC0gSm91bmkgJiBEYXBlbmcNCj4gPj4+Pj4NCj4gPj4+Pj4gNC8xLzIwMTUsIDg6MDIgQU0sIEpv dW5pIEtvcmhvbmVuIGtpcmpvaXR0aToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRm9s a3MsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhpcyBlbWFpbHMgc3RhcnRzIGEgdHdvIHdlZWsgY2Fs bCBmb3IgdGhlIEktRA0KPiA+Pj4+Pj4gICAgICBkcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHMt MDENCj4gPj4+Pj4+IHRvIGNvbmZpcm0gdGhlIGFhZG9wdGlvbiBzIGEgRE1NIFdHIGRvY3VtZW50 LiBUaGUgY2FsbCBlbmRzIEFwcmlsIDE1dGgNCj4gPj4+Pj4+IEVPQiBQU1QuDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gRXhwcmVzcyB5b3VyIHN1cHBvcnQgb3Igb3Bwb3NpdGlvbiB0byB0aGUgbWFpbGlu ZyBsaXN0LiBEdXJpbmcgdGhlDQo+ID4+Pj4+PiBJRVRGOTIgbWVldGluZyB3ZSBnb3QgNyB2b2lj ZXMgZm9yIHRoZSBhZG9wdGlvbiBzbyBhdCBsZWFzdCB0aGUgc2FtZQ0KPiA+Pj4+Pj4gYW1vdW50 IHN1cHBvcnRpbmcgZW1haWxzIHNob3VsZCBiZSBleHBlY3RlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiAtIEpvdW5pICYgRGFwZW5nDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IGRt bSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gZG1tQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPiA+Pj4+IGRtbUBpZXRmLm9yZw0KPiA+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4NCj4gPg0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRtbSBtYWlsaW5nIGxpc3QNCj4g ZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t DQo= From nobody Fri Apr 24 09:36:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B01ACC83 for ; Fri, 24 Apr 2015 09:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 XDaAOx3fYU_N for ; Fri, 24 Apr 2015 09:36:15 -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 D5DB21A1BD2 for ; Fri, 24 Apr 2015 09:36:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3OGa7mx013908; Fri, 24 Apr 2015 18:36:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C23EA2034C7; Fri, 24 Apr 2015 18:37:35 +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 B298A202091; Fri, 24 Apr 2015 18:37:35 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3OGZqkk025846; Fri, 24 Apr 2015 18:36:07 +0200 Message-ID: <553A70E8.2010304@gmail.com> Date: Fri, 24 Apr 2015 18:35:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Jouni Korhonen , "dmm@ietf.org" References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <5537D364.1010906@gmail.com> <2134F8430051B64F815C691A62D9831832E4FB26@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4FB26@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:36:19 -0000 Hi Fred, Le 22/04/2015 19:22, Templin, Fred L a 閏rit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, April 22, 2015 9:59 AM >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org >> Subject: Re: [DMM] Mobility Exposure and Selection WT call >> >> Le 22/04/2015 18:51, Templin, Fred L a 閏rit : >>> Hi Alex, >>> >>>> -----Original Message----- >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>>> Sent: Tuesday, April 21, 2015 12:42 PM >>>> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org >>>> Subject: Re: [DMM] Mobility Exposure and Selection WT call >>>> >>>> Le 31/03/2015 00:42, Templin, Fred L a 閏rit : >>>>> Hi Alex, >>>>> >>>>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>>>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 >>>>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility >>>>>> Exposure and Selection WT call >>>>>> >>>>>> Le 26/03/2015 13:17, Jouni Korhonen a 閏rit : >>>>>>> Alex, >>>>>>> >>>>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>>>> I thought by "fixed" you meant it stays the same wherever the >>>>>>>>> Host goes (something like the Home Address). >>>>>>>> >>>>>>>> Alper - I think a LL address can also be qualified as 'fixed' - >>>>>>>> it never changes. >>>>>>> >>>>>>> Does LL here mean link-local or link-layer? If it is the former >>>>>>> one, then the above assertion is not correct. >>>>>> >>>>>> Link-local. >>>>>> >>>>>> And you seem to say a link-local address is not fixed? I think >>>>>> link-local addresses _are_ fixed set in stone. They are formed >>>>>> locally without need of help from router. >>>>> >>>>> AERO provides a fixed link-local address that is formed from a >>>>> prefix received by DHCPv6 Prefix Delegation (PD). >>>> >>>> Fred - but why should this ll prefix be provided by DHCP? Is it of >>>> variable value? Or is the link-local constant all the time? (in which >>>> case it could be hardcoded everywhere). >>> >>> DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO >>> Client (e.g., 2001:db8:1:2::/64). The Client then constructs an >>> AERO link-local address from the prefix as fe80::2001:db8:1:2 >>> (i.e., it embeds the 64-bit prefix from the prefix delegation in >>> the 64-bit interface identifier of an IPv6 link-local address). >> >> Fred, that looks weird. Never saw a prefix to be used as an Interface >> Identifier. > > It is specified in the AERO document and also cited in RFC7421. There are > lots of weird "address within address" encapsulations in common use > within the IPv6 interface identifier (e.g., ISATAP address, etc.) and > this I think is in some ways less weird than some of the others. Ok. >> I guess this breaks the DHCP prefix delegation specification. > > Not at all; I have running code that uses unmodified public domain > DHCPv6 clients and servers. On the server side, I was using ISC > DHCP but have recently moved over to a great new server package > called Kea (also from ISC). > >> Why does not the DHCPv6 server assign a link-local address altogether >> (rather than assigning a prefix, to be used as an IID). > > Because the prefix length may be different than /64; hence, the > Client needs to receive the prefix in a DHCPv6 IA_PD option. What if DHCP had an option to provide an Interface ID (instead of Prefix Delegation)? Wouldnt that be more appropriate to form a link-local address with that Interface ID? Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> Alex >> >>> Once the prefix delegation and AERO address configuration >>> are done, they stay fixes as long as the Client remains >>> associated with the same AERO link. >>> >>>>> Once the AERO Client is given a PD (either IPv6 or IPv4) it can form >>>>> an AERO link-local address that stays the same wherever the Client >>>>> moves and with no need to perform Duplicate Address Detection (DAD). >>>>> It makes IPv6 ND simple and seamless. >>>> >>>> Is that prefix fe80::/10? >>> >>> No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link >>> has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which >>> longer global IPv6 prefixes are delegated to each Client. The Client then >>> gets to keep and continually use its prefix delegation as long as it stays >>> associated with the same AERO link. >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> - Jouni >>>>>>> >>>>>>>> >>>>>>>> I think it's hard to disagree with that, no? >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> >>>>>>>>> So, I guess, I should have referred to the "nomadic" address >>>>>>>>> to mean the one that is constant, wherever the Host goes. >>>>>>>>> >>>>>>>>> As such, my suggestion is that a "nomadic" address can never >>>>>>>>> be an RFC7217 address. >>>>>>>>> >>>>>>>>> In practice that would mean that if you configure an address >>>>>>>>> to be "nomadic" you must also tell the kernel to not run >>>>>>>>> RFC7217 on it. >>>>>>>>> >>>>>>>>> But ok, one might think that these two aspects ("nomadic" and >>>>>>>>> RFC7217) are orthogonal at this point in time. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't know if it makes sense to request a fixed and >>>>>>>>>> random-based IP address. But if someone does it, it works. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or >>>>>>>>>>>>> registered (RFC 6775). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Orthogonal. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> E.g. a nomadic address could never be a link-local >>>>>>>>>>>>> address. >>>>>>>>>>>>> >>>>>>>>>>>>>> #2. Describe how IP address type information is >>>>>>>>>>>>>> conveyed from network to MN. >>>>>>>>>>>>> >>>>>>>>>>>>> If one designs a protocol to convey address type >>>>>>>>>>>>> information from the network to the end node, then >>>>>>>>>>>>> one could also add the other types mentioned above. >>>>>>>>>>>>> >>>>>>>>>>>>> SLAAC could never 'convey' the address type to the >>>>>>>>>>>>> end-node, because SLAAC is an operation happening >>>>>>>>>>>>> with as heavy weight from the Server (router) as from >>>>>>>>>>>>> the Client (Host): the Router decides the prefix but >>>>>>>>>>>>> the Client decides the Interface ID. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Still, the network can convey the type of IP address to >>>>>>>>>>>> the host. Also, one can imagine augmenting Router >>>>>>>>>>>> Solicitation to let the host convey its requested >>>>>>>>>>>> type. >>>>>>>>>>> >>>>>>>>>>> I agree. >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Address Registration Option of 6lo and BTLE would >>>>>>>>>>>>> have the Host conveying this information to the >>>>>>>>>>>>> Router (and not vice-versa). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK. >>>>>>>>>>>> >>>>>>>>>>>> Alper >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> >>>>>>>>>>>>> Alex >>>>>>>>>>>>> >>>>>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility >>>>>>>>>>>>>> as the baseline for item#1 (the API). A revision of >>>>>>>>>>>>>> the draft will also include a new section to cover >>>>>>>>>>>>>> backward compatibility (Danny will provide the >>>>>>>>>>>>>> draft text). Comments on the draft are welcome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The next call will be about items #2/#3 (IP >>>>>>>>>>>>>> address configuration enhancements associated with >>>>>>>>>>>>>> the API). We intend to schedule that one in about 2 >>>>>>>>>>>>>> weeks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Alper >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Folks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See below for the Webex details. Remember, the >>>>>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't >>>>>>>>>>>>>>> forget to read the documents in the reading list >>>>>>>>>>>>>>> prior to the call. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>>>>>> the discussions: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. >>>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>>>>>> 3. >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>>>>>> 5. >>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> Alper >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* >>>>>>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time >>>>>>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Join WebEx meeting* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> Meeting number:641 085 326 >>>>>>>>>>>>>>>> Meeting password:dmm1911 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll >>>>>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* >>>>>>>>>>>>>>>> Call-in toll number (US/Canada) Access code: >>>>>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> Add this meeting >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> to your calendar. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can't join the meeting? Contact support. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx >>>>>>>>>>>>>>>> service allows audio and other information sent >>>>>>>>>>>>>>>> during the session to be recorded, which may be >>>>>>>>>>>>>>>> discoverable in a legal matter. By joining this >>>>>>>>>>>>>>>> session, you automatically consent to such >>>>>>>>>>>>>>>> recordings. If you do not consent to being >>>>>>>>>>>>>>>> recorded, discuss your concerns with the host >>>>>>>>>>>>>>>> or do not join the session. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Poll is closed, and majority selected the >>>>>>>>>>>>>>>> following date for the call: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please mark your calendars. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In this call, we'll aim making progress on the >>>>>>>>>>>>>>>> I-D for item#1 (an API for source address >>>>>>>>>>>>>>>> selection). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Attendees _shall read _the following material >>>>>>>>>>>>>>>> before the call so that we can directly jump to >>>>>>>>>>>>>>>> the discussions: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. >>>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>>>>>>>> 3. >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>>>>>>>> 5. >>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> Alper >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Folks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please mark your availability on the >>>>>>>>>>>>>>>>> following doodle for our next DMM WG Mobility >>>>>>>>>>>>>>>>> Exposure and Selection WT call: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Register your availability no later than the >>>>>>>>>>>>>>>>> end of Monday (Jan 26). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Alper >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ dmm >>>>>>>>>>>>>> mailing list dmm@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ dmm >>>>>>>>>>>>> mailing list dmm@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ dmm mailing >>>>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ dmm mailing >>>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm mailing list >>>>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>> >>> >>> >>> >> > > > From nobody Fri Apr 24 12:22:26 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5875C1A1A70 for ; Fri, 24 Apr 2015 12:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 c7NcQGBEA35A for ; Fri, 24 Apr 2015 12:22:22 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::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 027781B3868 for ; Fri, 24 Apr 2015 12:22:21 -0700 (PDT) Received: by labbd9 with SMTP id bd9so42280836lab.2 for ; Fri, 24 Apr 2015 12:22:19 -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-type:content-transfer-encoding; bh=wYxg+q0hDm1eGMCQvwWiNt6erg0BmxGDnoRyOmUC8WQ=; b=GwsX7na5xREL0/HI6adcmaswZqdu8Ba4WeV2he5t2pBdWvvNKjEW/shpBJaNgGxsBv hjVJkee/n5rdljbsFKRxUcvONZOtD6veLsNKCBds6ODDPW1nrZOQHoKSftq9U/Yl/+T6 23T8O++ZiwxIAxqLkuwW+HvtdrX38Kx7p5MwPDa81Ku7RxLOQAtHWpNbJvBTx7kBDtUs 1BpIU7nuCS+kePZ02KvKv9aWYzrMEsBzt49rHq0Dr57uKOcFsj/5y2VTCceCyaOB/xme 1Wyd5Wi/psL0+8MYyv5RLKXlEiTfTw/mTgmOPeQ7M2rpHLTziq+LhwRlwdfH/SbRTpXC nRFQ== MIME-Version: 1.0 X-Received: by 10.112.35.230 with SMTP id l6mr8114980lbj.5.1429903339555; Fri, 24 Apr 2015 12:22:19 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Fri, 24 Apr 2015 12:22:19 -0700 (PDT) In-Reply-To: <5539FE54.2030103@gmail.com> References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> <5539FE54.2030103@gmail.com> Date: Fri, 24 Apr 2015 14:22:19 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2015 19:22:24 -0000 I am still not convinced. At home I have LTE. LTE can be 3G if it is somewhat degraded and 3G is also available, so no reason for inter technology handoff. I am also concerned on some other MN ids proposed like RFid, what is the assumption there? Is it that the sensor node will have Mobile IP client? To that I say, give me a break. Behcet Behcet On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu wrote: > Le 23/04/2015 19:11, Behcet Sarikaya a =C3=A9crit : >> >> On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu >> wrote: >>> >>> Le 22/04/2015 18:06, Behcet Sarikaya a =C3=A9crit : >>>> >>>> >>>> Hi Alex, >>>> >>>> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu >>>> wrote: >>>>> >>>>> >>>>> Le 16/04/2015 06:58, Jouni Korhonen a =C3=A9crit : >>>>>> >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> The adoption call for this I-D has ended. There is a clear concensus >>>>>> to >>>>>> adopt the I-D as a working group item. >>>>> >>>>> >>>>> >>>>> >>>>> I support its adoption. >>>>> >>>>> We have been working with an identifier specific to automobiles to us= e >>>>> to >>>>> realize access control. Identifying an entire set of IP nodes deploy= ed >>>>> in a >>>>> vehicle is different than identifying an end-user like address@realm. >>>>> >>>>> We looked for such an identifier and believe the VIN (Vehicle >>>>> Identification >>>>> Number) be a good candidate. >>>>> >>>>> One would consider using one type, like type 40, to encode the VIN or >>>>> parts >>>>> of it, into an MN-ID. >>>>> >>>>> The questions to the group are the following: >>>>> - is VIN considered private information? (in deployments it is privat= e >>>>> to a certain extent, but publicly avaliable to cameras or in publ= ic >>>>> databases to another extent). >>>>> - is the MN-ID type 40 ok for it. >>>>> - is one type sufficient or should there be subtypes. >>>> >>>> >>>> >>>> What is your model here in providing Internet access to the car? >>>> As you may know, operators in US are deploying systems that connect >>>> the car to their LTE network upstream and downstream is the passengers >>>> in the car that access over Wi-Fi. >>>> With LTE, you get mobility support which is based on fixed anchoring. >>>> I cc'ed to Raj who works on these types of technologies. >>>> The ID there is the IMSI. I don't think vin is used. >>> >>> >>> >>> The model of Internet access to the cars for cars currently on market i= n >>> Europe is the same - the LTE technology is used, using the IMSI as an >>> identifier. However, that does not use MN-ID, is only IPv4, is not WiF= i >>> and >>> does not resist to cellular generation upgrades to 5G and beyond. >> >> >> I don't understand the handover scenario. I think you are mixing the >> car and the passengers in the car. >> LTE is available on a large geography, why should you handover the >> upstream traffic to Wi-Fi? > > > When the car arrives home it connects to the WiFi available in home, thus > handing over from LTE. This is a sold use-case at e.g. Tesla. The WiFi > hotspot can be the one deployed in-house, in-garage, or the WiFi offered = by > the electrical recharging stations. > > Other manufacturers propose scenarios in which car's WiFi antenna switche= s > from being an in-car hotspot to being a Client to outside wifi. > > Some consider 802.11p (wifi for vehicles) to be deployed along highways a= nd > cars to perform handovers between these 802.11p access points. > > Next time on highway scan for WiFi - one is surprised by the number of > hotspots driving around, even though often they use portals. > > There are many commercially considered scenarios involving WiFi handovers > for cars. > > Alex > > >> >> Behcet >>> >>> >>> Newer models will feature IPv6 in addition to IPv4, WiFi handover from >>> LTE >>> to house's hotspot, continuous sessions, and over-the-air software upda= te >>> for cheap upgradeability to future generation 5G and beyond. >>> >>> In this context it is hard to imagine IMSI will be there for a long tim= e >>> in >>> a given car, and a more permanent identifier is needed. >>> >>> To Raj - is LTE considering other kinds of identifiers for access contr= ol >>> (other than IMSI) for vehicular environments, like V2X? >>> >>> Alex >>> >>> >>> >>>> >>>> Regards, >>>> >>>> Behcet >>>>> >>>>> >>>>> >>>>> Yours, >>>>> >>>>> Alex >>>>> >>>>> >>>>>> >>>>>> - Jouni & Dapeng >>>>>> >>>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> This emails starts a two week call for the I-D >>>>>>> draft-perkins-dmm-4283mnids-01 >>>>>>> to confirm the aadoption s a DMM WG document. The call ends April >>>>>>> 15th >>>>>>> EOB PST. >>>>>>> >>>>>>> Express your support or opposition to the mailing list. During the >>>>>>> IETF92 meeting we got 7 voices for the adoption so at least the sam= e >>>>>>> amount supporting emails should be expected. >>>>>>> >>>>>>> - Jouni & Dapeng >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>>> >>>> >>>> >>> >>> >> >> > > From nobody Fri Apr 24 12:30:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD51B3185 for ; Fri, 24 Apr 2015 12:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 ulCzNNw9cFIs for ; Fri, 24 Apr 2015 12:30:57 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010: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 54D531B29E2 for ; Fri, 24 Apr 2015 12:30:55 -0700 (PDT) Received: by laat2 with SMTP id t2so42407177laa.1 for ; Fri, 24 Apr 2015 12:30:53 -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-type:content-transfer-encoding; bh=kUwXrF9p/8UMBBltTFYP+vO7GTSvGatMPBTnS67YAk8=; b=A4PS3/fs07UxeXkHE9RyGuVkGT43/NqVkRkbjJUPYY0KLzTW4GZcQzMgwDvgItp04S Ko44QlWcam+VInxoFiauRj/gV5QyvOfJ7Dtpsxr32vbZb2RcpR1LQb8s7+/4u+RTUpCN pc00Pl7qTd6PQGPWPgMPa6kT142zpSE+C3ksvXeVaWPDylvNq0oeruvSETjpHYHFTcfv x4h96aB3aI7F2VMNpVm6MyanBF9b4fGKas0gCjXfj+u+NY5LSXwW459BJj+m9Ha7PV+E CGH00I/4vcoc/IJ4ULTF5y8Q+GIZaBvYMcAI95eC7rxhLVsjCZImKq7R3Q1BRYHmsTHs qPLA== MIME-Version: 1.0 X-Received: by 10.112.181.68 with SMTP id du4mr7931662lbc.11.1429903853831; Fri, 24 Apr 2015 12:30:53 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Fri, 24 Apr 2015 12:30:53 -0700 (PDT) In-Reply-To: <5539FE54.2030103@gmail.com> References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> <5539FE54.2030103@gmail.com> Date: Fri, 24 Apr 2015 14:30:53 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2015 19:30:58 -0000 On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu wrote: > Le 23/04/2015 19:11, Behcet Sarikaya a =C3=A9crit : >> >> On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu >> wrote: >>> >>> Le 22/04/2015 18:06, Behcet Sarikaya a =C3=A9crit : >>>> >>>> >>>> Hi Alex, >>>> >>>> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu >>>> wrote: >>>>> >>>>> >>>>> Le 16/04/2015 06:58, Jouni Korhonen a =C3=A9crit : >>>>>> >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> The adoption call for this I-D has ended. There is a clear concensus >>>>>> to >>>>>> adopt the I-D as a working group item. >>>>> >>>>> >>>>> >>>>> >>>>> I support its adoption. >>>>> >>>>> We have been working with an identifier specific to automobiles to us= e >>>>> to >>>>> realize access control. Identifying an entire set of IP nodes deploy= ed >>>>> in a >>>>> vehicle is different than identifying an end-user like address@realm. >>>>> >>>>> We looked for such an identifier and believe the VIN (Vehicle >>>>> Identification >>>>> Number) be a good candidate. >>>>> >>>>> One would consider using one type, like type 40, to encode the VIN or >>>>> parts >>>>> of it, into an MN-ID. >>>>> >>>>> The questions to the group are the following: >>>>> - is VIN considered private information? (in deployments it is privat= e >>>>> to a certain extent, but publicly avaliable to cameras or in publ= ic >>>>> databases to another extent). >>>>> - is the MN-ID type 40 ok for it. >>>>> - is one type sufficient or should there be subtypes. >>>> >>>> >>>> >>>> What is your model here in providing Internet access to the car? >>>> As you may know, operators in US are deploying systems that connect >>>> the car to their LTE network upstream and downstream is the passengers >>>> in the car that access over Wi-Fi. >>>> With LTE, you get mobility support which is based on fixed anchoring. >>>> I cc'ed to Raj who works on these types of technologies. >>>> The ID there is the IMSI. I don't think vin is used. >>> >>> >>> >>> The model of Internet access to the cars for cars currently on market i= n >>> Europe is the same - the LTE technology is used, using the IMSI as an >>> identifier. However, that does not use MN-ID, is only IPv4, is not WiF= i >>> and >>> does not resist to cellular generation upgrades to 5G and beyond. >> >> >> I don't understand the handover scenario. I think you are mixing the >> car and the passengers in the car. >> LTE is available on a large geography, why should you handover the >> upstream traffic to Wi-Fi? > > > When the car arrives home it connects to the WiFi available in home, thus > handing over from LTE. This is a sold use-case at e.g. Tesla. The WiFi > hotspot can be the one deployed in-house, in-garage, or the WiFi offered = by > the electrical recharging stations. > Even if the is the case then 3GPP developed a lot of things on accessing non-3GPP networks like Wi-Fi. I think line-id is used instead of IMSI? Behcet > Other manufacturers propose scenarios in which car's WiFi antenna switche= s > from being an in-car hotspot to being a Client to outside wifi. > > Some consider 802.11p (wifi for vehicles) to be deployed along highways a= nd > cars to perform handovers between these 802.11p access points. > > Next time on highway scan for WiFi - one is surprised by the number of > hotspots driving around, even though often they use portals. > > There are many commercially considered scenarios involving WiFi handovers > for cars. > > Alex > > >> >> Behcet >>> >>> >>> Newer models will feature IPv6 in addition to IPv4, WiFi handover from >>> LTE >>> to house's hotspot, continuous sessions, and over-the-air software upda= te >>> for cheap upgradeability to future generation 5G and beyond. >>> >>> In this context it is hard to imagine IMSI will be there for a long tim= e >>> in >>> a given car, and a more permanent identifier is needed. >>> >>> To Raj - is LTE considering other kinds of identifiers for access contr= ol >>> (other than IMSI) for vehicular environments, like V2X? >>> >>> Alex >>> >>> >>> >>>> >>>> Regards, >>>> >>>> Behcet >>>>> >>>>> >>>>> >>>>> Yours, >>>>> >>>>> Alex >>>>> >>>>> >>>>>> >>>>>> - Jouni & Dapeng >>>>>> >>>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> This emails starts a two week call for the I-D >>>>>>> draft-perkins-dmm-4283mnids-01 >>>>>>> to confirm the aadoption s a DMM WG document. The call ends April >>>>>>> 15th >>>>>>> EOB PST. >>>>>>> >>>>>>> Express your support or opposition to the mailing list. During the >>>>>>> IETF92 meeting we got 7 voices for the adoption so at least the sam= e >>>>>>> amount supporting emails should be expected. >>>>>>> >>>>>>> - Jouni & Dapeng >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>>> >>>> >>>> >>> >>> >> >> > > From nobody Fri Apr 24 12:35:08 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3651B387C for ; Fri, 24 Apr 2015 12:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 C7wzssVRRWRT for ; Fri, 24 Apr 2015 12:35:02 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCD91B3877 for ; Fri, 24 Apr 2015 12:35:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3OJZ10u016701; Fri, 24 Apr 2015 14:35:01 -0500 Received: from XCH-BLV-403.nw.nos.boeing.com (xch-blv-403.nw.nos.boeing.com [130.247.25.62]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3OJYtKT016514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Apr 2015 14:34:55 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.184]) with mapi id 14.03.0235.001; Fri, 24 Apr 2015 12:34:54 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgIAAeiAA//+OQbCAA4/fAP//umQg Date: Fri, 24 Apr 2015 19:34:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5180C@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <5537D364.1010906@gmail.com> <2134F8430051B64F815C691A62D9831832E4FB26@XCH-BLV-504.nw.nos.boeing.com> <553A70E8.2010304@gmail.com> In-Reply-To: <553A70E8.2010304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 19:35:06 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, April 24, 2015 9:36 AM > To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 > Hi Fred, >=20 > Le 22/04/2015 19:22, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Wednesday, April 22, 2015 9:59 AM > >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > >> Subject: Re: [DMM] Mobility Exposure and Selection WT call > >> > >> Le 22/04/2015 18:51, Templin, Fred L a =E9crit : > >>> Hi Alex, > >>> > >>>> -----Original Message----- > >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >>>> Sent: Tuesday, April 21, 2015 12:42 PM > >>>> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > >>>> Subject: Re: [DMM] Mobility Exposure and Selection WT call > >>>> > >>>> Le 31/03/2015 00:42, Templin, Fred L a =E9crit : > >>>>> Hi Alex, > >>>>> > >>>>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] > >>>>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:0= 3 > >>>>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility > >>>>>> Exposure and Selection WT call > >>>>>> > >>>>>> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : > >>>>>>> Alex, > >>>>>>> > >>>>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > >>>>>>> > >>>>>>> [snip] > >>>>>>> > >>>>>>>>> I thought by "fixed" you meant it stays the same wherever the > >>>>>>>>> Host goes (something like the Home Address). > >>>>>>>> > >>>>>>>> Alper - I think a LL address can also be qualified as 'fixed' - > >>>>>>>> it never changes. > >>>>>>> > >>>>>>> Does LL here mean link-local or link-layer? If it is the former > >>>>>>> one, then the above assertion is not correct. > >>>>>> > >>>>>> Link-local. > >>>>>> > >>>>>> And you seem to say a link-local address is not fixed? I think > >>>>>> link-local addresses _are_ fixed set in stone. They are formed > >>>>>> locally without need of help from router. > >>>>> > >>>>> AERO provides a fixed link-local address that is formed from a > >>>>> prefix received by DHCPv6 Prefix Delegation (PD). > >>>> > >>>> Fred - but why should this ll prefix be provided by DHCP? Is it of > >>>> variable value? Or is the link-local constant all the time? (in whi= ch > >>>> case it could be hardcoded everywhere). > >>> > >>> DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO > >>> Client (e.g., 2001:db8:1:2::/64). The Client then constructs an > >>> AERO link-local address from the prefix as fe80::2001:db8:1:2 > >>> (i.e., it embeds the 64-bit prefix from the prefix delegation in > >>> the 64-bit interface identifier of an IPv6 link-local address). > >> > >> Fred, that looks weird. Never saw a prefix to be used as an Interface > >> Identifier. > > > > It is specified in the AERO document and also cited in RFC7421. There a= re > > lots of weird "address within address" encapsulations in common use > > within the IPv6 interface identifier (e.g., ISATAP address, etc.) and > > this I think is in some ways less weird than some of the others. >=20 > Ok. >=20 > >> I guess this breaks the DHCP prefix delegation specification. > > > > Not at all; I have running code that uses unmodified public domain > > DHCPv6 clients and servers. On the server side, I was using ISC > > DHCP but have recently moved over to a great new server package > > called Kea (also from ISC). > > > >> Why does not the DHCPv6 server assign a link-local address altogether > >> (rather than assigning a prefix, to be used as an IID). > > > > Because the prefix length may be different than /64; hence, the > > Client needs to receive the prefix in a DHCPv6 IA_PD option. >=20 > What if DHCP had an option to provide an Interface ID (instead of Prefix > Delegation)? Wouldnt that be more appropriate to form a link-local > address with that Interface ID? The great thing about the AERO address is that it can be used for both IPv6 ND messaging and route determination. The AERO address is guaranteed to be unique, so it can be used as the source address of IPv6 ND messages with no need for DAD. It can also be used for route determination without consulting a routing table. Plus, we don't need any special options since DHCPv6 PD works fine with no client or server modifications. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Alex > >> > >>> Once the prefix delegation and AERO address configuration > >>> are done, they stay fixes as long as the Client remains > >>> associated with the same AERO link. > >>> > >>>>> Once the AERO Client is given a PD (either IPv6 or IPv4) it can for= m > >>>>> an AERO link-local address that stays the same wherever the Client > >>>>> moves and with no need to perform Duplicate Address Detection (DAD)= . > >>>>> It makes IPv6 ND simple and seamless. > >>>> > >>>> Is that prefix fe80::/10? > >>> > >>> No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO= link > >>> has an associated AERO Service Prefix (e.g., 2001:db8::/32) from whic= h > >>> longer global IPv6 prefixes are delegated to each Client. The Client = then > >>> gets to keep and continually use its prefix delegation as long as it = stays > >>> associated with the same AERO link. > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> Alex > >>>> > >>>>> > >>>>> Thanks - Fred fred.l.templin@boeing.com > >>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> - Jouni > >>>>>>> > >>>>>>>> > >>>>>>>> I think it's hard to disagree with that, no? > >>>>>>>> > >>>>>>>> Alex > >>>>>>>> > >>>>>>>>> > >>>>>>>>> So, I guess, I should have referred to the "nomadic" address > >>>>>>>>> to mean the one that is constant, wherever the Host goes. > >>>>>>>>> > >>>>>>>>> As such, my suggestion is that a "nomadic" address can never > >>>>>>>>> be an RFC7217 address. > >>>>>>>>> > >>>>>>>>> In practice that would mean that if you configure an address > >>>>>>>>> to be "nomadic" you must also tell the kernel to not run > >>>>>>>>> RFC7217 on it. > >>>>>>>>> > >>>>>>>>> But ok, one might think that these two aspects ("nomadic" and > >>>>>>>>> RFC7217) are orthogonal at this point in time. > >>>>>>>>> > >>>>>>>>> Alex > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I don't know if it makes sense to request a fixed and > >>>>>>>>>> random-based IP address. But if someone does it, it works. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Alper > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or > >>>>>>>>>>>>> registered (RFC 6775). > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Orthogonal. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> E.g. a nomadic address could never be a link-local > >>>>>>>>>>>>> address. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> #2. Describe how IP address type information is > >>>>>>>>>>>>>> conveyed from network to MN. > >>>>>>>>>>>>> > >>>>>>>>>>>>> If one designs a protocol to convey address type > >>>>>>>>>>>>> information from the network to the end node, then > >>>>>>>>>>>>> one could also add the other types mentioned above. > >>>>>>>>>>>>> > >>>>>>>>>>>>> SLAAC could never 'convey' the address type to the > >>>>>>>>>>>>> end-node, because SLAAC is an operation happening > >>>>>>>>>>>>> with as heavy weight from the Server (router) as from > >>>>>>>>>>>>> the Client (Host): the Router decides the prefix but > >>>>>>>>>>>>> the Client decides the Interface ID. > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Still, the network can convey the type of IP address to > >>>>>>>>>>>> the host. Also, one can imagine augmenting Router > >>>>>>>>>>>> Solicitation to let the host convey its requested > >>>>>>>>>>>> type. > >>>>>>>>>>> > >>>>>>>>>>> I agree. > >>>>>>>>>>> > >>>>>>>>>>> Alex > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Address Registration Option of 6lo and BTLE would > >>>>>>>>>>>>> have the Host conveying this information to the > >>>>>>>>>>>>> Router (and not vice-versa). > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> OK. > >>>>>>>>>>>> > >>>>>>>>>>>> Alper > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Yours, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alex > >>>>>>>>>>>>> > >>>>>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility > >>>>>>>>>>>>>> as the baseline for item#1 (the API). A revision of > >>>>>>>>>>>>>> the draft will also include a new section to cover > >>>>>>>>>>>>>> backward compatibility (Danny will provide the > >>>>>>>>>>>>>> draft text). Comments on the draft are welcome. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The next call will be about items #2/#3 (IP > >>>>>>>>>>>>>> address configuration enhancements associated with > >>>>>>>>>>>>>> the API). We intend to schedule that one in about 2 > >>>>>>>>>>>>>> weeks. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Alper > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Folks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> See below for the Webex details. Remember, the > >>>>>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't > >>>>>>>>>>>>>>> forget to read the documents in the reading list > >>>>>>>>>>>>>>> prior to the call. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>>>>>> the discussions: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 1. > >>>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-= 4.pdf > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>>>>>> 3. > >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondeman= d-mobility/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>>>>>> 5. > >>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> Alper > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT* > >>>>>>>>>>>>>>> Tuesday 10 February 2015 16:00 | Europe Time > >>>>>>>>>>>>>>> (Paris, GMT+01:00) | 1 hr 30 min > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> *Join WebEx meeting* > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> Meeting number:641 085 326 > >>>>>>>>>>>>>>>> Meeting password:dmm1911 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll > >>>>>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208* > >>>>>>>>>>>>>>>> Call-in toll number (US/Canada) Access code: > >>>>>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> Add this meeting > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> to your calendar. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Can't join the meeting? Contact support. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx > >>>>>>>>>>>>>>>> service allows audio and other information sent > >>>>>>>>>>>>>>>> during the session to be recorded, which may be > >>>>>>>>>>>>>>>> discoverable in a legal matter. By joining this > >>>>>>>>>>>>>>>> session, you automatically consent to such > >>>>>>>>>>>>>>>> recordings. If you do not consent to being > >>>>>>>>>>>>>>>> recorded, discuss your concerns with the host > >>>>>>>>>>>>>>>> or do not join the session. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Poll is closed, and majority selected the > >>>>>>>>>>>>>>>> following date for the call: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please mark your calendars. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> In this call, we'll aim making progress on the > >>>>>>>>>>>>>>>> I-D for item#1 (an API for source address > >>>>>>>>>>>>>>>> selection). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Attendees _shall read _the following material > >>>>>>>>>>>>>>>> before the call so that we can directly jump to > >>>>>>>>>>>>>>>> the discussions: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 1. > >>>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-= 4.pdf > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>>>>>>>> 3. > >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondeman= d-mobility/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>>>>>>>> 5. > >>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> Alper > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Folks, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Please mark your availability on the > >>>>>>>>>>>>>>>>> following doodle for our next DMM WG Mobility > >>>>>>>>>>>>>>>>> Exposure and Selection WT call: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Register your availability no later than the > >>>>>>>>>>>>>>>>> end of Monday (Jan 26). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Alper > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ dmm > >>>>>>>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ dmm > >>>>>>>>>>>>> mailing list dmm@ietf.org > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ dmm mailing > >>>>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ dmm mailing > >>>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ dmm mailing list > >>>>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > > > >=20 From nobody Sat Apr 25 05:14:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CF61A1A00 for ; Sat, 25 Apr 2015 05:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 vyUQNKwuaxUS for ; Sat, 25 Apr 2015 05:14:19 -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 265181A19F6 for ; Sat, 25 Apr 2015 05:14:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3PCEF2I024710; Sat, 25 Apr 2015 14:14:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 026C7200FB9; Sat, 25 Apr 2015 14:15:14 +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 E6B05200F3E; Sat, 25 Apr 2015 14:15:13 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.67]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3PCDQYq026131; Sat, 25 Apr 2015 14:13:44 +0200 Message-ID: <553B84E6.8050001@gmail.com> Date: Sat, 25 Apr 2015 14:13:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> <5539FE54.2030103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:14:21 -0000 Le 24/04/2015 21:30, Behcet Sarikaya a 茅crit : [...] >> When the car arrives home it connects to the WiFi available in >> home, thus handing over from LTE. This is a sold use-case at e.g. >> Tesla. The WiFi hotspot can be the one deployed in-house, >> in-garage, or the WiFi offered by the electrical recharging >> stations. >> > > Even if the is the case then 3GPP developed a lot of things on > accessing non-3GPP networks like Wi-Fi. I think line-id is used > instead of IMSI? I dont know. Maybe line-id should be suggested as an MN-ID as well. But I can tell that vehicles will not always use the 3GPP-defined means to connect to WiFi. And the WiFi operator is different than the 3GPP operator, and thus a different MN-ID form. The MN-ID that I consider in vehicles is the one used for Mobile IP. 3GPP deployments I confront with dont use Mobile IP. Mobile IP offers a mobility solution completely independent of the access networks. Alex > > Behcet >> Other manufacturers propose scenarios in which car's WiFi antenna >> switches from being an in-car hotspot to being a Client to outside >> wifi. >> >> Some consider 802.11p (wifi for vehicles) to be deployed along >> highways and cars to perform handovers between these 802.11p >> access points. >> >> Next time on highway scan for WiFi - one is surprised by the >> number of hotspots driving around, even though often they use >> portals. >> >> There are many commercially considered scenarios involving WiFi >> handovers for cars. >> >> Alex >> >> >>> >>> Behcet >>>> >>>> >>>> Newer models will feature IPv6 in addition to IPv4, WiFi >>>> handover from LTE to house's hotspot, continuous sessions, and >>>> over-the-air software update for cheap upgradeability to >>>> future generation 5G and beyond. >>>> >>>> In this context it is hard to imagine IMSI will be there for a >>>> long time in a given car, and a more permanent identifier is >>>> needed. >>>> >>>> To Raj - is LTE considering other kinds of identifiers for >>>> access control (other than IMSI) for vehicular environments, >>>> like V2X? >>>> >>>> Alex >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>>> >>>>>>> - Jouni & Dapeng >>>>>>> >>>>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> This emails starts a two week call for the I-D >>>>>>>> draft-perkins-dmm-4283mnids-01 to confirm the >>>>>>>> aadoption s a DMM WG document. The call ends April 15th >>>>>>>> EOB PST. >>>>>>>> >>>>>>>> Express your support or opposition to the mailing >>>>>>>> list. During the IETF92 meeting we got 7 voices for >>>>>>>> the adoption so at least the same amount supporting >>>>>>>> emails should be expected. >>>>>>>> >>>>>>>> - Jouni & Dapeng >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm >>>>>>> mailing list dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm >>>>>> mailing list dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From nobody Sat Apr 25 05:18:01 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686A1A1A00 for ; Sat, 25 Apr 2015 05:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 00H8oErdj-VI for ; Sat, 25 Apr 2015 05:17:57 -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 027D21A19F6 for ; Sat, 25 Apr 2015 05:17:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3PCHrh5017731; Sat, 25 Apr 2015 14:17:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09DF4201982; Sat, 25 Apr 2015 14:18:52 +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 EE620200D0C; Sat, 25 Apr 2015 14:18:51 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.67]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3PCHLlA030355; Sat, 25 Apr 2015 14:17:22 +0200 Message-ID: <553B85D1.90107@gmail.com> Date: Sat, 25 Apr 2015 14:17:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <551C0877.1060100@gmail.com> <552F4165.9020300@gmail.com> <5536AB1E.6060507@gmail.com> <5537D047.5040502@gmail.com> <5539FE54.2030103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sofiane.imadali@gmail.com, Basavaraj Patil , "dmm@ietf.org" Subject: Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:18:00 -0000 Le 24/04/2015 21:22, Behcet Sarikaya a 茅crit : > I am still not convinced. > At home I have LTE. > LTE can be 3G if it is somewhat degraded and 3G is also available, so > no reason for inter technology handoff. YEs there is reason. At home one may prefer the cheap 802.11ac instead of 3G. The bandwith improvement is huge. > I am also concerned on some other MN ids proposed like RFid, what is > the assumption there? Is it that the sensor node will have Mobile IP > client? > To that I say, give me a break. Break. But the MN-ID as RFID does not necessarily mean it runs a MIP client. In some deployment of buses the RFID is on the passenger and the mobile router in the bus running Mobile IP uses another MN-ID form. YEt they authenticate to the same server, using MN-ID concept. I think yes, MN-ID should be independent of Mobile IP, but sometimes work together. Alex > > Behcet > Behcet > > On Fri, Apr 24, 2015 at 3:27 AM, Alexandru Petrescu > wrote: >> Le 23/04/2015 19:11, Behcet Sarikaya a 茅crit : >>> >>> On Wed, Apr 22, 2015 at 11:45 AM, Alexandru Petrescu >>> wrote: >>>> >>>> Le 22/04/2015 18:06, Behcet Sarikaya a 茅crit : >>>>> >>>>> >>>>> Hi Alex, >>>>> >>>>> On Tue, Apr 21, 2015 at 2:55 PM, Alexandru Petrescu >>>>> wrote: >>>>>> >>>>>> >>>>>> Le 16/04/2015 06:58, Jouni Korhonen a 茅crit : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> The adoption call for this I-D has ended. There is a clear concensus >>>>>>> to >>>>>>> adopt the I-D as a working group item. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I support its adoption. >>>>>> >>>>>> We have been working with an identifier specific to automobiles to use >>>>>> to >>>>>> realize access control. Identifying an entire set of IP nodes deployed >>>>>> in a >>>>>> vehicle is different than identifying an end-user like address@realm. >>>>>> >>>>>> We looked for such an identifier and believe the VIN (Vehicle >>>>>> Identification >>>>>> Number) be a good candidate. >>>>>> >>>>>> One would consider using one type, like type 40, to encode the VIN or >>>>>> parts >>>>>> of it, into an MN-ID. >>>>>> >>>>>> The questions to the group are the following: >>>>>> - is VIN considered private information? (in deployments it is private >>>>>> to a certain extent, but publicly avaliable to cameras or in public >>>>>> databases to another extent). >>>>>> - is the MN-ID type 40 ok for it. >>>>>> - is one type sufficient or should there be subtypes. >>>>> >>>>> >>>>> >>>>> What is your model here in providing Internet access to the car? >>>>> As you may know, operators in US are deploying systems that connect >>>>> the car to their LTE network upstream and downstream is the passengers >>>>> in the car that access over Wi-Fi. >>>>> With LTE, you get mobility support which is based on fixed anchoring. >>>>> I cc'ed to Raj who works on these types of technologies. >>>>> The ID there is the IMSI. I don't think vin is used. >>>> >>>> >>>> >>>> The model of Internet access to the cars for cars currently on market in >>>> Europe is the same - the LTE technology is used, using the IMSI as an >>>> identifier. However, that does not use MN-ID, is only IPv4, is not WiFi >>>> and >>>> does not resist to cellular generation upgrades to 5G and beyond. >>> >>> >>> I don't understand the handover scenario. I think you are mixing the >>> car and the passengers in the car. >>> LTE is available on a large geography, why should you handover the >>> upstream traffic to Wi-Fi? >> >> >> When the car arrives home it connects to the WiFi available in home, thus >> handing over from LTE. This is a sold use-case at e.g. Tesla. The WiFi >> hotspot can be the one deployed in-house, in-garage, or the WiFi offered by >> the electrical recharging stations. >> >> Other manufacturers propose scenarios in which car's WiFi antenna switches >> from being an in-car hotspot to being a Client to outside wifi. >> >> Some consider 802.11p (wifi for vehicles) to be deployed along highways and >> cars to perform handovers between these 802.11p access points. >> >> Next time on highway scan for WiFi - one is surprised by the number of >> hotspots driving around, even though often they use portals. >> >> There are many commercially considered scenarios involving WiFi handovers >> for cars. >> >> Alex >> >> >>> >>> Behcet >>>> >>>> >>>> Newer models will feature IPv6 in addition to IPv4, WiFi handover from >>>> LTE >>>> to house's hotspot, continuous sessions, and over-the-air software update >>>> for cheap upgradeability to future generation 5G and beyond. >>>> >>>> In this context it is hard to imagine IMSI will be there for a long time >>>> in >>>> a given car, and a more permanent identifier is needed. >>>> >>>> To Raj - is LTE considering other kinds of identifiers for access control >>>> (other than IMSI) for vehicular environments, like V2X? >>>> >>>> Alex >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>>> >>>>>>> - Jouni & Dapeng >>>>>>> >>>>>>> 4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> This emails starts a two week call for the I-D >>>>>>>> draft-perkins-dmm-4283mnids-01 >>>>>>>> to confirm the aadoption s a DMM WG document. The call ends April >>>>>>>> 15th >>>>>>>> EOB PST. >>>>>>>> >>>>>>>> Express your support or opposition to the mailing list. During the >>>>>>>> IETF92 meeting we got 7 voices for the adoption so at least the same >>>>>>>> amount supporting emails should be expected. >>>>>>>> >>>>>>>> - Jouni & Dapeng >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From nobody Sat Apr 25 05:21:31 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7451A1AB5 for ; Sat, 25 Apr 2015 05:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 VZ5BfC9av1kS for ; Sat, 25 Apr 2015 05:21:29 -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 AB8341A1AA5 for ; Sat, 25 Apr 2015 05:21:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3PCLRwg026435 for ; Sat, 25 Apr 2015 14:21:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16CDB201982 for ; Sat, 25 Apr 2015 14:22:56 +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 054D8200B52 for ; Sat, 25 Apr 2015 14:22:56 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.67]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3PCLQOU002011 for ; Sat, 25 Apr 2015 14:21:26 +0200 Message-ID: <553B86C5.3020003@gmail.com> Date: Sat, 25 Apr 2015 14:21:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832E4B634@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4B634@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] AERO as DMM working group item X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:21:30 -0000 Le 17/04/2015 18:27, Templin, Fred L a 閏rit : > Hello, > > I would like to request adoption of AERO as a DMM working group item > as a solution for enhanced mobility anchoring in particular and > distributed mobility management in general. The latest draft version > of AERO is here: > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > Thank you for your consideration, > > Fred Templin fred.l.templin@boeing.com > > _______________________________________________ dmm mailing list > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > I support adoption. The document presents a special way for mobility management in aeronautical networks which involves Mobile Routers onboard, as well as using standard IETF protocols and software. However, some use of protocols may be considered weird (eg DHCPv6-PD to provide a prefif to be used as an IID) although that weird use may result in certain operation advantage, and Route Optimization. I wonder what is the track considered for this document. Alex From nobody Sat Apr 25 07:39:35 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009B91B2B15 for ; Sat, 25 Apr 2015 07:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2jTyGEbkRPIk for ; Sat, 25 Apr 2015 07:39:33 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7111B2C46 for ; Sat, 25 Apr 2015 07:39:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3PEdW6Q007609; Sat, 25 Apr 2015 09:39:32 -0500 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3PEdMKh007601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 25 Apr 2015 09:39:23 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.186]) with mapi id 14.03.0235.001; Sat, 25 Apr 2015 07:39:22 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AERO as DMM working group item Thread-Index: AdB5KtmwGS4RWcPtRAGuebRvwStgRgGYiuiAAAn4HHA= Date: Sat, 25 Apr 2015 14:39:21 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E51B8E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B634@XCH-BLV-504.nw.nos.boeing.com> <553B86C5.3020003@gmail.com> In-Reply-To: <553B86C5.3020003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] AERO as DMM working group item X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 14:39:35 -0000 Hi Alex, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Saturday, April 25, 2015 5:21 AM > To: dmm@ietf.org > Subject: Re: [DMM] AERO as DMM working group item >=20 > Le 17/04/2015 18:27, Templin, Fred L a =E9crit : > > Hello, > > > > I would like to request adoption of AERO as a DMM working group item > > as a solution for enhanced mobility anchoring in particular and > > distributed mobility management in general. The latest draft version > > of AERO is here: > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > Thank you for your consideration, > > > > Fred Templin fred.l.templin@boeing.com > > > > _______________________________________________ dmm mailing list > > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > > > >=20 > I support adoption. Thanks. > The document presents a special way for mobility management in > aeronautical networks which involves Mobile Routers onboard, as well as > using standard IETF protocols and software. Yes, but it is about much more than just aeronautical networks. We are currently putting it on cell phones for accessing enterprise networks. > However, some use of protocols may be considered weird (eg DHCPv6-PD to > provide a prefif to be used as an IID) although that weird use may > result in certain operation advantage, and Route Optimization. Perhaps in this respect, beauty is in the eye of the beholder. > I wonder what is the track considered for this document. Standards track. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Apr 26 14:44:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A7E1A1BC6 for ; Sun, 26 Apr 2015 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2eZSKLVzLnSG for ; Sun, 26 Apr 2015 14:44:36 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::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 B31641A1BB1 for ; Sun, 26 Apr 2015 14:44:36 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so107106057pdb.1 for ; Sun, 26 Apr 2015 14:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=l40vEUDLwWWN+kZRz3I2Lj/Cq2Gz2c42uN9m/NU8SFc=; b=ZY+LTDgpEXDXbeQW97ApL0k551ge/y0n15y+koIiU1JpftbqgcBQD7RyZTvPMANSQ5 cyypem5RrZ4nmBu3rd95wCCFsYRPP+YMMScifl3kmZkGfnssFUcjTTVvT7H6EU9vPirb t/DXVOwEc+0qKuiUogl8GU8hIi0SCAsiIJKavg624V16mLGUeaRhkK8ZKrrHw0Qsudie oulfDzdS36Hu4nicmsi3e6JMV/7nSgAM9+wTZm0WXpdQJ9GMFkH1MFpfUlBpEuGqyCPq R99tQkHmETko6q0vH8HvwHC/Y+DwTINfbz3pmoHSfCOhiBO2Ixx3z0BvegN0WjxPHI8s LpTQ== X-Received: by 10.67.24.33 with SMTP id if1mr16278301pad.24.1430084676316; Sun, 26 Apr 2015 14:44:36 -0700 (PDT) Received: from ?IPv6:2601:9:3400:6c:d94d:312f:4169:efb4? ([2601:9:3400:6c:d94d:312f:4169:efb4]) by mx.google.com with ESMTPSA id h12sm17261301pdk.77.2015.04.26.14.44.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 14:44:35 -0700 (PDT) Message-ID: <553D5C40.5050301@gmail.com> Date: Sun, 26 Apr 2015 14:44:32 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Dapeng Liu , Jouni Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 21:44:38 -0000 Folks, Summer is getting closer as well as the Prague meeting. If you feel like having a presentation slot in the meeting let the chairs know (with I-D name, time requested and a reason why you need a slot). The WG I-Ds will have precedence and the rest of the available time will be divided using secret formula to individual contributions. We'd like to emphasize that for any I-Ds having discussion on the mailing list prior the meeting is a great plus and for a new work almost a prerequisite. Jouni & dapeng From nobody Sun Apr 26 19:02:04 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A690C1B2D4C for ; Sun, 26 Apr 2015 19:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.438 X-Spam-Level: ** X-Spam-Status: No, score=2.438 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 60PPFFDU-n87 for ; Sun, 26 Apr 2015 19:02:01 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 453C81B2D49 for ; Sun, 26 Apr 2015 19:01:59 -0700 (PDT) Received: from JoyYan (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIHyTmD1VlQQ7AA--.46667S2; Mon, 27 Apr 2015 10:01:55 +0800 (CST) Date: Mon, 27 Apr 2015 10:01:55 +0800 From: "Z.W. Yan" To: "Jouni Korhonen" , "dmm@ietf.org" , "Dapeng Liu" , "Jouni" References: <553D5C40.5050301@gmail.com> Message-ID: <201504271001550518347@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon762461685511_=====" X-CM-TRANSID: AQAAf0AZIHyTmD1VlQQ7AA--.46667S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Gw1UKFWkCFyfCFy3ZFy8Grg_yoWkGrX_ur ZFgry8Aw15tFy0gF47tF1DJrn3Wr42g3WUA34DX342vry8Aws8XwsxJ3sxZ3WxtFWUA3s8 GFWfAr17GrWUWjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUba8YjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAI xVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6x CaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC 0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcS sGvfC2KfnxnUUI43ZEXa7IU1_WrJUUUUU== X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 02:02:02 -0000 This is a multi-part message in MIME format. --=====003_Dragon762461685511_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMsDQpJdCdzIGFwcHJlY2lhdGVkIGlmIGEgMTAtbWludXRlIHNsb3QgY2FuIGJl IGFsbG9jYWx0ZWQgZm9yIHRoZSBITlAtcmVudW1iZXJpbmcgZHJhZnQ6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWRtbS1obnByZW51bS0wMSANCg0KV2Ugd2FudCB0byBp bnRyb2R1Y2UgdGhlIHJldmlzaW9uIHdvcmsgc2luY2UgdGhlIGxhc3QgSUVURiBtZWV0aW5nLg0K VGhhbmsgeW91IHNvIG11Y2ghDQoNCg0KMjAxNS0wNC0yNyANCg0KDQoNClouVy4gWWFuIA0KDQoN Cg0Kt6K8/sjLo7ogSm91bmkgS29yaG9uZW4gDQq3osvNyrG85KO6IDIwMTUtMDQtMjcgIDA1OjQ0 OjQzIA0KytW8/sjLo7ogZG1tQGlldGYub3JnOyBEYXBlbmcgTGl1OyBKb3VuaSANCrOty82juiAN Ctb3zOKjuiBbRE1NXSBJRVRGOTMgbWVldGluZy4uIGFuZCBmb3JtaW5nIHRoZSBhZ2VuZGEgDQog DQpGb2xrcywNClN1bW1lciBpcyBnZXR0aW5nIGNsb3NlciBhcyB3ZWxsIGFzIHRoZSBQcmFndWUg bWVldGluZy4gSWYgeW91IGZlZWwgbGlrZSANCmhhdmluZyBhIHByZXNlbnRhdGlvbiBzbG90IGlu IHRoZSBtZWV0aW5nIGxldCB0aGUgY2hhaXJzIGtub3cgKHdpdGggSS1EIA0KbmFtZSwgdGltZSBy ZXF1ZXN0ZWQgYW5kIGEgcmVhc29uIHdoeSB5b3UgbmVlZCBhIHNsb3QpLg0KVGhlIFdHIEktRHMg d2lsbCBoYXZlIHByZWNlZGVuY2UgYW5kIHRoZSByZXN0IG9mIHRoZSBhdmFpbGFibGUgdGltZSB3 aWxsIA0KYmUgZGl2aWRlZCB1c2luZyBzZWNyZXQgZm9ybXVsYSB0byBpbmRpdmlkdWFsIGNvbnRy aWJ1dGlvbnMuDQpXZSdkIGxpa2UgdG8gZW1waGFzaXplIHRoYXQgZm9yIGFueSBJLURzIGhhdmlu ZyBkaXNjdXNzaW9uIG9uIHRoZSANCm1haWxpbmcgbGlzdCBwcmlvciB0aGUgbWVldGluZyBpcyBh IGdyZWF0IHBsdXMgYW5kIGZvciBhIG5ldyB3b3JrIGFsbW9zdCANCmEgcHJlcmVxdWlzaXRlLg0K Sm91bmkgJiBkYXBlbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo= --=====003_Dragon762461685511_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNzI5NiI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IMvOzOU7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsN Cn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24x IHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAx MC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlm eTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0N CkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0la RTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1 c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0K fQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBs ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglG T05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUt dHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9u MQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0KfQ0KT0wg ew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFSR0lOOiAx MHB4Ij4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkRlYXIg Q2hhaXJzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5JdCdzIGFwcHJl Y2lhdGVkIGlmIGEgMTAtbWludXRlIHNsb3QgY2FuIGJlIGFsbG9jYWx0ZWQgDQpmb3IgdGhlIEhO UC1yZW51bWJlcmluZyBkcmFmdDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw ODA+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbi1kbW0taG5wcmVudW0tMDEg DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPldlIHdhbnQgdG8gaW50cm9kdWNlIHRoZSBy ZXZpc2lvbiB3b3JrIHNpbmNlIHRoZSBsYXN0IA0KSUVURiBtZWV0aW5nLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFuayB5b3Ugc28gbXVjaCE8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9 VmVyZGFuYT4yMDE1LTA0LTI3IDwvRk9OVD48L0RJVj48Rk9OVCANCmNvbG9yPSMwMDAwODAgc2l6 ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEwMHB4IiBhbGlnbj1sZWZ0IGNv bG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNp emU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+Wi5XLiBZYW48L1NQQU4+IDwvRk9OVD48L0RJVj4NCjxI UiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5h PjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gSm91bmkgS29yaG9uZW4gDQo8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz63osvNyrG85KO6PC9TVFJP Tkc+IDIwMTUtMDQtMjcmbmJzcDsgMDU6NDQ6NDMgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiBkbW1AaWV0Zi5v cmc7IERhcGVuZyBMaXU7IA0KSm91bmkgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT1WZXJkYW5hPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPtb3zOKjujwvU1RST05HPiBbRE1NXSBJ RVRGOTMgbWVldGluZy4uIGFuZCANCmZvcm1pbmcgdGhlIGFnZW5kYSA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+Rm9sa3MsPC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5TdW1tZXImbmJzcDtpcyZuYnNwO2dldHRpbmcmbmJzcDtjbG9zZXImbmJzcDthcyZuYnNwO3dl bGwmbmJzcDthcyZuYnNwO3RoZSZuYnNwO1ByYWd1ZSZuYnNwO21lZXRpbmcuJm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtmZWVsJm5ic3A7bGlrZSZuYnNwOzwvRElWPg0KPERJVj5oYXZpbmcmbmJzcDth Jm5ic3A7cHJlc2VudGF0aW9uJm5ic3A7c2xvdCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7bWVldGlu ZyZuYnNwO2xldCZuYnNwO3RoZSZuYnNwO2NoYWlycyZuYnNwO2tub3cmbmJzcDsod2l0aCZuYnNw O0ktRCZuYnNwOzwvRElWPg0KPERJVj5uYW1lLCZuYnNwO3RpbWUmbmJzcDtyZXF1ZXN0ZWQmbmJz cDthbmQmbmJzcDthJm5ic3A7cmVhc29uJm5ic3A7d2h5Jm5ic3A7eW91Jm5ic3A7bmVlZCZuYnNw O2EmbmJzcDtzbG90KS48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO1dHJm5ic3A7 SS1EcyZuYnNwO3dpbGwmbmJzcDtoYXZlJm5ic3A7cHJlY2VkZW5jZSZuYnNwO2FuZCZuYnNwO3Ro ZSZuYnNwO3Jlc3QmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2F2YWlsYWJsZSZuYnNwO3RpbWUmbmJz cDt3aWxsJm5ic3A7PC9ESVY+DQo8RElWPmJlJm5ic3A7ZGl2aWRlZCZuYnNwO3VzaW5nJm5ic3A7 c2VjcmV0Jm5ic3A7Zm9ybXVsYSZuYnNwO3RvJm5ic3A7aW5kaXZpZHVhbCZuYnNwO2NvbnRyaWJ1 dGlvbnMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XZSdkJm5ic3A7bGlrZSZuYnNwO3RvJm5i c3A7ZW1waGFzaXplJm5ic3A7dGhhdCZuYnNwO2ZvciZuYnNwO2FueSZuYnNwO0ktRHMmbmJzcDto YXZpbmcmbmJzcDtkaXNjdXNzaW9uJm5ic3A7b24mbmJzcDt0aGUmbmJzcDs8L0RJVj4NCjxESVY+ bWFpbGluZyZuYnNwO2xpc3QmbmJzcDtwcmlvciZuYnNwO3RoZSZuYnNwO21lZXRpbmcmbmJzcDtp cyZuYnNwO2EmbmJzcDtncmVhdCZuYnNwO3BsdXMmbmJzcDthbmQmbmJzcDtmb3ImbmJzcDthJm5i c3A7bmV3Jm5ic3A7d29yayZuYnNwO2FsbW9zdCZuYnNwOzwvRElWPg0KPERJVj5hJm5ic3A7cHJl cmVxdWlzaXRlLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj5Kb3VuaSZuYnNwOyZhbXA7Jm5ic3A7ZGFwZW5nPC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElWPg0K PERJVj5kbW0mbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kbW1AaWV0Zi5vcmc8 L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L0RJ Vj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon762461685511_=====-- From nobody Mon Apr 27 06:45:25 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07581A0218 for ; Mon, 27 Apr 2015 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6hmWOZhDsP5L for ; Mon, 27 Apr 2015 06:45:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186321A01D6 for ; Mon, 27 Apr 2015 06:45:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E571688124 for ; Mon, 27 Apr 2015 06:45:21 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9F9841368362 for ; Mon, 27 Apr 2015 06:45:21 -0700 (PDT) Message-ID: <553E3D68.3080307@innovationslab.net> Date: Mon, 27 Apr 2015 09:45:12 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vfWvedUn33TobJOinWjkjILqL3nhf2EsO" Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 13:45:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vfWvedUn33TobJOinWjkjILqL3nhf2EsO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/22/15 12:51 PM, Templin, Fred L wrote: > Hi Alex, >=20 >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Tuesday, April 21, 2015 12:42 PM >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org >> Subject: Re: [DMM] Mobility Exposure and Selection WT call >> >> Le 31/03/2015 00:42, Templin, Fred L a =E9crit : >>> Hi Alex, >>> >>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 >>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility >>>> Exposure and Selection WT call >>>> >>>> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : >>>>> Alex, >>>>> >>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: >>>>> >>>>> [snip] >>>>> >>>>>>> I thought by "fixed" you meant it stays the same wherever the >>>>>>> Host goes (something like the Home Address). >>>>>> >>>>>> Alper - I think a LL address can also be qualified as 'fixed' - >>>>>> it never changes. >>>>> >>>>> Does LL here mean link-local or link-layer? If it is the former >>>>> one, then the above assertion is not correct. >>>> >>>> Link-local. >>>> >>>> And you seem to say a link-local address is not fixed? I think >>>> link-local addresses _are_ fixed set in stone. They are formed >>>> locally without need of help from router. >>> >>> AERO provides a fixed link-local address that is formed from a >>> prefix received by DHCPv6 Prefix Delegation (PD). >> >> Fred - but why should this ll prefix be provided by DHCP? Is it of >> variable value? Or is the link-local constant all the time? (in which= >> case it could be hardcoded everywhere). >=20 > DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO > Client (e.g., 2001:db8:1:2::/64). The Client then constructs an > AERO link-local address from the prefix as fe80::2001:db8:1:2 > (i.e., it embeds the 64-bit prefix from the prefix delegation in > the 64-bit interface identifier of an IPv6 link-local address). So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Regards, Brian --vfWvedUn33TobJOinWjkjILqL3nhf2EsO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVPj1oAAoJEBOZRqCi7goq0iAH/1Ivj5dOwlyCbC7vddXtPUPe TwCYP2Rn44734HUiOFte6rh75d3iQvL6MiXwbQxrLmw95+Emio9hirp8pxhGaEcD NKmuI31iO89iDertSBakD2dK9gr+3YPuaoEylijnWorhtg6ZjbhUntP5SAV4/ols dFGgK+ODfda0OjpRnV8bB9ZfqnyeaNaQgSrx5LI2fXCaxJxGfMdwUUY/kfQEJY2d rtO+OMEGpwYe1YI9dsuDwbGrcCNTSID2jGq7r++wA5FhhmA3TlThZJQXvV7Yqwrz 1XYAwBjYUaQglXjpcpTMcC+e6bTPSU/eRwYMG67a5cOmSaXNuIWRWSagKLshJPM= =v45g -----END PGP SIGNATURE----- --vfWvedUn33TobJOinWjkjILqL3nhf2EsO-- From nobody Mon Apr 27 08:55:17 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529D61A892A for ; Mon, 27 Apr 2015 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bB3P5EYukdOI for ; Mon, 27 Apr 2015 08:55:13 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAD21A8908 for ; Mon, 27 Apr 2015 08:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3RFriJC014725; Mon, 27 Apr 2015 08:53:44 -0700 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3RFrgXB014646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Apr 2015 08:53:42 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.98]) with mapi id 14.03.0235.001; Mon, 27 Apr 2015 08:53:27 -0700 From: "Templin, Fred L" To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgIAIH48A//+qQ0A= Date: Mon, 27 Apr 2015 15:53:27 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <553E3D68.3080307@innovationslab.net> In-Reply-To: <553E3D68.3080307@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:55:15 -0000 Hi Brian, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Monday, April 27, 2015 6:45 AM > To: dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 >=20 >=20 > On 4/22/15 12:51 PM, Templin, Fred L wrote: > > Hi Alex, > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Tuesday, April 21, 2015 12:42 PM > >> To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org > >> Subject: Re: [DMM] Mobility Exposure and Selection WT call > >> > >> Le 31/03/2015 00:42, Templin, Fred L a =E9crit : > >>> Hi Alex, > >>> > >>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] > >>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 > >>>> PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility > >>>> Exposure and Selection WT call > >>>> > >>>> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : > >>>>> Alex, > >>>>> > >>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > >>>>> > >>>>> [snip] > >>>>> > >>>>>>> I thought by "fixed" you meant it stays the same wherever the > >>>>>>> Host goes (something like the Home Address). > >>>>>> > >>>>>> Alper - I think a LL address can also be qualified as 'fixed' - > >>>>>> it never changes. > >>>>> > >>>>> Does LL here mean link-local or link-layer? If it is the former > >>>>> one, then the above assertion is not correct. > >>>> > >>>> Link-local. > >>>> > >>>> And you seem to say a link-local address is not fixed? I think > >>>> link-local addresses _are_ fixed set in stone. They are formed > >>>> locally without need of help from router. > >>> > >>> AERO provides a fixed link-local address that is formed from a > >>> prefix received by DHCPv6 Prefix Delegation (PD). > >> > >> Fred - but why should this ll prefix be provided by DHCP? Is it of > >> variable value? Or is the link-local constant all the time? (in which > >> case it could be hardcoded everywhere). > > > > DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO > > Client (e.g., 2001:db8:1:2::/64). The Client then constructs an > > AERO link-local address from the prefix as fe80::2001:db8:1:2 > > (i.e., it embeds the 64-bit prefix from the prefix delegation in > > the 64-bit interface identifier of an IPv6 link-local address). >=20 > So, it is not actually a link-local address per the IPv6 Addressing > Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. Thanks - Fred fred.l.templin@boeing.com > Regards, > Brian From nobody Mon Apr 27 09:00:00 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434781A1A5D for ; Mon, 27 Apr 2015 08:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vUwgoztRTnia for ; Mon, 27 Apr 2015 08:59:57 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145141A88E7 for ; Mon, 27 Apr 2015 08:59:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3RFxuYQ031198; Mon, 27 Apr 2015 08:59:56 -0700 Received: from XCH-BLV-202.nw.nos.boeing.com (xch-blv-202.nw.nos.boeing.com [10.57.37.69]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3RFxpds031135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Apr 2015 08:59:51 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.165]) with mapi id 14.03.0235.001; Mon, 27 Apr 2015 08:59:50 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" , Dapeng Liu Thread-Topic: [DMM] IETF93 meeting.. and forming the agenda Thread-Index: AQHQgGo7jWU/CKS6LUyDcvybTDsr7Z1hBNog Date: Mon, 27 Apr 2015 15:59:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E525CB@XCH-BLV-504.nw.nos.boeing.com> References: <553D5C40.5050301@gmail.com> In-Reply-To: <553D5C40.5050301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:59:58 -0000 Hi Jouni, It seems there is interest in the AERO address format and its relation to the AERO link and the AERO routing system. I would like to therefore request a 10min slot to discuss just this aspect of AERO so that everyone has a clear understanding of this relationship. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Sunday, April 26, 2015 2:45 PM > To: dmm@ietf.org; Dapeng Liu; Jouni > Subject: [DMM] IETF93 meeting.. and forming the agenda >=20 > Folks, >=20 > Summer is getting closer as well as the Prague meeting. If you feel like > having a presentation slot in the meeting let the chairs know (with I-D > name, time requested and a reason why you need a slot). >=20 > The WG I-Ds will have precedence and the rest of the available time will > be divided using secret formula to individual contributions. >=20 > We'd like to emphasize that for any I-Ds having discussion on the > mailing list prior the meeting is a great plus and for a new work almost > a prerequisite. >=20 >=20 >=20 > Jouni & dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Apr 27 09:07:50 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD451A1A5D for ; Mon, 27 Apr 2015 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.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_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham 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 jB_k6VrMJ4uB for ; Mon, 27 Apr 2015 09:07:48 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 7F9731A88CF for ; Mon, 27 Apr 2015 09:07:25 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so132979495pdb.1 for ; Mon, 27 Apr 2015 09:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ucsip7jQA4Y31YpfcR7kwSrYExAXTHROeWdMixCMAOQ=; b=ffruPtrr7Eqo/K51muR4iSu4nNK6hwMymmlRrFuHwA+E9JfylJgY1idrtfCQOQY7Le 9VKXg8JYUHd369K+2pV5D+Xa7DXo7khL8niWK+MFBjqjIfdhAas/ftvUqTyZP2gQJyKx i4axNev0hMNAkKHL7TQqo7tQXPJiijo8pKko2zb6pV6wlChOodU+zwED2TCaJeBm9UL6 DuAHAEAJia7n/QJKDQwjHyiLwjdowJ3YWlAE1ve81Qqqtqo+lJVI5fG1BJGTDZWJYEsl s1Ecx0sWMfx2POUPRk3x7xKBRlhO5iz6eeF7OOHNaiCRCInAgiXqzqFIeHzHU6R1rISr /+qQ== X-Received: by 10.70.91.225 with SMTP id ch1mr23744529pdb.65.1430150845198; Mon, 27 Apr 2015 09:07:25 -0700 (PDT) Received: from [10.16.11.76] ([216.31.219.19]) by mx.google.com with ESMTPSA id ml6sm19856122pdb.69.2015.04.27.09.07.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 09:07:23 -0700 (PDT) Message-ID: <553E5EB9.6060409@gmail.com> Date: Mon, 27 Apr 2015 09:07:21 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Z.W. Yan" , "dmm@ietf.org" , Dapeng Liu References: <553D5C40.5050301@gmail.com> <201504271001550518347@cnnic.cn> In-Reply-To: <201504271001550518347@cnnic.cn> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] IETF93 meeting.. and forming the agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:07:50 -0000 ack. 4/26/2015, 7:01 PM, Z.W. Yan kirjoitti: > Dear Chairs, > It's appreciated if a 10-minute slot can be allocalted for the > HNP-renumbering draft: > https://tools.ietf.org/html/draft-yan-dmm-hnprenum-01 > We want to introduce the revision work since the last IETF meeting. > Thank you so much! > 2015-04-27 > ------------------------------------------------------------------------ > Z.W. Yan > ------------------------------------------------------------------------ > *发件人：* Jouni Korhonen > *发送时间：* 2015-04-27 05:44:43 > *收件人：* dmm@ietf.org; Dapeng Liu; Jouni > *抄送：* > *主题：* [DMM] IETF93 meeting.. and forming the agenda > Folks, > Summer is getting closer as well as the Prague meeting. If you feel like > having a presentation slot in the meeting let the chairs know (with I-D > name, time requested and a reason why you need a slot). > The WG I-Ds will have precedence and the rest of the available time will > be divided using secret formula to individual contributions. > We'd like to emphasize that for any I-Ds having discussion on the > mailing list prior the meeting is a great plus and for a new work almost > a prerequisite. > Jouni & dapeng > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Apr 27 09:22:06 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D01A891A for ; Mon, 27 Apr 2015 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ONVxi1J_fLcp for ; Mon, 27 Apr 2015 09:22:03 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BFD1A88F9 for ; Mon, 27 Apr 2015 09:22:03 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id CBFD988124 for ; Mon, 27 Apr 2015 09:22:03 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 942361368362 for ; Mon, 27 Apr 2015 09:22:03 -0700 (PDT) Message-ID: <553E6223.3020209@innovationslab.net> Date: Mon, 27 Apr 2015 12:21:55 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <553E3D68.3080307@innovationslab.net> <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uHnIpkwRnpN07cOtudqWumI6jO44oHcWq" Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:22:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uHnIpkwRnpN07cOtudqWumI6jO44oHcWq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/27/15 11:53 AM, Templin, Fred L wrote: >> So, it is not actually a link-local address per the IPv6 Addressing >> Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). >=20 > Just because the AERO address Interface ID is not formed via EUI-64 > does not mean that it is not a link-local address (see RFC7136, which > updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. --uHnIpkwRnpN07cOtudqWumI6jO44oHcWq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVPmIjAAoJEBOZRqCi7goqG1oH/2qN2n2uufLKVlnFrcYSLck8 4f/yaY4IWGqK3Uy/VQgwnRgPu1ogHy4KYn5Djze8lsxlY63O179jnv/+lfmq61WJ 6EEHwsR8Mp+MhJiIpMO71r4xsmdwTgLWB60m+GOpe42ccN/p6WJsXZmOEEGI19ef yKUjmS1bC4woarAd51Bm/v5AmOt4QCwERKdh1CwsdJNi4A3FcOyt9zQc6sE2djyK GSD4d0y6Sil/7yUORIeCm382nveAVgBT7PIQN96fqlYIkUUUZYBQEhChFFpZXQwd FD5keAwffMGd5S97nYKqQDV7HvYFRNpgfMeC+XynqDcFT818VTKya3e5D7ZPatI= =O5Ek -----END PGP SIGNATURE----- --uHnIpkwRnpN07cOtudqWumI6jO44oHcWq-- From nobody Mon Apr 27 09:30:45 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878E41A8A5E for ; Mon, 27 Apr 2015 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 N2IKqeLgXfbM for ; Mon, 27 Apr 2015 09:30:43 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1041A8A3C for ; Mon, 27 Apr 2015 09:30:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3RGUWMu015344; Mon, 27 Apr 2015 09:30:32 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3RGULa7015182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Apr 2015 09:30:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.150]) with mapi id 14.03.0235.001; Mon, 27 Apr 2015 09:30:20 -0700 From: "Templin, Fred L" To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgIAIH48A//+qQ0CAAIGGgP//jKiw Date: Mon, 27 Apr 2015 16:30:19 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E526EC@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <553E3D68.3080307@innovationslab.net> <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> <553E6223.3020209@innovationslab.net> In-Reply-To: <553E6223.3020209@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:30:44 -0000 Hi Brian, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Monday, April 27, 2015 9:22 AM > To: dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 >=20 >=20 > On 4/27/15 11:53 AM, Templin, Fred L wrote: >=20 > >> So, it is not actually a link-local address per the IPv6 Addressing > >> Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). > > > > Just because the AERO address Interface ID is not formed via EUI-64 > > does not mean that it is not a link-local address (see RFC7136, which > > updates RFC4291). RFC7421 gives further commentary. >=20 > I am not referring to the IID of the link-local address. I am talking > about the 54 bits of zero which immediately follow the FE80::/10 prefix. AERO leaves those 54 bits as zero - are you seeing some place in the spec where it does not appear that way? Thanks - Fred fred.l.templin@boeing.com From nobody Mon Apr 27 09:36:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051271A8A46 for ; Mon, 27 Apr 2015 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 dzWedBp5d_RV for ; Mon, 27 Apr 2015 09:36:21 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D111A8A20 for ; Mon, 27 Apr 2015 09:36:21 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C8B8C88124 for ; Mon, 27 Apr 2015 09:36:21 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7BDFD1368362 for ; Mon, 27 Apr 2015 09:36:21 -0700 (PDT) Message-ID: <553E6583.6030507@innovationslab.net> Date: Mon, 27 Apr 2015 12:36:19 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <553E3D68.3080307@innovationslab.net> <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> <553E6223.3020209@innovationslab.net> <2134F8430051B64F815C691A62D9831832E526EC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E526EC@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UMESaj9nOo5GTBA2knJd5Tecw9bpv6V4O" Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:36:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UMESaj9nOo5GTBA2knJd5Tecw9bpv6V4O Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/27/15 12:30 PM, Templin, Fred L wrote: > Hi Brian, >=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman >> Sent: Monday, April 27, 2015 9:22 AM >> To: dmm@ietf.org >> Subject: Re: [DMM] Mobility Exposure and Selection WT call >> >> >> >> On 4/27/15 11:53 AM, Templin, Fred L wrote: >> >>>> So, it is not actually a link-local address per the IPv6 Addressing >>>> Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). >>> >>> Just because the AERO address Interface ID is not formed via EUI-64 >>> does not mean that it is not a link-local address (see RFC7136, which= >>> updates RFC4291). RFC7421 gives further commentary. >> >> I am not referring to the IID of the link-local address. I am talking= >> about the 54 bits of zero which immediately follow the FE80::/10 prefi= x. >=20 > AERO leaves those 54 bits as zero - are you seeing some place in the > spec where it does not appear that way? Apologies. I read your example incorrectly. As long as the prefix delegated is 64 bits... Brian --UMESaj9nOo5GTBA2knJd5Tecw9bpv6V4O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVPmWDAAoJEBOZRqCi7goqLCQIAMMWMt/9MCCiPJJtz0LFf/cq Og5N4+js0G8hpl6D3k6rlU1hr2mdvV2IQUOShvoMvCtscoTcxRZsB1N4Ie0e5rui fs3jWoIJ4mX4mF2/sRmbUoFW+zcMyaznXl7D0Ri4wqdO/lZBprmYWHfQNQj20u8S ki7+yrzIS2UEevSrJcqBv7HvISBxsBhnimZHZJDF7wdF3OKxrUI/en8+tVnEyNt5 YEQvMrTiCbfiRVow5lZ/QQegb31GZNYjtspyVlPUUSQirrMPg/uR+PVB3rL4OvcP W0mgDrRwcE+mBglwp/S0EM74iyEQBonRzge9zy591yYvPABUN6vhR6B3HCeMc78= =+XYW -----END PGP SIGNATURE----- --UMESaj9nOo5GTBA2knJd5Tecw9bpv6V4O-- From nobody Mon Apr 27 09:55:21 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7951A8A4B for ; Mon, 27 Apr 2015 09:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Df6JM--9-2k0 for ; Mon, 27 Apr 2015 09:55:10 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C27F1A8A01 for ; Mon, 27 Apr 2015 09:55:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3RGtAWk030078; Mon, 27 Apr 2015 09:55:10 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3RGt0G9029861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Apr 2015 09:55:00 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.150]) with mapi id 14.03.0235.001; Mon, 27 Apr 2015 09:55:00 -0700 From: "Templin, Fred L" To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnAgCLXJoCAAOqdgIAIH48A//+qQ0CAAIGGgP//jKiwgAB3XoD//491YA== Date: Mon, 27 Apr 2015 16:54:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E527BF@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> <5536A823.9070803@gmail.com> <2134F8430051B64F815C691A62D9831832E4FA76@XCH-BLV-504.nw.nos.boeing.com> <553E3D68.3080307@innovationslab.net> <2134F8430051B64F815C691A62D9831832E52597@XCH-BLV-504.nw.nos.boeing.com> <553E6223.3020209@innovationslab.net> <2134F8430051B64F815C691A62D9831832E526EC@XCH-BLV-504.nw.nos.boeing.com> <553E6583.6030507@innovationslab.net> In-Reply-To: <553E6583.6030507@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:55:20 -0000 Hi Brian, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Monday, April 27, 2015 9:36 AM > To: dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 >=20 >=20 > On 4/27/15 12:30 PM, Templin, Fred L wrote: > > Hi Brian, > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > >> Sent: Monday, April 27, 2015 9:22 AM > >> To: dmm@ietf.org > >> Subject: Re: [DMM] Mobility Exposure and Selection WT call > >> > >> > >> > >> On 4/27/15 11:53 AM, Templin, Fred L wrote: > >> > >>>> So, it is not actually a link-local address per the IPv6 Addressing > >>>> Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). > >>> > >>> Just because the AERO address Interface ID is not formed via EUI-64 > >>> does not mean that it is not a link-local address (see RFC7136, which > >>> updates RFC4291). RFC7421 gives further commentary. > >> > >> I am not referring to the IID of the link-local address. I am talking > >> about the 54 bits of zero which immediately follow the FE80::/10 prefi= x. > > > > AERO leaves those 54 bits as zero - are you seeing some place in the > > spec where it does not appear that way? >=20 > Apologies. I read your example incorrectly. As long as the prefix > delegated is 64 bits... Yes, that is correct. The longest prefix AERO can delegate is /64. It can however delegate shorter prefixes like /56, /48, etc. Thanks - Fred fred.l.templin@boeing.com > Brian